reloading in 0.21

[bubblboy]

Hi,

There have been quite some discussions about reloading files that I
haven't really followed because up until recently, reload was working
fine for me. My application is just one code.py file ending with:

if __name__ == "__main__":
web.run(urls, globals(), web.reloader)

Using web.py 0.2, this worked just fine. Since the upgrade to 0.21, I
have to restart the server (built-in as well as lighttpd give the same
results) to make changes to the file take effect.

As far as I can remember I did not change anything important in the
file, it just doesn't work anymore now. Any ideas on what might be going on?

Greetings,
b^4

[Anand]

> Using web.py 0.2, this worked just fine. Since the upgrade to 0.21, I
> have to restart the server (built-in as well as lighttpd give the same
> results) to make changes to the file take effect.
>
> As far as I can remember I did not change anything important in the
> file, it just doesn't work anymore now. Any ideas on what might be
> going on?

There was a change in reload code from 0.2 to 0.21. But i don't think
it should change the reload behavior.
It was changed to fix reload problems when the urls are not in the
__main__ module.

Here is the difference between 0.2 and 0.21. Can you try replacing
the __import__ line with the old version.

Index: request.py
===================================================================
--- request.py (revision 149)
+++ request.py (revision 150)
@@ -115,9 +115,7 @@
if not hasattr(inp, '__call__'):
if autoreload:
# black magic to make autoreload work:
- mod = \
- __import__(
- fvars['__file__'].split(os.path.sep).pop().split
('.')[0])
+ mod = __import__(fvars['__name__'], None, None, [""])
#@@probably should replace this with some inspect magic
name = utils.dictfind(fvars, inp)
func = lambda: handle(getattr(mod, name), mod)

[bubblboy]

Yup, now that I changed it back to the old behaviour, reloading works
fine. Is that enough information or do you need more? Thanks btw, this
is a great fix in the mean time!

b^4

[BjornT]

I have big problems with restarting and reloading. Sometimes I have to
kill the lightttpd process, sometimes I have to kill the code.py
process other times I end up with a python <defunct> issue that I kill
by viewing the parent in the process tree. Cheetah templates cache
too, which sucks. I really am just getting started and it's kind of
annoying that these things are cached during development. Haven't
figured it all out quite yet.

[Justin Davis]

I'm not sure of your setup, but you're probably better off not doing
development in lighttpd. It's much easier to do development in the
integrated server and then push to lighttpd -- I only use lighttpd for
production so the only development I do on it are my tests.

-Justin

[bubblboy]

Justin Davis wrote:
> I'm not sure of your setup, but you're probably better off not doing
> development in lighttpd. It's much easier to do development in the
> integrated server and then push to lighttpd -- I only use lighttpd for
> production so the only development I do on it are my tests.
>
> -Justin
>
> On Jun 4, 7:36 pm, BjornT <bjorn.tipl...@gmail.com> wrote:
>> I have big problems with restarting and reloading. Sometimes I have to
>> kill the lightttpd process, sometimes I have to kill the code.py
>> process other times I end up with a python <defunct> issue that I kill
>> by viewing the parent in the process tree. Cheetah templates cache
>> too, which sucks. I really am just getting started and it's kind of
>> annoying that these things are cached during development. Haven't
>> figured it all out quite yet.

