Thank you Adam,
This is more or less what I ended up doing, sans the replace call, very
neat!
And thanks a lot for the expert advice, everyone!
For the time being at least, it seems we have an agreement on not allowing
non-strict validation into Django and I have to agree it just makes sense
>
> Folks wanting this can subclass URLValidator.
>
For anyone who does want this, the subclass is not so much work. You can
inherit the regex pieces from URLValidator and edit them to insert _ as a
valid character:
In [18]: import re
...:
...: from django.core.validators import URLValida
I'm also in the "I don't think this should be allowed" camp. People
who really need it can set up their own validator easily enough, and I
worry about the security implications of supporting non-standard
behavior in something as crucial as hostname validation -- Django's
been bitten by that sort of
> By all means add a lenient=False flag which can be turned to True to
enable lenient parsing...
I don't think we should even allow this. The extra API surface area
complicates the matter for all users, almost all of whom are never going to
set the new flag to anything but the default. (Of thos
Hi Adam,
On Wednesday, March 25, 2020 at 7:27:58 PM UTC+1, Adam Johnson wrote:
>
> I think that would make Florian happy, although it *has* been seven years
> since his closing comment on the ticket.
>
You should know me better :D No this would not make Florian happy and he is
still against it.
You're right there are two use cases here. It does sound like the pragmatic
approach is to allow underscores in URL's normally, but to preserve the
existing behaviour for those with stricter use cases, like you say.
I can also propose a solution that would still work for both: (deprecate
> and) re
Hey folks,
Sorry for not providing a more specific scenario before, was short on time
and just wanted to kick this off.
The most common scenario that I can think of (and the one that most similar
to our usage) would be a *form field* on a Django site, that allows users
to input a URL which is
> when there are many sites in the wild that use underscore in their domain
> name.
Can you share some examples please ?
In general, we should abide by standards unless we have a really good reason.
In my experience I always had to replace underscores by dashes for a reason or
another in hostn
Hi Pavel
The ticket ( https://code.djangoproject.com/ticket/20264 ) doesn't mention
any specific use cases, and nor have you. What has this behaviour blocked
for you?
Thanks,
Adam
On Tue, 24 Mar 2020 at 12:46, Pavel Savchenko wrote:
> Hi Folks,
>
> I've just encountered this issue, and it see