Re: [Python-Dev] pep8 reasoning

> 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

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

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

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

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

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

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

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

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

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

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

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 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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-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

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-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

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

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

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

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

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

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

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 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[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

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

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

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

> -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, particularly as it's the one thin

Re: [Python-Dev] pep8 reasoning

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

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

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

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

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

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

Re: [Python-Dev] pep8 reasoning

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

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

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

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

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

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