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 <[EMAIL PROTECTED]> wrote: > 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
