Re: PEP Idea: Real private attribute

On Tue, Aug 31, 2021 at 1:19 PM Mehrzad Saremi wrote: > Calvin, even if the language offered truly private members? > I'm saying I don't think they're necessary, especially not for the use case posited here. Private members in other languages are about things internal to the class of the object

Re: PEP Idea: Real private attribute

Calvin, even if the language offered truly private members? On Tue, 31 Aug 2021 at 17:31, Calvin Spealman wrote: > The right way for those decorators to hold some private information, imho, > isn't to put anything on the decorated object at all, but to use a weak-ref > dictionary using the

Re: PEP Idea: Real private attribute

The right way for those decorators to hold some private information, imho, isn't to put anything on the decorated object at all, but to use a weak-ref dictionary using the target object as a key. On Sat, Aug 28, 2021 at 5:42 PM Mehrzad Saremi wrote: > Python currently uses name mangling for

Re: PEP Idea: Real private attribute

The proposed semantics would be the same as self.__privs__[__class__, "foo"]; yes I can say the problem is ugliness. The following is an example where name mangling can be problematic (of course there are workarounds, yet if double-underscores are meant to represent class-specific members, the

Re: PEP Idea: Real private attribute

On Mon, Aug 30, 2021 at 5:49 AM Mehrzad Saremi wrote: > > No, a class ("the class that I'm lexically inside") cannot be accessed from > outside of the class. This is why I'm planning to offer it as a core > feature because only the parser would know. There's apparently no elegant > solution if

Re: PEP Idea: Real private attribute

No, a class ("the class that I'm lexically inside") cannot be accessed from outside of the class. This is why I'm planning to offer it as a core feature because only the parser would know. There's apparently no elegant solution if you want to implement it yourself. You'll need to write

Re: PEP Idea: Real private attribute

On Sun, Aug 29, 2021 at 7:40 AM Mehrzad Saremi wrote: > > Python currently uses name mangling for double-underscore attributes. Name > mangling is not an ideal method to avoid name conflicting. There are > various normal programming patterns that can simply cause name conflicting > in

PEP Idea: Real private attribute

Python currently uses name mangling for double-underscore attributes. Name mangling is not an ideal method to avoid name conflicting. There are various normal programming patterns that can simply cause name conflicting in double-underscore members. A typical example is when a class is re-decorated

[issue25315] OrderedDict mangled private attribute is inaccessible

Serge Matveenko added the comment: Sorry for reopening. I completely agree with the point that is it not necessary for Python and C implementations to duplicate each other. But then the Python OrderedDict implementation should be dropped from the library source. The code that is there now is

[issue25315] OrderedDict mangled private attribute is inaccessible

Emanuel Barry added the comment: The Python implementation will stay for two main reasons, one to provide a working implementation for all those who wish to use a modified version (you, for example, if you want to use a version that lets you alter order), and two for alternate implementations

[issue25315] OrderedDict mangled private attribute is inaccessible

R. David Murray added the comment: Yes, that would be correct. OrderedDict is designed to keep things in insertion order, so supporting changing that order is not part of its mission. Sorry about that, you'll have to write your own class. Now, Raymond might find the idea of supporting other

[issue25315] OrderedDict mangled private attribute is inaccessible

Serge Matveenko added the comment: Ok, then the OrderedDict is useless for any advanced hacking like altering the order in which __setitem__ stores items. It is just useless Python code and so much appliances missed for this class:( Thank you all for these completely helpful answers.

[issue25315] OrderedDict mangled private attribute is inaccessible

Serge Matveenko added the comment: Zach, ok I got your point. But there is Python implementation in the library still which does not conform the one done in C. Such a behavior is tremendously confusing. If there is both Python and C implementation in the library they must conform each other.

[issue25315] OrderedDict mangled private attribute is inaccessible

Serge Matveenko added the comment: If Python source does conform the one in C, it will be completely fine and understandable to have such a change and to rely on it in using version checks or whatever. -- ___ Python tracker

[issue25315] OrderedDict mangled private attribute is inaccessible

Changes by Serhiy Storchaka : -- assignee: -> rhettinger nosy: +rhettinger priority: normal -> low ___ Python tracker ___

[issue25315] OrderedDict mangled private attribute is inaccessible

Emanuel Barry added the comment: The same is true of the decimal and datetime modules. Names starting with an underscore are an implementation detail, and you shouldn't rely on these in production code. -- nosy: +ebarry ___ Python tracker

[issue25315] OrderedDict mangled private attribute is inaccessible

R. David Murray added the comment: A method that starts with an '_' is not part of the API unless documented to be so (as with namedtuple), and a non-special method that starts with two is purposefully mangled so that you cannot accidentally rely on it. The C implementation is an

[issue25315] OrderedDict mangled private attribute is inaccessible

elf, *args, **kwargs) ... >>> md = MyDict({'a': 1}) ------ components: Library (Lib) messages: 252296 nosy: Serge Matveenko (lig) priority: normal severity: normal status: open title: OrderedDict mangled private attribute is inaccessib

[issue25315] OrderedDict mangled private attribute is inaccessible

Zachary Ware added the comment: This is a side-effect of 3.5 having a C implementation of OrderedDict, and will not be fixed. In the standard library, even just having a single trailing underscore is a clear indication of "if you use this, expect it to break without warning at any time."

Re: Private attribute

Steven D'Aprano wrote: snip def SomeClass(object): _gridsize = 0.8 The leading underscore tells callers that they change the attribute at their own risk. An even more Pythonic approach is to write your class that makes no assumptions about gridsize, and thus explicitly supports any

Private attribute

I have a class with an attribute called 'gridsize' and I want a derived class to force and keep it at 0.8 (representing 8mm). Is this a correct, or the most pythonic approach? def __getattr__(self,attrname): if attrname == 'gridsize': return 0.8

Re: Private attribute

Ken Starks wrote: I have a class with an attribute called 'gridsize' and I want a derived class to force and keep it at 0.8 (representing 8mm). Is this a correct, or the most pythonic approach? def __getattr__(self,attrname): if attrname == 'gridsize':

Re: Private attribute

On Aug 25, 2:09 pm, Ken Starks [EMAIL PROTECTED] wrote: Ken Starks wrote: I have a class with an attribute called 'gridsize' and I want a derived class to force and keep it at 0.8 (representing 8mm). Is this a correct, or the most pythonic approach?     def

Re: Private attribute

On Aug 25, 3:47 pm, Ken Starks [EMAIL PROTECTED] wrote: I have a class with an attribute called 'gridsize' and I want a derived class to force and keep it at 0.8 (representing 8mm). Is this a correct, or the most pythonic approach?      def __getattr__(self,attrname):

Re: Private attribute

André wrote: On Aug 25, 3:47 pm, Ken Starks [EMAIL PROTECTED] wrote: I have a class with an attribute called 'gridsize' and I want a derived class to force and keep it at 0.8 (representing 8mm). Is this a correct, or the most pythonic approach? def

Re: Private attribute

On Mon, 25 Aug 2008 21:44:49 +0100, Ken Starks wrote: def __getattr__(self,attrname): if attrname == 'gridsize': return 0.8 def __setattr__(self,attrname,value): if attrname == 'gridsize': pass else:

Re: Private attribute

Marc 'BlackJack' Rintsch wrote: On Mon, 25 Aug 2008 21:44:49 +0100, Ken Starks wrote: def __getattr__(self,attrname): if attrname == 'gridsize': return 0.8 def __setattr__(self,attrname,value): if attrname == 'gridsize':

Re: Private attribute

On Mon, 25 Aug 2008 19:47:38 +0100, Ken Starks wrote: I have a class with an attribute called 'gridsize' and I want a derived class to force and keep it at 0.8 (representing 8mm). Is this a correct, or the most pythonic approach? Others have already suggested using a property, but I'll

[issue3152] ast module docs document private attribute

. -- assignee: georg.brandl components: Documentation keywords: easy messages: 68473 nosy: brett.cannon, georg.brandl priority: critical severity: normal status: open title: ast module docs document private attribute type: behavior versions: Python 2.6, Python 3.0

[issue3152] ast module docs document private attribute

Georg Brandl [EMAIL PROTECTED] added the comment: I disagree. The AST classes are auto-generated, the leading underscore of _fields is there to avoid clashes with field names from the AST types. This is similar to http://docs.python.org/dev/library/collections#collections.somenamedtuple._fields

[issue3152] ast module docs document private attribute

Raymond Hettinger [EMAIL PROTECTED] added the comment: This is consistent with the methods in named tuples (also to avoid name clashes). -- components: +None keywords: +26backport nosy: +rhettinger ___ Python tracker [EMAIL PROTECTED]

[issue3152] ast module docs document private attribute

Martin v. Löwis [EMAIL PROTECTED] added the comment: I agree with Georg and Raymond, closing this as won't fix. -- nosy: +loewis resolution: - wont fix status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3152