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