== The problem with trying to make everything into a Python module

One of the reasons for [[Django's unpleasant project restructuring
../programming/BadProjectLayout]] is that they want your website
directory (ie the directory that your project sits in) to be a module
that can be imported. This in fact seems to be somewhat of a general
trend; all sorts of things rather want you to to have not just a
collection of files in a directory but an actual module.  I wish they'd
stop. Modules are not the be all and end all in Python, at least not as
currently implemented, and not everything needs or wants to be a module.

The general reason for making things into modules is namespaces for
imports. If you're sitting in your project's directory and do '_import
fred_', in theory this is ambiguous; you might mean your _fred.py_
or you might mean some global _fred_ module installed in Python. The
absolute form of '_import mystuff.fred_' is more or less unambiguous.

(This preference for modules also goes with the fact that the relative
import syntax, '_from . import fred_', is only valid in an actual
module. I think that this is a terrible mistake, but no one asked me for
my opinion.)

I have no problem with modules as such. The problem I have is how you
get a directory to be a module, namely that you add the directory's
parent to the Python search path (in one of a number of ways), and
then the directory becomes a module (or technically I think a package)
called its directory name. This is bad in at least two ways. It tightly
couples together the directory name and the module name and it also
makes everything else in the directory's parent available as a potential
module. What both of these have in common is undesired name collisions.
For example, you cannot be working on two versions of a 'fred' module
that are sitting in a directory as, say, _src/fred-1_ and _src/fred-2_,
not unless you want to have a _src/fred_ symlink that you keep changing
back and forth.

(The natural structure seems to be to isolate each module in its own
artificial parent directory (eg _src/fred-1/fred_) or to ignore the
whole issue, put everything in _src/_, and assume you will never have
any collisions or be developing a new version of fred that you don't
want _src/bob_ getting when it does an '_import fred_'.)

What would make this situation okay is a simple way to tell Python
'directory X is module Y', where 'X' might be '.' (the current
directory). This should be available both on the Python command line and
from inside Python code. Sadly I don't expect this to arrive any time
soon.

(This stuff irritates me for reasons that are hard to pin down. Partly
it just feels wrong (eg '_/src_' or wherever isn't a directory of
modules, so why am I telling Python that it is?).)