[05:59]  * ToyKeeper wonders how to get relatively small feature requests pushed through the launchpad development process
[06:01] <jml> ToyKeeper: filing a bug works pretty well, as does mentioning it on the #launchpad channel.
[06:01] <ToyKeeper> Bug 161187 has been idle since November, and seems like it'd be a pretty quick, low-risk enhancement.
[06:01] <ToyKeeper> Oops, this is -meeting.  Xchat cuts off the tab titles.  :0
[09:17] <mrevell> g
[15:01] <barry> hello everyone and welcome to this week's ameu reviewers meeting.  who's here today?
[15:01] <sinzui> me
[15:01] <bigjools> me
[15:01] <schwuk> me
[15:01] <bac> me
[15:01] <allenap> me
[15:01] <intellectronica> me
[15:02] <flacoste> me
[15:02] <salgado> me
[15:02] <barry> BjornT: ping
[15:02] <barry> danilos: ping
[15:02] <barry> EdwinGrubbs: ping
[15:02] <barry> gmb: ping
[15:02] <intellectronica> barry: gmb had to leave urgently earlier today, so he probably won't be participating in the meeting
[15:03] <BjornT> me
[15:03] <EdwinGrubbs> me
[15:03] <barry> intellectronica: okay thanks (hope all is okay)
[15:03] <barry> statik: ping
[15:03] <barry> i think that's everyone
[15:03] <statik> me!
[15:03] <barry> == Agenda ==
[15:03] <barry>  * Roll call
[15:03] <barry>  * Next meeting
[15:03] <barry>  * Action items
[15:03] <barry>  * Queue status
[15:03] <barry>  * Mentoring update
[15:03] <barry>  * Review process
[15:03] <barry>    * domain-specific cheat sheets: there should be only one way to do it
[15:03] <barry>    * (intellectronica) What should our policy be for the formatting of destructuring assingments?
[15:03] <barry>  * Next meeting
[15:04] <barry> everyone good for next week, same time & place
[15:04] <barry> we'll take that as "yes" :)
[15:04] <barry>  * Action items
[15:05] <barry>  * barry to start discussion of big branch rejection policy on ml
[15:05]  * barry sucks
[15:05] <barry>  * bigjools to start domain specific cheat sheets
[15:05]  * bigjools sucks too
[15:05] <barry>  * flacoste to add `safe_hasattr()` to `lazr.utils`
[15:05] <bigjools> tbh I won't start that until after 2.0
[15:05] <barry> flacoste: does NOT suck!
[15:05] <flacoste> done!
[15:05] <barry> bigjools: okay, should we leave it on there or axe it?
[15:06] <bigjools> barry: it might be better to axe it until we can all agree on a good format for each project
[15:06] <barry> bigjools: done
[15:06] <bigjools> common format, I mean
[15:06] <barry>  * bjorn to add recommendation to test style guide saying don't use asserts in doctests
[15:07] <barry> BjornT: ^^
[15:07] <BjornT> that's done
[15:07] <barry> BjornT: excellent, thanks!
[15:07] <barry>  * Queue status
[15:08] <barry> jml was going to remove his rejected branch from the general queue
[15:08] <intellectronica> there are quite a few branches on the general queue. i suggest allocating to reviewers at the end of allenap's shift and mine if we didn't finish
[15:08] <barry> other than that, how are things going?
[15:08] <barry> intellectronica: +1
[15:08] <barry> intellectronica: favor mentorees if you can
[15:09] <intellectronica> ah good idea, wouldn't have thought about that
[15:09]  * bigjools does not need any more this week!
[15:09] <intellectronica> bigjools: noted. but you can always reject if you're overloaded
[15:10] <bigjools> just saving wasted effort ...
[15:10] <barry> any other queue related comments?
[15:11] <barry>  * Mentoring update
[15:11] <barry> if you have graduations or suggestions for recruits, send 'em to me
[15:12] <barry> that's all i have
[15:12] <flacoste> that was shor1
[15:12] <barry> wait, just on mentoring...
[15:12] <barry>  * Review process
[15:12] <barry>    * domain-specific cheat sheets: there should be only one way to do it
[15:13] <intellectronica> yeah, you should _always_ cheat
[15:13] <barry> bigjools: something was suggested in the asiapac meeting, regarding the soyuz suggestion you made.  jml thought that the code should express there's only one way to do it
[15:13] <bigjools> barry: that would be quite hard
[15:14] <bigjools> but I understand the ethos
[15:14] <barry> bigjools: make it a private attribute?
[15:14] <barry> bigjools: or, er non-public
[15:14] <barry> but in general, yes, that's what we should be doing
[15:14] <bigjools> it needs lots of drive-by fixing before that can happen, but yes I agree
[15:15] <bigjools> encapsulation is the way forwards
[15:15] <bigjools> ;)
[15:15] <barry> bigjools: cool :)
[15:15] <barry> btw intellectronica :)
[15:15] <barry>    * (intellectronica) What should our policy be for the formatting of destructuring assingments?
[15:15] <barry> intellectronica: the floor is yours
[15:16] <intellectronica> well, the question is pretty self explenatory
[15:16] <intellectronica> a) (item1, item2) = multival_func()
[15:16] <intellectronica> b) [item1, item2] = multival_func()
[15:16] <intellectronica> c) item1, item2 = multival_func()
[15:16] <intellectronica> which one should it be?
[15:16] <intellectronica> i used to write c, today i reviewed b, and got convinced that it should probably be a
[15:16]  * barry prefers (c) unless there's only one item
[15:16]  * bigjools votes (a) or (b) but not (c)
[15:16] <bigjools> and kiko preferred that too
[15:17]  * sinzui lists c
[15:17]  * bac prefers c
[15:17]  * allenap prefers c
[15:17] <salgado> yeah, I prefer (c) too
[15:17] <kiko> what are the dangers with c)
[15:17] <barry> bigjools: kiko prefers (c)?
[15:17]  * EdwinGrubbs thinks "item1 = func()[0]" looks cleaner for a single value
[15:17]  * sinzui likes c
[15:17] <kiko> ?
[15:17] <barry> EdwinGrubbs: i agree, but there's been disagreement over that one.  SteveA prefers:
[15:17] <intellectronica> kiko: you mentioned problems when refactoring. one could get confused when cut-and-pasting code, i suppose
[15:17] <barry> [item] = func()
[15:18]  * flacoste voes c
[15:18] <barry> and i've tended to let those go in reviews these days, though i was much stickier about them at one time
[15:18] <flacoste> that's because it's easy to miss the trailing comma
[15:18] <barry> flacoste: yes, definite this would suck:  foo, = func()
[15:18] <flacoste> or because that makes sure that you are really expecting only one items
[15:19] <flacoste> [item] = func() vs item func()[0]
[15:19] <barry> SteveA: things the latter looks "magical"
[15:19] <barry> er, s/things/thinks
[15:19]  * allenap prefers tuple literals: (item,) = func()
[15:19] <intellectronica> i think the format for two items should be identical to the format for one item, for simplicity
[15:19] <sinzui> barry: the latter is obtuse
[15:19] <EdwinGrubbs> (foo,) = func() would also look ugly
[15:19] <barry> i.e. it's not clear that you're expecting func() to return a sequence of exactly one item
[15:20] <EdwinGrubbs> [foo] = func() is cleaner
[15:20] <barry> intellectronica: well, unfortunately, python has this syntactic wart, so i'm not in favor of consistency here
[15:20] <salgado> I think we should use "[item] = singleval_func()" and "item1, item2 = multival_func()".  the reason being that in the first case that makes it clear that the return value is expected to have a single value and the brackets makes it more visually distinctive than a single trailing comma (e.g. "item, = func()")
[15:21] <barry> salgado: +1
[15:21] <allenap> functions always returning a 1-tuple are probably broken anyway.
[15:21] <intellectronica> barry: we could always use square brackets. i also like omitting them, but kiko's argument was convincing
[15:21] <bac> and if you're only interested in the nth value?  is 'item = func()[n]' acceptable then?
[15:21] <bigjools> hmmm it smacks of inconsistency to me
[15:21] <flacoste> i think so
[15:21] <barry> allenap: i've seen them mostly in tests, where func() returns "some sequence" which for a test case happens to have exactly 1 item
[15:21] <kiko> yes
[15:21] <kiko> I personally feel that
[15:22] <kiko> a, b = x
[15:22] <kiko> is kinda error prone
[15:22] <salgado> bac, in that case I usually unpack all items and then use only the one I want
[15:22] <kiko> (a, b) = x
[15:22] <kiko> I think that
[15:22] <allenap> barry: ah, true.
[15:22] <kiko> a = x, y
[15:22] <kiko> is even more error prone
[15:22] <kiko> and we should definitely always do
[15:22] <flacoste> kiko: why is it error prone?
[15:22] <kiko> a = (x, y)
[15:22] <sinzui> I like to see all the items unpacked...the identifier names act as documentation even when one one item is used.
[15:22] <flacoste> no, a, b = y
[15:22] <intellectronica> i agree with kiko. i think we should have `(x,) = func()` and `(x, y) = func()`
[15:22] <kiko> flacoste, because it's easy to miss the comma in long statements
[15:23] <barry> bac: i personally have no problem with that
[15:23] <salgado> bac, the reason why I do that is explained by sinzui above. :)
[15:23] <kiko> I've lost time tracking down this sort of sillyness
[15:23] <flacoste> (x,) = func() is error prone
[15:23] <intellectronica> sinzui: but won't lint error on that?
[15:23] <flacoste> that's easy to miss the comma there and do
[15:23] <flacoste> (x) = func()
[15:23] <flacoste> which isn't the same thing
[15:23] <sinzui> intellectronica: pylint sucks!
[15:23] <flacoste> i'm -1 on (x,)
[15:23] <kiko> flacoste, agreed. if you have a comma, we should have multiple items
[15:23] <kiko> I'm -1 on (x,) as well
[15:23] <kiko> I am +1 on (x, dummy)
[15:23] <kiko> that's what I mean.
[15:24] <kiko> no implicit tuples I think?
[15:24] <intellectronica> but if you return a 1-tuple?
[15:24] <flacoste> and why (x, dummy) over x, dummy?
[15:24] <kiko> anyway, just my 2c
[15:24] <flacoste> intellectronica: x = func()
[15:24] <kiko> flacoste, because it's easy to miss the comma.
[15:24] <kiko> as I said above? :)
[15:24] <flacoste> and use x as a tuple
[15:24] <flacoste> how would you miss the ocmma?
[15:24] <barry> btw, this pertains to record-type tuple unpacking, not list-type sequence unpacking.  i.e. if you really are interested in the 7th item in a 7-string list, use mystrings[7]
[15:24] <flacoste> you xdummy?
[15:24] <flacoste> you read xdummy?
[15:25] <kiko> flacoste, it is trickier when there's other punctuation or long words.
[15:25] <barry> kiko: i only find them hard to miss when they are trailing commas, but that's just me
[15:25] <kiko> but as I said, it was just a suggestion, I will keep on being explicit in code I write :)
[15:26] <intellectronica> ok, if 1-tuples are not relevant to the discussion, then i think (x, y) = is the best option
[15:26] <salgado> why aren't 1-tuples relevant?
[15:26] <sinzui> intellectronica: the pylint warning is an edge case. I have added disabled the warning. We could have a rule that identifiers ending in a trailing _ are to be ignored.
[15:27] <intellectronica> salgado: because they only happen when you return a sequence, not when you return a structure
[15:27] <sinzui> intellectronica: ignore that middle-would-be-sentence
[15:28] <barry> do we need a guideline here, or can we accept both "x, y =" and "(x, y) = "?
[15:28] <BjornT> intellectronica: tests do unpacking of sequences quite often, where the length of the sequence is well-known
[15:29] <barry> BjornT: in tests, i think [foo] = func() is fine
[15:29] <intellectronica> BjornT: sure, but they could still make an exception for 1-tuples
[15:29] <barry> though i still prefer foo = func()[0]
[15:30] <bigjools> [0] is a magic number though
[15:30] <BjornT> barry: i kind of agree with you. in tests i prefer [foo] = func(), but in real code i prefer foo = func()[0], together with an assert len(func()) == 1
[15:30] <sinzui> barry wont get that past me in a review
[15:31] <BjornT> if you use an assert, the 0 isn't very magical
[15:31] <barry> BjornT: +1
[15:31] <barry> BjornT: i definitely prefer the much more explicit length assertion
[15:31] <flacoste> verbose
[15:31] <barry> [foo] = func() seems passive agressive to me :)
[15:32] <flacoste> consise
[15:32] <flacoste> concise
[15:32] <bigjools> I must admit, I've got to prefer the short form for its conciseness
[15:33] <salgado> we seem to have only two occurrences of that in non-test code
[15:33] <salgado> database/queue.py:            [source] = self.sources
[15:33] <salgado> webapp/dynmenu.py:            [name] = self.names
[15:33] <intellectronica> anyway, [foo] is a slightly degenerate case that should only happen in tests, so we should decide on the multiple value, and allow for exceptions if we only have one value
[15:34] <salgado> and a third one
[15:34] <salgado> scripts/ftpmaster.py:        [action] = self.args
[15:34] <barry> intellectronica: agreed, okay, here's the vote:
[15:34] <barry> (a) foo, bar = func(); (b) (foo, bar) = func()
[15:34] <barry> what say ye: a or b
[15:35] <intellectronica> b
[15:35] <flacoste> a
[15:35] <barry> a
[15:35] <bigjools> b
[15:35] <salgado> a
[15:35] <BjornT> a
[15:35] <bac> a
[15:35] <sinzui> a
[15:35] <allenap> a
[15:35] <statik> a
[15:36] <barry> okay, unless the australian superdelegates steal the election, we'll go with (a)
[15:36] <intellectronica> bigjools: you see, you thoght convincing me would save you some work, but now you'll have to change it :)
[15:36] <bigjools> intellectronica: too late!
[15:36] <barry> anyway, that's all i have.  we have 9 minutes for anything not on the agenda.  anybody have anything else?
[15:37] <bigjools> I think it's inconsistent between one and many values now, but hey ho
[15:37] <mpt> barry, judging by the "baa baaaaa", it looks like they already have ;-)
[15:37] <sinzui> I propose that we end unused identifiers with an underscores (ot 2 underscores). It makes it a clearer which as really needed. I can add a pylint rule to never warn that they are unused.
[15:37]  * barry will update the style guide and send an email
[15:38] <barry> sinzui: ?
[15:38] <bigjools> for tests?
[15:38]  * sinzui asks fore better typing for his birthday
[15:38] <barry> sinzui: i don't understand the suggestion
[15:39] <salgado> (thing_i_want, thing_I_dont_want_) = foo() ?
[15:39] <sinzui> barry: I want a naming convention for variables that are unpacked and unused by the code.
[15:39] <sinzui> We can also tell pylint to ignore them.
[15:39] <barry> sinzui: oh, i use 'ignore'
[15:39] <bigjools> I quite often do dummy = func() in doctests when func produces unwanted output
[15:40] <barry> as in: ignore, ignore, supergoodness, ignore, ignore = func()
[15:40] <sinzui> barry: what is ignore? a port, a day?
[15:40] <salgado> I use dummy, but that doesn't tell me what data it's supposed to hold
[15:40] <barry> sinzui: who cares?
[15:40] <bigjools> if you're ignoring it who cares
[15:40] <sinzui> barry: I care!
[15:41] <sinzui> barry: I'm an idiot. I want to know what the ignored variable is. I may want to use it
[15:41] <barry> sinzui: then it's really not unused is it?
[15:41] <sinzui> barry: then I rename it
[15:42] <barry> sinzui: i don't see how you can have a naming convention for items you don't care about if you really want to know what they are :)
[15:42] <sinzui> barry: The code may not use them, but what they are is self-documentation
[15:43] <barry> sinzui: so then, what naming convention are you proposing?
[15:43] <sinzui> ending the dummy variables with an underscore (or 2 of them)
[15:44] <allenap> scheme_, netloc_, path, query, fragment_ = urlparse.urlsplit(...)
[15:44] <sinzui> barry: pylint will complain about unused variables. I have seen a number of meaningful names in an unpack statement changed to dummy.
[15:44] <barry> allenap: oh, i don't think i've seen that.  yeah, that's ugly
[15:45] <sinzui> allenap: right
[15:45] <barry> some of those will go away in python 2.5 anyway, y'know
[15:45] <sinzui> allenap: in py 2.5 you can use their names
[15:45] <barry> sinzui: exactly
[15:45] <barry> named tuples rule
[15:46] <allenap> Do you mean 2.6?
[15:46] <barry> anyway, we're out of time.  sinzui take it to the ml?
[15:46] <sinzui> ok
[15:46] <barry> allenap: nope, 2.5
[15:46] <allenap> Really, I didn't know. Cool :)
[15:46] <barry> thanks everyone, that's it.  have a good week!
[15:46] <barry> #endmeeting
[15:47]  * barry looks to the sky and yells: moooootbooootttttt!
[15:47] <intellectronica> thanks barry