PEP 251 promises a 2.2a1 release on July 18 (coming Wednesday), and I
have every intention to fulfill this promise. (That's why we added
the future statement for generators.)
The PEP also promises that the release will be done from a branch.
Rather than forming a new branch, I intend to do the release, for
once, from the descr-branch.
This means that the release will contain the experimental code that
implements most (but not all) of PEP 252 and 253. This is intended to
be backwards compatible. One purpose of the release is to see *how*
backwards compatible.
If the descr-branch release turns out to be a disaster, I may decide
to hold off on the descr-branch work and we'll release 2.2 without all
the good stuff from the descr-branch. But I don't expect that this
will happen. The worst that I really expect is that we'll have to do
a bunch more backwards compatibility work. If 2.2a1 is a success,
I'll merge the descr-branch into the trunk.
I realize that the descr-branch work is not finished and not
sufficiently documented (despite the 10K words in the two PEPs).
That's OK, it's an alpha release.
In preparation for this event, Tim is semi-continuously merging the
trunk into the descr-branch, and I've added the branch tag to all
files in the trunk (so the branch is now a complete set of files).
If you have something that should go into the 2.2a1 release, please
check it in on the trunk and add a note to the checkin message "please
merge into 2.2a1".
Backwards incompatibility
-------------------------
99% of the features on descr-branch are only invoked when you use a
class statement with a built-in object as a base class (or when you
use an explicit __metaclass__ assignment).
Some descr-branch things that might affect old code:
- Introspection works differently (see PEP 252). In particular, most
objects now have a __class__ attribute, and the __methods__ and
__members__ attributes no longer work. This means that dir([]) will
return an empty list. Use dir(type([])) instead -- this is
consistent with regular classes. See the example in PEP 252.
- Several built-ins that can be seen as coercions or constructors are
now type objects rather than factory functions; the type objects
support the same behaviors as the old factory functions. Affected
are: complex, float, long, int, str, tuple, list, unicode, and
type. (There are also new ones: dictionary, object, classmethod,
staticmethod, but since these are new built-ins I can't see how this
would break old code.)
- There's one very specific (and fortunately uncommon) bug that used
to go undetected, but which is now reported as an error:
class A:
def foo(self): pass
class B(A): pass
class C(A):
def foo(self):
B.foo(self)
Here, C.foo wants to call A.foo, but by mistake calls B.foo. In the
old system, because B doesn't define foo, B.foo is identical to
A.foo, so the call would succeed. In the new system, B.foo is
marked as a method requiring a B instance, and a C is not a B, so
the call fails.
- Binary compatibility with old extensions is not guaranteed. We'll
tighten this in future releases. I also very much doubt that
extensions based on Jim Fulton's ExtensionClass will work --
although I encourage folks to try this to see how much breaks, so we
can hopefully fix this for 2.2a2. While the ultimate goal of PEP
253 is to do away with ExtensionClass, I believe that ExtensionClass
should still work in 2.2, breaking it in 2.3.
I should also note that PEP 254 will probably remain unimplemented for
now, since it would create way more incompatibilities. I promise to
reopen it for Python 2.3.
--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