Some more notes

[bearophile]

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).
2) Adding "case var of:" can be useful.
3) "do while" (or "repeat until") can also be added, it's useful.
4) Maybe really raw strings RR"" can be added to avoid problems with
file paths on Win :-]

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

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?

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.

Thank you,
bear hugs,
Bearophile

[Istvan Albert]

bearophile wrote:

I don't know if I can really suggest improvements to the language...

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.

Istvan.

[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 <cl************@comcast.net>

[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

[David M. Cooke]

be************@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

[Cliff Wells]

On Thu, 2004-10-21 at 18:07 -0700, Jeff Shannon wrote:

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

Well, that's a matter of personal taste. Garlic is good on
*everything*.

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.

For many things this is true (and I use function lookup tables
frequently). However it doesn't as conveniently cover all use cases
that switch/case does (as it requires a function definition for each
item). 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).

Regards,
Cliff

--
Cliff Wells <cl************@comcast.net>

[Robby Russell]

On Thu, 2004-10-21 at 18:43 -0700, Cliff Wells wrote:

Well, that's a matter of personal taste. Garlic is good on
*everything*.

Mmm... roasted garlic smoothies.

--
/***************************************
* Robby Russell | Owner.Developer.Geek
* PLANET ARGON | www.planetargon.com
* Portland, OR | ro***@planetargon.com
* 503.351.4730 | blog.planetargon.com
* PHP/PostgreSQL Hosting & Development
****************************************/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQBBeGiS0QaQZBaqXgwRAqTGAKCux0K7b/tkMuLXcfriT7vtFbAwQQCglRJi
Ni1b5lmCwGnQzhCwfZjuMkk=
=Gg43
-----END PGP SIGNATURE-----

[Jeremy Bowers]

On Thu, 21 Oct 2004 17:59:41 -0700, Cliff Wells wrote:

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.

See the current thread "Python and generic programming". Those are
probably best though of as generic algorithms that can work even when
"max" isn't implemented.

Python 2.3.4 (#1, Sep 28 2004, 20:15:25)
[GCC 3.3.3 20040412 (Gentoo Linux 3.3.3-r6, ssp-3.3.2-2, pie-8.7.6)] on linux2
Type "help", "copyright", "credits" or "license" for more information.

def somenumbers(): .... yield 1
.... yield 5
.... yield 2
.... max(somenumbers()) 5

"max" isn't a method in any sense of the term that I am aware of, so it
would be wrong to put it there. In some sense, then, this is *more* pure
OO than, say, Java's "Everything is a method of some object and to hell
with the consequences!" approach.

(It seems like the more mature I get as a programmer, the more Java
disgusts me. I'm beginning to have to stretch for reasons to like it at
all; one after another they keep falling down for me. But I digress...)

[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 theequality 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

(orsome 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'dlike 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 typesmeans 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 bycreating 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)

[Peter Hansen]

bearophile wrote:

Cliff Wells:

Why not just use "/"?

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

That's not necessary in almost all cases. Windows happily(*)
accepts forward slashes in all system calls. The only place
it does not is in the *shell* (aka command.com and cmd.exe).
That means paths passed as arguments to os.system or the
Popen gang need to be normcased, but for things like open()
you don't need to bother.

-Peter

(*) There are theories that although Windows does accept
forward slashes, it does so only grudgingly.

[Steve Holden]

Peter Hansen wrote:

bearophile wrote:

Cliff Wells:

Why not just use "/"?

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

That's not necessary in almost all cases. Windows happily(*)
accepts forward slashes in all system calls. The only place
it does not is in the *shell* (aka command.com and cmd.exe).
That means paths passed as arguments to os.system or the
Popen gang need to be normcased, but for things like open()
you don't need to bother.

Having said which it's still good practice to use os.path functions to
manipulate paths for forward compatibility with Windows 2007, which will
change the separator to "^" :-)

regards
Steve
--
http://www.holdenweb.com
http://pydish.holdenweb.com
Holden Web LLC [phone]

[Josiah Carlson]

be************@lycos.com (bearophile) wrote:

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

Based on Python's use of '=' rather than ':=', I believe Guido has
already made his decision, and there has been no discussion on changing
the behavior for Python 3.0, so argument over it is a moot point.

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

As it stands, there has been more than one attempt to get case
statements into the Python language. All have been mostly fruitless
thusfar. There is a PEP: http://python.org/peps/pep-0275.html , but it
is certainly not going to make it into Python 2.4, and there has been
little discussion about its inclusion in any later versions on
python-dev.

In my opinion, the syntax-less case statement described in the PEP is
pure. That is, no new syntax is needed, but if your if/elif/else
statements are of a certain format, you gain the speed of dictionary
dispatch. I believe that any case-statement-like behavior in Python
will likely be of this sort.

Why not just use "/"?

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

Not necessary. You can mix '/' and '\\' freely on Windows when opening
files.

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

What you just said was that Python is transparent, but making it more
transparent is better. What would be more transparent? Understand that
Python is not likely to do anything that would make it more difficult to
learn or use, just for the sake of speed.

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) :-]
It would seem that copy-on-write for lists was a work-around for being
able to hash sequences, a result of only having mutable lists (no
immutable lists/tuples).

I don't remember copy-on-write with Mathematica, though it has been a
few years, I could have sworn that either append or prepend was fast
(which necessitates non-copy-on-write semantics).
"problems with globals and side effects"
The only problem is education. Once one becomes educated about the
side-effects of append/extend/etc., one rarely has problems of this kind,
as one either uses them to their advantage, or programs around what they
conceive to be a limitation. Feel free to program around them; I'm going
to stick with using mutables wherever I see fit. Please stop advocating
the removal of useful features.

"often it's also faster"
Honestly, I (and likely many others) don't care that Mathematica can be
faster. C can be faster, Java can be faster, Perl can be faster. We
use Python for varying reasons and for varying purposes.

In my case, the only thing I find Mathematica useful for is helping with
certain difficult bits of math that I have forgotten over the years.
For general programming, there are other better languages (in my opinion,
which I imagine is shared), nearly all of which are free.

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.
If you mean things like (I can't remember the exact syntax, perhaps this
is it)...

fib[a_] := If[a<3, Return[1], b=fib[a-1]+fib[a-2];fib[a]=b;Return[b]]

That does what is called memoization in computer science. Python can do
that, but you need to do so explicitly:

def fib(a, cache={}):
if a < 3:
return 1
if a not in cache:
cache[a] = fib(a-1)+fib(a-2)
return cache[a]
Ahh, dictionaries save the day. With a 'memoization decorator', it gets
easier in the general case

def memoize_single_arg(f)
cache = {}
def memoizer(arg):
if arg in cache:
return cache[arg]
return f(arg)
return memoizer

@memoize_single_arg
def fib_r(a):
if a < 3:
return 1
return fib_r(a-1)+fib(a-2)
If you are talking about something else, perhaps you should describe it.

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.

Funny, I found no mention of division operator breaking on the Python
3.0 wiki: http://www.python.org/cgi-bin/moinmoin/PythonThreeDotOh

Python 3.0 doesn't even exist yet, and likely won't for at least 6 years.
Virtually none of the suggestions you have offered thus far are even
remotely what Guido and others on python-dev have been talking about
changing for Python 3.0
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

That is the worst syntax for case statements I have ever seen.

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.

Understand that 'obj.attr = val' implies that obj is mutable. Do you
also want to remove object oriented programming in Python? Likely not,
but understand the implications for what you say.

Mutables aren't going away in Python. Stop complaining about them.

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

It is in the language reference:
http://docs.python.org/ref/augassign.html

"An augmented assignment expression like x += 1 can be rewritten as x =
x + 1 to achieve a similar, but not exactly equal effect. In the
augmented version, x is only evaluated once. Also, when possible, the
actual operation is performed in-place, meaning that rather than
creating a new object and assigning that to the target, the old object
is modified instead."
- Josiah

[David Bolen]

Peter Hansen <pe***@engcorp.com> writes:

That's not necessary in almost all cases. Windows happily(*)
accepts forward slashes in all system calls. The only place
it does not is in the *shell* (aka command.com and cmd.exe). (...)

Actually, almost all system calls. I don't have the precise list
handy, but there are some related to networking that use UNC names
that expect to see a machine name supplied as a string as "\\machine"
and will not accept "//machine".

-- David

[Peter Hansen]

David Bolen wrote:

Peter Hansen <pe***@engcorp.com> writes:

That's not necessary in almost all cases. Windows happily(*)
accepts forward slashes in all system calls. The only place
it does not is in the *shell* (aka command.com and cmd.exe). (...)

Actually, almost all system calls. I don't have the precise list
handy, but there are some related to networking that use UNC names
that expect to see a machine name supplied as a string as "\\machine"
and will not accept "//machine".

Have you verified that those calls would *not* accept
something like "\\machine/share/path/file"?

If they accept this, then I would simply argue that the \\machine
part has nothing to do with a path, other than the accident
of sharing (but doubling) the backslash that we're used to
in Windows paths. It's a machine name, not a path, similar to
how C: is a drive name, not a path, and therefore needs special
handling.

After all, you don't expect to be able to use C/ instead of C:,
and I don't think one should necessarily expect //machine to
work instead of \\machine.

This is mostly supposition/theory/wild hand-waving, however.
I don't know the reality. If you post a few of the APIs that
you mention, I can try to disprove my theory.

-Peter

[Jorgen Grahn]

On Sat, 23 Oct 2004 10:01:00 -0400, Peter Hansen <pe***@engcorp.com> wrote:

bearophile wrote:

Cliff Wells:

Why not just use "/"?
Okay, I'll use os.path.normcase to convert them.

That's not necessary in almost all cases. Windows happily(*)
accepts forward slashes in all system calls. The only place
it does not is in the *shell* (aka command.com and cmd.exe).

.... (*) There are theories that although Windows does accept
forward slashes, it does so only grudgingly.

IIRC, forward slashes have been acceptable since way back in early MS-DOS --
although someone somewhere on Usenet suggested that Microsoft have never
commited to keeping it that way.

Personally, I tend to use them -- but I accept full responsibility when/if
it breaks.

/Jorgen

--
// Jorgen Grahn <jgrahn@ Ph'nglui mglw'nafh Cthulhu
\X/ algonet.se> R'lyeh wgah'nagl fhtagn!

[Peter Hansen]

Jorgen Grahn wrote:

On Sat, 23 Oct 2004 10:01:00 -0400, Peter Hansen <pe***@engcorp.com> wrote:

That's not necessary in almost all cases. Windows happily(*)
accepts forward slashes in all system calls. The only place
it does not is in the *shell* (aka command.com and cmd.exe).

IIRC, forward slashes have been acceptable since way back in early MS-DOS --
although someone somewhere on Usenet suggested that Microsoft have never
commited to keeping it that way.

I know that there was an un(der)documented control somewhere that
allowed one to change even DOS to accept hyphens in place of
forward slashes as the "switch" indicator for command line options,
but this is the first time I've heard it suggested that even
the DOS "APIs" (I use the term loosely... the interrupt routines
barely qualify for that title :-) ) would allow forward slashes
as the Windows APIs (always?) have.

