[IPython-dev] Function specific hooks into the ipython tab completion system

Thomas Kluyver takowl@gmail....
Fri Nov 30 08:11:21 CST 2012


On 30 November 2012 12:49, Robert McGibbon <rmcgibbo@gmail.com> wrote:

> I don't use python3. (I would, but I depend on PyTabes for everything, and
> it isn't py3k ready). Without the
> syntactical support, manually attaching __annotations__ to functions seems
> like a lame api.
>

It would be quite easy to write a decorator (@annotations perhaps) that
would take care of handling __annotations__ for you, like this:

@annotate(a=tab('foo'), b=int)
def myfunc(a, b=1):
    ...

Then frameworks using annotations could keep working seamlessly as
downstream code transitions to:

def myfunc(a:tab('foo'), b:int =5):
   ...


> Second, in order to do annotations "right" in such a way that two
> independent project don't have annotation semantics
> that fail to interoperate, everyone needs to agree on some system. If one
> library expects the annotations to be strings
> (or to mean a  specific thing, like a type for typechecking) and another
> library expects something different, then everyone is
> in a bad spot. PEP3107 <http://www.python.org/dev/peps/pep-3107/> seems
> to want some convention to "develop organically".
>

I agree that this is somewhat awkward. But I think a convention will have
to develop where frameworks ignore annotations they don't understand. As a
starting set of rules, it seems sensible that:

- Annotations that are built-in types (e.g. int) will indicate some kind of
variable contract, so the associated parameter should always be of that
type.
- Annotations that are strings will be used like docstrings.

I suggest all more advanced uses involve some sort of wrapper, like tab()
in your examples. Frameworks that don't recognise the wrapper will ignore
the contents.



> (2). Inspired by ggplot <https://en.wikipedia.org/wiki/Ggplot2>, where
> you compose plots by *summing* components, the annotations could be the
> sum of
> objects that overload __add__, like:
>

This looks nice! I'd also thought of the dictionary idea, but it does make
code ugly.

I'd implement it slightly differently, though - instead of a linked list,
I'd make __add__ return a container object, so you could add things like
strings (so long as they're not in first place):

def my_io(fname, mode: tab('read','write') + "The mode in which to open the
file"):
     ...

I think it's worth floating these ideas in a more general Python forum, so
we can get feedback from other people thinking about using annotations.

Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.scipy.org/pipermail/ipython-dev/attachments/20121130/ad852ad9/attachment.html 


More information about the IPython-dev mailing list