On Mon, Aug 29, 2011 at 4:14 AM, Nick Coghlan
<ncoghlan@gmail.com> wrote:
<snip/>
The essential idea here is to be able to add a feature, but flag the
API as potentially unstable for an entire release cycle before
promising to maintain the API in perpetuity.
<snip/>
No, that's *not* what __future__ means. __future__ changes are exactly
what will become default behaviour in a future version - they aren't
going to change, so code that uses them won't need to change. What may
need changing in the case of __future__ is *old* code - the only
reason we use a __future__ flag is when old code might break.
The semantics of the new marker package would be to indicate that
stuff is a little undercooked, but we've decided that it won't get
enough exposure through PyPI (either through being too small to
overcome NIH syndrome or else too closely coupled to a specific
version of the interpreter). That's a completely different meaning, so
we shouldn't reuse the same word.
Unlike __future__ the API is unstable and therefore code that works with today's __experimental__ may fail tomorrow. If the API changes in an incompatible way, we would probably prefer that the import fail rather than succeed with random results. Therefore, I would propose a mechanism to support this, perhaps something like
which means import the regex module version 2, 3 or 4. A later version will be imported only if it is an expansion, i.e., compatible with all previous APIs and differs only in containing new features. If the version set is omitted from the import it's treated as {1} so that dealing with this is only necessary for those modules which do change in incompatible ways.
In general, checking for specific capabilities rather than version numbers is more robust but in this case, perhaps multiple versions of experimental APIs will be discouraged making that less necessary. But we could allow strings specifying required features in the version set. Note that the reason for allowing import with more than one version number is to handle the case when a new version is available but the differences are in parts of the API that don't impact the application.
--- Bruce