[Python-Dev] Sneaky 'super' instances

Martin v. Löwis martin@v.loewis.de
11 Jun 2003 20:59:38 +0200


<aol>
Me too.
</aol>

Martin

> > > "Phillip J. Eby" <pje@telecommunity.com> writes:
> > 
> > >> I hope to have some cycles soon to work on such a framework, but sin=
ce
> > >> 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.
> > 
> > From: Martin v. LŽöwis [mailto:martin@v.loewis.de]
> > > 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.
> > 
> [Paul Moore]
> > 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 inter=
est
> > 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.]
> 
> Well said.