headers
Josiah Carlson | 1 Jan 2007 23:03
Picon
Favicon

Re: [Python-3000] PEP 3107 Function Annotations: overloadable ->


To Tony and Kay, my short answer is: use __returns__ .

Moving to python-ideas as per Guido's request:

"Guido van Rossum" <guido@...> wrote:
> This is sufficiently controversial that I believe it ought to go to
> python-ideas first. If it comes to a PEP it should be a separate one
> from PEP 3107.

> On 1/1/07, Talin <talin@...> wrote:
> > Tony Lownds wrote:
> > >> From: Tony Lownds <tony@...>
> > > What do people here think?
> > 1) Normally, we don't name operators based on their shape - we don't
> > call '/' the __slash__ operator, for example, nor do we call '|' the
> > "__vbar__" operator.

Certainly, but those two operators, and basically every other operator
used in Python have long-standing semantics in basically every language
that Python is even remotely related to.

> > 2) I think that all operators should have a "suggested semantic". When
> > someone overloads the '+' operator, its a good bet that the meaning of
> > the overload has something to do with addition or accumulation in a
> > general sense. This won't *always* be true, but it will be true often
> > enough.

I don't buy your "suggested semantic" argument.  And even if I did,
operator overloading allows people to choose the semantics of operations
(Continue reading)

Permalink | Reply | 10 comments |
headers
Talin | 1 Jan 2007 23:25
Picon
Favicon

Re: [Python-3000] PEP 3107 Function Annotations: overloadable ->

Josiah Carlson wrote:
> To Tony and Kay, my short answer is: use __returns__ .
> 
> Moving to python-ideas as per Guido's request:
> 
> "Guido van Rossum" <guido@...> wrote:
>> This is sufficiently controversial that I believe it ought to go to
>> python-ideas first. If it comes to a PEP it should be a separate one
>> from PEP 3107.
> 
>> On 1/1/07, Talin <talin@...> wrote:
>>> Tony Lownds wrote:
>>>>> From: Tony Lownds <tony@...>
>>>> What do people here think?
>>> 1) Normally, we don't name operators based on their shape - we don't
>>> call '/' the __slash__ operator, for example, nor do we call '|' the
>>> "__vbar__" operator.
> 
> Certainly, but those two operators, and basically every other operator
> used in Python have long-standing semantics in basically every language
> that Python is even remotely related to.
> 
> 
>>> 2) I think that all operators should have a "suggested semantic". When
>>> someone overloads the '+' operator, its a good bet that the meaning of
>>> the overload has something to do with addition or accumulation in a
>>> general sense. This won't *always* be true, but it will be true often
>>> enough.
> 
> I don't buy your "suggested semantic" argument.  And even if I did,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tony Lownds | 1 Jan 2007 23:28

Re: [Python-3000] PEP 3107 Function Annotations: overloadable ->


On Jan 1, 2007, at 2:03 PM, Josiah Carlson wrote:

>
> To Tony and Kay, my short answer is: use __returns__ .
>

Thanks

Talin's arguments for a consistent semantic make me think
that __implies__ would be a bad idea (among other things).

Is anyone against "->" overloadable as __returns__ /__rreturns__
with no semantics for existing types?

-Tony
Permalink | Reply | 8 comments |
headers
Tony Lownds | 2 Jan 2007 00:17

PEP 3107 Function Annotations: interoperability (again)

In discussing the Function Annotations PEP on python-list,  
interoperability
between schemes came up again:

http://mail.python.org/pipermail/python-list/2006-December/420645.html

John Roth wrote:
> Third, it's half of a proposal. Type checking isn't the only use
> for metadata about functions/methods, classes, properties
> and other objects, and the notion that there are only going to
> be a small number of non-intersecting libraries out there is
> an abdication of responsibility to think this thing through.

This issue came up before in
http://mail.python.org/pipermail/python-3000/2006-August/002796.html
and a rather long thread followed. Here is the paragraph in the PEP that
needs updating, at the least:

    There is no worry that these libraries will assign semantics at
    random, or that a variety of libraries will appear, each with
    varying semantics and interpretations of what, say, a tuple of
    strings means. The difficulty inherent in writing annotation
    interpreting libraries will keep their number low and their
    authorship in the hands of people who, frankly, know what they're
    doing.

