From: Geoff T. <gta...@na...> - 2001-02-06 23:04:32
|
Fixed PSP class name generation -- now all non-alphanumeric characters are converted to underscores; before, if the path of your PSP included something like a "~" it would break. Also, fixed ThreadedAppServer and AsyncThreadedAppServer so that if a header is set to something other than a string (for example, setting "Status" to an integer) it works properly. -- - Geoff Talvola Parlance Corporation gtalvola@NameConnector.com |
From: Chuck E. <ec...@mi...> - 2001-02-06 23:18:56
|
At 06:10 PM 2/6/2001 -0500, Geoff Talvola wrote: >Fixed PSP class name generation -- now all non-alphanumeric characters are >converted to underscores; before, if the path of your PSP included >something like a "~" it would break. I think it would be safer to replace non-alphanumeric characters with their hex code equivalent so that if two different PSP pages had non-alphanumeric characters in the same position, they wouldn't clobber each other. If the character is in a variable c, then hex(ord(c))[2:] does the trick. At least on Python 2.0; I don't know how old hex() is. Even that isn't guaranteed, but it's probably in the realm of "will never really happen". Perhaps an ultimate solution would be to create truly unique names and a dictionary mapping path to class name. Some thoughts for the PSP guys, -Chuck |
From: Geoff T. <gta...@na...> - 2001-02-06 23:25:41
|
Chuck Esterbrook wrote: > At 06:10 PM 2/6/2001 -0500, Geoff Talvola wrote: > >Fixed PSP class name generation -- now all non-alphanumeric characters are > >converted to underscores; before, if the path of your PSP included > >something like a "~" it would break. > > I think it would be safer to replace non-alphanumeric characters with their > hex code equivalent so that if two different PSP pages had non-alphanumeric > characters in the same position, they wouldn't clobber each other. > > If the character is in a variable c, then hex(ord(c))[2:] does the trick. > At least on Python 2.0; I don't know how old hex() is. > > Even that isn't guaranteed, but it's probably in the realm of "will never > really happen". > > Perhaps an ultimate solution would be to create truly unique names and a > dictionary mapping path to class name. > > Some thoughts for the PSP guys, > -Chuck This change sounds like a good idea, but it would make the tracebacks you get from a PSP error even more confusing than they are already. So I'd recommend switching to a new naming strategy for the PSP classes at the same time we fix the PSP error reporting. -- - Geoff Talvola Parlance Corporation gtalvola@NameConnector.com |
From: Chuck E. <ec...@mi...> - 2001-02-06 23:29:44
|
At 06:31 PM 2/6/2001 -0500, Geoff Talvola wrote: >This change sounds like a good idea, but it would make the tracebacks you >get from a PSP error even more confusing than they are already. So I'd >recommend switching to a new naming strategy for the PSP classes at the >same time we fix the PSP error reporting. Then I would recommend: - replacing non-alphanumerics with underscores - attaching a unique id to the end of the class name - using a dictionary to map PSP paths to their corresponding class names This could probably be done separate from the error reporting. BTW do you guys have any idea how we're going to fix the PSP line numbers in tracebacks? -Chuck |
From: Jay L. <js...@js...> - 2001-02-07 00:32:35
|
I do not think this is possible, and I don't really see the need. If you can't figure out from the servlet class where that function is in your PSP source, then you've got too much python in your psp. I think. ;) Jay Chuck Esterbrook wrote: > > BTW do you guys have any idea how we're going to fix the PSP line > numbers in tracebacks? > > -Chuck > |
From: Geoff T. <gta...@na...> - 2001-02-07 16:19:03
|
There's one other aspect of PSP error reporting that bothers me that should be really easy to fix: The generated PSP classes look like: ##### try: import BaseClass except: pass class _My_PSP_Page(BaseClass.BaseClass): ... ##### This means that if there's some error in importing BaseClass, you get a NameError in the class definition, instead of getting a traceback from "import BaseClass" which would be much more useful. I think that we should remove the try-except-pass around "import BaseClass", but maybe there's some reason for the try-except-pass that I can't think of. -- - Geoff Talvola Parlance Corporation gtalvola@NameConnector.com |
From: Geoff T. <gta...@na...> - 2001-02-07 16:15:27
|
Anything is possible -- this is Python after all :-) You could embed special comments in your generated Python file that refer to the line number in the PSP file. For example, you could append "### Line <linenum>" to the end of each line in the generated file. Then wrap the whole thing in a custom exception handler that looks at the line in the generated servlet that caused the error, parses the line number, and then dumps out the line number and contents of the corresponding line in the PSP file. You might not think this is needed, but I've found myself making boneheaded errors in my PSP and wishing for this feature... Jay Love wrote: > I do not think this is possible, and I don't really see the need. > If you can't figure out from the servlet class where that function is in > your PSP source, then you've got too much python in your psp. I think. ;) > > Jay > > Chuck Esterbrook wrote: > > > > > BTW do you guys have any idea how we're going to fix the PSP line > > numbers in tracebacks? > > > > -Chuck > > -- - Geoff Talvola Parlance Corporation gtalvola@NameConnector.com |
From: Jay L. <js...@js...> - 2001-02-08 00:22:17
|
I had the same idea. I'll add it to my todo list. Jay On 07 Feb 2001 11:21:24 -0500, Geoff Talvola wrote: > Anything is possible -- this is Python after all :-) > > You could embed special comments in your generated Python file that refer to the line number in the PSP file. For example, you could append "### Line <linenum>" to the end of each line in the generated file. Then wrap the whole thing in a custom exception handler that looks at the line in the generated servlet that caused the error, parses the line number, and then dumps out the line number and contents of the corresponding line in the PSP file. > > You might not think this is needed, but I've found myself making boneheaded errors in my PSP and wishing for this feature... > > Jay Love wrote: > > > I do not think this is possible, and I don't really see the need. > > If you can't figure out from the servlet class where that function is in > > your PSP source, then you've got too much python in your psp. I think. ;) > > > > Jay > > > > Chuck Esterbrook wrote: > > > > > > > > BTW do you guys have any idea how we're going to fix the PSP line > > > numbers in tracebacks? > > > > > > -Chuck > > > > > -- > > > - Geoff Talvola > Parlance Corporation > gtalvola@NameConnector.com > > > _______________________________________________ > Webware-discuss mailing list > Web...@li... > http://lists.sourceforge.net/lists/listinfo/webware-discuss |
From: Geoff T. <gta...@na...> - 2001-02-08 18:54:47
|
I fixed a somewhat obscure bug in HTTPRequest.py that caused an exception when POSTing data that didn't come from an HTML form (one example is an XML-RPC request which contains XML-encoded parameters instead of URL-encoded parameters like a regular form POST). This error only happens in Python 2.0, not in Python 1.5.2, due to a change in the way that the FieldStorage class in the cgi module works between 1.5.2 and 2.0. -- - Geoff Talvola Parlance Corporation gtalvola@NameConnector.com |
From: Geoff T. <gta...@na...> - 2001-02-23 17:53:41
|
I checked in a fix to the PSP multiple inheritance. The Hello.psp example page uses a construct like the following: <%@ page imports = "Examples:ExamplePage"%> <%@ page extends="ExamplePage"%> where Examples is a package name, and ExamplePage is the name of a module as well as the name of the class within the module. But it could easily be the case that Examples.py is a module, and ExamplePage is the class within that module. PSP can't tell which is the case at the time it generates the servlet, so I've fixed it so that the generated code actually checks the type of ExamplePage at runtime when the servlet is first imported, and if it's a module, it uses ExamplePage.ExamplePage as the base class, otherwise it uses ExamplePage as the base class. This works correctly for all cases that I could think of. -- - Geoff Talvola Parlance Corporation gtalvola@NameConnector.com |
From: Geoffrey T. <gta...@na...> - 2002-04-12 15:13:30
|
New setting 'ReportRPCExceptionsInWebKit': 1 means report exceptions in RPC servlets in the same way as exceptions in other servlets, i.e. in the logfiles, the error log, and/or by email. 0 means don't report the exceptions on the server side at all; this is useful if your RPC servlets are raising exceptions by design and you don't want to be notified. Note that in release 0.7, there was no exception reporting on the server side in RPC servlets; if you want to get the same behavior in this release you'll have to set this setting to 0. - Geoff |