[Python-Dev] Instance variable access and descriptors
Steven Bethard
steven.bethard at gmail.com
Sun Jun 10 00:18:37 CEST 2007
> On 6/10/07, Steven Bethard <steven.bethard at gmail.com> wrote:
> > On 6/9/07, Eyal Lotem <eyal.lotem at gmail.com> wrote:
> > > I believe that this should be changed, so that Python first looks for
> > > the attribute in the instance's dict and only then through the dict's
> > > mro.
> >
> > Are you suggesting that the following code should print "43" instead of "42"?
> > ::
> >
> > >>> class C(object):
> > ... x = property(lambda self: self._x)
> > ... def __init__(self):
> > ... self._x = 42
> > ...
> > >>> c = C()
> > >>> c.__dict__['x'] = 43
> > >>> c.x
> > 42
On 6/9/07, Eyal Lotem <eyal.lotem at gmail.com> wrote:
> Yes, I do suggest that.
> But its important to notice that this is not a suggestion in order to
> improve Python, but one that makes it possible to get reasonable
> performance out of CPython. As such, I don't believe it should be done
> in Py3K.
>
> Firstly, like everything that breaks backwards compatibility, it is
> possible to have a transitional version that spits warnings for all
> problems (detect name clashes between properties and instance dict).
Sure, but then you're talking about really introducing this in Python
2.7, with 2.6 as a transitional version. So take a minute to look at
the release timelines:
http://www.python.org/dev/peps/pep-0361/
The initial 2.6 target is for April 2008.
http://www.python.org/dev/peps/pep-3000/
I hope to have a first alpha release (3.0a1) out in the first half of
2007; it should take no more than a year from then before the first
proper release, named Python 3.0
So I'm expecting Python 3.0 to come out *before* 2.7. Thus if you're
proposing a backwards-incompatible change that would have to wait
until 2.7 anyway, why not propose it for 3.0 where
backwards-incompatible changes are more acceptable?
STeVe
--
I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a
tiny blip on the distant coast of sanity.
--- Bucky Katt, Get Fuzzy
More information about the Python-Dev
mailing list