On 8/15/06, Collin Winter <
[EMAIL PROTECTED]> wrote:
Consider the following syntax:
class MyType:
def __init__(self, name):
self.name = name
Number = MyType("Number")
Tuple = MyTime("Tuple")
def foo(a: tc(Number)) -> Tuple(Number, Number)
1. Static analysis tools can deal with this as much as with ANY truly Pythonic syntax. Their ability to deal will depend (as in any syntax) on their ability to do module or whole-program analysis. In your syntax, or mine, "Number" could be defined dynamically. In either case, someone could say "Number = None" and confuse everything.
2. A decorator based anaysis could look at __signatures__ and do what it needs.
3. Similarly for non-decorator analyzers.
In fact, given that decorators are just syntactic sugar for function calls, I don't see why they should require special consideration at all. If the syntax works well for non-decorator consumers then decorators will be just a special case. As far as static analysis tools: Python has never made major concessions to them. Minor concessions, yes.
I'd ask that you add the following requirement:
* must define how multiple annotation syntaxes can assign potentially differing meanings to built-in types and objects, on the same parameter, without actually conflicting
My full program (meeting all requirements) follows.
Paul Prescod
====
def simulate_signature(sig):
"simulates the signature feature of Pythn 3000"
def _(func):
func.__signature__ = sig
return func
return _
def my_print_signature(func):
"a demo decorator that prints signatures."
if hasattr(func, "__signature__"):
sig = func.__signature__
[my_print_arg(name, value) for name, value in sig.items()]
return func
def my_print_arg(name, annotation):
"""print a single argument's
declaration, skipping unknown anno types."""
if isinstance(annotation, list):
[my_print_arg(name, anno)
for anno in annotation]
elif conformsToInterface(annotation, MyType):
print name
annotation.print_arg ()
def conformsToInterface(object, interface):
"naive implemenation of interfaces"
return isinstance(object, interface)
class MyType:
def __init__(self, *children):
self.children = children
def print_arg(self):
print self.children
#defined in your module. I have no knowledge of it
class YourType:
def __init__(self, *stuff):
pass
# a simple signature
# real syntax should be:
# def foo(bar: MyType(int))
@simulate_signature({"bar": MyType(int)})
def foo(bar):
return (bar, bar)
# use print signature decorator
# real syntax should be:
# def foo2(bar: [MyType(int)...]) -> [MyType(...]
@my_print_signature
@simulate_signature({"bar": [MyType(int), YourType("int")],
"return": [MyType(tuple([int, int])),
YourType("tuple of int,int")]})
def foo2(bar):
return (bar, bar)
# can also be used as non-decorator
for name, val in vars().items():
my_print_signature(val)
@typechecker
def foo(a: {'type': Number},
b: {'type': Number}) -> {'type': Number}
I'm going to raise the bar for future ideas on this subject: any
proposals must be able to address the following use cases:
1) Static analysis tools (pychecker, optimising compilers, etc) must
be able to use the annotations
2) Decorator-based annotation consumers must be able to use the annotations
3) Non-decorator-based annotation consumers (pydoc, etc) must be able
to use the annotations
Consider the following syntax:
class MyType:
def __init__(self, name):
self.name = name
Number = MyType("Number")
Tuple = MyTime("Tuple")
def foo(a: tc(Number)) -> Tuple(Number, Number)
1. Static analysis tools can deal with this as much as with ANY truly Pythonic syntax. Their ability to deal will depend (as in any syntax) on their ability to do module or whole-program analysis. In your syntax, or mine, "Number" could be defined dynamically. In either case, someone could say "Number = None" and confuse everything.
2. A decorator based anaysis could look at __signatures__ and do what it needs.
3. Similarly for non-decorator analyzers.
In fact, given that decorators are just syntactic sugar for function calls, I don't see why they should require special consideration at all. If the syntax works well for non-decorator consumers then decorators will be just a special case. As far as static analysis tools: Python has never made major concessions to them. Minor concessions, yes.
I'd ask that you add the following requirement:
* must define how multiple annotation syntaxes can assign potentially differing meanings to built-in types and objects, on the same parameter, without actually conflicting
My full program (meeting all requirements) follows.
Paul Prescod
====
def simulate_signature(sig):
"simulates the signature feature of Pythn 3000"
def _(func):
func.__signature__ = sig
return func
return _
def my_print_signature(func):
"a demo decorator that prints signatures."
if hasattr(func, "__signature__"):
sig = func.__signature__
[my_print_arg(name, value) for name, value in sig.items()]
return func
def my_print_arg(name, annotation):
"""print a single argument's
declaration, skipping unknown anno types."""
if isinstance(annotation, list):
[my_print_arg(name, anno)
for anno in annotation]
elif conformsToInterface(annotation, MyType):
print name
annotation.print_arg ()
def conformsToInterface(object, interface):
"naive implemenation of interfaces"
return isinstance(object, interface)
class MyType:
def __init__(self, *children):
self.children = children
def print_arg(self):
print self.children
#defined in your module. I have no knowledge of it
class YourType:
def __init__(self, *stuff):
pass
# a simple signature
# real syntax should be:
# def foo(bar: MyType(int))
@simulate_signature({"bar": MyType(int)})
def foo(bar):
return (bar, bar)
# use print signature decorator
# real syntax should be:
# def foo2(bar: [MyType(int)...]) -> [MyType(...]
@my_print_signature
@simulate_signature({"bar": [MyType(int), YourType("int")],
"return": [MyType(tuple([int, int])),
YourType("tuple of int,int")]})
def foo2(bar):
return (bar, bar)
# can also be used as non-decorator
for name, val in vars().items():
my_print_signature(val)
_______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
