[Gordon] > > I think it would probably enhance confusion to have the "look > > more like" without "being more like". [Paul] > Looking more like is the same as being more like. In other words, > there are a finite list of differences in behavior between types > and classes and I think we should chip away at them one by one > with each release of Python. There's only one difference that matters: subclassing. I don't think there's an incremental path to that that leaves Python "easily extended". [Gordon] > > __class__ is a callable object. It has a __name__. From the > > Python side, a type isn't much more than an address. > > Type objects also have names. But not a __name__. > They are not (yet) callable but I > cannot think of a circumstance in which that would matter. Take a look at copy.py. > Anyhow, I think that type objects should be callable just like > classes...but I'm trying to pick off low-hanging fruit first. I > think that the less "superficial" differences there are between > types and classes, the easier it becomes to tackle the deep > differences because more code out there will be naturally > polymorphic instead of using: > > if type(obj) is InstanceType: > do_onething() > else: > do_anotherthing() > > That is an evil pattern if we are going to merge types and > classes. And it would likely become: if callable(obj.__class__): .... Explicit is better than implicit for warts, too. - Gordon
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