Tony Lownds wrote:
On Dec 31, 2006, at 4:26 AM, Kay Schluehr wrote:
I have two questions:
1) I don't understand the clause ('*' [tname] (',' tname ['=' test])*
in the grammar rule of typedargslist. Does it stem from another PEP?
Yes, PEP 3102 Keyword-only Arguments.
2) Is the
On Jan 1, 2007, at 9:48 AM, Kay Schluehr wrote:
Good. There is still one issue. I understand that you don't want to
fix
the semantics of function annotations but to be usefull some
annotations are needed to express function types. Using those
consistently with the notation of the enhanced
Tony Lownds wrote:
It's possible packages like pylint will learn to interpret function
annotations to provide
better static analysis. Right?
It's true that for the area to be explored, which I know you've been
doing, one first has to introduce an annotation scheme that can then be
used by
On Jan 1, 2007, at 1:53 PM, Paul Boddie wrote:
It's true that for the area to be explored, which I know you've been
doing, one first has to introduce an annotation scheme that can
then be
used by things like pylint. I'd like to see assertions about the
usefulness of such annotations
I have two questions:
1) I don't understand the clause ('*' [tname] (',' tname ['=' test])*
in the grammar rule of typedargslist. Does it stem from another PEP?
2) Is the func_annotation information for def foo(*c: list)
stored as {*c: list} preserving optional argument information or
{c:list} ?
On Dec 31, 2006, at 4:26 AM, Kay Schluehr wrote:
I have two questions:
1) I don't understand the clause ('*' [tname] (',' tname ['=' test])*
in the grammar rule of typedargslist. Does it stem from another PEP?
Yes, PEP 3102 Keyword-only Arguments.
2) Is the func_annotation information
Tony Lownds wrote:
First, it only handles functions/methods. Python FIT needs
metadata on properties and assignable/readable attributes
...
Third, it's half of a proposal. Type checking isn't the only use
for metadata about functions/methods, classes, properties
and other
On Dec 31, 2006, at 7:54 AM, John Roth wrote:
Tony Lownds wrote:
Perhaps you are right and intersecting libraries will become an
issue.
Designing a solution in advance of the problems being evident seems
risky to me. What if the solution invented in a vacuum really is more
of a hindrance?
Tony Lownds wrote:
First, it only handles functions/methods. Python FIT needs
metadata on properties and assignable/readable attributes
of all kinds. So in no sense is it a replacement. Parenthetically,
neither is the decorator facility, and for exactly the same reason.
I can't argue
BJörn Lindqvist wrote:
On 12/29/06, Tony Lownds [EMAIL PROTECTED] wrote:
Rationale
=
Because Python's 2.x series lacks a standard way of annotating a
function's parameters and return values (e.g., with information about
what type a function's return value should be), a variety of
BJörn Lindqvist wrote:
On 12/29/06, Tony Lownds [EMAIL PROTECTED] wrote:
Rationale
=
Because Python's 2.x series lacks a standard way of annotating a
function's parameters and return values (e.g., with information about
what type a function's return value should be), a variety
here's a potentially nifty way of adding decorators to input args for python:
def a(int(arg1), arg2, tuple(arg3)):
#arg1 is an int (or was converted to an int)
#arg2's type is not known (ie this decoration is optional)
#arg3 is a tuple (may have been a list coming in, but is now a
First, it only handles functions/methods. Python FIT needs
metadata on properties and assignable/readable attributes
of all kinds. So in no sense is it a replacement. Parenthetically,
neither is the decorator facility, and for exactly the same reason.
I can't argue against docstrings and
(Note: PEPs in the 3xxx number range are intended for Python 3000)
PEP: 3107
Title: Function Annotations
Version: $Revision: 53169 $
Last-Modified: $Date: 2006-12-27 20:59:16 -0800 (Wed, 27 Dec 2006) $
Author: Collin Winter [EMAIL PROTECTED],
Tony Lownds [EMAIL PROTECTED]
Status: Draft
On 12/29/06, Tony Lownds [EMAIL PROTECTED] wrote:
Rationale
=
Because Python's 2.x series lacks a standard way of annotating a
function's parameters and return values (e.g., with information about
what type a function's return value should be), a variety of tools
and libraries have
On Dec 29, 2006, at 4:09 PM, BJörn Lindqvist wrote:
I think this rationale is very lacking and to weak for such a big
change to Python. I definitely like to see it expanded.
The reference links to two small libraries implementing type checking
using decorators and doc strings. None of which
16 matches
Mail list logo
