Python evolution: Unease

Roman Suzi rnd at onego.ru
Wed Jan 5 09:54:03 EST 2005


On Wed, 5 Jan 2005, Alex Martelli wrote:

>Dave Brueck <dave at pythonapocrypha.com> wrote:
>   ...
>> No, not at all - I'm just trying to better understand what you mean. Words
>> like "generic" and "concepts" don't yet have a widely recognized, strict
>> definition in the context of programming. If somebody has assigned some
>> specific definition to them, that's great, it's just not universal yet so
>> references and additional explanations are helpful.
>
>Googling for "generic programming" (with the quotes) gets 100,000 +
>hits.  The first couple pages of hits, at least, seem to all be speaking
>about exactly the same thing.  The terminology appears to be settled
>enough that Oxford's St Anne College feels they can organize a "Summer
>School on Generic Programming", Nottingham University a "Workshop on
>Generic Programming", etc, etc, without fearing ambiguity.

That is why I was pretty sure people undestand me.

>Exactly what extra support Roman would want from Python for 'concepts',
>beyond that offered by, say, C++, I'm not sure.  Protocols, interfaces
>and design-by-contract are other terms often used to try and capture
>pretty similar issues.

I just happen to like the term 'concept' more than Protocols, interfaces,
and design-by-contract ;-)

Alex, I think you are +10 for adding interfaces into Python. "Concept"
is more compact word and I am sure it is not used as a name in existing
projects, unlike other words.

Also, Python concept collection could be used as a teaching example or
templates for high quality code. Concepts need not appear in every
script out there, but as a result of design.

What else Python needs to support GP? A possibility to formally
define a concept (and concept relations) with (optionally)
checks of implementations.

I do not even insist in making it all run-time! Perhaps concepts could
be checked in PyChecker. And (perhaps) the whole type-checking
could be done this way.

However sweety it is, I also hope to have keystrokes saved when
I use ready-maid concept in my program.

Just imagine we have a concept for table and use (as adaptor) it for
db-connectivity, CSV-readers/writers, XML/HTML parsers/writers, arrays,
lists, ...

Right now Python _almost_ has it. However, small differences in small details
do not allow to interchange even different dbm-modules! I remember
getting into trouble when I switched from bsddb to gdbm: some places needed
'r' to be explicitly specified! Same problems with db-api 2.0 "almost"
conformant modules, datetime types and other small details which are
similar but differ in small details at the same time. I think the same
has place with XML-DOM implementations and such.

I think concepts could be guards against such things and also make life easier
for those who implement some standard protocols. That is, concepts could be
internal (Python) standardizing and quality control technique. We can use
constant publicId, systemId a-la XML for concepts, so upgrade path will be
similar to HTMLs. This will make concept-changing visible between versions.


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



More information about the Python-list mailing list