Re: To keep or not to keep: logging of undefined template variables

[Vlastimil Zíma]

-1 to the removal. I was annoyed by the logging at first, but then I 
started to clean individual logs. Half way through, I found several usages 
of long removed variables, one unused template (as a side effect) and I 
updated several views to always provide defined context variables.

All in all, I consider the warnings very useful for a cleaning, though I 
wouldn't be against an option to silence them. Which can already by 
accomplished by LOGGING, can't it?

Vlastik

Dne neděle 26. března 2017 11:14:23 UTC+2 Melvyn Sopacua napsal(a):
>
> On Thursday 16 March 2017 12:03:07 Tim Graham wrote:
>
> > Ticket #18773 [0] added logging of undefined template variables in
>
> > Django 1.9 [1], however, I've seen several reports of users finding
>
> > this logging more confusing than helpful. 
>
>  
>
> With channels hitting 2.0 and the already large stack of moving parts 
> surrounding Django you need some basic system administration skills and 
> programming experience to work with the system. And there are quite a few 
> examples to link to from the user's list that deal with those moving parts 
> rather then Django itself. It is not an application that you download, 
> install and run.
>
>  
>
> An introduction "What you need to know before starting Django" would help 
> a lot in this respect and explaining the noisiness of some logging belongs 
> in there.
>
>  
>
> Because it *is* useful if you defined that variable to True in your 
> settings, and it's working in all projects but this one. It could be 
> there's an extra piece of context middleware that uses the same name and 
> deletes the variable from the context. It could be there's a Mixin missing 
> in the view hierarchy. Or a typo you don't notice anymore after plowing 
> through 20+ included template bits.
>
>  
>
> Noisy logging is exactly what you want when debugging. It should log 
> things that may be working as designed, especially things that are 
> ambiguous (like undefined and false).
>
>  
>
> Another thing is that logging is the ugly duckling of Django. It's not 
> mentioned much if at all in the tutorial. It is not mentioned at all in 
> "How to write reusable apps" and it shows in the eco system. It's like 
> finding a diamond when an app actually has logging implemented.
>
>  
>
> But it also means that novice users touching the LOGGING configuration are 
> exceptions and I don't think Django should cater to the exceptions.
>
>  
>
> -- 
>
> Melvyn Sopacua
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/80fafa13-ef3b-4b8c-9376-cc63b1776cb8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: To keep or not to keep: logging of undefined template variables

[Anthony King]

-1 for removing logs. Like Vlastimil, it's helped me spot a couple of stray
bugs.

What I'd actually like to see is this becoming stricter, with the end goal
of errors raising when using undefined variables.

For the verbosity, perhaps there's a middle ground? only log once per
variable access per template context, and provide a formatter that will
clean up the output?

I believe in debug mode, you have access to line numbers and character
positions, so the final output could look something like this:

``
some_app/home.html:32:24: Undefined variable: *missing_variable*
``

I'm unsure how much effort this would take, but it would definitely make
the logging a lot more user + developer friendly.

On 20 June 2017 at 08:48, Vlastimil Zíma  wrote:

