[stdlib-sig] Breaking out the stdlib
michael at voidspace.org.uk
Tue Sep 15 18:59:32 CEST 2009
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
>> 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.
More information about the stdlib-sig