Hi,
I hope new stuff will follow only one naming style. And now we should
(or one person :-) should) decide which one.
I guess my point boils down to, we already did decide 4 years ago.
Let's stick with what we've got.
Ok, then let's stick with lower_case and check this if new libraries
Hi,
Too late. I don't think the diversity is all that distracting.
I disagree. One of the things that Java got very much right was to
specify, from the very beginning, what the preferred conventions are
for naming conventions. (Packages in lowercase, Classes in CapWords,
methods and
Guido van Rossum wrote:
You *might* want
to separate classes with two blank lines if the methods within them
are separated by single blank lines, but even there it's probably
overkill.
Lately I've taken to putting a separator like this
between consecutive class definitions of any substantial
Lately I've taken to putting a separator like this
between consecutive class definitions of any substantial
size:
#---
I find it helps a lot when I'm skimming through looking
for the beginnings of classes.
An editor/IDE with folding
On Wed, 2005-12-14 at 17:04 -0800, Guido van Rossum wrote:
One question: you made the suggestion that a blank line separate the
last line in a tqs docstring from its closing tqs. I'm wondering why
that is. Note that python-mode now (or shall we say with the fix I just
made ;) properly
Ian Bicking wrote:
Guido van Rossum wrote:
On 12/14/05, Barry Warsaw [EMAIL PROTECTED] wrote:
On Thu, 2005-12-15 at 11:13 +1100, Dave Cole wrote:
The only thing I strongly disagree with is the promotion of javaNaming
to equal footing with python_naming.
Actually, they're not on equal
On Wed, 2005-12-14 at 20:09 -0600, Ian Bicking wrote:
I think it's reasonable to loosen the
phrasing a bit -- it's nearly always better to stay consistent with a
package than follow PEP 8 on this point.
I agree, but actually I think there's a wider point to be made. The
worst of all
On Wed, 2005-12-14 at 20:22 -0600, Ian Bicking wrote:
I think the reference to Emacs here is unneeded. Use 4 spaces per
indentation level is sufficient instruction on its own.
Agreed. I've removed all references to Emacs in the PEP.
I think the reference to PEP 263 tests is kind of
On Wed, 2005-12-14 at 18:42 -0800, Guido van Rossum wrote:
Deprecated functions could be listed, too.
I think that's more proper for a separate PEP -- the style guide
shouldn't have to be updated each time something else is deprecated.
+1 to that, although I won't write that PEP. If
On Wed, 2005-12-14 at 20:41 -0800, Guido van Rossum wrote:
On 12/14/05, Barry Warsaw [EMAIL PROTECTED] wrote:
On Thu, 2005-12-15 at 11:13 +1100, Dave Cole wrote:
The only thing I strongly disagree with is the promotion of javaNaming
to equal footing with python_naming.
Actually,
[Guido van Rossum]
In a module where you import 'foo' I don't understand why you would
name a local variable 'foo'. So I'm not sure how the conflict would
arise.
It goes the other way around. First suppose, following an example in
a previous message, that I have a lot of variables named
On Thu, Dec 15, 2005, Barry Warsaw wrote:
PEP 8 though is primarily about establishing guidelines for the standard
library. The underline_words recommendation has been in place for 4+
years now, and modules that have been written in that time frame have
been written against to those rules.
Hi,
Barry Warsaw wrote:
That's fine. As always, projects (especially big framework-y ones like
Zope and Chandler) are free to adopt whatever they want. Their internal
consistency is more important anyway than adherence to PEP 8.
PEP 8 though is primarily about establishing guidelines for
François Pinard wrote:
[Guido van Rossum]
In a module where you import 'foo' I don't understand why you would
name a local variable 'foo'. So I'm not sure how the conflict would
arise.
It goes the other way around. First suppose, following an example in
a previous message, that I have
Reinhold Birkenfeld [EMAIL PROTECTED] wrote:
Ian Bicking wrote:
Guido van Rossum wrote:
It doesn't matter. Many large projects are adopting the camelCase
convention, either by choice or by accident. I did a brief review of
Zope 3 and Chandler, and while neither is consistent, camelCase
Hi,
Too late. I don't think the diversity is all that distracting.
I disagree. One of the things that Java got very much right was to
specify, from the very beginning, what the preferred conventions are
for naming conventions. (Packages in lowercase, Classes in CapWords,
methods and
On Thu, 2005-12-15 at 11:35 -0800, Josiah Carlson wrote:
In regards to naming conventions, I find that CapWords are easier for me
to read and remember as a native speaker of english. I've heard
statements from non-native english speakers that CapWords are hard to
read and/or understand, but
Hello,
PEP 8 for function and method names:
-
Function Names
Function names should be lowercase, possibly with words separated by
underscores to improve readability. mixedCase is allowed only in
contexts where that's already the prevailing style (e.g. threading.py),
[Wolfgang]
Or should we switch to camelCase with lowercase first letter ?
As most other Languages prefer this (Java, C#, C++, ...)
They also use curly braces instead of indentation to indicate block
structure. Maybe we should switch to that too. wink
--
Michael Hoffman [EMAIL PROTECTED]
Hi,
Michael Hoffman wrote:
[Wolfgang]
Or should we switch to camelCase with lowercase first letter ?
As most other Languages prefer this (Java, C#, C++, ...)
They also use curly braces instead of indentation to indicate block
structure. Maybe we should switch to that too. wink
Or BEGIN,
Wolfgang writes:
We need a clear style for function and method names
now std lib uses foo_bar sometimes foobar
and sometimes fooBar.
Personally, I prefer fooBar. But I try not to use it in python
code... I try to always use foo_bar because that's what PEP 8 says.
I believe recall the
Guido writes:
Actually this (function, method and ivar names) is such a contentious
issue that I think the style guide should explicitly allow all
two/three styles and recommend to be consistent within a class, module
or package.
Hurray! Now I can go back to using capWords for functions,
On Tue, 2005-12-13 at 07:26 -0500, Jim Fulton wrote:
I'd add somewhere: If in doubt, chose non-public. You can always change your
mind later.
Added.
We don't use the term private here, since no attribute is really
private in Python (without a generally unnecessary amount of
On Tue, 2005-12-13 at 12:00 -0500, Phillip J. Eby wrote:
In any case, the algorithms involved are near-trivial; the most complex
piece is the processing of complex version specifications like
CherryPy=2.1.0,!=2.1.1-rc2,2.2a into a series of version intervals.
The only outstanding feature
On Wed, 2005-12-14 at 09:08 -0800, Michael Chermside wrote:
Wolfgang writes:
We need a clear style for function and method names
now std lib uses foo_bar sometimes foobar
and sometimes fooBar.
Personally, I prefer fooBar. But I try not to use it in python
code... I try to always use
On Wed, 2005-12-14 at 10:17 -0800, Guido van Rossum wrote:
Actually this (function, method and ivar names) is such a contentious
issue that I think the style guide should explicitly allow all
two/three styles and recommend to be consistent within a class, module
or package.
My own feeling is
I've pushed out a revised PEP 8
http://www.python.org/peps/pep-0008.html
Please review and comment. Thanks everyone for providing an excellent
discussion. Hopefully I have captured our current collective
recommendations. I've also tried to simplify the text, while making it
(somewhat) more
On 12/14/05, Michael Chermside [EMAIL PROTECTED] wrote:
Guido writes:
Actually this (function, method and ivar names) is such a contentious
issue that I think the style guide should explicitly allow all
two/three styles and recommend to be consistent within a class, module
or package.
I've pushed out a revised PEP 8
http://www.python.org/peps/pep-0008.html
Please review and comment.
Why does PEP 8 continually refer to one particular editor (Emacs)?
(There are even parts in the form x is better because it works
better in Emacs, when surely it's actually the case that
On 12/14/05, Barry Warsaw [EMAIL PROTECTED] wrote:
I've pushed out a revised PEP 8
http://www.python.org/peps/pep-0008.html
Please review and comment. Thanks everyone for providing an excellent
discussion. Hopefully I have captured our current collective
recommendations. I've also tried
On Wed, 2005-12-14 at 14:10 -0800, Guido van Rossum wrote:
Thanks, Barry! I've made another pass and added a couple more tweaks,
hopefully non-controversial.
Cool thanks Guido. I fixed a couple of small typos.
One question: you made the suggestion that a blank line separate the
last line in
On Wed, 2005-12-14 at 14:14 -0800, Guido van Rossum wrote:
Historically many Python developers use Emacs. Barry I still do.
I think the best way to avoid editor wars is to pick one editor and
stick with it. :-)
Dinosaurs rule! :)
-Barry
signature.asc
Description: This is a digitally
Barry Warsaw wrote:
I've pushed out a revised PEP 8
http://www.python.org/peps/pep-0008.html
Please review and comment. Thanks everyone for providing an excellent
discussion. Hopefully I have captured our current collective
recommendations. I've also tried to simplify the text, while
On 12/14/05, Barry Warsaw [EMAIL PROTECTED] wrote:
On Wed, 2005-12-14 at 14:10 -0800, Guido van Rossum wrote:
Thanks, Barry! I've made another pass and added a couple more tweaks,
hopefully non-controversial.
Cool thanks Guido. I fixed a couple of small typos.
One question: you made the
Dave Cole wrote:
Barry Warsaw wrote:
I've pushed out a revised PEP 8
http://www.python.org/peps/pep-0008.html
Please review and comment. Thanks everyone for providing an excellent
discussion. Hopefully I have captured our current collective
recommendations. I've also tried to simplify the
[Barry Warsaw]
I've pushed out a revised PEP 8
http://www.python.org/peps/pep-0008.html
Please review and comment.
Hi, Barry, and people. Allow me a few remarks, nothing essential.
* Within Naming Conventions, Prescriptive: Naming Conventions,
Module names, we read:
Modules should have
Barry Warsaw wrote:
I've pushed out a revised PEP 8
http://www.python.org/peps/pep-0008.html
Just two little things...
Use 4 spaces per indentation level.
This is the default for Emacs's python-mode. For really old code
that you
don't want to mess up, you can continue to
On 12/14/05, François Pinard [EMAIL PROTECTED] wrote:
I would like that PEP 0008 add some cement around this idea that common
English words, properly spelled, which are likely to be user variable
names, be avoided whenever reasonable.
I don't think that's a reasonable rule. There are too many
[Barry]
I've pushed out a revised PEP 8
http://www.python.org/peps/pep-0008.html
Please review and comment.
[Tony Meyer]
Why does PEP 8 continually refer to one particular editor (Emacs)?
[Guido]
I think the best way to avoid editor wars is to pick one editor and
stick with it. :-)
I
[Guido van Rossum]
On 12/14/05, François Pinard [EMAIL PROTECTED] wrote:
I would like that PEP 0008 add some cement around this idea that common
English words, properly spelled, which are likely to be user variable
names, be avoided whenever reasonable.
I don't think that's a reasonable rule.
On Thu, 2005-12-15 at 11:13 +1100, Dave Cole wrote:
The only thing I strongly disagree with is the promotion of javaNaming
to equal footing with python_naming.
Actually, they're not on equal footing atm. I happen to agree with you
though.
-Barry
signature.asc
Description: This is a
On 12/14/05, François Pinard [EMAIL PROTECTED] wrote:
I do not understand your statement that module/package names can only
conflict with *global* user variable names. Local variables hide global
variables with same names, and imported modules are often global
variables. So, using a local
On 12/14/05, Barry Warsaw [EMAIL PROTECTED] wrote:
On Thu, 2005-12-15 at 11:13 +1100, Dave Cole wrote:
The only thing I strongly disagree with is the promotion of javaNaming
to equal footing with python_naming.
Actually, they're not on equal footing atm. I happen to agree with you
Guido van Rossum wrote:
On 12/14/05, Barry Warsaw [EMAIL PROTECTED] wrote:
On Thu, 2005-12-15 at 11:13 +1100, Dave Cole wrote:
The only thing I strongly disagree with is the promotion of javaNaming
to equal footing with python_naming.
Actually, they're not on equal footing atm. I happen to
At 11:50 PM 12/14/2005 -0600, Ian Bicking wrote:
Guido van Rossum wrote:
On 12/14/05, Barry Warsaw [EMAIL PROTECTED] wrote:
On Thu, 2005-12-15 at 11:13 +1100, Dave Cole wrote:
The only thing I strongly disagree with is the promotion of javaNaming
to equal footing with python_naming.
Michael Hoffman wrote:
[Ian Bickling]
stdlib, external modules, internal modules seems like enough
ordering to me.
[Jim Fulton]
Personally, I don't find the stdlib/external distinction to be useful.
It's useful because it allows one to quickly see all the prerequisites
need to be
Barry Warsaw wrote:
- If your class is intended to be subclassed, and you have attributes
that you do not want subclasses to use, consider naming them with
double leading underscores and no trailing underscores. This invokes
Python's name mangling algorithm,
Raymond Hettinger wrote:
Do not use accessor methods, like ``obj.getFoo()`` and
``obj.setFoo(v)``, instead just expose a public attribute
(``obj.foo``).
This advice is, of course, not appropriate for all users (properties are
not typically in a Python beginner's skill set)
Really? In any
Gustavo J. A. M. Carneiro wrote:
...
IMHO, if getting a property involves a potentially long computation,
it's better to have an accessor method rather than a property;
xpto.getFoobar() hints right away the programmer that to access that
value some code has to be run, so the programmer is
Dom, 2005-12-11 às 16:30 -0600, Ian Bicking escreveu:
Jim Fulton wrote:
Designing for inheritance
Always decide whether a class's methods and instance variables
should be public or non-public. In general, never make data
variables public unless you're
Nick Any old code could be fixed by putting from types import
Nick ClassType as __metaclass__ at the top of the affected modules.
Which would be, what, 90% of all Python code written that defines classes?
Skip
___
Python-Dev mailing list
Jim That's why, in my suggested writeup, I suggested that attributes
Jim should be used if the accessors are trivial.
In my experience it's difficult to find the locations where another module
mucks with your object's state. Using properties or accessor methods
coupling between modules
At 09:59 AM 12/12/2005 -0600, [EMAIL PROTECTED] wrote:
Jim That's why, in my suggested writeup, I suggested that attributes
Jim should be used if the accessors are trivial.
In my experience it's difficult to find the locations where another module
mucks with your object's state. Using
On Sun, 2005-12-11 at 11:20 -0500, Jim Fulton wrote:
This seems outdated. My impression, in part from time spent
working with the Python Labs guys, is that it is fine to have public
data sttributes even for non-record types. In fact, I would argue that
any time you would be tempted to
In my experience it's difficult to find the locations where another
module mucks with your object's state. Using properties or accessor
methods coupling between modules is reduced and you can be more
confident that the only place an object's state is modified directly
is
On Fri, 2005-12-09 at 17:19 -0600, Ian Bicking wrote:
I personally feel cls should be used for classmethods, and not
elsewhere. Just like I wouldn't like someone using self outside of
the first argument of instance methods. So class_ still would be a good
spelling elsewhere.
Here's what
On Sun, 2005-12-11 at 16:30 -0600, Ian Bicking wrote:
Potentially it could be added that the whole issue can often be avoided
when an object's methods perform actions instead of returning attributes
of the object. It's a long topic; maybe it could even just be a link,
if someone knows of
[EMAIL PROTECTED] wrote:
Jim That's why, in my suggested writeup, I suggested that attributes
Jim should be used if the accessors are trivial.
In my experience it's difficult to find the locations where another module
mucks with your object's state. Using properties or accessor
At 11:35 AM 12/12/2005 -0600, [EMAIL PROTECTED] wrote:
In my experience it's difficult to find the locations where another
module mucks with your object's state. Using properties or accessor
methods coupling between modules is reduced and you can be more
confident that the
Raymond Hettinger wrote:
Do not use accessor methods, like ``obj.getFoo()`` and
``obj.setFoo(v)``, instead just expose a public attribute
(``obj.foo``).
This advice is, of course, not appropriate for all users (properties are
not typically in a Python beginner's skill set) or all use cases.
Barry Warsaw wrote:
On Fri, 2005-12-09 at 17:19 -0600, Ian Bicking wrote:
I personally feel cls should be used for classmethods, and not
elsewhere. Just like I wouldn't like someone using self outside of
the first argument of instance methods. So class_ still would be a good
spelling
At 02:25 PM 12/12/2005 -0600, Ian Bicking wrote:
That looks good to me. Well, I actually try not to use cls as the first
argument to metaclass's __new__ method, because there's so many classes
being tossed about at that point that I try to be more explicit. But I
don't consider that a common
On 12/12/05, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 02:25 PM 12/12/2005 -0600, Ian Bicking wrote:
That looks good to me. Well, I actually try not to use cls as the first
argument to metaclass's __new__ method, because there's so many classes
being tossed about at that point that I try to
At 02:59 PM 12/12/2005 -0800, Alex Martelli wrote:
On 12/12/05, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 02:25 PM 12/12/2005 -0600, Ian Bicking wrote:
That looks good to me. Well, I actually try not to use cls as the first
argument to metaclass's __new__ method, because there's so many
On 12/12/05, Phillip J. Eby [EMAIL PROTECTED] wrote:
...
I'd rather see 'metaclass' fully spelled out than resort to 'mcl';
metaclass code is tricky enough to write without figuring out
abbreviations. :)
Indeed, the only reason I use 'cls' is because it was Pronounced the
standard;
Alex Martelli wrote:
On 12/12/05, Phillip J. Eby [EMAIL PROTECTED] wrote:
...
I'd rather see 'metaclass' fully spelled out than resort to 'mcl';
metaclass code is tricky enough to write without figuring out
abbreviations. :)
Indeed, the only reason I use 'cls' is because it was Pronounced
I looked at that too, but most of these didn't jump out at me. I'll
copy in the parts that aren't already in PEP 8 that seem possible:
From-imports should follow non-from imports. Dotted imports should
follow non-dotted imports. Non-dotted imports should be grouped
Jim I don't understand this argument. Any mutating method or property
Jim invoked by foreign code changes an object's state.
Sure, but the only place I need to look for direct changes to the object's
state are in the object's own code.
Jim If you provide a property or a pair if
* Python core modules/packages
* Third-party modules/packages
* Local modules/packages
This is already in PEP 8:
[...]
1. standard library imports
2. related major package imports (i.e. all email package
imports
next)
3. application specific imports
Ian Bicking wrote:
I was reading through PEP 8, and I think there's a few things that could
be clarified or updated:
Good idea.
...
Designing for inheritance
Always decide whether a class's methods and instance variables
should be public or non-public. In general,
[EMAIL PROTECTED] wrote:
Jim == Jim Fulton [EMAIL PROTECTED] writes:
Jim The decision about wither to implement foo as a key in the instance
Jim dictionary *is* an implementation detail that can be hidden by a
Jim property.
If it's not in the instance dictionary, where is
Ian Bicking wrote:
Jim Fulton wrote:
Designing for inheritance
Always decide whether a class's methods and instance variables
should be public or non-public. In general, never make data
variables public unless you're implementing essentially a
record.
Jim Fulton wrote:
FWIW, as a general rule, I like using a single trailing underscore,
especially for keywords. It allows the use of meaningful and easy
to remember names. When the name of a variable should be class or
for or whatever, it's easy, as a Python programmer, to remember that
I
Ian Do not use accessor methods, like ``obj.getFoo()`` and
Ian ``obj.setFoo(v)``, instead just expose a public attribute
Ian (``obj.foo``). If necessary you can use ``property`` to implement
Ian the same functionality that accessor methods would give you.
Don't properties only
Do not use accessor methods, like ``obj.getFoo()`` and
``obj.setFoo(v)``, instead just expose a public attribute
(``obj.foo``).
This advice is, of course, not appropriate for all users (properties are
not typically in a Python beginner's skill set) or all use cases. It is
closer to one
[EMAIL PROTECTED] wrote:
Ian Do not use accessor methods, like ``obj.getFoo()`` and
Ian ``obj.setFoo(v)``, instead just expose a public attribute
Ian (``obj.foo``). If necessary you can use ``property`` to implement
Ian the same functionality that accessor methods would give
Don't properties only work with new-style clsses? If so, this should
probably be noted.
Josiah In the future, aren't all classes going to become new-style?
Sure, but PEP 8 should be accurate for current Python. 0.5 wink
Josiah Was it going to wait until Py3k, or sometime
Josiah Carlson wrote:
[EMAIL PROTECTED] wrote:
Ian Do not use accessor methods, like ``obj.getFoo()`` and
Ian ``obj.setFoo(v)``, instead just expose a public attribute
Ian (``obj.foo``). If necessary you can use ``property`` to implement
Ian the same functionality that
On 12/11/05, Nick Coghlan [EMAIL PROTECTED] wrote:
Josiah Carlson wrote:
[EMAIL PROTECTED] wrote:
Ian Do not use accessor methods, like ``obj.getFoo()`` and
Ian ``obj.setFoo(v)``, instead just expose a public attribute
Ian (``obj.foo``). If necessary you can use ``property``
Robert Brewer wrote:
Barry Warsaw wrote:
Again, I'd say something like: Since your exceptions
will be classes, use the CapWord naming convention for
classes to name your exceptions. It is recommended
that your exception class end in the word Error.
Unless, of course, your exception is not
Barry Warsaw [EMAIL PROTECTED] writes:
Let's say something like string-based exceptions are strongly
discouraged, and in fact may be deprecated or disappear in a future
Python version. Use class-based exceptions.
If I have anything to do with it, they _will_ be deprecated in 2.5.
There is
[Ian Bicking]
Barry Warsaw wrote:
Just like I wouldn't like someone using self outside of the first
argument of instance methods.
A tiny nit. Within __new__(cls, ...), I find quite legible writing:
self = BASECLASSE.__new__(cls, ...)
and using it afterwards.
--
François Pinard
On 12/10/05, Michael Hudson [EMAIL PROTECTED] wrote:
Barry Warsaw [EMAIL PROTECTED] writes:
Let's say something like string-based exceptions are strongly
discouraged, and in fact may be deprecated or disappear in a future
Python version. Use class-based exceptions.
If I have anything to
Barry Warsaw wrote:
It does seem like the more popular convention is to use cls than
class_. I'll admit the latter does look kind of ugly. Maybe the
suggestion should be to use either a trailing single underscore or an
abbreviation instead of a spelling corruption. We could then list some
On Fri, 2005-12-09 at 17:19 -0600, Ian Bicking wrote:
I personally feel cls should be used for classmethods, and not
elsewhere. Just like I wouldn't like someone using self outside of
the first argument of instance methods. So class_ still would be a good
spelling elsewhere.
Cool.
Barry Warsaw wrote:
On Fri, 2005-12-09 at 15:38 -0600, Ian Bicking wrote:
Also decide whether your attributes should be private or not.
The difference between private and non-public is that the former
will never be useful for a derived class, while the latter might
On Fri, 2005-12-09 at 16:23 -0800, Robert Brewer wrote:
Barry Warsaw wrote:
Again, I'd say something like: Since your exceptions
will be classes, use the CapWord naming convention for
classes to name your exceptions. It is recommended
that your exception class end in the word Error.
87 matches
Mail list logo
