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

[Paul Prescod]

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