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