>>>>> "GvR" == Guido van Rossum <guido@python.org> writes:
GvR> I'm currently +1 on introducing names for abstract base
GvR> classes *and* extensing isinstance()'s API.
I'm worried about the abstract base class idea, because it might lead
us down a path of having a complicated class hierarchy in order to
provide completeness.
E.g. should "strings" be a sequencebase, as well as a stringbase? And
what does a sequencebase /mean/?
Will we push to try to include protocols/interfaces into this mix, so
that we'll end up defining abstract classes for all the deep-mojo
interfaces? Maybe we'll want to have abstract base classes for file
objects so things like file and StringIO's can have them as a common
base class?
In any event, I think the isinstance() extension is a simple, clean,
and (mostly :) uncontroversial change, so I'm also +1 on doing that
now.
Adding a set of abstract base classes and hooking them up with the
existing concrete data types seems much murkier to me, and of greater
long range impact, so I'm -1 on the idea, at least until it gets
PEP'd.
-Barry
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4