other python ideas

[Robert Amesz]

Douglas Alan wrote:

>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. Importing modules at the top of the file isn't syntactically 
required, but I would say it's highly recommended, unless there are 
very good reasons not to do so.

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. 
;-)


>> Also, install and freeze packages have a harder determining what
>> modules are needed (which is hard enough as it is).
>
>It would be no harder than it is now.  "module::foo" would just be
>syntactic sugar for "__import__("module").foo" (along with a more
>efficient implementation technique).

Well, using __import__()  really should be kept to a minimum as well, 
IMHO.


>>> Another problem is that if you import individual objects from a
>>> module, and then you reload the module, the individual objects
>>> remain out of date.  This causes you to end up trying in the
>>> debugger to track down bugs that turn out to debugger-only bugs.
>
>> Blame the debugger, not Python's module syntax. The debugger
>> really should start from scratch if you've edited a module,
>> otherwise you're actually modifying the program while it is still
>> running. Very unsafe, and there's no general way to fix that.
>
>Sure there is.  And I don't want to start from scratch.  A Lisp
>Machine just runs one big Lisp (even the OS is in that one big Lisp)
>that never goes away until you reboot it. In such an environment,
>being able to reliably reload modules is essential.
>
> [snip]

Switching back to Python: it probably wouldn't be very hard to delete 
the dictionary which holds all variables initialized by a module (and 
those variables may hold references to data, functions and class 
definitions) but what if - for instance - one such variable contained 
data needed for subsequent calculations? There's no general way to 
determine what data is safe to keep and what should be discarded and 
recalculated.

In a limited way - e.g. just to replace a simple, non-aliased function 
which doesn't have side effects - it could be done safely, of course. 
But for a debugger it would be very hard, if not impossible to 
determine if those conditions are met. 

A Python module is *not* a library: it's a piece of code which, when 
executed, will build certain data structures, which you can use from 
then on. Correctly building those data structures may or may not depend 
on executing that code in full and the exact same order it's in the 
file. Just take a look at the (admittedly silly) example below.


    def _one():
        return 0 # Oops!

    one = _one


Now what would happen if the '_one()' is corrected (it surely needs to 
be!) and only the 'def _one():' function is reloaded? That wouldn't 
change 'one' at all. And so I'll restate: there is no general way of 
importing or reloading part of a module which is guaranteed to work.


>Recall again that I'm not suggesting that Python be changed, at 
>least not before Python 3k. I'm just pointing out what would make a 
>better language.

There's no need to be defensive, we all like to bounce our ideas off 
others. I, for one, just don't like this particular idea.


Robert Amesz