Dreaming of new generation IDE
steven at REMOVE.THIS.cybersource.com.au
Wed Feb 3 22:37:55 CET 2010
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:
>> 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
As for Pythonistas refusing to accept this, how do you explain function
"Optional static typing has long been requested as a Python feature."
More on function annotations and type inference for Python:
> 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".
More information about the Python-list