[Python-3000] Conventions for annotation consumers (was: Re: Draft pre-PEP: function annotations) (original) (raw)

Paul Prescod paul at prescod.net
Tue Aug 15 20:09:17 CEST 2006

On 8/15/06, Collin Winter <collinw at gmail.com> wrote:

On 8/15/06, Paul Prescod <paul at prescod.net> wrote: > I totally do not understand the requirement for the dictionary and its extra > overhead. Under your proposal, annotation consumer libraries have to provide wrappers for Python's built-in types, since the only way a library has of knowing whether it should process a given object is by applying a subclass test. Extending this same idea to static analysis tools, tools like pychecker or an optimising compiler would have to supply their own such wrapper classes. This would be a huge burden, not just on the authors of such tools, but also on those wishing to use these tools.

No, this is incorrect. Metadata is just metadata. Libraries act on metadata. There is a many to many relationship. You could go and define Collin's type metadata syntax. You create a library of wrappers (really you need only ONE wrapper). Then you could convince the writers of PyPy to use the same syntax. So there would be one set of annotations used by two libraries.

Here's what the definition of the one wrapper could look like:

class my_type: def init(self, data): self.data = data

That's it. That's all you need to implement.

I want people to be able to use Python's built-in types without ugly

wrapper classes or any other similar impediments to their pre-existing Python workflow/thought patterns.

The wrapper class doesn't need to be ugly. Just:

from typecheck import my_type as t

def foo(a: t(int, int), b: t("abc")): ...

Paul Prescod -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/python-3000/attachments/20060815/6a95fa1a/attachment.html

More information about the Python-3000 mailing list