[Tutor] Losing the expressiveness ofC'sfor-statement?/RESENDwith example
kent37 at tds.net
Fri Aug 10 14:34:11 CEST 2007
Stephen McInerney wrote:
> 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
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
> 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
> I'm very well aware there are better Python implementions, that's
> the motivation was to give a legitimate example which clearly arises
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,
> but the C for-loop syntax is very syntactically
> 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:
> 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