[Python-3000] Anti-use-case for type annotations

[Guido van Rossum]

On 5/20/06, tomer filiba <tomerfiliba at gmail.com> wrote:
> i've been crying about that for quite a long time, but it seems people failed to see
> my point: type checking, which is more easily enforced by type annotations,
> is bad.

Pleast stop panicking. You don't seem to understand the proposal.

> and because it will have this nice (and pointless*) syntax, lots of people will start
> using them everywhere, and make projects like mine (RPyC) or PYRO worthless.

Depends.

> this kind of projects relies on proxies -- objects that *look* like the object they
> point to. like weakref.proxy. of course these objects don't have the *type* of
> the pointed object, they only have it's attributes, or rather, they deliver all
> __getattr__s and __setattr__s to the remote object, and re-raise exceptions
> locally.
>
> when type annotations become so handy, everybody will start using them,
> and it will greatly limit the use case of proxies. my proxies give you something
> that looks like a file, i.e, you can .read from it, .write to it, .close it, etc., but
> isinstance(f, file) is False.

Read my blogs on the topic. requiring isinstance() matching is *not*
part of the proposal. This has all been discussed before.

[...]
> * pointless -- type annotations basically subclass an existing container type (list,
> tuple, dict) and simply add type checking to append/insert/__setitem__, so
> that wrongly-typed objects can't accidentally get into the container.

I don't know where you got this idea. That's not the plan at all.

The plan is for the bytecode compiler to *ignore* the annotations
except to make the value of the evaluated annotation expressions
available via the __signature__ attribute of the function object, just
like the default values.

You can then write a decorator that does something with these. Or you
can just use them as documentation. The decorators don't have to do
type checking; they can do whatever you like; that's why there is no
semantic constraint on the type annotations.

If you want to write

def foo(a: "the first argument", b: 42) -> (1, 2, 3):

go right ahead.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)