Thread: [Pypgsql-users] __unicodeConvert and sub-classing unicode

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

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.

Thread: [Pypgsql-users] __unicodeConvert and sub-classing unicode

pypgsql-users