The notion that libraries don't intersect should be stripped from the
PEP. The question in my mind is whether this PEP needs to take
responsibility for interoperability.
(Continue reading)

Permalink | Reply | 752 comments |
headers
Brett Cannon | 2 Jan 2007 01:17
Favicon
Gravatar

Re: PEP 3107 Function Annotations: interoperability (again)



On 1/1/07, Tony Lownds <tony-lBXE9glqS0xBDgjK7y7TUQ@public.gmane.org> wrote:
In discussing the Function Annotations PEP on python-list,
interoperability
between schemes came up again:

http://mail.python.org/pipermail/python-list/2006-December/420645.html

John Roth wrote:
> Third, it's half of a proposal. Type checking isn't the only use
> for metadata about functions/methods, classes, properties
> and other objects, and the notion that there are only going to
> be a small number of non-intersecting libraries out there is
> an abdication of responsibility to think this thing through.

This issue came up before in
http://mail.python.org/pipermail/python-3000/2006-August/002796.html
and a rather long thread followed. Here is the paragraph in the PEP that
needs updating, at the least:

    There is no worry that these libraries will assign semantics at
    random, or that a variety of libraries will appear, each with
    varying semantics and interpretations of what, say, a tuple of
    strings means. The difficulty inherent in writing annotation
    interpreting libraries will keep their number low and their
    authorship in the hands of people who, frankly, know what they're
    doing.

The notion that libraries don't intersect should be stripped from the
PEP. The question in my mind is whether this PEP needs to take
responsibility for interoperability.

I contend that people who design an annotation-consuming library
that ends up intersecting several others will likely be capable of
finding
a solution even if not ideal without a central mechanism, and will be
far
better situated to define a solution for a central mechanism.

Any thoughts?


Until extensive usage happens with annotations we shouldn't try to shoehorn consumers of the annotations into a specific solution.  As you said, something will probably organically grow and that can be supported in another PEP later on (probably with stdlib support).  People tend to want to design up front but with something like this that is meant to be highly customizable by the people wanting to use it you just don't get that option without ample feedback from users.

-Brett


_______________________________________________
Python-ideas mailing list
Python-ideas@...
http://mail.python.org/mailman/listinfo/python-ideas
Permalink | Reply | 4 comments |
headers
Guido van Rossum | 2 Jan 2007 01:20
Favicon

Re: [Python-3000] PEP 3107 Function Annotations: overloadable ->

On 1/1/07, Tony Lownds <tony@...> wrote:
> Is anyone against "->" overloadable as __returns__ /__rreturns__
> with no semantics for existing types?

I suggest that you question *really* *hard* whether it's worth it.
We'd be introducing two very different syntactic uses for '->'. I
chose this operator to signify function return annotation specifically
because it *does't* have another meaning in Python. (My first choice
would've been ':', which is mostly a delimiter that derives its
meaning from context, like ',', but that would've introduced too much
syntactic ambiguity.

--

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
Permalink | Reply | 7 comments |
headers
Guido van Rossum | 2 Jan 2007 01:40
Favicon

Re: PEP 3107 Function Annotations: interoperability (again)

Well, it's your PEP, isn't it? Just submit a change to the PEP editor.

If it were me, any suggestion of how annotations could/should be used
should be stricken from the PEP, including the example

  def foo(a: int, b: dict, c: int = 5):

The only place where an example like this could be mentioned would be
a motivational section which could suffice by referring to Collin's
existing type annotation library and explaining how it could be made
more elegant by attaching the types directly to the arguments. The
interop issue needn't be mentioned -- I imagine it's not easy to
ensure interop between something like Collin's current library and
some other library that makes extensive use of decorators, either.

A later PEP, based on actual experience, could propose an interop
convention to be used by frameworks that expect to be needing it. To
me the current fuss about interop sounds like over-analyzing the
situation based on zero data points. Remember YAGNI.

