[perl-python] Python documentation moronicities (continued)

[Xah Lee]

http://python.org/doc/2.4.1/lib/module-re.html
http://python.org/doc/2.4.1/lib/node114.html

---------
QUOTE
The module defines several functions, constants, and an exception. Some
of the functions are simplified versions of the full featured methods
for compiled regular expressions. Most non-trivial applications always
use the compiled form
UNQUOTE
What does a programer who wants to use regex gets out from this piece
of motherfucking irrevalent drivel?

----------
QUOTE
compile(
pattern[, flags])

Compile a regular expression pattern into a regular expression object,
which can be used for matching using its match() and search() methods,
described below.

The expression's behaviour can be modified by specifying a flags
value. Values can be any of the following variables, combined using
bitwise OR (the | operator).
UNQUOTE
What exactly is it fucking saying?

I wanted to use regex to find & replace on text. I've read in a file.
Trying to reading this fucking doc is a pain in the ass. What are these
"flags"? Do i do

re.compile(r'mypat','M') or
re.compile(r'mypat',M)
or perhaps
re.compile(r'mypat',re.M)

The M isn't a fucking variable. Why does the doc incompetently use that
term?
And what the fuck is it unclearly meant by "OR" operator with the
mother fucking bitwise jargon?

All a person reading regex really wanted is to see how to use a string
pattern and replace it with another. The fucking doc cannot be possibly
fucking worsely written.

Fuck the mother fucking coders in the IT industry.

So, is
re.compile(r'mypat','M')
re.compile(r'mypat','MULTILINE')
equivalent?

and, by that fucking bitwise shit is it meant to say like
re.compile(r'mypat','M'|'U')
?

why cannot this piece of shit writing give a single example of usage?
and motherfucking confusedly organized, with fucking variable terms the
writer don't fucking understand, and meanwhile always trying to sound
big asshole and don't stop at masturbation by mention a regex book and
not hesitate to mention another language Perl. Fucking morons.

for a exposition of IT's fucking stupid docs and their fuckhead coders,
see:
http://xahlee.org/Periodic_dosage_di...ami_cukta.html

a cleaned up account of this post will be appended to the above
exposition.

--------

One final piece of advice here to sober up the fuckheads who are
currently offended and defiant: you want to ask yourself this question:
Can a seasoned programer, who is expert at least 2 languages, who is
also a expert at Perl and knew regex well, and who has also read the
official Python tutorial and has written at least 10 simple python
programs over a span of a month, can such a person, who have not yet
used regex in Python but now wants to use regex in Python and have just
read the doc, must he, resort to many trial and error to see exactly
what the doc is talking about?

But, can this doc be (re-)written effectively and easily so that any
programers needn't do trial'n'error post-reading?

The answer to the questions are resounding yeses, you fucking asses.

paypal me a hundred dollars and i'll rewrite the whole re doc in a few
hours.

Fuck you the standard IT morons. Excuse me for i didn't have time to
write a more coherent and detailed analysis of the stupidities of the
re doc.

Xah
xa*@xahlee.org
∑ http://xahlee.org/PageTwo_dir/more.html ☄

[Xah Lee]

I have now also started to rewrite the re-syntax page. At first i
thought that page needs not to be rewritten, since its about regex and
not really involved with Python. But after another look, that page is
as incompetent as every other page of Python documentation.

The rewritten page is here:
http://xahlee.org/perl-python/python...re-syntax.html

It's not complete, but is a start. The organization is largely taken
care of, except the last few paragraphs. The bottom half on capturing
and extension syntax i haven't started working on. In particular, they
need examples. The “repetitions� section also needs to be examed.

here are few notes on this whole rewriting ordeal.

-------------------

In the doc, examples are often given in Python command line interface
format, e.g.

def f(n): .... return n+1
.... f(1)

2

instead of:

def f(n):
return n+1
print f(1) # returns 2

the clean format should be used because it does not require familiarity
with Python command line, it is more readable, and the code can be
copied and run readily.

