Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #83625 > unrolled thread

Re: Python 3 regex?

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Python 3 regex? Ian <hobson42@gmail.com> - 2015-01-12 19:48 +0000
    Re: Python 3 regex? Rick Johnson <rantingrickjohnson@gmail.com> - 2015-01-12 15:47 -0800
      Re: Python 3 regex? Chris Angelico <rosuav@gmail.com> - 2015-01-13 10:52 +1100
      Re: Python 3 regex? Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-01-13 01:54 +0000
        Re: Python 3 regex? Rick Johnson <rantingrickjohnson@gmail.com> - 2015-01-12 18:53 -0800
          Re: Python 3 regex? Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-01-13 05:34 +0000
            Re: Python 3 regex? Rick Johnson <rantingrickjohnson@gmail.com> - 2015-01-13 08:01 -0800
          Re: Python 3 regex? wxjmfauth@gmail.com - 2015-01-13 11:19 -0800
            Re: Python 3 regex? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-01-14 14:02 +0100
              Re: Python 3 regex? alister <alister.nospam.ware@ntlworld.com> - 2015-01-14 15:11 +0000
                Re: Python 3 regex? wxjmfauth@gmail.com - 2015-01-14 10:10 -0800
              Re: Python 3 regex? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-01-15 11:33 +1100
                Re: Python 3 regex? wxjmfauth@gmail.com - 2015-01-14 23:03 -0800
                  Re: Python 3 regex? wxjmfauth@gmail.com - 2015-01-15 00:19 -0800
                Re: Python 3 regex? wxjmfauth@gmail.com - 2015-01-15 04:49 -0800
      Re: Python 3 regex? Steven D'Aprano <steve@pearwood.info> - 2015-01-13 06:39 +0000
        Re: Python 3 regex? Rick Johnson <rantingrickjohnson@gmail.com> - 2015-01-13 09:09 -0800
          Re: Python 3 regex? Rick Johnson <rantingrickjohnson@gmail.com> - 2015-01-13 10:17 -0800
    Re: Python 3 regex? Steven D'Aprano <steve@pearwood.info> - 2015-01-13 04:36 +0000
      Re: Python 3 regex? alister <alister.nospam.ware@ntlworld.com> - 2015-01-13 13:23 +0000
        Re: Python 3 regex? Jussi Piitulainen <jpiitula@ling.helsinki.fi> - 2015-01-13 15:58 +0200
      Re: Python 3 regex? Rustom Mody <rustompmody@gmail.com> - 2015-01-14 21:03 -0800
      Re: Python 3 regex? Rustom Mody <rustompmody@gmail.com> - 2015-01-14 21:08 -0800

Page 1 of 2  [1] 2  Next page →

#83625 — Re: Python 3 regex?

On 12/01/2015 18:03, Jason Bailey wrote:
> Hi all,
>
> I'm working on a Python _3_ project that will be used to parse ISC 
> DHCPD configuration files for statistics and alarming purposes (IP 
> address pools, etc). Anyway, I'm hung up on this one section and was 
> hoping someone could provide me with some insight.
>
> My script first reads the DHCPD configuration file into memory - 
> variable "filebody". It then utilizes the re module to find the 
> configuration details for the wanted "shared network".
>
Hi Jason,

If you actually look at the syntax of what you are parsing, it is very 
simple.

My recommendation would be to write a recursive decent parser for your 
files.

That way will be easier to write, much easier to modify and almost 
certainly faster that a RE solution - and it can easily give you all the 
information in the file thus future proofing it.

'Some people, when confronted with a problem, think "I know, I'll use 
regular expressions." Now they have two problems.' -  Jamie Zawinski.

Regards

Ian

[toc] | [next] | [standalone]

#83648

> 'Some people, when confronted with a problem, think "I
> know, I'll use regular expressions." Now they have two
> problems.' -  Jamie Zawinski.

This statement is one of my favorite examples of "powerful
propaganda", which has scared more folks away from regexps
than even the "Upright Citizens Brigade" could manage with
their "Journey through the center of gas giant #7" and it's
resulting "aggravated assault" on American coinage!

I wonder if Jamie's conclusions are a result of careful
study, or merely, an attempt to resolve his own cognitive
dissonance? Of course, if the latter is true, then i give
him bonus points for his use of the third person to veil his
own inadequacies -- nice Jamie, *verrrrry* nice!

    "Rick it sounds like you're accusing Jamie of cowardice
    resulting in "sour grapes"?"

Indeed! The problem with statements like his is that, the
ironic humor near the end *fortifies* the argument so much
that the reader forgets the limits of the harm (quantified
as: "some people") and immediately accepts the consequences
as effecting "all people who choose to use regexps", or more
generally, accepts the argument as a "universal unbounded
truth". Besides, who would want to be a member of a group
for which the individuals are too stupid to know good
choices from bad choices?

    HA, PEER PRESSURE, IT'S A POWERFUL THING!

But there is more going on here than just mere "slight of
forked tongue" my friends, because, even the most
accomplished propagandist cannot fool *most* of the people.
No, this type of "powerful propaganda" only succeeds when
the subject matter is both cryptic *AND* esoteric.

For instance, in the following example, i contrive a
similarly ironic statement to showcase the effects of such
propaganda, but one that covers a subject matter in which
laymen either: already understand, or, can easily attain
"enough knowledge" to appreciate the humor.

    ############################################################
    #                       Ironic Twist                       #
    ############################################################
    # Some diabetics, when confronted with hunger, think "I    #
    # know, I'll eat a box of sugar cookies." -- now they have #
    # two problems!'                                           #
    ############################################################

    "Wait a minute Rick! After eating the cookies the
    diabetic would not longer be hungry, so how could he
    have two problems? Your logic is flawed!

    Au Contraire! Read the statement carefully, I said:
    "When *CONFRONTED* with hunger" -- the two problems
    (and the eventual side effect) exist at the *MOMENT* the
    diabetic considers eating the cookies.

        PROBLEM1: Need to eat!
        PROBLEM2: Cookies raise glucose too quickly

In this example, even a layman would understand that the
statement is meant to showcase the irony of resolving a
problem (hunger) with a solution (eating a box of cookies)
that results in the undesirable outcome of (hyperglycemia).

And while this statement, and the one about regexps, both
contain a "factual underlying truth" (basically that
negative side effects should be avoided) the layman will
lack the esoteric knowledge of regexps to confirm the
factual basis for himself, and will instead blindly adopt
the propagandist assertion as truth, based solely on the
humorous prowess of the propagandist.

The most effective propaganda utilizes the sub-conscience.
You see, the role of propaganda is to "modify behavior", and
it is a more prevalent and powerful tool than most people
realize! The propagandist will seek to control you; he'll
use your ignorance against you; but you didn't notice
because he made you laugh!

    WHO'S LAUGHING NOW? -- YOU MINDLESS ROBOTS!

    "But what's so evil about that Rick? He scared away a
    few feeble minded folks. SO WHAT!

I argue that we are all "feeble minded" in any subject we
have not yet mastered. His propaganda (be it intentional or
not) is so powerful that it defeats the neophyte before they
can even begin. Because it gives them the false impression
that regexps are only used by foolish people.

Yes, i'll admit, regexps are very cryptic, but once you
grasp their intricacies, you appreciate the succinctness of
there syntax, because, what makes them so powerful is not
only the extents of their pattern matching abilities, but
their conciseness.

[toc] | [prev] | [next] | [standalone]

#83649

On Tue, Jan 13, 2015 at 10:47 AM, Rick Johnson
<rantingrickjohnson@gmail.com> wrote:
>     WHO'S LAUGHING NOW? -- YOU MINDLESS ROBOTS!

It's very satisfying when mindless robots laugh.

ChrisA

[toc] | [prev] | [next] | [standalone]

#83650

On 12/01/2015 23:47, Rick Johnson wrote:
>> 'Some people, when confronted with a problem, think "I
>> know, I'll use regular expressions." Now they have two
>> problems.' -  Jamie Zawinski.
>

[normal cobblers snipped]

