Some more notes

[Jeff Shannon]

bearophile wrote:

>I think some things are better in Delphi/Pascal 
>

They may well be better _in_ Delphi/Pascal.  That doesn't mean that 
adding them into Python will make Python a better language.  (I love 
garlic.  I love chocolate.  I do not want to eat chocolate-covered 
garlic cloves, nor garlic-flavored chocolate bars.)

>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).
>  
>

But Python *does* already have string interpolation: print "%s%s%s" % 
('one', 'two', 'three')

This is more flexible than printf() would be, because it can be used to 
generate strings even without printing.  C had to resort to creating a 
sprintf() function that did printf()-like formatting without actually 
printing; Python made that a built-in operation on strings.  I find that 
I use this all the time, and never worry about print statements adding a 
space after a comma because I don't need to use commas.

>2) Adding "case var of:" can be useful.
>  
>

Not sure exactly what this is, but if you're referring to a case/switch 
construct: using a dict of functions is (IMO) a better and cleaner way 
of implementing the same idea.

>3) "do while" (or "repeat until") can also be added, it's useful.
>  
>

Somewhat useful, sure, but it's not hard to achieve the same thing with 
'while 1: if cond: break' .  Python's designer made a deliberate 
decision to minimize number of different types of loop structures to 
use, since they tend to be very easy to convert between and fewer types 
means less to learn.  So we have two -- one that loops based on the 
status of a condition, and one that iterates over each object in a 
sequence.  Minor variations on these themes are (according to Python 
philosophy) better done by explicitly stating the rules, rather than by 
creating new syntax for each variation.

>4) Maybe really raw strings RR"" can be added to avoid problems with
>file paths on Win :-]
>  
>

Not really, because Python doesn't know what's supposed to be a file 
path and what isn't.  Unless, of course, you are explicit about it, 
which means using os.path.  In which case, you have already avoided 
those problems using standard strings and don't need to worry about 
whether a string is raw or not, let alone inventing a new "extra-raw" 
string.

>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]):
>  
>

Except that having mutable types be shared this way can be a useful 
feature.  It's approximately the same thing as (in C/Java) declaring a 
local variable to be static.

>6) Given:
>a = [1]
>a += [2]
>a = a + [3]
>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?
>  
>

The idea of using += is that it modifies in-place.  In-place 
modification isn't meaningful for immutable types, but it can be very 
useful for mutable types.  Having a += x mean in-place modification 
while a = a + x creates a new object allows both options to be easily 
accessible without function-call syntax.  Having both of them create a 
new object means that one must call a.extend(x) in order to get in-place 
modification.  And I'd guess that the vast majority of cases where += is 
used, in-place modification is the preferable behavior anyhow.

>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:
>s.len()
>s.min()
>s.max()
>etc.
>  
>

You're apparently more of an OOP purist than Python is...  Having these 
as functions instead of methods is much simpler for Python's dynamic 
type system.  For example, new sequence types don't need to define min() 
and max() methods -- the existing builtins just work.  It also means 
that implementation details of the function can be improved without 
requiring a rewrite of every class that has ever defined a len() method, 
and that Python can split the work of the function between the function 
itself and one or more helper methods that might (or might not) be 
implemented on any given class.

Remember, there's a lot more to good language design than just "Ooh, 
this piece might be useful!"  You also have to consider how all the 
pieces fit together, and how certain constellations of pieces interact 
with other constellations of pieces.  Bulldozer blades, furrowers, and 
manure-spreaders are all very useful devices when attached to the right 
vehicle, but you wouldn't want them on your commuter car, right?  Much 
better to stick with a small subset of "useful devices" which fit 
together in a consistent and (most importantly) practical way.

Jeff Shannon
Technician/Programmer
Credit International