Greg Ewing wrote:

Brett Cannon :

...

Best I can do is ArgParser or something to try to tie the name into sys.argv.

How about argvparse, by analogy with urlparse?

or argparse. The v is archaic and so silent it fades away =) --david

[Greg Ewing]

Brett Cannon :

...

Best I can do is ArgParser or something to try to tie the name into sys.argv.

How about argvparse, by analogy with urlparse?

+1 As David Abrahams pointed out in another email, having the "v" in their helps deal with any possible ambiguity. Now I know Guido suggested ``optlib`` and Greg liked it. But I don't like the idea of associating the package with the *lib modules in the stdlib. If you look at the stdlib we have modules like ftplib, htmllib, zlib, and urllib. I view these modules as collections of methods and classes that have a common theme, but where each method and class can be used in isolation; they are collections of utility methods and classes. They are not part of some single, large functionality like Optik is. And yes, I realize that urlparse is more like what I described above, but it is not a habit in the library yet. But if this *lib association sticks, I like ``optlib``. And since all of these name suggestions are ending up in all of these emails (and I have to know them for the Summary anyway), the following is best as I know so far. If someone has thrown their support behind another name, I only list their last supported name. optlib: Guido van Rossum, Greg Ward cmdline: cmdopts: Ka-Ping Yee, David Abrahams argvparse: Greg Ewing, Brett Cannon argparse: David Ascher

...

...

...

...

"BC" == Brett Cannon writes:

BC> optlib: Guido van Rossum, Greg Ward BC> cmdline: BC> cmdopts: Ka-Ping Yee, David Abrahams BC> argvparse: Greg Ewing, Brett Cannon BC> argparse: David Ascher Cute names be celebrated, the obvious choice now is "argument". :) this-is-getting-hit-on-the-head-lessons-ly y'rs, -Barry

...

...

...

...

"GW" == Greg Ward writes:

GW> Still haven't done anything about the test suite, which is GW> probably the main reason I've been procrastinating on this. (Oh GW> yeah, the docs too.) They can probably wait until the distutils docs are done. Jeremy

Let's assume we'll stick with optparse as the module name. There are still a few references to Optik in the source code, in particular there's an exception class OptikError. (The other mentions are in comments.) Should I rename OptikError to OptParseError, or leave it? --Guido van Rossum (home page: http://www.python.org/~guido/)

Ka-Ping Yee wrote:

On Thu, 14 Nov 2002, Guido van Rossum wrote:

...

Should I rename OptikError to OptParseError, or leave it?

I like optparse, and i think it's a good idea to call the corresponding error OptParseError.

Agreed. Now's the time to get rid of the legacy code.

On Thursday 14 November 2002 09:40, François Pinard wrote:

When one "imports" a module, one has to give up using the module name for other purposes.

Just a quick side note, you can always do things like: import socket SocketModule = socket socket = open( "blah blah blah") Which may be un-pythonic, but not too onerous, imo. Now that the string module is kind of superfluous, you may be able to start using 'string' as a variable name (I'd still avoid it for another five years, though. :) I think the point is well taken, however. Global namespace aliasing is a problem with many languages, and as python officially adopts more and more modules into the mainline, the current ad-hoc naming style could become a problem. Some early modules already appropriate common useful variable names (signal, thread, etc.), and there seems to be a trend of new modules trying to avoid this with different methods (Capitalization, -lib suffix, etc.) Perhaps we should discuss (if it hasn't been discussed to death already) a format to adopt for all future included modules, to make things sane. We could even consider renaming the old modules that don't fit the pattern (keeping the old names as well, but deprecating them) For example, I think modules should avoid being singular nouns. They should instead describe (or hint at) what services they provide, not what kind of object they provide. So, the 'socket' module would be better as 'sockets', because someone is more likely to use a temporary "socket" variable than the "sockets" variable. Furthermore, I don't particularly like the "lib" suffix, but it is useful for being short, and makes clear that it provides services. Lots of modules are using it, maybe we should formalize its use. Should we allow mixed case module names in the standard distribution module names? Yes or no? I suppose I don't really care, if other naming issues are worked out. But in general I prefer lowercase, which makes choosing the right name more important. So "Queue" would possibly be better as 'queues', but not as 'queue'. Oh well, enough rambling. Maybe it isn't that big a deal, not worthy of wasting too much time on. But as time goes on and the module namespace gets more crowded, the ad-hoc naming scheme starts to look a little rustic. -- Chad Netzer cnetzer@mail.arc.nasa.gov