On Wed, 03 Feb 2010 08:18:40 -0500, Adam Tauno Williams wrote: > On Wed, 2010-02-03 at 14:10 +0300, Vladimir Ignatov wrote: >> Hello, >> I am sitting here for quite some time, but usually keep silent ;-) I >> use Python since 2003 both "professionally" and for my hobby projects >> and love it a much. >> I notice however, that "maintaining" existing/older python code is may >> be not so enjoyable task. It may be even harder than supporting old >> code written in some type of "static" languages (like Java or C++). >> Surely "dynamic" nature of python comes with price. > > Yes, it certainly does. Not that you'll get many Pythonistas to confess > to that fact. Somehow those who brag about the readability and > expressiveness of source code just cannot admit that: > > class.method(sting name, int count) > > - is *obviously* more expressive than - > > class.method(name, count)
Obviously? I don't know about that. Being told that "count" is an int doesn't really help me -- it's obvious just from the name. In a well- written API, what else could it be? And surely count should be positive or zero but not negative? Saying it's an int is misleading. Or perhaps count can be negative, in which case maybe negative counts have some special meaning that isn't obvious from the function signature. Can I pass None to get the default behaviour? Either way, I need to read the docs, so the supposed added expressiveness doesn't actually add much. And why is count limited to an actual int type, rather than anything which is integer-like? Why can't I pass 3.0 or Decimal(3)? If you have a good reason for that limitation, great, but if it's just there to satisfy the compiler, then boo hiss to you. I cheerfully admit that *sometimes* there are type restrictions which make sense, and of course we know that there are sometimes useful performance gains to be made with static typing. Any compiler which requires types to be declared is far too 1970s though -- a good modern static language should use type inference to reduce the number of declarations needed. As for Pythonistas refusing to accept this, how do you explain function annotations then? Quoting Guido: "Optional static typing has long been requested as a Python feature." http://www.artima.com/weblogs/viewpost.jsp?thread=85551 More on function annotations and type inference for Python: http://lambda-the-ultimate.org/node/1519 http://www.python.org/dev/peps/pep-3107/ http://www.python.org/workshops/2000-01/proceedings/papers/aycock/aycock.html > This is obvious even in the Python documentation itself where one > frequently asks oneself "Uhh... so what is parameter X supposed to be... > a string... a list... ?" The answer is usually "both, and anything else that obeys some subset of the sequence or iterable protocols". -- Steven -- http://mail.python.org/mailman/listinfo/python-list
