-
If you were to implement this, I'd agree. I wouldn't do it either. From a standpoint of language fragmentation, yes, adding this feature to CPython is a bad thing(TM), because the other implementations will not be able to keep up.
On the other hand, coding in the language should not change much. If you do not declare types, fine. Your python code stays python all the same.
-
You didn't like list comps either, did you, Hans? ;-)
-
Actually, that was gencomps...
-
"""On the other hand, coding in the language should not change much. If you do not declare types, fine. Your python code stays python all the same."""
Guido claims that some people actually *need* this feature. I don't have a problem with these people getting it. I am more worried about those who don't need it, but who will use it anyway. I don't fancy looking at code with static type declarations that were added just because the author could. I don't consider such code to be Python.
-
Could your IDE not wipe the type declarations from the screen if you request it to? Like comment folding...type declaration folding...
Of course, if you get code that really *needs* type declarations, (and this might actually have some merit, since GvR wants to make them available at runtime) it will tend to look obfuscated without them, but then as you say, how many times will you encounter such code?
-
I prefer a language that is usable without having to use a specialized IDE... that way lies the Java road.
-
I agree with you entirely. The day before Guido's first blog about static types, I worried that decorators were the beginning of the c++ification of Python. Static types would be the end of it.
-
I agree that there needs to be a more pythonic solution or none at all. Interface validation wouldn't be a horrible idea, but isn't that what test cases are for? Perhaps the interface/contract concept could allow more automated testing, but it shouldn't be a cornerstone of software design a la Java.
Guido has also seemed to plagiarize ML's type syntax almost exactly (except for int list -> List[int]), though the pattern matching in python has nothing on ML's which will reduce the flexibility in this system.
Why not just allow some sort of advisory type system a-la lisp. Lisp doesn't have to sacrifice its dynamicism to gain compile-time type-orienteed optimizations, so why should Python? What about this:
def f(x,y):
assert isinstance(x,int)
assert isinstance(y,float)
...
This is completely valid within the current paradigm. What if -O interpreted these preconditions in order to do optimizations for type?
-
Brian: If python were lisp, this would not be a problem. Gladly, it isn't. A problem with your proposal is that this would clutter up your methods, something that decorators should be able to take care of (I even remember a typed function decorator in the cookbook...).
All you anti-typists: Why not make something like doctest, where you have a pretty informal method of telling something about your function in the docstrings and use that instead? Plus side: No clutter, types-as-documentation where they belong; Minus side: Imagine a bad docstring messing up your program...
-
Really sad to see how Python is starting to go the path of saying "me-too" to every stupid feature other hideous languages have... and as you very well said; that will only make the already messy global Python codebase even worse... *sigh*
/me starts to think of jumping ship... hell, even Ruby doesn't look that bad compared to where Python is going... but I think I like Erland and Limbo much better; if I'm going to have static typing then why not use a language that was designed for it?
-
"On the other hand, coding in the language should not change much. If you do not declare types, fine. Your python code stays python all the same."
Yes, but who only works with their own code? Meanwhile, the "feature slaves" who have to use the newest features within 15 minutes of them arriving in CVS, together with people coming from statically typed languages like Java, will be slipping in needless declarations all over the place in any moderately sized project unless educated differently. Only yesterday, I saw a project being announced as *requiring* Python 2.4 which has only been out for a month or so - are people so vain as to think everyone enjoys spending vast amounts of time upgrading and testing all their existing stuff (and without any real infrastructure to do so either) just to use something novel?
Meanwhile, like Victorian era explorers impatient to solve ancient mysteries, the dynamite comes out instead of people taking their time and working out an elegant way of meeting the challenges facing Python and its wider adoption. After the intellectually lightweight syntax debate that is inevitable around this proposed type annotation scheme, I envisage another layer of confusion spread unevenly on top of Python's other experimental heritage, the Jython people finding themselves as far behind CPython as they always were (PSF grant or otherwise), and the same persuasive promises that came with the current proposal and with decorators before it emerging again to lure the easily amused into another round of dubiously justified enhancements.
Wouldn't it have been a good idea to have paid the author of Starkiller to finish his write-up, get his code out there, and then to possibly review the other related work (Python implemented in Lisp/Scheme) instead?
-
"Yes, but who only works with their own code?"
You have a point there - you might be forced to read code with type declarations, which, given the proposed syntax, might hurt your eyes, if you are accustomed to the simple readable python source of those days.
I'm not convinced that static typing is a bad idea. But I think it doesn't deserve the very intrusive proposed syntax.
-
Andre Kloss; you obviously have never worked in any real worl project; it's not only that you have to _read_ other's code; you have to hack, fix, improve, rewrite, etc code that who knows what moron has written.
While it's always possible for a clueless programmer to write braindamaged code; this proposal basically is an encouragement for it, and if I wanted that I would use C++, Java or Perl; thank you very much.
"it's not that perl programmers are idiots, it's that the language rewards idiotic behavior in a way that no other language or tool has ever done" -- Erik Naggum
Good to see Python catching up with Perl then... *sigh*