[Python-Dev] Sneaky 'super' instances

[Moore, Paul]

From: Martin v. L=F6wis [mailto:martin@v.loewis.de]
> "Phillip J. Eby" <pje@telecommunity.com> writes:

>> I hope to have some cycles soon to work on such a framework, but =
since
>> it effectively depends on both PEP 246 and an unwritten PEP for a
>> "protocol declaration API" like the one in PyProtocols, it would be
>> good to get some idea of whether the Python developer community feels
>> this is a good direction for me to pursue.

> I'm quite skeptical about "grand new architectures" whose development
> starts off with "what we have is rubbish". In my experience, the
> rubbish that we have right now continues to be much better than what
> the grand new architecture can deliver for several years to come. So I
> would always favour evolution over revolution.

To some extent I agree with this. I haven't taken the time to *fully*
digest the adaptation PEP or Phillip's protocol ideas, but my general
impression is that they hover somewhere on the border. Their proponents
describe them as if they were grand new architectures, with an
implication of "let's rewrite everything" because "what we have is
rubbish" (as you say).

But in practice, I can't see anything in either of these proposals which
really needs much change to what we currently have. I suspect that the
reality is that they are more or less descriptions of "useful patterns"
which can be used to offer a standard answer to issues which sometimes
come up with current methods, but which aren't frequent or severe enough
to justify major angst. (For example, the old one about what precisely
constitutes a "file-like" object in a given context). In this context,
it's not entirely clear to me why the proposals need "official =
sanction",
as opposed to simply being made available as user-level libraries, with
the possibility of migrating to "standard" status if the level of =
interest
proves to justify it.

As usual, I suspect the reality is somewhere between these two extremes.
But I'd like to see the two proposals restated in the form of working
library code. Then I could *try* them rather than arguing about theory.
[Of course if there really *is* a need for language support, this would
focus on the *exact* language change needed, along with a real use case
to justify it.]

Paul.