Recently I was doing some work on PR Feature #5865 -- Cycle template tag should accept a single argument by e11bits · Pull Request #17716 · django/django · GitHub for ticket #5865 (cycle template tag should accept a single argument) – Django. I just put something together at https://sandbox.e11bits.com/ to showcase the feature more broadly. Maybe people can judge by that, if the feature is desirable and help with the code review? It’s just a quick hack, so don’t expect too much. The examples are more or less the ones found as testcases in the PR. (crossposted from discord)
Thank you Alexander for this analysis. I just read the full docs for the cycle tag, and despite I have used it in the past, I was not aware of its complexity!
My first reaction was that any extension to this template tag would be quite cumbersome, and then after reading the ticket, it seems that Malcomm in comment 3 and Alex in comment 14 also thought that the implementation could get tricky and lead to confusing and/or ambiguous syntax.
Based on the above, and taking as a precedent other template tags that offer their seq version (escapeseq, safeseq), I think we could consider prodiving a new cycleseq tag. This way we could start fresh with a clean and polished semantic for this tag.
What do you all think?
This is probably definitely too long, but you can safely skip the first parts to the cycle ticket.
Background
Being in between jobs, I thought to stay “in the loop” by contributing something back to Django. Although I have been using it for the past five years, it was mostly backend related. So there are many parts of the framework I haven’t used. A good time to change that.
What to work on
My plan is to start small and to find some tickets I could contribute to. “Easy pickings” are hard to find and so I used the “vulture” method that @sarahboyce proposed. Tickets that are accepted, haven’t seen any update lately, have already a patch, which needs some improvement to get the ticket over the finishing line. With these tickets I have to understand the problem, the proposed solution, the fix itself and what is still missing. From the comments I try to see if the problem is still a problem today and if working on the ticket would make sense. Ideally the missing bit is not too large and complex and I can create a small PR for the ticket. All that said, in the end I’m not the initial advocate for the change.
the cycle ticket
The ticket was opened 16 years ago. As far as I can see the `cycle` tag got last changed 13 years ago by adding the `silent` feature to it. Up to now people are using the `cycle` tag as it is and the ticket hasn’t seen any frequent comments with the question for when it will be fixed. So either the problem isn’t very big or people are happy to use workarounds or the `cycle` tag is just not so often used anymore as it might have been after its creation. I can’t tell.
After asking “Is this still considered a desirable feature?” the answer was “Yes, IMO nothing has changed.” . But maybe this was a classic miscommunication. Because I was referring to the original problem statement and not to the last comment saying “… however this is a good feature, and the current API is kind of silly. This is accepted, provisional on creating a new, more sane and consistent syntax, to be placed in the future module.”
So I moved forward, implemented a fix, created a PR, was wondering how I could attract reviewers to it and here I am.
If the ambiguity of the new syntax prevents the PR to be accepted, then I can understand and I’m happy with that. I can withdraw the PR, have learned a lot along the way and move to other topics.
I wouldn’t want to put more effort into something brand new like `cycleseq`, because, as I said, I think there is negligible demand for exactly that. And just to add a new tag to cover some edge case, that most likely will be very rarely used, doesn’t sound right to me.
And I really don’t want to sound negative. I strongly believe that the code not written or merged is as important as the code that gets accepted.
1 Like
This ticket is one that I have on the Back Burner — not doing anything about, but occasionally pondering.
What I’d like to investigate is whether we could add * and ** list and dictionary expansion to the DTL. cycle could benefit from list expansion. The new in Django 5.1 query_string tag could benefit from dictionary expansion.
I didn’t sit down with this to implement yet but, either doing it at the DTL syntax level, or (merely) at the parameter level for individual tags both seem like possibilities. (I’d imagine the latter being more straight-forward.)
I don’t know if this is something you’re in the ballpark for thinking about @e11bits, but I thought I’d mention it, since you’re looking into it. 
(I’d be happy to look at anything sketches in this direction.)
1 Like
I will definitely have a look at this a bit more and see if I can come up with a sketch. Thanks.
In the meantime I will withdraw the current PR and make a note in the ticket about this and the reasons.