Typed Python?

[Thomas Reichelt]

Moin,

short question: is there any language combining the syntax, flexibility and
great programming experience of Python with static typing? Is there a
project to add static typing to Python?

Thank you,

--
greetz tom

[Jacek Generowicz]

Ville Vainio <vi***@spammers .com> writes:

Chain> The code is much better structured in Scheme than in
Chain> Python. It is a big mistake to assume that Python displays
Chain> any readability. The one

So true.

(set! x 10)

Is so much more readable than

x=10

Well, that rather depends on what you are used to. But it is
undeniably true that the former is better structured.

[François Pinard]

[Ville Vainio]

[Chain Lube]

The code is much better structured in Scheme than in Python. It is a
big mistake to assume that Python displays any readability.

With all due respect, someone that thinks [...]

Flamatory comments are not really my bag. :-)

But as someone who much liked both Scheme and Python, let me stress a
few aspects where Python attracted me more than Scheme.

The most important one is the bulk of library code which comes standard
with Python, but which has to be collected or rewritten in Scheme, not
being part of the standard.

Another is that, despite Scheme attempts to be minimalist (something
that I much like), Python is -- or at least once was! :-) -- more on the
side of having only one way of doing things. Two examples come to mind.

Scheme has three ways to write a conditional statement: `(cond ...)',
`(if ...)' and `(case ...)'. All have virtues and drawbacks, and I often
switch between the three, depending on my code, and the edits I do on my
code, so it stays best at all time. This is annoying.

Scheme has many ways for looping while changing local variables, some
of which are less nice and which I did not use much, I'm not even
discussing them. The `(let loop ...)' construct is useful for writing
tail-recursive loops without creating a flurry of little separate
functions, but it is often clearer writing destructive `(set! ...)'
instead of always being tail-recursive, even if tail-recursivity
often yields more efficient compilation. When you mix assignment and
tail-recursion, the amount of solutions for a piece a code is near
exponential in the number of variables. I found this annoying, too.

Bindings, conditionals and loops are very basic and ubiquitous in any
programming language, and Python got these relatively simpler than
Scheme. Scheme may be minimalist overall, but because of the frequency
of the above constructs in a program, the minimalism is not so apparent.

P.S. - On the other side, in those rare circumstances one needs
continuations, Scheme offers them very easily, while there are rather
painful to simulate in standard Python. Also, there once was a notable
distance between Scheme and Python about lazy evaluation and closure
construction, but more recent versions of Python offer fairly tractable,
almost easy approaches for such things.

--
François Pinard http://www.iro.umontreal.ca/~pinard

[Peter Maas]

Jacek Generowicz schrieb:

(set! x 10)

Is so much more readable than

x=10

Well, that rather depends on what you are used to. But it is
undeniably true that the former is better structured.

You mean the expression

"(set! x 10)" is_better_struc tured_as "x=10"

is true? How is is_better_struc tured_as defined? :)

Mit freundlichen Gruessen,

Peter Maas

--
-------------------------------------------------------------------
Peter Maas, M+R Infosysteme, D-52070 Aachen, Tel [phone]
eMail 'cGV0ZXIubWFhc0 BtcGx1c3IuZGU=\ n'.decode('base 64')
-------------------------------------------------------------------

[Peter Hansen]

Peter Maas wrote:

Jacek Generowicz schrieb:

(set! x 10)

Is so much more readable than
x=10

Well, that rather depends on what you are used to. But it is
undeniably true that the former is better structured.

You mean the expression

"(set! x 10)" is_better_struc tured_as "x=10"

is true? How is is_better_struc tured_as defined? :)

I think you mean "is_better_stru ctured_than", not "_as".

What you wrote, if true, would mean that Jacek meant
"x=10" was the better structured one...

(Anyway, arguing over "structured " is silly. Clearly "more readable"
rules. ;-)

-Peter

[Reinhold Birkenfeld]

Peter Maas wrote:

Jacek Generowicz schrieb:

(set! x 10)

Is so much more readable than

x=10

Well, that rather depends on what you are used to. But it is
undeniably true that the former is better structured.

You mean the expression

"(set! x 10)" is_better_struc tured_as "x=10"

is true? How is is_better_struc tured_as defined? :)

Hey, it is

(is_better_stru ctured_as "(set! x 10)" "x=10")

Be consistent!

Reinhold

--
Wenn eine Linuxdistributi on so wenig brauchbare Software wie Windows
mitbrächte, wäre das bedauerlich. Was bei Windows der Umfang eines
"kompletten Betriebssystems " ist, nennt man bei Linux eine Rescuedisk.
-- David Kastrup in de.comp.os.unix .linux.misc

[Arthur]

On 05 Jul 2004 13:24:08 +0200, Jacek Generowicz
<ja************ **@cern.ch> wrote:

Ville Vainio <vi***@spammers .com> writes:

Chain> The code is much better structured in Scheme than in
Chain> Python. It is a big mistake to assume that Python displays
Chain> any readability. The one

So true.

(set! x 10)

Is so much more readable than

x=10

Well, that rather depends on what you are used to. But it is
undeniably true that the former is better structured.

Well it does seem to me that the subtleties of assignment in Python is
an excellant example of where its "easiness" is more apparent than
real.

The notice of which takes nothing away from Python.

