Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

You Should Learn Regex

blog.patricktriest.com

Post reply on HN
Print view View original

51–57 of 57 posts

Re: You Should Learn Regex

#51

Post by extra88 »

Invisig0th wrote: post #47
kqr wrote: post #31

Earlier quoted context omitted.

...but unless you actually send an email it is still just as unvalidated as it was before. Regexes aren't a tool to determine that a string refers to a mailbox capable of receiving mail. If you use regexes (or any other method of that does not send emails) all you're saying is that you don't actually care whether or not the string points to a recipient (much less the correct recipient). And don't get me wrong. It is…

Regex validation cannot verify that an email address is functioning any more than it can verify that a phone number is functioning. But if an address or a number passes formatting checks, one can indeed consider that data "validated". That's what that term means in the business software development industry. We're verifying if the data entered COULD be correct, not double-checking that it IS correct. You are correct…

The point is the vast majority of regexes attempting to validate an email address will produce false negatives, reject valid email addresses. If a regex must exist, it should strip all whitespace characters first, confirm there is a single '@' with one or more characters before it, and two or more characters after it (the davidcel.is article mentions checking for a dot but a@us could be a valid address that would fail that test); it should not balk at character sets other than ASCII.

If you want to do some additional non-regex validation, like confirm the hostname exists and has an MX record, have at it.

Re: You Should Learn Regex

#52

Post by kqr »

Invisig0th wrote: post #47
kqr wrote: post #31

Earlier quoted context omitted.

...but unless you actually send an email it is still just as unvalidated as it was before. Regexes aren't a tool to determine that a string refers to a mailbox capable of receiving mail. If you use regexes (or any other method of that does not send emails) all you're saying is that you don't actually care whether or not the string points to a recipient (much less the correct recipient). And don't get me wrong. It is…

Regex validation cannot verify that an email address is functioning any more than it can verify that a phone number is functioning. But if an address or a number passes formatting checks, one can indeed consider that data "validated". That's what that term means in the business software development industry. We're verifying if the data entered COULD be correct, not double-checking that it IS correct. You are correct…

And what I'm saying is that either the system relies on functioning email addresses, in which case they need to be ensured to work anyway. ...or the system does not rely on working email addresses, in which case drop the pretense, make it an optional field and peoples' days will suck less.

Besides the practical issues mentioned, it's this no-brained "why the heck not" collection of personal data I'm turning against. Either you need the stuff and then you have to work for it, or you dont and then you have nothibg to do with it.

Re: You Should Learn Regex

#53

Post by [deleted] »

kqr wrote: post #52
Invisig0th wrote: post #47

Earlier quoted context omitted.

Regex validation cannot verify that an email address is functioning any more than it can verify that a phone number is functioning. But if an address or a number passes formatting checks, one can indeed consider that data "validated". That's what that term means in the business software development industry. We're verifying if the data entered COULD be correct, not double-checking that it IS correct. You are correct…

And what I'm saying is that either the system relies on functioning email addresses, in which case they need to be ensured to work anyway. ...or the system does not rely on working email addresses, in which case drop the pretense, make it an optional field and peoples' days will suck less. Besides the practical issues mentioned, it's this no-brained "why the heck not" collection of personal data I'm turning against.…

[deleted]

Re: You Should Learn Regex

#54

Post by [deleted] »

kqr wrote: post #52
Invisig0th wrote: post #47

Earlier quoted context omitted.

Regex validation cannot verify that an email address is functioning any more than it can verify that a phone number is functioning. But if an address or a number passes formatting checks, one can indeed consider that data "validated". That's what that term means in the business software development industry. We're verifying if the data entered COULD be correct, not double-checking that it IS correct. You are correct…

And what I'm saying is that either the system relies on functioning email addresses, in which case they need to be ensured to work anyway. ...or the system does not rely on working email addresses, in which case drop the pretense, make it an optional field and peoples' days will suck less. Besides the practical issues mentioned, it's this no-brained "why the heck not" collection of personal data I'm turning against.…

[deleted]

Re: You Should Learn Regex

#55

Post by [deleted] »

kqr wrote: post #52
Invisig0th wrote: post #47

Earlier quoted context omitted.

Regex validation cannot verify that an email address is functioning any more than it can verify that a phone number is functioning. But if an address or a number passes formatting checks, one can indeed consider that data "validated". That's what that term means in the business software development industry. We're verifying if the data entered COULD be correct, not double-checking that it IS correct. You are correct…

And what I'm saying is that either the system relies on functioning email addresses, in which case they need to be ensured to work anyway. ...or the system does not rely on working email addresses, in which case drop the pretense, make it an optional field and peoples' days will suck less. Besides the practical issues mentioned, it's this no-brained "why the heck not" collection of personal data I'm turning against.…

[deleted]

Re: You Should Learn Regex

#56

Post by not_kurt_godel »

This sounds like an article I would have written in college. In my experience, if you're using regex often enough to remember how to write patterns that are sufficiently complex to actually be useful beyond short 'pre-processing' snippets, you're overusing regex. (Or alternatively, your memory is significantly better and/or less divided than mine.)

Re: You Should Learn Regex

#57

Post by bmn__ »

philipov wrote: post #35
submeta wrote: post #11

When I used to code in Perl (more than ten years ago) I tended to solve many many things using regexes. I tried to reduce many programming challenges into transformations that I could do via regexes. Why? Because regular expressions are first class citizens in Perl. And Perl made me learn and use them. (Reminds me of a an APL programmer that saw vectors everywhere.) When I replaced Perl with Python in my toolbox I ab…

Regex patterns might not be first class citizens in python, but they're easy enough to use, and I think they're ultimately more powerful than in Perl. I don't remember being able to use a callback to calculate my replace string as a function of the match results when doing substitution in Perl. It's super easy to do tokenization with python regexes. We lose first class patterns, but gain first class functions and cla…

> I don't remember being able to use a callback to calculate my replace string as a function of the match results when doing substitution in Perl.

That's easy with the `e` (eval) flag.

    say '13 37 123 42' =~ s
        { ( \d+ )           # get all the numbers }
        { my $total += $+;  # replace with running total }egrx;
    __END__
    output is 13 50 173 215
> I think they're ultimately more powerful than in Perl

No. Perl regex are more powerful than Python because

1. the programmer can pick from a large selection of delimiters

2. the full-featured engine is built-in and ready to use, but in Python you need to install the third-party "regex" module because the built-in one named "re" is hopelessly dyd¹

3. you may enable verbose (readable) character classes

4. the regex subsystem is pluggable with a common interface and you can within a lexical scope switch at run-time with more restricted implementations which have less features but better performance in some cases: https://metacpan.org/search?q=re%3A%3Aengine%3A%3A

5. you can embed arbitrary code with (?{...}) and (??{...})

> We lose first class patterns, but gain first class functions and classes :)

Perl had first-class functions since 1993.

You love having first-class classes in Python, but do not realise the downside. Python's one true meta object system (with its ageing design from the last millennium) is flawed: horizontal composition of methods with the same name does not emit a warning. Since the system is baked into the language, it cannot be changed. Contrast with Perl, where the language only provides some primitives on which to build a meta object system (incl. first-class classes). This enables bugs to be fixed, and the competition among several implementations on CPAN breeds excellence.

¹ https://i.imgur.com/66z4KDA.jpg

Post reply on HN