I was thinking about "yield from" and how many times I wanted to use the feature, but because of backward compatibilities, I couldn't. It's sad that it may take possibly 5 or 10 years to see this statement being used in real programs... The PEP 380<http://www.python.org/dev/peps/pep-0380/>was proposed while Python3.1 was still alpha or beta and it took two and a half years to be accepted, but once it was, Python3.2 was already released. I don't know if this was proposed before, but why can't Python have an "__experimental__" magic package for this kind of stuff? The __future__ thing already add features that are sure to be included on a future release, but why those that *may *become official have to suffer that much? What if an experimental feature becomes rejected? from __experimental__ import foo DeprecationWarning: "foo" will be removed on Python 4.0 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! As side effect, the feature will be more tested and become more mature when released. -- João Bernardo
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
João Bernardo 2013/3/2 Terry Reedy <tjreedy@udel.edu>
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.
If something is experimental, people are advised against using it for production. The idea here is to make forward compatibility possible.
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()
"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@gmail.com> wrote:
On Mar 2, 2013, at 17:00, João Bernardo <jbvsmo@gmail.com> wrote:
Is there really that much need to support 3.0? I write stuff all the time that requires 2.6, 2.7, or 3.2 or later, and I've had many people asking for 2.5, but not a single request for 3.1 or 3.0. Is that not typical?
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.
But there wasn't a working version, partial or otherwise, to add at the time. And even if the usual rule of "no backports to bug fix releases" we're suspended, do you really have users who would gladly upgrade to a later 3.1, but can't upgrade to a later 3.x? In my experience, people who stick with an old version are doing it because "that's the version that comes with CentOS x.y" or similar. Are there any important OS/distro extended service releases that come with 3.1? Meanwhile, if you need a workaround, it's not that hard. I've got code that does this today: I have my nifty 3.3 module, and the fallback is in a separate module, so I can "import foo33 as foo" or "import foo26 as foo" as appropriate.
Ubuntu LTS. Also when CentOS/RedHat start using Py3k, they will probably choose the oldest possible release like they always do with everything...
Because the PEP hasn't been accepted at the time and there was no way to add experimental stuff to the language.
If I wanted to write a lot of boring duplicated code, I ought to use Java instead. If I can't write it in a single code base (either using "2to3" or "six" or similar) I don't write it.
On Mar 3, 2013, at 7:42, João Bernardo <jbvsmo@gmail.com> wrote:
Meanwhile, if you need a workaround, it's not that hard. I've got code that does this today: I have my nifty 3.3 module, and the fallback is in a separate module, so I can "import foo33 as foo" or "import foo26 as foo" as appropriate.
If I wanted to write a lot of boring duplicated code, I ought to use Java instead. If I can't write it in a single code base (either using "2to3" or "six" or similar) I don't write it.
Most of the time, you can just use "for x in foo: yield foo", so you really don't need a workaround. But when that's not appropriate (e.g., for performance reasons), you generally have to implement things pretty differently anyway. You're already writing the code twice; fooling yourself into thinking otherwise doesn't help. More importantly, you don't have to duplicate the entire module. Factor out the part that's version dependent, and create two tiny modules for the two different implementations. It ends up being two more lines of code, one level less indented, and more readable. Where's the harm?
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
João Bernardo 2013/3/2 Terry Reedy <tjreedy@udel.edu>
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.
If something is experimental, people are advised against using it for production. The idea here is to make forward compatibility possible.
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()
"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@gmail.com> wrote:
On Mar 2, 2013, at 17:00, João Bernardo <jbvsmo@gmail.com> wrote:
Is there really that much need to support 3.0? I write stuff all the time that requires 2.6, 2.7, or 3.2 or later, and I've had many people asking for 2.5, but not a single request for 3.1 or 3.0. Is that not typical?
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.
But there wasn't a working version, partial or otherwise, to add at the time. And even if the usual rule of "no backports to bug fix releases" we're suspended, do you really have users who would gladly upgrade to a later 3.1, but can't upgrade to a later 3.x? In my experience, people who stick with an old version are doing it because "that's the version that comes with CentOS x.y" or similar. Are there any important OS/distro extended service releases that come with 3.1? Meanwhile, if you need a workaround, it's not that hard. I've got code that does this today: I have my nifty 3.3 module, and the fallback is in a separate module, so I can "import foo33 as foo" or "import foo26 as foo" as appropriate.
Ubuntu LTS. Also when CentOS/RedHat start using Py3k, they will probably choose the oldest possible release like they always do with everything...
Because the PEP hasn't been accepted at the time and there was no way to add experimental stuff to the language.
If I wanted to write a lot of boring duplicated code, I ought to use Java instead. If I can't write it in a single code base (either using "2to3" or "six" or similar) I don't write it.
On Mar 3, 2013, at 7:42, João Bernardo <jbvsmo@gmail.com> wrote:
Meanwhile, if you need a workaround, it's not that hard. I've got code that does this today: I have my nifty 3.3 module, and the fallback is in a separate module, so I can "import foo33 as foo" or "import foo26 as foo" as appropriate.
If I wanted to write a lot of boring duplicated code, I ought to use Java instead. If I can't write it in a single code base (either using "2to3" or "six" or similar) I don't write it.
Most of the time, you can just use "for x in foo: yield foo", so you really don't need a workaround. But when that's not appropriate (e.g., for performance reasons), you generally have to implement things pretty differently anyway. You're already writing the code twice; fooling yourself into thinking otherwise doesn't help. More importantly, you don't have to duplicate the entire module. Factor out the part that's version dependent, and create two tiny modules for the two different implementations. It ends up being two more lines of code, one level less indented, and more readable. Where's the harm?
participants (5)
-
Andrew Barnert -
João Bernardo -
MRAB -
Nick Coghlan -
Terry Reedy