Re: [Python-Dev] pep8 reasoning

2014-04-28 Thread Stephen J. Turnbull
> On Mon, Apr 28, 2014 at 11:12 AM, Chris Barker wrote: > not really -- it allows it: > > # Aligned with opening delimiter. > foo = long_function_name(var_one, var_two, > var_three, var_four) > > but all the examples have more than one variable per line...my poi

Re: [Python-Dev] pep8 reasoning

2014-04-28 Thread Stephen J. Turnbull
R. David Murray writes: > My unix fix-width terminal font handles most unicode (even a lot of > non-bmp stuff...though I have no idea if it is readable :). Oh, I bet you do. With a true fixed-width Unicode font, it's the *Latin-character* text that's painful, if not unreadable, because the asp

Re: [Python-Dev] pep8 reasoning

2014-04-28 Thread Terry Reedy
On 4/28/2014 7:13 PM, Chris Barker wrote: On Mon, Apr 28, 2014 at 3:01 PM, Terry Reedy mailto:tjre...@udel.edu>> wrote: I don't think anyone should write code with variable width fonts, The problem is that fixed pitch does not work well for even a half-way complete unicode font

Re: [Python-Dev] pep8 reasoning

2014-04-28 Thread Chris Barker
On Mon, Apr 28, 2014 at 3:01 PM, Terry Reedy wrote: > I don't think anyone should write code with variable width fonts, >> > > The problem is that fixed pitch does not work well for even a half-way > complete unicode font and I don't know that there are any available. > ... > Given that PEP8 gen

Re: [Python-Dev] pep8 reasoning

2014-04-28 Thread R. David Murray
On Mon, 28 Apr 2014 18:01:32 -0400, Terry Reedy wrote: > On 4/28/2014 2:12 PM, Chris Barker wrote: > > > I don't think anyone should write code with variable width fonts, > > The problem is that fixed pitch does not work well for even a half-way > complete unicode font and I don't know that the

Re: [Python-Dev] pep8 reasoning

2014-04-28 Thread Terry Reedy
On 4/28/2014 2:12 PM, Chris Barker wrote: I don't think anyone should write code with variable width fonts, The problem is that fixed pitch does not work well for even a half-way complete unicode font and I don't know that there are any available. As far as I know, my Windows 7 only came wit

Re: [Python-Dev] pep8 reasoning

2014-04-28 Thread Barry Warsaw
On Apr 28, 2014, at 11:12 AM, Chris Barker wrote: >No -- stupid variable-width font! > >I don't think anyone should write code with variable width fonts, and I'd >rather not do email that way either, but gmail is making it tough these >days.. Ouch. I'm sure it's gmail being "helpful" the way

Re: [Python-Dev] pep8 reasoning

2014-04-28 Thread Chris Barker
On Sun, Apr 27, 2014 at 6:34 PM, Steven D'Aprano wrote: > > 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. > not really -- a lot of folks learn more from foll

Re: [Python-Dev] pep8 reasoning

2014-04-28 Thread Chris Barker
On Sun, Apr 27, 2014 at 1:40 PM, Barry Warsaw wrote: > On Apr 27, 2014, at 12:34 PM, Chris Barker wrote: > >foo = long_function_name(var_one, > > var_two, > > var_three, > >

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:

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] 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 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 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 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] 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".

Re: [Python-Dev] pep8 reasoning

2014-04-26 Thread Stephen J. Turnbull
Donald Stufft writes: > For instance there are things on PyPI named after websites, like > github, twitter, Facebook, etc. These things are not written by the > companies behind those websites and are merely written to interface > with those websites. Should we assume that those companies all

Re: [Python-Dev] pep8 reasoning

2014-04-26 Thread Steven D'Aprano
On Fri, Apr 25, 2014 at 08:42:02PM -0400, Donald Stufft wrote: > > On Apr 25, 2014, at 7:20 PM, Ethan Furman wrote: > > > On 04/25/2014 03:26 PM, Donald Stufft wrote: > >> > >> pep8.py doesn’t violate PEP8, it just takes a stricter view of it. > > > > If pep8 reports errors on things that PEP

Re: [Python-Dev] pep8 reasoning

