Python evolution: Unease

[Ian Bicking]

Roman Suzi wrote:
>>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.

Umm... this isn't helpful.  "Generic" and "concept" are not terms that 
belong to Boost or STL or whatever.  They are just words.  Coining the 
term doesn't mean anyone else knows what it means, nor that anyone 
*should* know what they mean -- personally I get very suspicious of 
ideas that are based on redefined words, that tends to be a way of 
hiding complexity or fuzziness.

But anyway, if you use these terms, you really must provide references, 
otherwise no one will know what you mean.  "Python could have honest 
support of concepts" is simply an incomplete sentence.  "Python could 
have honest support of Concepts (url)" would be more reasonable.

-- 
Ian Bicking  /  ianb at colorstudy.com  /  http://blog.ianbicking.org