[Python-3000] Draft pre-PEP: function annotations (original) (raw)
Phillip J. Eby pje at telecommunity.com
Fri Aug 11 17:32:55 CEST 2006
- Previous message: [Python-3000] threading, part 2
- Next message: [Python-3000] Draft pre-PEP: function annotations
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
At 06:10 AM 8/11/2006 -0700, Talin <talin at acm.org> wrote:
Or to put it another way: If you create a tool, and you assume that tool will only be used in certain specific ways, but you fail to enforce that limitation, then your assumption will be dead wrong. The idea that there will only be a few type annotation providers who will all nicely cooperate with one another is just as naive as I was in the SysEx debacle.
Are you saying that function annotations are a bad idea because we won't be able to pickle them?
If not, your entire argument seems specious. Actually, even if that is your argument, it's specious, since all that's needed to support pickling is to support pickling. All that's needed to support printing is to support printing (via str), and so on.
Thus, by a similar process of analogy, all that's needed to support any operation is to have an extensible mechanism by which the operation is defined, so that the operation can be extended to include new types -- i.e., an overloadable function, like pickle.dump.
Conversely, using your analogy, one could say that the iteration protocol is a bad idea because lots of people might then have to implement their own iter methods. We should thus only have a fixed set of sequence types!
In short, your argument is based on a false analogy and is nonsensical when moved out of the realm of on-the-wire protocols and into the realm of a programming language.
- Previous message: [Python-3000] threading, part 2
- Next message: [Python-3000] Draft pre-PEP: function annotations
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]