A significant portion of Python doc's readers, if not majority, didn't
come to Python as beginning programers, and or one way or another never
used or cared about the Python command line interface.

Suppose a non-Python programer is casually shown a page of Python doc.
She will get much more from the clean example than the version
cluttered with Python Command line interface irrelevancies.

Suppose now we have a experienced professional Python programer. Upon
reading the Python doc, she will also find examples in plain code much
more readable and familiar, than the version plastered with Python
Command line interface irrelevancies.

The only place where the Python command line look-and-feel is
appropriate is in the Python tutorial, and arguably only in the
beginning sections.

-----
Extra point: If the Python command line interface is actually a robust
application, like so-called IDE e.g. Mathematica front-end, then things
are very different. In reality, the Python command line interface is a
fucking toy whose max use is as a simplest calculator and double as a
chanting novelty for standard coding morons. In practice it isn't even
suitable as a trial'n'error pad for real-world programing.

Extra point: do not use the fucking stupid meaningless jargon
“interpreter�. 90% of its use in the doc should be deleted.They
should be replaced with "software", "program", "command line
interface", or "language" or others.

(I dare say that 50% of all uses of the word interpreter in computer
language contexts are inane. Fathering large amounts of
misunderstanding and confusion.)

-----
history of Python are littered all over the doc. e.g.
“Incompatibility note: in the original Python 1.5 release, maxsplit
was ignored. This has been fixed in later releases.�

99% of programers really don't need to give a flying fuck about the
history of a language. Inevitably software including languages change
over time, however conservative one tries to be. So, move all these
changes into a "New and Incompatible changes" page at some appendix of
the lang spec. This way, people who are maintaining older code, can
find their info and in one coherent place. While, the general
programers are not forced to wade thru the details of fuckups or
whatnot of the past in every few paragraphs. (few exceptions can be
made, when the change is a major fuckup that all practicing Python
coders really must be informed regardless whether they maintain old
code.)

------

do not take a attitude like you have to stick to some artificial format
or order or "correctness" in the doc. Remember, the doc's prime goal is
to communicate to programers how a language functions, not how it is
implemented or how technically or computer scientifically speaking.

In writing a language documentation, there is a question of how to
organize it. This is a issue of design, and it takes thinking.

When a doc writer is faced with such a challenge, the easiest route is
a no-brainer by following the way the language is implemented. For
example, the doc will start with “data types� supported by the
language. This no-brainer stupidity is unfortunately how most language
docs are organized by, and the Python doc is one of the worst.

One can see this phenomenon in the official doc of Python's RE module.
For example, it begin with Regex Syntax, then it follows with “Module
contents�, then Regex Objects, then Match Objects. And in each page,
the functions or methods are arranged in a alphabetical order. This is
typical of the no-brainers organization following how the module is
implemented or certain “computer scientific logic�. It has remote
connection to how the module is used to perform a task.

In general, language docs should be organize by the tasks it is
supposed to accomplish, then by each module or function's
functionalities.

For example, the RE module doc, organize it by the purposes of the
module. To begin, we explain in the outset that this module is for the
purpose of search or replacing a string by a pattern. Then, we organize
with purpose and functionalities as guide.

Since Python provides a set of functions and a Object-Oriented set, we
create a page for each set, with a clear indication on how they relates
to the string pattern search/replace task. Since Python returns the
result as a special Object, we again create a section MatchObject and
clearly tells the reader what that page is about in relation to the
task. And, we also put the regex syntax on its own page, but again made
it clear what this page means in relation to the task. And in each
page, we again organize them by the guide of tasks and functionalities.
(for example, not alphabetical or some machinery logic) In this way,
the whole RE module doc is oriented to programing, not how this module
happens to be classified according to some Python idiosyncrasies or
categorization by some forced “computer science� outlook.

The complete rewritten doc is here:
http://xahlee.org/perl-python/python...module-re.html

-----

There were more issues and notes... but this will be it for today.

