Deprecating psycopg 1

[Jacob Kaplan-Moss]

Hi folks --

I'd like to start the process of deprecating and removing support for
psycopg 1. Why?

* psycopg 2 is better in every way.
* psycopg 1 hasn't been updated since October 2005; it's basically a dead end.
* I don't know anyone using it in production.
* For the couple-three people who *are*, it's now possible (and
reasonably easy) to maintain an external backend.

I'm proposing the following very predictable timeline:

Django 1.2
Use of the "postgresql" backend raises a PendingDeprecationWarning.

Django 1.3
Use of the "postgresql" backend raises a DeprecationWarning.

Django 1.4
Remove the "postgresql" backend from Django (and put it on
bitbucket/github?)

Any objections?

[I'm deliberately not discussing anything regarding the renaming of
the "postgresql_psycopg2" backend. I have a bigger proposal I'd like
to make around that, but that's gonna have to wait for 1.3.]

Jacob

[Alex Gaynor]

> --
>
> You received this message because you are subscribed to the Google Groups "Django developers" group.
> To post to this group, send email to django-d...@googlegroups.com.
> To unsubscribe from this group, send email to django-develop...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
>
>
>

+1. psycopg1 is already missing quite a few features from psycopg2
(autocommit, GIS, etc.).

Alex

--
"I disapprove of what you say, but I will defend to the death your
right to say it." -- Voltaire
"The people's good is the highest law." -- Cicero
"Code can always be simpler than you think, but never as simple as you
want" -- Me

[Jerome Leclanche]

+1 from me too on the timeline, but why the PendingDeprecationWarning?
I don't see the point, there isnt exactly a limit to how long
something can be deprecated.

J. Leclanche / Adys

[Russell Keith-Magee]

On Sun, Dec 13, 2009 at 8:02 AM, Jacob Kaplan-Moss <ja...@jacobian.org> wrote:
> Hi folks --
>
> I'd like to start the process of deprecating and removing support for
> psycopg 1. Why?
>
> * psycopg 2 is better in every way.
> * psycopg 1 hasn't been updated since October 2005; it's basically a dead end.
> * I don't know anyone using it in production.
> * For the couple-three people who *are*, it's now possible (and
> reasonably easy) to maintain an external backend.
>
> I'm proposing the following very predictable timeline:
>
> Django 1.2
>    Use of the "postgresql" backend raises a PendingDeprecationWarning.
>
> Django 1.3
>    Use of the "postgresql" backend raises a DeprecationWarning.
>
> Django 1.4
>    Remove the "postgresql" backend from Django (and put it on
> bitbucket/github?)
>
> Any objections?

+1. Sounds completely reasonable, and about time.

> [I'm deliberately not discussing anything regarding the renaming of
> the "postgresql_psycopg2" backend. I have a bigger proposal I'd like
> to make around that, but that's gonna have to wait for 1.3.]

This would have been my only comment, but if you have bigger plans, I
can hold my breath.

Yours,
Russ Magee %-)

[Russell Keith-Magee]

On Sun, Dec 13, 2009 at 8:13 AM, Jerome Leclanche <ady...@gmail.com> wrote:
> +1 from me too on the timeline, but why the PendingDeprecationWarning?
> I don't see the point, there isnt exactly a limit to how long
> something can be deprecated.

PendingDeprecationWarning lets us introduce the change gradually.

* PendingDeprecationWarnings aren't actually visible to the end user
unless the turn on the -W flag to the Python interpreter

* DeprecationWarning is visible by default.

By making the change over three releases, it gives plenty of
code-level warnings that a change is going to happen, including a
period where you can be warned of the change at your option.

Yours,
Russ Magee %-)

[Jerome Leclanche]

I'm guessing it's the standard way to do things and this may be a bit
offtopic but still, out of curiousity, since the PendingDepWarning is
not visible by default doesn't this actually give the users just the
illusion of more time to fix their code?

