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 "::".  (Remember, I
specifically said that every usage of an object from another module
would have an explicit module identifier.)  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.

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

> If unused imports bother you, well, the other day I saw an
> announcement here for a Python code checker. Perhaps it can check
> that too. If not, perhaps its maker(s) may include it in the next
> version if you ask it nicely enough. ("Please? Pretty please? ;-) )

I'd rather just specify my modules at each use.  But certainly a
checker would be nice in lieu of this.

> >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.  It is very useful
to have this work reliably for less severe environments too.  One
might argue that the complexity is not worth the gain, but I wasn't
arguing for anything more complicated -- just something different.

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.

|>oug