Launching Multiple Servers

Andrew Bennetts andrew-pythonlist at puzzling.org
Sun May 25 00:27:16 EDT 2003


On Sat, May 24, 2003 at 09:53:05PM -0600, Andrew Dalke wrote:
> Andrew Bennetts:
> 
> > I'm not an expert in this code, but twisted.python.log has been
> > reimplemented in 1.0.5, and presumably it's better ;)
> 
> After my prodding ;)

Yes -- thank you! :)

> > I'm not sure what you're referring to with "automatic prefix expansion I
> > don't like"?
> 
> Twisted expands an option given it's prefix.  Suppose you have
> an option like "--logfile", with no other options starting with "l" or
> "lo" or "...". Then as I read the Twisted docs, it will automatically
> expand "--log" to "--logfile".  This is what VMS did as well.
> It seems good, but the problem is that people write scripts which
> assume things will never change, so assume "--log" is the 'correct'
> option.

Ah, I see.  You're right, it does do that.  I never even realised that it
did that.  On further investigation, this actually happens inside the getopt
module!

> Now add a new feature enabled by '--login'.  This also has the
> prefix "--log", so will break scripts which expected '--log' to
> match '--logfile' -- unless you explicitly add all the prefixes or
> put in a "when multiple prefixes exist, prefer this one" option.
> 
> This makes things more confusing, so I would rather not allow
> prefix support.

I'm inclined to agree.  Having two ways to do something is already arguably
at least one way too many ;)

> So my complaint about writing a new command-arg parser
> in Twisted is not that a new one exists -- optparse shows that
> getopt has problems -- it's that the behaviour implemented is
> quite different from how Python or other packages work, and
> is a behaviour that I would rather not have.

Well, twisted.python.usage uses getopt internally, presumably to help ensure
it's behaviour is reasonably consistent with existing python programs... so
blame getopt, not Twisted!  ;)

> Both the logging and optparse modules support older versions.
> Include the code in Twisted, and in a few releases issues a
> deprecated warning with a "from optparse import *" as the
> implementation.

I'm inclined to agree, but obviously I can't speak for the rest of the
Twisted team.

> > On the other hand, asyncore already did asynchronous networking for
> > Python, and we've reimplemented that too -- but I think the result is
> > something much better than asyncore.  If we've reinvented something,
> > there will be a reason for it.  But as you point out, it can make life
> > harder for our users.
> 
> I don't doubt there's a reason.  I worry that the reason doesn't always
> consider the impact it has on people who aren't the implementors.

I think we're very conscious of the impact these sorts of decisions cause
our users.  That doesn't guarantee we make the right decisions, but we do at
least try :)

-Andrew.






More information about the Python-list mailing list