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

[Phillip J. Eby]

At 06:56 AM 8/15/2006 -0700, Paul Prescod wrote:
>On 8/14/06, Phillip J. Eby 
><<mailto:pje at telecommunity.com>pje at telecommunity.com> wrote:
>>At 1:51 PM 8/14/2006 -0700, "Paul Prescod" 
>><<mailto:paul at prescod.net>paul at prescod.net> wrote:
>> >On 8/14/06, Jim Jewett 
>> <<mailto:jimjjewett at gmail.com>jimjjewett at gmail.com> wrote:
>> > > The definition of a type as an annotation should probably be either
>> > > defined or explicitly undefined.  Earlier discussions talked about
>> > > things like
>> > >
>> > >     def f (a:int, b:(float | Decimal), c:[int, str, X]) ->str)
>> >
>> >
>> >I think that's a separate (large!) PEP. This PEP should disallow frameworks
>> >from inventing their own meaning for this syntax (requiring them to at 
>> least
>> >wrap). Then Guido and crew can dig into this issue on their own schedule.
>>
>>I see we haven't made nearly as much progress on the concept of "no
>>predefined semantics" as I thought we had.  :(
>
>
>>i.e., -1 on constraining what types mean.
>
>I don't understand what you're saying.

I'm saying that we don't need a predefined semantics for annotation objects 
of type 'type'; i.e. the PEP need not define what "a:int" means.  I'm 
roughly +0 on having predefined semantics for annotation objects of type 
'list' and 'str'.


>1. Do you (still?) agree that the meaning of the list type should be 
>defined as a semantically neutral container for other annotations?

I believe it should be a recommended best practice -- "defined" is too 
strong a word.


>2. Do you (still?) agree that the meanings of ALL built-in types at the 
>top-level should be reserved for the Python language designers and should 
>not be randomly used by framework developers. In other words: the function 
>type declaration syntax above should not be used by one third party type 
>checker while another third-party type checker uses the same structure to 
>mean something totally different. Note that I don't mind if they have 
>conflicting semantics for the same expression as long as the end-user is 
>forced to declare which semantic model they are using:

I don't see a reason to require an explicit wrapper except as a 
disambiguator.  That is, until you *actually* need them, 
discriminator-wrappers are a YAGNI.