[Python-Dev] Re: Adopting Optik (original) (raw)
Chad Netzer cnetzer@mail.arc.nasa.gov
Thu, 14 Nov 2002 12:06:20 -0800
- Previous message: [Python-Dev] Re: Adopting Optik
- Next message: [Python-Dev] Re: Adopting Optik
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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= or 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= a=20 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= =20 problem with many languages, and as python officially adopts more and mor= e=20 modules into the mainline, the current ad-hoc naming style could become a= =20 problem. Some early modules already appropriate common useful variable n= ames=20 (signal, thread, etc.), and there seems to be a trend of new modules tryi= ng=20 to avoid this with different methods (Capitalization, -lib suffix, etc.)
Perhaps we should discuss (if it hasn't been discussed to death already) = a=20 format to adopt for all future included modules, to make things sane. We= =20 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= uld=20 instead describe (or hint at) what services they provide, not what kind o= f=20 object they provide. So, the 'socket' module would be better as 'sockets= ',=20 because someone is more likely to use a temporary "socket" variable than = the=20 "sockets" variable.
Furthermore, I don't particularly like the "lib" suffix, but it is useful= for=20 being short, and makes clear that it provides services. Lots of modules = are=20 using it, maybe we should formalize its use.
Should we allow mixed case module names in the standard distribution modu= le=20 names? Yes or no? I suppose I don't really care, if other naming issues= are=20 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= s',=20 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= ets=20 more crowded, the ad-hoc naming scheme starts to look a little rustic.
--=20
Chad Netzer cnetzer@mail.arc.nasa.gov
- Previous message: [Python-Dev] Re: Adopting Optik
- Next message: [Python-Dev] Re: Adopting Optik
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]