(Serious?) package namespace problem (and a proposal)

[Rob Hooft]

>>>>> "JvR" == Just van Rossum <just at letterror.com> writes:

 JvR> <silly-proposal>
 JvR> If relative imports as we know them are shot in the head, an
 JvR> alternative spelling for relative imports could be invented.
 JvR> Eg. with a leading period:

 JvR> import .some.submodule
 JvR> </silly-proposal>

Really interesting view. Like "sh" would mean "sh in the root
directory", and "/bin/sh" means look in the current directory for a
directory bin, which contains sh?

Wrong way around? Wouldn't "from . import os" sound more reasonable?

I still think that if you have a package from which you want to use the
module "sys" or "os" or "string", you can AVOID using sys.py, os.py or
string.py. See your own future code:

from . import string; GLOBALstring=string
import string
....
c=GLOBALstring.strip(command)
string.emit(c)
....


And if you don't know what modules from the standard library
you might need in the future, don't use any of their names in your package.
And finally, claim the name of your package in the http://pitch.nist.gov/nics/
archive to prevent future collisions.

Having your own modules named the same as those in the standard library
is also confusing for somebody else that needs to read/modify your code.

Rob

-- 
=====   rob at hooft.net          http://www.hooft.net/people/rob/  =====
=====   R&D, Nonius BV, Delft  http://www.nonius.nl/             =====
===== PGPid 0xFA19277D ========================== Use Linux! =========