Re: Python Optional Typechecking Redux
Posted: Jan 19, 2005 6:28 PM
I dread the day when I'll be forced to use some arbitrary parameter type for methods defined in a strictly typed API using isinstance checks...
I don't want to loose the wonderful liberty of duck-typing that allows me to integrate code in Python way faster than in Java.
Checking types is very well, but if an API designer is doomed with short-sightedness, the type checks may well end up being too much restrictive, and the API users will soon enough find themselves piles and piles of wrapping code.
Stupid 2-seconds example of a badly designed API :
def count_words(f:file) -> int:
"OH, this method wants a file instance, not a file-like object. Damn, this means I must write my memory buffer to a real file so that it can be accessed ???"
Without type checks, the API would pose no problem here. Checking types implies a lot of extra thinking for the API designers.
What I mean is that introducing type checks will have three consequences :
1) poor API design will lead to unnecessary type restrictions, with a lot a wrapping code required from the users to work around the limitations introduced by the API designer.
2) good API design will require a plethora of abstract types or interfaces (what is precisely a file-like object ? What about an 'Readable' interface with a single read() method, from which file-like objects would inherit ? Yada yada ad nauseum) and you'll end up with Java-esque APIs. A lot of abstractions, but the job does not get done any faster.
3) This leads us to the current state of Java, which tries to break its static typing limitations by introducing genericity through generic types. At last you can write generic algorithms in Java ! Great ! But you could have done this long ago without static typing...
That's why I flipped when I read your first proposal about type checking, interface and generic types. It's the snake who bites its own tail ! You decide to add type checks, then you need interfaces for flexibility, then you notice that interfaces are not enough, you need generic types, and eventually you cool down and you realize that you'd better dump all those types checks ASAP.
There is a certain dynamically typed language out there, that's been developed and used heavily for more than 20 years, whose name begins by Small and ends by Talk... I'm not 100% sure, but I think that 20 years after, type checks are still not persona grata in this language. And I think there's a good reason for it.
Implementing types checks, a new syntax, unifying the various interfaces proposals, introducing a generic typing system, all this is very sexy, but it won't improve the 'get the job done simply, quickly and clearly' mission of Python.
I think there are other improvements which can be as sexy AND provide a strong value to the users' community, like (those are the one that fly around my head now, but there are many others) :
- improvements in multi-threading, dropping the GIL ?
- dropping reference counting to simplify C extension development
- endorsing the development of Psyco, including it in the standard Python distribution
- ditto for Pyrex - hey, in Pyrex you even get some type checks :)
- unifying the DBAPI parameter passing style across the various drivers (what's this mess with question marks, python-style, named style and so on ? How are we supposed to write portable SQL queries ?)
- cleaning up the XML situation
- find a clever way to concatenate strings so that we stop writing ''.join(list_of_strings), which is very non intuitive.
- making sure that sys.getdefaultencoding() returns a sensible value on each and every computer instead of 'ascii' everywhere. OK, this one is definitely not sexy, and in fact you just have to remove a comment or a "if 0" somewhere, or add something in sitecustomize.py . But why the hell is this required ? This should be automatically done !
And so on and so forth. Those improvements need to be tackled, and all the community energy should not be wasted by endlessly discussing typing or syntax issues. Well, that's my opinion, at least ;)
I understand that as the BDFL you may want to do other things than tackling unicode codecs issues, but if you tell the community 'we should really improve the standard library' instead of 'how can we complicate the language even further ?', you can make a huge difference, especially if you consider that there are much fewer people that can change the language than people who can improve the standard library. You choose where to turn the spotlight...