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 gener
Martin v. Löwis wrote:
> That's primarily for the author of the software to decide, at this
> point. Fredrik Lundh would have to offer it for contribution first.
I've already done that, as others have noted. Everything I release
under a Python-compatible license is available for bundling with th
Jim> This seems outdated. My impression, in part from time spent
Jim> working with the Python Labs guys, is that it is fine to have
Jim> public data sttributes even for non-"record" types. In fact, I
Jim> would argue that any time you would be tempted to provide
Jim> "getFoo(
[EMAIL PROTECTED] wrote:
> Jim> This seems outdated. My impression, in part from time spent
> Jim> working with the Python Labs guys, is that it is fine to have
> Jim> public data sttributes even for non-"record" types. In fact, I
> Jim> would argue that any time you would be temp
Fredrik Lundh wrote:
>>That's primarily for the author of the software to decide, at this
>>point. Fredrik Lundh would have to offer it for contribution first.
>
>
> I've already done that, as others have noted. Everything I release
> under a Python-compatible license is available for bundling w
> "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 it?
Skip
__
[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 dic
Martin v. Löwis wrote:
> >>That's primarily for the author of the software to decide, at this
> >>point. Fredrik Lundh would have to offer it for contribution first.
> >
> > I've already done that, as others have noted. Everything I release
> > under a Python-compatible license is available for b
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. It's almost
Ian Bicking wrote:
> Jim Fulton 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
>>>be. Yes, you sho
On Sun, Dec 11, 2005, Fredrik Lundh wrote:
>
> whaddya think?
Huzzah!
(Not that I've used ElementTree personally, but I think this conversation
is a wonderful example of good Open Source discussion and development
practice. Everyone involved deserves kudos, but particularly Fredrik for
taking th
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
>>>
On 12/11/05, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Fredrik Lundh wrote:
[SNIP]
> > - I check in an existing elementtree release in a separate location in
> > the svn.python.org source tree. e.g.
> >
> > svn.python.org/kits/elementtree-1.2.6-20050316
> >
> > this will make
Jim Fulton wrote:
> Can we officially mark __private as a mistake. Perhaps:
>
> - Strongly discourage it in the style guide
+1
> - Mark it in the language reference as a deprecated feature
+1
> - Generate deprecation warnings when it is used?
-0
I don't see that this gains us much. It will c
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> 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
On 12/11/05, Jim Fulton <[EMAIL PROTECTED]> wrote:
>
> Can we officially mark __private as a mistake. Perhaps:
>
> - Strongly discourage it in the style guide
This may be acceptable.
> - Mark it in the language reference as a deprecated feature
>
> - Generate deprecation warnings when it is used?
[Neal Norwitz]
> I recently asked Guido about name mangling wrt Py3k. He definitely
> wanted to keep it in. Unless he changed his mind, I doubt he would
> deprecate it. His rationale was that there needs to be a way to
> handle name collision with multiple inheritance.
That wasn't quite it. Th
> 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
Neal Norwitz wrote:
> On 12/11/05, Jim Fulton <[EMAIL PROTECTED]> wrote:
>> Can we officially mark __private as a mistake. Perhaps:
>>
>> - Strongly discourage it in the style guide
>
> This may be acceptable.
>
>> - Mark it in the language reference as a deprecated feature
>>
>> - Generate depre
Interesting discussion. I've been thinking the opposite; that I should
start using __attribute more often for "undocumented, private" member
variables that are implementation details and clearly not part of the
public interface.
I'm curious what people have against it?
On Sun, Dec 11, 2005 at 09
[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
On 12/11/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Keeping it for Py3K would be fine, if the mechanism was changed so that it
> actually worked right. That is, the mechanics would be such that any two
> concurrently existing classes would be guaranteed to mangle the names of their
> private var
>> 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
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
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
Hi All,
I think that a big problem is that there isn't an obvious way to say:
self.a is part of the class interface, self.b isn't. Or: you can
override self._c to do that. I believe we really need a way to do
these things more clear.
Currently we can use methods and properties, but even this is no
Look:
>>> a = file("dir/foo")
>>> a.close()
>>> a.read()
Traceback (most recent call last):
File "", line 1, in -toplevel-
a.read()
ValueError: I/O operation on closed file
Shoudn't this raise IOError? Seems more semantically correct to me.
--
João Paulo da Silva
LinuxUser #355914
ICQ: 26
On 12/11/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 12/11/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> > Keeping it for Py3K would be fine, if the mechanism was changed so that it
> > actually worked right. That is, the mechanics would be such that any two
> > concurrently existing class
On 12/11/05, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> > Overall, sounds like a good plan.
>
> Just say "go", and I'll start working on this.
Are you still waiting for someone to say go? I'm not sure what
responsible party should say it; if I'm not the right person, would
the right person pleas
Fredrik Lundh wrote:
> Exactly. But I'm not sure "branch" is really accurate here; it's more like
> "snapshot". Stable releases are added to the "vendor" tree, and relevant
> files are are then copied to the appropriate location in the release tree.
In practice, it will be a branch - unless you
João Paulo Silva wrote:
> >>> a = file("dir/foo")
> >>> a.close()
> >>> a.read()
>
> Traceback (most recent call last):
> File "", line 1, in -toplevel-
> a.read()
> ValueError: I/O operation on closed file
>
> Shoudn't this raise IOError? Seems more semantically correct to me.
IOError is,
Martin v. Löwis wrote
> > And maybe PEP 291 could be updated to cover both compatibility with older
> > Python versions and other compatibility issues.
>
> So what would be the minimum Python version you keep compatibility with?
as Brett pointed out, the procedure to use for externally developed
33 matches
Mail list logo
