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 ve
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 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 enhan
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.
>
>
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 c
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
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 ot
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 informati
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
> 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
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 t
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
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),
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 to
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 librari
(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: Draf
16 matches
Mail list logo