Does anyone have a reference for that?

-Peter

[Andrew Durdin]

On Sun, 24 Oct 2004 18:58:06 -0400, Peter Hansen <pe***@engcorp.com> wrote:

but this is the first time I've heard it suggested that even
the DOS "APIs" (I use the term loosely... the interrupt routines
barely qualify for that title :-) ) would allow forward slashes
as the Windows APIs (always?) have.

Does anyone have a reference for that?

Googling coincidentally brings up a c.l.py/python-list reference on
the first page, so that thread might be a good starting point:

http://mail.python.org/pipermail/pyt...er/185211.html

[Jorgen Grahn]

On Sun, 24 Oct 2004 18:58:06 -0400, Peter Hansen <pe***@engcorp.com> wrote:

Jorgen Grahn wrote:

On Sat, 23 Oct 2004 10:01:00 -0400, Peter Hansen <pe***@engcorp.com> wrote:

That's not necessary in almost all cases. Windows happily(*)
accepts forward slashes in all system calls. The only place
it does not is in the *shell* (aka command.com and cmd.exe).

IIRC, forward slashes have been acceptable since way back in early MS-DOS --
although someone somewhere on Usenet suggested that Microsoft have never
commited to keeping it that way.

I know that there was an un(der)documented control somewhere that
allowed one to change even DOS to accept hyphens in place of
forward slashes as the "switch" indicator for command line options,
but this is the first time I've heard it suggested that even
the DOS "APIs" (I use the term loosely... the interrupt routines
barely qualify for that title :-) ) would allow forward slashes
as the Windows APIs (always?) have.

