Some more notes

[Cliff Wells]

On Thu, 2004-10-21 at 15:16 -0700, bearophile wrote:

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

Actually, since the assignment operator is used far more often than the
equality operator, making it require three keystroke rather than just
one is a bad idea.

> 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 interpolation.  However, I agree having print as a statement
rather than a function is a (very small) wart.  Luckily it's easily
circumvented (and I've heard rumor that this is, in fact, slated to be
changed in Python 3000).

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

Not familiar with this construct.  If you mean "switch/case" as in C (or
some variation of same), then I absolutely agree.

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

Occasionally useful.  Not enough to put it high on my list of things I'd
like to see in Python, but I can see its utility for making *slightly*
more logical code (versus the "while True: if x: break" idiom).

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

Not sure what problems you are referring to since I rarely use that
platform and the times I have used it I haven't had any issues.  Do you
mean issues with "\"?  Why not just use "/"?

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

I don't see why valid Python syntax should be an error.  Admittedly this
quite often bites new users of Python, but there are plenty of things to
confuse newbies, so I don't know why this particular construct should be
singled out, especially when there is a perfectly valid explanation of
the resulting behavior.

> 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?

I'd agree this can be confusing.  However, like the mutable arguments
you mention previously, there is a logical explanation that suffices in
place of breaking tons of Python code.

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

I don't have a good answer for this. At least some of this is probably
pure history (len() worked on both strings and lists, and strings didn't
used to support methods, so I'm guessing it was a consistency issue back
then and it's a compatibility issue now, why it wasn't added as a method
is a good question).  As far as min() and max() <shrug>.  Perhaps to
avoid a plethora of methods on such commonly used constructs?  At what
point do you stop adding new methods to classes?  Perhaps the decision
was as simple as that.

> Thank you,
> bear hugs,
> Bearophile

That disturbs me every time I see it.


Regards,
Cliff

-- 
Cliff Wells <clifford.wells at comcast.net>