Re: psycopg2.connect change from a C function to module method
От | Daniele Varrazzo |
---|---|
Тема | Re: psycopg2.connect change from a C function to module method |
Дата | |
Msg-id | CA+mi_8Y_4arnxc-PXbLoPhkne8VqbrUK4NK_ffXiReAvDaawNQ@mail.gmail.com обсуждение исходный текст |
Ответ на | psycopg2.connect change from a C function to module method (Jan Urbański <wulczer@wulczer.org>) |
Ответы |
Re: psycopg2.connect change from a C function to module
method
|
Список | psycopg |
2011/12/27 Jan Urbański <wulczer@wulczer.org>: > Hi, > > the change that made psycopg2.connect a module-level Python function > rather than a function exposed from a C module turned ou to be > backwards-incompatible. > > 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. > The potential for actual breakage is very small, but I wanted to report > it in case someone hits it like I did and perhaps to discuss whether the > fix I applied is correct. I would have probably guarded it with an "if isinstance(conn, types.UnboundMethodType)": because a C function doesn't become a method, being able to make a staticmethod out of it seems a bet. 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. -- Daniele
В списке psycopg по дате отправления: