Is URL template tag's syntax going to change?
Julien Phalip
For months, there has been a mention in the url tag's documentation:
"Note that the syntax for this tag may change in the future, as we
make it more robust." [1]
Is that mention still relevant for 1.0 and beyond?
Julien
[1] http://www.djangoproject.com/documentation/templates/#url
Ivan Sagalaev
> Hi,
>
> For months, there has been a mention in the url tag's documentation:
>
> "Note that the syntax for this tag may change in the future, as we
> make it more robust." [1]
>
> Is that mention still relevant for 1.0 and beyond?
If I recall correctly, there was a discussion that the first parameter
should be changed to work like most other parameters to tags: treat it
literally if it's quoted, otherwise look it up in context. The objection
was that potential benefit wasn't worth the hassle of a backwards
incompatible change. But I can't remember if there was a final decision.
Malcolm Tredinnick
The couple of times I brought it up, it died from a lack of core
developers really caring that much. I thought it would have been a good
idea to change it originally. I think it would be a bad idea to change
it now, since it's been in use for so long. If somebody wants to use
variables in a url-like tag, it's trivial to write your own variant.
We're not hurting anybody's software too much by not making the change,
although it would have been nice to do so for consistency.
I suspect that unless Adrian or Jacob pipe up in the very near future
with agreement to change it, we can remove that note because the current
API will be set in stone.
Malcolm
>
> >
>
Johannes Dollinger
possible make url accept a quoted view name and deprecate unquoted
view names.
Especially unquoted non-ascii strings (as in test url05) are ugly and
would require hacks or re.LOCALE in my approach in #7806.
Malcolm Tredinnick
On Sun, 2008-07-20 at 21:37 +0200, Johannes Dollinger wrote:
> I'd prefer treating unquoted parameters as variables.
We've already had this thread in the past. It's really up to Adrian and
Jacob now, although technically, the decision's been made: there just
isn't the interest to change and it would break a lot of code to do so
without a huge benefit (since the alternate behaviour is easy to have in
any case).
> If that's not
> possible make url accept a quoted view name and deprecate unquoted
> view names.
>
> Especially unquoted non-ascii strings (as in test url05) are ugly
Subjective; not a technical reason. Non-ASCII strings look just the same
as ASCII strings. In fact, many non-Latin scripts are much prettier than
the Latin alphabet (just as subjective as your opinion, of course :-)).
> and
> would require hacks or re.LOCALE in my approach in #7806.
That would suggest a problem in the approach in that patch. :-)
There's more than one template tag in Django that treats unquoted
strings of characters as non-literals, although the url tag may be the
only one at the moment where non-ASCII strings are fairly natural. We
shouldn't rule them out, though. That needs to be handled by any
template parsing code. Non-ASCII strings are just as easy to handle as
ASCII strings in code. If you're at the point of thinking you need to
use re.LOCALE, it suggests you're trying to be too strict in the error
checking and loosening that up a bit would be faster, lead to easier to
read code and avoid difficulties like this.
Regards,
Malcolm
Johannes Dollinger
Am 20.07.2008 um 21:48 schrieb Malcolm Tredinnick:
>> Especially unquoted non-ascii strings (as in test url05) are ugly
>
> Subjective; not a technical reason. Non-ASCII strings look just the
> same
> as ASCII strings. In fact, many non-Latin scripts are much prettier
> than
> the Latin alphabet (just as subjective as your opinion, of
> course :-)).
Of course that's subjective, everything is.
>> and
>> would require hacks or re.LOCALE in my approach in #7806.
>
> That would suggest a problem in the approach in that patch. :-)
>
> There's more than one template tag in Django that treats unquoted
> strings of characters as non-literals, although the url tag may be the
> only one at the moment where non-ASCII strings are fairly natural. We
> shouldn't rule them out, though. That needs to be handled by any
> template parsing code. Non-ASCII strings are just as easy to handle as
> ASCII strings in code. If you're at the point of thinking you need to
> use re.LOCALE, it suggests you're trying to be too strict in the error
> checking and loosening that up a bit would be faster, lead to
> easier to
> read code and avoid difficulties like this.
Afaics the only other tag that would accept an arbitrary unquoted
literal is {% ssi %}.
Are there more?
Variables are currently matched with [\w.] (at least in filter
expressions) and that's what I use to match keywords and vars.
bit_re = re.compile(r"""
(?P<string_literal>"(?:[^"\\]*(?:\\.[^"\\]*)*)"|'(?:[^'\\]*(?:\\.
[^'\\]*)*)')
|(?P<numeric_literal>\b[+-]?\.?\d[\d\.e]*\b)
|(?P<name>[\w.]+) # keyword or variable
|(?P<char>\S) # punctuation
""", re.VERBOSE)
tokens = [(bit.lastgroup, bit.group(0)) for bit in bit_re.finditer
(contents)]
Seems like I have to rethink this then.
Steve Holden
[...]
> Of course that's subjective, everything is.
>
"The atomic number of hydrogen is 1" (IMHO?).
regards
Steve
Who just felt like picking this particular nit. Sorry.
--
Steve Holden +1 571 484 6266 +1 800 494 3119
Holden Web LLC http://www.holdenweb.com/
Ivan Sagalaev
> Afaics the only other tag that would accept an arbitrary unquoted
> literal is {% ssi %}.
> Are there more?
Actually when I've first implemented {% url %} I looked for formatting
parameters at {% cycle %}. Which back then had only one syntax:
{% cycle val1,val2,val3 %}
... where values were treated literally. No {% cycle %} has a more
proper syntax in addition to the old one. Unfortunately there's, as I
see, no way to do the same thing for {% url %}.
Having said that I'm actually +1 for the change. We're breaking a lot of
code on the road to 1.0 so nobody will notice such a small change :-)
Julien Phalip
regret not having done after 1.0 goes live). To back this up, the
above note has been hanging in the documentation for several months
(more than 8, as far as I can track back), so people could not say
that they weren't warned.
Over the last couple of weeks there's been lots of backward
incompatibilities introduced in trunk, so that would only be a small
extra one, and one that's easy to overcome.
Nicola Larosa (tekNico)
> Of course that's subjective, everything is.
--
Nicola Larosa - http://www.tekNico.net/
Johannes Dollinger
consciously.
Julien Phalip
there won't be other opportunities to discuss it.
Has Jacob or Adrian given the final word on this? If not, guys, tell
us what you think ;)
Whatever is decided, I guess the note in the documentation [1] should
go.
[1] http://www.djangoproject.com/documentation/templates/#url
On Jul 24, 1:16 am, Johannes Dollinger