[Python-Dev] PEP 246: lossless and stateless

[Just van Rossum]

Guido van Rossum wrote:

> Are there real-life uses of stateful adapters that would be thrown out
> by this requirement?

Here are two interfaces we're using in a project:

  http://just.letterror.com/ltrwiki/PenProtocol (aka "SegmentPen")
  http://just.letterror.com/ltrwiki/PointPen

They're both abstractions for drawing glyphs (characters from a font).
Sometimes the former is more practical and sometimes the latter. We
really need both interfaces. Yet they can't be adapted without keeping
some state in the adapter.

Implicit adaptations may be dangerous here, but I'm not so sure I care.
In my particular use case, it will be very rare that people want to do

    funcTakingPointPen(segmentPen)
    otherFuncTakingPointPen(segmentPen)

I don't it will be a problem in general that my adapter carries a bit of
state, and that if it _does_ become a problem, it's easy to work around.
It's not dissimilar to file.readline() vs. file.next(): sure, it's not
pretty that file iteration doesn't work nice with readline(), but all
bug reports about that get closed as "won't fix" ;-). It's something you
can easily learn to live with.

That said, I don't think implicit adaptation from str to file is a good
idea... Python (the std lib, really) shouldn't use "dangerous" adapters
for implicit adaptation, but that doesn't mean it should be impossible
to do so anyway.

[ ... ]
> But the solution IMO is not to weigh down adapt(), but to agree, as a
> user community, not to create such "bad" adapters, period. OTOH there
> may be specific cases where the conventions of a particular
> application or domain make stateful or otherwise naughty adapters
> useful, and everybody understands the consequences and limitations.
> Sort of the way that NumPy defines slices as views on the original
> data, even though lists define slices as copies of the original data;
> you have to know what you are doing with the NumPy slices but the
> NumPy users don't seem to have a problem with that. (I think.)
[ ... ]
> Guarantees again. I think it's hard to provide these, and it feels
> unpythonic.
[ ... ]
> Or maybe we shouldn't try to guarantee so much and instead define
> simple, "Pythonic" semantics and live with the warts, just as we do
> with mutable defaults and a whole slew of other cases where Python
> makes a choice rooted in what is easy to explain and implement (for
> example allowing non-Liskovian subclasses). Adherence to a particular
> theory about programming is not very Pythonic; doing something that
> superficially resembles what other languages are doing but actually
> uses a much more dynamic mechanism is (for example storing instance
> variables in a dict, or defining assignment as name binding rather
> than value copying).

Yes, yes and yes!

Just