[stdlib-sig] Breaking out the stdlib

[Michael Foord]

Paul Moore wrote:
> 2009/9/15 Michael Foord <michael at voidspace.org.uk>:
>   
>> Right - but part of the specific problem with optparse is that in many
>> situations it does a very inadequate job (i.e. it "it does what it is meant
>> to do" but not what many people "need it to do") and is designed in such a
>> way that *required* functionality can't be added in a backwards compatible
>> way.
>>
>> That is not "good code" (by my reckoning).
>>     
>
> As such, optparse needs to change (assuming that the stdlib *should*
> be "good code"). There are requirements (feature requests at least,
> possibly even bugs) which need addressing.
>
> If no maintainer can be found to do this, then optparse is de facto
> dead and unmaintained.(Laura's B-2). No-one has made a statement about
> what should be done with B-2 code in the stdlib, but I can see good
> arguments for allowing the possibility of dropping it in favour of a
> replacement library.
>
> If someone wants to argue that optparse is class "C" (ie, it is
> "finished" and "complete") then that's a different matter. Requests
> for optparse to support required arguments, or to better support user
> extension, would then be closed "won't fix - this is by design". And
> in that case, it *is* more or less by definition "good code" - it
> fulfills its aims, it just doesn't aim to do what Michael states many
> people "need it to do" above. (Personally, I don't see that code can
> be described as "good" if it doesn't aim to do what people need, but
> maybe someone wants to argue this).
>
> I think the issue with argparse vs optparse is that argparse appears
> to be intended as "optparse done right" (I can't comment on whether it
> is, just that's what it looks like). So having both in the stdlib
> looks like duplication (far more so than having getopt along with
> either). If optparse was still evolving, it should be possible to
> devise some way of merging the two (possibly with API breakages,
> admittedly). The dilemma here seems to be that optparse won't change,
> and argparse offers extra functionality that people actually want (and
> would like in the stdlib). Something needs to give.
>   


Seems like a good summary. I hope there will be a PEP from Steven for 
the inclusion of argparse. It's all a bit of a moot debate because we 
don't even need to decide whether to remove optparse now - we can start 
it down the deprecation road and *possibly* remove it eventually...

Personally I would like to see dead modules removed (whilst some would 
like to see the whole standard library dead ;-) - but our deprecation 
process is deliberately slow so that issues like this can be deliberated 
on a case by case basis over a period of years.

Michael

> Paul.
>   


-- 
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog