At 06:56 AM 8/15/2006 -0700, Paul Prescod wrote: >On 8/14/06, Phillip J. Eby ><<mailto:[EMAIL PROTECTED]>[EMAIL PROTECTED]> wrote: >>At 1:51 PM 8/14/2006 -0700, "Paul Prescod" >><<mailto:[EMAIL PROTECTED]>[EMAIL PROTECTED]> wrote: >> >On 8/14/06, Jim Jewett >> <<mailto:[EMAIL PROTECTED]>[EMAIL PROTECTED]> 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. _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
