Re: [Twisted-web] pgasync (was: /freeform_post!!random causes exceptions)
Andrea, Thanks for your suggestions; sorry I've taken so long to get back to them, but I haven't had time to work on pgasync until now... On Thu, Jan 20, 2005 at 02:15:36AM +0100, Andrea Arcangeli wrote:
Next thing I had to fix to be able to login has been to add this:
[snip bool patch] I've patched that in, thanks.
With the above a good part of my app started working. But it's not enough.
Here a list of the remaining issues (which I believe aren't related anymore to the API, as far as I'm concerned the current adbapi wrapper is all I need ;).
1) the '%(xx)d' format for integeres/logs insn't recognized. I'd like to use "%(xx)d" to be strict for integers.
This is fixed.
btw, is there any difference in python between %u and %d at all?
Nope, I don't think so.
2) it cannot handle a ";" at the end of the sql string. so I deleted all the finals ";" and I left only the intermediate ones.
This is fixed as well.
3) it doesn't print the nevow url type, note that such parameter is just incidentally passed down to the sql query, and pgasync should ignore it instead of complaining since it never gets resolved
It's not trival to determine whether or not something gets resolved. If it's a keyword argument situation, then I need to search the format string for some variation of %(keyword)s. If it's just tuple-style, then I need to count the number of %s/d/whatevers and determine whether or not it's beyond the limit. This seems ugly, and needlessly expensive for a corner case; I think the right answer is, only pass things to format() that are intended to be formatted and made safe for insertion into SQL. But, then again, maybe I'm misunderstanding you. - Jamie
On Thu, Feb 17, 2005 at 01:27:30PM -0600, J Turner wrote:
Andrea,
Thanks for your suggestions; sorry I've taken so long to get back to them, but I haven't had time to work on pgasync until now...
No problem, take your time. Sorry for not having discussed things last time in IRC, but I was busy fighting with the mailing lists ;)
I've patched that in, thanks.
You're welcome ;).
This is fixed.
Ok fine!
Nope, I don't think so.
Ok, I also couldn't find anything in the docs, perhaps %u should start raising a deprecation warning, it's way confusing when two things do the same thing and you never know if they're really the same thing ;)
This is fixed as well.
fine, and this part I already fixed in my app too 8) I had no idea the ; was added by the lib. it's actually the only part I changed after the pgasync test, along with the compatibility code for the deferreds in interaction that should allow me now to exchange psycopg2 with pgasync back and forth with full compatibility.
It's not trival to determine whether or not something gets resolved. If it's a keyword argument situation, then I need to search the format string for some variation of %(keyword)s. If it's just tuple-style, then I need to count the number of %s/d/whatevers and determine whether or not it's beyond the limit.
This seems ugly, and needlessly expensive for a corner case; I think the right answer is, only pass things to format() that are intended to be formatted and made safe for insertion into SQL.
But, then again, maybe I'm misunderstanding you.
You got it perfectly right, and I see your point, it'd be an unnecessary slowdown to parse the string too. But you could silenty convert to string if you can't find the conversion type. In this case I'm suggesting to actually make it less strict but it simplfy my code a lot. I've tons of cases where I've a kwargs filled with stuff that is needed by lots of chained deferreds. Now the sql one is using a few of the kwargs entries, and then later on the email deferred uses other entries. So if I can work with a single kwargs that has all the arguments collected while the form action starts, the code is a lot simpler. So my suggestion is not to give it up, but to try to convert to string, and format it like string if __str__ did its job. Comments? As soon as we sorted out this last bit, I'll give it a new spin and perhaps it'll just work without a changing anything on my app.
At 2005-02-17 01:27 PM -0600, you wrote:
btw, is there any difference in python between %u and %d at all?
Nope, I don't think so.
Yes, there is. %d -- integer (signed) %u -- Unsigned integer - Sam __________________________________________________________ Spinward Stars, LLC Samuel Reynolds Software Consulting and Development 303-805-1446 http://SpinwardStars.com/ sam@SpinwardStars.com
On Feb 18, 2005, at 9:22 AM, Samuel Reynolds wrote:
At 2005-02-17 01:27 PM -0600, you wrote:
btw, is there any difference in python between %u and %d at all?
Nope, I don't think so.
Yes, there is.
%d -- integer (signed) %u -- Unsigned integer
Nope, there isn't, in 2.4 and up. In 2.3 %u does the following:
"%u"%-5 __main__:1: FutureWarning: %u/%o/%x/%X of negative int will return a signed string in Python 2.4 and up '4294967291'
James
On Fri, Feb 18, 2005 at 03:48:57AM +0100, Andrea Arcangeli wrote:
On Thu, Feb 17, 2005 at 01:27:30PM -0600, J Turner wrote:
It's not trival to determine whether or not something gets resolved. If it's a keyword argument situation, then I need to search the format string for some variation of %(keyword)s. If it's just tuple-style, then I need to count the number of %s/d/whatevers and determine whether or not it's beyond the limit.
This seems ugly, and needlessly expensive for a corner case; I think the right answer is, only pass things to format() that are intended to be formatted and made safe for insertion into SQL.
So my suggestion is not to give it up, but to try to convert to string, and format it like string if __str__ did its job.
This makes sense. I was hesitant to "just str()" it because the whole point of format() (or, at least, the biggest point) is that it makes things safely escaped for insertion into a SQL statement--no malicious injection. If I did it the way you suggest, however, and do something like STRING(str(unknown_thing)) so that it was sure to be escaped properly, that seems like it would be a useful thing. - Jamie
On Fri, Feb 18, 2005 at 12:02:14PM -0600, J Turner wrote:
If I did it the way you suggest, however, and do something like STRING(str(unknown_thing)) so that it was sure to be escaped properly, that seems like it would be a useful thing.
Yes, the idea is to convert ot str and then to excape it with STRING. I could duplicate the hash and purify it myself, and it'd still work with pgasync too, but I'd need to write more code for it that would be unnecessary with the above. With the abvoe I could pass down as well an url and have it converted to string automatically by pgasync. The main cons is decreased strictness that might actually hide bugs if somebody pass down a weird type. So if you don't want to do that, I can as well try to purfy the stuff myself.
On Thu, Feb 17, 2005 at 01:27:30PM -0600, J Turner wrote:
1) the '%(xx)d' format for integeres/logs insn't recognized. I'd like to use "%(xx)d" to be strict for integers.
This is fixed.
I'm afraid this isn't necessary anymore, pgasync also dropped support for %d recently, so perhaps you can back it out now.
participants (4)
-
Andrea Arcangeli -
J Turner -
James Y Knight -
Samuel Reynolds