151–160 of 382 posts
Does anyone consider RegEx to be standardised? Moving to a new context is always a relearning exercise in my experience.
Earlier quoted context omitted.
The line delimiter is a newline. If you have a file containing `A\nB\nC` in a file, the file is three lines long. I guess it could be argued that a file containing `A\nB\nC\n` has four lines, with the fourth having zero length. That a regex is applying to an in memory string vs a file doesn't feel to me like it should have different semantics. Digging into the history a little, it looks like regexes were popularized…
Technically the “newline” character is actually a line _terminator_. Hence “A\n” is one line, not two. The “\n” is always at the end of a line by definition.
Earlier quoted context omitted.
…which both excludes addresses allowed by the RFC and includes addresses disallowed by the RFC. (For example, the RFC disallows two consecutive dots in the local-part.)
I take the descriptivist approach to email validation, rather than the prescriptivist. I know an email has to have a domain name after the @ so I know where to send it. I also know it has to have something before the @ so the domain’s email server knows how to handle it. But do I care if the email server is supports sub addresses, characters outside of the commonly supported range (eg quotation marks and spaces), or…
Earlier quoted context omitted.
regex is useful but chatgpt is amazing at it, so why spend a minute keeping such useless knowledge in mind. if you know where to find something no point in knowing it.
Does gpt produce efficient regex? Are there any experts here that can assess the quality and correctness of gpt-generated regex? I wonder how regex responses by gpt are validated if the prompter does not have the knowledge to read the output.
Earlier quoted context omitted.
…which both excludes addresses allowed by the RFC and includes addresses disallowed by the RFC. (For example, the RFC disallows two consecutive dots in the local-part.)
I take the descriptivist approach to email validation, rather than the prescriptivist. I know an email has to have a domain name after the @ so I know where to send it. I also know it has to have something before the @ so the domain’s email server knows how to handle it. But do I care if the email server is supports sub addresses, characters outside of the commonly supported range (eg quotation marks and spaces), or…
Though I guess adding a check for invalid dot patterns might be worthwhile.
Seriously, just write one unit test for your regex.
This, in a nutshell, is the sort of problem which renders fallacious the notion that you can unit-test your way to correct software.
Earlier quoted context omitted.
Technically the “newline” character is actually a line _terminator_. Hence “A\n” is one line, not two. The “\n” is always at the end of a line by definition.
So if you have "A" in a file with no newline, there are no lines in that file?
https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1... ("text file")
Earlier quoted context omitted.
Because even after disabling multi-line you are still dealing with line-based semantics when you use ^ or $, the newline at the end is still not part of the content. You have to use \A and \Z if you want to treat all characters as a string instead of one or multiple lines.
> Because even after disabling multi-line you are still dealing with line-based semantics when you use ^ or $ No, you're not, except for this weird corner case where `$` can match before the last `\n` in a string. It's not just any `\n` that non-multiline `$` can match before. It's when it's the last `\n` in the string. See: >>> re.search('cat$', 'cat\n') >>> re.search('cat$', 'cat\n\n') >>> This is weird behavior. I…
One could certainly have a debate whether this behavior is too strongly tied to the origins of regular expressions and now does more harm than good, but I am not convinced that this would be an easy and obvious choice to have breaking change.
- The JS/Go/Rust family, which treats $ like \z and does not support \Z at all
- The Java, .NET, PHP, Python family, which treats $ like \Z and may or may not (Python) support \z.
\Z does away with \n before the end of the string, while \z treats \n as a regular character. For multiline $ the distinction doesn't matter, because \n is the end.
Really the only deviation from the rule is Python's \Z, which is indeed weird.