On Sun, Apr 27, 2014 at 1:40 PM, Barry Warsaw ba...@python.org wrote:
On Apr 27, 2014, at 12:34 PM, Chris Barker wrote:
foo = long_function_name(var_one,
var_two,
var_three,
On Sun, Apr 27, 2014 at 6:34 PM, Steven D'Aprano st...@pearwood.infowrote:
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
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
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
On Mon, 28 Apr 2014 18:01:32 -0400, Terry Reedy tjre...@udel.edu 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
On Mon, Apr 28, 2014 at 3:01 PM, Terry Reedy 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 and I don't know that there are any available.
...
Given that
On 4/28/2014 7:13 PM, Chris Barker wrote:
On Mon, Apr 28, 2014 at 3:01 PM, Terry Reedy tjre...@udel.edu
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
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
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 point is
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
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
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,
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 =
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 =
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
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
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
On Fri, Apr 25, 2014 at 08:42:02PM -0400, Donald Stufft wrote:
On Apr 25, 2014, at 7:20 PM, Ethan Furman et...@stoneleaf.us 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
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
On 25/04/2014 03:00, Chris Angelico wrote:
On Fri, Apr 25, 2014 at 11:40 AM, Allen Li cyberdup...@gmail.com 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
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
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 some of its
On Fri, Apr 25, 2014 at 1:28 PM, Guido van Rossum gu...@python.org wrote:
On Apr 24, 2014 7:01 PM, Chris Angelico ros...@gmail.com wrote:
On Fri, Apr 25, 2014 at 11:40 AM, Allen Li cyberdup...@gmail.com wrote:
2) If you're starting a new project, follow PEP8 (or the standards for
the
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 means PEP 8.
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 code,
On 25 April 2014 10:36, Barry Warsaw ba...@python.org 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
2014-04-25 18:10 GMT+02:00 Nick Coghlan ncogh...@gmail.com:
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
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 signaled
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 fail to satisfy,
On Apr 25, 2014, at 5:52 PM, Carl Meyer c...@oddbird.net 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
On 25 April 2014 17:52, Carl Meyer c...@oddbird.net 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
On 25 April 2014 18:26, Donald Stufft don...@stufft.io 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
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
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.
2014-04-26 0:46 GMT+02:00 Nick Coghlan ncogh...@gmail.com:
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
On Apr 25, 2014, at 7:56 PM, Florent florent.xicl...@gmail.com wrote:
2014-04-26 0:46 GMT+02:00 Nick Coghlan ncogh...@gmail.com:
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
2014-04-26 1:46 GMT+02:00 Guido van Rossum gu...@python.org:
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
On Apr 25, 2014, at 7:20 PM, Ethan Furman et...@stoneleaf.us 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~
On 25 April 2014 19:56, Florent florent.xicl...@gmail.com wrote:
2014-04-26 0:46 GMT+02:00 Nick Coghlan ncogh...@gmail.com:
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,
On 25 April 2014 21:29, Nick Coghlan ncogh...@gmail.com wrote:
On 25 April 2014 19:56, Florent florent.xicl...@gmail.com wrote:
2014-04-26 0:46 GMT+02:00 Nick Coghlan ncogh...@gmail.com:
Florent is claiming the endorsement of the PEP 8 authors
and the consensus of python-dev for the tool's
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.
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
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
On Apr 26, 2014, at 12:31 AM, Stephen J. Turnbull step...@xemacs.org 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
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 compliment,
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
On Thu, Apr 24, 2014 at 2:18 AM, Chris Withers ch...@simplistix.co.uk 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
On Thu, Apr 24, 2014 at 10:18 AM, Chris Withers ch...@simplistix.co.uk 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:
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
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
On Thu, Apr 24, 2014 at 8:59 AM, Barry Warsaw ba...@python.org 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
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
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
On Thu, Apr 24, 2014 at 4:59 PM, Barry Warsaw ba...@python.org 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
On Wed, Apr 23, 2014 at 11:48 PM, Chris Withers ch...@withers.org 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
On Thu, Apr 24, 2014 at 7:11 AM, Skip Montanaro s...@pobox.com wrote:
On Thu, Apr 24, 2014 at 8:59 AM, Barry Warsaw ba...@python.org 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
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 identity
On Thu, Apr 24, 2014 at 11:59 PM, Barry Warsaw ba...@python.org 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
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
-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 thing
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 find
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
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
[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% to 48% for
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
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 the
On Fri, Apr 25, 2014 at 11:40 AM, Allen Li cyberdup...@gmail.com 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.
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
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
On Apr 24, 2014 7:01 PM, Chris Angelico ros...@gmail.com wrote:
On Fri, Apr 25, 2014 at 11:40 AM, Allen Li cyberdup...@gmail.com 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
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 redundancy
71 matches
Mail list logo
