Extending Methods Vs Delegates

[Adam DePrince]

On Sun, 2006-03-26 at 07:21 -0800, Alex Martelli wrote:
> vbgunz <vbgunz at gmail.com> wrote:
> 
> > I am sorry I couldn't reply sooner! Alex, Python in a nutshell is my
> > bible and I take it virtually everywhere! Seriously, I would highly
> > recommend it to anyone with a little to a lot of Python experience.
> > 
> > I apologize for misinterpreting your passage on page 80. I will look
> > much closer at your examples, links and ideas and I hope to straighten
> > my knowledge on the subject of delegates!
> > 
> > Thank you for hinting on the "Template Method design pattern"! Sorry
> > for any misunderstanding!
> 
> Hey, no problem -- such a misunderstanding is always a shared
> responsibility, and as an author I need to take my part of the blame.
> 
> Unfortunately, the root issue is that more and more common, ordinary,
> useful English words get expropriated by specialized technical meanings,
> making it almost impossible to discuss technical matters in ordinary
> English without *some* risk of misunderstanding (by the reader
> mistakenly seeing a "specialized, technical meaning" where the NORMAL
> English use of the word, possibly in a slightly metaphorical vein, is
> what the author meant).  From "function" and "procedure", to "delegate"
> and "built-in", a growing number of words become "risky"!-)
> 
> Funny enough, the problem is worst in English - because in many other
> languages, the specialized technical terms often use borrowed English
> words, so the other language's native terms remain available.  Latin had
> similar luck wrt Greek a couple millennia ago -- all technical terms of
> philosophy were borrowed Greek words, so the risk of confusion was in
> fact much lower than it was in Greek;-).

Of course, any language suffers that problem when the rise of a new
field is associated with it.  

Medicine draws from Latin.  For English speakers that is wonderful, a
whole language from which to assign specific meanings.  But consider Mr.
DaVinci at one of his past-times, the dissection of rapidly decomposing
corpses for the secrets hidden within.  That he might choose to spell
his description of the inside of an eye as vitreous humor, instead of
say, eye slime, didn't make it sound as impressive to him as the term
does to me today.   I almost feel that a true appreciation for the
complexity of any endeavor must wait until its native language passed a
bit from the spot light.

While I can't speak for other fields, I believe that our "linguistic
address space" does limit our progress.   Take list interpolations for
instance ... interpolation has other, specific meanings in other not so
far removed fields.  When I first read about it, I had to backup and
think for a moment, if only to resolve the fact that yet another term is
overloaded. 

And even our keyboards limit our space.  I can create a tuple (), or a
list [], or a dict{}, but why can't I create another structure .. oh
wait, we are out of parenthesis like characters, and nobody has the
courage to recycle the of HTML fame <> pair.  

Now, as I work on my mutable sequences PEP and implementation, I find
myself annoyed without a good, non-overloaded, way of naming an iter
friendly variant of a data store's normal __delitem__.   Actually, this
wasn't more than a minute long problem, but the rate of collisions
within the English word space is a problem.   At least English is pretty
friendly about adopted and synthetic words.  

Cheers - Adam