Re: [Python-Dev] Pronouncement on PEP 389: argparse?

[Anand Balachandran Pillai]

On Sun, Dec 27, 2009 at 11:21 PM, anatoly techtonik wrote:

> On Tue, Dec 15, 2009 at 12:37 AM, Steven Bethard
>  wrote:
> >
> > If you're only concerned about 2.X, then yes, optparse will *never* be
> > removed from 2.X. There will be a deprecation note in the 2.X
> > documentation but deprecation warnings will only be issued when the -3
> > flag is specified. Please see the "Deprecation of optparse" section of
> > the PEP:
> >
> > http://www.python.org/dev/peps/pep-0389/#deprecation-of-optparse
>
> I do not think that optparse should be deprecated at. It is good at
> what it does and its limitations make its starting point less
> confusing for people with different backgrounds that Python.
>
>
 Ref http://www.python.org/dev/peps/pep-0389/#deprecation-of-optparse .

 Considering that optparse will be deprecated like 5 years from now.
 I think this point is moot. The deprecation strategy IMHO is
 perhaps way too conservative. Maybe it should be deprecated
 faster ;)




-- 
--Anand
___
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

Re: [Python-Dev] Pronouncement on PEP 389: argparse?

[Daniel Fetchinson]

>> If you're only concerned about 2.X, then yes, optparse will *never* be
>> removed from 2.X. There will be a deprecation note in the 2.X
>> documentation but deprecation warnings will only be issued when the -3
>> flag is specified. Please see the "Deprecation of optparse" section of
>> the PEP:
>>
>> http://www.python.org/dev/peps/pep-0389/#deprecation-of-optparse
>
> I do not think that optparse should be deprecated at. It is good at
> what it does and its limitations make its starting point less
> confusing for people with different backgrounds that Python.
>
> Compare:
> http://docs.python.org/library/optparse.html
> http://argparse.googlecode.com/svn/tags/r101/doc/index.html
>
> argparse should be recommended as advanced and more featured variant
> of optparse - that goes without saying, but forcing people to switch
> and annoying them with deprecation messages brings only headache.

As has been noted already nobody is forcing people to switch. Optparse
will be available as a separate package and everybody will be free to
install it and will not have any deprecation messages anywhere.

> Just
> like optparse is better getopt, the latter could also be useful for
> people coming from other languages and porting their libraries to
> Python.
>
> I would better concentrate on real code examples how argparse solves
> problems and would really want to see
> http://www.python.org/dev/peps/pep-0389/#out-of-scope-various-feature-requests
> implemented until argparse enters phase where backward incompatible
> changes in API are impossible.
>
> I would prefer to see PEP 389 as a document describing proposed
> solutions to argument parsing problems rather than petition to replace
> one library with another. So, it should display common argument
> parsing scenarios (use cases) with examples that are also useful
> recipes for documentation. I guess more than 90% people here doesn't
> have time to read argparse methods descriptions to see what they could
> be useful for.



-- 
Psss, psss, put it down! - http://www.cafepress.com/putitdown
___
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

Re: [Python-Dev] Question over splitting unittest into a package

[Olemis Lang]

On Thu, Dec 31, 2009 at 10:30 AM, Martin (gzlist)  wrote:
> Thanks for the quick response.
>
> On 30/12/2009, Benjamin Peterson  wrote:
>>
>> When I made that change, I didn't know that the __unittest "hack" was
>> being used elsewhere outside of unittest, so I felt fine replacing it
>> with another. While I still consider it an implementation detail, I
>> would be ok with exposing an "official" API for this. Perhaps
>> __unittest_ignore_traceback?
>
> Well, bazaar has had the trick for a couple of years, and googling
> around now turns up some other projects using it or thinking about it:
> 
> 
> 
>

Add `dutest` and probably `nose` [2]_ and ...

> Reinstating the old implementation (with the same name) would mean
> that existing code would keep working with Python 2.7

IOW ... if it is removed all the libraries will have to change and
check for the Py version and ... (probably not a big deal depending on
the details of the «solution»)

> but maybe a
> discussion could start about a new, less hacky, way of doing the same
>

I am strongly -1 for modifying the classes in «traditional» unittest
module [2]_ (except that I am strongly +1 for the package structure
WITHOUT TOUCHING anything else ...) , and the more I think about it I
am more convinced ... but anyway, this not a big deal (and in the end
what I think is not that relevant either ... :o). So ...

pass

> May not be worthwhile making life more complicated though,
> there aren't *that* many unittest-extending projects.
>

But every library extending `unittest` will do it or otherwise
not-so-useful error messages will be displayed
;o)

PS: Happy New Year ! BTW

.. [1] [feature] nosexml should omit trace frames where `__unittest...
(http://code.google.com/p/python-nosexml/issues/detail?id=4#c0)

.. [2] Assessment of unittest 2.7 API : new features and opinions

(http://simelo-en.blogspot.com/2009/12/assessment-of-unittest-27-api-new.html)

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
Free new ripit 1.3.3 Download - mac software  -
http://feedproxy.google.com/~r/TracGViz-full/~3/KFwyUTKH0vI/
___
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