Thread: Dropping Python 2.4 support
Hello, Matthew Woodcraft and me have worked on exposing PQresultErrorField on the Error object, allowing to get detailed information from a server error. This includes the new diagnostics fields to be released in PostgreSQL 9.3. Ticket: http://psycopg.lighthouseapp.com/projects/62710-psycopg/tickets/149 Docs: http://initd.org/psycopg/docs/module.html#psycopg2.Error.diag http://initd.org/psycopg/docs/extensions.html#psycopg2.extensions.Diagnostics The feature needs the PQresult stored into Error, making it a StandardError subclass with a customized C structure. Unfortunately this breaks Python 2.4, where the exceptions were old style classes. Working around the issue seems a messy matter of #ifdefs scattered all around the code: I think it would be better to just pull the plug on Python 2.4 for psycopg release 2.5. If there was a 2.4.7 release (it could be: there is a couple of bug fixed and, sigh, another Zope problem) it would still be compatible with Python 2.4. Issues? Objections? Let me know. Cheers, -- Daniele
On Wed, Mar 20, 2013 at 11:17 AM, Daniele Varrazzo <daniele.varrazzo@gmail.com> wrote: > Hello, > > Matthew Woodcraft and me have worked on exposing PQresultErrorField on > the Error object, allowing to get detailed information from a server > error. This includes the new diagnostics fields to be released in > PostgreSQL 9.3. > > Ticket: http://psycopg.lighthouseapp.com/projects/62710-psycopg/tickets/149 > Docs: > http://initd.org/psycopg/docs/module.html#psycopg2.Error.diag > http://initd.org/psycopg/docs/extensions.html#psycopg2.extensions.Diagnostics > > The feature needs the PQresult stored into Error, making it a > StandardError subclass with a customized C structure. Unfortunately > this breaks Python 2.4, where the exceptions were old style classes. > > Working around the issue seems a messy matter of #ifdefs scattered all > around the code: I think it would be better to just pull the plug on > Python 2.4 for psycopg release 2.5. If there was a 2.4.7 release (it > could be: there is a couple of bug fixed and, sigh, another Zope > problem) it would still be compatible with Python 2.4. > > Issues? Objections? Let me know. Python 2.4 is still the default on RHEL5, I believe? That's always a potential issue - but python 2.6 at least is available as a second package, so it's something that can reasonably easily be worked around. And since psycopg 2.5 is certainly not going to be in a rhel5 default package :), I doubt it's a problem that actually needs much attention. Bottom line is that as long as we're aware of that whenever someone tries to install it via whatever manual operation on rhel5, it's perfectly reasonable to drop support for python 2.4. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
On Wed, Mar 20, 2013 at 11:30:57AM +0000, Magnus Hagander wrote:
> And since psycopg 2.5 is certainly not going to be in a rhel5 default
> package :), I doubt it's a problem that actually needs much attention.
Even the Stable (Squeeze) branch of Debian already has
Python 2.6 as default, too:
python:
Installed: 2.7.3-4
Candidate: 2.7.3-4
Version table:
2.7.3-13 0
10 ftp://ftp.de.debian.org/debian/ experimental/main i386 Packages
*** 2.7.3-4 0
990 http://ftp.de.debian.org/debian/ wheezy/main i386 Packages
990 ftp://ftp.de.debian.org/debian/ testing/main i386 Packages
50 ftp://ftp.de.debian.org/debian/ unstable/main i386 Packages
100 /var/lib/dpkg/status
2.6.6-3+squeeze7 0
500 http://ftp.de.debian.org/debian/ squeeze/main i386 Packages
so from that angle it shouldn't be a problem either.
Karsten
--
GPG key ID E4071346 @ gpg-keyserver.de
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346