|
michael bayer
mike_mp at zzzcomputing.com
Sun Jun 19 22:14:21 EDT 2005
On Jun 19, 2005, at 6:34 PM, Graham Dumpleton wrote: > I would advise against trying to accomodate ".pyc" files. If you > were to > do this you will in practice have to monitor the timestamps on both > the > ".py" and ".pyc" files and contend with issues such as what to do when > the ".pyc" file is removed but the ".py" still exists but you were > originally > loaded from the ".pyc" file. Similarly, what do you do if you are > loaded > from the ".pyc" file and the ".py" file is removed. Does this imply > that > the user is intending the page to now no longer be available. Another > cases is what do you do if you are loaded from the ".pyc" file and the > ".py" file modification time is changed to be older than what it > was before. > Do you take this as meaning that an older file has been restored and > that should be used instead. As you can see you have to make various > assumptions and in some respects hope for the best. Although it can > be made to work in a reasonably sensible way, I found it complicates > the code unnecessarily and not worth the trouble, especially when > Apache generally runs as a user where ".pyc" files can't be created in > the first place. ah well, I can definitely make assumptions as I'm talking specifically about modules loaded for Myghty, and the primary ".py" modules I am loading were generated from template files, so its already a given that there is a "data directory" configured where the Apache process can write .py files, and theres no problem assuming that a .py file must exist for each .pyc file else it gets recreated by the template, and they arent really part of a "package". For a large set of several hundred or thousands of templates, which are released from memory on a least-recently-used scheme, a lot of them will be falling out of memory and getting re-loaded back in again repeatedly; the .pyc factor has a sizeable impact on how much work the server has to do, particularly upon startup or creation of new child processes, and also within setups that are sensitive to "thrashing". I also have support for plain .py modules with callable functions/ objects in the spirit of Vampire/Publisher, but similarly they are just the end-points to handling a request...they arent really meant to be imported by other modules and I only seek to support basic reloading functionality for them; if you change the back-end to code you would still have to restart the server. Generally I would base module loading/reloading upon the existence/timestamp of the .py file, and then look for the .pyc file existence/timestamp as a second step, the way imp.load_source does (which is what Im using now). -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mm_cfg_has_not_been_edited_to_set_host_domains/pipermail/mod_python/attachments/20050619/ebf87abd/attachment-0001.html
|