[Steven Bethard]
import ellogon.utils as utils
import ellogon.features.relations as features_relations
import ellogon.chunking as chunking
import ml.classifiers as _ml_classifiers
import ml.data as _ml_data
The only two-letter one was ElementTree, and the vast majority were
unabbreviated, though
[Phillip J. Eby]
At 09:53 AM 12/13/2005 -0500, François Pinard wrote:
Everybody here agrees that this style makes the code much less legible.
I hope you mean, here at your company or organization, as I disagree. :)
Yes, of course! Sorry for the ambiguity.
--
François Pinard
On 12/12/05, Guido van Rossum [EMAIL PROTECTED] wrote:
Unfortunately that fails one of the other requirements, which (at the
time of implementation) was minimal impact on the rest of the
interpreter. Since __private isn't limited to self, and attribute
lookup doesn't always result in a dict
Tim Peters wrote:
[Neal Norwitz]
...
That was the only point to `__` name-mangling. People who think it's
trying to, e.g., emulate C++'s `private` gimmick are enjoying a
semi-private fantasy ;-) It works fine for its intended use.
In theory, I agree.
In practice, I don't agree that it
[Quotations deleted since I'm not replying to anything directly]
When I need an identifier unique to a class I just use a reference to
the class itself. As such I'd like to suggest that
obj.__private
be converted to
obj.__dict__[(type(obj), '__private')]
Note that I'm accessing __dict__
Jim Fulton wrote:
Ian Bicking wrote:
Jim Fulton wrote:
Ian Bicking wrote:
Private attributes should have two leading underscores, no
trailing underscores.
This conflicts with a previous suggestion Generally, double leading
underscores should be used only to avoid name
On 12/12/05, Scott David Daniels [EMAIL PROTECTED] wrote:
Jim Fulton wrote:
Ian Bicking wrote:
Jim Fulton wrote:
Ian Bicking wrote:
Private attributes should have two leading underscores, no
trailing underscores.
This conflicts with a previous suggestion Generally,
Jeremy Hylton wrote:
On 12/12/05, Scott David Daniels [EMAIL PROTECTED] wrote:
Perhaps The __ name convention is designed for 'mixins'; as a means of
enforcing private it is both ineffective and annoying. For example,
distutils.msvccompiler uses a bunch of instance variables which would I
On 12/11/05, Steven Bethard [EMAIL PROTECTED] wrote:
On 12/11/05, Guido van Rossum [EMAIL PROTECTED] wrote:
I know about the fear of accidental reuse of class names, but I don't
find it a compelling argument.
FWIW, I know I currently have a number of classes that are potentially
hazardous
On 12/12/05, Jim Fulton [EMAIL PROTECTED] wrote:
In practice, I don't agree that it works fine. Inevitably, someone
finds a need to access a private variable in a subclass. Or
even in the original class, you find some need to use something like
__getattr__ where the implicit name mangling
On 12/12/05, Scott David Daniels [EMAIL PROTECTED] wrote:
Perhaps The __ name convention is designed for 'mixins'; as a means of
enforcing private it is both ineffective and annoying. For example,
distutils.msvccompiler uses a bunch of instance variables which would I
would like to access in
On 12/12/05, Guido van Rossum [EMAIL PROTECTED] wrote:
On 12/11/05, Steven Bethard [EMAIL PROTECTED] wrote:
class Document(_cdm.Document):
...
# add convenience methods here
...
Personally, I find that naming convention a mistake. Call it
MyDocument or EnhancedDocument or
Neal Norwitz wrote:
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.
Then maybe it should
On 12/12/05, Guido van Rossum [EMAIL PROTECTED] wrote:
but that's not the same at all. The point of __private is that it uses
the *static* scope of the code that contains the reference, not the
(dynamic) type of the object being referenced. With your approach, if
class A defined __private,
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
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
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
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
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
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
22 matches
Mail list logo
