"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 bad!
It is Pythons "foreach" effect that makes it so powerful.
> I think the tutorial is lacking on this (should I email Fred Drake?)
You could try it but that would imply that the tutorial should flag
up where Python varies from the syntax of COBOL too - after all there
are many more COBOL porogrammers than any other language!
So explaining
x = y + z
we would need a note:
Notice that Python uses a math symbol for addition instead
of the more common COBOL usage
ADD Y, Z TO X
And explain to Smalltalk, ADA and Pascal programmers that = is
assignment instead of :=
Where do you stop?
> 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?
A language is syntactically fully featured if it supports the 3
elements
of structured programming (sequences, loops and branches) , or even
more starkly if it is Turing complete. No language should try to
encompass
all styntax structures of all languages (that way lies PL/1!)
> One of our aims should be to write code which is at least
> understandable to
> programmers of other languages.
Yes, but that doesn't mean a similar syntax, it means an easy
comprehension of the syntax as written. ie one that reads as much
as possible like a natural language - a test that C fails miserably!
>>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
> Yes I did: it occurs in a quicksort as we halve the stepsize each
> time,
> on an array of size 60000.
OK so use Pythons built in sort method. It uses quick sort I believe.
But if it doesn't still use it and see if its fast enough. If it isn't
consider
refactoring your data structures to improve it. If that doesn't work
then,
as a last resort, consider writing your own sort function. When using
high level languages leverage the language.
> 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 most straightforward solution is to use the standard sort
function.
> the fastest solution, the last-memory solution and the most elegant
> solution.
Yes it's almost certainly all of those.
>>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.
I disagree, the while lop is a distraction from what you are trying to
achieve,
which is use a specific list on numbers to performs some action, in
your
case a sort. The more you can hide the generation of the numbers the
clearer your code becomes. (PS I agree the name "half" is not great
but it was short in the interpreter! :-)
> lambda would also be too quirky.
lambda is no good here because Python's lambda only allows a
single expression not loops - I originally thought a lambda might
work.
(The limitations of Python's lambda are another copmmon complaint for
programmers moving from languages which better support functional
programming, but that still doesn't mean Python should change its
lambda to match)
> I know the generator is more runtime-efficient.
You know more than me in that case, I didn't even think about that, I
simply
tried to solve the problem. If run time efficiency is that critical
Python is probably
not the right language anyway - but only if you try it, and measure
it, and
know that run time efficiency is an issue. Python is not trying to get
you close to the machine, quite the opposite, its trying to get you
closer
to the problem you are trying to solve. C is designed to get you close
to
the machnie, that's why its the right choice for writing device
drivers etc.
But C is a poor choice for more user centric problems.
> 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()
HTH,
--
Alan Gauld
Author of the Learn to Program web site
http://www.freenetpages.co.uk/hp/alan.gauld
_______________________________________________
Tutor maillist - Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor
