On 5/20/06, tomer filiba <[EMAIL PROTECTED]> 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/) _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
