[Python-Dev] Re: Adopting Optik

Chad Netzer cnetzer@mail.arc.nasa.gov
Thu, 14 Nov 2002 12:06:20 -0800

On Thursday 14 November 2002 09:40, Fran=E7ois Pinard wrote:

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

Just a quick side note, you can always do things like:

import socket
SocketModule =3D socket

socket =3D open( "blah blah blah")

Which may be un-pythonic, but not too onerous, imo.  Now that the string=20
module is kind of superfluous, you may be able to start using 'string' as=
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 mor=
modules into the mainline, the current ad-hoc naming style could become a=
problem.  Some early modules already appropriate common useful variable n=
(signal, thread, etc.), and there seems to be a trend of new modules tryi=
to avoid this with different methods (Capitalization, -lib suffix, etc.)

Perhaps we should discuss (if it hasn't been discussed to death already) =
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=20
(keeping the old names as well, but deprecating them)

For example, I think modules should avoid being singular nouns.  They sho=
instead describe (or hint at) what services they provide, not what kind o=
object they provide.  So, the 'socket' module would be better as 'sockets=
because someone is more likely to use a temporary "socket" variable than =
"sockets" variable.

Furthermore, I don't particularly like the "lib" suffix, but it is useful=
being short, and makes clear that it provides services.  Lots of modules =
using it, maybe we should formalize its use.

Should we allow mixed case module names in the standard distribution modu=
names?  Yes or no?  I suppose I don't really care, if other naming issues=
worked out.  But in general I prefer lowercase, which makes choosing the=20
right name more important.  So "Queue" would possibly be better as 'queue=
but not as 'queue'.

Oh well, enough rambling.  Maybe it isn't that big a deal, not worthy of=20
wasting too much time on.  But as time goes on and the module namespace g=
more crowded, the ad-hoc naming scheme starts to look a little rustic.


Chad Netzer