On Mon, Dec 14, 2009 at 3:46 PM, Nick Coghlan <ncogh...@gmail.com> wrote:
> Steven Bethard wrote:
>> On Mon, Dec 14, 2009 at 11:12 AM, Olemis Lang <ole...@gmail.com> wrote:
>>> I thought that one of the following approaches would be considered :
>>>
>>> 1 - let optparse remain in stdlib (as is or not ...)
>>> 2 - re-implement optparse (i.e. a module having the same name ;o) using
>>> argparse
>>>
>>> isn't it ?
>>
>> Please read the PEP if you haven't, particularly the "Why isn't the
>> functionality just being added to optparse?" section. I don't believe
>> it is sensible to re-implement all of optparse.
>>
[...]
>>
>> For what it's worth, I'm still not sure it's a good idea, for exactly
>> the reason Ian points out - "having another class like OptionParser
>> also feels like backward compatibility cruft".
>
> People also need to remember the very conservative deprecation path for
> optparse proposed in the PEP - never deprecated in 2.x,
So, I don't get it . What's the difference between this and the first
option I mentioned above ? I am probably missing the obvious but if
optparse will be «never deprecated in 2.x» then what's gonna happen ?
The only options I see are mentioned above (and I thought it was the
first one ;o) :
- If (1) is the right one then -0 for considering backwards compatibility
- If (2) is the right one then IMO, +1 for adding «further backwards
compatibility cruft» in a separate module and remove it in Python 3.5
--
Regards,
Olemis.
Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/
Featured article:
Looking for a technique to create flexible, graphical dashboards ...
- http://feedproxy.google.com/~r/TracGViz-full/~3/r7Zcyrg1n3U/019aa74e7095d047
_______________________________________________
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/archive%40mail-archive.com
