On Fri, Aug 5, 2011 at 8:39 PM, Joe Abbate <jma@freedomcircle.com> wrote:
> Hi Daniele,
>
> On 08/05/2011 03:06 PM, Daniele Varrazzo wrote:
>> On Fri, Aug 5, 2011 at 6:34 PM, Joe Abbate <jma@freedomcircle.com> wrote:
>>
>>> Does anyone on the list know the status of the subject?
>>
>> Psycopg works out of the box with Python 3.1 and 3.2: "make
>> PYTHON=/path/to/pythonX.Y" and it is built against the desired Python
>> version.
>>
>> I assume it's just the dependencies of the debian package to have not
>> been updated after psycopg started supporting Python 3.x: there should
>> be no build problem (recent development has been mostly performed in
>> debian environment).
>
> Yes, that's what I suspected. When I do python -3 (using 2.6 or 2.7)
> and import psycopg2, I get DeprecationWarnings for
> mx/DateTime/DateTime.py. What I don't understand is that in PyPI,
> egenix-mx-base does not show as supporting Python 3. If that's correct,
> does psycopg2 use something else for Python 3?
Psycopg uses by default the standard python datetime objects, both in
Python 2 and 3. When it is built with mx support, both Python and mx
dates are handled as argument parameters, and values read from the
database are return as Python objects (if people want mx object
instead, they have either to have a flag a build time or to manipulate
the typecasters map). If mx is not available (either at compile or at
import time), Python datetime objects are the only types supported.
Psycopg 2.4.1 can be safely compiled with mx support, because if
mx.DateTime is not found at import time, the objects using it are not
used (in previous version this would have raised ImportError, see
ticket #53). The support is compiled if the mx include files are
found: with Python 3 such files are never found so its support is
never compiled.
So I believe a good packaging strategy would be, for Python 2, to
consider mx.DateTime a build-time dependency but not a package
dependency. In Python 3 just ignore mx.DateTime.
-- Daniele
