[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 http://pin
[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,
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. :)
The current draft API guidelines for Chandler encourage the use of short
API module names such
On 12/13/05, François Pinard <[EMAIL PROTECTED]> wrote:
> [Steven Bethard]
>
> >Ahh. I never run into this because I never import objects directly
> >from modules. So, instead of:
>
> >from elementtree.ElementTree import ElementTree
> >...
> >ElementTree(...)
>
> >I almost always writ
[Steven Bethard]
>Ahh. I never run into this because I never import objects directly
>from modules. So, instead of:
>from elementtree.ElementTree import ElementTree
>...
>ElementTree(...)
>I almost always write something like:
>import elementtree.ElementTree as et
>...
>
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 di
Guido van Rossum wrote:
> 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__
On 12/12/05, Adam Olsen <[EMAIL PROTECTED]> wrote:
> 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 ref
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
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 shoul
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 Enhanc
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 ac
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 mang
On 12/12/05, Adam Olsen <[EMAIL PROTECTED]> wrote:
> 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__ directly s
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
>
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
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 pre
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
[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__ directly
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
Tim Peters wrote:
> [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.
>
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
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
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
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
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
[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
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?
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
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
30 matches
Mail list logo