> -1 to the removal. I was annoyed by the logging at first, but then I
> started to clean individual logs. Half way through, I found several usages
> of long removed variables, one unused template (as a side effect) and I
> updated several views to always provide defined context variables.
>
> All in all, I consider the warnings very useful for a cleaning, though I
> wouldn't be against an option to silence them. Which can already by
> accomplished by LOGGING, can't it?
>
> Vlastik
>
> Dne neděle 26. března 2017 11:14:23 UTC+2 Melvyn Sopacua napsal(a):
>>
>> On Thursday 16 March 2017 12:03:07 Tim Graham wrote:
>>
>> > Ticket #18773 [0] added logging of undefined template variables in
>>
>> > Django 1.9 [1], however, I've seen several reports of users finding
>>
>> > this logging more confusing than helpful.
>>
>>
>>
>> With channels hitting 2.0 and the already large stack of moving parts
>> surrounding Django you need some basic system administration skills and
>> programming experience to work with the system. And there are quite a few
>> examples to link to from the user's list that deal with those moving parts
>> rather then Django itself. It is not an application that you download,
>> install and run.
>>
>>
>>
>> An introduction "What you need to know before starting Django" would help
>> a lot in this respect and explaining the noisiness of some logging belongs
>> in there.
>>
>>
>>
>> Because it *is* useful if you defined that variable to True in your
>> settings, and it's working in all projects but this one. It could be
>> there's an extra piece of context middleware that uses the same name and
>> deletes the variable from the context. It could be there's a Mixin missing
>> in the view hierarchy. Or a typo you don't notice anymore after plowing
>> through 20+ included template bits.
>>
>>
>>
>> Noisy logging is exactly what you want when debugging. It should log
>> things that may be working as designed, especially things that are
>> ambiguous (like undefined and false).
>>
>>
>>
>> Another thing is that logging is the ugly duckling of Django. It's not
>> mentioned much if at all in the tutorial. It is not mentioned at all in
>> "How to write reusable apps" and it shows in the eco system. It's like
>> finding a diamond when an app actually has logging implemented.
>>
>>
>>
>> But it also means that novice users touching the LOGGING configuration
>> are exceptions and I don't think Django should cater to the exceptions.
>>
>>
>>
>> --
>>
>> Melvyn Sopacua
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/django-developers/80fafa13-ef3b-4b8c-9376-
> cc63b1776cb8%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CALs0z1YDm5OYt%2B_spdXz4pgoA652fPg8V9kuW_sMWTV-qHyeEQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

django.core.signing and safe characters

[Ole Laursen]

Hi!

Maybe this has no practical implications, but this has been bugging me for 
a couple of years now, ever since I started using django.core.signing to 
generate tokens: if you take a look at

  https://github.com/django/django/blob/master/django/core/signing.py

the comment at the top says

   There are 65 url-safe characters: the 64 used by url-safe base64 and the 
':'. 
   These functions make use of all of them.

Yet, : is specifically mentioned as a reserved character:

  https://perishablepress.com/stop-using-unsafe-characters-in-urls/

It is used for the scheme "https:". encodeURIComponent(":") returns "%3A".

If I do a test with a link like  in Firefox, the 
browser doesn't quote any of the colons, though. OTOH, if you put in 
"foo:bar/" as a relative link, foo: is interpreted as a scheme. So it's not 
unconditionally safe.

Furthermore, the above page lists some more characters as safe:

  $-_.+!*'(),

Of these only -_.!*'() are not quoted by encodeURIComponent and -_ (and 
perhaps .) are already taken by signing code.

But in any case, the comment, although satisfying to read, is AFAICT 
incorrect?

I don't know if it is worth it to switch to another default separator (say 
*). There would need to be a fallback to : for some years at least.


Ole

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/4b0fb342-53d8-4f36-90b6-d450e24bfdab%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: django.core.signing and safe characters

[Florian Apolloner]

Hi,

On Tuesday, June 20, 2017 at 12:18:21 PM UTC+2, Ole Laursen wrote:
>
> Yet, : is specifically mentioned as a reserved character:
>

It depends on the context. The assumption here is that the encoded data is 
always used as part of the path/querystring, for which rfc1738 says:

 Within the  and  components, "/", ";", "?" are reserved. The 
"/" character may be used within HTTP to designate a hierarchical structure.


In that sense, ":" is not a reserved character.

It is used for the scheme "https:". encodeURIComponent(":") returns "%3A".
>

The usefulness of that function seems questionable to me.
  

> If I do a test with a link like  in Firefox, 
> the browser doesn't quote any of the colons, though.


This is correct behaviour since ":" is not reserved after all.
 

> OTOH, if you put in "foo:bar/" as a relative link, foo: is interpreted as 
> a scheme. So it's not unconditionally safe.
>

That is true, but then again relative links are hardly useful for cases 
where d.c.signing is used (usually in an email or when providing a full 
link to a resource). Even if not, I'd strongly suggest to start with an 
absolute path at least.

I don't know if it is worth it to switch to another default separator (say 
> *). There would need to be a fallback to : for some years at least.
>

Given the "impact" it is imo not worth to change.

Cheers,
Florian 

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/b3e4c226-55b6-4fe1-bba2-1f93c3cbad65%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: should nonexistent template filter arguments resolve to string_if_invalid rather than raise VariableDoesNotExist?