Does anyone have a reference for that?

[ greps his ~/News/* ]

Newsgroups: comp.lang.c++.moderated
Message-ID: <d6**************************@posting.google.com >

MS-DOS operating system requests (e.g. open), and those of Windows, have
always, from the very first, accepted either '\' or '/' as a directory
separator, and still do today. There is really not the slightest need to
use '\' for this in a string constant.

.... followed by a lot of other interesting stuff.

/Jorgen

--
// Jorgen Grahn <jgrahn@ Ph'nglui mglw'nafh Cthulhu
\X/ algonet.se> R'lyeh wgah'nagl fhtagn!

[Peter Hansen]

Andrew Durdin wrote:

On Sun, 24 Oct 2004 18:58:06 -0400, Peter Hansen <pe***@engcorp.com> wrote:

[about even DOS system calls accepting forward slash]
Does anyone have a reference for that?

Googling coincidentally brings up a c.l.py/python-list reference on
the first page, so that thread might be a good starting point:

http://mail.python.org/pipermail/pyt...er/185211.html

Thanks! I even participated in that thread, so I must have read it
at the time. Shows how great my memory is. :-(

The summary is that ever since DOS added subdirectories (in DOS 2.0)
it has allowed either slash in the system calls. Still, this was
problematic at the command line because the default "switch" character
was "/" and not "-", and because some programs hardcoded support for
only the backslash form.

Peter

[David Bolen]

Peter Hansen <pe***@engcorp.com> writes:

Have you verified that those calls would *not* accept
something like "\\machine/share/path/file"?
Nope. Actually, I don't think that was even applicable since the call
I'm recalling took a UNC machine name but not a full path, so the only
thing in the parameter was the machine portion. Although maybe it did
include the share level.
If they accept this, then I would simply argue that the \\machine
part has nothing to do with a path, other than the accident
of sharing (but doubling) the backslash that we're used to
in Windows paths. It's a machine name, not a path, similar to
how C: is a drive name, not a path, and therefore needs special
handling.
I suppose, but I certainly saw UNC as a logical extension of path
semantics to cross the network boundary (and imagine that the choice
of \\ was logically consistent with that approach). It was a way to
layer a level "above the root" of the filesystem into a path naming
convention.
After all, you don't expect to be able to use C/ instead of C:,
and I don't think one should necessarily expect //machine to
work instead of \\machine.
Well, we clearly expect different things, which is fine, and shows the
variety in the universe :-)

At least for me, knowing that the API permitted me to use
"/path/to/file.ext" instead of "\path\to\file.ext" made it seem
logical it would permit "//machine/share/path/file.ext" for
"\\machine\share\path\file.ext". Or at least desirable.
This is mostly supposition/theory/wild hand-waving, however.
I don't know the reality. If you post a few of the APIs that
you mention, I can try to disprove my theory.

I'll see if I can find at least one again and forward it over. I seem
to recall it was while using some of the win32net wrapped APIs to
interrogate things on a remote server.

But I'm also willing to just agree that it only impacts the machine
spec and that you could consider that distinct from any path
operation. I was really just qualifying the general comment about
Win32 accepting forward slashes in all system calls.

-- David

[Steve Holden]

David Bolen wrote:

Peter Hansen <pe***@engcorp.com> writes:

Have you verified that those calls would *not* accept
something like "\\machine/share/path/file"?

Nope. Actually, I don't think that was even applicable since the call
I'm recalling took a UNC machine name but not a full path, so the only
thing in the parameter was the machine portion. Although maybe it did
include the share level.

If they accept this, then I would simply argue that the \\machine
part has nothing to do with a path, other than the accident
of sharing (but doubling) the backslash that we're used to
in Windows paths. It's a machine name, not a path, similar to
how C: is a drive name, not a path, and therefore needs special
handling.

I suppose, but I certainly saw UNC as a logical extension of path
semantics to cross the network boundary (and imagine that the choice
of \\ was logically consistent with that approach). It was a way to
layer a level "above the root" of the filesystem into a path naming
convention.

As in UNIX United, circa 1983, for example? That was essentially (IIRC)
a federated filesystem with each machine's root identified byt he
machine's name. It worked rather well for its time.

After all, you don't expect to be able to use C/ instead of C:,
and I don't think one should necessarily expect //machine to
work instead of \\machine.

Although of course it DOES worek unr Cygwin, a superior environment to
many on Windows (even though the Twisted guys appear to dislike it).
Well, we clearly expect different things, which is fine, and shows the
variety in the universe :-)

At least for me, knowing that the API permitted me to use
"/path/to/file.ext" instead of "\path\to\file.ext" made it seem
logical it would permit "//machine/share/path/file.ext" for
"\\machine\share\path\file.ext". Or at least desirable.
No use expecting logic form Microsoft, matey ;-)

This is mostly supposition/theory/wild hand-waving, however.
I don't know the reality. If you post a few of the APIs that
you mention, I can try to disprove my theory.

I'll see if I can find at least one again and forward it over. I seem
to recall it was while using some of the win32net wrapped APIs to
interrogate things on a remote server.

But I'm also willing to just agree that it only impacts the machine
spec and that you could consider that distinct from any path
operation. I was really just qualifying the general comment about
Win32 accepting forward slashes in all system calls.

-- David

if-there's-a-nit-to-be-picked-you're-in-the-right-place-ly y'rs - steve
--
http://www.holdenweb.com
http://pydish.holdenweb.com
Holden Web LLC [phone]

[bearophile]

Thank you Josiah Carlson for all your comments.

so argument over it is a moot point. [...]Please stop advocating the removal of useful features. [...]Stop complaining about them.
Well, I haven't done something bad, so I think I still have the rights
to discuss, suggest and ask things here.

In my opinion, the syntax-less case statement described in the PEP is
pure. That is, no new syntax is needed, but if your if/elif/else
statements are of a certain format, you gain the speed of dictionary
dispatch. I believe that any case-statement-like behavior in Python
will likely be of this sort.
I'm still too much ignorant of Python to understand this :-)

I could have sworn that either append or prepend was fast
On Mathematica (4.0 ore less) both append and prepends are O(n) and
quite slow, if you want to do a much faster "append" to Mathematica
lists, you have to create a nested list:
[a, [b, [c, [d]]]]
And then Flatten it. This can be hundred times faster for 10000
elements.
A group of functions to do it re-defining the heads of the structure:

Clear[h123456]
createL = h123456[];
apppendL[l_, x_] := h123456[l, x];
prepL[l_, x_] := h123456[x, l];
convertL[l_] := Flatten[l] /.
h123456 -> List;

The only problem is education. Once one becomes educated about the side-effects of append/extend/etc., one rarely has problems of this
kind,<

Okay. I'll take my time to learn more and I'll see if you are right.

Honestly, I (and likely many others) don't care that Mathematica can be faster. C can be faster, Java can be faster, Perl can be faster.
We use Python for varying reasons and for varying purposes.<

I didn't meant to offend Python... I appreciate many languages at the
same time :-)
(Comparing the speed of C with python is probably of little use, but
comparisons between Mathematica and Python can be a bit more
interesting, because they are both interpreted, etc. And maybe
Mathematica can suggest things to improve Python.)

For general programming, there are other better languages (in my opinion, which I imagine is shared), nearly all of which are free.<

I agree.

If you mean things like (I can't remember the exact syntax, perhaps this is it)...
fib[a_] := If[a<3, Return[1], b=fib[a-1]+fib[a-2];fib[a]=b;Return[b]]
Something like this is probably nicer and/or more correct:
fib[1] = 1;
fib[2] = 1;
fib[x_] := fib[x] = fib[x - 1] + fib[x - 2]

Mathematica's global hash can contain the triads: (functions, params,
value)

With a 'memoization decorator', it gets easier in the general case<
Nice :-)

If you are talking about something else, perhaps you should describe it.

I was talking about something different. I have found a page about it:
http://www.verbeia.com/mathematica/t...ks_Misc_7.html
But this page is still quite basic: with the automatic rewriting rules
and pattern matching you can do lot of things.

Funny, I found no mention of division operator breaking on the Python 3.0 wiki:

I'm sorry, I'm ignorant and I'm just confused about all this. I've
read the PEP238:
http://www.python.org/peps/pep-0238.html
And here:
http://python.fyxm.net/peps/pep-3000.html
I find:True division becomes default behavior

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

That is the worst syntax for case statements I have ever seen.<

It's just an idea, and it's similar to Delphi sintax... The PEP275
suggests something like:

switch EXPR:
case CONSTANT:
SUITE
case CONSTANT:
SUITE
...
else:
SUITE

And:Another proposed extension would allow ranges of values (e.g. case 10..14: ...)

I've just used the Python range(a,b) to express the half-open
interval... But probably the Pascal a..b syntax is better.

Understand that 'obj.attr = val' implies that obj is mutable. Do you
also want to remove object oriented programming in Python? Likely not,but understand the implications for what you say.

I see.

A bear hug and thank you again,
Bearophile

[Josiah Carlson]

be************@lycos.com (bearophile) wrote:

Thank you Josiah Carlson for all your comments.

so argument over it is a moot point. [...]

Please stop advocating the removal of useful features.

[...]

Stop complaining about them.

Well, I haven't done something bad, so I think I still have the rights
to discuss, suggest and ask things here.

Oh, yes, feel free to complain about features that are being used by
literally thousands (perhaps hundreds of thousands) of people today.
Maybe tomorrow we'll start considering removing something so useful as
list mutation, dictionary mutation, object mutation, etc.

Or maybe not.

In my opinion, the syntax-less case statement described in the PEP is
pure. That is, no new syntax is needed, but if your if/elif/else
statements are of a certain format, you gain the speed of dictionary
dispatch. I believe that any case-statement-like behavior in Python
will likely be of this sort.

I'm still too much ignorant of Python to understand this :-)

I'll quote the section of the PEP:

It should be possible for the compiler to detect an
if-elif-else construct which has the following signature:

if x == 'first':...
elif x == 'second':...
else:...

i.e. the left hand side always references the same variable,
the right hand side a hashable immutable builtin type. The
right hand sides need not be all of the same type, but they
should be comparable to the type of the left hand switch
variable.
Immutables are anything with type of: int, long, str, unicode, tuple;
though tuples must contain only other immutables to still be immutable.

I could have sworn that either append or prepend was fast

On Mathematica (4.0 ore less) both append and prepends are O(n) and
quite slow, if you want to do a much faster "append" to Mathematica
lists, you have to create a nested list:
[a, [b, [c, [d]]]]
And then Flatten it. This can be hundred times faster for 10000
elements.
A group of functions to do it re-defining the heads of the structure:

That was it. Well, in Python you no longer need to create recursive
structures. Just use list.append(), it is fast (you don't need to rely
on a Mathematica mis-feature *wink*). If you wanted to prepend instead,
just remember to list.reverse() it before you are done.

The only problem is education. Once one becomes educated about the
side-effects of append/extend/etc., one rarely has problems of this
kind,<

Okay. I'll take my time to learn more and I'll see if you are right.

Think of it like this. You had likely been reassigning lists to
themselves in order to repeatedly append or prepend to a Mathematica
list because standard appends and prepends were slow. Now you don't
have to. You were doing explicit mutation before, now you are doing
implicit mutation without need to flatten. Will the wonders never cease?

Honestly, I (and likely many others) don't care that Mathematica can
be faster. C can be faster, Java can be faster, Perl can be faster.
We use Python for varying reasons and for varying purposes.<

I didn't meant to offend Python... I appreciate many languages at the
same time :-)

Ahh, but you said was, "hey, this super duper language does things like
this, wouldn't it be great if Python did this too?"

Understand that people have been building Python for only 2 years
younger than Mathematica. It gained some features and experience of C,
Modula and other languages which are far older than Mathematica, and
didn't limit the user to immutable types (thank god).

(Comparing the speed of C with python is probably of little use, but
comparisons between Mathematica and Python can be a bit more
interesting, because they are both interpreted, etc. And maybe
Mathematica can suggest things to improve Python.)
How would knowing about Mathematica help Python? Mathematica is
closed-source, commercial, and proprietary; you can't even look at the
guts for implementation details. We would be better off looking at
non-commercial implementations of Python, Perl, Lisp, Tcl, etc. for that.

And as for language features; it is of my opinion that the Mathematica
language leaves something to be desired, and I would prefer the
'features' of Mathematica language to be left there.

If you mean things like (I can't remember the exact syntax, perhaps this is it)...
fib[a_] := If[a<3, Return[1], b=fib[a-1]+fib[a-2];fib[a]=b;Return[b]]

Something like this is probably nicer and/or more correct:
fib[1] = 1;
fib[2] = 1;
fib[x_] := fib[x] = fib[x - 1] + fib[x - 2]

If the code runs, it is correct. Is it in the Mathematica style? No.
I haven't written Mathematica code in around 3 years.

Mathematica's global hash can contain the triads: (functions, params,
value)
Hrm...lemme see...

global_hash = {}

def memoize(fcn):
def call(*args):
if (fcn, args) not in global_hash:
global_hash[(fcn, args)] = fcn(*args)
return global_hash[(fcn, args)]
return call

@memoize
def foo(arg1, arg2):
...

@memoize
def goo(arg1, arg2):
...
Goodness, so can Python. But it is not necessary, my original
declaration used individual dictionaries for each memoized function.

If you are talking about something else, perhaps you should describe
it.

I was talking about something different. I have found a page about it:
http://www.verbeia.com/mathematica/t...ks_Misc_7.html
But this page is still quite basic: with the automatic rewriting rules
and pattern matching you can do lot of things.

In the C/C++ world, that is called polymorphism. You can do
polymorphism with Python, and decorators may make it easier...
@accepts(int, str, int, unicode)
def foo(a, b, c, d):
pass

@accepts(str, int)
def foo(a, b):
pass
With a properly implemented accepts decorator (I believe one is floating
around there somewhere, I would give one, but it is getting late, and I
need to wash dishes and shave).

Funny, I found no mention of division operator breaking on the Python

3.0 wiki:

I'm sorry, I'm ignorant and I'm just confused about all this. I've
read the PEP238:
http://www.python.org/peps/pep-0238.html
And here:
http://python.fyxm.net/peps/pep-3000.html
I find:

True division becomes default behavior
If you want floor division on integers, you can use the floor division
operator: // *gasp*

I believe that the standard division operator behavior on integers was
considered a misfeature in prior Python versions, a remnant of Python's
C roots, which is why it was slated for removal in 2.4, with documented
"it is going away" in the documentation for Python 2.3 .

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

That is the worst syntax for case statements I have ever seen.<

It's just an idea, and it's similar to Delphi sintax... The PEP275
suggests something like:

Just because something fits with another language, doesn't mean that it
is even remotely Pythonic.

A bear hug and thank you again,

Gah, no more hugs. Please.
- Josiah