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,

 

[Sam Jervis]

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,

You might want to take a quick look at Haskell, although I think it is
still largely an academic's language. A quick roundup of
similarities/differences:

Haskell is strongly typed but fully supports polymorphism
Haskell is functional rather than imperative
Haskell uses significant whitespace, like Python

Website:

http://www.haskell.org/

HUGS is a good interpreter for Haskell if you want to try it out.

Sam

 

[Jarek Zgoda]

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?

Static typing would destroy all fun in Python. Eventually we would end
with ObjectPascal-like language, just running in VM and not compiled.

Maybe Borland's Delphi for .NET is what you look for?

 

[Ville Vainio]

Jarek> Static typing would destroy all fun in Python. Eventually
Jarek> we would end with ObjectPascal-like language, just running
Jarek> in VM and not compiled.

Using a type inference system, it wouldn't. The code would "flow" like
it does now. Some corners of the code would probably benefit from
having explicit declarations to smooth up the process, but most of the
code could look exactly the way it does now.

 

[Ville Vainio]

Sam> You might want to take a quick look at Haskell, although I
Sam> think it is still largely an academic's language. A quick
Sam> roundup of

I think the Haskell programming experience is totally different from
the Python experience, because of the functional approach. This also
implies that there is about a zero possibility of introducing the
language in commercial projects because of peer opposition and the
"academic" flavor of the language (no libraries, absent/elitist
community that doesn't even need libraries).

The Lisp programming experience might be more pythonic, but the syntax
(or the absence of it) kinda ruins it too. But then again, Lisp is
dynamically typed but with type declarations.

 

[Michel Claveau/Hamster]

Python + Ctypes ?

 

[Thomas Reichelt]

Jarek> Static typing would destroy all fun in Python. Eventually
Jarek> we would end with ObjectPascal-like language, just running
Jarek> in VM and not compiled.

Using a type inference system, it wouldn't. The code would "flow" like
it does now. Some corners of the code would probably benefit from
having explicit declarations to smooth up the process, but most of the
code could look exactly the way it does now.

Yes, type inference, for example, would be a great addition to Python! I
took a look at OCaml a while ago, but as I am not very addicted to pure
functional programming, it wasn't my thing. Also, compared to Python, the
number of libraries is small, and the support for UI is cumbersome... but
type inference is great.

What I would have in mind is a flag, or maybe language directive, that
switches static typing via type inference on. Of course, some of the
dynamic features of Python would have to be disabled then, but it would
result in better error-checking, and perhaps bytecode compilable to native
code, resulting in faster execution.

 

[John Roth]

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?

I believe that it's on Guido's wish list, at least as an option.
At one time there was a types sig that was looking into it,
but I don't know of its current status. It got bogged down
and didn't deliver anything.

There are a couple of projects that have done some kind
of type inference in Python. You might check out Bicycle
Repair Man, which has a type inference engine that it uses
to help in refactoring. I've also heard of another academic
project that was supposed to release code sometime this
summer, but the name escapes me.

There are a number of places that would have to be cleaned
up to make type inference work well. The <string>.find() method
is practically a poster child for a method that would give any
type inference mechanism fits. It returns an integer, right?
Wrong. It's supposed to return either an index into the string
(a separate type) or an indication it didn't find one. However,
the result sometimes evaluates to False when it found one,
always evaluates to True when it didn't, and is a valid index
even when it didn't find a match.

A <string>.findall() method that returned a list of all
matches is much cleaner: it evalutes to false when the
list is empty (no matches), it never returns something
that looks like an index for a non-match, and it's
compatible with the for statement.

John Roth

 

[Marek =?iso-8859-2?Q?Baczy=F1ski?=]

Dnia Sat, 03 Jul 2004 10:56:24 +0200, Thomas Reichelt napisa³(a):

What I would have in mind is a flag, or maybe language directive, that
switches static typing via type inference on. Of course, some of the
dynamic features of Python would have to be disabled then, but it would
result in better error-checking, and perhaps bytecode compilable to native
code, resulting in faster execution.

Sounds just like Starkiller+Psyco combo (Even though Starkiller is not
released yet AFAIK.)

 

[Harald Massa]

Haskell is strongly typed but fully supports polymorphism

Haskell is functional rather than imperative
Haskell uses significant whitespace, like Python

and it is at least 3 days behind Python. At least in Sweden, @ Chalmers ...
EuroHaskell was just behind EuroPyhton

 

[Donn Cave]

Quoth Thomas Reichelt <[email protected]>:
| 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?

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, but it does have the
"contract", "interface" etc. stuff that seems to be needed with
statically typed object oriented languages. I can't tell right
away from the web pages, but it looks like subtype polymorphism
is all you get - so for example in a context that expects a File,
you can't show up with something that was just built in the shape
of a File, it has to be a subclass of File. Again as usual with
object oriented languages. But the type system certainly looks
more powerful, the language looks more expressive whatever that
means, and the Java implementation means lots of libraries.

Haskell is a conundrum. Not many known users outside of academia,
some kind of intractable problems that seem likely to keep it that
way, but it has deep roots and has become the archetypal functional
programming language with a supportive community that shows no signs
of withering away. And after all it's an inspiring language to use.
Not like the other relatively popular functional programming language
these days, rather the opposite.

Donn Cave, (e-mail address removed)

 

[chain_lube]

Moin,

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

Run, run, and run. Do not look back. And for heavens sake: use
"Bigloo".

I was not in dire need for looking back to Python any longer once I
encountered Bigloo:

- types
- object system
- pattern matching
- exception handling
- keywords
- Bee (development environment)
- excellent foreign function interface to C: Bigloo speaks C indeed!
- Java backends (automatically generated from Scheme code)
- .Net integration
- excellent and very stable high perfromance compiler for speed;
performance is on par with OCaml
- nearly on every platform

- and do not forget: though, there are types but you /always/ will get
the option of using Bigloo as it were an ordinary Scheme with all the
freedom so to speak! Types will never be your stumbling block as in
Clean or Haskell for example.


Fensterbrett
PS: Note: with srfi-1 you get a lot of typical functional programming
support! Hey man you can even download the srfi-functions for "lazy
streams".

 

[Thomas Reichelt]

Dnia Sat, 03 Jul 2004 10:56:24 +0200, Thomas Reichelt napisa?(a):


Sounds just like Starkiller+Psyco combo (Even though Starkiller is not
released yet AFAIK.)

Starkiller sounds very interesting... I am sure it is worth trying when it's
released!

 

[Thomas Reichelt]

Run, run, and run. Do not look back. And for heavens sake: use
"Bigloo".

I was not in dire need for looking back to Python any longer once I
encountered Bigloo:

[...]

Thanks, but... Scheme... I hate parens

 

[Paul Prescod]

Jarek> Static typing would destroy all fun in Python. Eventually
Jarek> we would end with ObjectPascal-like language, just running
Jarek> in VM and not compiled.

Using a type inference system, it wouldn't. The code would "flow" like
it does now. Some corners of the code would probably benefit from
having explicit declarations to smooth up the process, but most of the
code could look exactly the way it does now.

I don't really believe that is true. Many Python functions have
extremely complex type signatures. In a type inferenced language you
don't type in type signatures everywhere but you do define have to
design your types with the inferencer in mind. This would be a big
change in Python programming style.

To put it another way: Jarek complains that static typing would destroy
the "fun". I think he means Python's flexibility. A type inferencer
removes the need to declare types but a statically type-inferenced
language is still statically typed. It will still be strict about type
usage.

Paul Prescod

 

[chain_lube]

Thanks, but... Scheme... I hate parens

Do not take the following patronizing. But why to you believe that you
hate parens?

You put yourself into big troubles if you miss the opportunity of
Bigloo. I haven't counted parens or had to cope with it in any time I
can think of since parens will never come in your way. Why should
parens interfere with your way?

The code is much better structured in Scheme than in Python. It is a
big mistake to assume that Python displays any readability. The one
and only thing, provided I were a teacher, which I would never use for
annoying school people in introductory courses would be Python for its
huge learning curve and its messy behavior.

You should give Scheme a try.

Fensterbrett

 

[Thomas Reichelt]

Do not take the following patronizing. But why to you believe that you
hate parens?

You put yourself into big troubles if you miss the opportunity of
Bigloo. I haven't counted parens or had to cope with it in any time I
can think of since parens will never come in your way. Why should
parens interfere with your way?

Because the syntax of Scheme, Lisp etc. is strange to me. I don't speak
lightly, 'cause I have tried some of the dialects (although it was a long
time ago). It was not that I couldn't write correct code in it, but after
implementing some of my "test" programs that I write in every new language
I try, I looked at them and thought "O my god, what a mess". Guess that
it's my brain fooling me...

