PEP 3107 Function Annotations: interoperability (again)
In discussing the Function Annotations PEP on python-list, interoperability between schemes came up again: http://mail.python.org/pipermail/python-list/2006-December/420645.html John Roth wrote:
Third, it's half of a proposal. Type checking isn't the only use for metadata about functions/methods, classes, properties and other objects, and the notion that there are only going to be a small number of non-intersecting libraries out there is an abdication of responsibility to think this thing through.
This issue came up before in http://mail.python.org/pipermail/python-3000/2006-August/002796.html and a rather long thread followed. Here is the paragraph in the PEP that needs updating, at the least: There is no worry that these libraries will assign semantics at random, or that a variety of libraries will appear, each with varying semantics and interpretations of what, say, a tuple of strings means. The difficulty inherent in writing annotation interpreting libraries will keep their number low and their authorship in the hands of people who, frankly, know what they're doing. The notion that libraries don't intersect should be stripped from the PEP. The question in my mind is whether this PEP needs to take responsibility for interoperability. I contend that people who design an annotation-consuming library that ends up intersecting several others will likely be capable of finding a solution even if not ideal without a central mechanism, and will be far better situated to define a solution for a central mechanism. Any thoughts? Thanks -Tony
On 1/1/07, Tony Lownds <tony@pagedna.com> wrote:
In discussing the Function Annotations PEP on python-list, interoperability between schemes came up again:
http://mail.python.org/pipermail/python-list/2006-December/420645.html
John Roth wrote:
Third, it's half of a proposal. Type checking isn't the only use for metadata about functions/methods, classes, properties and other objects, and the notion that there are only going to be a small number of non-intersecting libraries out there is an abdication of responsibility to think this thing through.
This issue came up before in http://mail.python.org/pipermail/python-3000/2006-August/002796.html and a rather long thread followed. Here is the paragraph in the PEP that needs updating, at the least:
There is no worry that these libraries will assign semantics at random, or that a variety of libraries will appear, each with varying semantics and interpretations of what, say, a tuple of strings means. The difficulty inherent in writing annotation interpreting libraries will keep their number low and their authorship in the hands of people who, frankly, know what they're doing.
The notion that libraries don't intersect should be stripped from the PEP. The question in my mind is whether this PEP needs to take responsibility for interoperability.
I contend that people who design an annotation-consuming library that ends up intersecting several others will likely be capable of finding a solution even if not ideal without a central mechanism, and will be far better situated to define a solution for a central mechanism.
Any thoughts?
Until extensive usage happens with annotations we shouldn't try to shoehorn consumers of the annotations into a specific solution. As you said, something will probably organically grow and that can be supported in another PEP later on (probably with stdlib support). People tend to want to design up front but with something like this that is meant to be highly customizable by the people wanting to use it you just don't get that option without ample feedback from users. -Brett
On 1/1/07, Brett Cannon <brett@python.org> wrote:
Until extensive usage happens with annotations we shouldn't try to shoehorn consumers of the annotations into a specific solution. As you said, something will probably organically grow and that can be supported in another PEP later on (probably with stdlib support).
I agree that a convention will develop organically, but I would add that the emergence of that convention will be governed by two things: who has the bigger market share, and who's first to market. When the first big project like Zope or Twisted announces that "we will do annotation interop like so...", everyone else will be pressured to line up behind them. Until that happens, smaller projects like mine will either a) not support annotation interop (because there's no good, obvious solution), or b) pick an interop scheme at random (again, because there's no good, obvious solution). Thanks, Collin Winter
On 1/3/07, Collin Winter <collinw@gmail.com> wrote:
On 1/1/07, Brett Cannon <brett@python.org> wrote:
Until extensive usage happens with annotations we shouldn't try to shoehorn consumers of the annotations into a specific solution. As you said, something will probably organically grow and that can be supported in another PEP later on (probably with stdlib support).
I agree that a convention will develop organically, but I would add that the emergence of that convention will be governed by two things: who has the bigger market share, and who's first to market. When the first big project like Zope or Twisted announces that "we will do annotation interop like so...", everyone else will be pressured to line up behind them. Until that happens, smaller projects like mine will either a) not support annotation interop (because there's no good, obvious solution), or b) pick an interop scheme at random (again, because there's no good, obvious solution).
Actually, I think that's a pretty good way to arrive at a good solution. I don't this is something you can analyze on paper ahead of time; there aren't really any precedents I suspect (do you know of any other language that has semantics-free signature annotations?). You must've "built two and thrown one away" before you really know what the constraints are on the solution. I realize this is frustrating for you, but I really don't think it's appropriate to pre-empty this with a standardization attempt before-the-fact (remember ISO networking?). You could be first to market yourself -- after all you already have a type checking package! -- --Guido van Rossum (home page: http://www.python.org/~guido/)
On 1/3/07, Guido van Rossum <guido@python.org> wrote:
On 1/3/07, Collin Winter <collinw@gmail.com> wrote:
I agree that a convention will develop organically, but I would add that the emergence of that convention will be governed by two things: who has the bigger market share, and who's first to market. When the first big project like Zope or Twisted announces that "we will do annotation interop like so...", everyone else will be pressured to line up behind them. Until that happens, smaller projects like mine will either a) not support annotation interop (because there's no good, obvious solution), or b) pick an interop scheme at random (again, because there's no good, obvious solution).
[snip]
I realize this is frustrating for you, but I really don't think it's appropriate to pre-empty this with a standardization attempt before-the-fact (remember ISO networking?). You could be first to market yourself -- after all you already have a type checking package!
Unless someone comes up with a good interop solution before the Py3k release, I doubt my typechecking package will support annotation interop; I don't want to pick a mechanism, only to have to roll another release when Zope or Twisted or some other big project pushes out their own solution. I will support annotations, though; that way, I can at least gather real-world usage data when users complain about not being able to use more than one annotation consumer : ) Thanks, Collin Winter
On 1/3/07, Collin Winter <collinw@gmail.com> wrote:
Unless someone comes up with a good interop solution before the Py3k release, I doubt my typechecking package will support annotation interop; I don't want to pick a mechanism, only to have to roll another release when Zope or Twisted or some other big project pushes out their own solution.
I will support annotations, though; that way, I can at least gather real-world usage data when users complain about not being able to use more than one annotation consumer : )
Those projects, due to sheer size, will be years behind you in their adoption of Python 3000, so you still have an advantage if you change your mind. Good luck! -- --Guido van Rossum (home page: http://www.python.org/~guido/)
Well, it's your PEP, isn't it? Just submit a change to the PEP editor. If it were me, any suggestion of how annotations could/should be used should be stricken from the PEP, including the example def foo(a: int, b: dict, c: int = 5): The only place where an example like this could be mentioned would be a motivational section which could suffice by referring to Collin's existing type annotation library and explaining how it could be made more elegant by attaching the types directly to the arguments. The interop issue needn't be mentioned -- I imagine it's not easy to ensure interop between something like Collin's current library and some other library that makes extensive use of decorators, either. A later PEP, based on actual experience, could propose an interop convention to be used by frameworks that expect to be needing it. To me the current fuss about interop sounds like over-analyzing the situation based on zero data points. Remember YAGNI. --Guido On 1/1/07, Tony Lownds <tony@pagedna.com> wrote:
In discussing the Function Annotations PEP on python-list, interoperability between schemes came up again:
http://mail.python.org/pipermail/python-list/2006-December/420645.html
John Roth wrote:
Third, it's half of a proposal. Type checking isn't the only use for metadata about functions/methods, classes, properties and other objects, and the notion that there are only going to be a small number of non-intersecting libraries out there is an abdication of responsibility to think this thing through.
This issue came up before in http://mail.python.org/pipermail/python-3000/2006-August/002796.html and a rather long thread followed. Here is the paragraph in the PEP that needs updating, at the least:
There is no worry that these libraries will assign semantics at random, or that a variety of libraries will appear, each with varying semantics and interpretations of what, say, a tuple of strings means. The difficulty inherent in writing annotation interpreting libraries will keep their number low and their authorship in the hands of people who, frankly, know what they're doing.
The notion that libraries don't intersect should be stripped from the PEP. The question in my mind is whether this PEP needs to take responsibility for interoperability.
I contend that people who design an annotation-consuming library that ends up intersecting several others will likely be capable of finding a solution even if not ideal without a central mechanism, and will be far better situated to define a solution for a central mechanism.
Any thoughts?
Thanks -Tony
_______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas
-- --Guido van Rossum (home page: http://www.python.org/~guido/)
participants (4)
-
Brett Cannon -
Collin Winter -
Guido van Rossum -
Tony Lownds