Xah
xa*@xahlee.org
∑ http://xahlee.org/

[Fredrik Lundh]

Xah Lee wrote:

I have now also started to rewrite the re-syntax page. At first i
thought that page needs not to be rewritten, since its about regex and
not really involved with Python. But after another look, that page is
as incompetent as every other page of Python documentation.

The rewritten page is here:
http://xahlee.org/perl-python/python...re-syntax.html

It's not complete

and it no longer describes how things work. study the inner workings
of the RE engine some more, and try again.

</F>

[alex23]

Xah Lee wrote:

99% of programers really don't need to give a flying fuck about the
history of a language.

Ironically, I'm pretty confident that the same percentage of readers on
this group feel _exactly the same way_ about your 'improvements'.

-alex23

[André Roberge]

alex23 wrote:

Xah Lee wrote:

99% of programers really don't need to give a flying fuck about the
history of a language.

Ironically, I'm pretty confident that the same percentage of readers on
this group feel _exactly the same way_ about your 'improvements'.

-alex23

I take it that when you use the expression "same percentage", you must
mean within a percent or so!
André

[Bryan]

Xah Lee wrote:

Extra point: If the Python command line interface is actually a robust
application, like so-called IDE e.g. Mathematica front-end, then things
are very different. In reality, the Python command line interface is a
fucking toy whose max use is as a simplest calculator and double as a
chanting novelty for standard coding morons. In practice it isn't even
suitable as a trial'n'error pad for real-world programing.

i disagree with this 110%. i write python and jython code everyday at my
company and the python interpreter (or command line interface) is always running
on my computer whether it's from the command prompt, idle, pythonwin, pyshell,
etc.. using the interpreter while you are coding is an invaluable tool and
actually helps speed up software development which is opposite of what was
stated by xah lee. it allows complete freedom to experiment reducing the amount
of bugs that are in the real product. it's also useful to use the pywin modules
and experiment with the win32 api interactively, or use the jython interpreter
and experiment with some java api without any compilation step. i have never
found these interpreters to be anything but very robust and *IT IS SUITABLE* as
trial'n'error pad for real-world programming. the above comment can possible
only be made by someone who doesn't actually use it for real world programming.
bryan

[Steve Holden]

Fredrik Lundh wrote:

Xah Lee wrote:

I have now also started to rewrite the re-syntax page. At first i
thought that page needs not to be rewritten, since its about regex and
not really involved with Python. But after another look, that page is
as incompetent as every other page of Python documentation.

The rewritten page is here:
http://xahlee.org/perl-python/python...re-syntax.html

It's not complete

and it no longer describes how things work. study the inner workings
of the RE engine some more, and try again.

Though I realise I'm not one to gloat about other people's typos, I did
find that "When the LOCALE and UNICODE flags are apples as usual."
really appealed to my imagination. And I thought it was all ones and
zeroes ...

regards
Steve
--
Steve Holden [phone] [phone]
Holden Web LLC http://www.holdenweb.com/
Python Web Programming http://pydish.holdenweb.com/

[Jeff Epler]

To add to what others have said:

* Typos and lack of spell-checking, such as "occurances" vs "occurrences"

* Poor grammar, such as "Other characters that has special meaning
includes:"

* You dropped version-related notes like "New in version 2.4"

* You seem to love the use of <HR>s, while docs.python.org uses them
sparingly

* The category names you created, "Wildcards", "Repetition Qualifiers",
and so forth, don't help me understand regular expressions any better
than the original document

* Your document dropped some basic explanations of how regular
expressions work, without a replacement text:
Regular expressions can be concatenated to form new regular
expressions; if A and B are both regular expressions, then AB is
also a regular expression. In general, if a string p matches A and
another string q matches B, the string pq will match AB. [...] Thus,
complex expressions can easily be constructed from simpler primitive
expressions like the ones described here.
Instead, you start off with one unclear example ("a+" matching
"aaaahh!") and one misleading example (a regular expression that
matches some tiny subset of valid e-mail addresses)