The code is much better structured in Scheme than in Python. It is a
big mistake to assume that Python displays any readability. The one
and only thing, provided I were a teacher, which I would never use for
annoying school people in introductory courses would be Python for its
huge learning curve and its messy behavior.

This is coming close to trolling, IMHO.

 

[Arthur]

This is coming close to trolling, IMHO.

Perhaps it is.

But as an advocate of the potential of Python in education, it is to
me not unitneresting to hear, and I do not totally discount the point
of view.

Learning curve, messiness aside - there is little question to be that
the Scheme community has approached the issue of the role of
programming education, as an element of an *education* in general, in
more mature, sophisticated, and honest ways then I have generally
noticed in the Python community.

I recently reread the introduction to How to Design Programs, which is
a book that is part of the TeachScheme project.

http://www.htdp.org/2003-09-26/Book/curriculum-Z-H-4.html#node_chap_1

It expresses in a few paragtraphs some of the inescapable
fundamentals:

"Becoming and being a programmer is fun, but it is not easy."

"Programming a computer requires patience and concentration. Only
attention to minute details will avoid frustrating grammatical
mistakes."

The obvious.

Much of what you hear in the Python world regarding education sounds
different.

"Python is easy, and learning to program with Python is easy."

Often implying that it is only that others are making the effort in
languages other than Python that makes it seem otherwise.

Which is wonderful to hear, and would be worth saying, if saying it
would make it true.

Of course, it doesn't.

Of course, its nonsense.


Art

 

[Ville Vainio]

Chain> You put yourself into big troubles if you miss the
Chain> opportunity of Bigloo.

I agree. Should I also forward this message to 10 other people to
dodge the impending doom?

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

Chain> annoying school people in introductory courses would be
Chain> Python for its huge learning curve and its messy behavior.

With all due respect, someone that thinks python has a huge learning
curve must be a little bit on the slow side, cognition-wise.

 

[Ville Vainio]

Arthur> "Python is easy, and learning to program with Python is
Arthur> easy."

Arthur> Often implying that it is only that others are making the
Arthur> effort in languages other than Python that makes it seem
Arthur> otherwise.

Arthur> Which is wonderful to hear, and would be worth saying, if
Arthur> saying it would make it true.

Arthur> Of course, it doesn't.

Arthur> Of course, its nonsense.

Well, many of us just think it's true. Only the academics seem to
think Scheme is easier to learn than, say Python or even C. Students
often disagree.