On Sat, 05 Jun 2010 06:42:44 -0700, lkcl wrote: > 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. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
