Ticket #25236: Remove ifequal from the template language

253 views
Skip to first unread message

Daniel Greenfeld

unread,
Aug 6, 2015, 12:15:49 PM8/6/15
to Django developers (Contributions to Django itself)
No modern project uses ifequal. No one recommends it. I argue it is taking up valuable bytes in the project. Let's remove it.


In there you'll see Tim Graham mentions that older Django projects may push back on it, and suggests that a good medium ground would be to remove it from the documentation.

Any comments?

Regards,

Daniel Roy Greenfeld

Marc Tamlyn

unread,
Aug 6, 2015, 12:19:16 PM8/6/15
to django-d...@googlegroups.com
I commented on the ticket - it's been redundant since Django 1.2 when the smart if was introduced. +1 to deprecating it.

--
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-develop...@googlegroups.com.
To post to this group, send email to django-d...@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/add63617-a253-4571-a705-bf5773ed18ec%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Tzu-ping Chung

unread,
Aug 6, 2015, 1:32:03 PM8/6/15
to Django developers (Contributions to Django itself)
Also +1 for its removal. And ifnotequal, too, since nobody seems to have mentioned this yet.

I would imagine a simple regex find-and-replace very much enough to fix most problems this causes. And if someone really want those tags, it is also pretty trivial to just pull them into a third-party app. One line in INSTALLED_APPS and a {% load %} tag fix everything.


Daniel Greenfeld於 2015年8月7日星期五 UTC+8上午12時15分49秒寫道:

Karen Tracey

unread,
Aug 6, 2015, 4:07:29 PM8/6/15
to django-d...@googlegroups.com
On Thu, Aug 6, 2015 at 12:15 PM, Daniel Greenfeld <pyd...@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?

Marc Tamlyn

unread,
Aug 6, 2015, 5:08:57 PM8/6/15
to django-d...@googlegroups.com
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."

--
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-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.

Curtis Maloney

unread,
Aug 6, 2015, 8:21:50 PM8/6/15
to django-d...@googlegroups.com
Let me open by saying I am in no way averse to the removal of these
two tags... and this reminds me I need to also re-work my "remove the
'x as y' argument syntax" patch again...

On 7 August 2015 at 07:08, Marc Tamlyn <marc....@gmail.com> wrote:
> 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?

As a small point, and I have met people for whom it was beneficial,
ifequal/ifnotequal _are_ more efficient than smart-if... it's a tiny
margin, but they are, and inside an inner loop, it can make quite a
difference.

I'm not advocating we keep them, just putting the info out there.

Personally, I'll just add another yak to my quiver of optimising if
... perhaps putting my AST skills to good use :)

--
C

Karen Tracey

unread,
Aug 6, 2015, 9:43:16 PM8/6/15
to django-d...@googlegroups.com

