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
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
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 should design
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 the
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.
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 it clear that
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
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
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. The
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
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 deprecation warnings
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
[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``
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
Look:
a = file(dir/foo)
a.close()
a.read()
Traceback (most recent call last):
File pyshell#28, 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:
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 classes would
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 please say
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 want to
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 and
25 matches
Mail list logo
