Re: [Python-Dev] pep8 reasoning

2014-04-27 Thread Barry Warsaw
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".

[Python-Dev] Commit-ready patches needing review

2014-04-27 Thread Nikolaus Rath
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

Re: [Python-Dev] Commit-ready patches needing review

2014-04-27 Thread Antoine Pitrou
On Sun, 27 Apr 2014 12:10:46 -0700 Nikolaus Rath 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)

Re: [Python-Dev] pep8 reasoning

2014-04-27 Thread Chris Barker
On Sun, Apr 27, 2014 at 9:40 AM, 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/#indent

Re: [Python-Dev] Commit-ready patches needing review

2014-04-27 Thread Guido van Rossum
Agreed. On Sunday, April 27, 2014, Antoine Pitrou wrote: > On Sun, 27 Apr 2014 12:10:46 -0700 > Nikolaus Rath > 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) docu

Re: [Python-Dev] pep8 reasoning

2014-04-27 Thread Terry Reedy
On 4/27/2014 3:34 PM, Chris Barker wrote: On Sun, Apr 27, 2014 at 9:40 AM, Barry Warsaw 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,

Re: [Python-Dev] pep8 reasoning

2014-04-27 Thread Florent
2014-04-27 21:34 GMT+02:00 Chris Barker : > > 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_nam

Re: [Python-Dev] pep8 reasoning

2014-04-27 Thread Barry Warsaw
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_n

Re: [Python-Dev] pep8 reasoning

2014-04-27 Thread Janzert
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

Re: [Python-Dev] Commit-ready patches needing review

2014-04-27 Thread Nikolaus Rath
Antoine Pitrou writes: > On Sun, 27 Apr 2014 12:10:46 -0700 > Nikolaus Rath 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) depr

Re: [Python-Dev] pep8 reasoning

2014-04-27 Thread Steven D'Aprano
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 >> wrote: > > > >On Apr 26, 2014, at 12:33 AM, Janzert wrote: > > > > >So the one example under discussion is:

[Python-Dev] Clarification on MRO when inheriting from builtin type.

2014-04-27 Thread Paul Sokolovsky
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__"

Re: [Python-Dev] Clarification on MRO when inheriting from builtin type.

2014-04-27 Thread Chris Angelico
On Mon, Apr 28, 2014 at 12:59 PM, Paul Sokolovsky 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 abo

Re: [Python-Dev] Clarification on MRO when inheriting from builtin type.

2014-04-27 Thread Chris Angelico
On Mon, Apr 28, 2014 at 1:25 PM, Paul Sokolovsky 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, a

Re: [Python-Dev] Clarification on MRO when inheriting from builtin type.

2014-04-27 Thread Paul Sokolovsky
Hello, On Mon, 28 Apr 2014 13:13:53 +1000 Chris Angelico wrote: > On Mon, Apr 28, 2014 at 12:59 PM, Paul Sokolovsky > wrote: > > From the output, "User" class as expected does not override > > list.append(), but does override list.__str__(). Is this behavior > > documented somewhere (complete a