Import concerns revisited

[Kirk McDonald]

Bruno Medeiros wrote:
> Kirk McDonald wrote:
> 
>> Bruno Medeiros wrote:
>>
>>> This behavior of having all project entities(names) automatically 
>>> available by FQN is also how Java and C# work[*], which I think is a 
>>> quite sensible approach. And perhaps this should even be the standard 
>>> among D programs.
>>>
>>> [*] How is it in Python and Ruby? (I do not know those languages 
>>> well) Or in any other language you know with such similar structured 
>>> hierarchical namespacing?
>>>
>>>
>>
>> I've reviewed Python's import rules previously:
>> http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/39396
>>
> 
> How does Python determine module names, and map modules to files (or 
> vice-versa)?
> 

In the simple case, the file "foo.py" is mapped to the module "foo". 
When you attempt the import the module, Python searches something called 
the "Python path," which is a list of directories. Normally, this is 
just set to the current directory, the location(s) of the standard 
library, and the standard "site-packages" directory, where add-on 
libraries live. Python being Python, this list can be altered at runtime.

Python can accept other kinds of files as modules. .pyc files are 
bytecode-compiled Python code; .pyd, .dll, and/or .so files are compiled 
C (or C++, or D) extensions.

Python also has the concept of a "package," not unlike D. However, 
Python's packages are slightly more sophisticated than D's. Each 
directory in the package has a special "__init__.py" file which defines 
what the other components of the package are. This file is also a 
full-fledged Python source file, so you can do any number of things when 
just the /package/ is imported. It acts as a standard single point of 
access for the entire package.

-- 
Kirk McDonald
Pyd: Wrapping Python with D
http://dsource.org/projects/pyd/wiki