Steven Schveighoffer, el 2 de noviembre a las 10:59 me escribiste: > >The opposite of hijacking would be if any duplicates found would > >be an error. > > No, this is also a form of hijacking -- namespace hijacking. > > example: > > I write an application, defining a small internal library foo. I > put a module bar in the foo directory, and import foo.bar in my main > program. > > Now, someone compiles it on his system and happens to have a > globally installed foo library (completely unrelated to my > app-specific foo library) with a module bar. The compiler sees both > and throws an error? Now I have to deal with the possibility that > any library can kill the ability to compile my app by naming its > directories the same?
Maybe this can be addressed by adding relative imports like in Python 2.5+ import my_foo = .foo; // look for dirname(__FILE__)/foo.d, error if not found import ..foo: bar; // dirname(__FILE__)/../foo.d, error if not found import foo; // regular search path Relative imports are always aliased or subject to importing single symbols because .foo is not a valid symbol name. I think import ...foo; could be allowed by making it a shortcut to import foo = ...foo; See http://www.python.org/dev/peps/pep-0328/ for the complete proposal. The Python community already had to deal with this (maybe for different reasons though), maybe we can learn something from it. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- Yo soy peperino el que siempre pone el vino, yo soy aquel que come los huevos con tocino. -- Peperino Pómoro
