other python ideas

[Douglas Alan]

rcameszREMOVETHIS at dds.removethistoo.nl (Robert Amesz) writes:

>>> Getting rid of import statements is *evil*. It means the
>>> dependencies in your code will be hidden from others.

>> How's that?  All you'd have to do is grep for "::".  [...]  It's
>> not like import statements all have to be at the top of the file
>> in Python code as it is.  They certainly aren't in my code.

> But I don't *want* to be forced to search through your source, I prefer 
> to look at the top the file and see what's imported (and how) at a 
> glance.

Well, unfortunately you can't do that in my code and never will be
able to.  I don't put my imports at the top of the file -- I put them
close to where the module is used, which is where the imports belong.
(At least in my code, that's where they belong.)  There are all sorts
of things that one might in some conceivable programming language put
at the top of the file to make them more readily visible, but to me,
keeping declarations close, when possible, to where the declared
entity is used has almost always turned out to be the wisest thing.

For instance, often I want to rearrange or refactor my code.  I need
to move functions and classes from one file to another, etc.  If the
imports are at the top of the file, rather than with the functions
that use them, then I end up spending way too much time and effort
tracking down all the imports that I now need to also move.

On the other hand, your problem of wanting to quickly see what
dependencies are in my code is quickly solved by issuing a simple
"grep" command.  Consequently, my dependencies are not really hidden
from anyone.

> Remember: "Python gives you enough rope to let shoot yourself in the 
> foot," but that doesn't mean that you're under any obligation to do so. 
> ;-)

I find that it's putting the imports at the top of the file that
shoots me in the foot.

> And so I'll restate: there is no general way of importing or
> reloading part of a module which is guaranteed to work.

The answer is that it doesn't have to be *guaranteed* to work for it
to work, as long as the language specifies what the module implementer
must do to help make it work.  Common Lisp *does* solve this problem,
or so I am told, and in theory there is no reason why a similar
solution couldn't be grafted onto Python, but Common Lisp's solution
is rather complicated, and requires the implementer of a module to
follow certain rules if reloading is to work properly.  It would be
nice if there were a solution that is at least somewhat simpler than
Common Lisp's.  But I'm far from an expert on this topic, so I really
can't say if there is a simpler solution.  I was thinking that my "::"
importing notation, along with some guidelines for module implementers
and users might be a first stab at part of the solution, but there are
important reloading issues that this alone does not address.  For
instance, objects from the module that are already in existence will
still not have their behavior change, even if new objects being
created are more likely to reflect the reload.

Solving this problem does have huge pay-offs for certain problem
domains.  If there is no significantly simpler solution that Common
Lisp's, it may just be better for a Python-like language to leave
these problem domains to Lisp, rather than complicating the
Python-like language to address them.

One possible solution that might be more comprehensive and not require
a change in syntax would be to give the reloader the ability to modify
functions and classes that already exist.  When you reload a module,
instead of new functions and classes being created and the existing
variables in the module being rebound to the new objects, the original
functions, classes, and objects might be modified in place.
Guidelines would need to be provided to tell a module implementer all
the gotchas they need to keep in mind if they want their module to be
reloadable.  Immutable objects in the modules (such as integer
constants or global tuples) would seem to be a problem.  Perhaps an
exception could be made for reloading, and immutable objects could be
modified under these very limited circumstances.  But thinking about
all the issues that this might raise is very difficult.

In any case the "::" module notation has, I feel, other significant
advantages, even should it turn out to be worthless for helping to
solve module reloading issues.

|>oug

Disclaimer: The author of this message does not clamor to make any
changes to Python.  He is only musing on how he thinks things should
have been, or might yet be in some future Python-like language.