[Tutor] How to print complex numbers without enclosing parentheses
Why does the complex.__str__() method on complex numbers add the enclosing parentheses? It's unwanted, and it also makes them look like a tuple (other than the trailing comma). How can I get rid of it, other than the clunky: print d(0.80-0.58j) print repr(d)[1:-1]0.80-0.58j How can I change complex.__str__() ? Thanks, Stephen _ Get more out of the Web. Learn 10 hidden secrets of Windows Live. http://windowslive.com/connect/post/jamiethomson.spaces.live.com-Blog-cns!550F681DAD532637!5295.entry?ocid=TXT_TAGLM_WL_domore_092008___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
[Tutor] Help reproing IDLE bug 3841? esp. on Windows Vista, XP
Could anyone help reproing this minor IDLE bug?http://bugs.python.org/issue3841I found it on Windows Vista with Python 2.5 / IDLE 1.2.2. Other people have reported it does NOT occur with either: Win XP / Python 2.5 / Idle 1.2 Mac OS X 10.5.4 / Python 2.5.2 / IDLE 1.2.2 Can anyone repro it on Vista on 2.5? Vista on 2.6? Please let me know if you can/cannot repro on a combination of each of these:OS: Windows XP (SP2?), Windows Vista (SP1?), LinuxPython version: 2.5, 2.6, 2.7, 3.0IDLE versions: ? Copy-and-paste the testcase, view it inside IDLE and see what if the issue occurs.Should only take 1 minute. Thanks in advance,Stephen _ See how Windows connects the people, information, and fun that are part of your life. http://clk.atdmt.com/MRT/go/msnnkwxp1020093175mrt/direct/01/___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
[Tutor] Operators on complex numbers, and applying real to a list of real and complex numbers
Two questions about complex numbers: a) why are methods __add__,__mul__ defined but not the operators '+','-','*','/' ? How can I bind the methods to the obvious operators (without creating a custom subclass of complex?) It seems pretty weird writing a.__add__(b) b) Say I have a list ll which mixes real (float) and complex numbers. ll = [1, 0.80-0.58j, 0.11+.2j] What is the best Python idiom for getting the list of real parts of elements of ll? [lx.real for lx in ll] fails because only complex numbers have a 'real' attribute, real numbers don't (slightly bizarre). Unless I write the not-so-readable: [(type(lx) is complex and lx.real or lx) for lx in ll] or define my own function. Do any of you see a need for a math.real() (or math.complex()) function, which operates on all numeric types? Then I could simply take the list comprehension [real(lx) for lx in ll] Is this worthy of a PEP? It seems simple but overlooked. Regards, Stephen _ See how Windows connects the people, information, and fun that are part of your life. http://clk.atdmt.com/MRT/go/msnnkwxp1020093175mrt/direct/01/___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
[Tutor] Any Windows users help reproing IDLE bug 3841?
Can a couple of Vista and XP users please test this out? Thanks - Stephen _ Could anyone help reproing this minor IDLE bug?http://bugs.python.org/issue3841I found it on Windows Vista with Python 2.5 / IDLE 1.2.2.Other people have reported it does NOT occur with either:Win XP / Python 2.5 / Idle 1.2 Mac OS X 10.5.4 / Python 2.5.2 / IDLE 1.2.2Can anyone repro it on Vista on 2.5? Vista on 2.6?Please let me know if you can/cannot repro on a combination of each of these:OS: Windows XP (SP2?), Windows Vista (SP1?), LinuxPython version: 2.5, 2.6, 2.7, 3.0IDLE versions: ? Copy-and-paste the testcase, view it inside IDLE and see what if the issue occurs.Should only take 1 minute. Thanks in advance,Stephen _ Stay up to date on your PC, the Web, and your mobile phone with Windows Live. http://clk.atdmt.com/MRT/go/msnnkwxp1020093185mrt/direct/01/___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
[Tutor] Suggested books for Agile Programming Testing?
Can anyone recommend me the best single must-read book for Agile Programming? Also Agile Testing. (If they compare Agile in general to the other methodologies, that would be great) Also, can anyone comment on the limits or caveats of agile development? Thanks, Stephen _ Kick back and relax with hot games and cool activities at the Messenger Café. http://www.cafemessenger.com?ocid=TXT_TAGHM_SeptHMtagline1 ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Efficiency of Doxygen on Python vs C++?
Kent, I was asking if it's a recognized good programming practice to declare and initialize *all* members in the class defn. What do you mean by initialize *all* members in the class defn? - obviously I meant to say do it in the __init__() method, I wrote the snippet as I was rushing out the door to an exam, but I think the intent was clear. If you mean to initialize the variables in the __init__() method: maybe this is more common but I don't think I have ever seen it recommended to initialize all variables in the __init__() method. Certainly there are times when it makes sense to have some of the initialization in other methods that are called from __init__(). I only said make a token dummy assignment in __init__() to hint to the static analyzer the name and expected type, I didn't say you must do all the actual initialization itself in __init__(). In the context of the original question where and how should we assign class members in order to flag member names and types to static analyzers like Doxygen or pylint? I understood that people were agreeing Yes, assigning each member token values in the __init__() method is a good practice. I think I'm hearing a general yes on that - any other opinions? Not sure where you think you are hearing a yes, I am hearing a lot of objections. No they didn't - they said that this cannot be done for true dynamic code, which is true, but obviously doesn't apply to working with static analysis tools, which is what the question was about. Regards, Stephen _ Messenger Café open for fun 24/7. Hot games, cool activities served daily. Visit now. http://cafemessenger.com?ocid=TXT_TAGHM_AugHMtagline ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Efficiency of Doxygen on Python vs C++?
Hi Alan,
My friend clarifies: It's not the efficiency of doxygen that's the
question. The problem is that you can add fields to objects as you go in
Python so you need to do a deep analysis of the code to determine the
class
structure which you don't have to do with C++ (or Java).
That's true it's one of the benefits of a dynamic language, but it does
make the code harder to parse.
Is this not just evidence of a very bad Python coding style?
Should we not always declare *all* class fields in the class definition
by assigning to them, even if the assignment is token or dummy
i.e. 'None', , [], {} etc.
He mentioned numbers like maybe ~20+x slower on lines-of-code
for Python vs C++.
That sounds high, I would have expected no more than 5-10 times longer.
But of course against that we have the advantage that there will be far
fewer
lines to parse in a Python project, typically only a third or a quarter of
the number of lines - sometimes less than that.
Can you cite us a literature source for saying that Python is 3-4x more
expressive per line-of-code than C++?
Would come in handy for evangelizing.
A second friend of mine who is an XML/Java enthusiast echoed similar
comments about scalability in large builds with weakly-typed dynamic
languages such as Python.
The concept of a large build doesn't really exist in an interpreted
language like Python. OTOH I probably wouldn't usePython for a
very large project - say over a million lines of code in C++ - for a
variety of other reasons. eg. Python could do it but the coordination of
multi team projects becomes harder without tools like static type
checking.
Has anyone ever tried pragmas for hinting about member types as I suggested?
Stephen
_
A new home for Mom, no cleanup required. All starts here.
http://www.reallivemoms.com?ocid=TXT_TAGHMloc=us
___
Tutor maillist - Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Efficiency of Doxygen on Python vs C++?
Eric, you misunderstood my point.
I said you make a **token** assignment in the class defn simply
to do two things:
- 1) identify all the members in one place
- 2) annotate each member's type, as much as you can
e.g.:
class C
s = []
d = {}
ot = (None, None)
I didn't say you make the actual assignment. Obviously you can't
in most cases.
Regards,
Stephen
From: Eric Brunson [EMAIL PROTECTED]
Is this not just evidence of a very bad Python coding style?
Should we not always declare *all* class fields in the class definition
by assigning to them, even if the assignment is token or dummy
i.e. 'None', , [], {} etc.
Absolutely not. I have several classes that build themselves dynamically
at runtime. As an example, one of them reads the data dictionary of a
database. You may as well suggest that you define all your dictionary keys
at the beginning of the program.
_
A new home for Mom, no cleanup required. All starts here.
http://www.reallivemoms.com?ocid=TXT_TAGHMloc=us
___
Tutor maillist - Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Efficiency of Doxygen on Python vs C++?
Oh ok, I see. Yes I've also programmed classes that dynamically declare themselves (mine was for XML parsing). Presumably static analyzers like Doxygen etc. can't handle those so they lie outside the scope of what we were discussing. I was asking if it's a recognized good programming practice to declare and initialize *all* members in the class defn. I think I'm hearing a general yes on that - any other opinions? Stephen From: Eric Brunson [EMAIL PROTECTED] To: Alan Gauld [EMAIL PROTECTED] CC: tutor@python.org Subject: Re: [Tutor] Efficiency of Doxygen on Python vs C++? Date: Fri, 17 Aug 2007 18:37:54 -0600 We're definitely on the same wavelength, Alan. :-) Alan Gauld wrote: Stephen McInerney [EMAIL PROTECTED] wrote Eric, you misunderstood my point. I said you make a **token** assignment in the class defn simply to do two things: - 1) identify all the members in one place - 2) annotate each member's type, as much as you can I'm sure Eric can explain for himself but what I think he was saying was that his classes define themselves at runtime. They read the names of the fields and type information from the database metadata and create the attributes accordingly. Thus he doesn't know what his class attributes will be until the program runs. He may not even know the names of his classes until he reads the database tablenames. This is exactly the kind of tricky coding that is possible in a dynamic language which is next tio impossible in static compiled code, unless you write your own 'little language interpreter' inside the compiled program. This kind of abstract meta programming is extremely tricky to get right but at least it's possible in something like Python. But it makes analyzing the code very complex since much of the working code is being created by the config code at runtime. I've never actually tried this in Python but have done similar things in Lisp. In C++ you usually have to create classes in advance for every possible eventuality then use a factory class (or big switch statement) to create the desitred instances. That's a lot of excess code which is still less reliable and robust. Of course I could be misreading Eric's intent... Alan G. ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor _ Puzzles, trivia teasers, word scrambles and more. Play for your chance to win! http://club.live.com/home.aspx?icid=CLUB_hotmailtextlink ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
[Tutor] Efficiency of Doxygen on Python vs C++?
My friend said the runtime efficiency of Doxygen on his build was much worse on the Python code than the C++ code, i.e. it took ages to parse the Python code. Anyone agree/disagree, or have any efficiency tips on how to structure things for decent Doxygen performance? (I haven't used Doxygen myself and I don't have access to the build in question). Regards, Stephen _ Learn.Laugh.Share. Reallivemoms is right place! http://www.reallivemoms.com?ocid=TXT_TAGHMloc=us ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Efficiency of Doxygen on Python vs C++?
My friend clarifies: It's not the efficiency of doxygen that's the question. The problem is that you can add fields to objects as you go in Python so you need to do a deep analysis of the code to determine the class structure which you don't have to do with C++ (or Java). He mentioned numbers like maybe ~20+x slower on lines-of-code for Python vs C++. A second friend of mine who is an XML/Java enthusiast echoed similar comments about scalability in large builds with weakly-typed dynamic languages such as Python. (I said why doesn't doxygen have optional pragmas to annotate the type of tricky class members to the tool?) Has anyone used Doxygen and can comment? (Alan - their build setup was generating the docs every nightly build. Yes it sounds like overkill and an inefficient setup, but notwithstanding that I'm interested in the question as stands.) Thanks, Stephen Stephen McInerney [EMAIL PROTECTED] wrote My friend said the runtime efficiency of Doxygen on his build was much worse on the Python code than the C++ code, i.e. it took ages to parse the Python code. Anyone agree/disagree, or have any efficiency tips on how to structure things for decent Doxygen performance? Until your post I had never heard of it. Having read the wiki article I gather its a Javadoc style documentation generator. Not being a fan of such beasts I doubt I'd be inclined to use it, but why is performamce an issue for a documentation generator? Presumably you only need to generate the documents periodically - say once a day - rather than with every build? In-code documentation is what is being used to create the docs so you can use that in day to day coding - one reason I find doc generators fairly useless! Documentation should be about what the comments don;t say not merely a comment and interface extraction. IMHO of course :-) Alan G. _ A new home for Mom, no cleanup required. All starts here. http://www.reallivemoms.com?ocid=TXT_TAGHMloc=us ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Simple way to compare Two lists
Sorting both lists is unnecessary and not very scalable (order(NlogN)). Assuming the lists do not contain duplicates, just turn the longer one into a dict and check that each element of the shorter list in that dict (e.g. if j not in BigList: return false) Since dict lookup is constant-time O(1), this approach is O(M) i.e. speed is linear in the length of the shorter list; and memory requirement is O(N+M) i.e. linear in the length of the longer list. If MN this really saves you time. Stephen From: Jaggo [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: tutor@python.org Subject: Re: [Tutor] Simple way to compare Two lists Date: Thu, 16 Aug 2007 10:11:14 -0700 (PDT) Thank you Kent, Michael, Tom and anyone else I'm forgetting who took time to reply. I don't work quite so fast, very limited personal computer time means I only do it on weekends, I read through your suggestions and eventually found a way to speed-up the proccess through sorting the Two lists, then manually iterating through each of them. This way I've completely canceled the need to compare Two lists: instead just ensuring I start from a point not taken in One list and having to only check whether Item not in BigList. [If anyone's interested, I should have the script finished and thoroughly tested on, ah, next weekend, and I could post a link here.] Again, Thx. -Omer. Message: 1 Date: Fri, 10 Aug 2007 08:11:47 -0400 From: Kent Johnson Subject: Re: [Tutor] Simple way to compare Two lists To: Tom Fitzhenry , tutor@python.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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 ij: 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 - Park yourself in front of a world of choices in alternative vehicles. Visit the Yahoo! Auto Green Center. ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor _ See what youre getting into before you go there http://newlivehotmail.com/?ocid=TXT_TAGHM_migration_HM_viral_preview_0507 ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Efficiency of Doxygen on Python vs C++?
Yes but it's still a canonical question about analysis of weakly-typed dynamic languages, since my Java friend makes separate comments about scalability when analyzing large builds - he claims 1-5m lines of code is a threshold. From: Kent Johnson [EMAIL PROTECTED] To: Kevin Cameron [EMAIL PROTECTED] CC: tutor@python.org Subject: Re: [Tutor] Efficiency of Doxygen on Python vs C++? Date: Thu, 16 Aug 2007 22:06:13 -0400 Kevin Cameron wrote: Stephen McInerney wrote: My friend said the runtime efficiency of Doxygen on his build was much worse on the Python code than the C++ code, i.e. it took ages to parse the Python code. It's not the efficiency of doxygen that's the question. The problem is that you can add fields to objects as you go in Python so you need to do a deep analysis of the code to determine the class structure which you don't have to do with C++ (or Java). So doxygen is actually doing this deep analysis? Kent _ Puzzles, trivia teasers, word scrambles and more. Play for your chance to win! http://club.live.com/home.aspx?icid=CLUB_hotmailtextlink ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Simple way to compare Two lists
Jim Jaggo - Dict lookup is (essentially) constant-time because the hashing function computes which unique bucket a given entry will correspond to. (Hashing functions are usually polynomials involving prime numbers. Can assume that the computation of the hash value is constant-time) So there is no linear table-walking in dict lookup. Walking the shorter list will thus be faster in general, esp if MN. It would be neat to code this example up and measure performance using the standard timeit.Timer object (does anyone have any code or package to generate GIF graphs with logarithmic axes for N, based on timeit.Timer output? Maybe Matplotlib?) If Jaggo could suggest us typical ranges for M,N in his application that would help guide the discussion... cases like M=10, N=10^6 will showcase this. (I am real busy on another task I don't have time to do it right now) PS What is the name of the author of the 'profiler' module? Stephen _ Puzzles, trivia teasers, word scrambles and more. Play for your chance to win! http://club.live.com/home.aspx?icid=CLUB_hotmailtextlink ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] LosingtheexpressivenessofC'sfor-statement?/RESENDwithexample
I didn't suggest embedding C-specific stuff in the documentation; I merely said the current tutorial is deficient on this topic; this is more so important since the language is currently a moving target (as the comments about the increasing power of list comprehensions prove my point. Many Python people are still not aware that basic loops can be done away with via list comprehensiosn with an if conditional qualifier) I gave an idea of what I'm proposing: very simple one-liners like: Idiomatic translation of for-loops in Python may involve the following: list comprehensions / iterators / while-loop / generators (or special-purpose functions e.g. builtin quicksort() )) That's the sort of thing: a very compact signpost to other related topics. Not embedding pages of stuff - that rightly goes in the migration guide suggested. In response to Noufal's comment, KR does a very good job of illustrating the philosophy of the (C) language design. Thanks for the links but the moin wiki one seems dead. I do not have time now to write up my suggested doc changes, but I will do that in the next few weeks and post here. Regards, Stephen _ Messenger Café open for fun 24/7. Hot games, cool activities served daily. Visit now. http://cafemessenger.com?ocid=TXT_TAGHM_AugHMtagline ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Losing the expressivenessofC'sfor-statement?/RESENDwithexample
Hi Alan,
I appreciate your very thoughtful answer.
I had previously thought you were not taking the intent of my question
seriously, it did seem to have strayed hopelessly offtopic (e.g. I knew all
about Python's quicksort() already, but the generic question about for-loops
very much stands).
We certainly don't want the Python equivalent of Pascal-migration
abominations like:
#define BEGIN { #define END }
but idiomatic translation of for-loops into Python is hard:
(e.g. list comprehensions vs basic iterator vs while loop vs generator vs
special-purpose fn)
How can we address that reasonably and succinctly without polluting the doc
with language-migration-specific details, that is a worthy question... I
believe we can do a better job simply by grouping and highlighting related
alternative concepts like I listed above. As to a generator returning
tuples/sequences, I will look into how far that goes.
Also, I believe my generic comment about being forced to choose the
efficient approach vs the most clear, legible or simple approach stands, and
I will think up some examples.
I will collect my response and further thoughts and repost in a few days
when I have more time...
Best,
Stephen
From: Alan Gauld [EMAIL PROTECTED]
To: tutor@python.org
Subject: Re: [Tutor] Losing the
expressivenessofC'sfor-statement?/RESENDwithexample
Date: Sat, 11 Aug 2007 02:12:18 +0100
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
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[index] # bad bad
[Tutor] Losing the expressiveness of C's for-statement?
Hi all,
As the Python doc says: The for statement in Python differs a bit from what
you may be used to in C or Pascal. Rather than giving the user the ability
to define both the iteration step and halting condition (as C), Python's for
statement iterates over the items of any sequence (a list or a string).
This is much poorer than C/C++, and does not allow for the step action to be
multiple actions, fn calls etc. - not straightforwardly anyway. (don't take
that as a challenge)
- I know how to migrate to a while-loop, but I lament losing the very
compact expressiveness of:
for (node=start; valuethreshold node!=end; node=node-next) { ... }
- I figure the straightforward answer will be use a while-loop, put the
iteration step at the end.
- the fancy showoff answer will probably involve a funky iterator with
side-effects, or returning tuples.
- what if the loop iteration step involves variables from within the
loop-body (e.g. as in quicksort stepsize);
- what I'm trying to drive at here is the general solution of least
idiomaticity, not of greatest language-specific cleverness
Any comments or article links? Also, it would be useful to improve the
Python tutorial on this.
Since this is one area where Python is (syntactically) inferior to
C/C++/Java.
Thanks,
Stephen
_
More photos, more messages, more storageget 2GB with Windows Live Hotmail.
http://imagine-windowslive.com/hotmail/?locale=en-usocid=TXT_TAGHM_migration_HM_mini_2G_0507
___
Tutor maillist - Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Losing the expressiveness of C's for-statement?/RESENDwith example
Hi Alan,
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. Java is closer to C than Python is.
I'm bringing this up as one hurdle to migration, not a fundamental flaw.
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, you probably want to
transform it to a while-loop, (or the more advanced option being a
generator)?
I think the tutorial is lacking on this (should I email Fred Drake?)
Instead of leaving C and Java people cold scratching their heads about
why they think the language is hopelessly quirky and not (syntactically)
fully-featured?
One of our aims should be to write code which is at least understandable to
programmers of other languages.
Sorry I meant to pick a tangible example to focus the discussion:
This one cannot be (easily) translated to use Python's range()
operator for (i=3; i0; i=i/2) { ... }
You don't give us any reason why you want to generate a set
of numbers from 30,000 down to zero decreasing by half each
time: 30,000, 15,000, 7500, 3750, etc
To understand the Pythonic solution to the problem we would
need to know what those numbers were required for so that we
could determine if another python data structure might be more
appropriate.
Yes I did: it occurs in a quicksort as we halve the stepsize each time,
on an array of size 6.
Can you please give me your answer on this? We have to transform it to
a while-loop? (or write a custom iterator?)
It would nice to compare the most straightforward solution (while-loop?)
the fastest solution, the last-memory solution and the most elegant
solution.
You have to remember that C's for loop is mostly syntactic sugar
over a while loop: expression1 while test action expression2
Yes I know how to transform it.
Pythons for loop is a much more powerful foreach construct
intended to deal with collections. C's for loop is simply an extension
of assembler syntax and deals with indices, memory addresses, numbers,
whatever low level construct you want. The loop used for that kind
of low level detail in Python is, as you say, the while loop.
As to your particular case one non while option would be a generateor:
def half(n):
while int(n) 0:
n = n/2
yield n
for x in half(300): print x,
It's ok but it's visually clunky. while-loop wins for clarity. lambda would
also be too quirky.
I know the generator is more runtime-efficient.
It's regrettable we have to choose between the clear and the efficient, in
this situation.
Regards,
Stephen
_
Learn.Laugh.Share. Reallivemoms is right place!
http://www.reallivemoms.com?ocid=TXT_TAGHMloc=us
___
Tutor maillist - Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] capwords, maketrans
Ok thanks all. The doucmentation is confusing on that point. Also when it refers to the methods becoming methods of string objects a link would be nice. Regards, Stephen From: John Fouhy [EMAIL PROTECTED] To: Jacob S. [EMAIL PROTECTED] CC: tutor@python.org Subject: Re: [Tutor] capwords, maketrans Date: Thu, 14 Jun 2007 13:30:42 +1200 On 14/06/07, Jacob S. [EMAIL PROTECTED] wrote: Hi guys. I was just wondering what's going to happen to capwords and maketrans when the string module is finally terminated. As far as I know, the string module as a whole is not going away. In particular, the string module supplies various constants that are quite useful. Only those string functions that exist as string methods (and are on the deprecated list) will eventually die. -- John. ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor _ Hotmail to go? Get your Hotmail, news, sports and much more! http://mobile.msn.com ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
