(http://trentmick.blogspot.com/2010/02/other-python-vms-upcoming-python.html)
Note that this was just from the first 15 minutes or so...
Some quick notes about the coming plans by the "other" Python implementations from today's Python Language Summit at PyCon 2010:
- IronPython:
- plan is to do Python 2.7 first, focus for this year
- python 3.2 for the end of next year hopefully
- other work on IDE stuff
- Pynie (i.e. Parrot) -- Allison Randall:
- about 4 major features away from pure Python syntax (did dicts last night)
- targetting py3k repo and test suite: should be on track for python 3.2
- Jython:
- plan to target 2.6 (b/c 2to3 depends on 2.6)
- temporarily skip 2.7 and target 3.x (probably 3.2)
- then if 3.x adoption isn't fully there, then go back and add Python 2.7
- will require JDK 2.7 for Python 3 support (b/c of new support for dynamic languages)
- PyPy (Holger):
- plan is Benjamin will port to Python 2.7 in the summer
- only have slight deviations from CPython: idea is to merge back with CPython so don't have deviations. Typcically 1 or 2 line changes in ~25 modules.
Trent
My notes from the session I led:
+ argparse
- Same issues brought up.
+ Hg transition
- Just updated everyone; Dirkjan said everything I did in his email update.
+ Stdlib breakout
- Mentioned; nothing planned beyond a PEP at some point.
+ Extension module policy
- If you write C code just for performance, you must provide a pure Python version (and both are tested). - When the stdlib is broken out, say ctypes-based versions are possible as fallback implementations. - Non-CPython VMs should contribute their pure Python implementations of modules back to the stdlib (e.g. datetime).
+ Proposing language changes
- Need thorough dev docs. - People should vet ideas first, then PEP and code vetting, then submit for consideration.
+ Off-topic discussion
- Need a "languishing" state in the tracker. - Probably should have a paid admin to help keep things such as the Roundup tracker in tip-top shape to take load off of people like Martin (e.g. bug fixes, new features, etc).
On Thu, Feb 18, 2010 at 16:56, Trent Mick trentm@activestate.com wrote:
(http://trentmick.blogspot.com/2010/02/other-python-vms-upcoming-python.html)
Note that this was just from the first 15 minutes or so...
Some quick notes about the coming plans by the "other" Python implementations from today's Python Language Summit at PyCon 2010:
- IronPython:
- plan is to do Python 2.7 first, focus for this year - python 3.2 for the end of next year hopefully - other work on IDE stuff
- Pynie (i.e. Parrot) -- Allison Randall:
- about 4 major features away from pure Python syntax (did dicts last night) - targetting py3k repo and test suite: should be on track for python 3.2
- Jython:
- plan to target 2.6 (b/c 2to3 depends on 2.6) - temporarily skip 2.7 and target 3.x (probably 3.2) - then if 3.x adoption isn't fully there, then go back and add Python 2.7 - will require JDK 2.7 for Python 3 support (b/c of new support for dynamic languages)
- PyPy (Holger):
- plan is Benjamin will port to Python 2.7 in the summer - only have slight deviations from CPython: idea is to merge back with CPython so don't have deviations. Typcically 1 or 2 line changes in ~25 modules.
Trent
-- Trent Mick trentm at activestate.com http://trentm.com/blog/ _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/brett%40python.org
On Fri, Feb 19, 2010 at 7:50 AM, Brett Cannon brett@python.org wrote:
My notes from the session I led:
- argparse
- Same issues brought up.
For those of us not at PyCon, what were the issues?
Steve
Steven Bethard wrote:
On Fri, Feb 19, 2010 at 7:50 AM, Brett Cannon brett@python.org wrote:
My notes from the session I led:
argparse
- Same issues brought up.
For those of us not at PyCon, what were the issues?
I think they were all related to deprecation of optparse, not anything to do with argparse itself. I don't recall any specific decision on deprecation, but my sense was that optparse will be around for a long, long time. There was also a quick discussion on maybe implementing optparse using argparse, then getting rid of the existing optparse. Maybe you can comment on that.
Eric.
On Sun, Feb 21, 2010 at 4:30 AM, Eric Smith eric@trueblade.com wrote:
Steven Bethard wrote:
On Fri, Feb 19, 2010 at 7:50 AM, Brett Cannon brett@python.org wrote:
My notes from the session I led:
- argparse
- Same issues brought up.
For those of us not at PyCon, what were the issues?
I think they were all related to deprecation of optparse, not anything to do with argparse itself. I don't recall any specific decision on deprecation, but my sense was that optparse will be around for a long, long time. There was also a quick discussion on maybe implementing optparse using argparse, then getting rid of the existing optparse. Maybe you can comment on that.
Maybe the best thing is to make optparse *silently* deprecated, with a big hint at the top of its documentation telling new users to use argparse instead, but otherwise leaving it in indefinitely for the benefit of the many existing users.
On 21/02/2010 08:45, Guido van Rossum wrote:
On Sun, Feb 21, 2010 at 4:30 AM, Eric Smitheric@trueblade.com wrote:
Steven Bethard wrote:
On Fri, Feb 19, 2010 at 7:50 AM, Brett Cannonbrett@python.org wrote:
My notes from the session I led:
argparse
- Same issues brought up.
For those of us not at PyCon, what were the issues?
I think they were all related to deprecation of optparse, not anything to do with argparse itself. I don't recall any specific decision on deprecation, but my sense was that optparse will be around for a long, long time. There was also a quick discussion on maybe implementing optparse using argparse, then getting rid of the existing optparse. Maybe you can comment on that.
Maybe the best thing is to make optparse *silently* deprecated, with a big hint at the top of its documentation telling new users to use argparse instead, but otherwise leaving it in indefinitely for the benefit of the many existing users.
+1
argparse is a great step forward but there is no need to disrupt existing users - just direct new users to the place they should go.
We've done that with a couple of the commonly used but extraneous methods in unittest - deprecation via documentation.
Michael
Guido> Maybe the best thing is to make optparse *silently* deprecated, Guido> with a big hint at the top of its documentation telling new users Guido> to use argparse instead, but otherwise leaving it in indefinitely Guido> for the benefit of the many existing users.
Would a 2to3 fixer be possible?
S
2010/2/21 skip@pobox.com:
Guido> Maybe the best thing is to make optparse *silently* deprecated, Guido> with a big hint at the top of its documentation telling new users Guido> to use argparse instead, but otherwise leaving it in indefinitely Guido> for the benefit of the many existing users.
Would a 2to3 fixer be possible?
I don't think so. There would be subtle semantic difference 2to3 couldn't detect.
Thanks all for the updates. Sorry I can't make it to PyCon this year!
On Sun, Feb 21, 2010 at 1:30 AM, Eric Smith eric@trueblade.com wrote:
There was also a quick discussion on maybe implementing optparse using argparse, then getting rid of the existing optparse.
I think the PEP pretty much already covers why this isn't possible. See: http://www.python.org/dev/peps/pep-0389/#why-isn-t-the-functionality-just-be... Some of the reasons this would be really difficult include optparse's baroque extension API and the fact that it exposes the internals of its parsing algorithm, which means it's impossible to use a better algorithm that has a different implementation.
On Sun, Feb 21, 2010 at 6:19 AM, skip@pobox.com wrote:
Would a 2to3 fixer be possible?
On Sun, Feb 21, 2010 at 6:29 AM, Benjamin Peterson benjamin@python.org wrote:
I don't think so. There would be subtle semantic difference 2to3 couldn't detect.
Yep, that's probably right. And I don't know how I'd write the fixers for anyone who was using the old optparse extension API.
On Sun, Feb 21, 2010 at 5:45 AM, Guido van Rossum guido@python.org wrote:
Maybe the best thing is to make optparse *silently* deprecated, with a big hint at the top of its documentation telling new users to use argparse instead, but otherwise leaving it in indefinitely for the benefit of the many existing users.
So basically do what the PEP does now, except don't remove optparse in Python 3.5? For reference, the current proposal is:
* Python 2.7+ and 3.2+ -- The following note will be added to the optparse documentation: The optparse module is deprecated and will not be developed further; development will continue with the argparse module. * Python 2.7+ -- If the Python 3 compatibility flag, -3, is provided at the command line, then importing optparse will issue a DeprecationWarning. Otherwise no warnings will be issued. * Python 3.2 (estimated Jun 2010) -- Importing optparse will issue a PendingDeprecationWarning, which is not displayed by default. * Python 3.3 (estimated Jan 2012) -- Importing optparse will issue a PendingDeprecationWarning, which is not displayed by default. * Python 3.4 (estimated Jun 2013) -- Importing optparse will issue a DeprecationWarning, which is displayed by default. * Python 3.5 (estimated Jan 2015) -- The optparse module will be removed.
So if I drop that last bullet, is the PEP ready for pronouncement?
Steve
On Sun, Feb 21, 2010 at 1:26 PM, Steven Bethard steven.bethard@gmail.com wrote:
On Sun, Feb 21, 2010 at 5:45 AM, Guido van Rossum guido@python.org wrote:
Maybe the best thing is to make optparse *silently* deprecated, with a big hint at the top of its documentation telling new users to use argparse instead, but otherwise leaving it in indefinitely for the benefit of the many existing users.
So basically do what the PEP does now, except don't remove optparse in Python 3.5? For reference, the current proposal is:
- Python 2.7+ and 3.2+ -- The following note will be added to the
optparse documentation: The optparse module is deprecated and will not be developed further; development will continue with the argparse module.
- Python 2.7+ -- If the Python 3 compatibility flag, -3, is provided
at the command line, then importing optparse will issue a DeprecationWarning. Otherwise no warnings will be issued.
- Python 3.2 (estimated Jun 2010) -- Importing optparse will issue a
PendingDeprecationWarning, which is not displayed by default.
- Python 3.3 (estimated Jan 2012) -- Importing optparse will issue a
PendingDeprecationWarning, which is not displayed by default.
- Python 3.4 (estimated Jun 2013) -- Importing optparse will issue a
DeprecationWarning, which is displayed by default.
- Python 3.5 (estimated Jan 2015) -- The optparse module will be removed.
So if I drop that last bullet, is the PEP ready for pronouncement?
Drop the last two bullets and it's a deal. (OTOH AFAIK we changed DeprecationWarning so it is *not* displayed by default.)
On Sun, Feb 21, 2010 at 10:31 AM, Guido van Rossum guido@python.org wrote:
On Sun, Feb 21, 2010 at 1:26 PM, Steven Bethard steven.bethard@gmail.com wrote:
So basically do what the PEP does now, except don't remove optparse in Python 3.5? For reference, the current proposal is:
- Python 2.7+ and 3.2+ -- The following note will be added to the
optparse documentation: The optparse module is deprecated and will not be developed further; development will continue with the argparse module.
- Python 2.7+ -- If the Python 3 compatibility flag, -3, is provided
at the command line, then importing optparse will issue a DeprecationWarning. Otherwise no warnings will be issued.
- Python 3.2 (estimated Jun 2010) -- Importing optparse will issue a
PendingDeprecationWarning, which is not displayed by default.
- Python 3.3 (estimated Jan 2012) -- Importing optparse will issue a
PendingDeprecationWarning, which is not displayed by default.
- Python 3.4 (estimated Jun 2013) -- Importing optparse will issue a
DeprecationWarning, which is displayed by default.
- Python 3.5 (estimated Jan 2015) -- The optparse module will be removed.
So if I drop that last bullet, is the PEP ready for pronouncement?
Drop the last two bullets and it's a deal. (OTOH AFAIK we changed DeprecationWarning so it is *not* displayed by default.)
Done:
http://www.python.org/dev/peps/pep-0389/#deprecation-of-optparse
Thank you, and thanks to all who helped in the discussion of this PEP!
My plan is to make a final external release of argparse (1.1) fixing some current issues, and then merge that into the Python repository. I should be able to get this done before Python 2.7 alpha 4 on 2010-03-06.
Steve
On Sun, Feb 21, 2010 at 13:31, Guido van Rossum guido@python.org wrote:
On Sun, Feb 21, 2010 at 1:26 PM, Steven Bethard steven.bethard@gmail.com wrote:
On Sun, Feb 21, 2010 at 5:45 AM, Guido van Rossum guido@python.org
wrote:
Maybe the best thing is to make optparse *silently* deprecated, with a big hint at the top of its documentation telling new users to use argparse instead, but otherwise leaving it in indefinitely for the benefit of the many existing users.
So basically do what the PEP does now, except don't remove optparse in Python 3.5? For reference, the current proposal is:
- Python 2.7+ and 3.2+ -- The following note will be added to the
optparse documentation: The optparse module is deprecated and will not be developed further; development will continue with the argparse module.
- Python 2.7+ -- If the Python 3 compatibility flag, -3, is provided
at the command line, then importing optparse will issue a DeprecationWarning. Otherwise no warnings will be issued.
- Python 3.2 (estimated Jun 2010) -- Importing optparse will issue a
PendingDeprecationWarning, which is not displayed by default.
- Python 3.3 (estimated Jan 2012) -- Importing optparse will issue a
PendingDeprecationWarning, which is not displayed by default.
- Python 3.4 (estimated Jun 2013) -- Importing optparse will issue a
DeprecationWarning, which is displayed by default.
- Python 3.5 (estimated Jan 2015) -- The optparse module will be removed.
So if I drop that last bullet, is the PEP ready for pronouncement?
Drop the last two bullets and it's a deal. (OTOH AFAIK we changed DeprecationWarning so it is *not* displayed by default.
Yes, DeprecationWarning is now silent under Python 2.7 and 3.1 so a DeprecationWarning would only pop up if developers exposed DeprecationWarning. But if the module is not about to be removed in 3.x then I think regardless of the silence of both warnings it should stay PendingDeprecationWarning.
-Brett
Brett Cannon wrote:
Yes, DeprecationWarning is now silent under Python 2.7 and 3.1 so a DeprecationWarning would only pop up if developers exposed DeprecationWarning. But if the module is not about to be removed in 3.x then I think regardless of the silence of both warnings it should stay PendingDeprecationWarning.
But if we're never going to change it to a DeprecationWarning, it's not pending. So why not just change the docs and not add any warnings to the code?
Eric.
On Sun, Feb 21, 2010 at 14:46, Eric Smith eric@trueblade.com wrote:
Brett Cannon wrote:
Yes, DeprecationWarning is now silent under Python 2.7 and 3.1 so a DeprecationWarning would only pop up if developers exposed DeprecationWarning. But if the module is not about to be removed in 3.x then I think regardless of the silence of both warnings it should stay PendingDeprecationWarning.
But if we're never going to change it to a DeprecationWarning, it's not pending.
Well, it's pending until Py4K, so it's accurate, we just don't know yet when it will change to an actual deprecation. =)
So why not just change the docs and not add any warnings to the code?
Could, but the code will go away some day and not everyone will read the docs to realize that they might want to upgrade their code if they care to use the shiniest thing in the standard library.
-Brett
Brett Cannon wrote:
Could, but the code will go away some day and not everyone will read the docs to realize that they might want to upgrade their code if they care to use the shiniest thing in the standard library.
I agree with Brett here - PendingDeprecationWarning for "there's a better option available, this approach is probably going to go away some day, but you're in no imminent danger of that happening any time soon". DeprecationWarning is significantly stronger, saying "this will go away some time within the next few years".
The softest version (documentation warnings only) doesn't really apply in this case - optparse will almost certainly become a PyPI external package some day, even if that day is a decade or more from now.
Cheers, Nick.
-
Benjamin Peterson -
Brett Cannon -
Eric Smith -
Guido van Rossum -
Michael Foord -
Nick Coghlan -
skip＠pobox.com -
Steven Bethard -
Trent Mick