We could use the same name or just |trusted.
I'm not so concerned with the `safe` tag as it's already an adjective, but
I would be ok with an alias for trusted also.
On Friday, 23 February 2018 08:24:50 UTC+11, Florian Apolloner wrote:
>
>
>
> On Thursday, February 22, 2018 at 9:52:04 PM UTC+1,
On Thursday, February 22, 2018 at 9:52:04 PM UTC+1, Josh Smeaton wrote:
>
> Or, since this isn't a template tag (facepalm)
>
Which raises a perfectly valid point: If we were to change this, we will
also need to come up with a new name for the "|safe"-filter.
--
You received this message bec
Or, since this isn't a template tag (facepalm)
trusted_html(m.content)
trust_html(m.content)
On Friday, 23 February 2018 07:46:45 UTC+11, Josh Smeaton wrote:
>
> Yes I'm not a fan of the *dangerously...* names either. I'm still
> somewhat wary of *trust_html* which is a *verb* and could still
You're right, trusted_html is a better name than trust_html. I think either
is superior to mark_safe however.
Regarding deprecations, deprecating mark_safe will cause a lot of churn
even if the migration path is as simple as a rename. We should keep the old
alias around for a long time, but promot
Yes I'm not a fan of the *dangerously...* names either. I'm still somewhat
wary of *trust_html* which is a *verb* and could still confuse users in a
similar way (does the api make it trustworthy?). I think I'd prefer
something more descriptive like *trusted_html*.
{{ content|trusted_html }}
vs
Hello,
is everybody fine with the documentation of mark_safe?
I think by default people don't come to the idea to use mark_safe
except on occasions, where they notice their output is not the desired
one. Then investigations on rendering to achieve the right output
lead to mark_safe() and
Yes, people read *mark_safe* as *MAKE_safe*, I'm not sure yet, but I'm
liking the idea of *trust_html*, I feel like more developers will
understand what they're doing.
Maybe the docs could have more detailed notes about HTML inputs that you
want to mark them safe, one thing is trust "" another
I am also in favour of a rename without deprecating the old name.
I like 'trust_html' - it's still similarly short but as Tom says it implies
more than 'mark_safe' does.
On 22 February 2018 at 08:30, Tom Forbes wrote:
> What about just 'trust_html'? The dangerous part is quite context
> depende
What about just 'trust_html'? The dangerous part is quite context dependent
(and a bit of mouth-full), but at the core you are trusting the HTML.
Hopefully it follows that you should not trust html with user input that
hasn't been escaped.
On 22 Feb 2018 13:10, "Anthony King" wrote:
I entirely a
I entirely agree with renaming `mark_safe`. Though it's name is correct, it
doesn't convey the gravity of what this actually does.
However I'm unsure on the `dangerously_trust_html` name. It wouldn't be
dangerous to trust the literal "Some Content", for example.
Perhaps it could be something a bit
I don't know that "dangerously_trust_html" is a better name. The argument
is supposed to be a string that you know is trusted so there shouldn't be
any danger involved. Naming something based on how it could be misused
seems odd.
For me, mark_safe() is a fine name, but maybe that preference is
The concern isn't overusing an API. It's not understanding the proper use
case for it.
"mark safe" can sound like the API is doing sanitation so it can encourage
developers to use it incorrectly. I'm fairly sure I've done this myself.
The intended meaning is "this output is **already** safe" bu
Yeah, I am also worried about the churn for no gain in my eyes. If users
overuse mark_safe, they will overuse dangerously_trust_html too…
On Wednesday, February 21, 2018 at 10:41:15 PM UTC+1, Josh Smeaton wrote:
>
> I agree that the names are misleading and we should probably provide
> better na
13 matches
Mail list logo