But does work toward dispute of certain discriptions of it.

Art

[Ville Vainio]

>>>>> "Jacek" == Jacek Generowicz <ja************ **@cern.ch> writes:

Jacek> Ville Vainio <vi***@spammers .com> writes:

Only the academics seem to think Scheme is easier to learn
than, say Python or even C. Students often disagree.

Jacek> Sounds great; I bet it makes a lot of Python fans feel warm
Jacek> and fuzzy inside. Unfortunately the claim is completely
Jacek> unfounded.

Jacek> You should take a look at what the TeachScheme people have
Jacek> been doing, and what they seem to be achieving.

I took a look at the TeachScheme website. One example program in
particular caught my eye in http://www.teach-scheme.org/Talks/.

the Scheme version:

( define ( guest name list )
( cond
( ( empty? list ) ?no )
( ( equal? name ( first list )) ?yes )
( else ( guest name ( rest list )) ) ))
C/C++:

------

#include <stdio.h>
typedef struct listCell * list;
struct listCell {
int first;
list rest;
};
bool guest (int x, list l) {
if (l == NULL)
return false;
else if (x == (l -> first))
return true;
else
return guest (x, l -> rest);
}
int main (int argc, char ** argv) {
list l1, l2, l3 = NULL; int x;
l1 = (list) malloc (sizeof (struct listCell));
l2 = (list) malloc (sizeof (struct listCell));
l2 -> first = 3; l2 -> rest = l3;
l1 -> first = 2; l1 -> rest = l2;
scanf ("%d", &x);
printf ("%d\n", member (x, l1));
}
----------

So they implement a linked list data type in C/C++ version, and use
the native/natural linked list (i.e. just a list) in Scheme. That's
kinda weasely road to take, don't you think? Especially if they use
this as marketing material for non-techies...

And here's the equally weaselish Python version, which they
unsurprisingly don't include:

-----------
def guest(name, list):
return name in list
-----------

I'd like to see an example program, targeted at, say, 12 year olds,
where Scheme beats Python in simplicity (one that is not a compiler,
mind you ;-).

--
Ville Vainio http://tinyurl.com/2prnb

[Oliver Fromme]

Donn Cave <do**@drizzle.c om> wrote:

I haven't tried it, but Nice is a Java based language with a more
sophisticated type system than Java, and a few extra conveniences.

http://nice.sourceforge.net/

It doesn't appear to have type inference, which so far as I know
may be exclusive to functional languages, [...]

Just for the record, there's a dialect of C called Cyclone,
which supports type-inference (although with some limitations).
Since it's derived from C, it's not a functional language, but
it has grown quite some features typically found in functional
languages.

http://www.eecs.harvard.edu/~greg/cyclone/index.html

There's a mirror at AT&T:

http://www.research.att.com/projects/cyclone/

Best regards
Oliver

--
Oliver Fromme, Konrad-Celtis-Str. 72, 81369 Munich, Germany

``All that we see or seem is just a dream within a dream.''
(E. A. Poe)

[Erik Max Francis]

Oliver Fromme wrote:

Just for the record, there's a dialect of C called Cyclone,
which supports type-inference (although with some limitations).
Since it's derived from C, it's not a functional language, but
it has grown quite some features typically found in functional
languages.

http://www.eecs.harvard.edu/~greg/cyclone/index.html

Its extra pointer qualification features are interesting. Thanks for
bringing this to my attention, I don't think I'd heard of it before.

--
__ Erik Max Francis && ma*@alcyone.com && http://www.alcyone.com/max/
/ \ San Jose, CA, USA && 37 20 N 121 53 W && AIM erikmaxfrancis
\__/ If I had another face, do you think I'd wear this one?
-- Abraham Lincoln

[Christophe Cavalaria]

Ville Vainio wrote:

>> "Jacek" == Jacek Generowicz <ja************ **@cern.ch> writes:

C/C++:

------

#include <stdio.h>
typedef struct listCell * list;
struct listCell {
int first;
list rest;
};
bool guest (int x, list l) {
if (l == NULL)
return false;
else if (x == (l -> first))
return true;
else
return guest (x, l -> rest);
}
int main (int argc, char ** argv) {
list l1, l2, l3 = NULL; int x;
l1 = (list) malloc (sizeof (struct listCell));
l2 = (list) malloc (sizeof (struct listCell));
l2 -> first = 3; l2 -> rest = l3;
l1 -> first = 2; l1 -> rest = l2;
scanf ("%d", &x);
printf ("%d\n", member (x, l1));
}
----------

Some people need to be shot ! This is not C or C++ code, it is C code and
considered very bad C++ code. No wonder that C++ get so much bad press with
such slander.

The *real* C++ version :

#include <list>
#include <string>
#include <algorithm>

using namespace std;

bool guest(string m, list<string> l)
{
return find(l.begin(), l.end(),m) != l.end();
}

// And now the testing code

#include <iostream>

void try_find(string m, list<string> l)
{
if(guest(m,l))
cout << "Found " << m << '\n';
else
cout << "Missing " << m << '\n';
}

int main()
{
list<string> l;
l.push_back("Hi ");
l.push_back("Th ere");
l.push_back("Yo u");

try_find("Hi",l );
try_find("Yes", l);
try_find("You", l);
}