Re: Optional static typing

[Skip Montanaro]

On Thu, Aug 14, 2014 at 12:02 AM, Steven D'Aprano  wrote:
> Does anyone here use function annotations? If so, what do you use them
> for?

I've used them a little when converting Python to Cython, though I
readily admit that I have no idea if what Cython accepts as a type
declaration is compatible with whatever is being considered for 3.5.

Skip
-- 
https://mail.python.org/mailman/listinfo/python-list

Optional static typing

[Steven D'Aprano]

The BDFL Guido van Rossum is considering optional static typing (ish) for 
Python 3.5:

https://mail.python.org/pipermail/python-ideas/2014-August/028618.html



Does anyone here use function annotations? If so, what do you use them 
for?


-- 
Steven
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: optional static typing for Python

[Wildemar Wildenburger]

Kay Schluehr wrote:
> On Jan 30, 12:38 am, Wildemar Wildenburger
> <[EMAIL PROTECTED]> wrote:
>>> Python has a JIT right no
>> You mean in the Java-sense (outputting native machine code)?
>>
>> /W
> 
> Sure.
> 
> http://psyco.sourceforge.net/
> 

Oh, switcheroo! :)

/W
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: optional static typing for Python

[Kay Schluehr]

On Jan 30, 12:38 am, Wildemar Wildenburger
<[EMAIL PROTECTED]> wrote:
> > Python has a JIT right no
>
> You mean in the Java-sense (outputting native machine code)?
>
> /W

Sure.

http://psyco.sourceforge.net/


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: optional static typing for Python

[[EMAIL PROTECTED]]

On 28 jan, 11:21, "Russ P." <[EMAIL PROTECTED]> wrote:
> On Jan 28, 1:53 am, Bruno Desthuilliers 
>
>
> [EMAIL PROTECTED]> wrote:
> > Russ P. a écrit :
>
> > > On Jan 27, 5:03 pm, Paddy
>
> > >> If static typing is optional then a program written in a dynamic
> > >> language that passes such an automated static analysis of source code
> > >> would have to be a simple program written in a simplistic way, and
> > >> also in a static style.
>
> > > Yes, but for safety-critical software you usually want the simplest
> > > possible solution. The last think you want is an unnecessarily "fancy"
> > > design. Unless there is a darn good reason to write a "non-static"
> > > program, you just don't do it.
>
> > > You might want to check into what the FAA allows in "flight-critical"
> > > code, for example. I am certainly not an expert in that area, but I've
> > > had a passing exposure to it. My understanding is that every possible
> > > branch of the code must be fully and meticulously analyzed and
> > > verified. Hence, the dynamic dispatching of ordinary object-oriented
> > > code is either prohibited or severely frowned upon.
>
> > Then Python is definitively out, so this whole thread is pointless.
>
> Yes, Python as it stands now is "definitely out" as the ultimate
> implementation language for flight-critical software. That's
> essentially a no-brainer. But it can certainly be useful as a
> prototyping language for R&D.
>
> The question then arises as to how to best make use of the prototype.
> Do you throw away the code and start from scratch? That doesn't seem
> wise to me. But maybe that's because I have some idea of how much
> effort can go into developing a good prototype.
>
> If Python could be automatically converted to Ada or Java, that could
> potentially be used as a baseline for actual operational software.
> That would capture the algorithmic details more reliably than recoding
> from scratch by hand. But such an automatic conversion is not feasible
> without explicit typing.

As far as I can tell, this should be possible using type annotations
and some "soft" (ie: coding style guideline) restrictions on the most
dynamic features. This may even be possible without type annotation,
if I refer to the work being done on RPython for Pypy.

This being said, I don't personaly believe that much in "automatic
conversion" from Python to Java or Ada, because a language is not only
made of a syntax and grammar, but also of idioms, and I really doubt
you'll get idiomatic Java or Ada from idiomatic Python - unless your
Python code is written in Javaish (or Ada-ish) idioms, in which case
using Python is IMHO, well, how to say... somewhat pointless ?-)

> And speaking of "pointless," ... I just wasted a significant amount of
> time replying to a pointless post. Oh, well.

Coming from someone posting here that declarative static typing would
make a better Python just because *he* thinks he have a need for it,
without any consideration for the fact that most people here use
Python because they don't actually want static typing, and without
even realizing that most of what makes Python great for prototyping is
it's dynamism, I do find this use of terms like "pointless" and "waste
of time" *very* amusing. Almost as amusing as this other post where
you so kindly worried about my job and personal life.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: optional static typing for Python

[Wildemar Wildenburger]

> Python has a JIT right no
> 
You mean in the Java-sense (outputting native machine code)?

/W
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: optional static typing for Python

[Kay Schluehr]

On 29 Jan., 17:00, "Chris Mellon" <[EMAIL PROTECTED]> wrote:

> Given the difficulty of statically analyzing Python, and the
> limitations you need to add for either static typing or type inference
> to be practical, I think that the real future for faster Python code
> is JIT, not static optimizations.

Python has a JIT right now - so why do you think it's Pythons "real
future"?

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: optional static typing for Python

[Chris Mellon]

On Jan 28, 2008 10:31 AM, John Nagle <[EMAIL PROTECTED]> wrote:
> Arnaud Delobelle wrote:
> > On Jan 27, 11:00 pm, "Russ P." <[EMAIL PROTECTED]> wrote:
> >> On Jan 27, 2:49 pm, "André" <[EMAIL PROTECTED]> wrote:
> >>> Perhaps this:http://www.python.org/dev/peps/pep-3107/mightbe
> >>> relevant?
> >>> André
> >> Thanks. If I read this correctly, this PEP is on track for Python 3.0.
> >> Wonderful!
> >
> > Note that annotations do not provide explicit typing, AFAIK:
> >
> > def f(x:int) -> int: return x*2
> >
> > is stricly equivalent to
> >
> > def f(x): return x*2
> > f.__annotations__ = {'x':int, 'return':int}
> >
> > You still need to write a type-checking wrapper.
>
> Unenforced static typing is somewhat pointless.  If that
> goes in, it should be enforced by implementations.  Otherwise,
> maintenance programmers can't trust the type information they see.
>
> Enforced, it makes it possible to start getting serious about
> optimizing compilers for Python, like Shed Skin.  Shed Skin
> can usually figure out typing within a module, but across module
> boundaries, some help is needed if you want to push optimization from
> run time to compile time.
>
Given the difficulty of statically analyzing Python, and the
limitations you need to add for either static typing or type inference
to be practical, I think that the real future for faster Python code
is JIT, not static optimizations. Languages which enforce static
typing are, of course, not Python - that's why they have different
names, like Pyrex or ShedSkin or RPython.

I think static Python is pretty much a waste of time, really - if I'm
going to write statically typed code using a traditional C/C++/Java
style type system, I'll use a language designed for it, like D. If I
want *real* strict typing - the kind where you can actually make a
useful inference from the fact that the program is type-correct - I'll
use Haskell or Ocaml. There is a lot of choice out there and there's
no reason to try to make Python into whatever your favorite paradigm
is.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: optional static typing for Python

[Ben Finney]

"Russ P." <[EMAIL PROTECTED]> writes:

> I would just like to thank you for reminding me about what losers
> hang out perpetually on sites like this one, thinking they are in
> some kind of real "community." Being reminded of that will help
> prevent me from becoming such a loser myself. No, I didn't say that
> all the "regulars" here are losers, but you most certainly are.

We're a community largely because we don't tolerate this level of
content-free insult. Please find a different forum for this stuff.

