def foo(a: [Anno1, Anno2]):
All that that requires is a statement in the spec saying: "If you're processing annotations and you see an annotation you don't understand, skip it. And if you see a list, look inside it rather than processing it in some proprietary fashion."
It kind of seemed obvious to me, but I guess everyone's ideas seem obvious to them. There were other secondary things I would have liked but this seemed like the minimum required to protect programmers from "greedy frameworks" that don't play nice in the face of unfamiliar annotations.
On 8/16/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
There's much in this thread that I haven't followed, for lack of time.
But it seems clear to me that you've wandered off the path now that
you're discussing what should go into the annotations and how to make
it so that multiple frameworks can coexist.
I don't see how any of that can be analyzed up front -- you have to
build an implementation and try to use it and *then* perhaps you can
think about the problems that occur.
Collin wrote a great PEP that doesn't commit to any kind of semantics
for annotations. (I still have to read it more closely, but from
skimming, it looks fine.) Let's focus some efforts on implementing
that first, and see how we can use it, before we consider the use case
of a framework for frameworks.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
_______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
