ticket #2101: maxlength should be max_length

[Gary Wilson]

I brought the patch back in sync with trunk, and would like to make a
call for some eyes, as this is a big, mostly boring, patch. I don't
want to let this one get 6 months out of date again :)

Thanks,
Gary

[Jacob Kaplan-Moss]

Someone remind me -- did we decide what we wanted to do about this?
Seems that making the change outright would annoy a whole host of
people... IIRC, we'd decided to deprecate max_length and issue
warnings... does that sound right?

Jacob

[Gary Wilson]

Jacob Kaplan-Moss wrote:
> Seems that making the change outright would annoy a whole host of
> people... IIRC, we'd decided to deprecate max_length and issue
> warnings... does that sound right?

The patch actually still keeps maxlength around, raising an error only
if both max_length and maxlength are used. Currently, there is no
warning if maxlength is used, but that could be added.

Gary

[Adrian Holovaty]

On 7/30/07, Gary Wilson <gary....@gmail.com> wrote:

> The patch actually still keeps maxlength around, raising an error only
> if both max_length and maxlength are used. Currently, there is no
> warning if maxlength is used, but that could be added.

That sounds like the best thing to do -- I don't see a huge need to
deprecate maxlength immediately, or even issue warnings about it. The
change gets a +1 from me.

Adrian

--
Adrian Holovaty
holovaty.com | djangoproject.com

[Jacob Kaplan-Moss]

On 7/30/07, Adrian Holovaty <holo...@gmail.com> wrote:
> That sounds like the best thing to do -- I don't see a huge need to
> deprecate maxlength immediately, or even issue warnings about it. The
> change gets a +1 from me.

I'd say that making maxlength issue a PendingDeprecationWarning --
which is suppressed by default -- is probably worth the time. That way
people who want to update their code immediately can easily find where
maxlength is still used.

Then in the next release we can change that to a DeprecationWarning
(which is loud by default) and then finally remove it a release after
that.

But I'm really just bike-shedding now; I'm +1 check the patch in with
or without these changes.

Jacob

[SmileyChris]

Thanks for updating, Gary. I was letting it slide until after newforms-
admin hit. Good to see it's got a committer champion now ;)

[Gary Wilson]

Jacob Kaplan-Moss wrote:
> On 7/30/07, Adrian Holovaty <holo...@gmail.com> wrote:
>> That sounds like the best thing to do -- I don't see a huge need to
>> deprecate maxlength immediately, or even issue warnings about it. The
>> change gets a +1 from me.
>
> I'd say that making maxlength issue a PendingDeprecationWarning --
> which is suppressed by default -- is probably worth the time. That way
> people who want to update their code immediately can easily find where
> maxlength is still used.
>
> Then in the next release we can change that to a DeprecationWarning
> (which is loud by default) and then finally remove it a release after
> that.

I attached a new patch which issues a PendingDeprecationWarning.

The new patch also uses a metaclass for FormField and Field classes to
decorate __init__ instead of having to call legacy_maxlength in almost
every subclass's __init__. This should make things easier come time to
remove the legacy maxlength compatibility since it becomes as simple as
removing the metaclass.

Anyone against this approach?

The non-boring changes are in the following three files:
django/utils/maxlength.py
django/oldforms/__init__.py
django/db/models/fields/__init__.py

With tests in:
tests/regressiontests/maxlength/tests.py

Gary

[Adrian Holovaty]

On 8/4/07, Gary Wilson <gary....@gmail.com> wrote:
> I attached a new patch which issues a PendingDeprecationWarning.
>
> The new patch also uses a metaclass for FormField and Field classes to
> decorate __init__ instead of having to call legacy_maxlength in almost
> every subclass's __init__. This should make things easier come time to
> remove the legacy maxlength compatibility since it becomes as simple as
> removing the metaclass.
>
> Anyone against this approach?

This is a nice, clean approach -- good work! The patch is looking
good. Go ahead and check it in at your leisure.

[Gary Wilson]

Adrian Holovaty wrote:
> This is a nice, clean approach -- good work! The patch is looking
> good. Go ahead and check it in at your leisure.

Checked in as http://code.djangoproject.com/changeset/5803