Re: [Python-Dev] pep8 reasoning
On Apr 26, 2014, at 12:33 AM, Janzert wrote: So the one example under discussion is: foo = long_function_name( var_one, var_two, var_three, var_four) and comes from http://legacy.python.org/dev/peps/pep-0008/#indentation Specifically the third example with a heading of Optional. From my reading of the text, plus all the other examples around it, I would have assumed the 2 space indent was simply a typo and should have indeed been 4 spaces. If this is really meant to show that indents other than 4 spaces are allowed in this situation maybe verbiage to that effect could be added. No, I think it's a typo and should be 4 spaces. I'll fix that. -Barry ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Commit-ready patches needing review
Hello, While my last appeal resulted in quite some commits (thanks!), I still have some more commit-ready patches waiting for review. It'd be great if some people could find time to take a look: * http://bugs.python.org/issue1738 (filecmp.dircmp does exact match only) * http://bugs.python.org/issue20951 (SSLSocket.send() returns 0 for non-blocking socket) In this case someone just needs to decide if we want to (a) document the current behavior, (b) deprecate the current behavior or (c) change the current behavior. I have attached patches for (a) and (b), and if (c) is the desired route I'll be happy to create a patch on short notice. * http://bugs.python.org/issue20177 (Derby #8: Convert 28 sites to Argument Clinic across 2 files) * http://bugs.python.org/issue19414 (iter(ordered_dict) yields keys not in dict in some circumstances) * http://bugs.python.org/issue15955 (gzip, bz2, lzma: add option to limit output size) Nadeem has kindly reviewed the first iteration of this patch, but the second iteration has been waiting for attention for quite some time now. * http://bugs.python.org/issue20578 (BufferedIOBase.readinto1 is missing) * http://bugs.python.org/issue21057 (TextIOWrapper does not support reading bytearrays or memoryviews) Best, Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Commit-ready patches needing review
On Sun, 27 Apr 2014 12:10:46 -0700 Nikolaus Rath nikol...@rath.org wrote: * http://bugs.python.org/issue20951 (SSLSocket.send() returns 0 for non-blocking socket) In this case someone just needs to decide if we want to (a) document the current behavior, (b) deprecate the current behavior or (c) change the current behavior. I have attached patches for (a) and (b), and if (c) is the desired route I'll be happy to create a patch on short notice. In this case I'd be inclined to follow Ben Darnell's advice and change the current behaviour (i.e., let the exception bubble up rather than catch it). This is what your initial patch does. However, it would need a documentation addition to explain the change (and perhaps a test, though that doesn't seem terribly necessary here). Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pep8 reasoning
On Sun, Apr 27, 2014 at 9:40 AM, Barry Warsaw ba...@python.org wrote: On Apr 26, 2014, at 12:33 AM, Janzert wrote: So the one example under discussion is: foo = long_function_name( var_one, var_two, var_three, var_four) and comes from http://legacy.python.org/dev/peps/pep-0008/#indentation wow! just looked at that part of the PEP again, and that is a LOT of options. Is it impossible to come to any consensus on this? And as it happens, my favorite is not in there, though as far as I can tell not forbidden: foo = long_function_name(var_one, var_two, var_three, var_four) That is, I find that if the argument list is too long for one line, then splitting it out to only one argument per line is much more readable to me. This becomes more important with default parameters: foo = long_function_name(var_one, var_two=a_value, var_three=some_other_value, var_four=(a, tuple, of, values) ) as with more information in each argument, it's a lot more clear where one starts and the other begins. And it provides a nice place for comments: foo = long_function_name(var_one, var_two=a_value, # because default doesn't frobnicate in this case var_three=some_other_value, var_four=(a, tuple, of, values) ) Anyway -- is there a point in trying to standardize this a bit more in PEP8, or has that battle long since been fought and conceded ? -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/ORR(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Commit-ready patches needing review
Agreed. On Sunday, April 27, 2014, Antoine Pitrou solip...@pitrou.net wrote: On Sun, 27 Apr 2014 12:10:46 -0700 Nikolaus Rath nikol...@rath.org javascript:; wrote: * http://bugs.python.org/issue20951 (SSLSocket.send() returns 0 for non-blocking socket) In this case someone just needs to decide if we want to (a) document the current behavior, (b) deprecate the current behavior or (c) change the current behavior. I have attached patches for (a) and (b), and if (c) is the desired route I'll be happy to create a patch on short notice. In this case I'd be inclined to follow Ben Darnell's advice and change the current behaviour (i.e., let the exception bubble up rather than catch it). This is what your initial patch does. However, it would need a documentation addition to explain the change (and perhaps a test, though that doesn't seem terribly necessary here). Regards Antoine. -- --Guido van Rossum (on iPad) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pep8 reasoning
On 4/27/2014 3:34 PM, Chris Barker wrote: On Sun, Apr 27, 2014 at 9:40 AM, Barry Warsaw ba...@python.org mailto:ba...@python.org wrote: On Apr 26, 2014, at 12:33 AM, Janzert wrote: So the one example under discussion is: foo = long_function_name( var_one, var_two, var_three, var_four) and comes from http://legacy.python.org/dev/peps/pep-0008/#indentation wow! just looked at that part of the PEP again, and that is a LOT of options. Is it impossible to come to any consensus on this? And as it happens, my favorite is not in there, though as far as I can tell not forbidden: One arg per line is definitely permitted either when lining up with the first arg on the first line or with hanging indents. foo = long_function_name(var_one, var_two, var_three, var_four) In a fixed-pitch font, you have too many spaces for lines after the first. One advantage of hanging indent is that all arg lines have the same indent and thus the args line up regardless of the font. Hanging indents also give more space for default or named args and comments. I would agree with having at least one example done with one arg per line. -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pep8 reasoning
2014-04-27 21:34 GMT+02:00 Chris Barker chris.bar...@noaa.gov: wow! just looked at that part of the PEP again, and that is a LOT of options. Is it impossible to come to any consensus on this? And as it happens, my favorite is not in there, though as far as I can tell not forbidden: foo = long_function_name(var_one, var_two, var_three, var_four) Anyway -- is there a point in trying to standardize this a bit more in PEP8, or has that battle long since been fought and conceded ? FWIW, the tool pep8 has introduced continuation line indentation checks in 2012, based on the PEP 8 recommendations which were active at this date, and doing few extrapolations on cases which were not directly covered by the document (pep8.py v1.2, issue #64). Then we had a lot of iterations with the users of the library, and we've added more flexibility to cover the various styles which were in the spirit of PEP 8, and which give some added value for code readability. The end result of this work can be seen in the test suite : * more than 300 lines of rejected indentations: https://github.com/jcrocholl/pep8/blob/master/testsuite/E12.py * and more than 600 lines of acceptable cases: https://github.com/jcrocholl/pep8/blob/master/testsuite/E12not.py I don't think that the PEP 8 document should go in so much details, though. However these examples might help to have pragmatic discussions about which rules we want to recommend. Do not hesitate to give feedback here, or on the issue tracker. There's also a code-quality mailing-list which covers a little more than pep8.py: https://mail.python.org/mailman/listinfo/code-quality -- Florent ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pep8 reasoning
On Apr 27, 2014, at 12:34 PM, Chris Barker wrote: wow! just looked at that part of the PEP again, and that is a LOT of options. Is it impossible to come to any consensus on this? And as it happens, my favorite is not in there, though as far as I can tell not forbidden: foo = long_function_name(var_one, var_two, var_three, var_four) Wow, do you really indent those 42 columns? This actually is forbidden because you're not using vertical alignment when there is an argument on the first line. You would have to line up `var_two` right under `var_one` to be compliant. That is, I find that if the argument list is too long for one line, then splitting it out to only one argument per line is much more readable to me. Sure. The PEP outlines ways to do that. This becomes more important with default parameters: foo = long_function_name(var_one, var_two=a_value, var_three=some_other_value, var_four=(a, tuple, of, values) ) as with more information in each argument, it's a lot more clear where one starts and the other begins. And it provides a nice place for comments: foo = long_function_name(var_one, var_two=a_value, # because default doesn't frobnicate in this case var_three=some_other_value, var_four=(a, tuple, of, values) ) Anyway -- is there a point in trying to standardize this a bit more in PEP8, or has that battle long since been fought and conceded ? The only thing I see wrong (from a PEP 8 standpoint) with your example, is that your arguments are indented too far to the right. But e.g. this would be fine: foo = long_function_name(var_one, var_two=a_value, var_three=some_other_value, var_four=(a, tuple, of, values) ) Cheers, -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pep8 reasoning
On 4/27/2014 12:40 PM, Barry Warsaw wrote: On Apr 26, 2014, at 12:33 AM, Janzert wrote: So the one example under discussion is: foo = long_function_name( var_one, var_two, var_three, var_four) and comes from http://legacy.python.org/dev/peps/pep-0008/#indentation Specifically the third example with a heading of Optional. From my reading of the text, plus all the other examples around it, I would have assumed the 2 space indent was simply a typo and should have indeed been 4 spaces. If this is really meant to show that indents other than 4 spaces are allowed in this situation maybe verbiage to that effect could be added. No, I think it's a typo and should be 4 spaces. I'll fix that. -Barry Given the commits to pep 8 after this, I take it you decided the example really is correct. I'm glad the clarifying sentence got added and comment in the example changed, that should make it clear that the 2 space indent isn't a typo. Janzert ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Commit-ready patches needing review
Antoine Pitrou solip...@pitrou.net writes: On Sun, 27 Apr 2014 12:10:46 -0700 Nikolaus Rath nikol...@rath.org wrote: * http://bugs.python.org/issue20951 (SSLSocket.send() returns 0 for non-blocking socket) In this case someone just needs to decide if we want to (a) document the current behavior, (b) deprecate the current behavior or (c) change the current behavior. I have attached patches for (a) and (b), and if (c) is the desired route I'll be happy to create a patch on short notice. In this case I'd be inclined to follow Ben Darnell's advice and change the current behaviour (i.e., let the exception bubble up rather than catch it). This is what your initial patch does. However, it would need a documentation addition to explain the change (and perhaps a test, though that doesn't seem terribly necessary here). Sounds good to me. I just attached an updated patch to the issue. Thanks for looking at this! Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pep8 reasoning
On Sun, Apr 27, 2014 at 04:28:20PM -0400, Terry Reedy wrote: On 4/27/2014 3:34 PM, Chris Barker wrote: On Sun, Apr 27, 2014 at 9:40 AM, Barry Warsaw ba...@python.org mailto:ba...@python.org wrote: On Apr 26, 2014, at 12:33 AM, Janzert wrote: So the one example under discussion is: foo = long_function_name( var_one, var_two, var_three, var_four) and comes from http://legacy.python.org/dev/peps/pep-0008/#indentation wow! just looked at that part of the PEP again, and that is a LOT of options. Is it impossible to come to any consensus on this? And as it happens, my favorite is not in there, though as far as I can tell not forbidden: One arg per line is definitely permitted either when lining up with the first arg on the first line or with hanging indents. [...] I would agree with having at least one example done with one arg per line. Is it really necessary? I think that one-arg-per-line is an obvious variation of the existing example. If the only example given was one-arg-per-line, then the reader might wrongly assume that *only* one arg was allowed. But since the example shows more than one arg per line (two in the above example), I expect that people will read it as some arbitrary number rather than exactly two. So I don't think there's any need to show yet another example, especially since it's just a variation on the existing examples. -- Steven ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Clarification on MRO when inheriting from builtin type.
Hello, I used http://python-history.blogspot.com/2010/06/method-resolution-order.html and https://www.python.org/download/releases/2.3/mro/ as the reference, but it doesn't explain MRO in the following example (python3.4): class User: def __str__(self): return User.__str__ def append(self, a): print(User, a) class C(list, User): pass t = C([1, 2, 3]) print(t) t.append(10) print(t) print(t[-1]) The output is: = User.__str__ User.__str__ 10 = From the output, User class as expected does not override list.append(), but does override list.__str__(). Is this behavior documented somewhere (complete arrangement)? What's the rationale behind it? I need this info to implement MRO in an alternative Python implementation (MicroPython). Thanks, Paul mailto:pmis...@gmail.com ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Clarification on MRO when inheriting from builtin type.
On Mon, Apr 28, 2014 at 12:59 PM, Paul Sokolovsky pmis...@gmail.com wrote: From the output, User class as expected does not override list.append(), but does override list.__str__(). Is this behavior documented somewhere (complete arrangement)? What's the rationale behind it? In Python 3.4 (don't know about other versions), list.__str__ doesn't exist; when you call str([1,2,3]) it calls object.__str__. The MRO for C is (C, list, User, object) so anything from list (eg append) takes precedence over anything from User, but anything list doesn't have will fall through to User before catching object. ChrisA ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Clarification on MRO when inheriting from builtin type.
On Mon, Apr 28, 2014 at 1:25 PM, Paul Sokolovsky pmis...@gmail.com wrote: Thanks for quick response! I see that list.__repr__ exists, and test using it works as expected. Hopefully, such stuff can be treated as implementation-specific details... The language defines method lookups and the MRO and such, and then the class chooses what to define. If your classes aren't specifically designed with inheritance in mind, multiple inheritance will always get messy (no matter what language you're in!); even single inheritance can get messy very quickly if the classes aren't designed to coexist (there's no safe way to refactor a superclass method without knowing what subclasses might be overriding). ChrisA ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Clarification on MRO when inheriting from builtin type.
Hello, On Mon, 28 Apr 2014 13:13:53 +1000 Chris Angelico ros...@gmail.com wrote: On Mon, Apr 28, 2014 at 12:59 PM, Paul Sokolovsky pmis...@gmail.com wrote: From the output, User class as expected does not override list.append(), but does override list.__str__(). Is this behavior documented somewhere (complete arrangement)? What's the rationale behind it? In Python 3.4 (don't know about other versions), list.__str__ doesn't exist; when you call str([1,2,3]) it calls object.__str__. The MRO for C is (C, list, User, object) so anything from list (eg append) takes precedence over anything from User, but anything list doesn't have will fall through to User before catching object. Thanks for quick response! I see that list.__repr__ exists, and test using it works as expected. Hopefully, such stuff can be treated as implementation-specific details... ChrisA -- Best regards, Paul mailto:pmis...@gmail.com ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
