Hello list,
What started as a joke yesterday in the Bug Tracker and on Twitter now evolved into a serious consideration. In case the only reason for optparse to go away is that it does not have a maintainer I would take over that task.
In fact I would also implement missing features based on real-world needs. That would most likely mean that some of the changes in argparse would end up in optparse as well. Furthermore I would release a Python-independent version on PyPI for compatibility with older Python versions.
I would take over this task if the following criteria are met:
- argparse would not enter the standard library - I'm allowed to modernize optparse after a discussion with python-dev in a backwards compatible way. - I'm allowed to refactor the code - make the i18n support of the module more pluggable which would allow specifying a custom translations instance instead of using the global gettext function.
Regards, Armin
Armin Ronacher wrote:
Hello list,
What started as a joke yesterday in the Bug Tracker and on Twitter now evolved into a serious consideration. In case the only reason for optparse to go away is that it does not have a maintainer I would take over that task.
In fact I would also implement missing features based on real-world needs. That would most likely mean that some of the changes in argparse would end up in optparse as well. Furthermore I would release a Python-independent version on PyPI for compatibility with older Python versions.
I would take over this task if the following criteria are met:
- argparse would not enter the standard library
That can't be a pre-requisite as we can't tell if you will succeed until you actually look at the problem and see how possible it is. I would do a feasibility check.
For me the important features of argparse are:
* handling positional arguments including required positional arguments * required options (which it looks like can be added easily - the above is less easy though) * subcommands
- I'm allowed to modernize optparse after a discussion with python-dev
That would be true anyway, unless we had already decided to deprecate.
in a backwards compatible way.
- I'm allowed to refactor the code
Ditto.
- make the i18n support of the module more pluggable which would allow specifying a custom translations instance instead of using the global gettext function.
That sounds good to me. I don't know how 'mandatory' others feel the use of gettext is in il8n support in the standard library.
Michael
Regards, Armin _______________________________________________ stdlib-sig mailing list stdlib-sig@python.org http://mail.python.org/mailman/listinfo/stdlib-sig
Le mardi 15 septembre 2009 à 11:44 -0700, Armin Ronacher a écrit :
I would take over this task if the following criteria are met:
- I'm allowed to modernize optparse after a discussion with python-dev in a backwards compatible way.
- I'm allowed to refactor the code
- make the i18n support of the module more pluggable which would allow specifying a custom translations instance instead of using the global gettext function.
These all look fine and even welcome.
- argparse would not enter the standard library
This one doesn't. This is a kind of "you are either with me, or against me" argument. While I would favour improving optparse over including argparse, I don't think we can commit to never include argparse, just because you asked for it.
Please note that if you do improve optparse, the bar for including argparse will be much higher anyway. Perhaps people won't even ask for it, seeing that optparse has become sufficient for them.
Regards
Antoine.
Hi,
Antoine Pitrou wrote:
This one doesn't. This is a kind of "you are either with me, or against me" argument. While I would favour improving optparse over including argparse, I don't think we can commit to never include argparse, just because you asked for it.
I can see strong disagreement with me here which is why I would love to change my point to "I would only *continue* to maintain optparse is argparse does not end up in the standard library". If both end up there, maintenance from my side ends.
Regards, Armin
Le mardi 15 septembre 2009 à 12:09 -0700, Armin Ronacher a écrit :
I can see strong disagreement with me here which is why I would love to change my point to "I would only *continue* to maintain optparse is argparse does not end up in the standard library". If both end up there, maintenance from my side ends.
Then it is probably fine, IMHO. The optparse situation, if you ended up maintenance, wouldn't be worse than today's.
On Tue, Sep 15, 2009 at 11:44, Armin Ronacher armin.ronacher@active-4.com wrote:
Hello list,
What started as a joke yesterday in the Bug Tracker and on Twitter now evolved into a serious consideration. In case the only reason for optparse to go away is that it does not have a maintainer I would take over that task.
In fact I would also implement missing features based on real-world needs. That would most likely mean that some of the changes in argparse would end up in optparse as well. Furthermore I would release a Python-independent version on PyPI for compatibility with older Python versions.
I would take over this task if the following criteria are met:
- argparse would not enter the standard library
Now I know you said in another email that you meant for this to be ""I would only *continue* to maintain optparse is argparse does not end up in the standard library", but that still feels like I am being politically pushed around and I don't like that, especially when argparse already exists and this proposal is hypothetical.
- I'm allowed to modernize optparse after a discussion with python-dev
in a backwards compatible way.
That's always been allowed.
- I'm allowed to refactor the code
As long as the unit tests pass (but that assumes optparse has thorough tests) and you do not change the public API, then that has always been allowed as well.
- make the i18n support of the module more pluggable which would allow
specifying a custom translations instance instead of using the global gettext function.
Depends on how you want to do that. If you are suggesting creating your own i18n solution that precludes gettext, then no as that is the current solution in the standard library and you shouldn't try to exclude it. If you want it to be pluggable enough such that gettext or any other solution can be used, then fine.
But ignoring your criteria, Armin, python-dev has the criteria that you get commit privileges and I am not sure if you will get them because of lack of participation on python-dev and the issue tracker. Until you get commit privileges I can't take this seriously.
-Brett
2009/9/15 Brett Cannon brett@python.org:
But ignoring your criteria, Armin, python-dev has the criteria that you get commit privileges and I am not sure if you will get them because of lack of participation on python-dev and the issue tracker. Until you get commit privileges I can't take this seriously.
He has them, though.
On Tue, Sep 15, 2009 at 12:29, Benjamin Peterson benjamin@python.org wrote:
2009/9/15 Brett Cannon brett@python.org:
But ignoring your criteria, Armin, python-dev has the criteria that you get commit privileges and I am not sure if you will get them because of lack of participation on python-dev and the issue tracker. Until you get commit privileges I can't take this seriously.
He has them, though.
Yeah, just found that out.
-Brett
Hi,
Brett Cannon wrote:
Now I know you said in another email that you meant for this to be ""I would only *continue* to maintain optparse is argparse does not end up in the standard library", but that still feels like I am being politically pushed around and I don't like that, especially when argparse already exists and this proposal is hypothetical.
Open Source turns out to be very political unfortunately, and I'm of course driven my politics as well. I have not chosen my words carefully and I'm sorry if that causes you to think I try to push around anyone.
Depends on how you want to do that. If you are suggesting creating your own i18n solution that precludes gettext, then no as that is the current solution in the standard library and you shouldn't try to exclude it. If you want it to be pluggable enough such that gettext or any other solution can be used, then fine.
Django and Babel still use gettext without a global context, the way this would change is that you can provide your own translator when creating the option parser.
But ignoring your criteria, Armin, python-dev has the criteria that you get commit privileges and I am not sure if you will get them because of lack of participation on python-dev and the issue tracker. Until you get commit privileges I can't take this seriously.
I ended up with commit privileges a while ago, but don't take me serious because of that. No matter if I would have commit privileges or not, my offer is serious and I would do so either way *because* I want to see Python improve. So far I only complained about the standard library and it would only be fair to start improving it.
Regards, Armin
On Tue, Sep 15, 2009 at 12:35, Armin Ronacher armin.ronacher@active-4.com wrote:
Hi,
Brett Cannon wrote:
Now I know you said in another email that you meant for this to be ""I would only *continue* to maintain optparse is argparse does not end up in the standard library", but that still feels like I am being politically pushed around and I don't like that, especially when argparse already exists and this proposal is hypothetical.
Open Source turns out to be very political unfortunately,
Tell me about it.
and I'm of course driven my politics as well. I have not chosen my words carefully and I'm sorry if that causes you to think I try to push around anyone.
Glad you aren't.
Depends on how you want to do that. If you are suggesting creating your own i18n solution that precludes gettext, then no as that is the current solution in the standard library and you shouldn't try to exclude it. If you want it to be pluggable enough such that gettext or any other solution can be used, then fine.
Django and Babel still use gettext without a global context, the way this would change is that you can provide your own translator when creating the option parser.
As long as it can be used w/o modification then that's fine.
But ignoring your criteria, Armin, python-dev has the criteria that you get commit privileges and I am not sure if you will get them because of lack of participation on python-dev and the issue tracker. Until you get commit privileges I can't take this seriously.
I ended up with commit privileges a while ago, but don't take me serious because of that. No matter if I would have commit privileges or not, my offer is serious and I would do so either way *because* I want to see Python improve. So far I only complained about the standard library and it would only be fair to start improving it.
I'm glad this is motivating you!
Here is my perspective. I want Steven to move forward w/ trying to get argparse in, which means he has to write a PEP to propose his inclusion. If you manage to get optparse into a place where argprase is not needed, then at worst Steven has written a PEP that will be rejected and he can potentially stop working on argparse and switch to your refactored optparse. But I have seen too many well-intentioned people come along and say they really want to do something and not finish (because of time, turned out not to be doable, etc.). I am not saying I think you personally will more than likely fail, Armin, as I don't know you personally. But as a rule, I assume no one ever follows through until they have proven to me otherwise. That's why I am not willing to promise you that argparse will not go in or that I am willing to tell Steven to not try to get argparse in. But if you pull off what you are suggesting and you and Steven can get optparse to get what argparse has then there won't be a need to add argparse.
-Brett
Brett Cannon schrieb:
But ignoring your criteria, Armin, python-dev has the criteria that you get commit privileges and I am not sure if you will get them because of lack of participation on python-dev and the issue tracker. Until you get commit privileges I can't take this seriously.
In fact, Armin already had commit privileges since July 07, originally for work on doctools (now Sphinx), which started out in the python.org repo. Later he contributed the ast module and kept the privileges as its maintainer.
Georg
Georg Brandl schrieb:
Brett Cannon schrieb:
But ignoring your criteria, Armin, python-dev has the criteria that you get commit privileges and I am not sure if you will get them because of lack of participation on python-dev and the issue tracker. Until you get commit privileges I can't take this seriously.
In fact, Armin already had commit privileges since July 07, originally for work on doctools (now Sphinx), which started out in the python.org repo.
This is also the reason why he's not listed in developers.txt, in case someone is wondering.
cheers, Georg
On Tue, Sep 15, 2009 at 12:35, Georg Brandl g.brandl@gmx.net wrote:
Georg Brandl schrieb:
Brett Cannon schrieb:
But ignoring your criteria, Armin, python-dev has the criteria that you get commit privileges and I am not sure if you will get them because of lack of participation on python-dev and the issue tracker. Until you get commit privileges I can't take this seriously.
In fact, Armin already had commit privileges since July 07, originally for work on doctools (now Sphinx), which started out in the python.org repo.
This is also the reason why he's not listed in developers.txt, in case someone is wondering.
He should probably be added stating this.
-Brett
cheers, Georg
-- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.
stdlib-sig mailing list stdlib-sig@python.org http://mail.python.org/mailman/listinfo/stdlib-sig
Brett Cannon schrieb:
On Tue, Sep 15, 2009 at 12:35, Georg Brandl g.brandl@gmx.net wrote:
Georg Brandl schrieb:
Brett Cannon schrieb:
But ignoring your criteria, Armin, python-dev has the criteria that you get commit privileges and I am not sure if you will get them because of lack of participation on python-dev and the issue tracker. Until you get commit privileges I can't take this seriously.
In fact, Armin already had commit privileges since July 07, originally for work on doctools (now Sphinx), which started out in the python.org repo.
This is also the reason why he's not listed in developers.txt, in case someone is wondering.
He should probably be added stating this.
Makes sense, done.
Georg
participants (6)
-
Antoine Pitrou -
Armin Ronacher -
Benjamin Peterson -
Brett Cannon -
Georg Brandl -
Michael Foord