Re: Optional static typing
On Thu, Aug 14, 2014 at 12:02 AM, Steven D'Aprano st...@pearwood.info 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
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
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
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
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
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
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
On 28 jan, 11:21, Russ P. [EMAIL PROTECTED] wrote: On Jan 28, 1:53 am, Bruno Desthuilliers bruno. [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 RD. 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
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
On Jan 28, 1:53 am, Bruno Desthuilliers bruno. [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 RD. 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
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
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
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
On Jan 28, 11:42 am, Russ P. [EMAIL PROTECTED] wrote: On Jan 28, 1:51 am, Bruno Desthuilliers bruno. [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
On Jan 28, 1:51 am, Bruno Desthuilliers bruno. [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. -- http://mail.python.org/mailman/listinfo/python-list
Re: optional static typing for Python
Hallöchen! Russ P. writes: On Jan 28, 1:51 am, Bruno Desthuilliers bruno. [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
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
Russ P. a écrit : On Jan 28, 1:51 am, Bruno Desthuilliers bruno. [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
Russ P. wrote: On Jan 28, 1:51 am, Bruno Desthuilliers bruno. 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
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
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
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
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
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
optional static typing for Python
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: optional static typing for Python
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
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
Re: optional static typing for Python
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
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. 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
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
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
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
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
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
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
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
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
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
On Jan 28, 1:56 am, Paul Rubin http://[EMAIL PROTECTED] 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
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
On Jan 28, 6:17 am, Paul Rubin http://[EMAIL PROTECTED] 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
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: Status of optional static typing in Python?
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
Status of optional static typing in Python?
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: Status of optional static typing in Python?
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
Re: Status of optional static typing in Python?
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?
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 a écrit :
Perhaps I'm deluded but I don't think so.
after what='having read the rest of the post'.
You are.
/after
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?
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: Optional Static Typing
[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 y0, the compiler could simply cut away a branch of dead code guarded by if xy: (maybe with a 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: Part II
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 /joke. 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
Re: Optional Static Typing: Part II
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
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 - Haskell?
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 x0 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 these issues and I'll point to his
Re: Optional Static Typing
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?
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. mike -- Mike Meyer [EMAIL PROTECTED] 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 - Haskell?
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
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
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 y0, the compiler could simply cut away a branch of dead code guarded by if xy: (maybe with a warning, in this case;-)... Alex -- http://mail.python.org/mailman/listinfo/python-list
Re: Optional Static Typing - Haskell?
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
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
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 y0, the compiler Alex could simply cut away a branch of dead code guarded by if Alex xy: (maybe with a warning, in this case;-)... I realize that your example is theoretical, but efficiency impact of such optimizations would be dwarfed (speedwise) by optimization on type, so that if x y yields native object code for integer comparison. Also, to get real benefits the functions called would need to be inline-expanded so that the implications of x y are taken in account deeper in the call chain; a programmer that does def f(x,y): assert 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 - Haskell?
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
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?
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 - Haskell?
[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. mike -- Mike Meyer [EMAIL PROTECTED] 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 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?
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 - Haskell?
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
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
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 boolexp aborts if it is checked at all, but with __debug__ defined as 1, it passes. Perhaps you are proposing that expects be used in that context. 3.In my post i am not stressing on adding 'expects' as keyword or something. Only that type should not be enforced and 'expects' makes this clear. You need to explain why anyone would want to write expects at all. If you are expecting the code generation to change, you'd better enforce, rather than advise, unless you are defining points at which to do code specialization on types. --Scott David Daniels [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Optional Static Typing - Haskell?
[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. mike -- Mike Meyer [EMAIL PROTECTED] 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 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
[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: Optional Static Typing
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
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? mike -- Mike Meyer [EMAIL PROTECTED] 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 - Haskell?
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: Koolaid (was Re: Optional Static Typing)
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: Koolaid (was Re: Optional Static Typing)
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: Optional Static Typing
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: Optional Static Typing - Haskell?
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
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
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: Koolaid (was Re: Optional Static Typing)
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 - Haskell?
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: Optional Static Typing - Haskell?
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?
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
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
Optional Static Typing
Adding Optional Static Typing to Python looks like a quite complex thing, but useful too: http://www.artima.com/weblogs/viewpost.jsp?thread=85551 I have just a couple of notes: Boo (http://boo.codehaus.org/) is a different language, but I like its as instead of : and -, to have: def min(a as iterable(T)) as T: Instead of: def min(a: iterable(T)) - T: Sometimes it can be useful to mix parts with static typing and parts without it in the same module (because dynamic typing is very useful sometimes), but some other times you want to be sure to have a full typed and checked module. So maybe a kind of compiler directive (like the # used to define encoding) can be used to define a module fully typed and fully checked by a pychecker-like. (A module with static typing can be very useful for a true python compiler too.) Bear hugs, bearophile -- http://mail.python.org/mailman/listinfo/python-list
Re: Optional Static Typing
[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 Thanks for pointing out that article by Guido van Rossum. Looks like it just came out today. It is something that may be added to Python 3.0: http://www.python.org/moin/Python3.0 Sometimes it can be useful to mix parts with static typing and parts without it in the same module (because dynamic typing is very useful sometimes), but some other times you want to be sure to have a full typed and checked module. The closest option right now in CPython is to use Pyrex. http://nz.cosc.canterbury.ac.nz/~greg/python/Pyrex/ Boo (http://boo.codehaus.org/) is a different language, but I like its as instead of : and -, to have: def min(a as iterable(T)) as T: Instead of: def min(a: iterable(T)) - T: Right, you're first example is how Boo does it, and the 2nd is how Guido proposed to do it in Python 3.0. Boo flips the problem around. Instead of optional static typing, everything is statically typed by default (but with type inference so you do not always need to explicitly declare the type), and it has optional runtime typing that works like python's (duck typing). http://svn.boo.codehaus.org/trunk/tests/testcases/integration/duck-2.boo?view=auto http://svn.boo.codehaus.org/trunk/examples/duck-typing/XmlObject.boo?view=auto http://svn.boo.codehaus.org/trunk/tests/testcases/integration/duck-5.boo?view=auto http://boo.codehaus.org/Duck+Typing And there are some disadvantages to doing it this way. It means Python is more flexible to use than Boo, as I stated a couple months back: http://groups-beta.google.com/group/comp.lang.python/messages/c57cf0e48827f3de,a750c109b8ee57c3,cf89205a5e93051e,cfb1c7453e1f3c07,58a2dedd1059783e,8a1ee82cc328d023,7a51cdc9ffecbc72,38304f35cb42bb63,fc5e4ae1cbae0248,2de118caa7010b30?thread_id=5a7018d37b7bf4b8mode=threadnoheader=1q=boo+python-like#doc_7a51cdc9ffecbc72 -- http://mail.python.org/mailman/listinfo/python-list
Re: Optional Static Typing
[EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Adding Optional Static Typing to Python looks like a quite complex thing, but useful too: http://www.artima.com/weblogs/viewpost.jsp?thread=85551 One of the comments on Artima asks a rather profound question: static typing is an answer. What's the question? (That's a paraphrase.) The answer that everyone seems to give is that it prevents errors and clarifies the program. I'm not convinced that it's all that effective at either objective. My viewpoint on this is that of someone who generally uses test first programming (as in Test Driven Development or Extreme Programming). Many of the supposed advantages simply aren't there when you go to the discipline of writing a test and then writing exactly the code needed to make the test pass, and not one keystroke more. Most of the kinds of error that static typing is supposed to catch simply don't persist for more than a minute when you do test driven development. This isn't to say TDD is the be-all and end-all of correctness. Formal methods and formal inspections both have very good reputations. In fact, the technique with the best reputation is embodied in a sign that was on the wall of every office of the old IBM: Think! So let's look a bit deeper. As far as I remember, static typing came out of the formal methods work in the '70s by people like Djikstra, Hoar and Wirth (to name only a few.) The thing is, if you properly use the formal program derivation methods they advocated, then you don't need it: your program will be as correct as it's possible to get short of your being promoted to godhood. So the conclusion here is that static typing is an attempt to make programming safe for people that shouldn't be programming in the first place. This may sound a bit cynical, but most real uber-programmers have either Lisp or Smalltalk in their backgrounds, and frequently both one. Neither of those languages have static typing, and they simply don't need it. So if the problem is reducing errors, then maybe we should be working on the places where errors show up. Another point that's sometimes raised is that it's useful to provide type information via reflection. I used to think that was a valid concern until I started work on PyFit. I had to put a rather simplistic metadata facility into the program to substitute for not having type information, and I found that it was incredibly useful for other things that you can't get from reflection on type data. John Roth Bear hugs, bearophile -- http://mail.python.org/mailman/listinfo/python-list
Re: Optional Static Typing
John Roth wrote: One of the comments on Artima asks a rather profound question: static typing is an answer. What's the question? (That's a paraphrase.) The answer that everyone seems to give is that it prevents errors and clarifies the program. shrug It might just be me, but I thought it was to simplify code analysis and compilation. (That is, for the use of static typing in general, not for Python in particular.) Looking at C, it's doubtful error prevention and program clarification was a serious objective in the static typing system. It's more reasonable to conclude that C is statically typed because it allows the compiler to more easily allocate 1 vs 2 vs 8 bytes for a particular variable, and to make sure the proper addition opcodes get put down. Now whether this would be useful for Python is an open question. Many of the supposed advantages simply aren't there when you go to the discipline of writing a test and then writing exactly the code needed to make the test pass, and not one keystroke more. ... This isn't to say TDD is the be-all and end-all of correctness. Right. And unit tests don't do anything for people who don't use them. The question is, should Guido state TDD is the one true way to program in Python., or should concessions be made in the language design for those who don't drink the TDD Kool-aide. So the conclusion here is that static typing is an attempt to make programming safe for people that shouldn't be programming in the first place. I rebut it thusly: elitist bastard. wink and a half One of the draws of Python is that it's welcoming to newcomers and programmers of all talents. You don't have to be an uber-programmer to use it and use it well. Should we hobble it to suit poor programmers? No. But that's no reason why it can't be made to be easier and safer to use for the hobbyist when it doesn't compromise usefulness for the power-programmer. (My opinion) Python shouldn't have a sign on the door saying: You must be this 'leet to enter. Will static typing be a boon for Python? Is it necessary? Or is it the trailhead on the road to Hades? shrug Only time will tell. -- http://mail.python.org/mailman/listinfo/python-list
Re: Optional Static Typing
Doug Holton: And there are some disadvantages to doing it this way. It means Python is more flexible to use than Boo, I've just suggested the *syntax* that I like more. Bye, Bearophile -- http://mail.python.org/mailman/listinfo/python-list
Re: Optional Static Typing
Rocco Moretti [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] John Roth wrote: One of the comments on Artima asks a rather profound question: static typing is an answer. What's the question? (That's a paraphrase.) The answer that everyone seems to give is that it prevents errors and clarifies the program. shrug It might just be me, but I thought it was to simplify code analysis and compilation. (That is, for the use of static typing in general, not for Python in particular.) Looking at C, it's doubtful error prevention and program clarification was a serious objective in the static typing system. It's more reasonable to conclude that C is statically typed because it allows the compiler to more easily allocate 1 vs 2 vs 8 bytes for a particular variable, and to make sure the proper addition opcodes get put down. The C language does not have strong typing in the sense that most people use the term today. Now whether this would be useful for Python is an open question. Many of the supposed advantages simply aren't there when you go to the discipline of writing a test and then writing exactly the code needed to make the test pass, and not one keystroke more. ... This isn't to say TDD is the be-all and end-all of correctness. Right. And unit tests don't do anything for people who don't use them. Absolutely correct. The question is, should Guido state TDD is the one true way to program in Python., or should concessions be made in the language design for those who don't drink the TDD Kool-aide. Neither one. I hope you didn't mean that people who advocate TDD are suicidal fanatics, because that's exactly what drink the kool-aid means. So the conclusion here is that static typing is an attempt to make programming safe for people that shouldn't be programming in the first place. I rebut it thusly: elitist bastard. wink and a half Bullshit. Where did you get your certificate in mind reading? Remember that all of the people who started this were computer science professors, and most of their experiance was with computer science students. They were also European computer science professors with a strong mathematical tendency; we have since learned that mathematicians and software developers think differently (see some comments by Don Knuth to that effect - don't have the reference handy.) They're the ones who were elitist: they strongly believed that you had to be a mathematician to be able to properly program, and that they were doing something good for the people who weren't fortunate enough to have a rigorous mathematical background by forcing them into the strait-jacket of static typing. Competent professional programmers are a different group, and need different facilities. One of the draws of Python is that it's welcoming to newcomers and programmers of all talents. You don't have to be an uber-programmer to use it and use it well. Should we hobble it to suit poor programmers? No. But that's no reason why it can't be made to be easier and safer to use for the hobbyist when it doesn't compromise usefulness for the power-programmer. (My opinion) Python shouldn't have a sign on the door saying: You must be this 'leet to enter. And it won't. Python has always had the consenting adults philosophy. Will static typing be a boon for Python? Is it necessary? Or is it the trailhead on the road to Hades? shrug Only time will tell. Since it won't happen, I'm not particularly worried about it. If it does, I'll find another language. John Roth -- http://mail.python.org/mailman/listinfo/python-list
Re: Optional Static Typing
John Roth wrote: Rocco Moretti [EMAIL PROTECTED] wrote Looking at C, it's doubtful error prevention and program clarification was a serious objective in the static typing system. It's more reasonable to conclude that C is statically typed because it allows the compiler to more easily allocate 1 vs 2 vs 8 bytes for a particular variable, and to make sure the proper addition opcodes get put down. The C language does not have strong typing in the sense that most people use the term today. Strong != Static As I understand it, strong typing means an object (variable) is what it is, and can't be changed to a different type without explicit conversion - weak typing being that an object can be any type, depending on which functions you use to look at it. Static typing is that a variable has a specific type, and can't hold a variable of a different type. This is opposed to dynamic typing, where the type of an (object in a) variable is flexible and determined at run time. Python - Strong, Dynamic C - Weak, Static Perl - Weak, Dynamic This is how I understand it. Could be wrong - wouldn't be surprised if I was, as it's a rather confusing issue at times. 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. The irony didn't travel well. All I meant is that in all the advocacy, it may get ignored that reasonable people might disagree about the value of TDD, that TDD is not a be-all, end-all for all people. Concessions also probably wasn't the right choice of word, as it implies the TDD people are giving something up. My point was, if Python is not going to be solely targeted at TDD, facilities that make other ways of doing things easier are likely (should) be included, as long as they don't negatively affect how the majority of the people who use Python do things. So the conclusion here is that static typing is an attempt to make programming safe for people that shouldn't be programming in the first place. I rebut it thusly: elitist bastard. wink and a half Bullshit. Where did you get your certificate in mind reading? Sorry. I didn't mean to imply that *you* were an elitist bastard. I merely meant that someone who would dismiss something as for people that shouldn't be doing X in the first place is likely biased by snobbery. You were merely restating someone else's opinion, and if I accidentally accused you of also holding it, I'm sorry. From the rest of your post, it seems we pretty much agree on the key point - different people have different ways of doing things, none of which are necessarily wrong in and of themselves. Python tries to be open and inclusive towards all who want to program, without sacrificing power for it's core users. Is there a group of people for whom static typing truly helps? I don't know. What I do know is that saying that you don't need static typing if you use TDD doesn't say anything about the helpfulness of static typing for those who don't use TDD. Whether the latter group is worth Python worrying about is a philosophical question on the future direction of Python best left to Guido. -- http://mail.python.org/mailman/listinfo/python-list
Koolaid (was Re: Optional Static Typing)
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. Reading Wikipedia's account of Jonestown, it seems that the truth is a mix of both the blind loyalty thing and the suicidal fanatic thing. I've heard this applied most often in recent years to XML, and while I can imagine some people who apply the phrase to those overusing XML might think they are effectively committing suicide, I'm pretty sure most times it is just used to mean you are blindly doing what everybody else does without thinking about whether it's the right thing to do. -Peter P.S.: The ironic thing about all this is that it was actually something called Flavor Aid, made by a company called Jel Sert (http://www.jelsert.com), and not Kool-Aid at all. What would be even funnier is if the expression doesn't derive from the Jonestown suicides and I've always just assumed it did... -- http://mail.python.org/mailman/listinfo/python-list
Guido Optional Static Typing
Hi folks, This is an interesting new article (published today Dec. 23). Guido discusses the possibility of adding optional static typing to Python: http://www.artima.com/weblogs/viewpost.jsp?thread=85551 -- http://mail.python.org/mailman/listinfo/python-list
Re: Guido Optional Static Typing
Sorry... I just realized that somebody else already had started a thread on this... -- http://mail.python.org/mailman/listinfo/python-list
Re: Koolaid (was Re: Optional Static Typing)
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
