At 1:51 PM 8/14/2006 -0700, "Paul Prescod" <[EMAIL PROTECTED]> wrote:
>On 8/14/06, Jim Jewett <[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.
1. Do you (still?) agree that the meaning of the list type should be defined as a semantically neutral container for other annotations?
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:
tc = typechecker.typecheck
tl = typelinter.check_types
def f (a:tc(int),
b:tc(float | Decimal),
c:tc([int, str, X])) -> tc(str)
def g (a:tl(int),
b:tl(float | Decimal),
c:tl([int, str, X])) -> tl(str)
3. Do you agree that 1. and 2. together promotes the experimentation and variety that we need?
def f (a: [tc(int),tl("Integer")]
b: [tc(float | Decimal), tl(Or("float", "Decimal")]
c: [tc([int, str, X]), tl(listOf("Integer", "string", "X"))] ) ->
[tc(str), tl(str)]
Paul Prescod
_______________________________________________ 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
