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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4