What's wrong with using lighttpd? If you set up web.py correctly and
make it use reloader and not cache the templates, there shouldn't be a
difference. It works fine here (with Anand's tip about 0.21).

To the original poster; are you sure you are using web.reloader as is
described in the tutorial on webpy.org?

Greetins,
b^4

[Justin Davis]

I don't think there's anything wrong with developing in lighttpd, I
just think you'll be better off using the built-in server for
development. When something goes wrong, you can check the output from
the server by just switching to that terminal window for easier error
tracking. When you forgot to copy a file to your static folder and
things are acting strange, the terminal has the 404 status code
sitting there. If you're more comfortable using lighttpd, don't let
me stop you -- however, having tried both I've found the built-in
server easier to use overall.

Cheers,
Justin

[Bjorn Tipling]

I am using web.reloader, but I still have to figure out how to stop the templates from caching. The .py files are updating with all the changes, right now it's just getting the templates to update.

[Aaron Swartz]

> I am using web.reloader, but I still have to figure out how to stop the
> templates from caching. The .py files are updating with all the changes,
> right now it's just getting the templates to update.

Call web.render with cache=False.

[Bjorn Tipling]

You know I think I noticed an issue with exceptions in templates and caching. If you have an error such as trying to reference properties of a misspelled dictionary name and it leads to an error, your broken template is cached even if you have called the template with the cache=False argument. If you fix the error the application will continue to throw the exception. I'm pretty sure that's what's happening here, but let me know if I'm off. It threw me for a loop while debugging.

[Bjorn Tipling]

No, that's not it, but there is something strange going on with caching. I have the following code:


class index:
    def GET(self,path):
        render = web.template.render('templates/', cache=False)
        infoObject = {"title":"Test page","header":'This is a test page',"body":"It is."}
        print render.test(infoObject)

and this my template:

$def with (infoObject)
<html>
    <head>
        <title>$infoObject["title"]</title>
    </head>
    <body>
        <h1>$infoObject["header"]</h1>
        <p>$infoObject["body"]</p>
    </body>
</html>

and if I misspell $infoObject["title"] as $InfoObjectd["title"] even if I fix the problem the cache isn't fixed unless I arbitrarily change some extra text in the template some where else. Like cut "infoObject" from where I didn't misspell it and paste it back and over the other instances.

[bubblboy]

Bjorn Tipling wrote:
> No, that's not it, but there is something strange going on with caching. I
> have the following code:
>
>
> class index:
> def GET(self,path):
> render = web.template.render('templates/', cache=False)
> infoObject = {"title":"Test page","header":'This is a test
> page',"body":"It is."}
> print render.test(infoObject)
>
> and this my template:
>
> $def with (infoObject)
> <html>
> <head>
> <title>$infoObject["title"]</title>
> </head>
> <body>
> <h1>$infoObject["header"]</h1>
> <p>$infoObject["body"]</p>
> </body>
> </html>
>
> and if I misspell $infoObject["title"] as $InfoObjectd["title"] even if I
> fix the problem the cache isn't fixed unless I arbitrarily change some extra
> text in the template some where else. Like cut "infoObject" from where I
> didn't misspell it and paste it back and over the other instances.

Sorry if I'm talking about things that are none of my business, but I
thought I would mention two things about your code that actually have
nothing to do with the problem:
- PEP 8 [1] recommends using underscores to concatenate words for
variables instead of camel-case (info_object) unless you are using
some library that already uses camel-case and have to follow it.
- The storage class makes your templates look nice :) try this one;

>>> import web
>>> a=web.storify(dict(spam="eggs", tasty="bacon"))
>>> print repr(a)
<Storage {'tasty': 'bacon', 'spam': 'eggs'}>
>>> print a.spam
eggs

Now you can use “a.spam” in your template instead of “a["spam"]”.

About your actual problem; I don't know what could cause that. Does this
also happen when you run web.py in stand-alone mode?

Greetings,
b^4

[1] http://www.python.org/dev/peps/pep-0008/

[Bjorn Tipling]

Thanks for showing me that web.storify, I will use it, it does look much better. As for the camel back identifiers, I read practically that entire PEB and man that guy is picky! Even for comments he says:

"

    Comments should be complete sentences.  If a comment is a phrase or
    sentence, its first word should be capitalized, unless it is an identifier
    that begins with a lower case letter (never alter the case of

    identifiers!).

    If a comment is short, the period at the end can be omitted.  Block
    comments generally consist of one or more paragraphs built out of complete
    sentences, and each sentence should end in a period.


    You should use two spaces after a sentence-ending period.

"

Wow. Well I can use either type of variable, I have no personal preference, but I like to stay consistent. Since I'll probably will be asking for help now and again, it makes sense to go by the PEB.  Also I am not sure what you mean by "running web.py in stand alone  mode."  Do you mean in the python console?

Thanks!

[rob]

So, is there a solution to this? web.reloader works with 0.2, but not
with 0.21 or trunk. What changed? Is there a fix (aside from changing
the __import__ line)?

Rob

[bubblboy]

PEP: Python Enhancement Proposal. The accepted proposals are
considered standards by most of the python community and it is
generally a good idea to follow them as closely as possible. Once
you'll get used to it you will notice how useful it is when all code
looks the same :) It makes it really easy to understand and read other
code. Note that PEP 8 is just one out of many; there is an entire PEP
just about how docstrings should be written, for example. I would most
certainly recommend having a look at the index ([1]) and reading the
documents relevant to your project.

