some notes from the first part of the lang summit
(http://trentmick.blogspot.com/2010/02/other-python-vms-upcoming-python.html) Note that this was just from the first 15 minutes or so...
Trent -- Trent Mick trentm at activestate.com http://trentm.com/blog/
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:
Steven Bethard wrote:
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:
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. -- --Guido van Rossum (python.org/~guido)
On 21/02/2010 08:45, Guido van Rossum wrote:
+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 -- http://www.ironpythoninaction.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? S
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:
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:
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 -- Where did you get that preposterous hypothesis? Did Steve tell you that? --- The Hiphopopotamus
On Sun, Feb 21, 2010 at 10:31 AM, Guido van Rossum <guido@python.org> wrote:
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 -- Where did you get that preposterous hypothesis? Did Steve tell you that? --- The Hiphopopotamus
On Sun, Feb 21, 2010 at 13:31, Guido van Rossum <guido@python.org> 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. -Brett
On Sun, Feb 21, 2010 at 14:46, Eric Smith <eric@trueblade.com> wrote:
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:
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. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------
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:
Steven Bethard wrote:
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:
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. -- --Guido van Rossum (python.org/~guido)
On 21/02/2010 08:45, Guido van Rossum wrote:
+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 -- http://www.ironpythoninaction.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? S
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:
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:
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 -- Where did you get that preposterous hypothesis? Did Steve tell you that? --- The Hiphopopotamus
On Sun, Feb 21, 2010 at 10:31 AM, Guido van Rossum <guido@python.org> wrote:
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 -- Where did you get that preposterous hypothesis? Did Steve tell you that? --- The Hiphopopotamus
On Sun, Feb 21, 2010 at 13:31, Guido van Rossum <guido@python.org> 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. -Brett
On Sun, Feb 21, 2010 at 14:46, Eric Smith <eric@trueblade.com> wrote:
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:
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. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------
participants (9)
-
Benjamin Peterson -
Brett Cannon -
Eric Smith -
Guido van Rossum -
Michael Foord -
Nick Coghlan -
skip＠pobox.com -
Steven Bethard -
Trent Mick