Optional Static Typing

[bearophileHUGS]

Adding Optional Static Typing to Python looks like a quite complex
thing, but useful too:
http://www.artima.com/weblogs/viewpost.jsp?thread=85551

I have just a couple of notes:

Boo (http://boo.codehaus.org/) is a different language, but I like its
"as" instead of ":" and "->", to have:
def min(a as iterable(T)) as T:
Instead of:
def min(a: iterable(T)) -> T:


Sometimes it can be useful to mix parts with static typing and parts
without it in the same module (because dynamic typing is very useful
sometimes), but some other times you want to be sure to have a full
typed and checked module. So maybe a kind of compiler directive (like
the # used to define encoding) can be used to define a module fully
typed and fully checked by a pychecker-like. (A module with static
typing can be very useful for a "true" python compiler too.)
Bear hugs,
bearophile

 

[Doug Holton]

Adding Optional Static Typing to Python looks like a quite complex
thing, but useful too:
http://www.artima.com/weblogs/viewpost.jsp?thread=85551

Thanks for pointing out that article by Guido van Rossum. Looks like it
just came out today. It is something that may be added to Python 3.0:
http://www.python.org/moin/Python3.0

Sometimes it can be useful to mix parts with static typing and parts
without it in the same module (because dynamic typing is very useful
sometimes), but some other times you want to be sure to have a full
typed and checked module.

The closest option right now in CPython is to use Pyrex.
http://nz.cosc.canterbury.ac.nz/~greg/python/Pyrex/

> Boo (http://boo.codehaus.org/) is a different language, but I like its
> "as" instead of ":" and "->", to have:
> def min(a as iterable(T)) as T:
> Instead of:
> def min(a: iterable(T)) -> T:

Right, you're first example is how Boo does it, and the 2nd is how Guido
proposed to do it in Python 3.0.

Boo flips the problem around. Instead of optional static typing,
everything is statically typed by default (but with type inference so
you do not always need to explicitly declare the type), and it has
optional runtime typing that works like python's ("duck typing").
http://svn.boo.codehaus.org/trunk/tests/testcases/integration/duck-2.boo?view=auto
http://svn.boo.codehaus.org/trunk/examples/duck-typing/XmlObject.boo?view=auto
http://svn.boo.codehaus.org/trunk/tests/testcases/integration/duck-5.boo?view=auto
http://boo.codehaus.org/Duck+Typing

And there are some disadvantages to doing it this way. It means Python
is more flexible to use than Boo, as I stated a couple months back:
http://groups-beta.google.com/group...ader=1&q=boo+python-like#doc_7a51cdc9ffecbc72

 

[John Roth]

Adding Optional Static Typing to Python looks like a quite complex
thing, but useful too:
http://www.artima.com/weblogs/viewpost.jsp?thread=85551

One of the comments on Artima asks a rather profound
question: static typing is an answer. What's the question?
(That's a paraphrase.)

The answer that everyone seems to give is that it
prevents errors and clarifies the program.

I'm not convinced that it's all that effective at either objective.
My viewpoint on this is
that of someone who generally uses test first programming
(as in Test Driven Development or Extreme Programming).
Many of the supposed advantages simply aren't there
when you go to the discipline of writing a test and then
writing exactly the code needed to make the test pass, and
not one keystroke more.

Most of the kinds of error that static typing is supposed
to catch simply don't persist for more than a minute when
you do test driven development.

This isn't to say TDD is the be-all and end-all of
correctness. Formal methods and formal inspections
both have very good reputations. In fact, the technique
with the best reputation is embodied in a sign that was
on the wall of every office of the old IBM: Think!

So let's look a bit deeper. As far as I remember, static
typing came out of the formal methods work in the '70s
by people like Djikstra, Hoar and Wirth (to name only
a few.) The thing is, if you properly use the formal program
derivation methods they advocated, then you don't need
it: your program will be as correct as it's possible to get
short of your being promoted to godhood.

So the conclusion here is that static typing is an attempt
to make programming safe for people that shouldn't be
programming in the first place. This may sound a bit
cynical, but most real uber-programmers have either
Lisp or Smalltalk in their backgrounds, and
frequently both one. Neither of those languages
have static typing, and they simply don't need it.

So if the problem is reducing errors, then maybe
we should be working on the places where errors
show up.

Another point that's sometimes raised is that it's
useful to provide type information via reflection.
I used to think that was a valid concern until I
started work on PyFit. I had to put a rather
simplistic metadata facility into the program to
substitute for not having type information, and
I found that it was incredibly useful for other
things that you can't get from reflection on
type data.

John Roth

 

[Rocco Moretti]

One of the comments on Artima asks a rather profound
question: static typing is an answer. What's the question?
(That's a paraphrase.)

The answer that everyone seems to give is that it
prevents errors and clarifies the program.

<shrug> It might just be me, but I thought it was to simplify code
analysis and compilation. (That is, for the use of static typing in
general, not for Python in particular.)

Looking at C, it's doubtful error prevention and program clarification
was a serious objective in the static typing system. It's more
reasonable to conclude that C is statically typed because it allows the
compiler to more easily allocate 1 vs 2 vs 8 bytes for a particular
variable, and to make sure the proper addition opcodes get put down.

Now whether this would be useful for Python is an open question.

Many of the supposed advantages simply aren't there
when you go to the discipline of writing a test and then
writing exactly the code needed to make the test pass, and
not one keystroke more. ....
This isn't to say TDD is the be-all and end-all of
correctness.

Right. And unit tests don't do anything for people who don't use them.
The question is, should Guido state "TDD is the one true way to program
in Python.", or should concessions be made in the language design for
those who don't "drink the TDD Kool-aide".

So the conclusion here is that static typing is an attempt
to make programming safe for people that shouldn't be
programming in the first place.

I rebut it thusly: "elitist bastard." <wink and a half>

One of the draws of Python is that it's welcoming to newcomers and
programmers of all talents. You don't have to be an "uber-programmer" to
use it and use it well. Should we hobble it to suit poor programmers?
No. But that's no reason why it can't be made to be easier and safer to
use for the hobbyist when it doesn't compromise usefulness for the
power-programmer. (My opinion) Python shouldn't have a sign on the door
saying: "You must be this 'leet to enter."

Will static typing be a boon for Python? Is it necessary? Or is it the
trailhead on the road to Hades? <shrug> Only time will tell.

 

[bearophileHUGS]

Doug Holton:

And there are some disadvantages to doing it this way.
It means Python is more flexible to use than Boo,

I've just suggested the *syntax* that I like more.

Bye,
Bearophile

 

[John Roth]

<shrug> It might just be me, but I thought it was to simplify code
analysis and compilation. (That is, for the use of static typing in
general, not for Python in particular.)

Looking at C, it's doubtful error prevention and program clarification was
a serious objective in the static typing system. It's more reasonable to
conclude that C is statically typed because it allows the compiler to more
easily allocate 1 vs 2 vs 8 bytes for a particular variable, and to make
sure the proper addition opcodes get put down.

The C language does not have strong typing in the sense
that most people use the term today.

Now whether this would be useful for Python is an open question.


Right. And unit tests don't do anything for people who don't use them.

Absolutely correct.

The question is, should Guido state "TDD is the one true way to program in
Python.", or should concessions be made in the language design for those
who don't "drink the TDD Kool-aide".

Neither one. I hope you didn't mean that people
who advocate TDD are suicidal fanatics, because
that's exactly what "drink the kool-aid" means.

I rebut it thusly: "elitist bastard." <wink and a half>

Bullshit. Where did you get your certificate in mind reading?

Remember that all of the people who started this were
computer science professors, and most of their experiance was
with computer science students. They were also European
computer science professors with a strong mathematical
tendency; we have since learned that mathematicians and
software developers think differently (see some comments
by Don Knuth to that effect - don't have the reference handy.)

They're the ones who were elitist: they strongly believed
that you had to be a mathematician to be able to properly
program, and that they were doing something good for
the people who weren't fortunate enough to have a
rigorous mathematical background by forcing them into
the strait-jacket of static typing.

Competent professional programmers are a different group,
and need different facilities.

One of the draws of Python is that it's welcoming to newcomers and
programmers of all talents. You don't have to be an "uber-programmer" to
use it and use it well. Should we hobble it to suit poor programmers? No.
But that's no reason why it can't be made to be easier and safer to use
for the hobbyist when it doesn't compromise usefulness for the
power-programmer. (My opinion) Python shouldn't have a sign on the door
saying: "You must be this 'leet to enter."

And it won't. Python has always had the "consenting adults"
philosophy.

Will static typing be a boon for Python? Is it necessary? Or is it the
trailhead on the road to Hades? <shrug> Only time will tell.

Since it won't happen, I'm not particularly worried about it.
If it does, I'll find another language.

John Roth

 

[Rocco Moretti]

The C language does not have strong typing in the sense
that most people use the term today.

Strong != Static

As I understand it, strong typing means an object (variable) is what it
is, and can't be changed to a different type without explicit conversion
- weak typing being that an object can be any type, depending on which
functions you use to look at it.

Static typing is that a variable has a specific type, and can't hold a
variable of a different type. This is opposed to dynamic typing, where
the type of an (object in a) variable is flexible and determined at run
time.

Python - Strong, Dynamic
C - Weak, Static
Perl - Weak, Dynamic

This is how I understand it. Could be wrong - wouldn't be surprised if I
was, as it's a rather confusing issue at times.

Neither one. I hope you didn't mean that people
who advocate TDD are suicidal fanatics, because
that's exactly what "drink the kool-aid" means.

The irony didn't travel well. All I meant is that in all the advocacy,
it may get ignored that reasonable people might disagree about the value
of TDD, that TDD is not a "be-all, end-all" for all people.

"Concessions" also probably wasn't the right choice of word, as it
implies the TDD people are giving something up. My point was, if Python
is not going to be solely targeted at TDD, facilities that make other
ways of doing things easier are likely (should) be included, as long as
they don't negatively affect how the majority of the people who use
Python do things.

Bullshit. Where did you get your certificate in mind reading?

Sorry. I didn't mean to imply that *you* were an elitist bastard. I
merely meant that someone who would dismiss something as for "people
that shouldn't be doing X in the first place" is likely biased by
snobbery. You were merely restating someone else's opinion, and if I
accidentally accused you of also holding it, I'm sorry.

From the rest of your post, it seems we pretty much agree on the key
point - different people have different ways of doing things, none of
which are necessarily "wrong" in and of themselves. Python tries to be
open and inclusive towards all who want to program, without sacrificing
power for it's core users.

Is there a group of people for whom static typing truly helps? I don't
know. What I do know is that saying that you don't need static typing if
you use TDD doesn't say anything about the helpfulness of static typing
for those who don't use TDD. Whether the latter group is worth Python
worrying about is a philosophical question on the future direction of
Python best left to Guido.

 

[Peter Hansen]

Neither one. I hope you didn't mean that people
who advocate TDD are suicidal fanatics, because
that's exactly what "drink the kool-aid" means.

I always thought the connotation was more that those who
"drank the Kool-Aid" were unthinking drones, following what
others told them to do.

Reading Wikipedia's account of Jonestown, it seems
that the truth is a mix of both the blind loyalty thing
and the suicidal fanatic thing.

I've heard this applied most often in recent years
to XML, and while I can imagine some people who apply
the phrase to those overusing XML might think they
are effectively committing suicide, I'm pretty sure
most times it is just used to mean "you are blindly
doing what everybody else does without thinking about
whether it's the right thing to do".

-Peter

P.S.: The ironic thing about all this is that it was
actually something called "Flavor Aid", made by a
company called Jel Sert (http://www.jelsert.com),
and not Kool-Aid at all. What would be even funnier
is if the expression doesn't derive from the Jonestown
suicides and I've always just assumed it did...

 

[Alex Martelli]

Adding Optional Static Typing to Python looks like a quite complex
thing, but useful too:
http://www.artima.com/weblogs/viewpost.jsp?thread=85551

I have just a couple of notes:

Guido doesn't read this group; if you want him to read your notes, post
them as comments to Artima.

_My_ personal note is that I'm now even gladder I got myself Van Roy's
and Haridi's excellent "Concepts, Techniques and Models of Computer
Programming" book as a Christmas self-gift, and my motivation for
studying it in depth is renewed and refreshed...


Alex

 

[Alex Martelli]

question: static typing is an answer. What's the question?
(That's a paraphrase.)

The answer that everyone seems to give is that it
prevents errors and clarifies the program. ...
Most of the kinds of error that static typing is supposed
to catch simply don't persist for more than a minute when
you do test driven development.

....which is exactly the point of the famous post by Robert ("Uncle Bob")
Martin on another artima blog,
http://www.artima.com/weblogs/viewpost.jsp?thread=4639 .


Alex

 

[Mike Meyer]

This may sound a bit
cynical, but most real uber-programmers have either
Lisp or Smalltalk in their backgrounds, and
frequently both one. Neither of those languages
have static typing, and they simply don't need it.

LISP has type declarations. Everybody I know doing production work in
LISP uses them. It's the only way to get reasonable performance out of
LISP compiled code.

Which raises what, to me, is the central question. If we have optional
static typing, can I get a performance enhancement out of it? If not,
why bother?

<mike

 

[Neal D. Becker]

I've just started learning about Haskell. I suggest looking at this for an
example.

A good intro: http://www.haskell.org/tutorial

 

[Rahul]

Hi.
Well i am a newbie to python and maybe not qualified enough to make a
comment on proposals to changes in python. My previous programming
experience has been in Java and C. So maybe you will forgive me if i
make any outlandish comments.

But anyway here goes:

I think instead what should be done is:

1.def gcd(a,b) expects (int,int)

Here the function is not enforcing type checking. The compiler should
only generate warning when someone passes something which is not an int
and should not generate an error.Maybe the person calling the function
knows what he is doing and wants to pass the unexpected type.

2.Another possibility is to let the function decide if the type is not
what it is expecting. Maybe the function recvs some kind of flag which
tells it that the type passed is not what it was expecting. So it can
throw an error if it is really critical.

3.In my post i am not stressing on adding 'expects' as keyword or
something. Only that type should not be enforced and 'expects' makes
this clear.

Rahul Garg

 

[Alex Martelli]

I've just started learning about Haskell. I suggest looking at this for an
example.

A good intro: http://www.haskell.org/tutorial

Haskell's a great language, but beware: its static typing is NOT
optional -- it's rigorous. It can INFER types for you (just like, say,
boo), that's a different issue. It also allows bounded genericity at
compile time (like, say, C++'s templates without the hassles), and
that's yet another (typeclasses are a great mechanism, btw).

Languages with really optional static typing can be found; I think the
premier example is still Dylan -- a kind of commonlisp without infix
notation, unfortunately very out of fashion nowadays but still available
(some good books, too).

I love the explanations of Van Roy and Haridi, p. 104-106 of their book,
though I may or may not agree with their conclusions (which are
basically that the intrinsic difference is tiny -- they point to Oz and
Alice as interoperable languages without and with static typing,
respectively), all the points they make are good. Most importantly, I
believe, the way dynamic typing allows real modularity (harder with
static typing, since type discipline must be enforced across module
boundaries), and "exploratory computing in a computation model that
integrates several programming paradigms".

"Dynamic typing is recommended", they conclude, "when programs must be
as flexible as possible". I recommend reading the Agile Manifesto to
understand why maximal flexibility is crucial in most real-world
application programming -- and therefore why, in said real world rather
than in the more academic circles Dr. Van Roy and Dr. Hadidi move in,
dynamic typing is generally preferable, and not such a tiny issue as
they make the difference to be. Still, they at least show more
awareness of the issues, in devoting 3 excellent pages of discussion
about it, pros and cons, than almost any other book I've seen -- most
books have clearly delineated and preformed precedence one way or the
other, so the discussion is rarely as balanced as that.


Alex

 

[Nick Coghlan]

Which raises what, to me, is the central question. If we have optional
static typing, can I get a performance enhancement out of it? If not,
why bother?

I had some thoughts along the same lines, so I dug up PEP 246 and looked at how
it could be enhanced to potentially support compile time code optimisation
through static type declarations.

The write up is here:
http://boredomandlaziness.skystorm.net/2004/12/type-checking-in-python.html

Cheers,
Nick.

 

[Tim Jarman]

P.S.: The ironic thing about all this is that it was
actually something called "Flavor Aid", made by a
company called Jel Sert (http://www.jelsert.com),
and not Kool-Aid at all. What would be even funnier
is if the expression doesn't derive from the Jonestown
suicides and I've always just assumed it did...

I always thought it was a reference to the Illuminatus! trilogy
(http://tinyurl.com/5uhrz) by Robert Shea & Robert Anton Wilson. At
least, I'm pretty sure that's where I came across it. Maybe they were
referencing Jamestown?

Now if only I could think of a connection between this and Python...

 

[Donn Cave]

Quoth (e-mail address removed) (Alex Martelli):
....
| Haskell's a great language, but beware: its static typing is NOT
| optional -- it's rigorous. It can INFER types for you (just like, say,
| boo), that's a different issue. It also allows bounded genericity at
| compile time (like, say, C++'s templates without the hassles), and
| that's yet another (typeclasses are a great mechanism, btw).

He didn't dwell much on it, but there was some mention of type
inference, kind of as though that could be taken for granted.
I guess this would necessarily be much more limited in scope
than what Haskell et al. do.

Donn Cave, (e-mail address removed)


-----------== Posted via Newsfeed.Com - Uncensored Usenet News ==----------
http://www.newsfeed.com The #1 Newsgroup Service in the World!
-----= Over 100,000 Newsgroups - Unlimited Fast Downloads - 19 Servers =-----

 

[Alex Martelli]

Quoth (e-mail address removed) (Alex Martelli):
...
| Haskell's a great language, but beware: its static typing is NOT
| optional -- it's rigorous. It can INFER types for you (just like, say,
| boo), that's a different issue. It also allows bounded genericity at
| compile time (like, say, C++'s templates without the hassles), and
| that's yet another (typeclasses are a great mechanism, btw).

He didn't dwell much on it, but there was some mention of type
inference, kind of as though that could be taken for granted.
I guess this would necessarily be much more limited in scope
than what Haskell et al. do.

Assuming that by "he" you mean GvR, I think I saw that too, yes. And
yes, a language and particularly a typesystem never designed to
facilitate inferencing are hard-to-impossible to retrofit with it in as
thorough a way as one that's designed around the idea. (Conversely,
making a really modular system work with static typing and inferencing
is probably impossible; in practice, the type inferencer must examine
all code, or a rather copious summary of it... it can't really work
module by module in a nice, fully encapsulated way...).


Alex

 

[Scott David Daniels]

1.def gcd(a,b) expects (int,int)

I presume by this syntax you mean something like:
def gcd(a, b) expects (int, int):
if b > a:
a, b = b, a
while a > b > 0:
a, b = b, a % b
return a

Here the function is not enforcing type checking. The compiler should
only generate warning when someone passes something which is not an int
and should not generate an error.Maybe the person calling the function
knows what he is doing and wants to pass the unexpected type.

But if this is the case, why is it different from?:
def gcd(a, b): # expects (int, int)
return a * b

2.Another possibility is to let the function decide if the type is not
what it is expecting. Maybe the function recvs some kind of flag which
tells it that the type passed is not what it was expecting. So it can
throw an error if it is really critical.

Again, why make the test at all if you don't want to act on it?
assert <boolexp> aborts if it is checked at all, but with __debug__
defined as 1, it passes. Perhaps you are proposing that expects be
used in that context.

3.In my post i am not stressing on adding 'expects' as keyword or
something. Only that type should not be enforced and 'expects' makes
this clear.

You need to explain why anyone would want to write expects at all.
If you are expecting the code generation to change, you'd better
enforce, rather than advise, unless you are defining points at which
to do code specialization on types.

--Scott David Daniels
(e-mail address removed)

 

[Michael Sparks]

Rocco Moretti wrote:
....

Is there a group of people for whom static typing truly helps?

Yes. Python doesn't at present compile down to a binary executable. (Py2exe
don't really count since that's "just" tacking on a VM on the side (he says
dimissively regarding something he thinks is cool )

The closest I can get to this at present is pyrex - which essentially
performs a translation from a very python like language to C, which you
then compile, and if you do things right can produce standalone modules.
Type declarations there are optional, and if omitted falls back to a python
object. If they are included however, you can gain performance boosts for
certain kinds of work. (Most often though you're simply interfacing to C
code.)

ie the groups that could benefit are those that currently go to C/C++
extensions for performance boosts. (and of course those who just want
binary executables (In the absence of Starkiller being released that
is...)

Regards,


Michael.