Add from __experimental__ import bla [was: Should we move to replace re with regex?]
In the thread about replacing re with regex someone mentioned adding to __future__ which isnt a great idea as future APIs are already solidified, they just live there to give developer time to adapt their code. The idea of a __experimental__ area is good for any pep's or stliib additions that are somewhat controversial (API isnt agreed on, code may take a while to integrate properly, developer wants some time to hash out any edge case bugs or API clarifications that may come up in large scale testing, etc). __experimental__ should emit a warning on import that says anything in here may change or be removed at any time and should not be used in stable code. __experimental__ features should behave the same as __future__ in that they can add new keywords or semantics to the existing language __experimental__ features can move directly to the stlib or builtins if they do not add new keywords and/or are backwards compatible with the feature they are replacing. Otherwise they move into __future__ for how ever many releases are deemed reasonable time for developers to adapt their code.
Le samedi 27 août 2011 21:57:26, Dj Gilcrease a écrit :
__experimental__ does already exist, it's the Python Package Index (PyPI) ! http://pypi.python.org/pypi You can write Python extensions in C and distribute them on the PyPI. I did that when my patch to display the Python backtrace on a crash was "rejected" (not included in Python 3.2, just before the release). It was a great idea, because I had more time to change the API (read the history of the faulthandler module on PyPI: the API changed 5 times since the first public version on PyPI...) and the module is now available for Python 2.5 - 3.2, not only for Python 3.3. Remember that the API of a module added to CPython is frozen. You will have to wait something like 18 months until the next CPython release to change anything (add a new function, remove an old/useless function, etc.). Seriously, it's not a good idea to add a young module into Python before its API is well defined and stable. The Linux kernel has "staging" drivers. It's different because there is a new release of the Linux kernel each two months (instead of 18 months for CPython). The policy for the API is also different: the kernel has no stable API, whereas the Python API cannot be changed in minor release (x.y.Z). http://www.kroah.com/log/linux/stable_api_nonsense.html http://www.mjmwired.net/kernel/Documentation/stable_api_nonsense.txt Victor
On 07:57 pm, digitalxero@gmail.com wrote:
Hi Dj, As a developer of Python libraries and applications, I don't see how this would make my life easier. A warning in a module docstring that a module may not be long-lived if it is not well received tells me just as much as a warning emitted at runtime. And a warning emitted at runtime is likely to scare my users into thinking something is broken, leading to spurious or misleading bug reports. There also does not appear to be general consensus that modules should be added to stdlib if they are not widely used and demanded, so I don't know when a module would be added to __experimental__, anyway. The normal deprecation procedures (rarely used as they are) seem to cover this, anyway. Adding a new namespace separate from __future__ also just gives me another thing to remember. Was the feature added to __experimental__ or __future__? Also, it seems even less common that language features are added on an experimental basis. When a language feature (new syntax or semantics) goes in to the language, it is there for a long, long time. If new features are added first to __experimental__ and then to __future__ or the non-__experimental__ stdlib namespace, then I just have to update all my code to keep using it. So I'm guaranteed extra work whether the feature is successful and is adopted or if it fails and is later removed. I'd rather not have to do the extra work in the success case, at least, which is what the existing add-it-and-then-maybe -(but-probably-not-)deprecate it approach gives me. Jean-Paul
Le samedi 27 août 2011 21:57:26, Dj Gilcrease a écrit :
__experimental__ does already exist, it's the Python Package Index (PyPI) ! http://pypi.python.org/pypi You can write Python extensions in C and distribute them on the PyPI. I did that when my patch to display the Python backtrace on a crash was "rejected" (not included in Python 3.2, just before the release). It was a great idea, because I had more time to change the API (read the history of the faulthandler module on PyPI: the API changed 5 times since the first public version on PyPI...) and the module is now available for Python 2.5 - 3.2, not only for Python 3.3. Remember that the API of a module added to CPython is frozen. You will have to wait something like 18 months until the next CPython release to change anything (add a new function, remove an old/useless function, etc.). Seriously, it's not a good idea to add a young module into Python before its API is well defined and stable. The Linux kernel has "staging" drivers. It's different because there is a new release of the Linux kernel each two months (instead of 18 months for CPython). The policy for the API is also different: the kernel has no stable API, whereas the Python API cannot be changed in minor release (x.y.Z). http://www.kroah.com/log/linux/stable_api_nonsense.html http://www.mjmwired.net/kernel/Documentation/stable_api_nonsense.txt Victor
On 07:57 pm, digitalxero@gmail.com wrote:
Hi Dj, As a developer of Python libraries and applications, I don't see how this would make my life easier. A warning in a module docstring that a module may not be long-lived if it is not well received tells me just as much as a warning emitted at runtime. And a warning emitted at runtime is likely to scare my users into thinking something is broken, leading to spurious or misleading bug reports. There also does not appear to be general consensus that modules should be added to stdlib if they are not widely used and demanded, so I don't know when a module would be added to __experimental__, anyway. The normal deprecation procedures (rarely used as they are) seem to cover this, anyway. Adding a new namespace separate from __future__ also just gives me another thing to remember. Was the feature added to __experimental__ or __future__? Also, it seems even less common that language features are added on an experimental basis. When a language feature (new syntax or semantics) goes in to the language, it is there for a long, long time. If new features are added first to __experimental__ and then to __future__ or the non-__experimental__ stdlib namespace, then I just have to update all my code to keep using it. So I'm guaranteed extra work whether the feature is successful and is adopted or if it fails and is later removed. I'd rather not have to do the extra work in the success case, at least, which is what the existing add-it-and-then-maybe -(but-probably-not-)deprecate it approach gives me. Jean-Paul
participants (3)
-
Dj Gilcrease -
exarkun＠twistedmatrix.com -
Victor Stinner