Some more notes
David M. Cooke
cookedm+news at physics.mcmaster.ca
Fri Oct 22 03:24:44 CEST 2004
bearophileHUGS at lycos.com (bearophile) writes:
> Ville Vainio:
>>It's highly typical for the newbies to suggest improvements to the
>>language. They will usually learn that they are wrong, but the
>>discussion that ensues can be fruitfull anyway :-).
> Few more notes on the language. I don't know if I can really suggest
> improvements to the language... but I hope to learn something :-)
> I think some things are better in Delphi/Pascal (like the := for
> assignments instead of = and = for equality, that I suggested in the
> my precedent notes):
> 1) The "print" and "printf" pair without automatically added spaces
> between arguments, and with or without automatic newline, instead of
> the current "print" command. Because adding lots of "+str()+" isn't
> good for me (there's sys.stdout.write, but it's not built-in).
Use string formatting:
>>> a = "Hello"
>>> b = 5
>>> c = 4.52
>>> print "%s, %d is greater than %g" % (a, b, c)
Hello, 5 is greater than 4.52
Also, adding a , to the end of the print statement will suppress the
newline (although, not the space between the two calls).
> 2) Adding "case var of:" can be useful.
"can be" is the operative phrase here. It's not necessary. Chained
if/elif/elif works fine for small cases; for larger, you should
probably use a dict, or rewrite to use a class.
> 3) "do while" (or "repeat until") can also be added, it's useful.
Really, while loops and repeat until loops are special cases of the
much more useful loop-and-a-half:
... some stuff ...
... more stuff ...
The above is a common enough Python idiom (also seen with while 1:,
which runs slightly faster due to absence of the lookup for True).
> 4) Maybe really raw strings RR"" can be added to avoid problems with
> file paths on Win :-]
I'm confused; how does r"..." not help? The only thing that gets
interpreted in a raw string is a backslash at the end of a string:
r"\" is not allowed. (I don't do Windows :-)
> 5) Inside function definitions, assignments of mutable types like this
> can be forbidden and seen as errors by the interpreter:
> def func(a=[1,2]):
But then you have to determine what objects are mutable, and sometimes
this _is_ what you want (using the argument as a cache, or you're sure
that you don't mutate the argument).
> 6) Given:
> a = 
> a += 
> a = a + 
> The first assignment extends the list, and second creates a new list
> and rebinds it. Why such difference for operations that look the same?
> Isn't a kind of "error" to do different things with quite similar
> looking commands?
To me, a +=  and a = a +  look different. You're applying idioms
you've learned in other languages (C?) to Python. += _can_ mutate the
argument, but it doesn't have to: it's very useful when used with
large mutable objects, such as Numeric arrays.
> 7) There's something that I don't understand. I'm not a OOP purist,
> but finding functions like this beside normal methods seems odd to me:
> len(s) length of s
> min(s) smallest item of s
> max(s) largest item of s
> For uniformity they can be:
Alex Martelli has answered this throughly in another thread, where the
context is why have __len__, etc. methods.
Another argument is that most objects, these methods would be useless:
what should s.min() be when s is, for instance, a database object?
Should numbers also have them? These methods only make sense when s is
some type of sequence (len() also works for a collection like a dict
or set, also).
Also, one Python tenet is "practicality beats purity". Making a new
sequence type is _easy_. Add __getitem__ and __len__ methods, and
*poof*. I don't have to inherit from a 'sequence' object, or implement
the methods above: the algorithms in min() and max() work right away.
|David M. Cooke
More information about the Python-list