[Python-ideas] Add from __experimental__ import bla [was: Should we move to replace re with regex?]

[Bruce Leban]

On Mon, Aug 29, 2011 at 4:14 AM, Nick Coghlan <ncoghlan at 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

from __experimental__ import regex {2,3,4} as re


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
Follow me: http://www.twitter.com/Vroo http://www.vroospeak.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20110829/ed631f73/attachment.html>