[Python-Dev] yield without future statement?

Guido van Rossum guido@python.org
Mon, 13 Aug 2001 16:47:55 -0400


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