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 / [EMAIL PROTECTED] / http://blog.ianbicking.org -- http://mail.python.org/mailman/listinfo/python-list
