r11964 and PendingDeprecationWarning

[Luke Plant]

Hi all,

Since changeset 11964 (i18n improvements), if you import
django.forms.fields (directly or indirectly), you get a
PendingDeprecationWarning.

This is a problem, because it means that Django's own code is emitting
a warning. It's especially a problem if you use a line like this:

import warnings
warnings.simplefilter("error", PendingDeprecationWarning)

This is the simplest way to find out if your code is (directly or
indirectly) using code that will be deprecated, and it's what I use in
my django-admin.py command. But since this changeset, it now causes
errors to be raised, which means I can't use this method to find
deprecated code.

Also, when the current code is changed from PendingDeprecationWarning
to DeprecationWarning, then it will become noisy by default, at which
point the current behaviour will become much more annoying. So we
will need to fix this at *some* point.

A simple way to fix it is to use django.utils.functional.lazy() for
the DEFAULT_* globals. Patch attached. Using 'lazy' always has some
potential complications, but given that all the types are container
types (i.e. tuples), I wouldn't anticipate too many problems. If
people were taking the repr() or str() of DEFAULT_DATE_INPUT_FORMATS,
they will have a bug, but that doesn't seem likely outside of
debugging, and otherwise it should work fine.

Is there a reason you didn't do this Jannis/Marc? I missed this at
the review stage. Russell mentioned adding the warnings, but said it
might be hard to do (presumably because of the above problem). The
alternative to my patch is to just remove the warnings.

Regards,

Luke

--
I teleported home one night
With Ron and Sid and Meg,
Ron stole Meggie's heart away
And I got Sidney's leg
(THHGTTG)

Luke Plant || http://lukeplant.me.uk/

[Luke Plant]

pinging Jannis - did you see this? Can you have a look at my
suggestion?

Cheers,

Luke

--
"Love is like an hourglass, with the heart filling up as the brain
empties."

Luke Plant || http://lukeplant.me.uk/

[Jannis Leidel]

Hi Luke,

> pinging Jannis - did you see this? Can you have a look at my
> suggestion?

Mea culpa, this is indeed an issue and I like your solution of using lazy(), since the *_INPUT_FORMATS tuples are only used for iteration.

Maby just an odd idea but what happens if someone monkey patched them as lists (e.g. because the input formats weren't configurable until now)? Would lazy() handle this automatically given list and tuples are both iterables or should we pass an additional resultclass, like

DEFAULT_DATE_INPUT_FORMATS = lazy(lambda: en_format('DATE_INPUT_FORMATS'), tuple, list)()
DEFAULT_TIME_INPUT_FORMATS = lazy(lambda: en_format('TIME_INPUT_FORMATS'), tuple, list)()
DEFAULT_DATETIME_INPUT_FORMATS = lazy(lambda: en_format('DATETIME_INPUT_FORMATS'), tuple, list)()

Best,
Jannis

[Luke Plant]

On Tuesday 05 January 2010 00:40:42 Jannis Leidel wrote:

> Maby just an odd idea but what happens if someone monkey patched
> them as lists (e.g. because the input formats weren't configurable
> until now)? Would lazy() handle this automatically given list and
> tuples are both iterables or should we pass an additional
> resultclass, like
>
> DEFAULT_DATE_INPUT_FORMATS = lazy(lambda:
> en_format('DATE_INPUT_FORMATS'), tuple, list)()
> DEFAULT_TIME_INPUT_FORMATS = lazy(lambda:
> en_format('TIME_INPUT_FORMATS'), tuple, list)()
> DEFAULT_DATETIME_INPUT_FORMATS = lazy(lambda:
> en_format('DATETIME_INPUT_FORMATS'), tuple, list)()

Personally I wouldn't worry about people who are monkey patching -
they ought to expect things to break. But I don't think this addition
will harm either.