|
Graham Dumpleton
graham.dumpleton at gmail.com
Tue Jan 13 01:56:27 EST 2009
2009/1/13 Tim Valenta <tonightslastsong at gmail.com>: > I'm using 2.5.2, and so I suppose there could be a slight difference > in operation compared to plain old 2.5. > > I may just end up trying to use a different solution. My goal in > using mod_python initially was to keep things simple and not bloated. Hmmm, mod_python actually has a bit of a reputation for being bloated. :-) > All I needed was a basic template of my own, and then I would be done, > putting it into the hands of my project website's community. I'll > certainly investigate some more options though. They may in fact be > simpler, especially as Python is moving into its 3.0 days. And that is one of the problems with mod_python. At this stage it looks highly unlikely that it will be ported to Python 3.0. For a lightweight solution, suggest you look at: http://werkzeug.pocoo.org/ Can run on pure Python WSGI server, mod_wsgi, or fastcgi/scgi/ajp using flup. Graham > Thanks again-- I'll see what I can figure out. > > Tim > > On Mon, Jan 12, 2009 at 11:36 PM, Graham Dumpleton > <graham.dumpleton at gmail.com> wrote: >> What version of Python are you using? It is possible that if using >> version of Python newer than what that stuff was originally written >> against, that it is misbehaving. Have seen one other report of odd >> stuff happening. I don't use mod_python any more and don't really have >> time to go digging in to why. Really don't understand why people even >> want to keep writing stuff to mod_python specific APIs when better >> options exist these days for Python web applications. >> >> Graham >> >> 2009/1/13 Tim Valenta <tonightslastsong at gmail.com>: >>>> You should be able to add multiple directories and so long as a single >>>> Python module code file, should be found even when using 'import'. >>> >>> I tried adding my 'subDir'' to the path, so that it looks like this: >>> PythonOption mod_python.importer.path "['~' , '~/include/']" >>> My 'import' keyword attempts still failed when trying to import across >>> this 'include' folder into a specific module file residing there. >>> >>> I simplified the experiment down to the above importer.path, and just >>> ./A.py which uses a keyword 'import' to try to grab C.py from this >>> 'include' folder. This had surprisingly still lead to failure to find >>> the module. >>> >>>> 2009/1/13 Tim Valenta <tonightslastsong at gmail.com>: >>>>> Thank you for the links-- they prove useful. >>>>> >>>>> Capitalization shouldn't be an issue here... When I began learning >>>>> Unix a good while back, I quickly cast off relying on the OS to >>>>> 'figure it out'. I've been keeping everything case sensitive. >>>>> >>>>> Backing up to something foundational: I seem to be able to use the >>>>> import_module() method without problems now, but practically any use >>>>> of standard python 'import'/'from' keywords fails. The only success I >>>>> get is when the desired module is in the same directory as the one >>>>> trying to use the 'import' keyword. Does this stem from the fact that >>>>> import_module isn't look for packages, but rather specific files? Is >>>>> it for that reason that I can't use >>>>> from subDir import C >>>>> or, the equally broken, >>>>> import subDir.C >>>> >>>> Packages not supported with mod_python module importer, so these fall >>>> through import_module and uses standard Python import mechanism. >>>> >>>>> Jiggering around with adding more entries in importer.path to my >>>>> subdirectories doesn't seem to have any effect. >>>> >>>> You should be able to add multiple directories and so long as a single >>>> Python module code file, should be found even when using 'import'. >>>> >>>> Graham >>>> >>>>> If the 'import' >>>>> keyword really is bound to it's working directory only, I will likely >>>>> in fact have to use import_module() is several places, rather than >>>>> just at the head of the request (./A.py) >>>>> >>>>> Despite my general lack of success, I appreciate the comments you've >>>>> made along the way. >>>>> >>>>> Tim >>>>> >>>>> On Mon, Jan 12, 2009 at 10:40 PM, Graham Dumpleton >>>>> <graham.dumpleton at gmail.com> wrote: >>>>>> 2009/1/13 Tim Valenta <tonightslastsong at gmail.com>: >>>>>>>> You just need to ensure you set mod_python's own module search path, >>>>>>>> ie. mod_python.importer.path >>>>>>> >>>>>>> And yet, as I've now removed my www directory from my PythonPath, I >>>>>>> actually get limited functionality out of the mod_python imports. >>>>>>> I've got my apache conf file globally applying the option: >>>>>>> >>>>>>> PythonOption mod_python.importer.path "['~']" >>>>>>> Also have tried using an absolute path, which is producing the same >>>>>>> functionality: >>>>>>> PythonOption mod_python.importer.path "['V:/www/']" >>>>>>> >>>>>>> My main module ('A') is requested by Apache in my browser, which uses >>>>>>> import_module to find and import file B. File B is in the same >>>>>>> directory as A, and they only way it was found was through my apache >>>>>>> conf noted above. This part works just fine, but two cases develop >>>>>>> from here: >>>>>>> >>>>>>> 1) If I use module B to import a third module 'C', I can't seem to >>>>>>> make it find module C if it's in a subdirectory. For instance, doing >>>>>>> either 'import subDirectory.moduleC' or doing >>>>>>> 'apache.import_module("subDirectory/moduleC")' results in a failure to >>>>>>> find the module. Note that in this case of subdirectories, I'm >>>>>>> intentionally avoiding absolute paths to reach my modules. I only >>>>>>> want to get absolute in my Apache conf. On the flip side, if module C >>>>>>> is in the same local directory as A and B, then mod_python finds >>>>>>> module C just fine. >>>>>> >>>>>> Try: >>>>>> >>>>>> apache.import_module("./subDirectory/moduleC.py") >>>>>> >>>>>>> 2 ) If I place C in the same directory as A and B, so that mod_python >>>>>>> finds it, I tried using the natural Python 'import' keyword in B to >>>>>>> import C. According to what I understand, this should be fine for >>>>>>> auto-reloading, since A imports B via import_module, and so then B can >>>>>>> use either importing strategy to get C in the picture because >>>>>>> mod_python uses import_module behind the scenes anyway. In this >>>>>>> setup, my caching issue remains, and changes to C are definitely not >>>>>>> reflected in apache until a server restart. Again note that it >>>>>>> doesn't matter if I make B use the 'import' keyword or the >>>>>>> apache.import_module() method. Both result in failure to reload. >>>>>>> >>>>>>> I can't seem to diagnose what's even wrong, since the only reason >>>>>>> module A, B, or C is being found in the first place is because of my >>>>>>> importer.path variable is set in httpd.conf. I've been using >>>>>>> practically empty files to test this. Each file contains no more than >>>>>>> 5 lines to get the modules imported and then to write out a >>>>>>> confirmation to the screen that it worked. >>>>>>> >>>>>>> Wisdom to offer? >>>>>> >>>>>> Yes, from memory the module importer isn't properly case insensitive >>>>>> on Windows or MacOS X where file systems is case insensitive. Thus, >>>>>> make sure your imports match exactly the case of the directories/files >>>>>> in the file system. >>>>>> >>>>>> Also, use: >>>>>> >>>>>> from mod_python import apache >>>>>> apache.log_error('__name__ = %s' % repr(__name__)) >>>>>> apache.log_error('__file__ = %s' % repr(__file__)) >>>>>> >>>>>> in modules so that information about imported files is logged as >>>>>> imported. This will tell you which files are being imported. >>>>>> >>>>>> With PythonDebug On you should also see messages in Apache error logs >>>>>> describing when they are being imported, initially and when changed. >>>>>> >>>>>> You can also write some code which extracts out of the mod_python >>>>>> importer cache the details of everything that has been loaded and the >>>>>> relationships. The function to call is: >>>>>> >>>>>> from mod_python import apache >>>>>> data = apache.request_modules_graph() >>>>>> >>>>>> write that to a file and run: >>>>>> >>>>>> http://www.graphviz.org/ >>>>>> http://www.graphviz.org/Download_windows.php >>>>>> >>>>>> on it. >>>>>> >>>>>> Graham >>>>>> >>>>>>>> Now you do realise you don't need to convert 'import' to >>>>>>>> import_module() everywhere? >>>>>>>> >>>>>>>> The 'import' directive when used inside a file which was already >>>>>>>> managed by mod_python calls import_module() internally anyway. >>>>>>>> >>>>>>>> You just need to ensure you set mod_python's own module search path, >>>>>>>> ie. mod_python.importer.path >>>>>>>> >>>>>>>> Graham >>>>>>>> >>>>>>>> 2009/1/12 Tim Valenta <tonightslastsong at gmail.com>: >>>>>>>> > Okay, I think I'm on the same page as you now-- I've been playing >>>>>>>> > around with it and it seems that when I leave my PythonPath to find my >>>>>>>> > import modules, I definitely get no auto reloading goodness, while >>>>>>>> > when I specify the root path to find them as files, rather than as >>>>>>>> > modules (as explained in that documentation you linked to), things >>>>>>>> > seem to work as expected. >>>>>>>> > >>>>>>>> > I wasn't getting any warnings in my apache log, and after putting >>>>>>>> > together the details, I shouldn't be expecting any of that behavior >>>>>>>> > with two of the same module in memory. My issue seems to be simply in >>>>>>>> > avoiding letting my PythonPath find my code. >>>>>>>> > >>>>>>>> > Thank you much, >>>>>>>> > Tim >>>>>>>> > >>>>>>>> > On Sun, Jan 11, 2009 at 9:39 PM, Graham Dumpleton >>>>>>>> > <graham.dumpleton at gmail.com> wrote: >>>>>>>> >> 2009/1/12 Tim Valenta <tonightslastsong at gmail.com>: >>>>>>>> >>> Okay, that makes sense. My PythonPath system var definitely includes >>>>>>>> >>> my www directory. >>>>>>>> >> >>>>>>>> >> That in itself may not be enough to cause problem. You should actually >>>>>>>> >> see a warning in Apache error log complaining you have done this. That >>>>>>>> >> is, overlapped sys.path with directories that mod_python module >>>>>>>> >> importer uses. >>>>>>>> >> >>>>>>>> >> The real problem with doing this overlapping is that a module which >>>>>>>> >> wasn't one managed by mod_python, ie., standard Python module, imports >>>>>>>> >> something from the www directory, which also happens to be a handler >>>>>>>> >> module, there will actually be too copies in memory and so can give >>>>>>>> >> unexpected results. >>>>>>>> >> >>>>>>>> >> Graham >>>>>>>> >> >>>>>>>> >>> I had been using a forced path in my apache conf >>>>>>>> >>> file to point to '~', for simple reference for the time being. >>>>>>>> >>> >>>>>>>> >>> I think my problem is simply that the modules I'm trying to import >>>>>>>> >>> aren't 'candidates' for reloading. Other than that, all other modules >>>>>>>> >>> should already have been chained together with these >>>>>>>> >>> apache.load_module calls. My test case was pretty simple-- just two >>>>>>>> >>> scripts, the first loading the second. >>>>>>>> >>> >>>>>>>> >>> Tim >>>>>>>> >>> >>>>>>>> >>> On Sun, Jan 11, 2009 at 8:25 PM, Graham Dumpleton >>>>>>>> >>> <graham.dumpleton at gmail.com> wrote: >>>>>>>> >>>> 2009/1/12 Tim Valenta <tonightslastsong at gmail.com>: >>>>>>>> >>>>> Apologies for more trouble on the caching issue-- I've been adapting >>>>>>>> >>>>> some of my scripts over to this apache.load_module function, but I >>>>>>>> >>>>> don't think I'm seeing resolution to the issue. If I've read the >>>>>>>> >>>>> documentation properly, it seems that the PythonOption for >>>>>>>> >>>>> auto-reloading is set to On by default, so to be clear, I haven't put >>>>>>>> >>>>> a line for that in my httpd.conf file. Are there any other tricks, or >>>>>>>> >>>>> have I simply misread the documentation? I still have to restart the >>>>>>>> >>>>> Apache service in order to push the changes. >>>>>>>> >>>> >>>>>>>> >>>> Reloading does not work for any Python modules/packages installed in >>>>>>>> >>>> standard Python module search path. Thus, if you have set PythonPath >>>>>>>> >>>> to some directory where you store your modules, or if they are in >>>>>>>> >>>> system site-packages directory, they are not candidates for reloading. >>>>>>>> >>>> >>>>>>>> >>>> Where are the modules you are modifying and expecting to be reloading >>>>>>>> >>>> located? Is that location on sys.path, or have you explicitly setup >>>>>>>> >>>> mod_python module importer path to tell it where they are? >>>>>>>> >>>> >>>>>>>> >>>> From within running application, print out __name__ from the module >>>>>>>> >>>> you have loaded and are expecting to be reloadable, What is it? Does >>>>>>>> >>>> it look like a normal module name or something magic? >>>>>>>> >>>> >>>>>>>> >>>> How was that module imported? There needs to be a chain from >>>>>>>> >>>> mod_python handler for imports right down through to all modules you >>>>>>>> >>>> want reloadable. If there aren't, for example, you are using >>>>>>>> >>>> import_module() from a normal Python module which isn't a candidate >>>>>>>> >>>> for reloading, you will not see the depth checking for reloading >>>>>>>> >>>> occurring as you might expect. >>>>>>>> >>>> >>>>>>>> >>>> Graham >>>>>>>> >>>> >>>>>>>> >>>>> Tim >>>>>>>> >>>>> >>>>>>>> >>>>> On Sun, Jan 11, 2009 at 2:32 PM, Tim Valenta <tonightslastsong at gmail.com> wrote: >>>>>>>> >>>>>> Despite the jab at Windows, the site will be deployed on a Unix >>>>>>>> >>>>>> machine. I just prefer Windows for ease of use, especially since my >>>>>>>> >>>>>> wife has zero experience on a unix terminal or in the dearth of truly >>>>>>>> >>>>>> professional software found on the Unix/Linux platform. So yes, in >>>>>>>> >>>>>> the end it will be on a "real" operating system, But for now I'm >>>>>>>> >>>>>> willingly sticking to a more user-friendly environment for the simple >>>>>>>> >>>>>> folk. >>>>>>>> >>>>>> >>>>>>>> >>>>>> Given the characteristics of PHP that allow it to circumvent this >>>>>>>> >>>>>> caching stuff, I still think a nice little friendly red-flag reminder >>>>>>>> >>>>>> on the main mod_python tutorial should point out this limitation of an >>>>>>>> >>>>>> Apache module like this, for those of us like me, who would have gone >>>>>>>> >>>>>> many months more before having every accidentally found this manual >>>>>>>> >>>>>> import method. >>>>>>>> >>>>>> >>>>>>>> >>>>>> On Sun, Jan 11, 2009 at 2:23 PM, Graham Dumpleton >>>>>>>> >>>>>> <graham.dumpleton at gmail.com> wrote: >>>>>>>> >>>>>>> >>>>>>>> >>>>>>> 2009/1/12 Tim Valenta <tonightslastsong at gmail.com>: >>>>>>>> >>>>>>> >> Still not short enough, so much so I stopped part way through. >>>>>>>> >>>>>>> > >>>>>>>> >>>>>>> > And for that I apologize. I do appreciate the straight answer given, >>>>>>>> >>>>>>> > though I would appreciate much more the addition of that fact in some >>>>>>>> >>>>>>> > point-blank documentation that was easy to find. I have scoured the >>>>>>>> >>>>>>> > mod_python archives by search engine and came out utterly empty >>>>>>>> >>>>>>> > handed. I knew what the problem was, but I could find nothing to >>>>>>>> >>>>>>> > remedy the issue. I haven't encountered anything quite like this in >>>>>>>> >>>>>>> > my adventures with PHP, perl, or other similar scripting languages >>>>>>>> >>>>>>> > piloted by Apache. It raises a valid concern to which I ideally >>>>>>>> >>>>>>> > should have found answers very quickly. >>>>>>>> >>>>>>> > >>>>>>>> >>>>>>> > I hope this cures the subsequent issue given in the latter half of my message. >>>>>>>> >>>>>>> >>>>>>>> >>>>>>> PHP is specifically designed for web applications and it purposely >>>>>>>> >>>>>>> throws away all code at the end of each request and thus is reloading >>>>>>>> >>>>>>> it all on every request. Have a read of: >>>>>>>> >>>>>>> >>>>>>>> >>>>>>> http://blog.ianbicking.org/2008/01/12/what-php-deployment-gets-right/ >>>>>>>> >>>>>>> >>>>>>>> >>>>>>> I would be very surprised if mod_perl auto reloaded code as it is >>>>>>>> >>>>>>> similar to Python in that you are applying a non web language to the >>>>>>>> >>>>>>> web. Only way perl code would be reload is if you were running them as >>>>>>>> >>>>>>> CGI scripts. If you run Python as CGI scripts you will get reloading >>>>>>>> >>>>>>> as well, but as with anything CGI, much slower. >>>>>>>> >>>>>>> >>>>>>>> >>>>>>> BTW, maybe read: >>>>>>>> >>>>>>> >>>>>>>> >>>>>>> http://blog.dscpl.com.au/2008/12/using-modwsgi-when-developing-django.html >>>>>>>> >>>>>>> >>>>>>>> >>>>>>> For WSGI hosted Python web application, this provides auto reloading >>>>>>>> >>>>>>> on code changes. You do need to use a real operating system though, >>>>>>>> >>>>>>> and not Windows. >>>>>>>> >>>>>>> >>>>>>>> >>>>>>> Graham >>>>>>>> >>>>>>> >>>>>>>> >>>>>>> > Tim >>>>>>>> >>>>>>> > >>>>>>>> >>>>>>> > On Sat, Jan 10, 2009 at 10:23 PM, Graham Dumpleton >>>>>>>> >>>>>>> > <graham.dumpleton at gmail.com> wrote: >>>>>>>> >>>>>>> >> >>>>>>>> >>>>>>> >> 2009/1/11 Tim Valenta <tonightslastsong at gmail.com>: >>>>>>>> >>>>>>> >> > Hello all-- I've been experiencing a caching issue from the >>>>>>>> >>>>>>> >> > very beginning of my use of mod_python... It's been at least 2 months now, >>>>>>>> >>>>>>> >> > and I keep running into actual issues that prevent me from coding. >>>>>>>> >>>>>>> >> > I have a knack for over-explaining, so I'll try to keep this concise yet >>>>>>>> >>>>>>> >> > descriptive. >>>>>>>> >>>>>>> >> >>>>>>>> >>>>>>> >> Still not short enough, so much so I stopped part way through. >>>>>>>> >>>>>>> >> >>>>>>>> >>>>>>> >> The simple matter of it is that mod_python does not do deep checking >>>>>>>> >>>>>>> >> of code for changes, nor does it automatically restart the process >>>>>>>> >>>>>>> >> when code is changed. Thus the need to restart Apache when you make >>>>>>>> >>>>>>> >> code changes to anything imported from sys.path is expected and normal >>>>>>>> >>>>>>> >> behaviour. >>>>>>>> >>>>>>> >> >>>>>>>> >>>>>>> >> The only time any code is automatically reloaded is the direct code >>>>>>>> >>>>>>> >> files imported by mod_python using its own special module importer. >>>>>>>> >>>>>>> >> This is documented under 'import_module()' function in: >>>>>>>> >>>>>>> >> >>>>>>>> >>>>>>> >> http://www.modpython.org/live/current/doc-html/pyapi-apmeth.html >>>>>>>> >>>>>>> >> >>>>>>>> >>>>>>> >> Graham >>>>>>>> >>>>>>> >> >>>>>>>> >>>>>>> >> > I'm developing a site on my local machine, Windows Vista, using Apache 2.2.x >>>>>>>> >>>>>>> >> > and mod_python 3.3.1 . I'm a programmer for a living, and I'm not quick to >>>>>>>> >>>>>>> >> > point the finger at the language, *but* (you knew that was coming, eh?) I >>>>>>>> >>>>>>> >> > know my code isn't to blame for the issue: >>>>>>>> >>>>>>> >> > I write some basic code for an 'index.py' file, using the >>>>>>>> >>>>>>> >> > mod_python.publisher handler. 'index.py' includes other modules which I've >>>>>>>> >>>>>>> >> > coded from that same location, etc, etc. Nothing fancy. Any changes I make >>>>>>>> >>>>>>> >> > in the 'index.py' file will be reflected immediately on my local web server. >>>>>>>> >>>>>>> >> > On the other hand, any changes I make to the modules included via import >>>>>>>> >>>>>>> >> > from within 'index.py' are completely ignored by the web server. It took me >>>>>>>> >>>>>>> >> > a while to realize that my pages didn't reflect my code. I also discovered >>>>>>>> >>>>>>> >> > that the .pyc files had nothing to do with it. I finally just restarted the >>>>>>>> >>>>>>> >> > apache web service (which in fact runs as a service on my machine), and then >>>>>>>> >>>>>>> >> > my code finally gets pushed through to the web server. >>>>>>>> >>>>>>> >> > I've been looking around practically every other day for documentation on >>>>>>>> >>>>>>> >> > how to make apache/mod_python simply cut it out and stop caching my python >>>>>>>> >>>>>>> >> > code, but I've found nothing. You can imagine the annoyance this presents, >>>>>>>> >>>>>>> >> > since I have to restart my web server every single time I make even the >>>>>>>> >>>>>>> >> > slightest change to a 'utility.py' file, etc. >>>>>>>> >>>>>>> >> > I've been coping with the problem for a while now, but then I've found far >>>>>>>> >>>>>>> >> > more annoying issues recently. To abbreviate the problem into short terms, >>>>>>>> >>>>>>> >> > I've got a main module 'MAIN' which imports another module for a class >>>>>>>> >>>>>>> >> > 'CLASS'. CLASS also has a few imports, such as 'backend' stuff for >>>>>>>> >>>>>>> >> > interfacing with various databases, etc. We'll call the 'backend' module >>>>>>>> >>>>>>> >> > "BACKEND". Given the setup, any changes I make to CLASS or BACKEND require >>>>>>>> >>>>>>> >> > an apache restart in order to take effect. >>>>>>>> >>>>>>> >> > I have a function in CLASS which calls a function from it's imported BACKEND >>>>>>>> >>>>>>> >> > module. I tried adding a parameter to the BACKEND function in question, and >>>>>>>> >>>>>>> >> > properly passed said parameter while in CLASS, yet the mod_python debugger >>>>>>>> >>>>>>> >> > spits out an error about me having passed 3 arguments, when the BACKEND >>>>>>>> >>>>>>> >> > function takes exactly 2. This is outright false, since my function in >>>>>>>> >>>>>>> >> > BACKEND looks like: >>>>>>>> >>>>>>> >> > def getUsers(self, req, terms): >>>>>>>> >>>>>>> >> > >>>>>>>> >>>>>>> >> > and I'm calling it with >>>>>>>> >>>>>>> >> > self.backend.getUsers(self.req, search) >>>>>>>> >>>>>>> >> > >>>>>>>> >>>>>>> >> > In reality, my code dictates that I'm passing 3 (including the implicit >>>>>>>> >>>>>>> >> > 'self' argument), and BACKEND's 'getUsers' does in fact take exactly 3 >>>>>>>> >>>>>>> >> > arguments. Yet, the debugger is telling me that it takes only 2. >>>>>>>> >>>>>>> >> > I was trying to pass it 'req' because I wanted to investigate a little error >>>>>>>> >>>>>>> >> > in the code by printing something to the output HTML. So, my attempt is >>>>>>>> >>>>>>> >> > foiled, since somewhere something isn't being updated to what my most >>>>>>>> >>>>>>> >> > current code actually says. >>>>>>>> >>>>>>> >> > Just to test, I made the 'getUsers' function return immediately with a >>>>>>>> >>>>>>> >> > string of gibberish, like 'return "adsfasdfadsfa"'. this should make my >>>>>>>> >>>>>>> >> > other code spin wildly out of control and encounter errors, yet when I >>>>>>>> >>>>>>> >> > restart apache and test it... lo and behold, it's completely ignoring my >>>>>>>> >>>>>>> >> > goofy 'return' statement. The 'getUsers' function is still somehow >>>>>>>> >>>>>>> >> > returning valid data, as if the 'return' wasn't there at all! >>>>>>>> >>>>>>> >> > So then I tried causing actual syntax errors. The debugger caught this, >>>>>>>> >>>>>>> >> > much to my inner joy. So I tried causing a semantic error instead: >>>>>>>> >>>>>>> >> > referencing a non-existent attribute of a non-existent variable: >>>>>>>> >>>>>>> >> > madeUpVar.moo = 42 >>>>>>>> >>>>>>> >> > Syntactically, nothing wrong, but at run time it should most definitely >>>>>>>> >>>>>>> >> > encounter a NameError or something equally as realistic. But I restart >>>>>>>> >>>>>>> >> > apache, and... nothing. The line is completely ignored. >>>>>>>> >>>>>>> >> > Which leads me to believe that it's not actually being 'ignored' per se, but >>>>>>>> >>>>>>> >> > rather the code being compiled is not the same as the code in play within >>>>>>>> >>>>>>> >> > the web server. When I delete my .pyc files and restart apache and visit >>>>>>>> >>>>>>> >> > the URL that triggers my python code, my .py files are in fact being >>>>>>>> >>>>>>> >> > recompiled down to their byte code .pyc files. And clearly the interpreter >>>>>>>> >>>>>>> >> > is processing my code, since it flags me on improper syntax. Yet, no matter >>>>>>>> >>>>>>> >> > what kind of syntactically-sound nonsense I put into my code, the changes >>>>>>>> >>>>>>> >> > aren't being reflected in my web server. >>>>>>>> >>>>>>> >> > These problems come and go, and I've go better explanation than over zealous >>>>>>>> >>>>>>> >> > caching. I imagine that by tomorrow sometime when I start my computer up, >>>>>>>> >>>>>>> >> > the problem will have disappeared for the time being. >>>>>>>> >>>>>>> >> > I've cursed this computer up and down as I've tried to figure out ANYTHING >>>>>>>> >>>>>>> >> > that I can do to alleviate the issue, by to no avail. >>>>>>>> >>>>>>> >> > Anybody with counsel to spare my tired brain is welcome to share... >>>>>>>> >>>>>>> >> > _______________________________________________ >>>>>>>> >>>>>>> >> > Mod_python mailing list >>>>>>>> >>>>>>> >> > Mod_python at modpython.org >>>>>>>> >>>>>>> >> > http://mailman.modpython.org/mailman/listinfo/mod_python >>>>>>>> >>>>>>> >> > >>>>>>>> >>>>>>> >> > >>>>>>>> >>>>>>> > >>>>>>>> >>>>>> >>>>>>>> >>>>>> >>>>>>>> >>>>>> >>>>>>>> >>>>> _______________________________________________ >>>>>>>> >>>>> Mod_python mailing list >>>>>>>> >>>>> Mod_python at modpython.org >>>>>>>> >>>>> http://mailman.modpython.org/mailman/listinfo/mod_python >>> >> > > > > -- > "Thanksgiving Dinner sent you a message." > "If you are not a member, you need to join us." > "i was not declared before this scope." >
|