If you wish to use a hydrogen bomb instead of a tooth pick feel free, I 
won't lose any sleep over it.  Meanwhile I'll get on with writing code, 
and for the simple jobs that can be completed with string methods I'll 
carry on using them.  When that gets too complicated I'll reach for the 
regex manual, knowing full well that there's enough data in books and 
online to help even a novice such as myself get over all the hurdles. 
If that isn't good enough then maybe a full blown parser, such as the 
pile listed here http://nedbatchelder.com/text/python-parsers.html ?

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

[toc] | [prev] | [next] | [standalone]

#83654

On Monday, January 12, 2015 at 7:55:32 PM UTC-6, Mark Lawrence wrote:
> On 12/01/2015 23:47, Rick Johnson wrote:
> >> 'Some people, when confronted with a problem, think "I
> >> know, I'll use regular expressions." Now they have two
> >> problems.' -  Jamie Zawinski.
> >
>
> [snip]
>
> If you wish to use a hydrogen bomb instead of a tooth pick
> feel free, I won't lose any sleep over it.  Meanwhile I'll
> get on with writing code, and for the simple jobs that can
> be completed with string methods I'll carry on using them.
> When that gets too complicated I'll reach for the regex
> manual, knowing full well that there's enough data in
> books and online to help even a novice such as myself get
> over all the hurdles. If that isn't good enough then maybe
> a full blown parser, such as the pile listed here [snip]

Mark, if you're going to quote me, then at least quote me in
a manner that does not confuse the content of my post. The
snippet you posted was not a statement of mine, rather, it
was a quote that i was responding to, and without any
context of my response, what is the point of quoting
anything at all? It would be better to quote nothing and
just say @Rick, then to quote something which does not have
any context.

Every python programmer worth his *SALT* should master the
following three text processing capabilities of Python, and
he should know how and when to apply them (for they all have
strengths and weaknesses):

    (1) String methods: Simplistic API, but with limited
        capabilities -- but never underestimate the
        possibilities!

    (2) Regexps: Great for pattern matching with a powerful
        and concise syntax, but highly cryptic and unintuitive
        for the neophyte (and sometimes even the guru! *wink*).

    (3) Parsers: Great for extracting deeper meaning from text,
        but if pattern matching is all you need, then why not
        use (1) or (2) -- are you scared or uninformed?

    "We can easily forgive a child who is afraid of the
    dark; the real tragedy of life is when men are afraid of
    the light. -- Plato

IMHO, if you seek to only match patterns, then string
methods should be your first choice, however, if the pattern
is too difficult for string methods, then graduate to
regexps. If you need to extract deeper meaning from
text, by all means utilize a parser.

But above all, don't fall for these "religious teachings"
about how regexps are too difficult for mortals -- that's
just hysteria. If you follow the outline i provided above,
you should find Python's "text processing Nirvana".

[toc] | [prev] | [next] | [standalone]

#83662

On 13/01/2015 02:53, Rick Johnson wrote:
> On Monday, January 12, 2015 at 7:55:32 PM UTC-6, Mark Lawrence wrote:
>> On 12/01/2015 23:47, Rick Johnson wrote:
>>>> 'Some people, when confronted with a problem, think "I
>>>> know, I'll use regular expressions." Now they have two
>>>> problems.' -  Jamie Zawinski.
>>>
>>
>> [snip]
>>
>> If you wish to use a hydrogen bomb instead of a tooth pick
>> feel free, I won't lose any sleep over it.  Meanwhile I'll
>> get on with writing code, and for the simple jobs that can
>> be completed with string methods I'll carry on using them.
>> When that gets too complicated I'll reach for the regex
>> manual, knowing full well that there's enough data in
>> books and online to help even a novice such as myself get
>> over all the hurdles. If that isn't good enough then maybe
>> a full blown parser, such as the pile listed here [snip]
>
> Mark, if you're going to quote me, then at least quote me in
> a manner that does not confuse the content of my post. The
> snippet you posted was not a statement of mine, rather, it
> was a quote that i was responding to, and without any
> context of my response, what is the point of quoting
> anything at all? It would be better to quote nothing and
> just say @Rick, then to quote something which does not have
> any context.

You snipped the bit that says [normal cobblers snipped].