2014-04-25 Thread Steven D'Aprano
On Fri, Apr 25, 2014 at 08:13:35PM -0400, Donald Stufft wrote: > I agree that I’ve never taken the name to mean that you’re claiming any > sort of endorsement. There are a *vast* number of projects that implement > something that was defined somewhere else and I don’t think any reasonable > person

Re: [Python-Dev] pep8 reasoning

2014-04-25 Thread Stephen J. Turnbull
Carl Meyer writes: > I'd like to thank Florent for taking the time to maintain an > extremely-useful tool that makes it feasible to keep to a > consistent PEP 8 style throughout a large codebase with many > contributors, I would too. N.B. Nick's complaints are a sort of left-handed complimen

Re: [Python-Dev] pep8 reasoning

2014-04-25 Thread Donald Stufft
On Apr 26, 2014, at 12:31 AM, Stephen J. Turnbull wrote: > Florent writes: > >> I wrote some words in the documentation, one year ago, to explain what >> is the purpose of the tool and its limitations. There's no claim of >> any endorsement implicit or explicit by the PSF, the PSU or any other

Re: [Python-Dev] pep8 reasoning

2014-04-25 Thread Janzert
On 4/25/2014 5:52 PM, Carl Meyer wrote: - we aren't talking about real variance from the spirit or recommendations of PEP 8 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/#i

Re: [Python-Dev] pep8 reasoning

2014-04-25 Thread Stephen J. Turnbull
Florent writes: > I wrote some words in the documentation, one year ago, to explain what > is the purpose of the tool and its limitations. There's no claim of > any endorsement implicit or explicit by the PSF, the PSU or any other > python developer :-) Of course there is an implicit claim of

Re: [Python-Dev] pep8 reasoning

2014-04-25 Thread Ethan Furman
On 04/25/2014 05:42 PM, Donald Stufft wrote: On Apr 25, 2014, at 7:20 PM, Ethan Furman wrote: On 04/25/2014 03:26 PM, Donald Stufft wrote: pep8.py doesn’t violate PEP8, it just takes a stricter view of it. If pep8 reports errors on things that PEP 8 says are okay, that's a violation. Being

Re: [Python-Dev] pep8 reasoning

2014-04-25 Thread Nick Coghlan
On 25 April 2014 21:29, Nick Coghlan wrote: > On 25 April 2014 19:56, Florent wrote: >> 2014-04-26 0:46 GMT+02:00 Nick Coghlan : >>> Florent is claiming the endorsement of the PEP 8 authors >>> and the consensus of python-dev for the tool's default behaviour >>> (as noted above, this makes it per

Re: [Python-Dev] pep8 reasoning

2014-04-25 Thread Nick Coghlan
On 25 April 2014 19:56, Florent wrote: > 2014-04-26 0:46 GMT+02:00 Nick Coghlan : >> Florent is claiming the endorsement of the PEP 8 authors >> and the consensus of python-dev for the tool's default behaviour >> (as noted above, this makes it personal for me, as I am a >> co-author of PEP 8). > >

Re: [Python-Dev] pep8 reasoning

2014-04-25 Thread Donald Stufft
On Apr 25, 2014, at 7:20 PM, Ethan Furman wrote: > On 04/25/2014 03:26 PM, Donald Stufft wrote: >> >> pep8.py doesn’t violate PEP8, it just takes a stricter view of it. > > If pep8 reports errors on things that PEP 8 says are okay, that's a violation. > > -- > ~Ethan~ > __

Re: [Python-Dev] pep8 reasoning

2014-04-25 Thread Florent
2014-04-26 1:46 GMT+02:00 Guido van Rossum : > I think the tool's name is unfortunate. The first time I heard about it I > was having an in-person discussion with a developer who (I thought) said > that "PEP 8" was okay with his code (which I knew couldn't be the case) but > in fact he meant to say

Re: [Python-Dev] pep8 reasoning

2014-04-25 Thread Donald Stufft
On Apr 25, 2014, at 7:56 PM, Florent wrote: > 2014-04-26 0:46 GMT+02:00 Nick Coghlan : >> Florent is claiming the endorsement of the PEP 8 authors >> and the consensus of python-dev for the tool's default behaviour >> (as noted above, this makes it personal for me, as I am a >> co-author of PEP

