[Python-3000] Draft pre-PEP: function annotations (original) (raw)

Phillip J. Eby pje at telecommunity.com
Sun Aug 13 08:06:50 CEST 2006

At 01:29 AM 8/13/2006 -0400, Jim Jewett wrote:

On 8/13/06, Josiah Carlson <jcarlson at uci.edu> wrote:

"Phillip J. Eby" <pje at telecommunity.com> wrote: > However, if you have: > def myfunc( x : doc("The x coordinate"), y : doc("The y coordinate") ) > There is no ambiguity. 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".

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!

I'm really baffled by the controversy over this; is it really the case that so many people don't know what tell-don't-ask code is or why you want it? I guess maybe it's something that's only grasped by people who have experience writing code intended for interoperability.

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()!

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.

The other possibility, of course, is that all of you have some horrendously complex use case in mind that I just don't "get". But so far all the examples that anybody else has put forth have been practically whimsical in their triviality -- while I've been explaining how the same principles will even work for complex things like type-checking code generation, let alone the trivial examples. So I don't think that's it. And at least Paul and Josiah have shown that they "get" what I'm saying, so I don't think that the answer is simply that I'm crazy, either.

[Meanwhile, I'm not going to respond to the rest of your message, since it contained some things that appeared to me to be a mixture of ad hominem attack and straw man argument. I hope that was not actually your intent.]

More information about the Python-3000 mailing list