From comments below...
How is the argument from reliability of Lisp and Erlang systems an argument against optional static type declarations?The real question is, should optional type annotations be added to Python? I'd say no, the return on investment is not nearly as great as investing in several other implementation features.
In the Lisp world, you program with dynamic typing initially until the program stabilizes and the hot spots are known. You then type annotate just the hot spots to improve code generation of those hot spots (Lisp code is generally compiled), with the option to go to C to improve the hottest of the hot spots.Optional type annotations were added to Common Lisp in the early 1980's. Compiler strategies have improved a lot since then, as have machine capabilities. I think a better return would come from investing in the implementation of the current Python language rather than changing the Python language itself.
Basically, type annotations in Lisp (and, one presumes, Python) are an upside option that you can but don't have to use. Writing Python code (or Lisp code) from scratch with type annotations would be pretty silly. (Or, to put this another way, in Lisp type annotation is a performance, not a reliability feature).I think the downside of having every Python programmer have to understand the best practices of optional type annotations would be far worse than the upside of having them. To repeat myself, the investment should be made "under the hood" of the current Python language.
17 comments:
There *are* other uses for type declarations besides type checking. For example, the Naked Objects framework in Java uses method signatures to figure out what actions might apply when one object is dragged-and-dropped onto another object in a GUI.
Documentation, of course, is an even more immediately useful use case. A good syntax would be more precise and more brief than docstring explanations. And, such information can be cross-referenced -- if you're looking at a method that takes an IFoo, it's nice to be able to jump to the documentation for IFoo.
Last, but far from least, declarations are useful in interfacing to code built in languages that have declarations. Interfacing to C, Objective-C, C++, C#, and Java would all be much easier if type declarations were available -- even if the Python language itself had no semantics for such declarations!
In other words, what I'm saying is that declarations could be a purely syntactic/metadata feature, and they'd still be quite useful for many things.
Note, by the way, that people have interfaced to those other languages with Python already, but the APIs can be quite awkward because there's no simple way to argument/return/attribute metadata. So, having such annotations would be an immediate win for those interface tools. An important part of Python's heritage and future is that it is "universal glue" -- it doesn't shy away from talking with other languages, whether those languages are static or dynamic.
Is there a danger of over-declaration by newbies? Sure. I'd probably find it really annoying to use code with excessive declarations, if those declarations actually restricted anything. However, if they were *just annotations* (or were adaptation specifiers per PEP 246), then I could still pass their code any darn thing I pleased, and we could all continue to be happy.
In none of the dialogue on this topic have I heard boost::python mentioned.
Why not let just migrate the application pieces that would benefit from C++ification migrate gacefully into boost::python, and resist the temptation to 'sex up' what is truly a beautiful product?
In response to the above comment, I would point out that there are other (better) ways to do what the Naked Objects Framework (NOF) is doing in Python. The NOF must use the type declarations because it has no other good mechanism for it. Ironically, this is no better (in implementation or runtime speed) that just using Python's type(object) feature and a dictionary of functions (a very Pythonic way to do it).
Also, I don't like them so much, but look at PEAK's generic functions for another take on this, as it may be more familiar to Java types who are used to function overloading.
Python *IS* strongly typed. It just doesn't type the variables, only the data itself. Why people want statically typed VARIABLES instead of statically typed DATA is beyond me.
I don't mind if my language encourages me to code well (see Python's indention). I do mind if it tells me how to think (second-class functions, statically typed variables).
I would have agreed about documentation a year ago, but after looking at how Zope/Twisted do interfaces, I believe that type signatures can probably be applied with a clever use of decorators in the existing interfaces work.
It's also important to realize that type signatures are just more complex (or at least very different) in Python, where we have no overloading, default arguments, variable arguments lists, keyword arguments, etc.
I'd rather see the Zope-style interfaces integrated into the Python Standard Library and the Standard Library rewritten with interfaces in mind. The standardizing of expressive power in having Python Standard Library interfaces with such tidbits as IFile, IFileSeekable, IIterable, and the like (or even having these defined in the language) would be awesome.
I think that having a thoughtful set of basic interfaces in Python with a standard interface declaration format (think of it as Duck-Typing Grown Up) would be infinitely more productive for the Python community than any language feature we could add. Definitely more than statically-typed variables.
Virtually no language feature to date has been about limiting the expressive power of Python. There's no need to start now.
"""Also, I don't like them so much, but look at PEAK's generic functions for another take on this,"""
I've looked; in fact I wrote them. :)
Seriously, for simple type-based dispatch, an inline way of specifying type or interface would be quite nice for generic functions.
My point is that I'd like to be able to introspect on argument type -- from *outside* the function. For example, if arguments had type data available via 'inspect.getargspec()', then I could do something like:
@somegeneric.when()
def something(x:int, y:str):
instead of the current:
@somegeneric.when("x in int and y in str")
def something(x,y):
As I said, I don't care if the syntax is pure documentation, as long as it's introspectable.
Another interesting use is that one could have a metaclass that inspected the constructor's argument types to define a relational schema for that class... Anyway, there are zillions of applications (imo) for being able to annotate arguments as well as functions. I personally don't want to see 'def foo(x@int,y@str)', though!
I might go for a style like 'def foo(x [int], y [str])' though, as that would help emphasize the optional and descriptive (as opposed to restrictive!) nature.
http://the-best-porn-stars-free-porn-movie.blogspot.com
http://photo-erotique.blogspot.com/
Click Here To Enter
Hi, my mame is OuiOui
from France
, Ce site est tres cool merci ! Ouix.com Annuaire France
, my web site , my e-mail: ouiouiii@hotmail.com
Hi, my name is britney
from United States
, Free Chat - Free Web Cam -
, my web site , my e-mail: cyntia_bimbo@hotmail.com
Hi, my name is britney_movies
from United States
, Download The Videos_Paradise
, my web site , my e-mail: alizee_bi@hotmail.com
Hi, my name is http://alizeevideosx.free.fr
from alizee_bimbo
, hi, your site is very good, please look at mine too !
, my web site , my e-mail: United States
Hi, my name is divx videos x
from United States
, hello !
, my web site , my e-mail: divx.videos.x@sexbot.com
This blog is awesome! If you get a chance you may want to visit this download simple plan site, it's pretty awesome too!
Searching free amateur web cam sites I was surprised at some of the free amateur web cam content...Its amazing some of these free amateur web cam sites show weird things.
I stumbled onto your blog while just messing around tonight after dinner...
Jon
www.microrange.com a le plaisir de vous faire decouvrir: recyclage dechet informatique Did you mean: recyclage informatique and recyclage dechet recyclage.dechet@free.fr
Galeries Videos X - X Movies - Free Gallery
DivX a Gogo !
Post a Comment