[Python-ideas] Experimental package

Terry Reedy 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 
version....'/

> 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 mailing list