One of the things on my mind the last week or so has been: what kind of constructs in Python would allow for easy to use type safety / type checking?
Mix a little keyword parameter usage with a little bit of django-y model definitions and the net result is Bartleby.
I expect that the reaction of most people to type safety in python would be to first ask why, and then wonder wouldn't it make python as slow to develop in as C or Java. Worse: doesn't it break duck-typing.
Let me answer those in reverse order:
My personal take regarding development speed is that python is good not due to how few keystrokes it requires you to enter, but from how quickly you can try out new ideas.
Number one on that front is that python is an interpreted language, so no compiler. Especially compared to C where something like a header file change can force you to sit for umpteen minutes to get results, life with python is good. Beyond that: automatic garbage collection, good string support, and a gigantic set of built in libraries all make getting real work done easy.
For me ( at least ) typing ( keystrokes ) is the least time consuming aspect of development. Even if i have to cursor around to add members to a class, that's nothing compared with the brain time it takes me to figure out how i'm going to put together an application.
All that said, even if you were to allow that maybe a few extra keystrokes here and there ( i think it averages out to about 15 extra characters or so per parameter and class member ) might not make a significant difference in development time -- the question still remains: why.
I'm a bad programmer. I make mistakes all the time. To me, types are an integral part of making sure I'm doing the right thing. To put it another way:
Types are a form of implicit unit tests.
And unit tests are good, right?
Bartleby is actually the expression of the fact that whenever I try to refactor code in python, I often spend a significant amount of time tracking errors due to parameters or class members that have changed. If those errors were caught early in a given run, rather than late: so much the better.
Last thing: duck-typing.
First, imagine a long philosophical argument about the wonderful clarity of adapter classes here -> ().
And then, imagine a similar discussion about how code is mostly supported not written here -> ().
Roger. So that said ; ) you can always ''not'' use Bartleby where you want to allow duck typing, and you can also use Type(object,...) to allow any type.