[Python-ideas] Experimental package

Nick Coghlan ncoghlan at gmail.com
Sun Mar 3 14:13:49 CET 2013


"yield from" is just syntactic sugar for stuff you can already effectively
do with a few appropriate helper functions and an event loop - otherwise
Twisted's inline deferreds wouldn't work.

The exclusion of PEP 380 from 3.2 was due to the moratorium imposed on
language changes in 3.2, to give the broader Python community a chance to
catch up with the Python 3 transition.

Cheers,
Nick.
On 3 Mar 2013 11:01, "João Bernardo" <jbvsmo at gmail.com> wrote:

>
>
> João Bernardo
>
>
> 2013/3/2 Terry Reedy <tjreedy at udel.edu>
>
>> 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.
>>
>>
> Writing new stuff for the stdlib doesn't need to be compatible with older
> python versions... I develop on 3.3 but need to support 3.1 or 3.0.
>
>
>>  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.
>>
>>
> If something is experimental, people are advised against using it for
> production. The idea here is to make forward compatibility possible.
>
>
>> 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.
>>
>>
> It is not about backporting features. Think about the "with" statement:
>
> It was added on version 2.5 (not as default) then it changed on version
> 2.7 to allow multiple contexts.
> You can write code compatible with 2.5, 2.6 and 2.7 by just restricting
> yourself to use only one context per block.
>
> Now, if you had a partial version of "yield from" syntax on 3.1 that could
> solve 50% of the problems of the current syntax, it would be used a lot by
> now.
> The current problem is that on older versions, using it gives *SyntaxError
> *that cannot be bypassed by a try...except... statement!
>
> Having the syntax available makes possible to do:
>
>     if sys.version_info >= (3,3):
>         yield from foo()
>     else:
>         bar()
>
>
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20130303/f2c4b423/attachment.html>


More information about the Python-ideas mailing list