DIP16: Transparently substitute module with package

[Michel Fortin]

On 2012-04-06 09:41:27 +0000, deadalnix <deadalnix at gmail.com> said:

> Why not limit name collision to name which make sense ?

You're proposing that fully qualified names sometime work and sometime 
do not work based on what you've imported and the context of usage. 
This makes any FQN conflict hard to detect, because the error will be 
dependent on the context in which you use the name.

You say it'll never happen for modules spitted in submodules, but I 
disagree. Someday, someone will add a symbol to a submodule without 
checking every package/module file underneath. Unit tests in the module 
won't catch the problem because for them to catch the problem the 
parent module/package has to be imported. Only on certain usages, with 
the right imports and in the right context will the error occur.

In fact, if you add disambiguation based on what "makes sense" you're 
making the error more obscure and harder to detect in the first place 
because sometime it'll occur and sometime not depending on hard to 
predict conditions.

If we allow arbitrary symbols to live inside a package, any conflict in 
FQN should be caught as soon as possible, ideally as soon as you 
compile after having added the symbol, and even if you don't use the 
symbol anywhere. Just like how you get an error today when you try to 
import a module matching a known package name, you shouldn't be allowed 
to import a module matching a known symbol name, or create a symbol 
matching a module fully qualified name.

-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/