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

[tomer filiba]

Guido writes:
> 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.

well, if that's the case, i'm fine with that. still, i think people would
break duck-typing with that new feature, but as long as it's not enforced by
the language -- it's their problem.

-----

by the way, i released a working draft of the pythonic sockets module,
if anyone is interested:
http://iostack.wikispaces.com/download

i'd like to receive feedback on it. c.l.p didn't respond.

allow me to remind that this socket module is not directly related to stream-
based IO that was discussed here. Sock2 improves the existing socket
module, and streams would be constructed on top of it, if desired.


-tomer

On 5/20/06, Guido van Rossum <guido at python.org> wrote:
> 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/)
>