function with a state
Xah Lee
value?
something like this:
globe=0;
def myFun():
globe=globe+1
return globe
apparently it can't be done like that. I thought it can probably be
done by prefixing the variable with some package context...
the Python doc is quite stilted. Where in the python doc is a programer
supposed read about how the package/module system in Python works?
(besides the tutorial that touches it)
Patrick Useldinger
> globe=0;
> def myFun():
> globe=globe+1
> return globe
The short answer is to use the global statement:
globe=0
def myFun():
global globe
globe=globe+1
return globe
more elegant is:
globe=0
globe=myfun(globe)
def myFun(var):
return var+1
and still more elegant is using classes and class attributes instead of
global variables.
-pu
and-g...@doxdesk.com
> is it possible in Python to create a function that maintains a
> variable value?
Yes. There's no concept of a 'static' function variable as such, but
there are many other ways to achieve the same thing.
> globe=0;
> def myFun():
> globe=globe+1
> return globe
This would work except that you have to tell it explicitly that you're
working with a global, otherwise Python sees the "globe=" and decides
you want 'globe' be a local variable.
globe= 0
def myFun():
global globe
globe= globe+1
return globe
Alternatively, wrap the value in a mutable type so you don't have to do
an assignment (and can use it in nested scopes):
globe= [ 0 ]
def myFun():
globe[0]+= 1
return globe[0]
A hack you can use to hide statics from code outside the function is to
abuse the fact that default parameters are calcuated at define-time:
def myFun(globe= [ 0 ]):
globe[0]+= 1
return globe[0]
For more complicated cases, it might be better to be explicit and use
objects:
class Counter:
def __init__(self):
self.globe= 0
def count(self):
self.globe+= 1
return self.globe
myFun= Counter().count
--
Andrew Clover
mailto:a...@doxdesk.com
http://www.doxdesk.com/
Kent Johnson
> The short answer is to use the global statement:
>
> globe=0
> def myFun():
> global globe
> globe=globe+1
> return globe
>
> more elegant is:
>
> globe=0
> globe=myfun(globe)
> def myFun(var):
> return var+1
This mystifies me. What is myfun()? What is var intended to be?
Kent
gene...@gmail.com
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/52558
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/66531
http://www.python.org/2.2.3/descrintro.html
(scroll wayyy down)
Reinhold Birkenfeld
> is it possible in Python to create a function that maintains a variable
> value?
>
> something like this:
>
> globe=0;
> def myFun():
> globe=globe+1
> return globe
You could work with function attributes:
def myFun():
try: myFun.globe += 1
except: myFun.globe = 1
return myFun.globe
or with a default function argument:
class Dummy: pass
def myFun(globe=Dummy()):
try: globe.globe += 1
except: globe.globe = 1
return globe.globe
Reinhold
Andrew Koenig
news:1110096425....@o13g2000cwo.googlegroups.com...
> globe=0;
> def myFun():
> globe=globe+1
> return globe
>
> apparently it can't be done like that. I thought it can probably be
> done by prefixing the variable with some package context...
You can do this:
globe=0
def myFun():
global globe
globe=globe+1
return globe
The question you should ask yourself, however, is why you want to do this.
Do you really want to tie your function to a single global variable? Are
you sure you will never need more than one?
For example, the function you've written represents a counter. Are you sure
you will never need more than one such counter?
gene...@gmail.com
not complicated. Read chapter 7 of the nutshell, it's only 10 pages
long. 2.3 and 2.4 didn't introduce any fundamental changes in how
modules work AFAIK
Patrick Useldinger
>> globe=0
>> globe=myfun(globe)
>> def myFun(var):
>> return var+1
>
>
> This mystifies me. What is myfun()? What is var intended to be?
myfun is an error ;-) should be myFun, of course.
var is parameter of function myFun. If you call myFun with variable
globe, all references to var will be replaced by globe inside function
myFun.
-pu
Kent Johnson
Oh. I thought there was some deep magic here that I was missing :-)
You also have to define myFun before you call it...
def myFun(var):
return var+1
globe = 0
...
globe = myFun(globe)
Kent
Mike Meyer
> the Python doc is quite stilted. Where in the python doc is a programer
> supposed read about how the package/module system in Python works?
> (besides the tutorial that touches it)
The python docs at <URL: http://docs.python.org/ref/naming.html > are
perfectly clear. It explains the namespaces used when resolving
variable names, and how to subvert the standard resolution to solve
your problem.
<mike
--
Mike Meyer <m...@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
Stephen Thorne
Or what about just using the function object directly?
def myFun():
myFun.x += 1
return myFun.x
myFun.x = 0
for test in range(10):
assert myFun()+1 == myFun()
assert myFun()*2+3 == myFun()+myFun()
assert range(myFun(), myFun()+9) == [myFun() for x in range(10)]
assert range(myFun()+2, myFun()+11) == [myFun() for x in range(10)]
:))
couldn't-help-feeding-the-troll-ly-y'rs.
Stephen Thorne.
Reinhold Birkenfeld
> or with a default function argument:
>
>
> class Dummy: pass
>
> def myFun(globe=Dummy()):
> try: globe.globe += 1
> except: globe.globe = 1
>
> return globe.globe
A quicker way:
def myFun(globe=[0]):
globe[0] += 1
return globe[0]
Reinhold
Xah Lee
-------
the python doc is stilted. It tried to organized the thing and with a
style around some highbrow inane "computer science" outlook.
i found the little section on global
(http://python.org/doc/2.4/ref/global.html)
and can't make out what shit it is trying to say without having read
and figured out the entire doc of its style and contexts and
definitions. (formalization varies and computing model and jargons mean
different things.)
Python doc writers needs to re-organize and re-style their docs so that
its organization is towards programing, as opposed to how the
implementation works (as in the Lib Reference), or a formalization of
the language spec. (e.g. the fucking semi-joke of "(for language
lawyers)" and BNF and those Runtime "Service" shits.) Its style
needs to shift from highbrowism to pragmatic and exemplary.
I've addressed some of the jargon-riding ills common in industry with
examples from the Python doc, archived here:
http://xahlee.org/Periodic_dosage_dir/t2/xlali_skami_cukta.html
as to the way of its stiltedenss and academicism, which make it hard
for programers to find or apply any info, i'll expound later.
PS just so that there is no misunderstanding: The docs of unix and
Perl, are fucking criminally incompetent. Python docs, although stilted
in a academic way, but nevertheless is solid, and its writers are
educated, and tried best to make it a quality one, albeit sometimes
inevitably showed some masterbation and jargonization. While the unix
and Perl docs, (and essentially all things out of unix, e.g. Apache
docs), are fucking incompetent drivels and in many cases exorbitant
lies, and they semi-present it as humor and want and brainwash people
to take them as norm. In a nutshell, these people are spreading
untruths and indirectly are causing massive harm in the computing
industry. People, we need to stop it. This each of us can do by not
accepting their attitudes or behavior. In online forums, work place,
conventions, conversations etc., raise questions or otherwise voice
your opinion whenever you can.
Sean Blakey
> http://mail.python.org/mailman/listinfo/python-list
>
Have you submitted a patch? I'm curious how you would document "global".
--
Sean Blakey
Saint of Mild Amusement, Evil Genius, Big Geek
Python/Java/C++/C(Unix/Windows/Palm/Web) developer
quine = ['print "quine =",quine,"; exec(quine[0])"'] ; exec(quine[0])
Steve Holden
> thanks for the help...
>
> -------
> the python doc is stilted. It tried to organized the thing and with a
> style around some highbrow inane "computer science" outlook.
>
<sarcasm>And your writing is so lucid and comprehensible, it's a pity
you can't simply rewrite the documentation so the rest of the world can
understand it.</sarcasm>
While the Python documentation does, of course, have its shortcomings,
you will not improve it by indulging in this kind of nonsense, which
appears to have become some kind of reflex. Your apparent assumption
that your idiotic behavior will make any difference to anything or
anybody is arrogant beyond belief. This is a real pity, as your web site
makes it apparent that in matters where you possess genuine knowledge
you can produce worthwhile work.
Please abandon any notion that your own writings are in any way superior
to the object of your complaints. At least I can learn Python from the
documentation. From you I can learn nothing, you are so self-absorbed
that it would take a pneumatic drill to penetrate that thick skull.
regards
Steve
PS: There is no "e" in masturbation, as any properly-qualified wanker
should know.
Xah Lee
> return var+1
>globe = 0
this is intriguing. How does it work?
not a rhetorical question, but where in the python doc can i read about
it?
thanks.
Peter Hansen
>>def myFun(var):
>> return var+1
>>globe = 0
>>globe = myFun(globe)
>
> this is intriguing. How does it work?
> not a rhetorical question, but where in the python doc can i read about
> it?
The tutorial, presumably, since there is nothing here
that isn't covered by the most basic aspects of Python.
Really, what did you think was there that was so
intriguing? A function is defined. It takes a
parameter and returns its value plus one. A
variable is created with the value 0. The
function is called, passing the value of the
variable, and the return value (remember, the
function just adds one!) is assigned to the
variable. Now "globe" equals 1.
Again, what aspect of this startled you?
-Peter
Xah Lee
Xah
Dan Bishop
> Xah Lee <x...@xahlee.org> wrote:
>
> > is it possible in Python to create a function that maintains a
> > variable value?
>
> Yes. There's no concept of a 'static' function variable as such, but
> there are many other ways to achieve the same thing.
>
> > globe=0;
> > def myFun():
> > globe=globe+1
> > return globe
>
>
> For more complicated cases, it might be better to be explicit and use
> objects:
>
> class Counter:
> def __init__(self):
> self.globe= 0
> def count(self):
> self.globe+= 1
> return self.globe
>
> myFun= Counter().count
You can also use generators.
>>> def myGenerator():
... var = 0
... while True:
... var += 1
... yield var
...
>>> myFun = myGenerator().next
>>> myFun()
1
>>> myFun()
2
>>> myFun()
3
>>> myFun()
4
Patrick Useldinger
understand Software industry in general? Smart...
Xah Lee
tech writing quality.
I think i'll just post snippets of my comments as i find them. (and
feel like exposing)
Python doc:
http://python.org/doc/2.4/lib/comparisons.html
Quote:
Comparison operations are supported by all objects. They all have the
same priority (which is higher than that of the Boolean operations).
Comparisons can be chained arbitrarily; for example, x < y <= z is
equivalent to x < y and y <= z, except that y is evaluated only once
(but in both cases z is not evaluated at all when x < y is found to be
false).
--
Problem: “Comparison operations are supported by all objects.”
This is very vague and ambiguous.
The word “object” has generic English meaning as well might have
very technical meaning in a language. In Python, it does not have very
pronounced technical meaning. For example, there's a chapter in Python
Library Ref titled “2. Built-In Objects”, and under it a section
“2.1 Built-in Functions”. Apparently, functions can't possibly be
meant as a “object” for comparisons.
Now suppose we take the object in the sentence to be sensible items as
numbers, lists etc. The clause “supported by all objects” is
ambiguous. What is meant by “supported”?
--
Problem: They all have the same priority (which is higher than that of
the Boolean operations).
This sentence is very stupid, in multitude of aspects.
The “priority” referred to here means operator precedence.
It tries to say that the comparison operator has higher syntactical
connectivity than boolean operators. E.g. “False and False==False”
means “False and (False==False)” and not “(False and
False)==False”.
However, the “they” pronoun from the context of previous sentence,
refers to “the comparison operation”, not “operator”. So, it
conjures the reader to think about some “operation precedence”,
which in itself cannot be ruled out as nonsense depending on the
context. Very fucking stupid confusional writing.
And, from pure writing aspect, the sentence “...(which is ...)” is
some kind of a juvenile latch on. If the author intent to make that
point, say it in its own sentence. e.g. The comparison operators have
higher precedence than boolean operators. It would be better to not
mention this at all. For practical considerations, very rare is the
case of mixing boolean and comparison operators, and if so, parenthesis
are likely used and is indeed a good practice. The proper place for
operator precedence is a table list all such, giving a clear view, and
in some appendix of language spec.
--
Problem: Comparisons can be chained arbitrarily; for example, x < y <=
z is equivalent to x < y and y <= z, except that y is evaluated only
once (but in both cases z is not evaluated at all when x < y is found
to be false).
Drop the word “arbitrarily”. It has no meaning here.
the whole sentence is one fucked up verbiage of pell-mell thinking and
writing. Here's one example of better:
Comparisons can be chained, and is evaluated from left to right. For
example, x < y <= z is equivalent to (x < y) <= z.
With respect to documentation style, it is questionable that this
aspect needs to be mentioned at all. In practice, if programers need to
chain comparisons, they will readily do so. This is not out of ordinary
in imperative languages, and evaluation from left to right is also not
extraordinary to cost a mention.
--
Problem: <> and != are alternate spellings for the same operator. != is
the preferred spelling; <> is obsolescent
Very bad choice of term “spellings” -- not a standard usage for
computer language operators.
Better: “!=” can also be written as “<>”.
If “<>” is not likely to go out in future versions, don't even
mention about “preference”, because it has no effective meaning.
(if one wants to wax philosophical about “programing esthetics”, go
nag it outside of language documentation.)
In general, when something is obsolete or might go defunct in the
future, consider not even mentioning that construct. If necessary, add
it in a obscure place, and not adjacent to critical info. In many
places of Python documentation, this is breached.
--
This is just a quick partial analysis of one episode of incompetence i
see in Python docs in the past months i've had the pleasure to scan
here and there. A extreme pain in the ass.
I'm in fact somewhat surprised by this poor quality in writing. The
more egregious error is the hardware-oriented organization aka
technical drivel. But that i accept as common in imperative language
communities and in general the computing industry. But the poor quality
in the effectiveness and clarity of the writing itself surprised me. As
exhibited above, the writing is typical of programers, filled with
latch on sentences and unclear thinking. (they in general don't have a
clear picture of what they are talking about, and in cases they do,
they don't have the writing skills to express it effectively. (just as
a footnote: this writing problem isn't entirely the fault of programers
or Python doc writers. In part the English language (or in general
natural languages) are to blame, because they are exceptionally
illogical and really take years to master as a art by itself.))
The Python doc, though relatively incompetent, but the author have
tried the best. This is in contrast to documentations in unix related
things (unix tools, perl, apache, and so on etc), where the writers
have absolutely no sense of clear writing, and in most cases don't give
a damn and delight in drivel thinking of it as literary. A criminal of
this sort that does society huge damage is Larry Wall and the likes of
his cohorts in the unix community. (disclaimer: this is a piece of
opinion.)
addendum: quality writing takes time. Though, the critical part lies
not in the mastery of writing itself, but in clarity of thinking of
what exactly one wants to say. So, next time you are writing a tech
doc, first try to have a precise understanding of the object, and then
know exactly what is that you want to say about it, then the writing
will come out vastly better. If the precise understanding of the object
is not readily at hand (which is common and does not indicate
incompetence), being aware of it helps greatly in its exposition.
This and past critics on Python documentation and IT doc in general is
archived at
http://xahlee.org/Periodic_dosage_dir/t2/xlali_skami_cukta.html
Xah
x...@xahlee.org
∑ http://xahlee.org/PageTwo_dir/more.html
John Bokma
> The Python doc is relatively lousy, from content organization to the
> tech writing quality.
So write your own or fork the current one. I doubt if that's a problem.
Did you read Dive into Python?
--
John Small Perl scripts: http://johnbokma.com/perl/
Perl programmer available: http://castleamber.com/
Happy Customers: http://castleamber.com/testimonials.html
Martin Ambuhl
> The Python doc is relatively lousy, from content organization to the
> tech writing quality.
>
> I think i'll just post snippets of my comments as i find them. (and
> feel like exposing)
The cross-posting idiot is back. Next he'll be posting his readings
from Richard Burton's _Arabian Nights_.
Xah, for you to think that Python is topical in the newsgroups to which
you posted, you must be sharing Karl Malbrain's cell at the loony bin.
Apologies to these various newsgroups, but I have no idea which one Xah
Lee actually reads or posts from. F'ups set.
Paul L. Du Bois
> I think i'll just post snippets of my comments as i find them. (and
> feel like exposing)
That is a very good analysis. Can you submit a documentation patch? I
would, but I'm too lazy to contribute. That doesn't mean I'm not
thankful for your efforts, though!
p
Michael Spencer
> Xah Lee wrote:
>
>
>
> That is a very good analysis. Can you submit a documentation patch? I
> would, but I'm too lazy to contribute. That doesn't mean I'm not
> thankful for your efforts, though!
>
> p
>
Michael
John Bokma
> Apologies to these various newsgroups, but I have no idea which one Xah
> Lee actually reads or posts from. F'ups set.
Probably none, since they are all crowded with crazy linux zealots :-D.
Terry Reedy
>example, x < y <= z is equivalent to (x < y) <= z.
The proposed 'correction' above is incorrect and should be ignored.
>>> x,y,z = 2,3,1
>>> x<y<=z
0
>>> (x<y)<=z
1
Terry J. Reedy
Erik Max Francis
> Very fucking stupid confusional writing.
I agree. Oh, were you talking about the Python documentation?
--
Erik Max Francis && m...@alcyone.com && http://www.alcyone.com/max/
San Jose, CA, USA && 37 20 N 121 53 W && AIM erikmaxfrancis
Men live by forgetting -- women live on memories.
-- T.S. Eliot
Leif K-Brooks
> The word “object” has generic English meaning as well might have
> very technical meaning in a language. In Python, it does not have very
> pronounced technical meaning. For example, there's a chapter in Python
> Library Ref titled “2. Built-In Objects”, and under it a section
> “2.1 Built-in Functions”. Apparently, functions can't possibly be
> meant as a “object” for comparisons.
Why not?
>>> def foo():
... pass
...
>>> def bar():
... pass
...
>>> foo > bar
False
CBFalconer
Unfortunately once the imbecile has done such a crosspost the only
cure it to immediately PLONK the thread.
--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
Xah Lee
mighty, lissome, and tabby
algorithms it puffs
tim-toady it engulfs
and sways universality
there is a camel, lanky
ugly, petty, ungainly
foolhardy comports
hacking it supports
and toadies eunuch's fancy
Xah
x...@xahlee.org
∑ http://xahlee.org/PageTwo_dir/more.html
Xah Lee
Comparison can be chained, and is equivalent to a sequence of
comparisons with “and” in between. For example, “x<y<=z” is
effectively “(x<y) and (y<=z)”
Xah
x...@xahlee.org
∑ http://xahlee.org/
ax...@white-eagle.invalid.uk
> The Python doc is relatively lousy, from content organization to the
> tech writing quality.
Which has precisely what to do with most of the groups to which you
cross-posted?
> Problem: They all have the same priority (which is higher than that of
> the Boolean operations).
> However, the ?they? pronoun from the context of previous sentence,
> refers to ?the comparison operation?, not ?operator?. So, it
> conjures the reader to think about some ?operation precedence?,
> which in itself cannot be ruled out as nonsense depending on the
> context. Very fucking stupid confusional writing.
The meaning is perfectly plain. By the way did you perhaps mean
'confusing' or 'confused'? I normally regard language flames
otiose but here, since you are trying to correct other people's
writing, fair game.
> And, from pure writing aspect, the sentence ?...(which is ...)? is
> some kind of a juvenile latch on. If the author intent to make that
Do you mean... 'if the author's intent is to make' or 'if the author
intends to'?
> point, say it in its own sentence. e.g. The comparison operators have
> higher precedence than boolean operators. It would be better to not
> mention this at all. For practical considerations, very rare is the
> case of mixing boolean and comparison operators, and if so, parenthesis
> are likely used and is indeed a good practice. The proper place for
Should that not be 'parentheses are likely to be used'?
It is not rare at all. Besides, little asides like this are an ideal
way to reinforce thoughts about operator preference and more helpful
then memorising a table.
> Problem: Comparisons can be chained arbitrarily; for example, x < y <=
> z is equivalent to x < y and y <= z, except that y is evaluated only
> once (but in both cases z is not evaluated at all when x < y is found
> to be false).
> Drop the word ?arbitrarily?. It has no meaning here.
I suggest you look up the meaning of the word.
> the whole sentence is one fucked up verbiage of pell-mell thinking and
> writing. Here's one example of better:
> Comparisons can be chained, and is evaluated from left to right. For
> example, x < y <= z is equivalent to (x < y) <= z.
You mean 'are evaluated'. Your rephrasing is also incomplete since
it doesn't note that z will not be evaulated if x < y is false.
> With respect to documentation style, it is questionable that this
> aspect needs to be mentioned at all. In practice, if programers need to
> chain comparisons, they will readily do so. This is not out of ordinary
> in imperative languages, and evaluation from left to right is also not
> extraordinary to cost a mention.
Really? In a reference manual such matters should be fully specified
regardless of what happens in other languages.
> Problem: <> and != are alternate spellings for the same operator. != is
> the preferred spelling; <> is obsolescent
> In general, when something is obsolete or might go defunct in the
> future, consider not even mentioning that construct. If necessary, add
> it in a obscure place, and not adjacent to critical info. In many
> places of Python documentation, this is breached.
Really? Actually it is very important to mention it in the correct
place in a reference manual. Do you understand the concept of
maintaining old code?
> I'm in fact somewhat surprised by this poor quality in writing. The
Really? The writing in the manual seems simple, straight-forward and
clear to me (knowing no Python). Unlike your writing.
> more egregious error is the hardware-oriented organization aka
> technical drivel.
What on earth does this mean?
> The Python doc, though relatively incompetent, but the author have
> tried the best. This is in contrast to documentations in unix related
> things (unix tools, perl, apache, and so on etc), where the writers
> have absolutely no sense of clear writing, and in most cases don't give
> a damn and delight in drivel thinking of it as literary.
I think that this is an excellent description of your own writing.
Axel
Xah Lee
there is a Python, pithy
mighty, lissome, and tabby
algorithms it puffs
conundrums it snuffs
and cherished by those savvy
there is a camel, kooky
ugly, petty, ungainly
hacking it supports
TIMTOWTDI it sports
and transports DWIM-wit's fancy
Xah
x...@xahlee.org
∑ http://xahlee.org/PageTwo_dir/more.html
Ulrich Hobelmann
>>The Python doc, though relatively incompetent, but the author have
Really, how could those morons even dream of creating a language,
and even writing docs to accompany it??
>>tried the best. This is in contrast to documentations in unix related
>>things (unix tools, perl, apache, and so on etc), where the writers
>>have absolutely no sense of clear writing, and in most cases don't give
>>a damn and delight in drivel thinking of it as literary.
Well, man-pages are at least coherent and precise.
It's not literature, it's technical documentation!
>
> I think that this is an excellent description of your own writing.
:)
To be sure, he's a stupid troll, but I think you shouldn't insult
him for being bad at English. I bet you (or most Western people
anyway) have trouble getting fluent in an Asian language. Imagine
the lingua franca were Chinese, non English...
Keith Thompson
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Andras Malatinszky
These "limericks" just don't work, do they? I mean, the number of
syllables is just way off, and then the rhymes are just plain wrong. By
all means, don't stop trying, but don't quit your day job yet.
Roy Smith
Andras Malatinszky <nob...@dev.null> wrote:
A poetry critic, Andras
In a huff at the tempo, alas!
The meter's too free,
So he's telling Xah Lee,
Nocturnal employment won't last!
Xah Lee
http://python.org/doc/2.4/lib/typesseq-mutable.html
in which contains the documentation of the “sort” method of a list.
Quote:
--------------
.sort([cmp[, key[, reverse]]])
sort the items of s in place
(7), (8), (9), (10)
...
(8)
The sort() method takes optional arguments for controlling the
comparisons.
cmp specifies a custom comparison function of two arguments (list
items) which should return a negative, zero or positive number
depending on whether the first argument is considered smaller than,
equal to, or larger than the second argument: "cmp=lambda x,y:
cmp(x.lower(), y.lower())"
key specifies a function of one argument that is used to extract a
comparison key from each list element: "cmp=str.lower"
reverse is a boolean value. If set to True, then the list elements
are sorted as if each comparison were reversed.
In general, the key and reverse conversion processes are much faster
than specifying an equivalent cmp function. This is because cmp is
called multiple times for each list element while key and reverse
touch each element only once.
Changed in version 2.3: Support for None as an equivalent to omitting
cmp was added.
Changed in version 2.4: Support for key and reverse was added.
------------------
As a piece of documentation, this is a relatively lousy one.
The question Python doc writers need to ask when evaluating this piece
of doc are these:
* can a experienced programer (expert at several languages) who is new
to Python, and also have read the official Python tutorial, can he,
read this doc about ”sort”, and know exactly how to use it with all
the options?
* can this piece of documentation be rewritten fairly easily, so that
the answer to the previous question is a resounding yes?
To me, the answers to the above questions are No and Yes. Here are some
issues with the doc:
* in the paragraph about “Key”, the illustration given is:
“cmp=str.lower”. Shouldn't it be “key=str.lower”?
* This doc lacks examples. One or two examples will help a lot,
especially to less experienced programers. (which comprises the
majority of readers) In particular, it should give a full example of
using the cmp predicate and one with key.
* This doc fails to address what happens when the predicate and the
short cut version conflicts. e.g.
myList.sort(lambda x,y: cmp(x[0], y[0]), lambda x: str(x[0]), False )
* on the whole, the way this doc is written does not give a clear
picture of what exactly is happening (think of mathematics) with sort,
nor the roles of the supplied options, nor how to use them.
Quick remedy: add a examples of using cmp predicate. And a example
using “key” predicate. Add example of Using one of them and with
reverse. (the examples need not to come with much explanations. One
sentence annotation will do. )
Other than that, the way the doc is layed out with a terse table and
run-on footnotes (as appeared in other pages) is not inductive. For a
better improvement, there needs to be overhaul of the organization and
the attitude of the entire doc. The organization needs to be programing
based, as opposed to implementation or computer science based. (in this
regard, one can learn from the Perl folks). As to attitude, the writing
needs to be Python-as-is, as opposed to computer science framework.
I'll might have to give more details in the future, but I've made some
headway in this respect before; peruse:
http://xahlee.org/Periodic_dosage_dir/t2/xlali_skami_cukta.html
Xah
x...@xahlee.org
∑ http://xahlee.org/PageTwo_dir/more.html
☄
Mark McIntyre
<x...@xahlee.org> wrote:
>Python doc “3.6.4 Mutable Sequence Types” at
(whatever)
will you /please/ stop crossposting this python thread to comp.lang.c.
(FUP's set to exclude CLC, please respect this)
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>