>
> Every python programmer worth his *SALT* should master the
> following three text processing capabilities of Python, and
> he should know how and when to apply them (for they all have
> strengths and weaknesses):
>
>      (1) String methods: Simplistic API, but with limited
>          capabilities -- but never underestimate the
>          possibilities!
>
>      (2) Regexps: Great for pattern matching with a powerful
>          and concise syntax, but highly cryptic and unintuitive
>          for the neophyte (and sometimes even the guru! *wink*).
>
>      (3) Parsers: Great for extracting deeper meaning from text,
>          but if pattern matching is all you need, then why not
>          use (1) or (2) -- are you scared or uninformed?
>

String methods, regexes, parsers, isn't that what I've already said 
above?  Why repeat it?

>      "We can easily forgive a child who is afraid of the
>      dark; the real tragedy of life is when men are afraid of
>      the light. -- Plato
>
> IMHO, if you seek to only match patterns, then string
> methods should be your first choice, however, if the pattern
> is too difficult for string methods, then graduate to
> regexps. If you need to extract deeper meaning from
> text, by all means utilize a parser.
>

I feel humbled that a great such as yourself is again repeating what 
I've already said.

> But above all, don't fall for these "religious teachings"
> about how regexps are too difficult for mortals -- that's
> just hysteria. If you follow the outline i provided above,
> you should find Python's "text processing Nirvana".
>

My favourite things in programming all go along the lines of DRY and 
KISS, with "Although practicality beats purity" being the most important 
of the lot.  So called "religious teachings" never enter into my way of 
doing things.  For example I can't stand code which jumps through hoops 
to avoid using GOTO, whereas nothing is cleaner than (say) GOTO ERROR. 
You'll (plural) find loads of them in cPython.

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

[toc] | [prev] | [next] | [standalone]

#83701

On Monday, January 12, 2015 at 11:34:57 PM UTC-6, Mark Lawrence wrote:
> You snipped the bit that says [normal cobblers snipped].

Oh my, where are my *manners* today? Tell you what, next time when
your sneaking up behind me with a knife in hand, do be a
friend and tap me on the shoulder first, so i can take the
knife and stab *myself* in the back!

Your pal, Rick.

[toc] | [prev] | [next] | [standalone]

#83720

Le mardi 13 janvier 2015 03:53:43 UTC+1, Rick Johnson a écrit :
> 
> [...]
> you should find Python's "text processing Nirvana"
> [...]


I recommend, you write a "small" application sorting
strings composed of latin characters, a sort based on
diacritical characters (and eventually, taking into
account linguistic specific aspects).
And, why not? compare Py3.2 and Py3.3+ !

jmf

[toc] | [prev] | [next] | [standalone]

#83748

wxjmfauth@gmail.com wrote:

> Le mardi 13 janvier 2015 03:53:43 UTC+1, Rick Johnson a écrit :
>> [...]
>> you should find Python's "text processing Nirvana"
>> [...]
> 
> I recommend, you write a "small" application

I recommend you get a real name and do not post using the troll and spam-
infested Google Groups, but a newsreader instead.

> sorting strings composed of latin characters, a sort based on
> diacritical characters

I do not think you need regular expressions for that: you can use Unicode 
collations.

> (and eventually, taking into account linguistic specific aspects).

BTDT.  For a translator application, I used Python to sort a dictionary of 
the Latin phonetic transcription of Golic Vulcan whose alphabet is “S T P K 
R L A Sh O U D V Kh E H G Ch I N Zh M Y F Z Th W B” [1].  re helped a lot 
with that because inversely sorting the list by character length and turning 
it into an alternation allowed me to easily find the characters in words, 
and assign numbers to the letters so that I could sort the words according 
to this alphabet.  If anyone is interested, I can post the relevant code.

> And, why not? compare Py3.2 and Py3.3+ !

What are you getting at?

[1] <http://home.comcast.net/~markg61/vlif.htm>

-- 
PointedEars

Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#83760

On Wed, 14 Jan 2015 14:02:27 +0100, Thomas 'PointedEars' Lahn wrote:

> wxjmfauth@gmail.com wrote:
> 
>> Le mardi 13 janvier 2015 03:53:43 UTC+1, Rick Johnson a écrit :
>>> [...]
>>> you should find Python's "text processing Nirvana"
>>> [...]
>> 
>> I recommend, you write a "small" application
> 
> I recommend you get a real name and do not post using the troll and
> spam- infested Google Groups, but a newsreader instead.
> 
>> sorting strings composed of latin characters, a sort based on
>> diacritical characters
> 
> I do not think you need regular expressions for that: you can use
> Unicode collations.
> 
>> (and eventually, taking into account linguistic specific aspects).
> 
> BTDT.  For a translator application, I used Python to sort a dictionary
> of the Latin phonetic transcription of Golic Vulcan whose alphabet is “S
> T P K R L A Sh O U D V Kh E H G Ch I N Zh M Y F Z Th W B” [1].  re
> helped a lot with that because inversely sorting the list by character
> length and turning it into an alternation allowed me to easily find the
> characters in words, and assign numbers to the letters so that I could
> sort the words according to this alphabet.  If anyone is interested, I
> can post the relevant code.
> 
>> And, why not? compare Py3.2 and Py3.3+ !
> 
> What are you getting at?
> 
> [1] <http://home.comcast.net/~markg61/vlif.htm>

Do not wast you/our time with JMF
he is a resident troll but unlike some of our resident trolls I don't 
think he has ever contributed anything useful 



-- 
An actor's a guy who if you ain't talkin' about him, ain't listening.
		-- Marlon Brando

[toc] | [prev] | [next] | [standalone]

#83774

Le mercredi 14 janvier 2015 16:12:09 UTC+1, alister a écrit :
> On Wed, 14 Jan 2015 14:02:27 +0100, Thomas 'PointedEars' Lahn wrote:
> 
> > wxjmfauth@gmail.com wrote:
> > 
> >> Le mardi 13 janvier 2015 03:53:43 UTC+1, Rick Johnson a écrit :
> >>> [...]
> >>> you should find Python's "text processing Nirvana"
> >>> [...]
> >> 
> >> I recommend, you write a "small" application
> > 
> > I recommend you get a real name and do not post using the troll and
> > spam- infested Google Groups, but a newsreader instead.
> > 
> >> sorting strings composed of latin characters, a sort based on
> >> diacritical characters
> > 
> > I do not think you need regular expressions for that: you can use
> > Unicode collations.
> > 
> >> (and eventually, taking into account linguistic specific aspects).
> > 
> > BTDT.  For a translator application, I used Python to sort a dictionary
> > of the Latin phonetic transcription of Golic Vulcan whose alphabet is "S
> > T P K R L A Sh O U D V Kh E H G Ch I N Zh M Y F Z Th W B" [1].  re
> > helped a lot with that because inversely sorting the list by character
> > length and turning it into an alternation allowed me to easily find the
> > characters in words, and assign numbers to the letters so that I could
> > sort the words according to this alphabet.  If anyone is interested, I
> > can post the relevant code.
> > 
> >> And, why not? compare Py3.2 and Py3.3+ !
> > 
> > What are you getting at?
> > 
> > [1] <http://home.comcast.net/~markg61/vlif.htm>
> 
> Do not wast you/our time with JMF
> he is a resident troll but unlike some of our resident trolls I don't 
> think he has ever contributed anything useful 
> 
> 
> 
> -- 
> An actor's a guy who if you ain't talkin' about him, ain't listening.
> 		-- Marlon Brando

Did you do it? I did.
That's the whole difference.

jmf

[toc] | [prev] | [next] | [standalone]

#83783

Thomas 'PointedEars' Lahn wrote:

> wxjmfauth@gmail.com wrote:
[...]
>> And, why not? compare Py3.2 and Py3.3+ !
> 
> What are you getting at?


Don't waste your time with JMF. He is obsessed with a trivial performance
regression in Python 3.3. Unicode strings can be slightly more expensive to
create in Python 3.3 compared to earlier versions, due to a clever memory
optimization which saves up to 50% if your strings are all in the Basic
Multilingual Plane and up to 75% if they are all in Latin-1. Never mind
that for real-world code, that memory saving can often lead to applications
running faster, JMF is obsessed with an artificial benchmark of his own
devising that involves making, and throwing away, thousands of Unicode
strings as fast as possible in such a way as to exercise the worst-case of
the new Unicode model. From this unimportant performance regression, he has
convinced himself that this means that Python 3.3 and beyond is logically
and mathematically in violation of the Unicode standard.

