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

Comments

@Naddiseo
Copy link

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

Disallow f(x, y=1, z) and similar nonsense
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

Disallow f(x, y=1, z) and similar nonsense
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
1 participant
You can’t perform that action at this time.