> 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. Yes, that's a danger. I'm currently thinking about adding a small number of abstract base classes, corresponding to the groups of basic concrete data types in Python: numberbase, integerbase, sequencebase, stringbase, mappingbase, filebase. And I'm not even sure of these! Practically, I only see a use for stringbase and integerbase, since these have two concrete subclasses; the others are just to make the OO zealots happy. :-) > E.g. should "strings" be a sequencebase, as well as a stringbase? Yes. Any way you can think of that checks for a "sequence" will consider strings to be sequences, unless you make explicit exceptions. > And what does a sequencebase /mean/? Whatever I want it to mean. :-) The latest code for sequence-ness tests for sq_getitem != NULL, and I think that's reasonable. > 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? I'd prefer not to. > 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? That's currently hard. I don't think we can make StringIO a new-style class, and classic classes can't inherit from new-style classes (not even abstract ones). > 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. Yes. > 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. I'm at best +0 myself -- I have more thinking to do... I've *mostly* convinced myself that stringbase is a good idea. But even there, the existence of the buffer API makes the semantics slightly murky. --Guido van Rossum (home page: http://www.python.org/~guido/)
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