Any time JMF mentions anything to do with Python versions or Unicode or
ASCII or French, he is in full-blown "pi equals 3 exactly" crank territory
and is best ignored.



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#83798

Le jeudi 15 janvier 2015 01:33:37 UTC+1, Steven D'Aprano a écrit :
> Thomas 'PointedEars' Lahn wrote:
> 
> > wxjmfauth@gmail.com wrote:
> [...]
> >> And, why not? compare Py3.2 and Py3.3+ !
> > 
> > What are you getting at?
> 
> 
> Don't waste your time with JMF. He is obsessed with a trivial performance
> regression in Python 3.3. Unicode strings can be slightly more expensive to
> create in Python 3.3 compared to earlier versions, due to a clever memory
> optimization which saves up to 50% if your strings are all in the Basic
> Multilingual Plane and up to 75% if they are all in Latin-1. Never mind
> that for real-world code, that memory saving can often lead to applications
> running faster, JMF is obsessed with an artificial benchmark of his own
> devising that involves making, and throwing away, thousands of Unicode
> strings as fast as possible in such a way as to exercise the worst-case of
> the new Unicode model. From this unimportant performance regression, he has
> convinced himself that this means that Python 3.3 and beyond is logically
> and mathematically in violation of the Unicode standard.
> 
> Any time JMF mentions anything to do with Python versions or Unicode or
> ASCII or French, he is in full-blown "pi equals 3 exactly" crank territory
> and is best ignored.
> 
> 

It is not only a question of performance [*].
This kind of work is an *illustration" of a bad
design.
Unicode implementation in Python 3 is a shame,
and this brave devs are pretending to write a
serious tool? Let's be a little be serious.

What can I do against a guy who has already
invented the automatic coercion between ASCII
and Unicode. Nothing! Python3 is working in the
same spirit.

[*] on top of this, it is expectedly buggy.

For your information, I also wrote a (completely
dirty) unicode plain text editor, based on the
same widget used in TeXWorks. And I can tell
you, I'm not blind. It works very well with
Python 32  (it covers the whole unicode range).

Rembember: use a sheet of paper and a pencil
and a little bit less an editor.

jmf

[toc] | [prev] | [next] | [standalone]

#83801

About parser.

>>> 9999and 0
0
>>> 

Maybe it's time for the misc. colorizing tools and other
systax analyzing tools to work coherently.

[toc] | [prev] | [next] | [standalone]

#83820

Le jeudi 15 janvier 2015 01:33:37 UTC+1, Steven D'Aprano a écrit :
> Thomas 'PointedEars' Lahn wrote:
> 
> > wxjmfauth@gmail.com wrote:
> [...]
> >> And, why not? compare Py3.2 and Py3.3+ !
> > 
> > What are you getting at?
> 
> 
> Don't waste your time with JMF. He is obsessed with a trivial performance
> regression in Python 3.3. Unicode strings can be slightly more expensive to
> create in Python 3.3 compared to earlier versions, due to a clever memory
> optimization which saves up to 50% if your strings are all in the Basic
> Multilingual Plane and up to 75% if they are all in Latin-1. Never mind
> that for real-world code, that memory saving can often lead to applications
> running faster, JMF is obsessed with an artificial benchmark of his own
> devising that involves making, and throwing away, thousands of Unicode
> strings as fast as possible in such a way as to exercise the worst-case of
> the new Unicode model. From this unimportant performance regression, he has
> convinced himself that this means that Python 3.3 and beyond is logically
> and mathematically in violation of the Unicode standard.
> 
> Any time JMF mentions anything to do with Python versions or Unicode or
> ASCII or French, he is in full-blown "pi equals 3 exactly" crank territory
> and is best ignored.
> 
> 
> 

Out of curiosity. Did you you try the exercise I proposed?

jmf

[toc] | [prev] | [next] | [standalone]