Believe me I understand what technical debt is. In my opinion the cost of this debt in Django is not sufficient to warrant the cost to users of Django to remove it. Find and fix (or figure out if it's necessary to fix) all templates (some of which may be coming from 3rd party packages)  used in a site is not that trivial of a task for a large site with many 3rd party dependencies. By contrast documenting why these two tags exist is pretty painless.

Curtis Maloney

unread,
Aug 6, 2015, 9:56:29 PM8/6/15
to django-d...@googlegroups.com
Given the [currently] low burden, I agree with a more gradual
deprecation... document against their use to help encourage people to
move away from them, then we're in a better position to more
painlessly remove them in the future.

--
Curtis
> --
> 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-develop...@googlegroups.com.
> To post to this group, send email to django-d...@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/CACS9rafSuot0xati8HLOe2QEV7QpNny7d4bZDnVGzwsiAgDP7A%40mail.gmail.com.

Josh Smeaton

unread,
Aug 6, 2015, 10:01:31 PM8/6/15
to Django developers (Contributions to Django itself)
Can we just push the ifequal type tags through regular deprecation? As mentioned, the cost of maintaining the tags is extremely low. Remove the ifequal tags from the docs, document their deprecation, and remove in Django 2.0.

Karen Tracey

unread,
Aug 6, 2015, 10:49:37 PM8/6/15
to django-d...@googlegroups.com
We certainly weren't discussing removing without deprecating, were we? I'm saying removing isn't worth the hassle to users, period. My opinion from working on a fair number of inherited sites, plus sites where I don't get to choose who contributes code I'm responsible for maintaining. I've reported I have code I have to maintain written last year that uses these tags, it's not just ancient crufty old stuff. These tags don't cause a massive "brain stop" to figure out what "ifequal" might mean when encountering them in existing templates.They are not that bad. This wart isn't worth the pain to users to remove, in my opinion. Finding and fixing all templates used by a site is NOT trivial. Fixing url was worth it. This is not.


Josh Smeaton

unread,
Aug 6, 2015, 11:05:12 PM8/6/15
to Django developers (Contributions to Django itself)
Fair enough, I don't necessarily disagree with you. Would removing the documentation for ifequal be OK? At least that would prevent new projects from using it or being confused about multiple ways to compare values.

Curtis Maloney

unread,
Aug 6, 2015, 11:43:40 PM8/6/15
to django-d...@googlegroups.com
I'd probably go with updating the documentation to say they're legacy
tags, you're better off using {% if %} now, and warn they may be
removed in a later release.

This way (a) people are warned off it, and (b) we're confusing people
who find it and want to check what it does [even though it's quite
clear from the name]

--
Curtis
> --
> 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-develop...@googlegroups.com.
> To post to this group, send email to django-d...@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/44ee5d1f-1071-4dd7-a1dd-fe798c0dc2de%40googlegroups.com.

Aymeric Augustin

unread,
Aug 7, 2015, 3:06:42 AM8/7/15
to django-d...@googlegroups.com
> On 7 août 2015, at 05:43, Curtis Maloney <cur...@acommoncreative.com> wrote:
>
> I'd probably go with updating the documentation to say they're legacy
> tags, you're better off using {% if %} now, and warn they may be
> removed in a later release.

This is my inclination as well. Then we can revisit the topic in a few years :-)

--
Aymeric.




Tim Graham

unread,
Aug 7, 2015, 7:33:52 AM8/7/15
to Django developers (Contributions to Django itself)
Django 1.9 has the option to add templates tags to the builtins using the TEMPLATES setting, so it wouldn't be difficult to publish a third-party app with the legacy tags and document how to use it in legacy projects that have difficulty updating:

OPTIONS={
    'builtins': ['ifequal.tags'],

Tim Graham

unread,
Aug 7, 2015, 10:31:47 AM8/7/15
to Django developers (Contributions to Django itself)
I put together a pull request to see how much code we are talking about: https://github.com/django/django/pull/5114

It's 275 lines of code (mostly tests). I don't mind the outcome of the decision either way, but as it's been 5 years since the release of 1.2 and the "smart if" tag, I'm not sure delaying this a few more years would make a huge difference (that is to say, how about we make a "remove now or never" decision). We did a similar "undocument but don't remove" thing with the @permalink decorator.

Marc Tamlyn

unread,
Aug 7, 2015, 10:36:24 AM8/7/15
to django-d...@googlegroups.com

I think Tim's suggestion of releasing the tag as a separate library which can be included in builtins answers Karen's concerns about updating 3rd party templates. I admit that is a case I had not considered.

Marc

--
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-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.

Russell Keith-Magee

unread,
Aug 7, 2015, 9:24:22 PM8/7/15
to Django Developers
I agree. We shouldn't encourage new users to use the {% ifequal %} tag, but I don't see any benefit in removing something that is in use, and doesn't pose any particular maintenance burden or impediment to progress.

The only other suggestion I've got is to add a new "pre-deprecation" step to our deprecation process - a flag that lets us indicate that at some point, we intend to deprecate something, but we haven't decided when that will be. This would essentially be a "don't use this on new code, but there's no rush in replacing it". It could also be accompanied with a Warning so that existing uses could be found and replaced if someone was so inclined.

Yours,
Russ Magee %-)
 

