Some more notes

[David M. Cooke]

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:

while True:
      ... some stuff ...
      if condition_true:
         break
      ... 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 = [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?

To me, a += [2] and a = a + [3] 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:
> s.len()
> s.min()
> s.max()

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
|cookedm(at)physics(dot)mcmaster(dot)ca