[allejjandrozf]

# Some examples here for illustrate better my point of view:
from django.template import Context, Template

# CASE_1: shouldn't raise an exception because 'foo' variable exists in the 
context and 'default' filter
# shouldn't be invoked, 
Template('{{ foo|default:notreal }}').render(Context({'foo': ''}))   
#so, the output should be ''

# CASE_2: should raise an exception because 'foo' variable not exist in the 
context and 'default' filter
# will be invoked with non existent variable as argument, 
Template('{{ foo|default:notreal }}').render(Context({}))   #so, the 
output should be the exception VariableDoesNotExist

# CASE_3: should raise an exception because although 'foo' variable exists 
in the context and 'default' filter
# shouldn't be invoked, the filter 'center' is called with non existent 
variable as argument, 
Template('{{ foo|default:notreal|center:notreal2 
 }}').render(Context({'foo': '', }))   #so, the output should be the 
exception VariableDoesNotExist but for 'notreal2' variable

# CASE_4: shouldn't raise an exception because 'foo' variable exists in the 
context and 'default' filter
# shouldn't be invoked and also the filter 'center' is called with existent 
variable as argument, 
Template('{{ foo|default:notreal|center:notreal2 
}}').render(Context({'foo': 'django', 'notreal2':'15' }))   #so, the 
output should be ' django'

# and the same reasoning and analogous examples should be derived for 
'default_is_none' filter, only having in mind the definition of that filter


El lunes, 19 de junio de 2017, 19:58:56 (UTC-3), Tim Graham escribió:
>
> Could you describe your use case in more detail?
>
> On Monday, June 19, 2017 at 5:48:36 PM UTC-4, allejj...@gmail.com wrote:
>>
>> But if the current behaviour is left intact it goes against the 
>> definitions of filters like 'default' and 'default_if_none'.
>>
>> If one reads the code snippet example in the ticket, the exception is 
>> raised even when the filter shouldn't be invoked.
>>
>> So, for me the correct behaviour should be not raise any exceptions 
>> (maybe a warning could be used) in cases when filters used are 'default' or 
>> 'default_if_none', and are applied to a variable with a valid value that 
>> not trigger these filters.
>>
>> Only we should focus to resolve (or raise VariableDoesNotExiste exception 
>> if applies) the variables in other filters, e.g if we have more chaining 
>> filters with variables like:
>>  
>> Template('{{ foo|default:notreal1|date:notreal2 
>> }}').render(Context({'foo': '', notreal2: 'as'})).
>>
>>
>> El lunes, 19 de junio de 2017, 15:10:54 (UTC-3), Tim Graham escribió:
>>>
>>> I think that to convince me to change the current behavior, you would 
>>> have to present a compelling use case for relying on nonexistent variables 
>>> as filter arguments. Wouldn't this behavior typically just hide bugs?
>>>
>>> On a related note, I proposed removing the logging of undefined template 
>>> variables here: 
>>> https://groups.google.com/d/topic/django-developers/zdULZcmAWNw/discussion
>>>
>>> On Saturday, June 3, 2017 at 10:30:51 AM UTC-4, Shai Berger wrote:

 On Friday 02 June 2017 18:38:47 Vlastimil Zíma wrote: 
 > 
 > Shai: Values are sometimes turned into an empty string in case of 
 > UnicodeDecodeError, see 
 > 
 https://github.com/django/django/blob/master/django/template/base.py#L994-L
  
 > 998 
 > 

 That code is within a render() method -- a place where the value is 
 already 
 going to be turned into a string. 

 > IMO invalid variable should behave the same way regardless of whether 
 it's 
 > printed or used as an filter argument. 
 > 

 My point was that rendering makes a difference because it already 
 implies a 
 possible type change. 

 I stand by my earlier position: Changing a filter argument to a string 
 is odd 
 and unexpected and we shouldn't do this. We should either keep raising 
 an 
 exception, or replace the whole filter expression (rather than just the 
 argument) with string_if_invalid. My preference is towards the 
 exception, but 
 I also see the value of failing silently here. 

 Shai. 

>>>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/1c3125b8-08a0-48c0-a5d4-d2fd850fdc32%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.