#83667

On Mon, 12 Jan 2015 15:47:08 -0800, Rick Johnson wrote:

>> 'Some people, when confronted with a problem, think "I know, I'll use
>> regular expressions." Now they have two problems.' -  Jamie Zawinski.
> 
> I wonder if Jamie's conclusions are a result of careful study, or
> merely, an attempt to resolve his own cognitive dissonance? 

Zawinski is one of the pantheon of geek demi-gods, with Linus, Larry, 
Guido, RMS, and a few others. (Just don't ask me to rank them. I'm not 
qualified.) His comment isn't based on a failure to grok regular 
expressions, but on an understanding that many people use regular 
expressions inappropriately.

Here is more on the context of the famous quote:

http://regex.info/blog/2006-09-15/247


(By the way, the quote actually wasn't original to JZ, he stole it from 
an all but identical quote about awk.)


[...]
> For instance, in the following example, i contrive a similarly ironic
> statement to showcase the effects of such propaganda, but one that
> covers a subject matter in which laymen either: already understand, or,
> can easily attain "enough knowledge" to appreciate the humor.
> 
>     ############################################################ #      
>                     Ironic Twist                       #
>     ############################################################ # Some
>     diabetics, when confronted with hunger, think "I    # # know, I'll
>     eat a box of sugar cookies." -- now they have # # two problems!'    

Not the best of analogies, since there are two forms of diabetes. Those 
with Type 2 diabetes can best manage their illness by avoiding sugar 
cookies. Those with Type 1 should keep a box of sugar cookies (well, 
perhaps glucose lollies are more appropriate) on hand for emergencies.

http://www.betterhealth.vic.gov.au/bhcv2/bhcarticles.nsf/pages/Diabetes_explained?open

In any case, most people with diabetes (or at least those who are still 
alive) are reasonably good at managing their illness and wouldn't make 
the choice you suggest. You have missed the point that people who misuse 
regexes are common in programming circles, while diabetics who eat a box 
of sugar cookies instead of a meal are rare.

To take your analogy to an extreme:

  Some people, when faced with a problem, say "I know, I'll cut 
  my arm off with a pocketknife!" Now they have two problems.

This is not insightful or useful. Except in the most specialised and 
extreme circumstances, such as being trapped in the wilderness with a 
boulder on your arm, nobody would consider this to be good advice. But 
using regexes to validate email addresses or parse HTML? The internet is 
full of people who thought that was a good idea.


[...]
> Yes, i'll admit, regexps are very cryptic, but once you grasp their
> intricacies, you appreciate the succinctness of there syntax, because,
> what makes them so powerful is not only the extents of their pattern
> matching abilities, but their conciseness.

Even Larry Wall says that regexes are too concise and cryptic:

http://perl6.org/archive/doc/design/apo/A05.html



-- 
Steve

[toc] | [prev] | [next] | [standalone]

#83709

On Tuesday, January 13, 2015 at 12:39:55 AM UTC-6, Steven D'Aprano wrote:
> On Mon, 12 Jan 2015 15:47:08 -0800, Rick Johnson wrote:
> [...]
> > [...]
> > ############################################################
> > #                Ironic Twist (Reformatted)                #
> > ############################################################
> > # Some diabetics, when confronted with hunger, think "I    #
> > # know, I'll eat a box of sugar cookies." -- now they have #
> > # # # two problems!'                                       #
> > ############################################################
>
> Not the best of analogies, since there are two forms of
> diabetes. Those with Type 2 diabetes can best manage their
> illness by avoiding sugar cookies. Those with Type 1
> should keep a box of sugar cookies (well, perhaps glucose
> lollies are more appropriate) on hand for emergencies.

You seem to misunderstand the basic distinction between
type1 and type2 diabetes, it's not a mere dichotomy between
hyperglycemia and hypoglycemia that defines a diabetes
diagnosis, NO, Type1 can be simplified as "insulin
deficiency" and Type2 as "insulin resistance" -- with both
resulting in the inability of glucose (aka: fuel) to nourish
the cells.

YOUR ASSESSMENT OF MY ANALOGY IS JUST AS "WEAK".

