Hello Tim,
I got confused and didn't realize Claude was arguing against moving to the HTML
validation rules. Oops.
I'm still +0 on copying HTML validation rules strictly so that and EmailField behave identically by default. (+0 rather than +1
because I'm mostly care about ending this debate.)
Aymeric, did anything specific change your mind from your March 2016 mail:
"Indeed, for some reason, the URL and email validators get anywhere from 2
to 8 changes in every Django version, and there’s no end in sight. (I
contributed to this. Sorry.) Like James, I’m in favor of making the
I agree with Claude.
--
Aymeric.
> On 1 Jun 2017, at 09:50, Claude Paroz wrote:
>
> As for me, I still think the current validator is valid for 99% of use cases.
> And 99% of the time, an email address with dot-less domain is a user input
> error.
>
> So I would
As for me, I still think the current validator is valid for 99% of use
cases. And 99% of the time, an email address with dot-less domain is a user
input error.
So I would prefer fixing #25594 (validator propagation from db field to
form field), adding a "looser" validator in validators.py and
Hi All,
There's a PR [0] to make validation match HTML. Though there's a question
about what to do with domain_whitelist.
Here's the background:
- Originally Django didn't allow any dotless (non-FQDN) domain names.
- People wanted to use "localhost", but the SMTP spec said "Local nicknames
or
Any thoughts about whether or not to make similar simplifications to
URLValidator? There's an old ticket to add a DomainNameValidator [0] which
may or may not be worth moving forward with based on the decision.
[0] https://code.djangoproject.com/ticket/18119
On Saturday, April 2, 2016 at
On Saturday 02 April 2016 09:44:54 Josh Smeaton wrote:
> For what reason Zach?
There is only one reason for which a strict and accurate validation is
required, as far as I can see, and that is if your application is not just
using existing email addresses (i.e. sending mail to users) but
For what reason Zach? Without a canonical regex implementation to copy or
include, we're stuck poorly reimplementing a bunch of esoteric rules to
what end? The main purpose of email validation is to provide relevant
feedback to the user, and to guard against obviously bad or malicious data.
-1 on less strict validation. Saying we need less strict validation because
emails are usually confirmed by sending an email to it, is akin to saying
urls are only valid if the url can be fetched. "Looks vaguely like a url"
would not be enough for validation purposes. I believe we should strive
On Thursday 31 March 2016 02:03:26 Florian Apolloner wrote:
> Having a new field seems overkill to me -- a new validation routine which
> is less strict is something we should be able to do without backward compat
> considerations.
Strictly speaking, the new method is not less strict. It does
On Wednesday 30 March 2016 15:45:23 Tim Graham wrote:
> How did you imagine the deprecation cycle working? Do you want Django to
> raise a warning saying that the regular expression is changing and provide
> a temporary setting or something to opt-in to the simpler validation?
>
Yes, that's one
How did you imagine the deprecation cycle working? Do you want Django to
raise a warning saying that the regular expression is changing and provide
a temporary setting or something to opt-in to the simpler validation?
On Saturday, March 26, 2016 at 5:25:04 AM UTC-4, Shai Berger wrote:
>
> On
On Tuesday 15 March 2016 04:51:50 Markus Holtermann wrote:
>
> WRT the backwards compatibility issues:
>
> 2) You're not able to submit an email address that does not pass the new
> validator but the old one. --> Unlikely, but when the new field is of
> type="email" your rather modern browser
Validation that doesn't rely on browser behavior *is* useful, if only for
the (admittedly shrinking, but still non-zero) population of folks using
older browsers. Also API clients and so forth.
Very much agreed that it should match the HTML5 spec, though - fewer edge
cases and more predictable
Is there a reason for having a backend validation at all?
There is no reliable way to validate an email-address without actually
sending a message to it.
In my opinion EmailField should use a widget that uses `type="email"` to
trigger frontend validation.
It may also set a max length for the
> On 15 Mar 2016, at 03:51, Markus Holtermann wrote:
>
> I'd go with the HTML5 validator.
Indeed, it would be a good idea to align the behavior of
and Django’s validation. Currently a@b passes the former but not the latter.
--
Aymeric.
--
You received this
On Mon, Mar 14, 2016 at 12:34:40PM -0700, Florian Apolloner wrote:
On Monday, March 14, 2016 at 8:08:09 PM UTC+1, Michael Manfre wrote:
Simple is better. Anyone who needs/wants something more complex is not
prevented by Django from doing so.
+1 to that and what the rest said ;)
+1
As
On Tuesday, March 15, 2016 at 12:29:42 AM UTC+1, Josh Smeaton wrote:
>
> +1. I don't think we need strict email validation. "looks vaguely like an
> email address" is enough for validation purposes in forms. Are there any
> security concerns we need to be aware of though?
>
Absolutely, the
+1. I don't think we need strict email validation. "looks vaguely like an
email address" is enough for validation purposes in forms. Are there any
security concerns we need to be aware of though?
On Tuesday, 15 March 2016 05:17:15 UTC+11, James Bennett wrote:
>
> Personally I've long been in
On Monday, March 14, 2016 at 8:08:09 PM UTC+1, Michael Manfre wrote:
>
> Simple is better. Anyone who needs/wants something more complex is not
> prevented by Django from doing so.
>
+1 to that and what the rest said ;)
>
> Regards,
> Michael Manfre
>
> On Mon, Mar 14, 2016 at 2:31 PM,
Simple is better. Anyone who needs/wants something more complex is not
prevented by Django from doing so.
Regards,
Michael Manfre
On Mon, Mar 14, 2016 at 2:31 PM, Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:
> Indeed, for some reason, the URL and email validators get anywhere
Personally I've long been in favor of drastically simplifying the email
regex and essentially telling people that if they want to support
triply-nested comments in a bang-path address they can write their own :)
Is there an actual compelling reason to not just pare it down to "word
characters
22 matches
Mail list logo