[Python-ideas] Experimental package
tjreedy at udel.edu
Sat Mar 2 23:23:44 CET 2013
On 3/2/2013 4:04 PM, João Bernardo wrote:
> I was thinking about "yield from" and how many times I wanted to use the
> feature, but because of backward compatibilities, I couldn't.
Load 3.3 and use it. If you need an external 3.x library that will not
run on 3.3 yet, 6 months after release, bug the author. If you want your
code to run on earlier releases, select new and old versions with 'if
> It's sad that it may take possibly 5 or 10 years to see this statement
> being used in real programs...
But it will not take that long. 'yield from' plays an essential role in
Guido's new asynch package (code name: Tulip), which he hope will be
ready for 3.4. It will probably also run in 3.3, but that will be it.
People who want to use it will have to upgrade.
> I don't know if this was proposed before, but why can't Python have an
> "__experimental__" magic package for this kind of stuff?
Experimental modules and packages are usually available on PyPI. I think
experimental syntax that might be removed is a BAD idea. Getting rid of
things that were not experimental is bad enough.
> The __future__ thing already add features that are sure to be included
> on a future release,
Actually, the feature is included in the release that adds the
__future__ option. It is just not included *by default*. This is only
done when the new feature changes the meaning of legal existing code.
(Take a look at the 2.x examples*.) So the __future__ import allows the
old deprecated meaning to still be used while simultaneously making the
great new meaning available *immediately* to those willing to explicitly
disable the old meaning.
When 'yield from' was ready to be added, it was just added because
'yield' and 'from' were already keywords and 'yield from' was previously
a syntax error. We have not yet added any new future imports in 3.x. The
existing future imports from 2.x have no effect since 3.0 incorporated
all existing __future__ changes.
* There are only 7 future features. Generaters required a future
transition period because making 'yield' a keyword invalidated uses of
'yield' as an identifier (as would be common in finance software).
> Note that*the idea is not for people to use experimental features* when
> they appear, but to have a fallback for when the feature becomes official!
The details of a new feature are not fixed until they are fixed, when it
becomes official be being added. Even future imports are not backported
as bugfix releases do not get new features.
Terry Jan Reedy
More information about the Python-ideas