Re: [Python-Dev] pep8 reasoning

2014-04-25 Thread Florent
2014-04-26 0:46 GMT+02:00 Nick Coghlan : > Florent is claiming the endorsement of the PEP 8 authors > and the consensus of python-dev for the tool's default behaviour > (as noted above, this makes it personal for me, as I am a > co-author of PEP 8). You're a co-author of PEP 8 since less than a ye

Re: [Python-Dev] pep8 reasoning

2014-04-25 Thread Guido van Rossum
I think the tool's name is unfortunate. The first time I heard about it I was having an in-person discussion with a developer who (I thought) said that "PEP 8" was okay with his code (which I knew couldn't be the case) but in fact he meant to say that (some configuration of) "pep8" didn't mind it.

Re: [Python-Dev] pep8 reasoning

2014-04-25 Thread Ethan Furman
On 04/25/2014 03:26 PM, Donald Stufft wrote: pep8.py doesn’t violate PEP8, it just takes a stricter view of it. If pep8 reports errors on things that PEP 8 says are okay, that's a violation. -- ~Ethan~ ___ Python-Dev mailing list Python-Dev@python.o

Re: [Python-Dev] pep8 reasoning

2014-04-25 Thread Nick Coghlan
On 25 April 2014 18:26, Donald Stufft wrote: >> If python-dev wants to control the precise behavior of pep8.py, bring it >> into the standard library and adopt maintenance of it. Otherwise, please >> give Florent some grace. >> >> Carl > > Carl’s post mirrors my own thoughts and it’s said much bet

Re: [Python-Dev] pep8 reasoning

2014-04-25 Thread Nick Coghlan
On 25 April 2014 17:52, Carl Meyer wrote: > On 04/25/2014 01:55 PM, Ethan Furman wrote: >> On 04/25/2014 12:45 PM, Florent wrote: >>> 2014-04-25 18:10 GMT+02:00 Nick Coghlan: > I think this fuss is unreasonable and unwarranted. > > I'd like to thank Florent for taking the time to maintain an > ext

Re: [Python-Dev] pep8 reasoning

2014-04-25 Thread Donald Stufft
On Apr 25, 2014, at 5:52 PM, Carl Meyer wrote: > On 04/25/2014 01:55 PM, Ethan Furman wrote: >> On 04/25/2014 12:45 PM, Florent wrote: >>> 2014-04-25 18:10 GMT+02:00 Nick Coghlan: And if you're going to publish a tool to enforce your *personal* style guide and include your own cu

Re: [Python-Dev] pep8 reasoning

2014-04-25 Thread Carl Meyer
On 04/25/2014 01:55 PM, Ethan Furman wrote: > On 04/25/2014 12:45 PM, Florent wrote: >> 2014-04-25 18:10 GMT+02:00 Nick Coghlan: >>> >>> And if you're going to publish a tool to enforce your *personal* style >>> guide and include your own custom rules that the "this is OK" examples >>> in PEP 8 fai

Re: [Python-Dev] pep8 reasoning

2014-04-25 Thread Ethan Furman
On 04/25/2014 12:45 PM, Florent wrote: 2014-04-25 18:10 GMT+02:00 Nick Coghlan: And if you're going to publish a tool to enforce your *personal* style guide and include your own custom rules that the "this is OK" examples in PEP 8 fail to satisfy, don't call it "pep8". Two cases where signale

Re: [Python-Dev] pep8 reasoning

2014-04-25 Thread Florent
2014-04-25 18:10 GMT+02:00 Nick Coghlan : > > And if you're going to publish a tool to enforce your *personal* style > guide and include your own custom rules that the "this is OK" examples > in PEP 8 fail to satisfy, don't call it "pep8". Especially don't do > that if you're then going to ignore a

Re: [Python-Dev] pep8 reasoning

2014-04-25 Thread Nick Coghlan
On 25 April 2014 10:36, Barry Warsaw wrote: > On Apr 25, 2014, at 11:06 PM, Stephen J. Turnbull wrote: > >>And from *outside* of your organization, it's a no-brainer. PEP 8 is >>what Python itself and most 3rd party OSS modules use. Getting your >>people to use PEP 8 will make it a lot easier fo

