look_and_skip_if will fail if there's more than two optional attributes, since it would be possible to arrange a combination where the first attribute we look for comes last in the list of tokens.

A possible solution is a "look and skip while" method instead, which will keep looking until there are no more of the given type of token. In this case, looking through all names for one that matches the name we're currently looking for, accumulating other names then pushing them all back.

Token has a test_any function, did we already consider using that?

look_and_skip_if will fail if there's more than two optional attributes, since it would be possible to arrange a combination where the first attribute we look for comes last in the list of tokens.

Is this for other nodes in general? Hmm, yeah look_and_skip_if was only designed with Block nodes in mind since they had just 2 attributes.

A possible solution is a "look and skip while" method instead, which will keep looking until there are no more of the given type of token. In this case, looking through all names for one that matches the name we're currently looking for, accumulating other names then pushing them all back.

This sounds like it'll be more useful. I can give it a try

Token has a test_any function, did we already consider using that?

Yeah, one of the earlier iterations tried this. I think the issue I ran into was preventing duplicates like {% block name scoped scoped %}, and having to do something like setattr(node, token.type, True) since test_any won't know which value resulted in the match.

Do you think it would be better to play around with test_any more before trying a look_and_skip_while?

I'll take a look at this, I need to experiment to see what feels right.

Was looking through the docs, and found another case of a tag having two optional keywords. include can have ignore missing and with context, and they must appear in that order if they're both used. https://jinja.palletsprojects.com/en/2.11.x/templates/#include Looks like whoever implemented that didn't want to deal with arbitrary order either, especially for phrases instead of words. 🙂

I think for now the easiest thing to do is just document that required comes last. We can always relax that requirement later if it starts coming up a lot, but I don't want figuring that out to block merging this.

Was looking through the docs, and found another case of a tag having two optional keywords. include can have ignore missing and with context, and they must appear in that order if they're both used. https://jinja.palletsprojects.com/en/2.11.x/templates/#include Looks like whoever implemented that didn't want to deal with arbitrary order either, especially for phrases instead of words. 🙂

I think for now the easiest thing to do is just document that required comes last. We can always relax that requirement later if it starts coming up a lot, but I don't want figuring that out to block merging this.

Awesome! Didn't notice include was a similar case. This really does simplify the problem 😄 . I'll update the docs and switch them to skip_if's.