"Martin v. Loewis" wrote: > > Neal Norwitz <neal@metaslash.com> writes: > > > Should I start converting/removing uses of the types module where possible? > > Would you like to review patch 562373. Walter already has some code > for that. Reviewing now... So far so good, but it brings up a question. There was talk about changing string (the base class) to something else since it was the same name as the module. Was there ever a decision made? Since I expect confusion between string (the module) and string (the abstract class). The name issue is marginally related to what's described below. Right now, if you derive a class from an instance (yes, this shouldn't work): >>> class x(5): pass ... Traceback (most recent call last): File "<stdin>", line 1, in ? TypeError: int() takes at most 2 arguments (3 given) This makes sense and is what I would expect. But this is not what I would expect: >>> import string >>> class newstr(string): pass ... # i would have expected this to raise a TypeError >>> x = newstr() Traceback (most recent call last): File "<stdin>", line 1, in ? TypeError: 'module' object is not callable Perhaps this error should be handled when the class is constructed rather than when instantiating an object? Of course, you can't derive from the string class either: >>> del string >>> print string <type 'string'> >>> class x(string): pass ... >>> y = x() Traceback (most recent call last): File "<stdin>", line 1, in ? TypeError: The string type cannot be instantiated Neal
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