> So, I think some use cases do exist for the general-ish rule > "whenever it makes some sense, a type is callable without arguments > and when so called returns the one instance of that type which > evaluates to false". Right. The first half of this is probably why I did it in the first place: I'd like all types to have a constructor callable with no arguments, and whenever it's possible and reasonable to construct a valid instance by providing suitable default constructor arguments, this should be so. The second half is a pretty weak additional requirement that I think Raymond H made up when he fixed the bool() constructor; it just makes sense for containers and sequences to construct an empty one and for numbers to use zero. BTW, for your amusement, here's a (theoretical) use case: sometimes you write some polymorphic code that takes a sequence but would like to use an empty sequence of the same type. You can do a[:0] to create one, but some sequence types (e.g. Numeric arrays) have funny slice semantics. Calling type(a)() would make perfect sense for creating an empty of the same type. Moreover (and here it gets really theoretical :-) it's possible to write polymorphic code that accepts either a sequence or a number as argument, using only + and int* as operators. In this case, type(a)() is even more attractive for getting the "zero" of the group. --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