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 librar
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, b
On Thu, 2005-12-15 at 11:22 +0100, [EMAIL PROTECTED]
wrote:
> 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.
-Barry
signatu
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 an
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
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,
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
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 rule
[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 'tex
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.
> >
>
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 s
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 ob
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 poss
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
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 ;) pro
> 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 fol
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 substant
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 an
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
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
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 yo
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 loc
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 digit
[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 reasona
[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
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 m
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
[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 shou
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 t
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: y
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, w
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 digitall
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 12/14/05, Tony Meyer <[EMAIL PROTECTED]> wrote:
> > 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
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 als
> 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
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 pa
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 pre
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
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
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
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
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, m
On 12/14/05, Wolfgang <[EMAIL PROTECTED]> wrote:
> 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 wh
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
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.
Or BE
[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.
--
Michael Hoffman <[EMAIL PROTECTED]>
Europe
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),
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, w
On 12/13/05, Jim Fulton <[EMAIL PROTECTED]> wrote:
> Personally, I'd rather just sort aphabetically based on dotted package
> name. Because packages provide meaningful groupings to begin with,
> this approach provides the most meaningful groupings to me. (All of
> my "internal" modules are in pac
At 07:26 AM 12/13/2005 -0500, Jim Fulton wrote:
>Personally, I'd actively discourage use of trivial accessors. Simple
>attribute access is not only "fine", IMO, but it is much better than
>trivial accessors. This is an important point, IMO, because, in my
>experience, the vast majority of accesso
At 03:25 PM 12/13/2005 +, Michael Hoffman wrote:
>[Jim Fulton]
> > Sure, if you only have one module, and if your module doesn't do any
> > dynamic imports, and if the things your importing don't have dependencies,
> > and ...
> >
> > I think it would be simpler to have a formal dependency syst
Jim Fulton wrote:
>> stdlib, external modules, internal modules seems like enough ordering
>> to me. If you want to order things more exactly, sure, but I don't
>> really see the point personally. Since I can't assume as a reader
>> that imports are ordered in any way I have to search to be su
[Jim Fulton]
>>> Personally, I don't find the stdlib/external distinction to be useful.
[Michael Hoffman]
>> It's useful because it allows one to quickly see all the prerequisites
>> need to be installed in one place.
[Jim Fulton]
> Sure, if you only have one module, and if your module doesn't do
Jim> Personally, I don't find the stdlib/external distinction to be
Jim> useful.
For me it's just a "who do I blame for problems" sort of thing. Most of the
time I know, but others looking at my code might not know that MySQLdb isn't
in the core but that bsddb is.
Skip
_
Nick> Having to type '(object)' all the time is annoying, but less
Nick> annoying than trying to figure out which set of semantics a given
Nick> class is using.
Sure. Since I started writing Python long before new-style classes were
around, I have lots of classic classes. My default
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 prerequisit
Guido van Rossum <[EMAIL PROTECTED]> writes:
> Dotted non-from imports (e.g. import test.pystone) are rare enough
> that they don't deserve a special rule; if you want me to give a rule,
> I think they should be mixed in with the undotted ones,
> alphabetically.
I actually really hate this style,
[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 installed in one place.
--
Mic
Barry Warsaw wrote:
> 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 ti
Barry Warsaw wrote:
> 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
[EMAIL PROTECTED] wrote:
> 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>
Ian Bicking wrote:
> Barry Warsaw wrote:
...
>>>This seems too complex to me for PEP 8.
>>
>>
>>Really? ISTR adopting this convention from Guido, but I'm not 100% sure
>>about that. After having used it for several years now, I do really
>>like this style, but I'm willing to leave the recommenda
Seg, 2005-12-12 às 22:38 -0600, [EMAIL PROTECTED] escreveu:
> 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 th
[EMAIL PROTECTED] wrote:
> 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?
I generally don't allow old-style classes in an
>> * 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 sp
On 12/12/05, Ian Bicking <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> > This is subjective enough that I would think some rationale explaining this
> > convention should be given. Personally, I group imports into three sections
> > as follows:
> >
> > * Python core modules/packages
[EMAIL PROTECTED] wrote:
> This is subjective enough that I would think some rationale explaining this
> convention should be given. Personally, I group imports into three sections
> as follows:
>
> * Python core modules/packages
>
> * Third-party modules/packages
>
> * Local module
On 12/12/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> >> 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
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
>> 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
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
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
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
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
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
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
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 us
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
> >> confide
[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 accesso
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
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
>> 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
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
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.
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
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
Py
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
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 i
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?
[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
Guido van Rossum wrote:
> 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`
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 u
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
>> 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 somet
[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 woul
> 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 person
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 onl
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 tha
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
>>>
1 - 100 of 118 matches
Mail list logo