-- 
 \   "We spend the first twelve months of our children's lives |
  `\  teaching them to walk and talk and the next twelve years |
_o__)telling them to sit down and shut up."  -- Phyllis Diller |
Ben Finney
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: optional static typing for Python

[Arnaud Delobelle]

On Jan 28, 4:31 pm, John Nagle <[EMAIL PROTECTED]> wrote:
> Arnaud Delobelle wrote:
[...]
> > Note that annotations do not provide explicit typing, AFAIK:
>
> > def f(x:int) -> int: return x*2
>
> > is stricly equivalent to
>
> > def f(x): return x*2
> > f.__annotations__ = {'x':int, 'return':int}
>
> > You still need to write a type-checking wrapper.
>
>     Unenforced static typing is somewhat pointless.  If that
> goes in, it should be enforced by implementations.  Otherwise,
> maintenance programmers can't trust the type information they see.

(As discussed earlier, there is no static typing in Python, there can
only be runtime type-checking or, as someone called it, "explicit
typing")
I think the idea is to let the user decide how to enforce type-
checking, not the language.  I suppose if in a few years a way to do
it emerges that is "the best", then it'll make its way into the
standard library...

--
Arnaud

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: optional static typing for Python

[Marc 'BlackJack' Rintsch]

On Mon, 28 Jan 2008 08:31:43 -0800, John Nagle wrote:

> Unenforced static typing is somewhat pointless.  If that
> goes in, it should be enforced by implementations.

Luckily we don't get static typing.  We get annotations which *can* be
used for type hints, checked by additional code.  Can be used for other
things as well.

Ciao,
Marc 'BlackJack' Rintsch
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: optional static typing for Python

[Boris Borcic]

Wish you'd opted out of typing all that static.

BB

Russ P. wrote:
(...)
> 
> What is that supposed to mean?
> 
> Oh, I almost forgot. I'm supposed to sit here and be polite while
> clueless dolts make wise cracks. Sorry, but I haven't yet mastered
> that level of self-control.
> 
> I would just like to thank you for reminding me about what losers hang
> out perpetually on sites like this one, thinking they are in some kind
> of real "community." Being reminded of that will help prevent me from
> becoming such a loser myself. No, I didn't say that all the "regulars"
> here are losers, but you most certainly are.
> 
> Do you have a job? How about a life? Have you ever been "with" a
> woman? How in the world is it that every time I come to this site, I
> see your sorry ass hanging around yet again? I can't even imagine how
> "pointless" your life must be if you have that much time to spend
> "hanging around" on comp.lang.python -- and being an a--hole to boot.
> 
> Yeah, Lord have mercy -- on losers like you.
> 
> And thanks for reminding me to quit wasting so much time here. I've
> been doing way too much of that lately.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: optional static typing for Python

[John Nagle]

Arnaud Delobelle wrote:
> On Jan 27, 11:00 pm, "Russ P." <[EMAIL PROTECTED]> wrote:
>> On Jan 27, 2:49 pm, "André" <[EMAIL PROTECTED]> wrote:
>>> Perhaps this:http://www.python.org/dev/peps/pep-3107/mightbe
>>> relevant?
>>> André
>> Thanks. If I read this correctly, this PEP is on track for Python 3.0.
>> Wonderful!
> 
> Note that annotations do not provide explicit typing, AFAIK:
> 
> def f(x:int) -> int: return x*2
> 
> is stricly equivalent to
> 
> def f(x): return x*2
> f.__annotations__ = {'x':int, 'return':int}
> 
> You still need to write a type-checking wrapper. 

Unenforced static typing is somewhat pointless.  If that
goes in, it should be enforced by implementations.  Otherwise,
maintenance programmers can't trust the type information they see.

Enforced, it makes it possible to start getting serious about
optimizing compilers for Python, like Shed Skin.  Shed Skin
can usually figure out typing within a module, but across module
boundaries, some help is needed if you want to push optimization from
run time to compile time.

John Nagle
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: optional static typing for Python

[Kay Schluehr]

On 27 Jan., 23:19, "Russ P." <[EMAIL PROTECTED]> wrote:
> A while back I came across a tentative proposal from way back in 2000
> for optional static typing in Python:
>
> http://www.python.org/~guido/static-typing
>
> Two motivations were given:
>
> -- faster code
> -- better compile-time error detection
>
> I'd like to suggest a third, which could help extend Python into the
> safety-critical domain:
>
> -- facilitates automated source-code analysis
>
> There has been much heated debate in the past about whether Python is
> appropriate for safety-critical software. Some argue that, with
> thorough testing, Python code can be as reliable as code in any
> language. Well, maybe. But then, a famous computer scientist once
> remarked that,
>
> "Program testing can be used to show the presence of bugs, but never
> to show their absence!" --Edsger Dijkstra
>
> The next step beyond extensive testing is automated, "static" analysis
> of source-code ("static" in the sense of analyzing it without actually
> running it). For example, Spark Ada is a subset of Ada with
> programming by contract, and in some cases it can formally prove the
> correctness of a program by static analysis.
>
> Then there is Java Pathfinder (http://javapathfinder.sourceforge.net),
> an "explicit state software model checker." The developers of JPF
> wanted
> to use it on a prototype safety-critical application that I wrote in
> Python, but JPF only works on Java code. We considered somehow using
> Jython and Jythonc, but neither did the trick. So they ended up having
> someone manually convert my Python code to Java! (The problem is that
> my code was still in flux, and the Java and Python versions have now
> diverged.)
>
> In any case, optional static typing in Python would help tremendously
> here. The hardest part of automated conversion of Python to a
> statically typed language is the problem of type inference. If the
> types are explicitly declared, that problem obviously goes away.
> Explicit typing would also greatly facilitate the development of a
> "Python Pathfinder," so the conversion would perhaps not even be
> necessary in the first place.
>
> Note also that, while "static" type checking would be ideal,
> "explicit" typing would be a major step in the right direction and
> would probably be much easier to implement. That is, provide a syntax
> to explicitly declare types, then just check them at run time. A
> relatively simple pre-processor could be implemented to convert the
> explicit type declarations into "isinstance" checks or some such
> thing. (A pre-processor command-line argument could be provided to
> disable the type checks for more efficient production runs if
> desired.)
>

> I noticed that Guido has expressed further interest in static typing
> three or four years ago on his blog. Does anyone know the current
> status of this project? Thanks.

It has been withdrawn in its original version. What's left is
annotation syntax and the __annotation__ dict ( I don't know what the
latter is good for but maybe some purpose emerges once a complete
signature object is provided? ). So there has not been much work spent
on hybrid type systems, static analysis and type directed native
compilation.

I did some work on type feedback and created a Python dialect called
TPython a while ago based on Python 3.0 but supporting more syntax to
add also local type annotations and an 'A of T' construct for type
parametricity. The main purpose of TPython was to provide an interface
for 3rd party tools used for refactoring, type checking, compilation,
documentation etc. without separating annotations from Python code but
build them in place.

This project is unpublished and on hold because it is part of
EasyExtend 2.0 and I reworked EE to incorporate a brand new parser
generator called Trail that involved quite some research from my side.
EasyExtend 3 is intended to be released in Q2.

Regards
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: optional static typing for Python

[Bjoern Schliessmann]

Russ P. wrote:
> On Jan 28, 1:51 am, Bruno Desthuilliers > Lord have mercy(tm).
> 
> What is that supposed to mean?

I suppose he wants to communicate that this is the nth time this
topic is brought up (n=>infinite). Try searching the archives next
time.
 
Regards,


Björn

P.S.: IMHO, your flame is a record low in manners and respect and
it's a shame for this list/NG.


-- 
BOFH excuse #89:

Electromagnetic energy loss

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: optional static typing for Python

[Bruno Desthuilliers]

Russ P. a écrit :
> On Jan 28, 1:51 am, Bruno Desthuilliers  [EMAIL PROTECTED]> wrote:
>> Russ P. a écrit :> A while back I came across a tentative proposal from way 
>> back in 2000
>>> for optional static typing in Python:
>> (snip)
>>
>>> In any case, optional static typing in Python would help tremendously
>>> here. The hardest part of automated conversion of Python to a
>>> statically typed language is the problem of type inference. If the
>>> types are explicitly declared, that problem obviously goes away.
>> (snip)
>>
>>> Note also that, while "static" type checking would be ideal,
>>> "explicit" typing would be a major step in the right direction
>> Lord have mercy(tm).
> 
> What is that supposed to mean?

That I definitively don't agree with you on this point and would prefer 
that statically-typed languages proponants (and specially those advocate 
declarative typing) leave Python alone.

> Oh, I almost forgot. I'm supposed to sit here and be polite while
> clueless dolts make wise cracks. Sorry, but I haven't yet mastered
> that level of self-control.
> 
> I would just like to thank you for reminding me about what losers hang
> out perpetually on sites like this one, thinking they are in some kind
> of real "community." Being reminded of that will help prevent me from
> becoming such a loser myself. No, I didn't say that all the "regulars"
> here are losers, but you most certainly are.
> 
> Do you have a job? 

Yes.

> How about a life? 

Idem.

> Have you ever been "with" a
> woman? 

I'm married and have kids, and we're pretty happy, thanks.

> How in the world is it that every time I come to this site, I
> see your sorry ass hanging around yet again? I can't even imagine how
> "pointless" your life must be if you have that much time to spend
> "hanging around" on comp.lang.python -- and being an a--hole to boot.
> 
> Yeah, Lord have mercy -- on losers like you.
> 
> And thanks for reminding me to quit wasting so much time here. I've
> been doing way too much of that lately.

How does it come that you having nothing better to do than insulting 
peoples that happen to disagree with you ?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: optional static typing for Python

[Diez B. Roggisch]

> If Python could be automatically converted to Ada or Java, that could
> potentially be used as a baseline for actual operational software.
> That would capture the algorithmic details more reliably than recoding
> from scratch by hand. But such an automatic conversion is not feasible
> without explicit typing.

If python could be automatically converted to ADA or Java, it wouldn't be
python. The fundamental difference IS the lack of static type annotations.
The problem is that people often confuse type inference with dynamic
typing, because it looks similar - but it isn't the same. All typeinference
does is to take an expression like this:

a = 10 * 100

and place type-variables on it, like this:

a:t_0 = 10:int * 100:int

Actually, the multiplication also gets annotated, like this:

a:t_0 = *(10:int, 100:int):t_1

Then the unknown type variables are inferred - it is known (and that is an
important property: ALL FUNCTIONS ARE KNOWN AT THIS POINT) that there
exists a multiplication function that has this signature:

_ * _ : [int, int] -> int

so t_1 can be inferred to be int, thus t_0 can be inferred to be int as
well.

But the key-point is: each and every function declaration is and has to be
fully statically typed. And all of them have to be known at compile-time!!
And of course this extends to classes or interfaces and such.

There are some nice tricks like generic types that themselves containt
type-variables in their declaration, so that you can declcare e.g. map,
reduce, filter and so forth in generic ways. But they are _fully_ type
annotated.

And the "normal" (Henly/Millner) type inference fails to produce correct
results in cases like this:

def foo(arg):
if arg > 10:
   return 100
else:
   return "n/a"

Which is perfectly legal and sometimes useful in python. Yes, there is
dependent typing, but this also goes only so far.

Additionally, it can be shown that type-inferencing becomes
non-deterministic or even unsolvable in the very moment you start
introducing recursive types - so, away with lists, arrays, trees and so
forth. Which of course also means that the statically typed languages will
produce errors, unless you restrict them heavily with respect to dynamic
memory allocation and so forth (that restricted ADA variant sometimes
popping up in discussions about this is one such case)

bottom-line: type-inference doesn't do magic, fully staticly annotated
languages still fail, and efforts like shedskin are interesting but will
never grow to a full-fledged python. And adding static type-declarations to
python will make it NotPython, a totally different language.

Diez


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: optional static typing for Python

[Torsten Bronger]

Hallöchen!

Russ P. writes:

> On Jan 28, 1:51 am, Bruno Desthuilliers  [EMAIL PROTECTED]> wrote:
>> Russ P. a écrit :> A while back I came across a tentative proposal from way
> back in 2000
>> > for optional static typing in Python:
>>
>> (snip)
>>
>>> In any case, optional static typing in Python would help
>>> tremendously here. The hardest part of automated conversion of
>>> Python to a statically typed language is the problem of type
>>> inference. If the types are explicitly declared, that problem
>>> obviously goes away.
>>
>> (snip)
>>
>>> Note also that, while "static" type checking would be ideal,
>>> "explicit" typing would be a major step in the right direction
>>
>> Lord have mercy(tm).
>
> What is that supposed to mean?

So you haven't understood him.  Then why is this rant following?

Anyway, I can only speak for myself: I have the concern that any
(albeit optional) declaring of types in Python leads to people
thinking that their code is more valuable with such declarations.
Mostly you know which type is to be expected after all.

As a result, you see such declarations everywhere, whether helpful
or not.  Maybe eventually tools such as pylint will even give a
percentage how many parameters are annotated, and people try to
maximize this value.  Ugh.

Then, Python is not as useful anymore because readability falls
drastically.  Moreover, there is a Fortran saying: "One person's
constant is another person's variable."  The same applies to types
in Python.

Pythons is one way, Ada another way; there is no silver bullet.

Tschö,
Torsten.

-- 
Torsten Bronger, aquisgrana, europa vetus
  Jabber ID: [EMAIL PROTECTED]
   (See http://ime.webhop.org for further contact info.)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: optional static typing for Python

[cokofreedom]

On Jan 28, 11:42 am, "Russ P." <[EMAIL PROTECTED]> wrote:
> On Jan 28, 1:51 am, Bruno Desthuilliers 
>
>
> [EMAIL PROTECTED]> wrote:
> > Russ P. a écrit :> A while back I came across a tentative proposal from way 
> > back in 2000
> > > for optional static typing in Python:
>
> > (snip)
>
> > > In any case, optional static typing in Python would help tremendously
> > > here. The hardest part of automated conversion of Python to a
> > > statically typed language is the problem of type inference. If the
> > > types are explicitly declared, that problem obviously goes away.
>
> > (snip)
>
> > > Note also that, while "static" type checking would be ideal,
> > > "explicit" typing would be a major step in the right direction
>
> > Lord have mercy(tm).
>
> What is that supposed to mean?
>
> Oh, I almost forgot. I'm supposed to sit here and be polite while
> clueless dolts make wise cracks. Sorry, but I haven't yet mastered
> that level of self-control.
>
> I would just like to thank you for reminding me about what losers hang
> out perpetually on sites like this one, thinking they are in some kind
> of real "community." Being reminded of that will help prevent me from
> becoming such a loser myself. No, I didn't say that all the "regulars"
> here are losers, but you most certainly are.
>
> Do you have a job? How about a life? Have you ever been "with" a
> woman? How in the world is it that every time I come to this site, I
> see your sorry ass hanging around yet again? I can't even imagine how
> "pointless" your life must be if you have that much time to spend
> "hanging around" on comp.lang.python -- and being an a--hole to boot.
>
> Yeah, Lord have mercy -- on losers like you.
>
> And thanks for reminding me to quit wasting so much time here. I've
> been doing way too much of that lately.

Why is it everyone has to resort to name calling and instantly being
offended by everyone. If you don't think he reply has merit, then
either simply ask him what he meant or ignore the post altogether.
Your reply just flames the issue.

I never get the reason why people feel the need to insult someone they
feel has insulted them. That somehow by the re-doing the act they will
solve the issue? Just move on.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: optional static typing for Python

[Russ P.]

On Jan 28, 1:51 am, Bruno Desthuilliers  wrote:
> Russ P. a écrit :> A while back I came across a tentative proposal from way 
> back in 2000
> > for optional static typing in Python:
>
> (snip)
>
> > In any case, optional static typing in Python would help tremendously
> > here. The hardest part of automated conversion of Python to a
> > statically typed language is the problem of type inference. If the
> > types are explicitly declared, that problem obviously goes away.
>
> (snip)
>
> > Note also that, while "static" type checking would be ideal,
> > "explicit" typing would be a major step in the right direction
>
> Lord have mercy(tm).

What is that supposed to mean?

Oh, I almost forgot. I'm supposed to sit here and be polite while
clueless dolts make wise cracks. Sorry, but I haven't yet mastered
that level of self-control.

I would just like to thank you for reminding me about what losers hang
out perpetually on sites like this one, thinking they are in some kind
of real "community." Being reminded of that will help prevent me from
becoming such a loser myself. No, I didn't say that all the "regulars"
here are losers, but you most certainly are.

Do you have a job? How about a life? Have you ever been "with" a
woman? How in the world is it that every time I come to this site, I
see your sorry ass hanging around yet again? I can't even imagine how
"pointless" your life must be if you have that much time to spend
"hanging around" on comp.lang.python -- and being an a--hole to boot.

Yeah, Lord have mercy -- on losers like you.

And thanks for reminding me to quit wasting so much time here. I've
been doing way too much of that lately.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: optional static typing for Python

[Russ P.]

On Jan 28, 1:53 am, Bruno Desthuilliers  wrote:
> Russ P. a écrit :
>
>
>
> > On Jan 27, 5:03 pm, Paddy
>
> >> If static typing is optional then a program written in a dynamic
> >> language that passes such an automated static analysis of source code
> >> would have to be a simple program written in a simplistic way, and
> >> also in a static style.
>
> > Yes, but for safety-critical software you usually want the simplest
> > possible solution. The last think you want is an unnecessarily "fancy"
> > design. Unless there is a darn good reason to write a "non-static"
> > program, you just don't do it.
>
> > You might want to check into what the FAA allows in "flight-critical"
> > code, for example. I am certainly not an expert in that area, but I've
> > had a passing exposure to it. My understanding is that every possible
> > branch of the code must be fully and meticulously analyzed and
> > verified. Hence, the dynamic dispatching of ordinary object-oriented
> > code is either prohibited or severely frowned upon.
>
> Then Python is definitively out, so this whole thread is pointless.

Yes, Python as it stands now is "definitely out" as the ultimate
implementation language for flight-critical software. That's
essentially a no-brainer. But it can certainly be useful as a
prototyping language for R&D.

The question then arises as to how to best make use of the prototype.
Do you throw away the code and start from scratch? That doesn't seem
wise to me. But maybe that's because I have some idea of how much
effort can go into developing a good prototype.

If Python could be automatically converted to Ada or Java, that could
potentially be used as a baseline for actual operational software.
That would capture the algorithmic details more reliably than recoding
from scratch by hand. But such an automatic conversion is not feasible
without explicit typing.

And speaking of "pointless," ... I just wasted a significant amount of
time replying to a pointless post. Oh, well.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: optional static typing for Python

[Paul Rubin]

"Russ P." <[EMAIL PROTECTED]> writes:
> You might want to check into what the FAA allows in "flight-critical"
> code, for example. I am certainly not an expert in that area, but I've
> had a passing exposure to it. My understanding is that every possible
> branch of the code must be fully and meticulously analyzed and
> verified. Hence, the dynamic dispatching of ordinary object-oriented
> code is either prohibited or severely frowned upon.

This would also seem to impact higher-order functions, which are
prominent in fancy verification systems based on extracting code from
constructive theorem provers.  I know those things are used in some
sensitive security applications.  I wonder what the aerospace
community thinks of that area.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: optional static typing for Python

[Bruno Desthuilliers]

Russ P. a écrit :
> On Jan 27, 5:03 pm, Paddy
> 
>> If static typing is optional then a program written in a dynamic
>> language that passes such an automated static analysis of source code
>> would have to be a simple program written in a simplistic way, and
>> also in a static style.
> 
> Yes, but for safety-critical software you usually want the simplest
> possible solution. The last think you want is an unnecessarily "fancy"
> design. Unless there is a darn good reason to write a "non-static"
> program, you just don't do it.
> 
> You might want to check into what the FAA allows in "flight-critical"
> code, for example. I am certainly not an expert in that area, but I've
> had a passing exposure to it. My understanding is that every possible
> branch of the code must be fully and meticulously analyzed and
> verified. Hence, the dynamic dispatching of ordinary object-oriented
> code is either prohibited or severely frowned upon.

Then Python is definitively out, so this whole thread is pointless.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: optional static typing for Python

[Bruno Desthuilliers]

Russ P. a écrit :
> A while back I came across a tentative proposal from way back in 2000
> for optional static typing in Python:
> 
(snip)

> In any case, optional static typing in Python would help tremendously
> here. The hardest part of automated conversion of Python to a
> statically typed language is the problem of type inference. If the
> types are explicitly declared, that problem obviously goes away.

(snip)

> Note also that, while "static" type checking would be ideal,
> "explicit" typing would be a major step in the right direction

Lord have mercy(tm).
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: optional static typing for Python

[Paul Rubin]

Paddy <[EMAIL PROTECTED]> writes:
> > Fair enough.  My main issue was against the notion that random testing
> > is the only thing necessary.
> 
> Sorry Paul if I may have given that impression, its just that when you
> bring in random testing to a design that until then had only directed
> tests you can see the bug rate jump up! 

Sure, I agree with that as well, what I should have said was I have an
issue with the notion that testing (of any sort) is all that is needed
to reach high assurance.  Directed and random tests BOTH failed to
catch the FDIV bug.  You need methods that demonstrate the absence of
defects, not just fail to demonstrate their presence.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: optional static typing for Python

[Paddy]

On Jan 28, 6:17 am, Paul Rubin  wrote:
> Paddy <[EMAIL PROTECTED]> writes:
> > Given the complexity of current microprocessors i'm guessing that
> > their previous testing methods would be too good to just junk in
> > totality because the FDIV bug was not found. Similarly if they were
> > not using formal methods then it makes sense to add it too your
> > arsenal; and unfortunately it takes a mistake like that to allow
> > different methods to be explored and incorporated.
>
> Fair enough.  My main issue was against the notion that random testing
> is the only thing necessary.

Sorry Paul if I may have given that impression, its just that when you
bring in random testing to a design that until then had only directed
tests you can see the bug rate jump up! Think of a hysteresis curve
that has gone flat with current testing methods as not many new bugs
are being found; add a new test methodology - random testing and you
get a new hysteresis curve added as bugs found jump up again. We
eventually ship the chip and get awarded by one of our large customers
for quality - which happened - so thats why I put it forward.
- Paddy.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: optional static typing for Python

[Paul Rubin]

Paddy <[EMAIL PROTECTED]> writes:
> Given the complexity of current microprocessors i'm guessing that
> their previous testing methods would be too good to just junk in
> totality because the FDIV bug was not found. Similarly if they were
> not using formal methods then it makes sense to add it too your
> arsenal; and unfortunately it takes a mistake like that to allow
> different methods to be explored and incorporated.

Fair enough.  My main issue was against the notion that random testing
is the only thing necessary.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: optional static typing for Python

[Paddy]

On Jan 28, 1:56 am, Paul Rubin  wrote:
> Paddy <[EMAIL PROTECTED]> writes:
> > I would rather advocate such random test generation methods as being
> > more appropriate for testing software in safety critical systems when
> > the programming language is dynamic.
>
> That method totally failed to find the Pentium FDIV bug, and they use
> static proof checkers like ACL2 now.

I would doubt that they would use purely static methods to verify such
large and complex chips. You need a spread of methods, and some
techniques find more bugs at different stages of the design. When
alerted to the existence of a bug then you have to create a test find
it and might well choose to create assertions for formal proof on that
section of the design.

Given the complexity of current microprocessors i'm guessing that
their previous testing methods would be too good to just junk in
totality because the FDIV bug was not found. Similarly if they were
not using formal methods then it makes sense to add it too your
arsenal; and unfortunately it takes a mistake like that to allow
different methods to be explored and incorporated.
It's rarely either/or. More a question of the right, cost-effective,
mix of tools to find bugs, and get the product released on time.

- Paddy.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: optional static typing for Python

[Kay Schluehr]

On Jan 28, 12:22 am, Arnaud Delobelle <[EMAIL PROTECTED]> wrote:
> On Jan 27, 11:00 pm, "Russ P." <[EMAIL PROTECTED]> wrote:
>
> > On Jan 27, 2:49 pm, "André" <[EMAIL PROTECTED]> wrote:
> > > Perhaps this:http://www.python.org/dev/peps/pep-3107/mightbe
> > > relevant?
> > > André
>
> > Thanks. If I read this correctly, this PEP is on track for Python 3.0.
> > Wonderful!
>
> Note that annotations do not provide explicit typing, AFAIK:
>
> def f(x:int) -> int: return x*2
>
> is stricly equivalent to
>
> def f(x): return x*2
> f.__annotations__ = {'x':int, 'return':int}
>
> You still need to write a type-checking wrapper.

Has anyone figured out how to match arguments passed into a "wrapper"
function defined within a decorator onto the signature of f or onto
f.__annotations__ respectively?

> PEP 3107 mentions two
> such tools:
> *http://oakwinter.com/code/typecheck/
> *http://maxrepo.info/taxonomy/term/3,6/all
> Neither require annotations.

I like the design of the typecheck package. Everying is implemented in
__init__.py ;)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: optional static typing for Python

[Terry Reedy]

"Russ P." <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
|> Perhaps this:http://www.python.org/dev/peps/pep-3107/might be relevant?
| Thanks. If I read this correctly, this PEP is on track for Python 3.0. 
Wonderful!

If you experiment with static analysis using annotations, I am sure many 
would be interested in the results.

tjr




-- 
http://mail.python.org/mailman/listinfo/python-list

Re: optional static typing for Python

[Russ P.]

On Jan 27, 5:03 pm, Paddy

> If static typing is optional then a program written in a dynamic
> language that passes such an automated static analysis of source code
> would have to be a simple program written in a simplistic way, and
> also in a static style.

Yes, but for safety-critical software you usually want the simplest
possible solution. The last think you want is an unnecessarily "fancy"
design. Unless there is a darn good reason to write a "non-static"
program, you just don't do it.

You might want to check into what the FAA allows in "flight-critical"
code, for example. I am certainly not an expert in that area, but I've
had a passing exposure to it. My understanding is that every possible
branch of the code must be fully and meticulously analyzed and
verified. Hence, the dynamic dispatching of ordinary object-oriented
code is either prohibited or severely frowned upon.

> Having used such formal tools on hardware designs that are expressed
> using statically typed languages such as Verilog and VHDL, we don't
> have the problem of throwing away run time typing, but we do get other
> capacity problems with formal proofs that mean only parts of a design
> can be formally prooved, or we can proof that an assertion holds only
> as far as the engine has resources to expand the assertion.
> We tend to find a lot of bugs in near complete designs by the random
> generation of test cases and the automatic checking of results. In
> effect, two (or more) programs are created by different people and
> usually in different languages. One is written in say Verilog and can
> be used to create a chip, another is written by the Verification group
> in a 'higher level language' (in terms of chip testing), a tunable
> randomized test generator then generates plausible test streams that
> the Verification model validates. The test stream is applied to the
> Verilog model and the Verilogs responses checked against the
> Verification models output and any discrepancy flagged. Coverage
> metrics (line coverage , statement coverage, expression coverage ...),
> are gathered to indicate how well the design/program is being
> exercised.
>
> I would rather advocate such random test generation methods as being
> more appropriate for testing software in safety critical systems when
> the programming language is dynamic.

Random test generation methods can go a long way, and they certainly
have their place, but I don't think they are a panacea. Coming up with
a random set of cases that flush out every possible bug is usually
very difficult if not impossible. That was the point of the quote in
my original post.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: optional static typing for Python

[Paul Rubin]

Paddy <[EMAIL PROTECTED]> writes:
> I would rather advocate such random test generation methods as being
> more appropriate for testing software in safety critical systems when
> the programming language is dynamic.

That method totally failed to find the Pentium FDIV bug, and they use
static proof checkers like ACL2 now.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: optional static typing for Python

[Paddy]

On Jan 27, 10:19 pm, "Russ P." <[EMAIL PROTECTED]> wrote:
> A while back I came across a tentative proposal from way back in 2000
> for optional static typing in Python:
>
> http://www.python.org/~guido/static-typing
>
> Two motivations were given:
>
> -- faster code
> -- better compile-time error detection
>
> I'd like to suggest a third, which could help extend Python into the
> safety-critical domain:
>
> -- facilitates automated source-code analysis
>
> There has been much heated debate in the past about whether Python is
> appropriate for safety-critical software. Some argue that, with
> thorough testing, Python code can be as reliable as code in any
> language. Well, maybe. But then, a famous computer scientist once
> remarked that,
>
> "Program testing can be used to show the presence of bugs, but never
> to show their absence!" --Edsger Dijkstra
>
> The next step beyond extensive testing is automated, "static" analysis
> of source-code ("static" in the sense of analyzing it without actually
> running it). For example, Spark Ada is a subset of Ada with
> programming by contract, and in some cases it can formally prove the
> correctness of a program by static analysis.
>
> Then there is Java Pathfinder (http://javapathfinder.sourceforge.net),
> an "explicit state software model checker." The developers of JPF
> wanted
> to use it on a prototype safety-critical application that I wrote in
> Python, but JPF only works on Java code. We considered somehow using
> Jython and Jythonc, but neither did the trick. So they ended up having
> someone manually convert my Python code to Java! (The problem is that
> my code was still in flux, and the Java and Python versions have now
> diverged.)
>
> In any case, optional static typing in Python would help tremendously
> here. The hardest part of automated conversion of Python to a
> statically typed language is the problem of type inference. If the
> types are explicitly declared, that problem obviously goes away.
> Explicit typing would also greatly facilitate the development of a
> "Python Pathfinder," so the conversion would perhaps not even be
> necessary in the first place.
>
> Note also that, while "static" type checking would be ideal,
> "explicit" typing would be a major step in the right direction and
> would probably be much easier to implement. That is, provide a syntax
> to explicitly declare types, then just check them at run time. A
> relatively simple pre-processor could be implemented to convert the
> explicit type declarations into "isinstance" checks or some such
> thing. (A pre-processor command-line argument could be provided to
> disable the type checks for more efficient production runs if
> desired.)
>
> I noticed that Guido has expressed further interest in static typing
> three or four years ago on his blog. Does anyone know the current
> status of this project? Thanks.

If static typing is optional then a program written in a dynamic
language that passes such an automated static analysis of source code
would have to be a simple program written in a simplistic way, and
also in a static style.

Having used such formal tools on hardware designs that are expressed
using statically typed languages such as Verilog and VHDL, we don't
have the problem of throwing away run time typing, but we do get other
capacity problems with formal proofs that mean only parts of a design
can be formally prooved, or we can proof that an assertion holds only
as far as the engine has resources to expand the assertion.
We tend to find a lot of bugs in near complete designs by the random
generation of test cases and the automatic checking of results. In
effect, two (or more) programs are created by different people and
usually in different languages. One is written in say Verilog and can
be used to create a chip, another is written by the Verification group
in a 'higher level language' (in terms of chip testing), a tunable
randomized test generator then generates plausible test streams that
the Verification model validates. The test stream is applied to the
Verilog model and the Verilogs responses checked against the
Verification models output and any discrepancy flagged. Coverage
metrics (line coverage , statement coverage, expression coverage ...),
are gathered to indicate how well the design/program is being
exercised.

I would rather advocate such random test generation methods as being
more appropriate for testing software in safety critical systems when
the programming language is dynamic.

- Paddy.
P.S. I think that random generation has also been used to test
compilers by automatically generating correct source for compilation.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: optional static typing for Python

[Christian Heimes]

Arnaud Delobelle wrote:
> On Jan 27, 11:00 pm, "Russ P." <[EMAIL PROTECTED]> wrote:
>> On Jan 27, 2:49 pm, "André" <[EMAIL PROTECTED]> wrote:
>>> Perhaps this:http://www.python.org/dev/peps/pep-3107/mightbe
>>> relevant?
>>> André
>> Thanks. If I read this correctly, this PEP is on track for Python 3.0.
>> Wonderful!
> 
> Note that annotations do not provide explicit typing, AFAIK:
> 
> def f(x:int) -> int: return x*2
> 
> is stricly equivalent to
> 
> def f(x): return x*2
> f.__annotations__ = {'x':int, 'return':int}

Your assumption is correct.

Christian

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: optional static typing for Python

[ajaksu]

On Jan 27, 9:13 pm, "Russ P." <[EMAIL PROTECTED]> wrote:
> On Jan 27, 3:08 pm, Jarek Zgoda <[EMAIL PROTECTED]> wrote:
>
> > Russ P. pisze:
>
> > >>> I noticed that Guido has expressed further interest in static typing
> > >>> three or four years ago on his blog. Does anyone know the current
> > >>> status of this project? Thanks.
> > >> I thought it was april fools joke?
>
> > > On January 21, 2000? Which calendar do you use?
>
> > Static typing in Python is usual theme of april fools jokes.
>
> I hope Guido doesn't find out about that!

He does know, follow 
http://mail.python.org/pipermail/python-dev/2007-April/072419.html
and get a laugh too! :)

On a more serious note, I suggest you look up ShedSkin, Pyrex and
Cython, where the static typing is used for better performance. And
with Psyco, you get dynamic typing with JIT specialization. In core
CPython, little is being done AFAIK to support static typing per-se,
but annotations can (and probably will) be used for that end. However,
I don't think it'll interfere in how CPython executes the program.

Daniel
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: optional static typing for Python

[Arnaud Delobelle]

On Jan 27, 11:00 pm, "Russ P." <[EMAIL PROTECTED]> wrote:
> On Jan 27, 2:49 pm, "André" <[EMAIL PROTECTED]> wrote:
> > Perhaps this:http://www.python.org/dev/peps/pep-3107/mightbe
> > relevant?
> > André
>
> Thanks. If I read this correctly, this PEP is on track for Python 3.0.
> Wonderful!

Note that annotations do not provide explicit typing, AFAIK:

def f(x:int) -> int: return x*2

is stricly equivalent to

def f(x): return x*2
f.__annotations__ = {'x':int, 'return':int}

You still need to write a type-checking wrapper. PEP 3107 mentions two
such tools:
* http://oakwinter.com/code/typecheck/
* http://maxrepo.info/taxonomy/term/3,6/all
Neither require annotations.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: optional static typing for Python

[Russ P.]

On Jan 27, 3:08 pm, Jarek Zgoda <[EMAIL PROTECTED]> wrote:
> Russ P. pisze:
>
> >>> I noticed that Guido has expressed further interest in static typing
> >>> three or four years ago on his blog. Does anyone know the current
> >>> status of this project? Thanks.
> >> I thought it was april fools joke?
>
> > On January 21, 2000? Which calendar do you use?
>
> Static typing in Python is usual theme of april fools jokes.

I hope Guido doesn't find out about that!

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: optional static typing for Python

[Jarek Zgoda]

Russ P. pisze:

>>> I noticed that Guido has expressed further interest in static typing
>>> three or four years ago on his blog. Does anyone know the current
>>> status of this project? Thanks.
>> I thought it was april fools joke?
> 
> On January 21, 2000? Which calendar do you use?

Static typing in Python is usual theme of april fools jokes.

-- 
Jarek Zgoda
http://zgodowie.org/

"We read Knuth so you don't have to" - Tim Peters
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: optional static typing for Python

[Russ P.]

On Jan 27, 2:49 pm, "André" <[EMAIL PROTECTED]> wrote:
> On Jan 27, 6:19 pm, "Russ P." <[EMAIL PROTECTED]> wrote:
>
>
>
> > A while back I came across a tentative proposal from way back in 2000
> > for optional static typing in Python:
>
> >http://www.python.org/~guido/static-typing
>
> > Two motivations were given:
>
> > -- faster code
> > -- better compile-time error detection
>
> > I'd like to suggest a third, which could help extend Python into the
> > safety-critical domain:
>
> > -- facilitates automated source-code analysis
>
> > There has been much heated debate in the past about whether Python is
> > appropriate for safety-critical software. Some argue that, with
> > thorough testing, Python code can be as reliable as code in any
> > language. Well, maybe. But then, a famous computer scientist once
> > remarked that,
>
> > "Program testing can be used to show the presence of bugs, but never
> > to show their absence!" --Edsger Dijkstra
>
> > The next step beyond extensive testing is automated, "static" analysis
> > of source-code ("static" in the sense of analyzing it without actually
> > running it). For example, Spark Ada is a subset of Ada with
> > programming by contract, and in some cases it can formally prove the
> > correctness of a program by static analysis.
>
> > Then there is Java Pathfinder (http://javapathfinder.sourceforge.net),
> > an "explicit state software model checker." The developers of JPF
> > wanted
> > to use it on a prototype safety-critical application that I wrote in
> > Python, but JPF only works on Java code. We considered somehow using
> > Jython and Jythonc, but neither did the trick. So they ended up having
> > someone manually convert my Python code to Java! (The problem is that
> > my code was still in flux, and the Java and Python versions have now
> > diverged.)
>
> > In any case, optional static typing in Python would help tremendously
> > here. The hardest part of automated conversion of Python to a
> > statically typed language is the problem of type inference. If the
> > types are explicitly declared, that problem obviously goes away.
> > Explicit typing would also greatly facilitate the development of a
> > "Python Pathfinder," so the conversion would perhaps not even be
> > necessary in the first place.
>
> > Note also that, while "static" type checking would be ideal,
> > "explicit" typing would be a major step in the right direction and
> > would probably be much easier to implement. That is, provide a syntax
> > to explicitly declare types, then just check them at run time. A
> > relatively simple pre-processor could be implemented to convert the
> > explicit type declarations into "isinstance" checks or some such
> > thing. (A pre-processor command-line argument could be provided to
> > disable the type checks for more efficient production runs if
> > desired.)
>
> > I noticed that Guido has expressed further interest in static typing
> > three or four years ago on his blog. Does anyone know the current
> > status of this project? Thanks.
>
> Perhaps this:http://www.python.org/dev/peps/pep-3107/might be
> relevant?
> André

Thanks. If I read this correctly, this PEP is on track for Python 3.0.
Wonderful!

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: optional static typing for Python

[Russ P.]

On Jan 27, 2:36 pm, Jarek Zgoda <[EMAIL PROTECTED]> wrote:
> Russ P. pisze:
>
> > I noticed that Guido has expressed further interest in static typing
> > three or four years ago on his blog. Does anyone know the current
> > status of this project? Thanks.
>
> I thought it was april fools joke?

On January 21, 2000? Which calendar do you use?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: optional static typing for Python

[André]

On Jan 27, 6:19 pm, "Russ P." <[EMAIL PROTECTED]> wrote:
> A while back I came across a tentative proposal from way back in 2000
> for optional static typing in Python:
>
> http://www.python.org/~guido/static-typing
>
> Two motivations were given:
>
> -- faster code
> -- better compile-time error detection
>
> I'd like to suggest a third, which could help extend Python into the
> safety-critical domain:
>
> -- facilitates automated source-code analysis
>
> There has been much heated debate in the past about whether Python is
> appropriate for safety-critical software. Some argue that, with
> thorough testing, Python code can be as reliable as code in any
> language. Well, maybe. But then, a famous computer scientist once
> remarked that,
>
> "Program testing can be used to show the presence of bugs, but never
> to show their absence!" --Edsger Dijkstra
>
> The next step beyond extensive testing is automated, "static" analysis
> of source-code ("static" in the sense of analyzing it without actually
> running it). For example, Spark Ada is a subset of Ada with
> programming by contract, and in some cases it can formally prove the
> correctness of a program by static analysis.
>
> Then there is Java Pathfinder (http://javapathfinder.sourceforge.net),
> an "explicit state software model checker." The developers of JPF
> wanted
> to use it on a prototype safety-critical application that I wrote in
> Python, but JPF only works on Java code. We considered somehow using
> Jython and Jythonc, but neither did the trick. So they ended up having
> someone manually convert my Python code to Java! (The problem is that
> my code was still in flux, and the Java and Python versions have now
> diverged.)
>
> In any case, optional static typing in Python would help tremendously
> here. The hardest part of automated conversion of Python to a
> statically typed language is the problem of type inference. If the
> types are explicitly declared, that problem obviously goes away.
> Explicit typing would also greatly facilitate the development of a
> "Python Pathfinder," so the conversion would perhaps not even be
> necessary in the first place.
>
> Note also that, while "static" type checking would be ideal,
> "explicit" typing would be a major step in the right direction and
> would probably be much easier to implement. That is, provide a syntax
> to explicitly declare types, then just check them at run time. A
> relatively simple pre-processor could be implemented to convert the
> explicit type declarations into "isinstance" checks or some such
> thing. (A pre-processor command-line argument could be provided to
> disable the type checks for more efficient production runs if
> desired.)
>
> I noticed that Guido has expressed further interest in static typing
> three or four years ago on his blog. Does anyone know the current
> status of this project? Thanks.

Perhaps this: http://www.python.org/dev/peps/pep-3107/ might be
relevant?
André
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: optional static typing for Python

[Jarek Zgoda]

Russ P. pisze:

> I noticed that Guido has expressed further interest in static typing
> three or four years ago on his blog. Does anyone know the current
> status of this project? Thanks.

I thought it was april fools joke?

-- 
Jarek Zgoda
http://zgodowie.org/

"We read Knuth so you don't have to" - Tim Peters
-- 
http://mail.python.org/mailman/listinfo/python-list

optional static typing for Python

[Russ P.]

A while back I came across a tentative proposal from way back in 2000
for optional static typing in Python:

http://www.python.org/~guido/static-typing

Two motivations were given:

-- faster code
-- better compile-time error detection

I'd like to suggest a third, which could help extend Python into the
safety-critical domain:

-- facilitates automated source-code analysis

There has been much heated debate in the past about whether Python is
appropriate for safety-critical software. Some argue that, with
thorough testing, Python code can be as reliable as code in any
language. Well, maybe. But then, a famous computer scientist once
remarked that,

"Program testing can be used to show the presence of bugs, but never
to show their absence!" --Edsger Dijkstra

The next step beyond extensive testing is automated, "static" analysis
of source-code ("static" in the sense of analyzing it without actually
running it). For example, Spark Ada is a subset of Ada with
programming by contract, and in some cases it can formally prove the
correctness of a program by static analysis.

Then there is Java Pathfinder (http://javapathfinder.sourceforge.net),
an "explicit state software model checker." The developers of JPF
wanted
to use it on a prototype safety-critical application that I wrote in
Python, but JPF only works on Java code. We considered somehow using
Jython and Jythonc, but neither did the trick. So they ended up having
someone manually convert my Python code to Java! (The problem is that
my code was still in flux, and the Java and Python versions have now
diverged.)

In any case, optional static typing in Python would help tremendously
here. The hardest part of automated conversion of Python to a
statically typed language is the problem of type inference. If the
types are explicitly declared, that problem obviously goes away.
Explicit typing would also greatly facilitate the development of a
"Python Pathfinder," so the conversion would perhaps not even be
necessary in the first place.

Note also that, while "static" type checking would be ideal,
"explicit" typing would be a major step in the right direction and
would probably be much easier to implement. That is, provide a syntax
to explicitly declare types, then just check them at run time. A
relatively simple pre-processor could be implemented to convert the
explicit type declarations into "isinstance" checks or some such
thing. (A pre-processor command-line argument could be provided to
disable the type checks for more efficient production runs if
desired.)

I noticed that Guido has expressed further interest in static typing
three or four years ago on his blog. Does anyone know the current
status of this project? Thanks.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Status of optional static typing in Python?

[John Roth]

Christian Convey wrote:
> Hi guys,
>
> I'm looking at developing a somewhat complex system, and I think some
> static typing will help me keep limit my confusion.  I.e.:
>
> http://www.artima.com/weblogs/viewpost.jsp?thread=87182
>
> Does anyone know if/when that feature may become part of Python?

Optional static typing is listed as item # 3 in
PEP 3100 (Python 3.0 plans).
For a timeline, look at PEP 3000.

John Roth

>
> Thanks very much,
> Christian
>
>
> --
> Christian Convey
> Computer Scientist,
> Naval Undersea Warfare Centers
> Newport, RI
> (401) 832-6824
> [EMAIL PROTECTED]

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Status of optional static typing in Python?

[George Sakkis]

Christian Convey wrote:

> Perhaps I'm deluded but I don't think so.  I'll tell you my situation
> and I'd appreciate your take on it...
>
> I'm looking into the design a network simulator.  The simulator has a
> few requirements:
>
> (1) I need to be able to swap in a variety of replacement components
> during different simulations.  I.e., RadioFrequencyChannelModel,
> WiredNetworkChannelModel, etc.  This drives me to want the notion of
> inherited interfaces, partly as a form of documentation.
>
> (2) I want a form of encapsulation (which I realize isn't necessarily
> guaranteed in all possible static typing implementations).  I.e., I want
> to ensure that any code which accesses a ChannelModel only calls those
> methods that are part of the ChannelModel interface.  If there's a
> method RadioFrequencyChannelModel.setBroadcastDistance(...), which isn't
> part of the generic ChannelModel interface, I don't want most of my code
> to be able to start using that particular method, if the code need to be
> able to work with all possible ChannelModel implementations.
>
> (3) I like Interfaces as a matter of documentation.  It helps me to
> thing things through.  I've got a lot of components that must support
> interchangeable implementations: channels, modems, MAC layers, link
> layers, etc.  If I have an abstract MAC_layer interface, it helps me
> think carefully about what every MAC layer ought to provide, and it also
> helps me explain to other people what a MAC layer in my simulator must
> provide.  That is, it helps me better explain to other people how the
> system's major components relate to each other.

All your concerns (and several more) have been beaten to death in past
topics about the benefits and shortcomings of static typing, you can
look them up. Briefly, python doesn't prevent you from writing good
documentation and have nice, clean interfaces if you want to, and
indeed there are several Interface implementations around. Still it
doesn't force you to do so like other "pure" OO languages, which is
very handy if you don't have a crystal clear idea of how your
interfaces should be laid out in advance or if the requirements change
along the way, both very typical scenaria in the real world.

As for encapsulation, again the idea is convention rather than language
enforcement. The convention is to have all non-public elements
(attributes, methods, functions, classes, etc.) starting with a single
underscore. A client can still access it, but he takes the
responsibility of relying on an implementation feature, which is
typically less stable than the public interface.

> Now, I could use Java or C# to get functionality such as interfaces, but
> I loath giving up the general productive goodness of Python.  That's why
> I'm looking for something like interfaces.

Others have already mentioned some Interface add-on packages that you
can download and use right away; another option you may want to look
into is the type-checking module
(http://oakwinter.com/code/typecheck/).

> But even if we disagree about the wisdom of my intentions, do you know
> if/when Guido's planning to work that stuff into Python?  The last post
> I noticed from him on the topic was from 2005.  At least back then he
> sounded pretty into it.

I wouldn't count on it if I was to start a project sometime soon.
 
George

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Status of optional static typing in Python?

[Bruno Desthuilliers]

Christian Convey a écrit :
> Perhaps I'm deluded but I don't think so. 

.
You are.


> I'll tell you my situation 
> and I'd appreciate your take on it...
> 
> I'm looking into the design a network simulator.  The simulator has a 
> few requirements:
> 
> (1) I need to be able to swap in a variety of replacement components 
> during different simulations.  I.e., RadioFrequencyChannelModel, 
> WiredNetworkChannelModel, etc.  This drives me to want the notion of 
> inherited interfaces, partly as a form of documentation.

Ok.

> (2) I want a form of encapsulation (which I realize isn't necessarily 
> guaranteed in all possible static typing implementations).  I.e., I want 
> to ensure that any code which accesses a ChannelModel only calls those 
> methods that are part of the ChannelModel interface.  If there's a 
> method RadioFrequencyChannelModel.setBroadcastDistance(...), which isn't 
> part of the generic ChannelModel interface, I don't want most of my code 
> to be able to start using that particular method, if the code need to be 
> able to work with all possible ChannelModel implementations.

This is mostly a self-discipline issue. But FWIW, unit-testing should be 
enough here. And if you really want something more 
bondage-and-discipline, you can use some wrapper object to filter out 
the exposed interface. There's very few to do - here's a possible (while 
mostly dumb) home-made solution:

class InterfaceType(type):
   def __new__(meta, class_name, bases, new_attrs):
 cls = type.__new__(meta, class_name, bases, new_attrs)
 cls._exposed = [name for name in new_attrs.keys() \
 if not name.startswith('_')]
 return cls

class Interface(object):
   __metatype__ = InterfaceType
   @classmethod
   def _expose(cls, name):
 return name in cls._exposed

class InterfaceRestrictor(object):
   def __init__(self, obj, interface):
 self._interface = interface
 self._obj = obj
   def __getattr__(self, name):
 if self._interface._expose(name):
   return getattr(self._obj, name)
 else:
   raise AttributeError("name %s not allowed" % name)

And you can use a decorator specifying arg names or types -> expected 
interface to automagically ensure you get correctly wrapped objects in 
the client code.

NB : Don't use that code - here again, object-adaptation (which is at 
the core of Zope3 interfaces and Peak's Protocols) comes to mind...

> (3) I like Interfaces as a matter of documentation.  It helps me to 
> thing things through.  I've got a lot of components that must support 
> interchangeable implementations:

BTW, did I suggest to have a look at Zope3 interface or Peak's protocols ?-)

> channels, modems, MAC layers, link 
> layers, etc.  If I have an abstract MAC_layer interface, it helps me 
> think carefully about what every MAC layer ought to provide, and it also 
> helps me explain to other people what a MAC layer in my simulator must 
> provide.  That is, it helps me better explain to other people how the 
> system's major components relate to each other.

Ok, now this is a design issue. All you need here is an UML-aware 
drawing program.

> Now, I could use Java or C# to get functionality such as interfaces, but 
> I loath giving up the general productive goodness of Python.  That's why 
> I'm looking for something like interfaces.

Given your motivations and requirements (which seems pretty sensible 
AFAIC), you definitively want to have a look at Zope3 Interfaces or Peak 
Protocol. They'll give you *much* more than Java's interfaces.

> But even if we disagree about the wisdom of my intentions,

We don't. The point on which we disagree is the proposed solution !-)

> do you know 
> if/when Guido's planning to work that stuff into Python?  The last post 
> I noticed from him on the topic was from 2005.  At least back then he 
> sounded pretty into it.

I don't think this will ever make it into Python. But you really don't 
need it anyway. Well, IMHO at least !-)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Status of optional static typing in Python?

[Kay Schluehr]

Christian Convey wrote:
> Hi guys,
>
> I'm looking at developing a somewhat complex system, and I think some
> static typing will help me keep limit my confusion.  I.e.:
>
> http://www.artima.com/weblogs/viewpost.jsp?thread=87182
>
> Does anyone know if/when that feature may become part of Python?
>
> Thanks very much,
> Christian

It was discussed recently at the Python 3000 mailing list and it seems
that the goals are not very ambitious but this was already clear from
Guidos Artima blog post you cited. So it may happen that type
annotation syntax in function signatures will be introduced in Py3K but
the semantics is reduced to a "protocol" i.e. Python will still be
untyped in a strict sense ( or dynamically type checked to put it more
positive ).

An proposed alternative for type annotation syntax and runtime
type-checks that comes up from time to time is using decorators for
this job.

Here is a recipe that might be usefull in your project right now:

http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/426123

Regards,
Kay

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Status of optional static typing in Python?

[Christian Convey]

Perhaps I'm deluded but I don't think so.  I'll tell you my situation 
and I'd appreciate your take on it...

I'm looking into the design a network simulator.  The simulator has a 
few requirements:

(1) I need to be able to swap in a variety of replacement components 
during different simulations.  I.e., RadioFrequencyChannelModel, 
WiredNetworkChannelModel, etc.  This drives me to want the notion of 
inherited interfaces, partly as a form of documentation.

(2) I want a form of encapsulation (which I realize isn't necessarily 
guaranteed in all possible static typing implementations).  I.e., I want 
to ensure that any code which accesses a ChannelModel only calls those 
methods that are part of the ChannelModel interface.  If there's a 
method RadioFrequencyChannelModel.setBroadcastDistance(...), which isn't 
part of the generic ChannelModel interface, I don't want most of my code 
to be able to start using that particular method, if the code need to be 
able to work with all possible ChannelModel implementations.

(3) I like Interfaces as a matter of documentation.  It helps me to 
thing things through.  I've got a lot of components that must support 
interchangeable implementations: channels, modems, MAC layers, link 
layers, etc.  If I have an abstract MAC_layer interface, it helps me 
think carefully about what every MAC layer ought to provide, and it also 
helps me explain to other people what a MAC layer in my simulator must 
provide.  That is, it helps me better explain to other people how the 
system's major components relate to each other.


Now, I could use Java or C# to get functionality such as interfaces, but 
I loath giving up the general productive goodness of Python.  That's why 
I'm looking for something like interfaces.

But even if we disagree about the wisdom of my intentions, do you know 
if/when Guido's planning to work that stuff into Python?  The last post 
I noticed from him on the topic was from 2005.  At least back then he 
sounded pretty into it.

Thanks,
Christian

Bruno Desthuilliers wrote:
> Christian Convey a écrit :
>> Hi guys,
>>
>> I'm looking at developing a somewhat complex system, and I think some 
>> static typing will help me keep limit my confusion.  
> 
> Then I think you're suffering from an alas too common delusion. Static 
> typing (at least declarative static typing) will only makes your system 
> more complex. But if you want some help in managing complexity, you may 
> want to look at interfaces systems (Zope3 interfaces or Peak's Protocol) 
> and multidispatch (Peak's Protocol dispatch package).
> 

-- 
Christian Convey
Computer Scientist,
Naval Undersea Warfare Centers
Newport, RI
(401) 832-6824
[EMAIL PROTECTED]
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Status of optional static typing in Python?

[Bruno Desthuilliers]

Christian Convey a écrit :
> Hi guys,
> 
> I'm looking at developing a somewhat complex system, and I think some 
> static typing will help me keep limit my confusion.  

Then I think you're suffering from an alas too common delusion. Static 
typing (at least declarative static typing) will only makes your system 
more complex. But if you want some help in managing complexity, you may 
want to look at interfaces systems (Zope3 interfaces or Peak's Protocol) 
and multidispatch (Peak's Protocol dispatch package).

-- 
http://mail.python.org/mailman/listinfo/python-list

Status of optional static typing in Python?

[Christian Convey]

Hi guys,

I'm looking at developing a somewhat complex system, and I think some 
static typing will help me keep limit my confusion.  I.e.:

http://www.artima.com/weblogs/viewpost.jsp?thread=87182

Does anyone know if/when that feature may become part of Python?

Thanks very much,
Christian


-- 
Christian Convey
Computer Scientist,
Naval Undersea Warfare Centers
Newport, RI
(401) 832-6824
[EMAIL PROTECTED]
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Optional Static Typing: Part II

[Carl Banks]

John Roth wrote:
> http://www.artima.com/weblogs/viewpost.jsp?thread=86641

Nitpicking: I don't think he's necessarily in good company w.r.t. types
vs classes.  Take Ada, for example.   In Ada, a class is a set of types
(in particular, the type and all its subtypes), which is kind of the
opposite way Guido claims to see it.  Not the Ada is relevant, and not
that there is ever any agreement on terminology in computer science,
but still.

Based on their English language meanings, I would tend to agree with
Ada's terminology.  But, based on how the terminology developed for
computer languages (especially under the influence of C++), it seems
that most people would regard class as more of an implementation.

Another question: can anyone think of something an interface statement
could syntactically that an interface metaclass couldn't?  I couldn't
think of anything, based on the description, and it's not like th BDFL
to throw out keywords for things that current syntax can handle.  It
leads me to suspect that maybe he has something up his sleeve.  Hmm.
-- 
CARL BANKS

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Optional Static Typing: Part II

[Michael Hobbs]

John Roth <[EMAIL PROTECTED]> wrote:
> Now, the base objective seems to be to incorporate PyChecker
> functionality into the root. This in turn requires type inference,
> which in turn strongly suggests type annotations to help the
> inferencer out over rough spots.
> 
> I like this approach a lot.

If he makes the type inferencer "proud", that might help alleviate
the fears around here that it will become standard practice to put
type annotations on everything. That is, if you explicitly annotate
a function in the same way that the inferencer would have inferenced
it, the PyChecker thingie would emit a message saying:

"I'm no dummy! I could have told you that foo() takes an 'int' and
returns a 'bool'. What do you think I am, stupid? Duuu-uhhh!"

:)

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Optional Static Typing: Part II

[Roman Suzi]

On Tue, 4 Jan 2005, John Roth wrote:

>Guido has posted a second blog entry on the optional static typing
>initiative.
>I like this a lot better than the first.

Declarative approach is even more human-oriented than algorithmic one.
If Python is to support declarations, let it support declarative programming
paradigm with full-blown inference engine .

So, why not add some logic approach to type declarations? I hope
that "type" is understood in a generic programming way: it will be a
big win for Python to provide grounds for GP 'concept' concept ;)
Why not? Python program right now are nearer to GP than C++'s.
'Concept' is not mere "interface", but interface + semantic behaviour.
And to describe that behaviour logic is needed (right now it could be done
with asserts).

I propose to skip 'interface' support with Python and go stright to
GP concepts :>

This way Python will be ahead with innovation and type/interface/concept
declarations will not be seen as atavisms but a step forward from OOP.

I hope GvR waited so long not implementing interfaces to implement something
better, concepts for example ;-) Right now concepts are expressed informally
in the docstrings.


Sincerely yours, Roman Suzi
-- 
[EMAIL PROTECTED] =\= My AI powered by GNU/Linux RedHat 7.3
-- 
http://mail.python.org/mailman/listinfo/python-list

Optional Static Typing: Part II

[John Roth]

Guido has posted a second blog entry on the optional static typing 
initiative.
I like this a lot better than the first.

http://www.artima.com/weblogs/viewpost.jsp?thread=86641
Now, the base objective seems to be to incorporate PyChecker
functionality into the root. This in turn requires type inference,
which in turn strongly suggests type annotations to help the
inferencer out over rough spots.
I like this approach a lot.
There's also an explicit recognition that there are a lot of
use cases for being able to access type information at
run time.
I also like this. I'm kind of neutral to the idea of using it
for actual type checking: I don't think that it catches that
many errors if the developer is doing a decent job of
testing. However, since it's going to be supplemental to
type inference, it will be a lot less intrusive.
There's a new approach to interfaces that looks
intriguing. One nice part is the ability to include
Design By Contract type preconditions with the
interface. It will be even better if they can be checked
at compile time, or by the PyChecker functionality.
I have to say this turned my attitude around on the
subject: I'm quite in favor of the direction Guido
seems to be going.
John Roth
--
http://mail.python.org/mailman/listinfo/python-list

Re: Optional Static Typing

[Jacek Generowicz]

[EMAIL PROTECTED] (Alex Martelli) writes:

> I've always liked the (theoretical) idea that assertions (including of
> course contracts) could be used as axioms used to optimize generated
> code, rather than (necessarily) as a runtime burden.  E.g. (and I don't
> know of any implementation of this concept, mind you), inferring (e.g.
> from such assertions) that x>=0, and that y<0, the compiler could simply
> cut away a branch of dead code guarded by "if x warning, in this case;-)...

A few months ago, a troll challenged the denizens of comp.lang.lisp to
write a Lisp implementation of some some code which he posted in C++,
which would be competitive in terms of speed with his C++
version. The c.l.lers duly obliged, and, IIRC, it so happened that the
improvement that made the Lisp version overtake the C++ one was the
declaration of some variable to be of type "floating point number in
the range 0 to two Pi".

Of course, in CL type declarations are not contracts, but promises to
the compiler ... but it's still an examlpe of a situation where more
specific type information allowed the compiler to produce more
efficient code, in practice.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Optional Static Typing

[Ville Vainio]

> "Ryan" == Ryan Paul <[EMAIL PROTECTED]> writes:

Ryan> I wrote a blog post this morning in which I briefly argue
Ryan> using DbC and predicate based argument constraints instead
Ryan> of static typing. Take a look

I took a look. The first impression is that there is too much stuff to
be added to the language, for a relatively unproven methodology (DbC).

Yes, observe the herecy in my argument; I'm indeed referring to DbC as
being an unproven way to write software. Eiffel never really made it,
and explicit preconditions/postconditions haven't really appeared in
other languages either. I'm not sure I'd like to see Python (which is
not an academic language) take the risk of bloating the language
definition with it. Let Ruby, or Boo, or whatever have a go before
Python. And yes, I've read my OOSC, and my code has its share of
asserts.

Type declarations, on the other hand, are as mainstream as one can
get. Being optional, they would not brutally murder the spirit of all
the good that is Python, contrary to the doom and gloom people have
been painting here and elsewhere. The implementation of CPython would
become more complex, but I trust the people that are implementing it
enough to not be overly concerned.

-- 
Ville Vainio   http://tinyurl.com/2prnb
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Optional Static Typing

[Ryan Paul]

On Thu, 23 Dec 2004 01:49:35 -0800, bearophileHUGS wrote:

> 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 wrote a blog post this morning in which I briefly argue using DbC and
predicate based argument constraints instead of static typing. Take a look
if you are interested. It also contains a link to a wiki page where I have
been producing a more refined specification complete with good examples:

http://www.cixar.com/segphault/pytype.html

I would appreciate some feedback, I want to know what other python
programmers think about DbC and arg constraints.

-- SegPhault
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Optional Static Typing - Haskell?

[Robin Becker]

Scott David Daniels wrote:

Then you need "Scott and Dave's Programming Language" -- SAD/PL.
By providing separate data types for even and odd numbers, you can
avoid off-by-one errors ;-)
mmmhhh off by two-licious
--
Robin Becker
--
http://mail.python.org/mailman/listinfo/python-list

Re: Optional Static Typing

[Ville Vainio]

> "Alex" == Alex Martelli <[EMAIL PROTECTED]> writes:

Alex> I've always liked the (theoretical) idea that assertions
Alex> (including of course contracts) could be used as axioms used
Alex> to optimize generated code, rather than (necessarily) as a
Alex> runtime burden.  E.g. (and I don't know of any
Alex> implementation of this concept, mind you), inferring (e.g.
Alex> from such assertions) that x>=0, and that y<0, the compiler
Alex> could simply cut away a branch of dead code guarded by "if
Alex> x y
  if x < y:
blah(y,x)

needs a slap on the wrists anyway. Doing "if x < y" in blah() would
make sense, but then there would need to be a special version of
blah()...
  
I could think of one worthwhile example as well:

def foo(l):
  assert issorted(l)
  if "hi" in l:   # in does a bsearch because the list is sorted
blah()

but things like this probably belong to languages like Lisp where the
user gets to expand and mess with the compiler.

-- 
Ville Vainio   http://tinyurl.com/2prnb
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Optional Static Typing

[Robert Kern]

Luis M. Gonzalez wrote:
Robert Kern wrote:
Starkiller, at least, can deal with cases where a variable might be one 
of a set of types and generates code for each of this set. Explicit type 
declarations can help keep these sets small and reduces the number of 
times that Starkiller needs to fall back to PyObject_* calls.
Will we be able to see it anytime soon?
I'm eagerly waiting for its release.
It's been "about a month away" for at least 4 months now. I don't know 
what the holdup has been. I know that Michael has graduated and so he's 
probably been busy with a new job.

--
Robert Kern
[EMAIL PROTECTED]
"In the fields of hell where the grass grows high
 Are the graves of dreams allowed to die."
  -- Richard Harter
--
http://mail.python.org/mailman/listinfo/python-list

Re: Optional Static Typing - Haskell?

[Scott David Daniels]

Michael Hobbs wrote:
I've always found that with Haskell, if I can get my program to
compile without error, it usually runs flawlessly. (Except for the
occasional off-by-one error. :-)
Then you need "Scott and Dave's Programming Language" -- SAD/PL.
By providing separate data types for even and odd numbers, you can
avoid off-by-one errors ;-)
--Tongue-in-cheek-ily-yours,
Scott David Daniels
[EMAIL PROTECTED]
--
http://mail.python.org/mailman/listinfo/python-list

Re: Optional Static Typing

[Alex Martelli]

Michael Hobbs <[EMAIL PROTECTED]> wrote:

> Your proposition reminds me very much of Design by Contract, which is
> a prominent feature of the Eiffel programming language. Considering
> that Python is an interpreted language where type checking would
> naturally occur at runtime, I think Design by Contract would be more
> appropriate than static typing.

I entirely agree with this opinion.

> In a function's contract, not only could it state that its parameter
> must be an integer,

I'd like to be able to state something about the *INTERFACE* of the
parameter, to the rigorous exclusion of its *TYPE* (which is an
"implementation detail").  I doubt it's really feasible, but, in Haskell
terms, I'd love for such assertions to be always and necessarily about
_typeclasses_ rather than _types_...

> but also that it must be > 50 and be divisible by
> 7. If a value is passed to the function that violates the contract,
> it raises an exception.
> 
> In Eiffel, contract checking can be turned on or off based on a 
> compiler flag or a runtime switch.

I've always liked the (theoretical) idea that assertions (including of
course contracts) could be used as axioms used to optimize generated
code, rather than (necessarily) as a runtime burden.  E.g. (and I don't
know of any implementation of this concept, mind you), inferring (e.g.
from such assertions) that x>=0, and that y<0, the compiler could simply
cut away a branch of dead code guarded by "if xhttp://mail.python.org/mailman/listinfo/python-list

Re: Optional Static Typing

[Alex Martelli]

Donn Cave <[EMAIL PROTECTED]> wrote:
   ...
> > > 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 .
> 
> Wait a minute, isn't he same fellow whose precious
> dependency inversion principle shows us the way to
> support fully modular programming?  What would he

Yep, just the same guy (also responsible for Dynamic Visitor, et al).

> say about unit testing to catch up with changes in
> dependent modules, do you think?  Do we have a
> combinatorial explosion potential here?

I can't do justice to all he has to say about these issues, and many
others related to Agile development methods -- you should really get his
book (he's written several, but, in my opinion, it's his masterpiece --
), or, failing that, at least read his essays at
 (I would skip all of the silly 'craftsman'
fictionalization he's writing for 'Software Development', but I guess
_some_ people must be into that...).


Alex
 
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Optional Static Typing

[Donn Cave]

In article <[EMAIL PROTECTED]>,
 [EMAIL PROTECTED] (Alex Martelli) wrote:

> John Roth <[EMAIL PROTECTED]> wrote:
>...
> > 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 .

Wait a minute, isn't he same fellow whose precious
dependency inversion principle shows us the way to
support fully modular programming?  What would he
say about unit testing to catch up with changes in
dependent modules, do you think?  Do we have a
combinatorial explosion potential here?

   Donn Cave, [EMAIL PROTECTED]
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Optional Static Typing - Haskell?

[Michael Hobbs]

Neal D. Becker <[EMAIL PROTECTED]> wrote:
> I've just started learning about Haskell.  I suggest looking at this for an
> example.
> 
> A good intro: http://www.haskell.org/tutorial
> 

I've always found that with Haskell, if I can get my program to
compile without error, it usually runs flawlessly. (Except for the
occasional off-by-one error. :-) I don't know if that's due to the
fact that Haskell enforces pure functional programming, or if it's
due to Haskell's strict static typing, or the combination of the
two. But if anyone ever demanded that I wrote code that absolutely 
positively has to work, no matter the cost, I would probably choose
Haskell.

Tying Haskell back to Python, if static type checking ever is 
grafted on to Python, I would propose that it uses type inference,
a la Haskell or O'Caml, and raise an Error only when it detects a
truly unmistakable type error. This may be easier said than done,
however, given Python's dynamic nature. For example, a class's
method may be re-bound to any other function at runtime, which would
wreak havoc on any static type checker.

- Mike

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Optional Static Typing

[Michael Hobbs]

Rahul <[EMAIL PROTECTED]> wrote:
> I am assuming that optional type checking is being added for easier
> debugging only. So if 'expects' are turned on , python raises
> warnings(which do not halt the system) but not when they are turned
> off. These will enable easier debugging for new people while not
> affecting masters. Also,perhaps, it will be easier to accomodate till
> type checking mechanism is perfected(if it is implemented at all that
> is) so that python does not stop you when it is in fact  python which
> might be making some mistake.(This last statement is a guess only...)
> 
> It is similar to assert and __debug__=1 in a way.
> 
> So the crux is :
> 1.Expects is only a bridge between type checking and dynamic typing.
> 2.Type checking is done only as a tool which you are free to override
> if you want to.
> 3.The objective of type checking here is only to make debugging easier
> and not speed/optimization.
> 4.The point is not that 'expects' be a additional keyword.You can go
> like this also :
> def (int a,int b): or whatever you like. Only that expects make it a
> bit clearer IMHO.
> 
> sincerely.,
> rahul

Your proposition reminds me very much of Design by Contract, which is
a prominent feature of the Eiffel programming language. Considering
that Python is an interpreted language where type checking would
naturally occur at runtime, I think Design by Contract would be more
appropriate than static typing.

In a function's contract, not only could it state that its parameter
must be an integer, but also that it must be > 50 and be divisible by
7. If a value is passed to the function that violates the contract,
it raises an exception.

In Eiffel, contract checking can be turned on or off based on a 
compiler flag or a runtime switch.

- Mike

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Optional Static Typing - Haskell?

[Mike Meyer]

"Donn Cave" <[EMAIL PROTECTED]> writes:

> Quoth Mike Meyer <[EMAIL PROTECTED]>:
> | [EMAIL PROTECTED] (Alex Martelli) writes:
> ...
> |> But then, the above criticism applies: if interface and implementation
> |> of a module are tightly coupled, you can't really do fully modular
> |> programming AND static typing (forget type inferencing...).
> |
> | I beg to differ. Eiffel manages to do this quite well. Then again,
> | every Eiffel environment comes with tools to extract the interface
> | information from the code. With SmartEiffel, it's a command called
> | "short". Doing "short CLASSNAME" is like doing "pydoc modulename",
> | except that it pulls routine headers and DbC expression from the code,
> | and not just from comments.
>
> And you probably think Eiffel supports fully modular programming, as
> I thought Objective CAML did.  But Alex seems not to agree.
>
> The way I understand it, his criteria go beyond language level semantics
> to implementation details, like whether a change to a module may require
> dependent modules to be recompiled when they don't need to be rewritten.
> I don't know whether it's a reasonable standard, but at any rate hopefully
> he will explain it better than I did and you can decide for oneself whether
> it's an important one.

I read through his explanation. And the answer for Eiffel is, of
course, "it depends".

There's an optimization that embeds a class data directly in the
cilent class - the expanded keyword. If you have an expanded variable
or type in your client class, then changing the implementation of the
provider may require recompilation of the client. On the other hand,
that's pretty much an optimization, and so you shouldn't run into it
during development.

SmartEiffel, on the other hand, always does full-source analysis. It
drops class features that aren't used by any client, so changing the
client can cause the provider to be recompiled.

 http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Optional Static Typing

[Luis M. Gonzalez]

Robert Kern wrote:
> Starkiller, at least, can deal with cases where a variable might be
one
> of a set of types and generates code for each of this set. Explicit
type
> declarations can help keep these sets small and reduces the number of

> times that Starkiller needs to fall back to PyObject_* calls.

Will we be able to see it anytime soon?
I'm eagerly waiting for its release.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Optional Static Typing - Haskell?

[Alex Martelli]

Donn Cave <[EMAIL PROTECTED]> wrote:
   ...
> And you probably think Eiffel supports fully modular programming, as
> I thought Objective CAML did.  But Alex seems not to agree.

Rather, I would say it's Dr Van Roy and Dr Haridi who do not agree;
their definition of "truly open programming" being quite strict, based
on modules "not having to know anything about each other".  BTW, while I
have looked into Alice yet, some people posting on this thread
apparently have -- I know the Alice whitepaper claims Alice adds to ML
just what is needed to support "truly open programming" -- features that
OCAML doesn't have, so, if the Alice researchers are right, your
assessment of OCAML is wrong; OTOH, since Alice _is_ statically typed
like any other ML dialect, they'd appear to rebut Van Roy and Haridi's
contention, too.  VR & H do mention Alice at the end of their pages
about static vs dynamic typing but they don't appear to acknowledge the
claim.  Maybe it all boils down to both Oz and Alice being still open
research efforts, making it difficult to assess fully what results they
can eventually achieve.


> The way I understand it, his criteria go beyond language level semantics
> to implementation details, like whether a change to a module may require
> dependent modules to be recompiled when they don't need to be rewritten.

Ah yes, definitely: Lakos' "Large Scale C++ Software Design" was the
first place where I met a thorough exposition of the evil effects that
come from modules "just needing to be recompiled, not rewritten" as soon
as the number of modules becomes interestingly large, at least with the
kind of dependency graphs that naturally emerge when designers are
focused on all other important issues of software design rather than
dependency control.

Basically, what emerges from Lakos' analysis, and gets formalized in
Robert Martin's precious "dependency inversion principle", is the
equivalent of the interface/implementation separation that you always
get e.g. in Corba, by writing the interface in IDL and the
implementation in whatever language you wish: both implementation and
client modules depend on an abstract-interface module, so the dependency
arrows go the "right" way (concrete depends on abstract) and the cycle
is more tractable.  But if you proceed by extracting the abstract
interface from a concrete implementation, that's a dependency too
(albeit for a tool that's not the compiler), and it's the wrong way
around... abstract depends on concrete.  (Main hope being that the
abstract part changes VERY rarely -- when it DOES change, the rebuild
cost is still potentially out of control).

You may use a separate language to express the interface (IDL,
whatever), you may use a subset of the implementation language with
strict constraints, but one way or another, if you want to control your
dependency graph and avoid the ills Lakos points out so clearly,
dependency inversion is an indispensable (perhaps not sufficient) tool.

Mike points out this breaks "once and only once", but then that same
principle is broken in any language where you express the type of a
variable twice -- in declaring AND in using it -- as is typical of most
statically-typed languages (even where the language does not mandate the
redundancy, as in *ML or Haskell, typical style in such languages is to
have the redundancy anyway; and AFAIK Eiffel _does_ mandate the
redundancy, just like C++ or Java do).

Dynamic languages have dependencies too, maybe not "reified" but
conceptually, _operationally_ there.  For example, if you consider the
contract (as in DbC) to be part of a type, that's how Eiffel works: it
diagnoses the type violation (breach of contract) dynamically, at
runtime.  And that's how's Oz, Python, Ruby, Erlang, etc etc, work too:
no type (signature, contract, ...) violation along any dependency arrow
need pass silently, they're diagnosed dynamically just like DbC
violations in Eiffel or more generally violations of other constraints
which a given language chooses not to consider "type-related" (e.g., if
the positive-reals are a separate type from general reals, sqrt(x) with
x<0 is a type violation -- if there's only a general reals type, it's
not -- hopefully, it's diagnosed at runtime, though).

Robert Martin's "Dynamic Visitor" design pattern is, I believe, an
instructive case.  The classic "Visitor", per se, has intractable
dependency problems and cannot possibly respect fully the open/closed
principle; Dynamic Visitor uses the escapes to dynamic typing allowed by
such tools as C++'s dynamic_cast (and Java's own casts, which work quite
similarly) to ensure a sane dependency structure.  If you don't have or
don't allow any escape from static typing, Visitor is somewhat of a
nightmare DP as soon as the kinds of visitors and visitees start
multiplying -- at the very least it's a build-time nightmare, even if
your language has tricks to save the need to change the code.  Martin
does a much more thorough job of exploring thes

Re: Optional Static Typing - Haskell?

[Donn Cave]

Quoth Mike Meyer <[EMAIL PROTECTED]>:
| [EMAIL PROTECTED] (Alex Martelli) writes:
...
|> But then, the above criticism applies: if interface and implementation
|> of a module are tightly coupled, you can't really do fully modular
|> programming AND static typing (forget type inferencing...).
|
| I beg to differ. Eiffel manages to do this quite well. Then again,
| every Eiffel environment comes with tools to extract the interface
| information from the code. With SmartEiffel, it's a command called
| "short". Doing "short CLASSNAME" is like doing "pydoc modulename",
| except that it pulls routine headers and DbC expression from the code,
| and not just from comments.

And you probably think Eiffel supports fully modular programming, as
I thought Objective CAML did.  But Alex seems not to agree.

The way I understand it, his criteria go beyond language level semantics
to implementation details, like whether a change to a module may require
dependent modules to be recompiled when they don't need to be rewritten.
I don't know whether it's a reasonable standard, but at any rate hopefully
he will explain it better than I did and you can decide for oneself whether
it's an important one.

Donn Cave, [EMAIL PROTECTED]
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Optional Static Typing

[Robert Kern]

Luis M. Gonzalez wrote:
Robert Kern wrote:
Automatic type inferencing is great, but sometimes the inference is
"object". Being able to supply more information about types helps
Starkiller keep the inferences tight and specific.

Hmm... I'm not an expert in this subject at all, but I think that when
the  inference is "object", as you said, is because the type couldn't
be inferred so it defaults to object, which is the more general type of
all.
For example, this is what happens in Boo, which is the only language I
know (a little bit) that uses type inference.
Starkiller, at least, can deal with cases where a variable might be one 
of a set of types and generates code for each of this set. Explicit type 
declarations can help keep these sets small and reduces the number of 
times that Starkiller needs to fall back to PyObject_* calls.

--
Robert Kern
[EMAIL PROTECTED]
"In the fields of hell where the grass grows high
 Are the graves of dreams allowed to die."
  -- Richard Harter
--
http://mail.python.org/mailman/listinfo/python-list

Re: Optional Static Typing - Haskell?

[Mike Meyer]

[EMAIL PROTECTED] (Alex Martelli) writes:

> Mike Meyer <[EMAIL PROTECTED]> wrote:
>> [EMAIL PROTECTED] (Alex Martelli) writes:
>> > Mind you, I personally _like_ the concept of describing
>> > an interface separately, even in a different language (Corba's IDL, say)
>> > that's specialized for the task.  But it doesn't seem to be all that
>> > popular... without such separation, modularity plus static checking
>> > appears to imply bottom->up coding: you need to compile modules in some
>> > topologically sorted order compatible with the "X uses Y" relation.
>> Personally, I hate declaring the interface separately, whether in the
>> same language or another language. 
> Yeah, so do many people -- as I mentioned, it's not all that popular.
> Personally, I don't see _why_

Because it violates the principle of "Once and only once". If the
interface is described in two places, that means it's possible to
update one and forget to update the other. That's not possible if the
interface is defined once and only once. I've forgotten to update my
IDL more than once.

> But then, the above criticism applies: if interface and implementation
> of a module are tightly coupled, you can't really do fully modular
> programming AND static typing (forget type inferencing...).

I beg to differ. Eiffel manages to do this quite well. Then again,
every Eiffel environment comes with tools to extract the interface
information from the code. With SmartEiffel, it's a command called
"short". Doing "short CLASSNAME" is like doing "pydoc modulename",
except that it pulls routine headers and DbC expression from the code,
and not just from comments.

>> On the other hand, generating the
>> interface information from the code for type checking (and
>> documentation) purposes makes an incredible amount of sense. A type
>> inferencing engine to generate that information from Python code -
>> with possible a bit of human assistance - would make it possible to
>> use pychecker to catch duck typing errors without having to import an
>> entire module.
> And why should it be a problem to "import an entire module", pray?

It isn't. I was just thinking out loud. If you had a type inferencing
engine that created the type signatures of everything in a module,
that would let you do type checking without importing the module. It's
actually more interesting for compiled languages than for interpreted
ones.

  http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Optional Static Typing

[Luis M. Gonzalez]

Robert Kern wrote:
> Automatic type inferencing is great, but sometimes the inference is
> "object". Being able to supply more information about types helps
> Starkiller keep the inferences tight and specific.

Hmm... I'm not an expert in this subject at all, but I think that when
the  inference is "object", as you said, is because the type couldn't
be inferred so it defaults to object, which is the more general type of
all.
For example, this is what happens in Boo, which is the only language I
know (a little bit) that uses type inference.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Optional Static Typing - Haskell?

[Alex Martelli]

Mike Meyer <[EMAIL PROTECTED]> wrote:

> [EMAIL PROTECTED] (Alex Martelli) writes:
> 
> > Mind you, I personally _like_ the concept of describing
> > an interface separately, even in a different language (Corba's IDL, say)
> > that's specialized for the task.  But it doesn't seem to be all that
> > popular... without such separation, modularity plus static checking
> > appears to imply bottom->up coding: you need to compile modules in some
> > topologically sorted order compatible with the "X uses Y" relation.
> 
> Personally, I hate declaring the interface separately, whether in the
> same language or another language. 

Yeah, so do many people -- as I mentioned, it's not all that popular.
Personally, I don't see _why_, but there's no doubt that the market is
speaking quite loudly in this respect; the concept of using IDL is seen
as a handicap of (e.g.) Corba and pure COM (while I agree with Don Box's
lavish _praise_ for that concept in a COM context!), and the concept of
not having an interface separate from the implementation is touted as a
plus of (e.g.) Java vs C++.

But then, the above criticism applies: if interface and implementation
of a module are tightly coupled, you can't really do fully modular
programming AND static typing (forget type inferencing...).


> On the other hand, generating the
> interface information from the code for type checking (and
> documentation) purposes makes an incredible amount of sense. A type
> inferencing engine to generate that information from Python code -
> with possible a bit of human assistance - would make it possible to
> use pychecker to catch duck typing errors without having to import an
> entire module.

And why should it be a problem to "import an entire module", pray?  I
just fail to see any BIG advantage here.  Sure, you could extend pydoc
to generate a bit more docs than it already does -- big deal.  How much
would that augment your overall productivity?  5%?  10%?  Some tiny
incremental amount, anyway.  If it prompts you to do less unit testing,
it might even have a negative lifecycle-productivity impact;-).


Alex
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Optional Static Typing

[Robert Kern]

Luis M. Gonzalez wrote:
I don't understand why this discussion on optional static typing came
up right at this moment.
As far as I know, it has been discussed many times in the past, and
there even was a SIG that simply died... but it seems that it never was
something of much interest to python developers (that's my impression,
I might be wrong).
Now, that the Pypy project is steadily advancing (and which is aimed at
making Python faster while keeping it dynamic and simple), why has this
topyc been raised?
Also there's starkiller, which deals with agressive type inference and
compilation to native code. If these projects are serious and are well
headed, then I don't know why we are talking now of static typing.
Lets say that Pypy and/or Starkiller end up as succesful projects, what
would be the advantage of having static typing in Python?
Starkiller would *love* type declarations. In Michael Salib's words (to 
my recollection), "every piece of type information helps." I'm sure that 
PyPy's code generator(s) could use this information to good effect, too.

Automatic type inferencing is great, but sometimes the inference is 
"object". Being able to supply more information about types helps 
Starkiller keep the inferences tight and specific.

--
Robert Kern
[EMAIL PROTECTED]
"In the fields of hell where the grass grows high
 Are the graves of dreams allowed to die."
  -- Richard Harter
--
http://mail.python.org/mailman/listinfo/python-list

Re: Optional Static Typing - Haskell?

[Mike Meyer]

[EMAIL PROTECTED] (Alex Martelli) writes:

> Mind you, I personally _like_ the concept of describing
> an interface separately, even in a different language (Corba's IDL, say)
> that's specialized for the task.  But it doesn't seem to be all that
> popular... without such separation, modularity plus static checking
> appears to imply bottom->up coding: you need to compile modules in some
> topologically sorted order compatible with the "X uses Y" relation.

Personally, I hate declaring the interface separately, whether in the
same language or another language. On the other hand, generating the
interface information from the code for type checking (and
documentation) purposes makes an incredible amount of sense. A type
inferencing engine to generate that information from Python code -
with possible a bit of human assistance - would make it possible to
use pychecker to catch duck typing errors without having to import an
entire module.

 http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Optional Static Typing

[Luis M. Gonzalez]

> > I don't understand why this discussion on optional static typing
came
> > up right at this moment.
>
> Because Guido made some notes on it.
>
> http://www.artima.com/weblogs/viewpost.jsp?thread=85551
>
> merry christmas.
> Stephen.

Yes, I know Guido did it.
But I wonder why at this moment, just when things seem to be directed
in a complete opposite way and with good chance of success (as I said:
Pypy, Starkiller, etc).

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Optional Static Typing

[Rahul]

I am assuming that optional type checking is being added for easier
debugging only. So if 'expects' are turned on , python raises
warnings(which do not halt the system) but not when they are turned
off. These will enable easier debugging for new people while not
affecting masters. Also,perhaps, it will be easier to accomodate till
type checking mechanism is perfected(if it is implemented at all that
is) so that python does not stop you when it is in fact  python which
might be making some mistake.(This last statement is a guess only...)

It is similar to assert and __debug__=1 in a way.

So the crux is :
1.Expects is only a bridge between type checking and dynamic typing.
2.Type checking is done only as a tool which you are free to override
if you want to.
3.The objective of type checking here is only to make debugging easier
and not speed/optimization.
4.The point is not that 'expects' be a additional keyword.You can go
like this also :
def (int a,int b): or whatever you like. Only that expects make it a
bit clearer IMHO.

sincerely.,
rahul

Scott David Daniels wrote:
> Rahul wrote:
> > 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  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
> [EMAIL PROTECTED]

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Optional Static Typing

[Just]

In article <[EMAIL PROTECTED]>,
 moma <[EMAIL PROTECTED]> wrote:

> What about this?
> u'int() = t, 6, 7,

What about this?

u'int() = t, 6, 7,'

...which is valid Python today.

Just
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Optional Static Typing

[moma]

[EMAIL PROTECTED] wrote:
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:
I want to introduce a shorter syntax form:
Declare variables
a'int
a'int = 13  
s'string = "Santana"
d'float
def min(a'int,  b'int)'int:
   c'int# Declare a local variable c of type int
   c = a
   ...
*
The (template) notation is very useful.
def min(a'T, b'T)'T:
c'T
c = a

f'float = min(1.2, 2.2)
i'int = min(9, f)  ## of course: comiler adds int(f) type conversion
*
But these 2 should be syntactically wrong. The type of T is not obvious.
def max(a'int, b'int)'T:
   
def max(a, b)'T:
   
*
The big question is how to handle combound data types (container 
objects) ?  lists, tuples, maps...

Can a list contain various data types?
>>> h=['abc', 13, (9,8)]
# Declare h as list of ints
h'int[] = [1, 8, 991]
# These declarations produce syntax errors
h'int = [1, 8, 991]
error: h is a scalar not container
h'int[] = ['abc', 13, (9,8)]
 ^^
error: expecting int value
*
Tuples
A general sequence
t = 1, 3, 4,
A tuple of ints
t'int() = 1, 3, 4,
What about this?
u'int() = t, 6, 7,
Yes, it's OK.  because the basic_scalar_values are ALL ints.
>>>print u
((1,3,4), 6,7)
Maps
.
*
I think the compiler should allow typeless containers even you compile 
with --strict option.  Apply --strict (strictly) to scalar types only.

*
class A:
  pass
def func1(h'A)
 # Expects (instance) A or any subclass of A
  
*
// moma
   http://www.futuredesktop.org/OpenOffice.html

--
http://mail.python.org/mailman/listinfo/python-list

Re: Optional Static Typing

[gabriele renzi]

Mike Meyer ha scritto:
"John Roth" <[EMAIL PROTECTED]> writes:

<[EMAIL PROTECTED]> wrote in message
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.
I also think some smalltalk allow you to tag stuff with type hints for 
performance.

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?
for documentation and 'crash early' purposes, I'd say.
Btw, why don't we rip out the approach of CL and some schemes that offer 
optional typing ? (not that I understand how those work, anyway)
--
http://mail.python.org/mailman/listinfo/python-list

Re: Optional Static Typing - Haskell?

[Alex Martelli]

Donn Cave <[EMAIL PROTECTED]> wrote:
   ...
> | 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...).
> 
> Well, I would assume that a modules in a static system would present
> a typed external interface, and inference would apply only within the
> module being compiled.
   ...
> There might be tricky spots, but I imagine the Objective CAML
> folks would object to an assertion like "making a really modular
> system work with static typing and inferencing is probably
> impossible"!

It seems to me that you just restated in the first part I quoted what
you say in the second part OCAML folks would object to.  If you give up
on type inferencing across modules, and only have type inferencing
inside each module, then you're getting little mileage out of the
inferencing if your modules are many and small.

But let me quote Van Roy and Haridi, rather than paraphrasing them, lest
I fail to do them justice -- I think quoting 8 lines out of a book of
over 800 pages is "fair use" (anecdote: my Xmas gift is said book, my
wife's a real-bargain Powerbook 15" Titanium laptop -- yesterday we
weighed them against each other and determined the book's heavier;-)...

"""
Dynamic typing makes it a trivial matter to do separate compilation,
i.e. modules can be compiled without knowing anything about each other.
This allows truly open programming, in which independently written
modules can come together at runtime and interact with each other.  It
also makes program development scalable, i.e., extremely large programs
can be divided into modules that can be recompiled individually without
recompiling other modules.  This is harder to do with static typing
because the type discipline must be enforced across module boundaries.
"""

I see that by paraphrasing and summarizing by heart I was changing their
argument a bit, from 'enforcing the type discipline' (which is what
they're discussing, and is obviously mandatory if you want to talk about
static typing) to 'type inferencing' (which they don't discuss in this
specific paragraph).  Nor do they claim 'probably impossible', since
they're only discussing enforcement, not inferencing -- just 'harder'.

Essentially, to compile a module under static typing you need full type
information for other modules -- the "without knowing anything about
each other" condition of fully separate compilation can't hold, and thus
neither can the "truly open programming" and "scalable development"
consequences.  Mind you, I personally _like_ the concept of describing
an interface separately, even in a different language (Corba's IDL, say)
that's specialized for the task.  But it doesn't seem to be all that
popular... without such separation, modularity plus static checking
appears to imply bottom->up coding: you need to compile modules in some
topologically sorted order compatible with the "X uses Y" relation.


Alex
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Optional Static Typing

[Stephen Thorne]

On 24 Dec 2004 21:35:24 -0800, Luis M. Gonzalez <[EMAIL PROTECTED]> wrote:
> I don't understand why this discussion on optional static typing came
> up right at this moment.

Because Guido made some notes on it.

http://www.artima.com/weblogs/viewpost.jsp?thread=85551

merry christmas.
Stephen.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Optional Static Typing

[Luis M. Gonzalez]

I don't understand why this discussion on optional static typing came
up right at this moment.
As far as I know, it has been discussed many times in the past, and
there even was a SIG that simply died... but it seems that it never was
something of much interest to python developers (that's my impression,
I might be wrong).

Now, that the Pypy project is steadily advancing (and which is aimed at
making Python faster while keeping it dynamic and simple), why has this
topyc been raised?

Also there's starkiller, which deals with agressive type inference and
compilation to native code. If these projects are serious and are well
headed, then I don't know why we are talking now of static typing.

Lets say that Pypy and/or Starkiller end up as succesful projects, what
would be the advantage of having static typing in Python?

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Optional Static Typing - Haskell?

[Donn Cave]

Quoth [EMAIL PROTECTED] (Alex Martelli):
| Donn Cave <[EMAIL PROTECTED]> wrote:
...
| > 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...).

Well, I would assume that a modules in a static system would present
a typed external interface, and inference would apply only within the
module being compiled.

for example, Objective CAML revised syntax -

  $ cat mod.ml
  module T =
struct
   type op = [On | Off];
   value print t a = match t with
  [ On -> print_string a | Off -> () ];
   value decide t a b = match t with
  [ On -> a | Off -> b ];
end;

  $ ocamlc -i -pp camlp4r mod.ml
  module T :
sig
  type op = [ On | Off ];
  value print : op -> string -> unit;
  value decide : op -> 'a -> 'a -> 'a;
end;

This is fairly obvious, so I'm probably missing the point,
but the compiler here infers types and produces an interface
definition.  The interface definition must be available to
any other modules that rely on this one, so they are relieved
of any need to examine code within this module.

There might be tricky spots, but I imagine the Objective CAML
folks would object to an assertion like "making a really modular
system work with static typing and inferencing is probably
impossible"!

Donn Cave, [EMAIL PROTECTED]
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Optional Static Typing

[Scott David Daniels]

Rahul wrote:
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  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
[EMAIL PROTECTED]
--
http://mail.python.org/mailman/listinfo/python-list

Re: Optional Static Typing - Haskell?

[Alex Martelli]

Donn Cave <[EMAIL PROTECTED]> wrote:

> Quoth [EMAIL PROTECTED] (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
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Optional Static Typing - Haskell?

[Donn Cave]

Quoth [EMAIL PROTECTED] (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, [EMAIL PROTECTED]


---== 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 =-
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Koolaid (was Re: Optional Static Typing)

[Tim Jarman]

In article <[EMAIL PROTECTED]>,
 Peter Hansen <[EMAIL PROTECTED]> wrote:

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

-- 
Remove luncheon meat to reply.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Optional Static Typing

[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.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Optional Static Typing

[Nick Coghlan]

Mike Meyer wrote:
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.
--
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
http://boredomandlaziness.skystorm.net
--
http://mail.python.org/mailman/listinfo/python-list

Re: Optional Static Typing - Haskell?

[Alex Martelli]

Neal D. Becker <[EMAIL PROTECTED]> wrote:

> 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
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Optional Static Typing

[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

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Koolaid (was Re: Optional Static Typing)

[Scott David Daniels]

Tim Churches wrote:
Peter Hansen <[EMAIL PROTECTED]> wrote:
I always thought the connotation was more that those who
"drank the Kool-Aid" were unthinking drones, following what
others told them to do.
I thought it was an allusion to "The Electric Kool-Aid Acid test" by Tom Wolfe - see 
http://en.wikipedia.org/wiki/The_Electric_Kool_Aid_Acid_Test
I am pretty sure that it was a Jonestown reference.  I was living in
Menlo Park, CA around the time of Jonestown, and "drank the Kool-Aid"
came into coin as a (shocking at the time) reference after Jonestown,
and I knew a number of people who hung out at Keysey's place and a
few "on the bus" types -- none of them ever used the "drank the Kool-
Aid" phrase before Jonestown to my knowledge.
--Scott David Daniels
[EMAIL PROTECTED]
--
http://mail.python.org/mailman/listinfo/python-list

Re: Koolaid (was Re: Optional Static Typing)

[Robert Kern]

Tim Churches wrote:
Peter Hansen <[EMAIL PROTECTED]> wrote:
John Roth wrote:
"Rocco Moretti" <[EMAIL PROTECTED]> wrote:
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 always thought the connotation was more that those who
"drank the Kool-Aid" were unthinking drones, following what
others told them to do.

I thought it was an allusion to "The Electric Kool-Aid Acid test" by Tom Wolfe - see 
http://en.wikipedia.org/wiki/The_Electric_Kool_Aid_Acid_Test
First Google hit for "drank the Kool-aid":
http://www.wordspy.com/words/drinktheKool-Aid.asp
"""
Notes:
This phrase comes from the 1978 "Jonestown massacre" in which members of 
the Peoples Temple cult committed suicide by drinking cyanide-laced 
Kool-Aid (although some say the drink of choice was actually Flav-R-Aid).
"""

--
Robert Kern
[EMAIL PROTECTED]
"In the fields of hell where the grass grows high
 Are the graves of dreams allowed to die."
  -- Richard Harter
--
http://mail.python.org/mailman/listinfo/python-list

Re: Optional Static Typing - Haskell?

[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

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Optional Static Typing

[Mike Meyer]

"John Roth" <[EMAIL PROTECTED]> writes:

> <[EMAIL PROTECTED]> wrote in message
> 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?

  http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Optional Static Typing

[Alex Martelli]

John Roth <[EMAIL PROTECTED]> wrote:
   ...
> 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
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Optional Static Typing

[Alex Martelli]

<[EMAIL PROTECTED]> wrote:

> 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
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Koolaid (was Re: Optional Static Typing)

[Tim Churches]

Peter Hansen <[EMAIL PROTECTED]> wrote:
> 
> John Roth wrote:
> > "Rocco Moretti" <[EMAIL PROTECTED]> wrote:
> >> 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 always thought the connotation was more that those who
> "drank the Kool-Aid" were unthinking drones, following what
> others told them to do.

I thought it was an allusion to "The Electric Kool-Aid Acid test" by Tom Wolfe 
- see 
http://en.wikipedia.org/wiki/The_Electric_Kool_Aid_Acid_Test

Tim C
-- 
http://mail.python.org/mailman/listinfo/python-list