> I does seem almost comical that the introduction of yield as a keyword
> requires a future statement but the descr branch changes do not.
We discussed this extensively at a PythonLabs meeting today. Unless
we get a real revolt about this from the users, we'll keep the future
generators statement because that's the least work.
> Talk about silent failures -- dir() no longers work, method
> resolution for multiple inheritance changes, changes to the str
> names of types. Why don't these require a future statement?
The latest proposal is to let dir() return more rather than less: it
will return the instance variable names *plus* all attributes defined
by the class *and* its base classes.
The MRO change is not incompatible: the MRO for classic classes is
unchanged. You get the new MRO only when you explicitly request new
classes (by inheriting from 'object' or specifying '__metaclass__ =
type').
I don't know how I would make the name of the string object vary based
on a future statement, and I doubt that this particular breakage will
bother those affected much.
In general, the unification introduces new or changed features only
when they are explicitly requested. dir() and type("").__name__ are
the rare exceptions.
BTW, please read the introduction at
http://www.python.org/2.2/descrintro.html
--Guido van Rossum (home page: http://www.python.org/~guido/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4