feat: support call template_filter without parens

[kadai0308]

This PR enhances the App.template_filter decorator to support:

• @app.template_filter (without parentheses)

It also ensures that the original usage remains fully supported, with no breaking changes:

• @app.template_filter()
• @app.template_filter(name="...")
• @app.template_filter("...")

I’m not fully confident in the solution, so I’d like to confirm it first. If it’s good, I’ll apply the same change to template_global and template_test.

---

I considered the following implementation options:

1. Rename the input parameter to func_or_name to better reflect the logic of how the input is interpreted:

def template_filter(self, func_or_name: t.Callable[..., t.Any] | str | None = None):

However, this would be a breaking change for calls like @app.template_filter(name="..."), so I decided to keep the original parameter name for backward compatibility.

2. Make func_or_name a positional-only parameter and keep name as keyword-only:

def template_filter(self, func_or_name: t.Callable[..., t.Any] | str | None = None, /, *, name: str | None = None):

This approach is type-safe, but it introduces the awkward case where both func_or_name and name are provided at the same time. It could also be confusing for users reading the function signature.

So eventually, I decided to keep the original function parameter and distinguish the usage using if callable(name):. I’d like to discuss whether there’s a better approach, and I’m open to making improvements based on feedback and suggestions.

---

fixes https://github.com/pallets/flask/issues/5729

---

• [x] Add tests that demonstrate the correct behavior of the change. Tests should fail without the change.
• [x] Add or update relevant docs, in the docs folder and in code.
• [x] Add an entry in CHANGES.rst summarizing the change and linking to the issue.
• [ ] Add .. versionchanged:: entries in any relevant code docs.

[kadai0308]

Hi @RonnyPfannschmidt @davidism This is a draft PR because I'm not entirely sure if this is the right approach. I'd really appreciate it if you could take a look when you have time. Please let me know if there's anything I should improve or change. Thank you!

[kadai0308]

Sorry for didn't aware the contriubing rule, just close the PR.

[davidism]

You're fine, this is the direction I want to go and you were first anyway.

[kadai0308]

You're fine, this is the direction I want to go and you were first anyway.

Thanks for sharing this; I'll go ahead and process the PR.

[davidism]

Thanks for working on this, you were really through with the typing, docs, and tests, as well as noticing the other methods and blueprints as well. I ended up pushing another commit that rewrote the docs entirely, used the callable types consistently, and made the code a bit more concise.