[Tutor] Losing the expressiveness ofC'sfor-statement?/RESENDwith example

Kent Johnson kent37 at tds.net
Fri Aug 10 14:34:11 CEST 2007

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.


More information about the Tutor mailing list