--Guido

On 1/1/07, Tony Lownds <tony@...> wrote:
> In discussing the Function Annotations PEP on python-list,
> interoperability
> between schemes came up again:
>
> http://mail.python.org/pipermail/python-list/2006-December/420645.html
>
> John Roth wrote:
> > Third, it's half of a proposal. Type checking isn't the only use
> > for metadata about functions/methods, classes, properties
> > and other objects, and the notion that there are only going to
> > be a small number of non-intersecting libraries out there is
> > an abdication of responsibility to think this thing through.
>
> This issue came up before in
> http://mail.python.org/pipermail/python-3000/2006-August/002796.html
> and a rather long thread followed. Here is the paragraph in the PEP that
> needs updating, at the least:
>
>     There is no worry that these libraries will assign semantics at
>     random, or that a variety of libraries will appear, each with
>     varying semantics and interpretations of what, say, a tuple of
>     strings means. The difficulty inherent in writing annotation
>     interpreting libraries will keep their number low and their
>     authorship in the hands of people who, frankly, know what they're
>     doing.
>
> The notion that libraries don't intersect should be stripped from the
> PEP. The question in my mind is whether this PEP needs to take
> responsibility for interoperability.
>
> I contend that people who design an annotation-consuming library
> that ends up intersecting several others will likely be capable of
> finding
> a solution even if not ideal without a central mechanism, and will be
> far
> better situated to define a solution for a central mechanism.
>
> Any thoughts?
>
> Thanks
> -Tony
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas@...
> http://mail.python.org/mailman/listinfo/python-ideas
>

--

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
Permalink | Reply | 751 comments |
headers
Josiah Carlson | 2 Jan 2007 02:39
Picon
Favicon

Re: [Python-3000] PEP 3107 Function Annotations: overloadable ->


"Guido van Rossum" <guido@...> wrote:
> 
> On 1/1/07, Tony Lownds <tony@...> wrote:
> > Is anyone against "->" overloadable as __returns__ /__rreturns__
> > with no semantics for existing types?
> 
> I suggest that you question *really* *hard* whether it's worth it.
> We'd be introducing two very different syntactic uses for '->'. I
> chose this operator to signify function return annotation specifically
> because it *does't* have another meaning in Python. (My first choice
> would've been ':', which is mostly a delimiter that derives its
> meaning from context, like ',', but that would've introduced too much
> syntactic ambiguity.

Just to clarify, the only place '->' is allowable is in the case of
function annotations...

    def <name>(<args...>) -> <annotation>:
        <body>

Given a reading of version 53169 of PEP 3107, I see no reason to even
offer a __returns__ attribute, automatic method call, etc.  PEP 3107
already defines the annotation to be specified as a dictionary of named
argument names, with a key of 'return' for the annotation of the return
annotation.  Is there any reason why this isn't sufficient?

Even in the context of the signature PEP 362, there is no need for
__returns__, as an annotation-consuming library would check the
signature object for argument annotations, and the func_annotations
dictionary for the 'return' key for any return annotations.

 - Josiah
Permalink | Reply | 6 comments |
headers
Tony Lownds | 2 Jan 2007 03:53

Attribute Docstrings and Annotations

I'd like to propose annotations and docstrings on attributes for  
Python 3000
with the following Grammar and properties:

expr_stmt: test (':' test ['=' (yield_expr|testlist)] |
                  augassign (yield_expr|testlist) |
                  [',' testlist] ('=' (yield_expr|testlist))*
                 )

* annotations can appear for attributes that are not defined yet
* code to generate and populate __annotations__ and __attrdoc__
   would appear for all modules and class bodies, not for functions.
* attribute annotations allow a name as target only
* attribute annotations without assignment are illegal for functions
* attribute annotations with assignment should probably be illegal  
for functions
* docstring annotations only apply to the first target, and only if  
it is a name
* docstring annotations do not apply to augmented assignments
* docstring and annotations on functions do not get populated in  
__annotations__
* the class docstring is not reused as a function docstring