Re: [Python-Dev] pep8 reasoning

2014-04-25 Thread Barry Warsaw
On Apr 25, 2014, at 11:06 PM, Stephen J. Turnbull wrote: >And from *outside* of your organization, it's a no-brainer. PEP 8 is >what Python itself and most 3rd party OSS modules use. Getting your >people to use PEP 8 will make it a lot easier for them to learn to >read Python core and stdlib cod

Re: [Python-Dev] pep8 reasoning

2014-04-25 Thread Stephen J. Turnbull
Chris Withers writes: > On 25/04/2014 04:03, Barry Warsaw wrote: > > I'd say it depends. If the code is going to be shared with > > people outside of your organization (e.g. open source libraries), > > then there's a strong motivation to be consistent throughout the > > community, which mean

Re: [Python-Dev] pep8 reasoning

2014-04-25 Thread Chris Angelico
On Fri, Apr 25, 2014 at 1:28 PM, Guido van Rossum wrote: > On Apr 24, 2014 7:01 PM, "Chris Angelico" wrote: >> >> On Fri, Apr 25, 2014 at 11:40 AM, Allen Li wrote: >> > 2) If you're starting a new project, follow PEP8 (or the standards for >> >the language you're using) to preserve CONSISTEN

Re: [Python-Dev] pep8 reasoning

2014-04-25 Thread Tim Golden
On 25/04/2014 13:09, Chris Withers wrote: > On 25/04/2014 04:03, Barry Warsaw wrote: >> On Apr 25, 2014, at 12:00 PM, Chris Angelico wrote: >> >>> Don't forget that PEP 8 is not the standard for the Python language, >>> only the Python stdlib. Particularly, there's no strong reason to >>> follow so

Re: [Python-Dev] pep8 reasoning

2014-04-25 Thread Chris Withers
On 25/04/2014 04:03, Barry Warsaw wrote: On Apr 25, 2014, at 12:00 PM, Chris Angelico wrote: Don't forget that PEP 8 is not the standard for the Python language, only the Python stdlib. Particularly, there's no strong reason to follow some of its lesser advices (eg spaces rather than tabs, the

Re: [Python-Dev] pep8 reasoning

2014-04-25 Thread Chris Withers
On 25/04/2014 03:00, Chris Angelico wrote: On Fri, Apr 25, 2014 at 11:40 AM, Allen Li wrote: 2) If you're starting a new project, follow PEP8 (or the standards for the language you're using) to preserve CONSISTENCY. Don't forget that PEP 8 is not the standard for the Python language, only

Re: [Python-Dev] pep8 reasoning

2014-04-24 Thread Steven D'Aprano
On Thu, Apr 24, 2014 at 01:57:38PM +0100, Tim Golden wrote: > On 24/04/2014 12:59, Tal Einat wrote: > > As far as I know that reason for these examples being frowned upon is > > that they are needlessly redundant. > > Oh, the irony! (Sorry, couldn't resist) Not really ironic, since not all redun

Re: [Python-Dev] pep8 reasoning

2014-04-24 Thread Guido van Rossum
On Apr 24, 2014 7:01 PM, "Chris Angelico" wrote: > > On Fri, Apr 25, 2014 at 11:40 AM, Allen Li wrote: > > 2) If you're starting a new project, follow PEP8 (or the standards for > >the language you're using) to preserve CONSISTENCY. > > Don't forget that PEP 8 is not the standard for the Pyth

Re: [Python-Dev] pep8 reasoning

2014-04-24 Thread Greg Ewing
Chris Angelico wrote: add_HTTP_header add_http_header addHTTPHeader addHttpHeader Five... there are FIVE options... convertXMLtoJSON i.e. don't capitalise a part that follows capitalised initials. -- Greg ___ Python-Dev mailing list Python-Dev@py

Re: [Python-Dev] pep8 reasoning

2014-04-24 Thread Barry Warsaw
On Apr 25, 2014, at 12:00 PM, Chris Angelico wrote: >Don't forget that PEP 8 is not the standard for the Python language, >only the Python stdlib. Particularly, there's no strong reason to >follow some of its lesser advices (eg spaces rather than tabs, the >exact maximum line length) for new proje

