On 8/14/06, <b class="gmail_sendername">Phillip J. Eby</b> &lt;<a href="mailto:pje@telecommunity.com">pje@telecommunity.com</a>&gt; wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
At 1:51 PM 8/14/2006 -0700, &quot;Paul Prescod&quot; &lt;<a href="mailto:paul@prescod.net">paul@prescod.net</a>&gt; wrote:<br>&gt;On 8/14/06, Jim Jewett &lt;<a href="mailto:jimjjewett@gmail.com">jimjjewett@gmail.com</a>&gt; wrote:
<br>&gt; &gt; The definition of a type as an annotation should probably be either<br>&gt; &gt; defined or explicitly undefined.&nbsp;&nbsp;Earlier discussions talked about<br>&gt; &gt; things like<br>&gt; &gt;<br>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; def f (a:int, b:(float | Decimal), c:[int, str, X]) -&gt;str)
<br>&gt;<br>&gt;<br>&gt;I think that's a separate (large!) PEP. This PEP should disallow frameworks<br>&gt;from inventing their own meaning for this syntax (requiring them to at least<br>&gt;wrap). Then Guido and crew can dig into this issue on their own schedule.
<br><br>I see we haven't made nearly as much progress on the concept of &quot;no<br>predefined semantics&quot; as I thought we had.&nbsp;&nbsp;:(<br></blockquote><div>&nbsp;</div><br><div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
i.e., -1 on constraining what types mean.<br><br></blockquote><br>I don't understand what you're saying.<br><br>1. Do you (still?) agree that the meaning of the list type should be defined as a semantically neutral container for other annotations?
<br><br>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:
<br><br>tc = typechecker.typecheck<br>tl = typelinter.check_types<br><br>def f (a:tc(int), <br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; b:tc(float | Decimal), <br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; c:tc([int, str, X])) -&gt; tc(str)<br></div><br>def g (a:tl(int), <br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; b:tl(float | Decimal), 
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; c:tl([int, str, X])) -&gt; tl(str)<br><br>3. Do you agree that 1. and 2. together promotes the experimentation and variety that we need?<br><br>def f (a: [tc(int),tl(&quot;Integer&quot;)] <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; b: [tc(float | Decimal), tl(Or(&quot;float&quot;, &quot;Decimal&quot;)]<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; c: [tc([int, str, X]), tl(listOf(&quot;Integer&quot;, &quot;string&quot;, &quot;X&quot;))] ) -&gt; <br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [tc(str), tl(str)]<br>
<br>&nbsp;Paul Prescod<br><br></div>