| * ToyKeeper wonders how to get relatively small feature requests pushed through the launchpad development process | 05:59 | |
| 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 |
| ubottu | 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 |
| ToyKeeper | Oops, this is -meeting. Xchat cuts off the tab titles. :0 | 06:01 |
| mrevell | g | 09:17 |
| === 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 | ||
| barry | hello everyone and welcome to this week's ameu reviewers meeting. who's here today? | 15:01 |
| === bigjools_ is now known as bigjools | ||
| sinzui | me | 15:01 |
| bigjools | me | 15:01 |
| schwuk | me | 15:01 |
| bac | me | 15:01 |
| allenap | me | 15:01 |
| intellectronica | me | 15:01 |
| 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:02 |
| 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:03 |
| barry | everyone good for next week, same time & place | 15:04 |
| barry | we'll take that as "yes" :) | 15:04 |
| barry | * Action items | 15:04 |
| 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:05 |
| 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:06 |
| barry | BjornT: ^^ | 15:07 |
| BjornT | that's done | 15:07 |
| barry | BjornT: excellent, thanks! | 15:07 |
| barry | * Queue status | 15:07 |
| 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:08 |
| 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:09 |
| bigjools | just saving wasted effort ... | 15:10 |
| barry | any other queue related comments? | 15:10 |
| barry | * Mentoring update | 15:11 |
| barry | if you have graduations or suggestions for recruits, send 'em to me | 15:11 |
| 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:12 |
| 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:13 |
| 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:14 |
| 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:15 |
| 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:16 |
| * 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:17 |
| * 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:18 |
| 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:19 |
| 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:20 |
| 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:21 |
| 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:22 |
| 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:23 |
| 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:24 |
| 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:25 |
| 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:26 |
| 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:27 |
| 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:28 |
| 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:29 |
| 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:30 |
| 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:31 |
| flacoste | consise | 15:32 |
| flacoste | concise | 15:32 |
| bigjools | I must admit, I've got to prefer the short form for its conciseness | 15:32 |
| 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:33 |
| 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:34 |
| 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:35 |
| 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:36 |
| 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:37 | |
| 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:38 |
| 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:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| === cprov-lunch is now known as cprov | ||
| 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:43 |
| === mrevell_ is now known as mrevell | ||
| 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:44 |
| 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:45 |
| 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:46 |
| * barry looks to the sky and yells: moooootbooootttttt! | 15:47 | |
| intellectronica | thanks barry | 15:47 |
| === 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 | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!