Both my and Jamie's analogy present an example of the "cruel
irony". The only *DIFFERENCE* is that mine utilizes a
subject matter which requires less study to understand.

One can learn enough about diabetes to draw his own factual
conclusions of my statement from a simple Google search,
however, for regexps, a neophyte would need days, weeks, or
even months of serious study to drawn sensible conclusions
of merit.

> In any case, most people with diabetes (or at least those
> who are still alive) are reasonably good at managing their
> illness and wouldn't make the choice you suggest. You have
> missed the point that people who misuse regexes are common
> in programming circles, while diabetics who eat a box of
> sugar cookies instead of a meal are rare.

I believe you could find many diabetics who've eaten poorly
and suffered from the result -- even died! I'm not missing
the point, you are! 

    HECK, *I'M* THE ONE WHO *DEFINED* THE "POINT".

> To take your analogy to an extreme:
>
>   Some people, when faced with a problem, say "I know, I'll cut
>   my arm off with a pocketknife!" Now they have two problems.
>
> This is not insightful or useful. Except in the most
> specialized and extreme circumstances, such as being
> trapped in the wilderness with a boulder on your arm,
> nobody would consider this to be good advice.

I'm not giving *advice*, i'm merely drawing parallels. I
think your repeated failures to understand me are are a
result of your superficiality. When reading my posts, you
need to learn to: "read between the lines". Many of the
writings i author are implicit philosophical statements,
musings, and/or explorations. For me, everything has deeper
meanings, just begging to be *plundered*!

> But using regexes to validate email addresses or parse
> HTML? The internet is full of people who thought that was
> a good idea.

Again, i did not suggested that people have never done
anything stupid with regexps, on the contrary, this list has
bear witness to many of them. My only intention was to point
out the damaging (albeit interesting) effects of propaganda.

    MY WHOLE POINT IS ABOUT "PROPAGANDA"!
    
    THAT'S IT!

    DO YOU NEED ME TO DRAW YOU A PICTURE?

[toc] | [prev] | [next] | [standalone]

#83715

On Tuesday, January 13, 2015 at 11:09:17 AM UTC-6, Rick Johnson wrote:
> [...]
>     DO YOU NEED ME TO DRAW YOU A PICTURE?

I don't normally do this, but in the interest of education
i feel i must bear the burdens for which all professional
educators like myself are responsible. 

  https://plus.google.com/114883720122692827712/posts/Nxo3rR7TwQS

[toc] | [prev] | [next] | [standalone]

#83656

On Mon, 12 Jan 2015 19:48:18 +0000, Ian wrote:

> My recommendation would be to write a recursive decent parser for your
> files.
> 
> That way will be easier to write,

I know that writing parsers is a solved problem in computer science, and 
that doing so is allegedly one of the more trivial things computer 
scientists are supposed to be able to do, but the learning curve to write 
parsers is if anything even higher than the learning curve to write a 
regex.

I wish that Python made it as easy to use EBNF to write a parser as it 
makes to use a regex :-(

http://en.wikipedia.org/wiki/Extended_Backus–Naur_Form



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#83688

On Tue, 13 Jan 2015 04:36:38 +0000, Steven D'Aprano wrote:

> On Mon, 12 Jan 2015 19:48:18 +0000, Ian wrote:
> 
>> My recommendation would be to write a recursive decent parser for your
>> files.
>> 
>> That way will be easier to write,
> 
> I know that writing parsers is a solved problem in computer science, and
> that doing so is allegedly one of the more trivial things computer
> scientists are supposed to be able to do, but the learning curve to
> write parsers is if anything even higher than the learning curve to
> write a regex.
> 
> I wish that Python made it as easy to use EBNF to write a parser as it
> makes to use a regex :-(
> 
> http://en.wikipedia.org/wiki/Extended_Backus–Naur_Form



I would not say that writing parsers is a solved problem.
there may be solutions for a number of specific cases but many cases 
still cause difficulty, as an example I do not think there is a 100% 
complete parser for English (even native English speakers don't always 
get it)

-- 
Keep the number of passes in a compiler to a minimum.
		-- D. Gries

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.python

csiph-web