* You write
Characters that have special meanings in regex do not have special
meanings when used inside []. For example, '[b+]' does not mean one
or more b; It just matches 'b' or '+'.
and then go on to explain that backslash still has special meaning; I
see that the original documentation has a similar problem, but this
just goes to show that you aren't improving the accuracy or clarity of
the documentation in most cases, just rewriting it to suit your own
style. Or maybe just as an excuse to write offensive things like "[a]
fucking toy whose max use is as a simplest calculator"

I can't see anything to make me recommend this documentation over the
existing documentation.

Jeff

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQFCe8kWJd01MZaTXX0RAoJKAJ9SFnR2FZJ0zEZOyO3HWY EDLVQu4wCfQDz1
EkbIOwiWs/xg0Hn4EzmvVA4=
=Qv6B
-----END PGP SIGNATURE-----

[Xah Lee]

HTML Problems in Python Doc

I don't know what kind of system is used to generate the Python docs,
but it is quite unpleasant to work with manually, as there are
egregious errors and inconsistencies.

For example, on the “Module Contents� page (
http://python.org/doc/2.4.1/lib/node111.html ), the closing tags for
<dd> are never used, and all the tags are in lower case. However, on
the regex syntax page ( http://python.org/doc/2.4.1/lib/re-syntax.html
), the closing tages for <dd> are given, and all tages are in caps.

The doc's first lines declare a type of:
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">

yet in the files they uses "/>" to close image tags, which is a XHTML
syntax.

the doc litters <p> and never closes them, making it a illegal
XML/XHTML by breaking the minimal requirement of well-formedness.

Asides from correctness, the code is quite bloated as in generally true
of generated HTML. For example, it is littered with: <tt id='l2h-853'
xml:id='l2h-853'> which isn't used in the style sheet, and i don't
think those ids can serve any purpose other than in style sheet.

Although the doc uses a huge style sheet and almost every tag comes
with a class or id attribute, but it also profusively uses hard-coded
style tags like <b>, <big> and Netcsape's <nobr>.

It also abuse tables that effectively does nothing. Here's a typical
line:
<table cellpadding="0" cellspacing="0"><tr valign="baseline">
<td><nobr><b><tt id='l2h-851' xml:id='l2h-851'
class="function">compile</tt></b>(</nobr></td>
<td><var>pattern</var><big>[</big><var>,
flags</var><big>]</big><var></var>)</td></tr></table>
If Python is supposed to be a quality language, then its
documentation's content and code seems indicate otherwise.
-----------------------

This email is archived at:
http://xahlee.org/perl-python/re-write_notes.html

Xah
xa*@xahlee.org
∑ http://xahlee.org/
☄

[Xah Lee]

erratum:

the correct URL is:
http://xahlee.org/perl-python/python...module-re.html

Xah
xa*@xahlee.org
∑ http://xahlee.org/

[Skip Montanaro]

Xah> I don't know what kind of system is used to generate the Python
Xah> docs, but it is quite unpleasant to work with manually, as there
Xah> are egregious errors and inconsistencies.

The main Python documentation is written in LaTeX. I believe most, if not
all, HTML is generated by latex2html. I suspect most of the HTML cruftiness
arises from latex2html.

Skip

[Philippe C. Martin]

This is nice! I just might understand regex eventually.
Xah Lee wrote:

erratum:

the correct URL is:
http://xahlee.org/perl-python/python...module-re.html

Xah
xa*@xahlee.org
∑ http://xahlee.org/

[Xah Lee]

Let me expose one another fucking incompetent part of Python doc, in
illustration of the Info Tech industry's masturbation and ignorant
nature.

The official Python doc on regex syntax (
http://python.org/doc/2.4/lib/re-syntax.html ) says:

--begin quote--

"|"
A|B, where A and B can be arbitrary REs, creates a regular expression
that will match either A or B. An arbitrary number of REs can be
separated by the "|" in this way. This can be used inside groups (see
below) as well. As the target string is scanned, REs separated by "|"
are tried from left to right. When one pattern completely matches, that
branch is accepted. This means that once A matches, B will not be
tested further, even if it would produce a longer overall match. In
other words, the "|" operator is never greedy. To match a literal "|",
use \|, or enclose it inside a character class, as in [|].

--end quote--

Note: “In other words, the "|" operator is never greedy.�

Note the need to inject the high-brow jargon “greedy� here as a
latch on sentence.

“never greedy�? What is greedy anyway?

“Greedy�, when used in the context of computing, describes a
certain characteristics of algorithms. When a algorithm for a
minimizing/maximizing problem is such that, whenever it faced a choice
it simply chose the shortest path, without considering whether that
choice actually results in a optimal solution.

The rub is that such stratedgy will often not obtain optimal result in
most problems. If you go from New York to San Francisco and always
choose the road most directly facing your destination, you'll never get
on.

For a algorithm to be greedy, it is implied that it faces choices. In
the case of alternatives in regex "regex1|regex2|regex3", there is
really no selection involved, but following a given sequence.

What the writer were thinking when he latched on about greediness, is
that the result may not be from the pattern that matches the most
substring, therefore it is not “greedy�. It's not greedy Python
docer's ass.

Such blind jargon throwing, as found everywhere in tech docs, is a
significant reason why the computing industry is filled with shams the
likes of unix, Perl, Programing Patterns, eXtreme Programing,
“Universal Modeling Language�, fucking shits.

----
A better writen doc for the complete regex module is at:
http://xahlee.org/perl-python/python...module-re.html

See also: Responsible Software Licensing
http://xahlee.org/UnixResource_dir/w...e_license.html

Xah
xa*@xahlee.org
∑ http://xahlee.org/

[John Bokma]

Xah Lee wrote:

Let me expose one another fucking incompetent part of

your writing capablities?

If you really had a point, there wouldn't be any need of swearing...

--
John MexIT: http://johnbokma.com/mexit/
personal page: http://johnbokma.com/
Experienced programmer available: http://castleamber.com/
Happy Customers: http://castleamber.com/testimonials.html

[Ron Adam]

Xah Lee wrote:

Let me expose one another fu....

Hello Xah,

I think you will continue to have difficulty getting respect on this
matter as long as you show disrespect to those who have come before you.

When you refer to the documentation as being f'ing stupid, and other
disrespectful terms, you are in an indirect, or depending on your
intent, directly insulting the people who have done their best, as
*volunteers* in most cases, to provide the existing documentation.

Text is never F'ing, Stupid, or any of the other terms you refer to as
it being. However it can be uninformative, hard to read, confusing, and
even plain wrong. But it is only text, and does not have a mind of it's
own. Referring to it as if it does, in such angry tones, reflects back
on yourself and gives others a poor impression of you.

At the start, you choose to approach this matter as a personal and
competitive agenda, ie.. You vs those who came before you. Is this
really the correct way to do this? You don't have to insult those who
came before you in order to make your case. If you do, then maybe your
case isn't strong enough. But even this is wrong because it isn't a
competition.

I suppose that if you respectfully offer something even a little better
it would be respectfully accepted, after due review of course. You will
probably even get many helpful suggestions along they way because you
will have created a situation where every one wins.

But by approaching it in the way you are, you make it very hard for
people to support you, because to do so, they have to take on the role
of losers in order for you to be a winner.

Just some thoughts, you might consider.

Cheers, and good luck with whatever aproach you decide.

[Peter Hansen]

Ron Adam rote:

I suppose that if you respectfully offer something even a little better
it would be respectfully accepted, after due review of course. You will
probably even get many helpful suggestions along they way because you
will have created a situation where every one wins.

Remarkably, and because of the special nature of this newsgroup, Ron is
right: "something even a little better" would be respectfully accepted,
in spite of the incredibly anti-social nature of nearly all of Xah' past
postings here.

In the (unlikely, IMHO) event that Xah can change, and wants to submit
something "even a little better", here are a few suggestions:

1. Use a spell checker.

2. Use a grammar checker. Many people can get away without this tool,
but pretty clearly Xah cannot.

3. Realize that posting partial improvements to this newsgroup will not
really help anyone, unless you are explicitly soliciting feedback on the
wording or structure with the intent of submitting the changes via the
proper channels at a later time.

4. Clean up all loose ends, including removing comments of the sort "to
be rewritten later", and "still needs work" and such. Somebody has to
do the work; if you leave it undone, the changes are unlikely to be
accepted.

-Peter

[Mike Meyer]

"Xah Lee" <xa*@xahlee.org> writes:

Let me expose one another fucking incompetent part of Python doc, in
illustration of the Info Tech industry's masturbation and ignorant
nature.
What you actually expose is your own ignorance.
Note: “In other words, the "|" operator is never greedy.�

Note the need to inject the high-brow jargon “greedy� here as a
latch on sentence.
Actually, greedy is a standard term when dealing with regular
expression matching. Anyone who's done even a little work with regular
expressions - which is pretty much all I've done, as I prefer to avoid
them - will know what it means.
“never greedy�? What is greedy anyway?

“Greedy�, when used in the context of computing, describes a
certain characteristics of algorithms. When a algorithm for a
minimizing/maximizing problem is such that, whenever it faced a choice
it simply chose the shortest path, without considering whether that
choice actually results in a optimal solution.

Except that's not the *only* meaning for greedy in a computing
context. That's what it means when you're talking about a specific
kind of problem solving algorithm. Those algorithms have *nothing* to
do with regular expressions, so this definition is irrelevant.

After doing a google for "regular expression greedy", the second match
starts with the text:

By default, pattern matching is greedy, which means that the matcher
returns the longest match possible.

Now, it can be argued that the term ought not to be used, except that
it's a standard term with a well-known meaning, and exactly describes
the behavior in question.

You can argue that it ought to be defined. The problem is, you can't
explain things to a rock. You have to assume some basic level of
understanding. In particular, documentation on a regular expression
package should explain *how to use the package*, not what regular
expressions are, and the terminology associated with them.

As I've suggested before, what's really needed is a short tutorial on
regular expressions in general. That page could include a definition
of terms that are unique to regular expressions, and the re package
documentation could link the word greedy to that definition.

<mike
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

[axel]

In comp.lang.perl.misc Xah Lee <xa*@xahlee.org> wrote:

Let me expose one another fucking incompetent part of Python doc, in
illustration of the Info Tech industry's masturbation and ignorant
nature. Note the need to inject the high-brow jargon “greedy� here as a
latch on sentence. “never greedy�? What is greedy anyway? “Greedy�, when used in the context of computing, describes a

When used in terms of Usenet, I think it can be applied in the sense
of 'a troll who is greedy for attention'.

Hence the saying 'do not feed the troll'.

Axel

[John Bokma]

wrote:

When used in terms of Usenet, I think it can be applied in the sense
of 'a troll who is greedy for attention'.

Hence the saying 'do not feed the troll'.

Unless you can cause a buffer overflow :-D

--
John Small Perl scripts: http://johnbokma.com/perl/
Perl programmer available: http://castleamber.com/
Happy Customers: http://castleamber.com/testimonials.html

[Taenia Solium]

"Xah Lee" <xa*@xahlee.org> writes:

HTML Problems in Python Doc

Why dont you write a Mathematica tutorial instead ?

It looks like you know a little about Mathematica while
your knowledge of Python is abyssmal.

[Peter Hansen]

Mike Meyer wrote:

As I've suggested before, what's really needed is a short tutorial on
regular expressions in general. That page could include a definition
of terms that are unique to regular expressions, and the re package
documentation could link the word greedy to that definition.

You mean like http://www.amk.ca/python/howto/regex/ ?

Which as I recall is already linked from the Python re docs. (Perhaps
Xah's browser wasn't working that day...)

And which, at least implicitly, defines "greedy" by in section 6.3
titled "Greedy versus Non-Greedy". It's not perfect, but then nobody in
this thread has offered anything even remotely resembling perfect
documentation for regular expressions yet. <wink>

-Peter

[Skip Montanaro]

Peter> And which, at least implicitly, defines "greedy" by in section
Peter> 6.3 titled "Greedy versus Non-Greedy". It's not perfect, but
Peter> then nobody in this thread has offered anything even remotely
Peter> resembling perfect documentation for regular expressions
Peter> yet. <wink>

In the re syntax page:

http://www.python.org/dev/doc/devel/lib/re-syntax.html

the *?, +? and ?? operators *, + and ? are described as greedy:

*?, +?, ??
The "*", "+", and "?" qualifiers are all greedy; they match as much
text as possible. Sometimes this behaviour isn't desired; if the RE
<.*> is matched against '<H1>title</H1>', it will match the entire
string, and not just '<H1>'. Adding "?" after the qualifier makes it
perform the match in non-greedy or minimal fashion; as few
characters as possible will be matched. Using .*? in the previous
expression will match only '<H1>'.

{m,n}? is also described as a non-greedy version of {m,n} and A|B is
described as never being greedy (if A matches, B is never tried). Perhaps
there's no explicit definition of the word "greedy" in the context of
regular expressions, but I think that after reading that page most people
will at least have an intuitive notion of the meaning. If it's still
unclear, a little experimentation should suffice:

import re
re.match("(a+)", "aaaaa").group(1) 'aaaaa' re.match("(a+?)", "aaaaa").group(1)

'a'

In short, I think the re docs are fine as-is w.r.t. the greedy concept. I
also added a definition to the Python Glossary for good measure:

http://www.python.org/moin/PythonGlossary

Feel free to amend/enhance/correct as you see fit. (Feel free to flesh out
any definitions for that matter, especially those with "???" as the
definition.)

Skip

[Fredrik Lundh]

Mike Meyer wrote:

After doing a google for "regular expression greedy", the second match
starts with the text:

By default, pattern matching is greedy, which means that the matcher
returns the longest match possible.

Now, it can be argued that the term ought not to be used, except that
it's a standard term with a well-known meaning, and exactly describes
the behavior in question.

fwiw, judging from frequently asked questions and bug reports,
people have no problems understanding the phrase "greedy", but
they sometimes have problems understanding why "return the
longest match possible" doesn't always mean "return the overall
longest match possible"

(using the greedy modifier only applies to the given RE operator;
it doesn't modify the behaviour of other operators, or the method
used; e.g. | will still pick the *first* possible match even if one of
the alternatives use a greedy operator, search/find still scans the
target string from left to right, etc).

</F>

[Xah Lee]

> I think you will continue to have

difficulty getting respect on this
matter as long as you show disrespect
to those who have come before you.
...
Dear Ron Adam and other good people,

I respect people and I respect truth. And, the priority is truth first.

The software community, is one fucked up ball, and in part, because
people respect not people nor truth. They respect their own asses,
euphorimically known as politics and power game, and exhibited and
understood as respecting other people.

the above, as you've seen, can be seen in the behaviors and inactions
in this python group as judged by its posts on the Python doc issue i
raised. (of course there are also posts by good hearted and educated
people)

The documentations in computing industry and The Python doc in
particular, is one gravely fucking incompetent ball. And, execuse me
that most people do not understand this, but it is because people
respects their own asses more than other people or truth as i outlined
above.

The fucked up writings and thinkings in the computing industry is in
part what causes the sorry situation of today's software.

I, am taking my time as time permits to explain this situation little
by little to the computing public, message by message.

As to my criticism and rewrite of Python doc in particular, the Python
community can take it or leave it. If they take it, or if i instigated
any change, they shall give proper credit where credit is due.

-----
To the generic Python community:

go re-read my posts, and this time pay attention:
http://xahlee.org/Periodic_dosage_di...ami_cukta.html
http://xahlee.org/perl-python/re-write_notes.html

These writings and my involvement with Python will probably only
increase. It is beneficial for you, either personally or as part of the
Python collective, to behave properly.

Xah
xa*@xahlee.org
∑ http://xahlee.org/

Newsgroups: comp.lang.python
From: Ron Adam <[e-mail]> - Find messages by this author
Date: Sat, 07 May 2005 20:23:35 -0400
Local: Sat,May 7 2005 8:23Â*pm
Subject: Re: New Python regex Doc
Reply | Reply to Author | Forward | Print | Individual Message |
Show original | Report Abuse

Xah Lee wrote: Let me expose one another fu....

Hello Xah,

I think you will continue to have difficulty getting respect on this
matter as long as you show disrespect to those who have come before
you.

When you refer to the documentation as being f'ing stupid, and other
disrespectful terms, you are in an indirect, or depending on your
intent, directly insulting the people who have done their best, as
*volunteers* in most cases, to provide the existing documentation.

Text is never F'ing, Stupid, or any of the other terms you refer to as
it being. Â*However it can be uninformative, hard to read, confusing,
and
even plain wrong. Â*But it is only text, and does not have a mind of
it's
own. Â*Referring to it as if it does, in such angry tones, reflects
back
on yourself and gives others a poor impression of you.

At the start, you choose to approach this matter as a personal and
competitive agenda, ie.. You vs those who came before you. Â*Is this
really the correct way to do this? Â*You don't have to insult those
who
came before you in order to make your case. Â*If you do, then maybe
your
case isn't strong enough. Â*But even this is wrong because it isn't a
competition.

I suppose that if you respectfully offer something even a little better
it would be respectfully accepted, after due review of course. Â*You
will
probably even get many helpful suggestions along they way because you
will have created a situation where every one wins.

But by approaching it in the way you are, you make it very hard for
people to support you, because to do so, they have to take on the role
of losers in order for you to be a winner.

Just some thoughts, you might consider.

Cheers, and good luck with whatever aproach you decide.

[John Bokma]

Xah Lee wrote:

I respect people
and I was convinced he was going to show different:
The software community, is one fucked up ball, and in part, because
just one person sees the light...
people respect not people nor truth. They respect their own asses,
Then you must be the #1 fine example of that same fucked up ball.
raised. (of course there are also posts by good hearted and educated
people)

Like yourself, sure.

If you had really any point, you didn't need to swear in every third
sentence. Nor bother so many groups with your rants.

If you think it can be done better, pick up a part of documentation, and
rewrite it. To make it very hard, you are not allowed to use fuck, fucking,
fucked, ass, asses or other similar words, which in the way you use them
show quite some lack of both creativity and writing skills.

--
John Small Perl scripts: http://johnbokma.com/perl/
Perl programmer available: http://castleamber.com/
Happy Customers: http://castleamber.com/testimonials.html

[axel]

In comp.lang.perl.misc John Bokma <jo**@castleamber.com> wrote:

If you had really any point, you didn't need to swear in every third
sentence. Nor bother so many groups with your rants. If you think it can be done better, pick up a part of documentation, and
rewrite it. To make it very hard, you are not allowed to use fuck, fucking,
fucked, ass, asses or other similar words, which in the way you use them
show quite some lack of both creativity and writing skills.

Oh please let him use an ass... then we might not see him again for
several months nutil his donley comes over the hill.

Axel

[John Bokma]

wrote:

In comp.lang.perl.misc John Bokma <jo**@castleamber.com> wrote:
[ @55, |@#~~|!! ]
Oh please let him use an ass...

Ok, he is allowed to use ass in examples, e.g. (Perl)

s/ass/domesticated donkey/g;

(Maybe to explain \b ? )

--
John Small Perl scripts: http://johnbokma.com/perl/
Perl programmer available: http://castleamber.com/
Happy Customers: http://castleamber.com/testimonials.html