Some more notes
jeff at ccvcorp.com
Fri Oct 22 03:07:50 CEST 2004
>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"
>5) Inside function definitions, assignments of mutable types like this
>can be forbidden and seen as errors by the interpreter:
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.
>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
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:
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.
More information about the Python-list