Dreaming of new generation IDE

[Steven D'Aprano]

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