Collin Anderson

unread,
Aug 9, 2015, 3:36:57 PM8/9/15
to Django developers (Contributions to Django itself)
Hi All,

I really like the "don't use this on new code, but there's no rush in replacing it" category. I think that's really important to have that in a project that's this old. I think it would be great to minimize the amount required changes that need to be done.

Thanks,
Collin

Jon Dufresne

unread,
May 4, 2020, 10:08:46 AM5/4/20
to django-d...@googlegroups.com
Hi,

I'd like to raise this topic for renewed discussion. I think it is time to begin deprecating the obsolete template tags. So +1 for removal.

I had all but forgotten about the {% ifequal %} template tag and then eventually stumbled across it doing unrelated work. Upon rediscovering it as a practical duplicate of {% if %}, I thought I'd help out Django by deprecating it for eventual removal so that we're back to "one -- and preferably only one -- obvious way to do it". I created the PR to begin the deprecation here: https://github.com/django/django/pull/12851

We're now coming up on 10 years since Django 1.2 was released with the smart if template tag. Projects and third party apps have had a generous extended time to update their code.

For projects that don't follow Django releases in detail, they may not be aware that the {% ifequal %} tag is obsolete and so have not had any motivation to change. Adding a deprecation warning may help such projects to understand they should update their templates.

For projects that find it is a burden to update, they've had 10 years to do so. I think adding more time isn't what they need at this point. The actual upgrade can be mostly automated with sed (I could even put a recommended command in the release notes). So the update doesn't need to be very time consuming.

While perhaps we agree leaving old code around can mostly go unnoticed, technical debt has subtle ways of showing up. For example, time was spent by me rediscovering this feature exists and wondering why there are two way to write {% if ... %} (this could happen to other contributors studying the template tag system). Time has been spent on this mailing list discussing what to do with old unused code. Its tests -- which mostly don't matter at this point -- run on every PR and in local environments. If there is ever an attempt at an internal refactoring of the template code, the ifequal tag will need to be considered and maintained. And so on.

--
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-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.

Adam Johnson

unread,
May 4, 2020, 12:05:00 PM5/4/20
to django-d...@googlegroups.com
+1 for removal. 5 years have nearly passed since that discussion with the docs saying "The ifequal and ifnotequal tags will be deprecated in a future release." so I think it's worth actioning.

(I could even put a recommended command in the release notes).

I like this idea. It would also be worth having a sentence that one could extract them as custom template tags as Tim noted previously.



--
Adam

Mariusz Felisiak

unread,
May 4, 2020, 12:30:51 PM5/4/20
to Django developers (Contributions to Django itself)
Agreed. We should deprecate both.

(I could even put a recommended command in the release notes).

I don't think it's a good idea. You can attach "unofficial" script in the ticket, but release notes are not a proper place, IMO. It may not behave properly in block comments etc. Don't get me wrong, I wrote dozens of such scripts, but they can be error-prone, and we shouldn't take responsibilities for potential issues.

It would also be worth having a sentence that one could extract them as custom template tags as Tim noted previously.

Sounds good.

Best,
Mariusz

Markus Holtermann

unread,
May 4, 2020, 1:40:44 PM5/4/20
to Django developers
Yes please! Nice catch and followup :)

Cheers,

Markus
> > To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/2ddf20f1-af1a-47c1-b07c-669818846b53%40googlegroups.com <https://groups.google.com/d/msgid/django-developers/2ddf20f1-af1a-47c1-b07c-669818846b53%40googlegroups.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-develop...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CADhq2b5%3D3A03OjPTGa7mUgm-7braWgJwLUU_xW5pFJrgPP6Uow%40mail.gmail.com <https://groups.google.com/d/msgid/django-developers/CADhq2b5%3D3A03OjPTGa7mUgm-7braWgJwLUU_xW5pFJrgPP6Uow%40mail.gmail.com?utm_medium=email&utm_source=footer>.
Reply all
Reply to author
Forward
0 new messages