Some more notes

[bearophile]

Istvan Albert:

>No you can't. Your suggestions are  driven by nothing else
>but your desire to make  Python resemble Pascal since
>that is the language that you are accustomed to.

You are right, I'm just a newbie in Python, and there are other
languages than I know a bit better, like Delphi.
Like natural languages, computer languages have a personal "soul"
(grammar core, etc), but they also keep copying other languages, to
improve, etc.
-----------

Cliff Wells:

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

Right, still, from a mathematical/formal point of view, Pascal syntax
is better here :-]


>Use string interpolation.

Okay, I'll learn to use it more often.


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

Yes, it's the Delphi/Pascal version of it.


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

I agree, it's not essential, but it can be useful :-)


>Why not just use "/"?

Okay, I'll use os.path.normcase to convert them.


>but there are plenty of things to confuse newbies,

Reducing non-obvious, magic or not-standard behaviours is quite
necessary inside a language, it helps non-newbies too, making the
language more conceptually transparent. Sometimes such non-standard
behaviours can be useful to improve language speed or other things,
but they have to reduced to the minimum possible. Python often prefers
transparency, even when there are many (worse and more opaque, but
maybe faster) ways to do things. This is positive for a hi-level
language. So making a hi-level language like Python more transparent
can be a way to improve it :-)
Mathematica is more transparent than Python (its hashes can process
everything, it has just a mutable list type and not tuples, assignment
copies the object, and it's more functional so there are much less
problems with globals and side effects, etc. but it can still be used
with imperaive programming) and often it's also faster, but it's far
from free (and its can be worse to do "real" programming, etc) :-]
Note: Mathematica can be used with a quite powerful "pattern matching
programming", I don't know if such thing (or a subset of it) can be
useful to add to Python.


>there is a logical explanation that suffices in
>place of breaking tons of Python code.

There are logical explanations for everything (because everything must
be executed by the processor), but for humans some things are more
logical than others :-)
Python 3.0 already breaks lots of things, even division operators, so
that's the best occasion to improve/change/fix things.
-----------

Jeff Shannon:

>using a dict of functions is (IMO) a better and cleaner
>way of implementing the same idea.

I don't know... The Case syntax can be something like:

Case <name>:
    1: DoSomething1
    range(2,23): DoSomething2
    else: DoSomething3

(Etc. There are many other possibilities, like the Switch, etc).


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

Okay... I'll use the 'while 1: if cond: break'


>Except that having mutable types be shared this way can be a useful
feature.<

It looks more dangerous than useful. And assignments of non-mutable
types can still be accepted.


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

Okay, the manual I've read wasn't clear enough about this :-)


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

Okay. Thank you for the info. I still prefer Python to Ruby (a more
pure OO language, I think).


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

I agree, sometimes adding things is positive, and sometimes it's not
good.
Things have to be discussed by people expert on the language (and I'm
a newbie), but I am here to learn too :-)
("pattern matching programming" can be one of such things.)
-----------

Cliff Wells:

>While it's also true that if/elif/else can be used instead for
>these other cases, I personally find switch/case far cleaner looking
>(when there are more than five or six conditions to test).
>[...]
>Also, I'd be reluctant to claim that the dictionary lookup is cleaner
>(it looks more cluttered to my eye), but rather, more flexible (items
>can be dynamically added to the list).

I agree.
-----------

David M. Cooke:

>Also, adding a , to the end of the print statement will suppress the
>newline (although, not the space between the two calls).

Right, I've forgot it :-)


>"can be" is the operative phrase here. It's not necessary.<

Well, OOP and lots of other things (inside Python too) aren't
necessary. I was discussing mostly about things that can be useful.


>Chained if/elif/elif works fine for small cases; for larger,
>you should probably use a dict, or rewrite to use a class.

Uhm... I'll try with the dictionary.


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

I'll use it, but I think it's really ugly. It looks like the old
spaghetti code with GOTOs :-]

Thank you for the answers and explanations,
a handshake to Cliff and bear hugs to everybody else,
bearophile
(remove HUGS if you want to mail me directly)