[Python-Dev] Sneaky 'super' instances

[Guido van Rossum]

> > "Phillip J. Eby" <pje@telecommunity.com> writes:
>=20
> >> 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.
>=20
> From: Martin v. L=F6wis [mailto:martin@v.loewis.de]
> > I'm quite skeptical about "grand new architectures" whose develop=
ment
> > starts off with "what we have is rubbish". In my experience, the
> > rubbish that we have right now continues to be much better than w=
hat
> > the grand new architecture can deliver for several years to come.=
 So I
> > would always favour evolution over revolution.
>=20
[Paul Moore]
> To some extent I agree with this. I haven't taken the time to *full=
y*
> digest the adaptation PEP or Phillip's protocol ideas, but my gener=
al
> impression is that they hover somewhere on the border. Their propon=
ents
> 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).
>=20
> 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 patte=
rns"
> which can be used to offer a standard answer to issues which someti=
mes
> come up with current methods, but which aren't frequent or severe e=
nough
> to justify major angst. (For example, the old one about what precis=
ely
> constitutes a "file-like" object in a given context). In this conte=
xt,
> it's not entirely clear to me why the proposals need "official sanc=
tion",
> as opposed to simply being made available as user-level libraries, =
with
> the possibility of migrating to "standard" status if the level of i=
nterest
> proves to justify it.
>=20
> As usual, I suspect the reality is somewhere between these two extr=
emes.
> But I'd like to see the two proposals restated in the form of worki=
ng
> library code. Then I could *try* them rather than arguing about the=
ory.
> [Of course if there really *is* a need for language support, this w=
ould
> focus on the *exact* language change needed, along with a real use =
case
> to justify it.]

Well said.

--Guido van Rossum (home page: http://www.python.org/~guido/)