From: | Jan Urbański <wulczer(at)wulczer(dot)org> |
---|---|
To: | Daniele Varrazzo <daniele(dot)varrazzo(at)gmail(dot)com> |
Cc: | Psycopg List <psycopg(at)postgresql(dot)org> |
Subject: | Re: psycopg2.connect change from a C function to module method |
Date: | 2011-12-28 12:39:32 |
Message-ID: | 4EFB0E04.8040100@wulczer.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | psycopg |
On 28/12/11 13:26, Daniele Varrazzo wrote:
> 2011/12/27 Jan Urbański <wulczer(at)wulczer(dot)org>:
>> Attached is a small snippet that works well with psycopg2 2.4.2 and
>> tracebacks with "TypeError: argument 1 must be string, not C" with 2.4.3.
>
> Uhm... if you assign a function to a class you get an unbound method:
> this is the standard Python semantic. The fact it doesn't happen with
> a C function seems just short of a cpython bug, and it's an ugly
> asymmetry anyway.
Yeah, I couldn't find any real explanation of whether that's intended
behaviour or a bug.
> Even better, probably:
>
> class C(object):
> def conn(self, *args, **kwargs):
> return psycopg2.connect(*args, **kwargs)
>
> def __init__(self):
> self.conn('')
>
> to give subclasses the possibility to change it in a standard OOP way.
That would be nice, but I can't do that because of
backwards-compatibility (overriding the connectionFactory class variable
needs to work).
I'll stick with staticmethod for now and if situation warrants (like for
instance CPython decides you can't call staticmethod on a C function)
I'll turn to something more elaborate.
Thanks!
Jan
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Irbizon | 2012-01-01 19:40:07 | cannot install psycopg2 |
Previous Message | Daniele Varrazzo | 2011-12-28 12:26:24 | Re: psycopg2.connect change from a C function to module method |