Re: [Python-Dev] pep8 reasoning

2014-04-24 Thread Chris Angelico
On Fri, Apr 25, 2014 at 11:40 AM, Allen Li wrote: > 2) If you're starting a new project, follow PEP8 (or the standards for >the language you're using) to preserve CONSISTENCY. Don't forget that PEP 8 is not the standard for the Python language, only the Python stdlib. Particularly, there's no

Re: [Python-Dev] pep8 reasoning

2014-04-24 Thread Allen Li
On Thu, Apr 24, 2014 at 11:36:03AM -0500, Tim Peters wrote: > There's been a bit of serious study on this. The results are still > open to interpretation, though ;-) Here's a nice summary: > > http://whathecode.wordpress.com/2011/02/10/camelcase-vs-underscores-scientific-showdown/ To summarize

Re: [Python-Dev] pep8 reasoning

2014-04-24 Thread Glenn Linderman
On 4/24/2014 11:01 AM, Daniel Holth wrote: Fortunately, Unicode provides us with the COMBINING LOW LINE character, combining the horizontal space-savings of camelCase with the underscore-indicates-separation properties of _. And it's a valid Python identifier. convertx̲mlt̲oj̲son That should b

Re: [Python-Dev] pep8 reasoning

2014-04-24 Thread Tim Peters
[Tim] >> There's been a bit of serious study on this. The results are still >> open to interpretation, though ;-) Here's a nice summary: >> >> >> http://whathecode.wordpress.com/2011/02/10/camelcase-vs-underscores-scientific-showdown/ [Terry Reedy] > The linked poll is almost evenly split, 52% t

Re: [Python-Dev] pep8 reasoning

2014-04-24 Thread Terry Reedy
On 4/24/2014 12:36 PM, Tim Peters wrote: There's been a bit of serious study on this. The results are still open to interpretation, though ;-) Here's a nice summary: http://whathecode.wordpress.com/2011/02/10/camelcase-vs-underscores-scientific-showdown/ The linked poll is almost evenly spli

Re: [Python-Dev] pep8 reasoning

2014-04-24 Thread Daniel Holth
Fortunately, Unicode provides us with the COMBINING LOW LINE character, combining the horizontal space-savings of camelCase with the underscore-indicates-separation properties of _. And it's a valid Python identifier. convertx̲mlt̲oj̲son On Thu, Apr 24, 2014 at 12:25 PM, Chris Angelico wrote:

Re: [Python-Dev] pep8 reasoning

2014-04-24 Thread Barry Warsaw
On Apr 24, 2014, at 06:51 PM, Tal Einat wrote: >I speak two languages as mother tongues - English and Hebrew. Hebrew >has no capital letters (and is also right-to-left) and is the spoken >and written language in the parts of Israel where I've lived most of >my life. Perhaps because of this, I do f

Re: [Python-Dev] pep8 reasoning

2014-04-24 Thread Kristján Valur Jónsson
> -Original Message- > From: Python-Dev [mailto:python-dev- > bounces+kristjan=ccpgames@python.org] On Behalf Of Chris Withers > Sent: 24. apríl 2014 07:18 > To: Python-Dev > Subject: [Python-Dev] pep8 reasoning > The biggest sticking point is naming, particu

Re: [Python-Dev] pep8 reasoning

2014-04-24 Thread Tim Peters
There's been a bit of serious study on this. The results are still open to interpretation, though ;-) Here's a nice summary: http://whathecode.wordpress.com/2011/02/10/camelcase-vs-underscores-scientific-showdown/ of-course-dashes-are-most-natural-ly y'rs - tim On Thu, Apr 24, 2014 at 11:25 A

Re: [Python-Dev] pep8 reasoning

2014-04-24 Thread Chris Angelico
On Thu, Apr 24, 2014 at 11:59 PM, Barry Warsaw wrote: > I will say this: the original preference for underscore_names in PEP 8 was > spurred by user studies some of our early non-native English speaking users > conducted many years ago. We learned that it was more difficult for many of > them to

Re: [Python-Dev] pep8 reasoning

