[Python-Dev] Heads up: Python 2.2a1 to be released from descr-branch

[Guido van Rossum]

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/)