>First of all, I would like to do some ego boosting. I think Python is
>one the most attractive languages I have seen. With Python you can write
>console programs and gui programs. The only type of programming left I
>do is html programming. I love PHP, but what makes Spyce better is it
>uses Python. Now all the programming I do can be in Python. I think the
>job you have done with Spyce is wonderful. Keep up the good work!
>With that said, I have some concerns, at the very least, I would like you
>to be aware of and at most a solution for. I asked you sometime ago
>about when Spyce has an error that it display what line had the problem
>in your web browser. You told me that you added it to the latest version
>of Spyce and you did. But the line number it displays does not match the
>line number in my .spy file. It is in the ballpark though, so it is
I know about this problem... (I think!) Are you using multi-line strings?
Those offset the line numbers, by the number of 'extra' lines per string.
It's a problem that is caused by the transformation into Python. It's not
at the top of my list of issues, but I will eventually get to it. Are
there other cases? If you could narrow it down to the basic syntactic
construct that offsets numbers, with an error in it, that would help. i.e.
Can you send me a file with a the most basic version of the problem? The
only one that I currently know about is the 'multi-line strings' case. If
you'd like to work on it, search for the 'rimtodo' comment in the
spyceCompile.py file. That's the point that needs the work. Otherwise, I
will get to it eventually.
>Another concern I have is .py files. I import .py files that I wrote in
>my .spy files. This works great except when I make a change to my .py
>file, the .spy file does not see that change. The only way I have found
>to force the .spy file to see my change is to restart the apache web
>server. Is there a better way?
Yes... It's called debug mode. When you're running a production server,
you don't want the engine to check the timestamp of so many files. It's a
major slowdown, and so debug is off by default. But, you do want this for
when you are prototyping. Check out:
and look at the 'debug' option.
This will recompile the Spyce file on every hit, and reload all the Spyce
modules. I'm not sure about Python modules. Get back to me on that one if
it does not work. I think that I can fix that too. Python usually checks
the system cache for Python modules that are already loaded, for
performance. I'm thinking that we can run the entire file in a restricted
execution environment that intercepts imports and reloads the module if
necessary (or something like that). We'll see... Another really simple fix
is to run in plain CGI mode. You'll get a fresh copy of the engine on each
invocation! That might do the trick for you as well.
>One last concern is using MySQLdb. I'm not sure if this is a problem
>with Spyce or MySQLdb. When I lock a table using this import and Spyce
>gets an error before the database close, the table stays locked until I
>restart apache. It's like Spyce never cleaned up my MySQLdb object.
Tiberius reported a simlar problem. I'm not sure what this is, but it
seems to be related to Python garbage collection. I think we resolved it
back then, but I can't remember how. I don't think it was something
related to Spyce in the end, but I could be mistaken. It could be that the
MySQLdb object is not properly written. I'm not sure, as I have not used
it. I would, however, recommend that you trace the garbage collection
calls, and see what's going on. Try the following spyce file
x = foo()
The output should be:
This indicates that the garbage collection is working, at least in this
simple example. The destroyed gets printed when x goes out of scope at the
end of spyceProcess function. This decrements the ref-count on the foo
object, and it gets collected, since its ref-count is zero. If you are
creating a MySQLdb object, it should be cleaning up after itself.
Perhaps you can look at the MySQLdb implementation, and understand why the
state of the database is remaining locked. Again, this could be unrelated
to Spyce and really be a MySQLdb issue; that's what I am hoping. Could you
give me a pointer to the code you are using? Does anyone else have
experience using this library?
All the best,