Cool, PR here: https://github.com/django/django/pull/12479
On Thu, Feb 20, 2020 at 1:59 AM Adam Johnson wrote:
> I guess it's not a very big change so could be worth it to increase
> readability.
>
> On Wed, 19 Feb 2020 at 16:12, Ram Rachum wrote:
>
>> In any case, if it's decided that it's a
I guess it's not a very big change so could be worth it to increase
readability.
On Wed, 19 Feb 2020 at 16:12, Ram Rachum wrote:
> In any case, if it's decided that it's a worthwhile change, I'll be happy
> to make the patch.
>
> On Wed, Feb 19, 2020 at 10:31 AM Adam Johnson wrote:
>
>> The wik
I agree that "dangerously" doesn't and shouldn't be in the name - it's
unnecessarily verbose.
I think a name like "no_escape" ,or similar, conveys the meaning properly
and is no more verbose than mark_safe.
On Thursday, 20 February 2020 10:16:12 UTC+11, Kye Russell wrote:
>
> Personally I thin
Personally I think that the current name does a fairly good job of conveying
the effect, and this is coming from someone who doesn’t explicitly understand
the internal process and is merely inferring it.
However my anecdote doesn’t negate what we all see around the internet, so I
suppose it ca
My thoughts:
Use and promote a different name that does not make it sound like Django is
making the string safe for you.
Alias the new name to the old names to prevent churn.
Remove all references of the old name from the docs.
What the name should be, meh.
On Thu, 20 Feb 2020 at 03:56, Adam J
I think it's a non-invasive worthwhile change and that a PR for it would be
well received.
Le mercredi 19 février 2020 11:13:15 UTC-5, Ram Rachum a écrit :
>
> In any case, if it's decided that it's a worthwhile change, I'll be happy
> to make the patch.
>
> On Wed, Feb 19, 2020 at 10:31 AM Adam
Sorry I was a bit keen after a reminder of the thread by Josh Smeaton on
reddit. I skimmed again and it felt like there was consensus on some kind
of rename, and it had moved to decision on the name. I guess I'm also sick
of fixing this in client projects :)
I think your concerns are fair and well
In any case, if it's decided that it's a worthwhile change, I'll be happy
to make the patch.
On Wed, Feb 19, 2020 at 10:31 AM Adam Johnson wrote:
> The wikipedia page says:
>
> In cryptography, a salt is random data that is used as an additional input
>> to a one-way function that hashes data, a
Hi izaias de oliveira elias, this is an existing thread in the Django
Developers group.
What you want is to create a new thread in the Django Users group:
https://groups.google.com/forum/#!forum/django-users
On Tuesday, February 18, 2020 at 5:51:22 PM UTC-5, izaias de oliveira elias
wrote:
>
>
Hi All,
Calendar Week 6 -- ending 09 February.
Triaged:
https://code.djangoproject.com/ticket/31229 -- Add setting to allow
flexible session saving based on response codes (wontfix)
https://code.djangoproject.com/ticket/31232 -- Add secure default
SECURE_REFERRER_POLICY / Referrer-policy h
I've just closed the ticket as wontfix, because I'm not seeing a consensus
for the change here. I'm seeing a few Yeahs and a few Mehs.
That doesn't mean we can't have it, but the procedure is generally agree
here before a ticket.
So can I ask, those wanting this, to make the case here, then we
I made a ticket for this: https://code.djangoproject.com/ticket/31287
On Fri, 23 Feb 2018 at 08:53, Kamil wrote:
> The name "mark_safe" unnecessarily exposes an implementation detail.
> People who misunderstand this API probably have no idea how this "marking"
> happens, it would make sense to n
The wikipedia page says:
In cryptography, a salt is random data that is used as an additional input
> to a one-way function that hashes data, a password or passphrase. Salts are
> used to safeguard passwords in storage.
Ram is right - this variable is not a salt in that definition. We aren't
usi
13 matches
Mail list logo
