6 ms·

The problem really is Python import semantics. As soon as you can provide me with a way to say "this imported code is identical to the one you loaded before", I

by fijal 14y ago

The problem really is Python import semantics. As soon as you can provide me with a way to say "this imported code is identical to the one you loaded before", I'm fine with providing a way to save the JIT state. Note that "identical" means also module globals, state of sys.modules etc. etc. In short, the assumptions are all the same.

stcredzero 14y ago
> As soon as you can provide me with a way to say "this imported code is identical to the one you loaded before", I'm fine with providing a way to save the JIT state. How about an SHA2 hash of the source files?
- ot 14y ago
  That would not be sufficient. Python modules can execute arbitrary code at import time, so the behaviour could depend on a number of external factors, such as environment variables, other files, current time, response from a remote service (?!), etc...
  - stcredzero 14y ago
    That would not be sufficient in some corner cases. I think for a competent group running web application servers, which knows it needs to control such external factors, it could well be enough.
    - fijal 14y ago
      but this is not the attitude you have to have when writing compilers. from the compiler standpoint, it has to be correct, even in corner cases (which are not even as corner as you would like them to be). A competent group can leave a dormant process that communicates over pipe for example and then the warmup issue disappears (it does not really appear for long running web application servers to start with)
acdha 14y ago
Have you given up on automatic handling being feasible? It seems like the performance wins could be enough to justify something like a module-level constant explicitly stating that you're not doing metaprogramming, monkey-patching, etc. and allowing implementors to optimize as desired.

6 ms·

The problem really is Python import semantics. As soon as you can provide me with a way to say "this imported code is identical to the one you loaded before", I

by fijal 14y ago

stcredzero 14y ago
> As soon as you can provide me with a way to say "this imported code is identical to the one you loaded before", I'm fine with providing a way to save the JIT state. How about an SHA2 hash of the source files?
- ot 14y ago
  That would not be sufficient. Python modules can execute arbitrary code at import time, so the behaviour could depend on a number of external factors, such as environment variables, other files, current time, response from a remote service (?!), etc...
  - stcredzero 14y ago
    That would not be sufficient in some corner cases. I think for a competent group running web application servers, which knows it needs to control such external factors, it could well be enough.
    - fijal 14y ago
      but this is not the attitude you have to have when writing compilers. from the compiler standpoint, it has to be correct, even in corner cases (which are not even as corner as you would like them to be). A competent group can leave a dormant process that communicates over pipe for example and then the warmup issue disappears (it does not really appear for long running web application servers to start with)
acdha 14y ago
Have you given up on automatic handling being feasible? It seems like the performance wins could be enough to justify something like a module-level constant explicitly stating that you're not doing metaprogramming, monkey-patching, etc. and allowing implementors to optimize as desired.