[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [PATCH] svnmerge-migrate-history-remotely.py: move from getopt to optparse

From: anatoly techtonik <techtonik_at_gmail.com>
Date: Wed, 8 Jun 2011 13:59:06 +0300

On Wed, Jun 8, 2011 at 12:57 PM, Stefan Sperling <stsp_at_elego.de> wrote:
> On Wed, Jun 08, 2011 at 09:34:05AM +0300, anatoly techtonik wrote:
>> On Mon, Jun 6, 2011 at 6:32 PM, Stefan Sperling <stsp_at_elego.de> wrote:
>> > On Thu, Jun 02, 2011 at 07:06:05PM +0300, anatoly techtonik wrote:
>> >> Attached patch fixes svnmerge history conversion script to use
>> >> optparse library instead of getopt. This allows further addition of
>> >> new options, such as --username and --password.
>> >
>> > Hi,
>> >
>> > Can you explain why you need to convert this script to optparse
>> > to add new options? Is this a cosmetic fix or is there a technical
>> > problem with adding more options via getopt? Thanks!
>> 1. It makes code more clear
>> 2. It saves me time on learning what a getopt is
> So those who already know getopt should learn about optparse for
> your convenience? I don't think that's a good argument.
> By the same argument you could send a patch that rewrites the script
> in your favourite programming language because you don't like Python.

optparse is de-facto standard for option parsing in Python. It makes
code more maintainable and clear as you may see from the patch. You
should waste 15 minutes to play with it if you program Python for
terminal scripts as it will really save you a lot of time in future.

I actually rewrote old awk and perl scripts in Python for projects
like Far Manager and UFO: AI just to make build toolchain more
maintainable on Windows. These are usually land in contrib/ dirs, but
they enable more people to use them and adapt for their own workflow,
which is a good thing IMO.

> I don't mind the change in principle because I don't really care
> strongly about whether this script should optparse or getopt.
> But it is generally better to send minimal patches because they can
> be more easily digested and applied. So if all you really want is another
> option, I'd be much happier with a patch that just adds this option.

My goal was to make this script understand authentication parameters
for closed repositories. So far I've found a workaround by using
special config that allows to do this with 'password-stores ='. It
would be more convenient to have username and password params that
automatically generate this config in temp dir, but I probably won't
have time for that and it will be a much more complicated patch.

If you ever wondered why Bugzilla doesn't have OpenID support, then it
because it requires people to learn Perl and for some strange reason
people don't do that. I guess that's the same reason I don't want to learn

anatoly t.
Received on 2011-06-08 12:59:59 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.