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
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/)
"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(Continue reading)
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(Continue reading)
Tony Lownds <tony@...> wrote: > > > 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(Continue reading)
On Jan 1, 2007, at 10:34 PM, Josiah Carlson wrote: > -1 on the -> operator as specified in the email you link. There is no > reason to add aribtrary operators for call-site annotations. What was the arbitrary operator? -> is not arbitrary, and there was a reason given to add it. > PEP 3107 > has already defined the syntax for function definition site > annotations > as follows... > > def name(argument=default:annotation) -> annotation: > body > You mean def name(argument:annotation=default) > The mail you link, talks about an arbitrary -> operator for call-site > annotations. Without seeing actual use-cases where a -> operator > would > be useful in the real-world, I can't help but be -1 on the -> operator > and -1 on the __returns__ method. That email had a use case... The gain is being able to write(Continue reading)
Tony Lownds <tony@...> wrote: > On Jan 1, 2007, at 10:34 PM, Josiah Carlson wrote: > > -1 on the -> operator as specified in the email you link. There is no > > reason to add aribtrary operators for call-site annotations. > > What was the arbitrary operator? -> is not arbitrary, and there was a > reason given to add it. I misunderstood portions of the post. > > PEP 3107 > > has already defined the syntax for function definition site > > annotations > > as follows... > > > > def name(argument=default:annotation) -> annotation: > > body > > You mean > > def name(argument:annotation=default) Thank you for the correction. Maybe I'm the only one, but I would prefer the default value to come before the annotation. > > The mail you link, talks about an arbitrary -> operator for call-site > > annotations. Without seeing actual use-cases where a -> operator > > would > > be useful in the real-world, I can't help but be -1 on the -> operator(Continue reading)
On 1/2/07, Josiah Carlson <jcarlson@...> wrote: > > > PEP 3107 > > > has already defined the syntax for function definition site > > > annotations > > > as follows... > > > > > > def name(argument=default:annotation) -> annotation: > > > body > > > > You mean > > > > def name(argument:annotation=default) > > Thank you for the correction. Maybe I'm the only one, but I would > prefer the default value to come before the annotation. You're about a year and a half too late with this objection. And anyway, I strongly favor putting the annotation first; that's how it is in other languages from which Python has borrowed before, e.g. Modula-3. Regarding the status of the PEP: I am mostly waiting for the wording to improve, e.g. not use examples that suggest this will have type checking semantics by default. I am +1 on the syntax used in the PEP, since it is what I have been proposing for a long time. I am against more additions like an '->' operator or attribute annotations or anything else at this point, at least until there has been actual experience with using the implementation as-is. (And yes, I have seen the use case, and remain unconvinced. Not every use case(Continue reading)
Josiah Carlson schrieb: >Tony Lownds <tony@...> wrote: > > >>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.(Continue reading)
RSS Feed