is there a way to warn about missing modules *without* runningpython?

[lkcl]

folks, hi,

although i know the answer to this question, i'm having difficulty
explaining it, to a user on the pyjamas list. i was therefore
wondering if somebody could also provide an answer, on this list, to
which i can refer the user.

to make it clear: the user is confused as to why the pyjamas compiler
(which strictly speaking isn't actually a compiler it's a "language
translator", translating from one dynamic language into another
dynamic language, feature-for-feature, concept-for-concept) is _not_
making any effort to help or advise the user at *COMPILE TIME* when
they make the mistake of trying to import a module that does not
exist. they are confused as to why they have to go to all the trouble
of executing the [translated] javascript code in a web browser engine,
where web browser engines are known to be a complete pain as far as
debugging is concerned, just to find out that they made a mistake in
mis-naming an import module.

in other words, they are confusing the concept of "python as a dynamic
language" with the concept of "compiler in the traditional static-
language-such-as-c-or-c++ sense".

i've tried explaining that the answer is because this has absolutely
****-all to do with pyjamas, and has everything to do with the
http://python.org programming language, but i'm not getting through to
them.

if someone could perhaps explain this (in a different way from me), in
the context of "python the programming language" and "python the
http://python.org interpreter", i.e. having absolutely nothing to do
with pyjamas, i would be most grateful, and it would benefit that
user's understanding of python.

many thanks,

l.

ref: http://groups.google.com/group/pyjamas-dev/browse_thread/thread/64cf948082bfec52?hl=en_US

 

[Steven D'Aprano]

to make it clear: the user is confused as to why the pyjamas compiler
(which strictly speaking isn't actually a compiler it's a "language
translator", translating from one dynamic language into another dynamic
language, feature-for-feature, concept-for-concept) is _not_ making any
effort to help or advise the user at *COMPILE TIME* when they make the
mistake of trying to import a module that does not exist.

Just because a module doesn't exist at compile time doesn't mean it won't
exist later on when the code is run.

And visa versa: just because the module exists when pyjamas "compiles"
the code doesn't mean it will still be there when you actually try to run
the code.

[...]

in other words, they are confusing the concept of "python as a dynamic
language" with the concept of "compiler in the traditional static-
language-such-as-c-or-c++ sense".

Neither Python, nor Javascript (as far as I know -- I welcome
corrections) do static linking. If your Python code relies on a library,
that library must be there *at runtime*, or you will get an error. This
is no different from C or C++ code using dynamic linking. This is very
common in e.g. Windows applications that use DLLs.

Python modules are, conceptually speaking, like DLLs. They are loaded at
runtime, not at compile time. This has many advantages over static
linking, but some disadvantages as well.

 

[Terry Reedy]

if someone could perhaps explain this (in a different way from me), in
the context of "python the programming language" and "python the
http://python.org interpreter", i.e. having absolutely nothing to do
with pyjamas, i would be most grateful, and it would benefit that
user's understanding of python.

I do not know the background of your user, but here is my try:
Loading a Python module at runtime is like loading a song, picture, or
web page. An import statement is like a web page link. If the name of
the resource is misspelled, or if the resource is not available when
requested, it cannot be loaded and the requesting progran can only
report an error. ImportError is equivalent to http's "40x: not found"
message. A web link that works one time may not work another time.

Terry Jan Reedy

 

[lkcl]

I do not know the background of your user, but here is my try:
Loading a Python module at runtime is like loading a song, picture, or
web page. An import statement is like a web page link.

thank you, terry - that's a good analogy.

l.

 

[lkcl]

Neither Python, nor Javascript (as far as I know -- I welcome
corrections) do static linking.

for the command-line versions of javascript such as spidermonkey, i
believe that a keyword/function is dropped into the global namespace -
"load", which take one argument (a filename).

in browsers, it's much more waffly: anything that is tagged as
"script language='javascript'" gets executed in a global namespace
(into which two strategically critical global variables have been
dropped: "window" and "document", which is really the only "real" clue
that you have that this is javascript in a web browser engine, not
javascript at a command-line).

so, if the DOM happens to ever get modified (typically using AJAX),
such that an additional node with a tag of "script" and an attribute
"language='javascript'" happens to get added, the browser engine
_happens_ to notice and _happens_ to execute the resultant newly-added
javascript.

this well-known but horribly archaic technique is about as close to
dynamic module loading that you're ever likely to get in web browsers.

everything else is "static", so to speak, and _everything_ operates
in one monster global namespace (on a per-page basis).

... but i digress

Python modules are, conceptually speaking, like DLLs. They are loaded at
runtime, not at compile time. This has many advantages over static
linking, but some disadvantages as well.

thank you, steve - i believe this is the crux of the matter (which
terry's analogy expanded on). much appreciated the replies.

l.