By "running it in stand-alone mode" I mean doing something like this:

$ python code.py
http://0.0.0.0:8080/

Calling code.py this way makes it run on a built-in webserver that you
can access on port 8080 (as it says in the uri). This is useful for
debugging since you can rule out issues coming from the webserver
configuration.

Good luck and greetings,
b^4

[1] http://www.python.org/dev/peps/

[Bjorn Tipling]

You know for some reason the web.storify doesn't work for me in the python console:

http://pastebin.ca/557082

But it does work in the application.  Is that weird?

On 6/10/07, bubblboy <bubb...@gmail.com> wrote:

[Bjorn Tipling]

Nevermind, I had a web.pyc in that directory that was something else. Weird.

[BjornT]

Hi,

I actually have that old version still and my code.py will not update
if I change it. I have to restart the web server everytime. This is
really not an efficient way to figure things out. I am calling
web.reloader. I don't know what I can do anymore, any have any ideas?
This is my code.py:

#!/usr/bin/env python
import web
import sharewonders

urls = (
'/(.*)', 'colortool.index'
)

class index:
def GET(self):
print "Hello World!"
#nothing

class test:
def GET(self):
print "Test succeeded!"

web.webapi.internalerror = web.debugerror

if __name__ == "__main__": web.run(urls, globals(), web.reloader)

[Zekel]

Even with all the reload stuff, you still have to restart the
development server when you change the main python file. To make this
less painful I did the following:

1 - Launch run.py with with a shell script.

#!/bin/sh
while sleep 0; do
echo "RESTARTING (Press ^C twice to exit.)"
./run.py
echo "KILLED"
done

2 - Write the pid to file in run.py.

open('/tmp/webpy.pid', 'w').write(`os.getpid()`)

3 - Bind this shell script to a hotkey.

cat /tmp/webpy.pid | xargs kill

I'm on OS X, and I use Spark.app, which is free. I have to wrap it as
an applescript, which looks like this:
do shell script "cat /tmp/webpy.pid | xargs kill"

This makes development much more pleasant for me. Another thing you
might have it do is switch to your browser after you press the restart
hotkey. (Bind it in the kill script, not launch script.) Let me know
if anyone finds this useful or has any suggestions.

Developer's Site: http://www.shadowlab.org/Software/software.php?sign=Sprk
Download: http://www.shadowlab.org/Software/Spark/Spark.dmg.bin

[Bjorn Tipling]

Thanks a ton, I'll try this out.

[Bjorn Tipling]

I'm still having caching issues, even in files that are not the main code.py ... I have to continuously ps aux | grep www and then kill both lighttpd and code.py. Can I just like go in somewhere and disable caching? I don't want caching. I just want it to display what I tell it to. This is making development impossible.  I have upgraded 0.22 and no help.

Thanks in advance.

[Bjorn Tipling]

OK so I switched from using "from mything import myotherthing" to "import mything" and either that or some randomness has changed my caching issue. :/

[bubblboy]

Bjorn Tipling wrote:
> I'm still having caching issues, even in files that are not the main

> code.py... I have to continuously ps aux | grep www and then kill both

Development is not supposed to be done using an external webserver but
using webpy's internal webserver. Aside from that; have you already
tried deleting the sockets? These things caused weird caching issues I
could not explain (pages were cached even after restarting lighttpd), so
that might be a good thing to do. /etc/init.d/lighttpd stop && rm -f
/tmp/webpy.sock && /etc/init.d/lighttpd start.

Anyway, good luck.