2014-04-24 Thread Chris Barker - NOAA Federal
One added note: >> if greeting == True: >> if greeting is True: > > This one is based on the preference for identity checks when singletons are > involved, rather than equality tests. Being composed of English words, the > latter is also more readable. It's the same reason why you would do ident

Re: [Python-Dev] pep8 reasoning

2014-04-24 Thread Guido van Rossum
On Thu, Apr 24, 2014 at 7:11 AM, Skip Montanaro wrote: > On Thu, Apr 24, 2014 at 8:59 AM, Barry Warsaw wrote: > > I will say this: the original preference for underscore_names in PEP 8 > was > > spurred by user studies some of our early non-native English speaking > users > > conducted many year

Re: [Python-Dev] pep8 reasoning

2014-04-24 Thread Guido van Rossum
On Wed, Apr 23, 2014 at 11:48 PM, Chris Withers wrote: > Apologies if this is considered off topic, but I'm keen to get the > "language designers" point of view and short of emailing Barry, Guido and > Nick directly, this seemed like the best place. > > I'm having a tough time persuading some peo

Re: [Python-Dev] pep8 reasoning

2014-04-24 Thread Tal Einat
On Thu, Apr 24, 2014 at 4:59 PM, Barry Warsaw wrote: > I will say this: the original preference for underscore_names in PEP 8 was > spurred by user studies some of our early non-native English speaking users > conducted many years ago. We learned that it was more difficult for many of > them to p

[Python-Dev] pep8 reasoning

2014-04-24 Thread Chris Withers
Hi All, Apologies if this is considered off topic, but I'm keen to get the "language designers" point of view and short of emailing Barry, Guido and Nick directly, this seemed like the best place. I'm having a tough time persuading some people of the benefits of pep8, particularly when it co

Re: [Python-Dev] pep8 reasoning

2014-04-24 Thread Robert Kern
On 2014-04-24 14:59, Barry Warsaw wrote: I will say this: the original preference for underscore_names in PEP 8 was spurred by user studies some of our early non-native English speaking users conducted many years ago. We learned that it was more difficult for many of them to parse mixedCase nam

Re: [Python-Dev] pep8 reasoning

2014-04-24 Thread Skip Montanaro
On Thu, Apr 24, 2014 at 8:59 AM, Barry Warsaw wrote: > I will say this: the original preference for underscore_names in PEP 8 was > spurred by user studies some of our early non-native English speaking users > conducted many years ago. We learned that it was more difficult for many of > them to p

Re: [Python-Dev] pep8 reasoning

2014-04-24 Thread Barry Warsaw
On Apr 24, 2014, at 08:18 AM, Chris Withers wrote: >I'm having a tough time persuading some people of the benefits of pep8, >particularly when it comes to applying to an existing large code base. First of all, the purposes of PEP 8 is not to impose mandates of style on your colleagues. :) Two im

Re: [Python-Dev] pep8 reasoning

2014-04-24 Thread Tim Golden
On 24/04/2014 12:59, Tal Einat wrote: > As far as I know that reason for these examples being frowned upon is > that they are needlessly redundant. Oh, the irony! (Sorry, couldn't resist) TJG ___ Python-Dev mailing list Python-Dev@python.org https://ma

Re: [Python-Dev] pep8 reasoning

2014-04-24 Thread Tal Einat
On Thu, Apr 24, 2014 at 10:18 AM, Chris Withers wrote: > A couple of others that have raised some consternation; what are the > technical reasons for this pattern being bad: > > if len(seq) > if not len(seq) > > ...or, for me, the rather ugly: > > if 0 != len(seq) > > Likewise, these: > > if greet

Re: [Python-Dev] pep8 reasoning

2014-04-24 Thread Skip Montanaro
On Thu, Apr 24, 2014 at 2:18 AM, Chris Withers wrote: > What were the compelling reasons to go from mixedCase to > underscore_separated? What's considered the best approach for migrating from > the former to the latter? I never recall Python "going from" camelCase to separate_words. The descripti

[Python-Dev] pep8 reasoning

2014-04-24 Thread Chris Withers
Hi All, Apologies if this is considered off topic, but I'm keen to get the "language designers" point of view and short of emailing Barry, Guido and Nick directly, this seemed like the best place. I'm having a tough time persuading some people of the benefits of pep8, particularly when it co