The basic rationale for annotations on attributes is completeness  
with PEP3107.
I'm proposing attribute docstrings as well because I think it's  
preferable to have
a spot for documentation that isn't tied to annotations, like  
functions' __doc__.
Also attribute docstrings as specified look similar to function  
docstrings; both
have statements consisting of only a string that is taken as  
documentation.

Here is an interactive session and the code that might be generated.  
What do you
think?

Thanks
-Tony

 >>> class X:
...     "class docstring"
...     foo: 1 = 1
...     bar: 2
...     "attribute docstring"
...     attr = None
...     "another attribute docstring"
...     fields = __slots__ = ['fields', 'attr']
...     "docstring ignored"
...     x, y = 1, 2
...
 >>> X.__attrdoc__
{'fields': 'another attribute docstring', 'attr': 'attribute docstring'}
 >>> X.__annotations__
{'foo': 1, 'bar': 2}
 >>> X.foo
1
 >>> X.bar
Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
AttributeError: type object 'X' has no attribute 'bar'
 >>> def f():
...     x: 1
...
   File "<stdin>", line 2
SyntaxError: annotation without assignment not allowed in function

   2           0 LOAD_NAME                0 (__name__)
               3 STORE_NAME               1 (__module__)
               6 BUILD_MAP                0
               9 STORE_NAME               2 (__annotations__)
              12 BUILD_MAP                0
              15 STORE_NAME               3 (__attrdoc__)

   3          18 LOAD_CONST               0 ('class docstring')
              21 STORE_NAME               4 (__doc__)

   5          24 LOAD_CONST               1 ('attribute docstring')
              27 LOAD_NAME                3 (__attrdoc__)
              30 LOAD_CONST               2 ('attr')
              33 STORE_SUBSCR
              34 LOAD_NAME                5 (None)
              37 STORE_NAME               6 (attr)

   6          40 LOAD_CONST               3 (1)
              48 STORE_NAME               7 (foo)
              44 LOAD_CONST               3 (1)
              51 LOAD_NAME                2 (__annotations__)
              54 LOAD_CONST               4 ('foo')
              57 STORE_SUBSCR

   7          58 LOAD_CONST               5 (2)
              61 LOAD_NAME                2 (__annotations__)
              64 LOAD_CONST               6 ('bar')
              67 STORE_SUBSCR

   9          68 LOAD_CONST               7 ('another attribute  
docstring')
              71 LOAD_NAME                3 (__attrdoc__)
              74 LOAD_CONST               8 ('fields')
              77 STORE_SUBSCR
              78 LOAD_CONST               8 ('fields')
              81 LOAD_CONST               2 ('attr')
              84 BUILD_LIST               2
              87 DUP_TOP
              88 STORE_NAME               8 (fields)
              91 STORE_NAME               9 (__slots__)
              94 LOAD_LOCALS
              95 RETURN_VALUE
Permalink | Reply | 7 comments |
headers
Tony Lownds | 2 Jan 2007 04:28

Re: [Python-3000] PEP 3107 Function Annotations: overloadable ->


On Jan 1, 2007, at 5:39 PM, Josiah Carlson wrote:

> Given a reading of version 53169 of PEP 3107, I see no reason to even
> offer a __returns__ attribute, automatic method call, etc.  PEP 3107
> already defines the annotation to be specified as a dictionary of  
> named
> argument names, with a key of 'return' for the annotation of the  
> return
> annotation.  Is there any reason why this isn't sufficient?
>
> Even in the context of the signature PEP 362, there is no need for
> __returns__, as an annotation-consuming library would check the
> signature object for argument annotations, and the func_annotations
> dictionary for the 'return' key for any return annotations.

Something got lost in the movement between lists... __returns__ wasn't
going to supplant or alter func_annotations or PEP 362 in any way.

__returns__ was proposed as the special method attached to a new
operator (->). That operator could be used to write expressions that  
look
like a function signature.

Here's Kay's original email.

http://mail.python.org/pipermail/python-list/2007-January/420774.html

-Tony
Permalink | Reply | 5 comments |

Gmane