Python evolution: Unease

[Roman Suzi]

On Tue, 4 Jan 2005, Dave Brueck wrote:

>Roman Suzi wrote:
>>>>It may be optional in the sense that the language will
>>>>accept missing declarations but as soon as the feature
>>>>is available it will become "mandatory" to use it
>>>>(peer pressure, workplace practices).
>>
>>
>> What about generic programming coming into fashion anytime soon?
>
>Roman, I think I've read every single thread in the past year or three wherein
>you've brought up generic programming, and I think you'd do well to choose a new
>term for the idea you're trying to convey.

IIRC, I did it only once: at fall 2004.

>The term "generic programming" is too... er... generic. :)

Nope. It is not generic. It has it's definition made by the co-author
of STL - A.Stepanov. And the Boost C++ library (many of us know it as
Boost Python) standardise on the approach, AFAIK.

>As you know, Python
>already includes a _lot_ of support for generic programming (a function that
>iterates over a sequence can easily process a list, or a string, or a tuple as
>input; a function that takes a file-like object can often work just as will with
>a true file object or a cStringIO object; etc.). So when you bring up "generic
>programming", it's too easy to dismiss the comment because (1) it's too vague
>and (2) Python already does a lot of it.
>
>So, what is your term for the type of generic programming that Python doesn't
>yet support? Interfaces? Protocols? Adapters? Metatype hierarchies?

Python could have honest support of concepts. Everything else will be
available with them.

That is the whole point that Python supports GP. It is only one step
to do concepts right (and GvR it seems want type-checking into Python 3.0
anyway), so support for concepts/concept checking is very logical,
isn't it?

Right now concepts in Python are things which experienced Python programmers
know from practise. Sometimes, they feel them unconsciously.
Concepts could be veryfied and this, for example, could prevent errors
like DB-API-complient module doesn't have some small, but necessary
to comply, attributes.

Standard concepts could be part of standard concept "metalibrary", along with
verification mechanisms (this could be done even on C++, why not in a candy
like Python?). So every programmer could verify that his/her class, created to
satisfy concept XYZ is (formally) such. Your example - cStringIO - does
it really satisfy concept of STRING? It does. Partially. Those "partially"
here and there could lead to madness.

Unit testing will be simplified too, because structural tests will be
built into concept-checking mechanism.

And BTW, are we really disputing? What do you propose instead? Old-fashioned
Pascal-like type definitions? Java-like interface/implementaion ...? IMHO it
could be a big mistake to play catch-up.


Sincerely yours, Roman Suzi
-- 
rnd at onego.ru =\= My AI powered by GNU/Linux RedHat 7.3