ifequal is technical debt in Django. It's a legacy way of doing things
which we would not add now. Sure, we don't have to remove it, it isn't
blocking us from doing anything else and it isn't broken, and it doesn't
need much maintenance.
However, as with all technical debt, it has a cost. It's additional code,
tests, documentation to maintain, low as the burden is. There is now "more
than one way to do it" - when as a new developer who has learned {% if x ==
y %} I then stumbles across {% ifequal x y %}, which is better? Does it
matter? Is one more efficient? They don't know that one is legacy code from
days when {% if %} was more stupid.
We want to grow the Django community and make it easier to use Django. We
also want to make sure that "There should be one-- and preferably only one
--obvious way to do it". This is why we have done things like removing
patterns(), why we rewrote transactions, why django.migrations is not
South, and why removing features which could have been deprecated in 1.2 is
important. Changes always result in work for upgrading existing sites, but
this is a cost the community should bear to make progress.
The number of sites using ifequal is small (it's very old, and not
recommended in any tutorial for many years). The number of future sites
which should not be using it, and future users (and maintainers of old
projects) who shouldn't have to worry about two ways to do the same thing
is large. The upgrade path is easy - you can achieve it with sed.
Quoting the 1.2 release notes: "There’s really no reason to use {% ifequal
%} or {% ifnotequal %} anymore, unless you’re the nostalgic type."
On 6 August 2015 at 21:07, Karen Tracey <kmtra...@gmail.com> wrote:
> On Thu, Aug 6, 2015 at 12:15 PM, Daniel Greenfeld <pyda...@gmail.com>
> wrote:
>
>> No modern project uses ifequal. No one recommends it. I argue it is
>> taking up valuable bytes in the project. Let's remove it.
>>
>
> I maintain (did not write) a project written last year that has ifequal
> and ifnotequal. Is it really necessary to make it harder to upgrade this
> project to a more recent Django?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CACS9radErjkfJHC0wVvPJWK4HpzVQiAyj0s_2ykG57EAG1%2BqLA%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-developers/CACS9radErjkfJHC0wVvPJWK4HpzVQiAyj0s_2ykG57EAG1%2BqLA%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/CAMwjO1EG9%2BOAWiW9iAT%3DnCFKD4_jDeBLVX2cJNXP6CUL9_uafA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
