Re: [Tutor] Losing the expressiveness ofC'sfor-sta tement?/RESENDwith example
Stephen,
I've come into this thread late, but it looks like you're lamenting the fact
you can stipulate complex iterations on a single line, which can be nice. I'd
not really missed this in several years of programming with python.
However, Your post is interesting because it raises a point I've personally
not considered before.
Your example loops are:
for (node=start; valuenext) { ... }
for (i=3; i>0; i=i/2) { ... }
The argument you got back is that this is just syntactic sugar for logic
along the lines of:
node=start;
while valuenext
Which of course is true. However simply saying that does miss the fact
that it is syntactic sugar with a purpose. Syntactic sugar is generally added
for one of two reasons - speed of coding, or clarity of coding. In this case
it can be argued it does both, since it spells out the iterator algorithm
clearly on a single line.
Specifically you can look at one line and see the loop logic. This is nowhere
near as clear with this form:
node=start;
while valuenext
And its certainly not on one line.
If you still want to spell out the iteration in one location, then you're
right you do have to use a generator. However the fact that you can put a
def anyway means you can do this:
start = getNodesFromSomewhere()
def traverseNodes(start):
node = start
yield node
while node.next:
node = node.next
yield node
for node in traverseNodes(start):
...
Similarly you can do this:
def bisectdown(i=3):
while i >0:
yield i
i = i/2
for node in bisectdown(3):
...
That said, I agree that its not as nice perhaps as C's compact one liner for
each of these.
HOWEVER, you can rebuild C's version: (or something close)
import compiler
def cfor(iter_name, args,locals):
Y=[x.strip().rstrip() for x in args.split(";")]
Y[0] = compiler.compile(Y[0], "__main__.py", "exec")
Y[1] = compiler.compile(Y[1], "__main__.py", "eval")
Y[2] = compiler.compile(Y[2], "__main__.py", "exec")
Y.append( compiler.compile(iter_name, "__main__.py", "eval"))
exec(Y[0],locals,locals)
while eval(Y[1],locals,locals):
yield eval(Y[3],locals,locals)
exec(Y[2],locals,locals)
You can then use this as follows:
max = 10
for i in cfor("i", "i=3; i>max; i=i/2",locals()):
print i
And also:
start = getNodesFromSomewhere()
for node in cfor("n", "n=start; n.next is not None; n = node.next",
locals()):
...
That's potentially quite useful. Yes there's a little cruft there (locals()),
but its not hideously inefficient either because I've made sure we compile the
code fragments and run those.
Personally I think its not a huge loss, but if you do, then you can always
reuse this cfor iterator if you like.
I disagree though regarding the idea that C's for syntax is a universal
syntax. It isn't. It's a commonly understood syntax due to C derived
languages (C/C++/Java), but far from universal. I've had to learn many
different "for" syntaxes over many years for different languages.
Even then where a C-type loop is availabe, it isn't always idiomatic to use
it. For example perl (which does have a C-type for loop) idiomatically uses
foreach extensively. And you also get *very* different iterative behaviour
in ruby.
Different languages have different concepts. Just because you can write one
language like another doesn't mean you should. That said, given that maxim,
it sounds like your beef with more with docs rather than the lack of the
construct, asking "is this a problem normally", to which the answer is most
definitely not, "what do people normally do", to which you have numerous
replies - people either create an iterator (as you often would in C++ and
Java) or use a while loop.
As for rudeness, bear in mind that text is a naturally harsh medium, and
also cultural norms are very different for different posters. One man's
polite behaviour is another man's gravest insult. No one means to be rude,
so it's worth remembering that. (And yes, I know, merely saying that can
be considered rude in itself in some cultures :-)
You found people rude, they found you rude. None of you intended to be,
and probably weren't from your own perspectives, that's what really matters.
Michael.
___
Tutor maillist - Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Losing the expressiveness ofC'sfor-statement?/RESENDwith example
Thank you for reminding me of that! I've just started with 2.5 but that one had slipped my memory and I've still been using X = (z and [y] or [w])[0] Thank! Jeff -Original Message- From: Kent Johnson [mailto:[EMAIL PROTECTED] Sent: Friday, August 10, 2007 10:23 AM To: Smith, Jeff Cc: tutor@python.org Subject: Re: [Tutor] Losing the expressiveness ofC'sfor-statement?/RESENDwith example Smith, Jeff wrote: > P.S. This should in no way be construed as undercutting my belief that > Python should have a case statement, a ternary operator, and > full-fledged lambdas Python 2.5 does have conditional expressions that do the work of a ternary operator: x = y if z else w http://docs.python.org/whatsnew/pep-308.html Kent ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Losing theexpressiveness ofC'sfor-statement?/RESENDwith example
"Smith, Jeff" <[EMAIL PROTECTED]> wrote > Python should have a case statement, I don;t care about that one, but we do ave the even less useful(IMHO) with statement so don't give up hope! > a ternary operator, Well you have that now in 2.5 I believe. > full-fledged lambdas... I'm with you there but I've been waiting long enough to have given up. In fact I think we are more likely to lose lambdas altogether than see an improved version! Alan G ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Losing theexpressiveness ofC'sfor-statement?/RESENDwith example
On 10/08/07, Alan Gauld <[EMAIL PROTECTED]> wrote: > > full-fledged lambdas... > > I'm with you there but I've been waiting long enough to have > given up. In fact I think we are more likely to lose lambdas > altogether than see an improved version! Guido said he's keeping lambdas in Python 3000, I think pretty much as is http://www.artima.com/weblogs/viewpost.jsp?thread=208549 ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
[Tutor] Installation of Django on Mac Tiger
Hi. I'm not a real programmer/low level Unix guy yet. I realize that this is not a Django forum per se. But, I don't know where else to turn before giving up. Can anyone help me install Django on my Mac? I have tried all sorts of approaches outlnied on various blogs and have Django on my MacBook Pro but I think that I have simply failed to get Python to see the Django module. Thanks, David Handel ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Losing the expressiveness ofC'sfor-statement?/RESENDwith example
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kent Johnson Stephen McInerney wrote: >> The C for-loop syntax itself is not error-prone at all. >> Unless you mean off-by-one errors etc., missing initializations, and >> those are mostly semantic not syntax-related. > Yeah other than that it isn't error-prone at all. This distinction is, unfortunately, lost on most programmers. When there is a bug in the code that needs to be tracked down and resolved, it doesn't really matter much whether it is the fault of the compiler, or the language sytnax which drives a programmer to make mistakes. Quibbling about this doesn't make these errors magically disappear. IMHO, a language being syntactically error prone is far worse since there's no way for the vendor to "fix" that one! Jeff P.S. This should in no way be construed as undercutting my belief that Python should have a case statement, a ternary operator, and full-fledged lambdas...sometimes the risk of syntactic errors is overcome by a construct's logically expressive usefulness...but that's grist for another mill :-) ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Losing the expressiveness ofC'sfor-statement?/RESENDwith example
Stephen McInerney wrote: > Guys, > > I'm annoyed at how far offtopic If you get annoyed at threads drifting off-topic you'd better stay away from all public mailing lists! > and frankly rude the responses to my > email were, Re-reading the entire thread I don't see anything I would construe as rude. I think you need to lighten up a bit. > I didn't get much decent opinion on my central question: > "isn't this idiom more restrictive than C/C++/Java (aka the rest of the > universe), You got considerable disagreement, it seems to me. Most of the posts are either explicitly disagreeing or trying to point you to the Python way of doing things. > Nobody attempted to address the valid > follow-on question about generators returning a tuple (e.g. walking a > pointer, > and incrementing a count, let alone anything more complex) I don't see any question about generators and tuples. Maybe you should start a new thread about that, it's pretty off-topic for this one ;) > - quibbling the motivation for the quicksort example I gave was clearly > offtopic; > I'm very well aware there are better Python implementions, that's > irrelevant; > the motivation was to give a legitimate example which clearly arises > commonly. Wait. You say it is a "legitimate example that occurs commonly" but we are not allowed to talk about other ways to do it? You actually seem to have two items on your agenda - convincing us that for loops in C are more powerful than in Python, and that Python is lacking - changing the docs to reflect this We don't buy the first item so the second one doesn't get much traction. > - This is offtopic, Uh oh! > but the C for-loop syntax is very syntactically > powerful, > so when people perceive Python lacks it, they may baulk at that. We have to > do a better job selling why Python is better. > The C for-loop syntax itself is not error-prone at all. > Unless you mean off-by-one errors etc., missing initializations, and > those are mostly semantic not syntax-related. Yeah other than that it isn't error-prone at all. >> > It's regrettable we have to choose between the clear and the >> > efficient, in this situation. >> >> The most clear and efficient is probably: >> >> myList.sort() > > Alan - this was totally unnecessary and trashes the entire (legitimate) > context of my question. The point is that Python has efficient ways to do many common operations that may be different from the way you expect. Kent ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Simple way to compare Two lists
I think you could use sets, (I asked a similar question a few days ago re numpy arrays). ie Convert both list to sets use Set intersection convert answer to lists HTH Andy Tom Fitzhenry wrote: > On Fri, Aug 10, 2007 at 02:54:44AM -0700, Jaggo wrote: >> Can anyone think of any better way? > > If SmallList and BigList are sorted (in order), there is a faster method: > > def IsAPartOfList(SmallList,BigList): > for i in BigList: > for j in SmallList: > if i==j: > return true > if i>j: > break > return false > > (I'm not sure how encouraged using break statements are, so wait for a tutor > to > answer) > > If one list is already sorted but the other isn't, it may still be faster to > sort the unsorted list then use the method above. > > If neither SmallList or BigList are sorted, it's probably best to use your > original method, which I cannot improve. > ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Simple way to compare Two lists
Tom Fitzhenry wrote: > On Fri, Aug 10, 2007 at 02:54:44AM -0700, Jaggo wrote: >> Can anyone think of any better way? > > If SmallList and BigList are sorted (in order), there is a faster method: > > def IsAPartOfList(SmallList,BigList): > for i in BigList: > for j in SmallList: > if i==j: > return true > if i>j: > break > return false > > (I'm not sure how encouraged using break statements are, so wait for a tutor > to > answer) break is fine! If the list you are searching is sorted you can use the bisect module to do a binary search instead of the linear search above. > If one list is already sorted but the other isn't, it may still be faster to > sort the unsorted list then use the method above. I don't think BigList has to be sorted in the above algorithm. If both lists are sorted I suppose you could write it like a merge sort, walking along both lists looking for a match. Kent ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Simple way to compare Two lists
On Fri, Aug 10, 2007 at 02:54:44AM -0700, Jaggo wrote: > Can anyone think of any better way? If SmallList and BigList are sorted (in order), there is a faster method: def IsAPartOfList(SmallList,BigList): for i in BigList: for j in SmallList: if i==j: return true if i>j: break return false (I'm not sure how encouraged using break statements are, so wait for a tutor to answer) If one list is already sorted but the other isn't, it may still be faster to sort the unsorted list then use the method above. If neither SmallList or BigList are sorted, it's probably best to use your original method, which I cannot improve. -- Tom Fitzhenry ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Losing the expressiveness ofC'sfor-statement?/RESENDwith example
Stephen McInerney wrote: > Guys, > > I'm annoyed at how far offtopic and frankly rude the responses to my > email were, > and I'm just going to submit my doc change request to Fred Drake > exactly as > I was intending to before I sent the first mail. I have found your e-mails to be far more rude than those of the other list members. > I didn't get much decent opinion on my central question: > "isn't this idiom more restrictive than C/C++/Java (aka the rest of > the universe), I'm pretty sure a lot of people use .NET, Ruby, PHP, Perl, and other languages, so I wouldn't say C/C++/Java is the 'universe.' A large part, though. Yes, it's more restrictive. Python's 'for' loop has a specific purpose of iterating over collections. This feels similar to saying "Isn't the fact that you don't have direct access to the pointers that variables are storing more restrictive than C++?" It restricts you from accessing the pointers, this is true. However, it doesn't restrict you from anything you actually need to do. Python's aiming for the most common use-case of a for loop to be the clearest syntactically. > don't you agree it's badly explained in the doc (there is no basic > advice to transform > to while loop or else write generator), and the doc should have a > simple change > (add one or two lines with links is all that's needed)." Which doc is this? I don't think this addition would be a line or two. It's not simply "translate all your C++ for loops to while loops." There are particular situations where for loops are desired, and some where while are, and this requires a fairly in-depth discussion. > I made it clear that my motivation was that this is badly explained > and is a real > hurdle to migration. Then perhaps you should have avoided statements like "This is much poorer than C/C++" and "this is one area where Python is (syntactically) inferior to C/C++/Java. " Them's fighting words. It was completely unnecessary to use such strong language. You're not writing a college essay. We're not going to slap you on the wrists if you say things like "in my opinion." Just because you didn't put "in my opinion" doesn't change the fact that it is your opinion, and the list members disagreed with you. So they discussed why your statements were faulty. If I said Your mother was a hamster and your father smelt of elderberries! How do I program hello, world! in Python? I'm pretty sure most of the focus of the ensuing discussion would fall upon whether your mother were, in fact, a rodent. > Show any of the code we discussed to non-Python > programmers and they'll be lost. Nobody attempted to address the valid > follow-on question about generators returning a tuple (e.g. walking a > pointer, > and incrementing a count, let alone anything more complex) > > - quibbling the motivation for the quicksort example I gave was > clearly offtopic; > I'm very well aware there are better Python implementions, that's > irrelevant; > the motivation was to give a legitimate example which clearly arises > commonly. I quite enjoyed the discussion. It was educational and it involved Python. It was in the spirit of the list, whether it followed your topic or not. Telling everyone off for discussing Python on a python tutor mailing list is not a good way to get the discussion back on track. You'll just get lots of e-mails like this one that, again, have no bearing on the original subject. > - nowhere did I ask for "the language to be changed". I made it clear > this > was a question about how the *documentation* *describes* the > Python approach (very badly describes). Again, these parenthetical criticisms are not doing you any good. They just piss people off. > In any case, when we talk about people migrating from other languages, > C/C++/Java is ~60-95% of the audience, COBOL is irrelevant and PL/I is > ancient history. > > - This is offtopic, but the C for-loop syntax is very syntactically > powerful, > so when people perceive Python lacks it, they may baulk at that. We > have to > do a better job selling why Python is better. The first time I used Python's for loop it was instantly clear that it was better to me. The same for all of my friends who I've introduced to Python. I think its ease of use speaks for itself and it's unnecessary to be preachy about it moreso than a simple explanation of the differences and the motivations behind the changes would be. > The C for-loop syntax itself is not error-prone at all. > Unless you mean off-by-one errors etc., missing initializations, and > those are mostly semantic not syntax-related. > Anyway most of those can be caught by trivial linting and code reviews, > and the rest by automated checkers. > > >> The C syntax is extremely odd to most programmers who haven't been >> trained in it but in more traditional languages like Lisp, Cobol, >> Fortran, Pascal, ADA, etc. > > I couldn't disagree more strongly. > Those were already dated in 1980 - almost everyo
Re: [Tutor] need futher explaining
> names = ['anne', 'beth', 'george', 'damon']
> ages = [12, 45, 32, 102]
> for i in range(len(names)):
> print names[i], 'is', ages[i], 'years old'
>
> now all of it makes sense to me except for the line for i in
> range(len(names)):
> the len statement calculates the number of characters
hi, and welcome to python!
first of all len() is built-in function and not a statement. the way
you can tell is that if it has parentheses after it, i.e., "len()",
then it is usually a function. a statement will not have that, i.e.,
print, if, for, etc. those are statements.
minor semantics... anyway, len() can be used to find out how many
things there are in an object. as you've pointed out, len() can be
used to determine how many characters are in a string. but len() can
also be used to find out how many objects are in a list, tuple, or
dictionary (dict):
>>> names = ['anne', 'beth', 'george', 'damon']
>>> len(names)
4
the example above is less clear to beginners because there is also the
complication added due to the the call to the range() built-in
function. range() works like this:
>>> range(4)
[0, 1, 2, 3]
>>> range(2, 6)
[2, 3, 4, 5]
>>> range(2, 10, 2)
[2, 4, 6, 8]
with a single argument, range() will create a list of numbers from 0
up to but not including the number, as in range(4) above.
with a pair of parameters, range() will create a list of numbers from
the first number up to but not including the 2nd number, as in
range(2, 6).
finally, with 3 arguments, range() will create a list of numbers from
the first number up to but not including the 2nd number, but skipping
each time by the 3rd number, as in range(2, 10, 2).
in the original example, len(names) is called first, which we saw
results in 4. then that gets fed to range(), or effectively,
range(4). so it's the same thing as having this for-loop:
>>> for i in range(4):
... print names[i], 'is', ages[i], 'years old'
...
does this code make more sense to you? hope so! kent also had a good
idea in that there is a better way to pulling out the elements of two
lists via the same index. there is *clearly* a relationship between
the 1st name and the 1st age, as well as the 2nd name and 2nd age,
etc.
his idea is to create another list, but pairing the elements of each
list that have a relationship to each other. that's what the zip()
built-in function does... it takes 2 lists and "zips" them up like a
zipper into a list of tuples:
>>> zip(names, ages)
[('anne', 12), ('beth', 45), ('george', 32), ('damon', 102)]
now you can iterate over the name-age pairs together using his example.
let's go back to the original example. why did the author use a
strange syntax that would possibly confuse readers and new Python
programmers? well, Python's for-loop is really built to iterate over
sequences of items and is less of a counting one like it is in other
languages such as C/C++, Java, and Perl. range() was created to make
it act more like a counting loop.
a long time ago, using range(len()) was the only way to loop through a
sequence via its index instead of by element like "for name in names"
(which is the typical way of iterating through a sequence). in this
particular case, because the author wanted to get elements of 2
different lists at the same time, he had no choice but to go with the
more confusing index route and range(len()).
a 3rd way of doing the same thing became possible starting in Python
2.3, when the enumerate() function was added to the language. what
i've shown you above are the two different ways to iterate through a
sequence... either by element or by index. but there are times that
you want *both*, and that's where enumerate() comes in. it is a
special iterator that emits both an index and an element as it
traverses the sequence/iterable:
>>> for i, name in enumerate(names):
... print "person #%d's name is %s and they are %d years old." % (i,
name, ages[i])
...
person #0's name is anne and they are 12 years old.
person #1's name is beth and they are 45 years old.
person #2's name is george and they are 32 years old.
person #3's name is damon and they are 102 years old.
for those of you who have Core Python, enumerate() is discussed in
section 8.6 along with for-loops and range().
hope this helps!
-- wesley
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
"Core Python Programming", Prentice Hall, (c)2007,2001
http://corepython.com
wesley.j.chun :: wescpy-at-gmail.com
python training and technical consulting
cyberweb.consulting : silicon valley, ca
http://cyberwebconsulting.com
___
Tutor maillist - Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Losing the expressivenessofC'sfor-statement?/RESENDwith example
It seems this is a delightful exchange of rude threats and insults. ;-) My question is: If you love C syntax so much, why don't you program in C and leave us python people alone? And also: It is not the responsibility of the docs to ease the way for C programmers. That is what a specific tutorial is for. The docs are there for the sole purpose of teaching you how to program in python. That is - how you *think* in python. The reason for loops are not the same in python as they are in C is because they are not the same language. You are supposed to write things differently in python than in C (because they are different languages), and the fact that you don't seem capable of doing that tells me that *you* sir are inferior, not python's for. I certainly would not expect to go to Spain, tell them their language is inferior, and then ask them to make concessions for English speakers. JS ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Losing the expressivenessofC'sfor-statement?/RESENDwithexample
That's a good point. He keeps indicating that the tutorial should make reference to C/C++/Java syntax specifically because that's what the rest of the known universe uses. To carry your example one step farther, it's like expecting a grade school Spanish text to have pointers for English speakers because that's what the rest of the known universe speaks. Not only is the claim itself specious, but if the target audience for the book is children learning Spanish, it would make things worse, not better, by only managing to confuse them with something they don't understand. If that's the case, we should have pointers in our English books in Mandarin, which, I believe, really is the most spoken language. I'm sure his local school board would by his argument :-) Jeff -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tiger12506 Sent: Friday, August 10, 2007 5:02 PM To: tutor@python.org Subject: Re: [Tutor] Losing the expressivenessofC'sfor-statement?/RESENDwithexample It seems this is a delightful exchange of rude threats and insults. ;-) My question is: If you love C syntax so much, why don't you program in C and leave us python people alone? And also: It is not the responsibility of the docs to ease the way for C programmers. That is what a specific tutorial is for. The docs are there for the sole purpose of teaching you how to program in python. That is - how you *think* in python. The reason for loops are not the same in python as they are in C is because they are not the same language. You are supposed to write things differently in python than in C (because they are different languages), and the fact that you don't seem capable of doing that tells me that *you* sir are inferior, not python's for. I certainly would not expect to go to Spain, tell them their language is inferior, and then ask them to make concessions for English speakers. JS ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Losing the expressiveness ofC'sfor-statement?/RESENDwith example
Guys, I'm annoyed at how far offtopic and frankly rude the responses to my email were, and I'm just going to submit my doc change request to Fred Drake exactly as I was intending to before I sent the first mail. I didn't get much decent opinion on my central question: "isn't this idiom more restrictive than C/C++/Java (aka the rest of the universe), don't you agree it's badly explained in the doc (there is no basic advice to transform to while loop or else write generator), and the doc should have a simple change (add one or two lines with links is all that's needed)." I made it clear that my motivation was that this is badly explained and is a real hurdle to migration. Show any of the code we discussed to non-Python programmers and they'll be lost. Nobody attempted to address the valid follow-on question about generators returning a tuple (e.g. walking a pointer, and incrementing a count, let alone anything more complex) - quibbling the motivation for the quicksort example I gave was clearly offtopic; I'm very well aware there are better Python implementions, that's irrelevant; the motivation was to give a legitimate example which clearly arises commonly. - nowhere did I ask for "the language to be changed". I made it clear this was a question about how the *documentation* *describes* the Python approach (very badly describes). In any case, when we talk about people migrating from other languages, C/C++/Java is ~60-95% of the audience, COBOL is irrelevant and PL/I is ancient history. - This is offtopic, but the C for-loop syntax is very syntactically powerful, so when people perceive Python lacks it, they may baulk at that. We have to do a better job selling why Python is better. The C for-loop syntax itself is not error-prone at all. Unless you mean off-by-one errors etc., missing initializations, and those are mostly semantic not syntax-related. Anyway most of those can be caught by trivial linting and code reviews, and the rest by automated checkers. The C syntax is extremely odd to most programmers who haven't been trained in it but in more traditional languages like Lisp, Cobol, Fortran, Pascal, ADA, etc. I couldn't disagree more strongly. Those were already dated in 1980 - almost everyone these days learns C/C++/Java(/C#) as their main programming language, unless they're mechanical engineers or accounting programmers. Look at TIOBE Index to confirm that. I am an EE who started out in the 80s with garbage like BASIC, Fortran, Pascal and assembly, but when I discovered C in 1992 I almost wept that the for-loop syntax was so simple yet infinitely powerful. But C is a poor choice for more user centric problems. I never said otherwise, but the reality we're operating in is that the common languages in use will always lag the leading edge by ~15-30 years. So we should at least make very basic accomodations for that migration reality. Specifically, give the people a hint to use while-loops and generators. > It's regrettable we have to choose between the clear and the > efficient, in this situation. The most clear and efficient is probably: myList.sort() Alan - this was totally unnecessary and trashes the entire (legitimate) context of my question. Regards, Stephen From: "Alan Gauld" <[EMAIL PROTECTED]> To: tutor@python.org Subject: Re: [Tutor] Losing the expressiveness ofC'sfor-statement?/RESENDwith example Date: Tue, 7 Aug 2007 15:24:34 +0100 "Stephen McInerney" <[EMAIL PROTECTED]> wrote > I don't deny the superiority of the underlying language design, > I'm just pointing out the very real mindjolting effect of Python not > supporting the universal syntax. An interesting term. The C syntax is extremely odd to most programmers who haven't been trained in it but in more traditional languages like Lisp, Cobol, Fortran, Pascal, ADA, etc. It is also highly error prone and a source of many bugs in C programs (I know I spent several years running a C maintenance project and for loop side-effects were right up there with uninitialised variables and memory leaks in the common error lists!). > Java is closer to C than Python is. True, Java deliberately set out to be a simple subset of C++ so it has a similar syntax. Python is closer to Lisp than C is but nobody would suggest that C should change its semantics to suit the tastes of Lisp programmers who are converting. Languages are different and learning the new idioms both positives and negatives) is part of the process. > Don't you agree that the Python tutorial should say something simple > and accessible to beginners like: "For all for-loop constructs where > the > iteration can't be written as a simple range object, In fact the range version of a for loop is only one style and probably not the most common. You should iterate over a collection not a range in most cases: ie someList = [1,2,3,4,5] for item in someList: print item and never for index in range(len(somelist)): print somelist
[Tutor] Simple way to compare Two lists
Hello! I desperately need a simple way to compare whether any item of SmallList is in BigList. My current way, def IsAPartOfList(SmallList,BigList) for item in SmallList: if item in BigList: return True return False Takes up waay too much time to process. Can anyone think of any better way? Usually, SmallList is generated using range(Long, Long+ ~300) BigList is usually of a few hundreds of long numbers. The long numbers themselves represent date in seconds-since-the-epoch time. (E.G: time.time() is now in seconds-since-the-epoch, 1186739653.467 at the time of writing.) Thank you for your help, Omer Tabach. Now playing: Haggard - Requiem in D-Minor posted with FoxyTunes - Looking for a deal? Find great prices on flights and hotels with Yahoo! FareChase.___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Losing the expressivenessofC'sfor-statement?/RESENDwith example
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Stephen McInerney > I didn't get much decent opinion on my central question: > "isn't this idiom more restrictive than C/C++/Java (aka the rest of the universe)," I thought you got plenty of decent opinion and most of was disagreement. And, frankly, this underlies your lack of knowledge about the universe. And I'm not saying that to be rude. While those three languages may be near the top for something like the TIOBE TCP index, even they admit that it is "based on the world-wide availability of skilled engineers, courses, and third party vendors. This availability is determined by using the Google and Yahoo! search engines to calculate the ratings." This is not a very good way to determine real world use although it is probably instructive if you are starting a new project and are looking for some direction as to choice of language. It says nothing, however about the number of programmers actually using a language. This list would almost certainly include COBOL and Visual Basic (which is actually #3 on the TCP as well). > quibbling the motivation for the quicksort example I gave was clearly offtopic; I'm very well aware there are > better Python implementions, that's irrelevant; the motivation was to give a legitimate example which clearly > arises commonly. Maybe that's because many of us don't feel that it was an example that arises commonly. Once you become experienced OO language programming and start to think in OO constructs, which Python is very good at facilitating, that type of usage virtually disappears. > In any case, when we talk about people migrating from other languages, C/C++/Java is ~60-95% of the audience, > COBOL is irrelevant and PL/I is ancient history. Actually, since COBOL and PL/I are both ancient history with tons of legacy code in service, they are the classic target for migration. I'll admit I was amused by the figure of 60-95%...what's the error bar on that :-) >>The C syntax is extremely odd to most programmers who haven't been >>trained in it but in more traditional languages like Lisp, Cobol, >>Fortran, Pascal, ADA, etc. > I couldn't disagree more strongly. > Those were already dated in 1980 - almost everyone these days learns C/C++/Java(/C#) > as their main programming language, unless they're mechanical engineers or accounting programmers. Look at TIOBE > Index to confirm that. They may have been dated but they were still in heavy use. At many engineering schools and research labs FORTRAN was still be widely taught well into the 90's and is still in fair use today. And the TCP doesn't give a breakdown by job category. And since it's based on Google and Yahoo searches, I'm not sure of its general usefulness anyway. >>myList.sort() >Alan - this was totally unnecessary and trashes the entire (legitimate) context of my question. Why? It most certainly isn't...it speaks directly to your contention that implementing a quicksort is a common task nowadays... Jeff ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Simple way to compare Two lists
Jaggo wrote: > Hello! > > I desperately need a simple way to compare whether any item of SmallList > is in BigList. > > My current way, > > def IsAPartOfList(SmallList,BigList) > for item in SmallList: > if item in BigList: >return True > return False > > Takes up waay too much time to process. > Can anyone think of any better way? > > Usually, SmallList is generated using range(Long, Long+ ~300) > BigList is usually of a few hundreds of long numbers. Why not just check if if any item in BigList is in the range Long, Long+300? for item in BigList: if Long < item <= Long+300: return True return False which (in Python 2.5) can be shortened to return any(item in BigList if if Long < item <= Long+300) If you really have to make the list, you will do better with a set, especially if the set can be reused over multiple calls. bigSet = set(BigList) return any(item for item in SmallList if item in BigList) If speed is critical, you might see if it matters which list becomes the set and which is iterated. Kent ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Installation of Django on Mac Tiger
David Handel wrote: > Hi. I'm not a real programmer/low level Unix guy yet. I realize that > this is not a Django forum per se. But, I don't know where else to turn > before giving up. > > Can anyone help me install Django on my Mac? I have tried all sorts of > approaches outlnied on various blogs and have Django on my MacBook Pro > but I think that I have simply failed to get Python to see the Django > module. It sounds like you don't have Django in the Python search path. Here is one way: Download the 0.96 release and unpack it. Open a command line to the Django-0.96 directory and run > python setup.py install Kent ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
[Tutor] Extension problem
Hello!
I'm quiet new to Python and definitely a beginner in implementing Python
extensions in C/C++. I've followed the structure given in the formal Python
documentation to write the following code block:
===
//cmatmod.c
#include
static unsigned int eigenvect_calc(double *min_eps)
{
return 5;
}
static PyObject *cmat_eigv(PyObject *self, PyObject *args)
{
double *min_eps;
unsigned int m;
if(!PyArg_ParseTuple(args, "d", &min_eps))
return NULL;
m=eigenvect_calc(min_eps);
return Py_BuildValue("I", m);
}
static PyMethodDef cmat_methods[]=
{
{ "eigenvect", cmat_eigv, METH_VARARGS, "Comment"},{NULL, NULL, 0, NULL}
};
void initcmat(void)
{
(void) Py_InitModule("cmat", cmat_methods);
}
===
I have succeeded to build and install this extension using disutils package in
the setup.py file below:
===
from distutils.core import setup
from distutils.extension import Extension
setup(name='eigenvect',
version='1.0',
ext_modules=[Extension('cmat', ['cmatmod.c'])],
)
==
But when I try to call eigenvect(3.0) from Python I would receive a core dump:
==
6 [main] python 2336 _cygtls::handle_exceptions: Error while dumping state
(probably corrupted stack)
Segmentation fault (core dumped)
==
My question is what is wrong with the extension code above? Is it something
with reference counting?
I don't know which method is suitable for debugging extension codes. I've tried
gdb but I didn't understand the debug information:
==
(gdb) >>> eigenvect(4.0)
Program received signal SIGSEGV, Segmentation fault.
---Type to continue, or q to quit---
0x6abb248e in libpython2!PyEval_EvalFrameEx () from /usr/bin/libpython2.5dll
(gdb)
==
/best regards
Spray Webbhotell. Ingen startkostnad, 3 månader gratis och fri support. Perfekt
för dig som ska starta en egen webbplats. http://www.spray.se/kampanj___
Tutor maillist - Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Simple way to compare Two lists
Hi,
You're really asking about optimisation incidentally.
On Friday 10 August 2007 10:54, Jaggo wrote:
> Hello!
>
> I desperately need a simple way to compare whether any item of SmallList is
> in BigList.
A simple way:
True in [x in BigList for x in SmallList]
Not efficient necessarily, but it is a simple way. Sounds like you want a
faster way.
> My current way,
>
> def IsAPartOfList(SmallList,BigList)
> for item in SmallList:
> if item in BigList:
> return True
> return False
This is directly equivalent to my approach above BUT I *expect* your approach
will run faster. *Since you short circuit the result by returning true.
> Takes up waay too much time to process.
> Can anyone think of any better way?
So what you're really after is a quicker way, yes?
The problem you have here is worst case IsAPartOfList will run through all the
elements of BigList a number of times (specifically len(SmallList).
Sorting the two lists and then working through may be quicker, but I'm struck
that the cost of sorting BigList itself may be more costly than you want
given you say the above function you wrote (which is pretty efficient) is too
slow.
Two immediate thoughts - use psyco on the function. It's a simple enough
function and psyco may be able to give you a dramatic speedup.
Alternatively you could reverse your loop. Rather than do SmallList * BigList
number of comparisons, if there are duplicates in BigList (rather than being
a set), then you could iterate through BigList more efficiently.
If I read your spec correctly, then the following holds true even though its
the inverse of what you stated as the probem:
def IsAPartOfList_2(SmallList,BigList)
for item in BigList:
if item in SmallList:
return True
return False
Incidentally this simple reversal may in itself be quicker depending on your
data. If the numbers are generated from (say) a list of events and you're
correlating events, then you may find this quicker:
def IsAPartOfList_3(SmallList,BigList)
for item in reversed(BigList):
if item in SmallList:
return True
return False
Since that exploits domain knowledge about the two lists. This becomes
especially likely if the lists are likely to be already sorted because
they've come from some ordered source (eg a server log).
Furthermore if BigList is a list of times all in ascending order, and
SmallList is a list of times in ascending order, and the latter represents a
list of "recent" events and BigList represents a list of all events, then you
can make another optimsation to take advantage of that knowledge:
def IsAPartOfList_4(SmallList,BigList)
for item in reversed(BigList):
if item in reversed(SmallList):
return True
return False
Why?
Consider the following two lists:
BigList:
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20,
21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39]
SmallList:
[33, 34, 35, 36]
Then IsAPartOfList_4 will make 13 comparisons before returning True. Whereas
IsAPartOfList_2 will make 133 comparisons, and your original will make 34
comparisons.
However, if you have duplicates in BigList, we can skip the "if item in
SmallList" every time we have a duplicate:
def IsAPartOfList(SmallList,BigList)
seen = {}
for item in BigList:
if not seen.get(item, False):
if item in SmallList:
return True
return False
This will only give you a potential speedup IF two things hold:
* BigList contains duplicates
* seen.get(item, False) is quicker
IF these things don't hold then you won't see any improvement. Personally I'd
try using psyco on the function since then you leave the function looking
clean and simple.
Which is things is quickest will depend heavily on the likely structure of the
data, likelihood of duplicate, ordering and likely similarities between data.
Overall though you have two choices:
* Exploit your knowledge of the distribution and ordering of values
* Use psyco
These aren't mutually exclusive options :-)
Michael.
___
Tutor maillist - Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Losing the expressiveness ofC'sfor-statement?/RESENDwith example
Smith, Jeff wrote: > P.S. This should in no way be construed as undercutting my belief that > Python should have a case statement, a ternary operator, and > full-fledged lambdas Python 2.5 does have conditional expressions that do the work of a ternary operator: x = y if z else w http://docs.python.org/whatsnew/pep-308.html Kent ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Losing the expressivenessofC'sfor-statement?/RESENDwith example
"Stephen McInerney" <[EMAIL PROTECTED]> wrote > I'm annoyed at how far offtopic and frankly rude the responses Don;t get annoyed at off topic posts, that's all part of the fun in a group like this which is aimed at teaching novices how to program and specifically how to program in Python. The wider issues are all part of the training. As to rudeness, this is a very polite group by most internet standards, but if anything I wrote upset you I apologise, it wasn't my intention. > I'm just going to submit my doc change request to Fred Drake > exactly as I was intending to before I sent the first mail. That's fine and Fred may well incorporate it. Personally I believe that would be a mistake as it sets a bad precedent. It may even encourage C programmers to try to convert their C coding style into Python, and that would be a big mistake - both for the individuals concerned and for the Python community. > I didn't get much decent opinion on my central question: You got a lot of very good opinion, namely that you are comparing apples and oranges. C's for loop is syntactic sugar for a while loop. Python's for loop is a foreach construct for iterating over a collection. Very different things, and impossible to compare sensibly. > "isn't this idiom more restrictive than C/C++/Java (aka the > rest of the universe), But your central premis that C/C++/Java form the "rest of the universe" is just plain wrong. There are many, many other languages in day to day use. Infoweek and Computing magazines regularly run surveys of their readers which show COBOL to be the most widely practiced language today (as indeed it has been for the last 30 years!) - looking at job ads doesn't take account of the fact that most COBOL jobs are with big corporations and are often jobs for life! I know several of our (5000 or so) in-house COBOL jockeys who have over 30 years service...) > don't you agree it's badly explained in the doc (there is no basic > advice to transform to while loop or else write generator), and the > doc > should have a simple change The docs explain how the python for loop works pretty well I think. They do not explain the differences between Python's for loop and C's for loop any more than they explain the differences between Pythons lambda and Lisp's version. Whether the docs should do that is a moot point that the maintainer (Fred) can decide. > Show any of the code we discussed to non-Python programmers > and they'll be lost. That I doubt, most of it was generic apart from the generator 'yield' construct. And anyone used to generators - Lisp, Ruby, Smalltalk programmers would all guess at its function pretty well intuitively. > follow-on question about generators returning a tuple > (e.g. walking a pointer, and incrementing a count, let alone > anything more complex) Sorry, I missed it. Can you ask again in a separate thread and we can take a look at it. > - quibbling the motivation for the quicksort example I gave was > clearly offtopic; No, it was an example of how, by considering the actual purpose of the code we can usually find a completely different solution to any such problem. There are very few scenarios that actually require that kind of low level algorithmic access in Python - algorithm design being one valid example! > the motivation was to give a legitimate example which clearly arises > commonly. And my point was that in Python it doesn't arise very commonly at all. There is nearly always an alternative style of solution, often avoiding for loops entirely. > In any case, when we talk about people migrating from other > languages, > C/C++/Java is ~60-95% of the audience, COBOL is irrelevant Going by the posts we see on this list the majority of the folks coming to python come from other scripting languages: PHP, Perl, Visual Basic or from shell scripting (DOS Batch, VMS DCL or Unix shell) or from other high level languages like Rebol, Mathematica or Lisp. There are also many first timers since python is fast becoming the teaching language of choice in colleges and schools. We very rarely get questions from C/C++ programmers and only a few from Java. We have had at least one COBOL programmer but I agree they aren't that common - mostly they are still hacking away in COBOL! Where they might come from is using Python as a replacement for their JCL scripts, and we have had a couple of those at least... > and PL/I is ancient history. But we can learn from history and the lesson of PL/1 was - don't try to create a language with all the features of every other language, it will be a monster! I know you weren't trying to change the for loop merely translate its style in the docs, but my point was that anyone looking for all their best loved featires from language X in language Y is doomed to failure. > - This is offtopic, but the C for-loop syntax is very syntactically > powerful, so when people perceive Python lacks it, they may baulk > at that. No arguments about i
Re: [Tutor] Installation of Django on Mac Tiger
David Handel wrote: > Hi Kent, > I'm not having much luck. I placed the Django 0.96 folder in /Library Better to put it in a Download folder or some such, it doesn't need to be in Library. Not a big deal though. > and then ran the following session: > Last login: Fri Aug 10 16:58:58 on ttyp1 > Welcome to Darwin! > david-handels-computer:~ davidHandel$ cd Library > david-handels-computer:~/Library davidHandel$ python setup.py install This is the right command, but you have to be in the dir that contains setup.py when you give it. I.e. from Library, $ cd Django-0.96 $ python setup.py install > /Library/Frameworks/Python.framework/Versions/2.5/Resources/Python.app/Contents/MacOS/Python: > > can't open file 'setup.py': [Errno 2] No such file or directory > david-handels-computer:~/Library davidHandel$ python > Python 2.5.1 (r251:54869, Apr 18 2007, 22:08:04) > [GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> setup.py install This is not the right way to do it. Kent PS Please use Reply All to reply to the list. ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
