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
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
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
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
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 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
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
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 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
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
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
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
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,
13 matches
Mail list logo
