41–50 of 60 posts
It helps to know the basic syntax by memory, but you can just as easily look it up if you understand how they work.
Earlier quoted context omitted.
A typical regex looks like this: \b[A-Z0-9._%-]+@[A-Z0-9.-]+\.[A-Z]{2,4}\b Which is also what happens when a cat walks across the keyboard.
I find that perfectly readable, except for the \b which I hadn't seen before. It's matching an all-uppercase email address.
Earlier quoted context omitted.
How would you design a regular expression syntax more intuitively? Personally, I find beauty and simplicity in regular expressions. Sure, they can grow to hideous atrocities, but you can achieve such disastrous feats with any language/syntax. Maybe you could back up your claim of regexes being a disgusting abomination with, at the very least, anecdotal evidence.
A typical regex looks like this: \b[A-Z0-9._%-]+@[A-Z0-9.-]+\.[A-Z]{2,4}\b Which is also what happens when a cat walks across the keyboard.
(?x: #standard token is an uppercase letter, digit, dot, or hyphen
\b
[A-Z0-9._%-]+ #1 or more of standard token, underscore, or percent sign
@ #at-sign
[A-Z0-9.-]+ #1 or more standard tokens
\. #dot
[A-Z]{2,4} #2 to 4 uppercase letters
\b
)
Yes, it is, without a doubt. It's one of the most universal tricks of the trade that you'll literally never regret learning, mainly because just about any environment you'll ever work in will by necessity support regexes, and in many, it will be the primary way you interact with text. But it's also a must that you realize that despite the fact that they're exceptionally useful and widely supported, regexes are a disg…
Earlier quoted context omitted.
How would you design a regular expression syntax more intuitively? Personally, I find beauty and simplicity in regular expressions. Sure, they can grow to hideous atrocities, but you can achieve such disastrous feats with any language/syntax. Maybe you could back up your claim of regexes being a disgusting abomination with, at the very least, anecdotal evidence.
A typical regex looks like this: \b[A-Z0-9._%-]+@[A-Z0-9.-]+\.[A-Z]{2,4}\b Which is also what happens when a cat walks across the keyboard.
[It's also perfectly obvious that if this is an attempt to match email addresses that it's not a very good one - but I don't know the context where it's supposed to be used, it might be good enough for whatever the author intended].
Yes, it is, without a doubt. It's one of the most universal tricks of the trade that you'll literally never regret learning, mainly because just about any environment you'll ever work in will by necessity support regexes, and in many, it will be the primary way you interact with text. But it's also a must that you realize that despite the fact that they're exceptionally useful and widely supported, regexes are a disg…
Hmm - you know I actually think it's not correct to look at regex as an interface - even though we use it as one. It's really more accurate to look at it as a grammar (type 3 if I remember correctly). Anything that comes out of the whole chomskian hierarchy stuff isn't going to look intuitive. But the point is that it is a particular, very rigorously defined system of representation. And various systems of representa…
This applies only to the theoretical computer science regexes. The practical regexes are very different in this aspect.
Practical regexes are neither discovered nor invented - they are constructed. The theoretical regexes are just the basis but on top of that there's a lot of features added. Some of them are just syntactic sugar for theoretical regexes but others actually make the language non-regular.
Groups that match what previous named groups have matched are definitely in this category.
Earlier quoted context omitted.
I find that perfectly readable, except for the \b which I hadn't seen before. It's matching an all-uppercase email address.
There's plenty of upper case e-mail addresses that won't match that expression.
Earlier quoted context omitted.
There's plenty of upper case e-mail addresses that won't match that expression.
/i
if "@" in email and "." in email.split("@")[1]:
send_verification(email)
[1] http://en.wikipedia.org/wiki/Email_address#Syntax [2] http://en.wikipedia.org/wiki/List_of_Internet_top-level_doma...
But you will be limited. You will run into a lot of situations where your ignorance will create friction and limitations. Something as simple as editing an nginx configuration file, for example.
You should learn regexes, you should be able to use a regex as necessary and be able to understand regexes you come across, you should understand when they are most useful, and when they are not. You should learn their limits and your limits in using them as well. When used appropriately they can be a potent addition to your technical knowledge. When they should be used but are avoided the result is typically a massive inflation of the effort to solve a simple problem. And when used incorrectly they can result in an inflation of intractable complexity (much like any technology).