Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Default parameters aren't tracked properly #364

Closed
Naddiseo opened this issue Sep 9, 2014 · 0 comments
Closed

Default parameters aren't tracked properly #364

Naddiseo opened this issue Sep 9, 2014 · 0 comments

Comments

@Naddiseo
Copy link
Contributor

@Naddiseo Naddiseo commented Sep 9, 2014

I was looking through the parser and noticed that default arguments for macro/call parameters aren't attached to the parameter they were defined with. This can lead to unexpected behaviour:

>>> import jinja2
>>> jinja2.Template("{% macro a(b, c=1, d) %}b={{b}},c={{c}},d={{d}}{% endmacro %} {{ a() }}").render()
u' b=,c=,d=1'

Here you can see that the default was applied to parameter d instead of c. There are two fixes for this:

  • Tie the defaults to the parameter they were defined from
  • Throw a synxtax error like python does: SyntaxError: non-default argument follows default argument
ThiefMaster added a commit to ThiefMaster/jinja that referenced this issue Feb 5, 2015
Python rejects such function definitions because it doesn't make much
sense to have arguments with no default values after arguments with
default values.

Jinja did allow them, but handled them improperly (associating the
default value with the wrong argument).

Due to how broken the current behavior is, it makes more sense to reject
templates containing such defintions instead of trying to handle them
properly. Both cases are going to break existing code containing such
definitions, but besides the fact that possibly no such code exists it
is better to fail with a clear error than to silently change the values
of arguments.

This fixes pallets#364
ThiefMaster added a commit to ThiefMaster/jinja that referenced this issue Feb 6, 2015
Python rejects such function definitions because it doesn't make much
sense to have arguments with no default values after arguments with
default values.

Jinja did allow them, but handled them improperly (associating the
default value with the wrong argument).

Due to how broken the current behavior is, it makes more sense to reject
templates containing such defintions instead of trying to handle them
properly. Both cases are going to break existing code containing such
definitions, but besides the fact that possibly no such code exists it
is better to fail with a clear error than to silently change the values
of arguments.

This fixes pallets#364
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Nov 13, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

1 participant