[Python-bugs-list] [ python-Bugs-569257 ] __slots__ attribute and private variable

[noreply@sourceforge.net]

Bugs item #569257, was opened at 2002-06-14 19:54
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=569257&group_id=5470

Category: Type/class unification
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Keyton Weissinger (keytonw)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: __slots__ attribute and private variable

Initial Comment:
If you use a __slots__ class variable and include a 
variable with a double underscore as the first two 
characters, that variable is NOT private as would be the 
case for any other variable whose name begins with a 
double underscore.

If this is by design, then it should be in the docs. If it is 
not and represents a bug, it needs to be investigated.

Thank you!!!

Keyton Weissinger

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-20 00:19

Message:
Logged In: YES 
user_id=80475

Done.
Revised patch attached.
No more modifying immutables for me!

Thanks for the comments -- they really help me get to the 
root of a problem, get it fixed, and learn something for the 
next bugfix.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-19 22:04

Message:
Logged In: YES 
user_id=6380

Eh, no, I think there's a bug. The slots variable is made a
tuple by calling PySequence_Tuple(). If it was already a
tuple, this adds a reference to the existing tuple. And
later you're modifying it in-place! This gives the
"impossible" semantics of the following example:

>>> t = ("__foo", "__bar")
>>> class C(object):
      __slots__ = t
    
>>> t
('_C__foo', '_C__bar')
>>> 

I'm afraid you'll have to clone the tuple when you find its
refcount is >1.

Also, please make lines < 79 chars. And a readability
recommendation: if an if statement's expression is several
lines long, don't hide the '{' at the end of a line, but put
it at the beginning of the next, under the if: e.g.

    if (blah, blah, blah,
        blah, blah, blah,
        blah, blah, blah)
    {
        blah;
        blah;
    }

Barry taught me this trick. :-)

Also, I think it's wrong to #include "compile.h" in
Python.h, it exposes too many internals... Better declare
the _Py_Munge() prototype somewhere else (directly in
Python.h would be fine).

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-19 21:51

Message:
Logged In: YES 
user_id=80475

Done.  New patch attached. Okay to commit?

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-19 14:30

Message:
Logged In: YES 
user_id=6380

rhettinger: I haven't seen the patch, but I agree this ought
to be fixed -- in Python 2.3, as a new feature though. Why
don't you make munge() a private global (with an _Py prefix
to its name).

keytonw: I have no idea what you meant in your comment about
properties and slots and __property_name__. Can you
elaborate that?

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-19 13:13

Message:
Logged In: YES 
user_id=80475

Added patch.

Note, the patch would be much shorter if mangle() in 
compile.c were made non-static.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-17 23:19

Message:
Logged In: YES 
user_id=80475

Agree that it is a bug.
Working on a patch.

----------------------------------------------------------------------

Comment By: Keyton Weissinger (keytonw)
Date: 2002-06-14 22:31

Message:
Logged In: YES 
user_id=396481

Also, this issue prevents you from using the combination of 
property() and __slots__ which would be powerful, as 
attempting to use them would make __property_name__ a 
legal public variable, no?


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=569257&group_id=5470