On Sun, 2011-08-28 at 10:10 -0700, Guido van Rossum wrote:

The main difference between experimental and regular status in the
stdlib is that for experimental modules we reserve the right to make
incompatible changes in subsequent versions (possibly even in bugfix
releases, although that's worth a separate discussion).

An experimental feature in the stdlib also signals a certain
commitment from the core developers. We shouldn't use experimental as
a dumping ground for random stuff; that's what PyPI is for. We should
use experimental within the context of the stdlib.

It looks to me, that Importing from __future__ can do things that a regular import can't do, like add or change core syntax. So they tend to be python core features rather than library features.

The term __experimental__ may have differing expectations to different people and may be a little too broad.

I like __future__ for *early* core changes, and __lib_future__ or __sdtlib_future__, for early stdlib features.

I describe them as "early" because they either aren't quite ready for the current release cycle or they are waiting for something else to be depreciated or done before they can included.

I think It makes sense to split core and library future features this way because usually, future core features are built into the core, while a future standard library module can be imported from the disk.

Cheers,
Ron