[Python-3000] Draft pre-PEP: function annotations

[Paul Prescod]

Sorry to write so many emails, but I want to get in one last point tonight
(I'm sure I'll regret posting late at night)

Jim's email seems not to have gotten through to the whole list. There's a
lot of that going aruond.

On 8/12/06, Phillip J. Eby <pje at telecommunity.com> wrote:
>
> >Sure there is.  There will probably be several frameworks using the
> >magic name "doc".
> >
> >This isn't a problem for the person writing myfunc, and therefore
> >isn't a problem for immediate decorators.  It is a problem for
> >inspection code that wants to present information about arbitrary
> >3rd-party libraries.
>
> By this argument, we shouldn't have metaclasses or function attributes,
> because they have the same "problem".


I don't think Jim's issue is a real one (according to the snippet I see in
your email) because doc is an object defined in one and only one place in
Python. It has a unique id(). If two people use the name "doc" then they
will be addressable as module1.doc() and module2.doc(). No problem.

However, it's only a problem if you insist on writing brain-damaged
> code.  If you want interoperability here, you must write tell-don't-ask
> code.  This is true for *any* use case where frameworks might share
> objects; there is absolutely *nothing* special about annotations in this
> regard!


There is something different about annotations than everything else in
Python so far. Annotations are the first feature other than docstrings
(which are proto-annotations) in core Python where third party tools are
supposed to go trolling through your objects FINDING STUFF that they may
decide is interesting or not to them. When you attach a metaclass or a
decorator, you INVOKE CODE that you have installed on your hard drive and if
it crashes then you load up your debugger and see what happend.

When you attach an annotation, you are just adding information that code
OUTSIDE OF YOUR CONTROL will poke around and interpret (the metadata
processor, like a type checker or documentation generator). What you do when
you attach an annotation is make an assertion. You always want to be
confident that you and the person writing the processor code have the same
understanding of the assertion you are making. You do not want to attach a
list because you are asserting that the list is a container for a bunch of
other assertions about the contents of the list whereas the person writing
the processing code thinks that you are asserting that the variable will be
of TYPE list.

Now I'm sure that with all of your framework programming you've run into
this many times and have many techniques for making these assertions
unambiguous. All we need to do is document them so that people who are not
as knowledgable will not get themselves into trouble. It isn't sufficient to
say: "Only smart people will use this stuff so we need not worry" which is
what the original PEP said. Even if it is true, I don't understand why we
would bother taking the risk when the alternative is so low-cost. Define the
behaviour for intepreting a few built-in types and define guidelines and
best practices for other types.

After you run into the issue a few times, you look for a solution, and end
> up with either duck typing, interfaces/adaptation, overloaded functions,
> or
> ad hoc registries.  ALL of these solutions are *more* than adequate to
> handle a simple thing like argument annotations.  That's why I keep
> describing this as a trivial thing: even *pickling* is more complicated
> than this is.  This is no more complex than len() or iter() or filter()!


Pickling works because of the underscores and magic like "
__safe_for_unpickling__". Len works because of __length__. etc. There are
reasons there are underscores there. You understand them, I understand them,
Talin understands them. That doesn't mean that they are self-evident. A
lesser inventor might have used a method just called "safe_for_pickling" and
some unlucky programmer at Bick's might have accidentally triggered
unexpected aspects of the protocol while documenting the properties of
cucumbers.

These are not universally understood techniques. Let's just document them in
the PEP.

However, it appears that mine is a minority opinion.  Unfortunately, I'm at
> a bit of a communication disadvantage, because if somebody wants to
> believe
> something is complicated, there is nothing that anybody can do to change
> their mind.  If you don't consider the possibility that it is way simpler
> than you think, you will never be able to see it.


If it wasn't at least a bit complicated then there would be no underscores.
The underscores are there to prevent SOMETHING bad from happening, right?

 Paul Prescod
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20060813/f99f4ac2/attachment.htm