[Python-ideas] Type Hinting Kick-off
abarnert at yahoo.com
Mon Dec 22 17:19:31 CET 2014
On Dec 21, 2014, at 23:02, Guido van Rossum <guido at python.org> wrote:
> Any's "contagiousness" is somewhat similar to NaN for floats, but it has its limits -- e.g. repr() of Any is still a string, and Any==Any is still a bool. Another similar concept exists IIUC in Objective-C, which has a kind of null object that can be called (sent a message), always returning another null result. (This has occasionally been proposed for Python's None, but I don't think it is appropriate.)
I think you're mixing up two things here.
ObjC does have a concept pretty close to Any, but it's not nil, it's id. This is a type that's never seen at runtime, but at compile time, in practice,* it's both a top and bottom type** (any method can be called on an object declared as id; any argument can be passed to a covariant or contravariant parameter of type id; a value declared id can be stored or passed anywhere), and subtyping is transitive except as far as id is concerned.
But nil is a whole different thing. Dynamically, it's similar to Python's None, except that it responds to every method with None. Statically, every type is effectively an Optional[T], and can hold either a T (or subclass) instance or nil.*** The static type of nil might be id, but it doesn't really matter, because that never comes up.**** The dynamic type of nil is nil.*****
* In reality, this relies on the fact that ObjC objects are always referenced by C pointers, and id is effectively just a typedef for void*, and C allows any pointer to be implicitly cast to and from void*.
** Except when native C types get involved. Traditional ObjC waved that away by assuming that every C type except double and long long was the same size as a pointer and you don't use those two very often; the 64-bit transition screwed that up, and the compiler no longer lets you mix up ObjC and native C types.
*** Again, this is because you always reference ObjC objects as C pointers, and C pointers can always accept null values.
**** Unless you explicitly use the compile-time typeof or sizeof operators on nil, which there's no good reason to do. If you do, then you'll see it's defined as (id)0.
***** Because the equivalent of the type function is a method.
More information about the Python-ideas