Django releases are, from what I can see, getting a lot faster than
Python ones. A commandline switch to enable specific warnings makes
sense for python itself, but for Django itself, someone who just
regularly runs svn update every 4-5 months and has some bad luck with
timing may know about the warning only a very short time before the
release. Maybe I'm just digging in the paint, but to me it would make
a lot more sense to disable warnings with a command line switch rather
than enable them and have a note around the lines of
DeprecationWarning: The pycopg1 backend will be removed in Django 1.4.
You may disable this warning with --some-switch.

(Disclaimer: I never use warnings)

J. Leclanche / Adys

[Jacob Kaplan-Moss]

On Sat, Dec 12, 2009 at 6:36 PM, Jerome Leclanche <ady...@gmail.com> wrote:
> I'm guessing it's the standard way to do things and this may be a bit
> offtopic but still, out of curiousity, since the PendingDepWarning is
> not visible by default doesn't this actually give the users just the
> illusion of more time to fix their code?

That's the pessamistic version, yes.

I prefer to think of it like this:

Django 1.2 ships. Users read the release notes, and notice that
psycopg1 is now deprecated and will be removed. It's still there, and
still supported, so they can upgrade quickly and not have to be stuck
on 1.1.

Django 1.3 ships. Now, using psycopg1 spews ugly error messages to the
console and Apache's error logs. But psycopg1 still works, so users
can upgrade immediately and get around to fixing the ugly warning
messages at their leisure.

Django 1.4 ships. Those who've ignored both the release notes and the
error messages over the last year (or more) get what they deserve.

The main point is this: upgrading from Django 1.N to Django 1.N++
should be a no-brainer. We want our users to upgrade as quickly as
possible: this makes our jobs as maintainers *much* easier. To
encourage upgrades, we make them easy. This means long deprecation
schedules, and it means gradually working up to things.

Jacob

[Tobias McNulty]

+1 to removing the psycopg1 backend. I was just wondering if it was
ever going to happen earlier today when I was creating example
settings files for running the tests, and got tired of typing
'postgresql_psycopg2'. Even getting psycopg1 installed is a small
PITA on any modern Linux system. I'll hold my breath in anticipation
of your renaming plan, too.

On Sat, Dec 12, 2009 at 8:09 PM, Jacob Kaplan-Moss <ja...@jacobian.org> wrote:
> Django 1.2 ships. Users read the release notes, and notice that
> psycopg1 is now deprecated and will be removed. It's still there, and
> still supported, so they can upgrade quickly and not have to be stuck
> on 1.1.

Plus, those who care about these things can enable the
PendingDeprecationWarnings if they want to. It certainly doesn't hurt
and it probably helps a few folks. It's how everything else is
deprecated and it makes sense. I see no reason to change the plan.

Tobias
--
Tobias McNulty
Caktus Consulting Group, LLC
P.O. Box 1454
Carrboro, NC 27510
(919) 951-0052
http://www.caktusgroup.com

[Kevin Teague]

On Dec 12, 5:09 pm, Jacob Kaplan-Moss <ja...@jacobian.org> wrote:
>
> I prefer to think of it like this:
>
> Django 1.2 ships. Users read the release notes, and notice that
> psycopg1 is now deprecated and will be removed. It's still there, and
> still supported, so they can upgrade quickly and not have to be stuck
> on 1.1.
>
> Django 1.3 ships. Now, using psycopg1 spews ugly error messages to the
> console and Apache's error logs. But psycopg1 still works, so users
> can upgrade immediately and get around to fixing the ugly warning
> messages at their leisure.
>
> Django 1.4 ships. Those who've ignored both the release notes and the
> error messages over the last year (or more) get what they deserve.
>

Note that Python recently changed it's policy on deprecation warnings.
Python 2.7 and 3.2 will only display DeprecationWarnings when a switch
is set (a lower-case -w switch was proposed to enable these warnings).
So with these versions of Python it won't make a difference between
PendingDeprecationWarning and DeprecationWarning in terms of
noisyness ... although it is possible to modify this behaviour in code
with the warnings module (such as during Django initialization).