From: Mike M. <zo...@je...> - 2004-10-27 06:00:13
|
Hi everyone. I'm thinking of reporting this as a bug properly, but it'd be good if someone with a better knowledge of pyPgSQL internals could confirm my line of reasoning first. In my CGI script, I use my own subclass of the 'unicode' class rather than the regular unicode class. My sub-class is very similar, apart from adding a few extra methods and member variables. When I try to pass my customised unicode strings to a stored procedure call via the Cursor.callproc() method, however, pyPgSQL doesn't want to automatically encode them. I can provide more detailed information about exactly what happens or attempt to produce a simplified test case if anyone wants it. I've tracked this down to the Cursor.__unicodeConvert() method, which uses the 'is' operator to figure out if a particular object is a StringType or a UnicodeType. Unfortunately this doesn't detect my sub-class of the unicode class, so it's simply not trying to encode it. I've experimented with hacking PgSQL.py to use isinstance() in the various places instead. ie. Instead of: if type(obj) is UnicodeType: do_something() I've changed it to: if isinstance(obj, UnicodeType): do_something() In my case at least, this appears to fix things, but I haven't tested it intensively. I realise that sub-classing 'str' and 'unicode' isn't a normal thing for most people to do. Is that the only reason that the 'is' operator was used, or is it more complicated than that? If someone who better understands the inner workings of pyPgSQL could clarify it for me, I'd appreciate it. Otherwise I'll go ahead and report it as a bug. Thanks for any help. Mike. |