Re: [Python-3000] Draft pre-PEP: function annotations

On 8/15/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote: I don't see a reason to require an explicit wrapper except as adisambiguator.  That is, until you *actually* need them,discriminator-wrappers are a YAGNI.How will you know you "actually" need them until you run a tool on your code and it crashes

Re: [Python-3000] Draft pre-PEP: function annotations

At 06:56 AM 8/15/2006 -0700, Paul Prescod wrote: >On 8/14/06, Phillip J. Eby ><[EMAIL PROTECTED]> wrote: >>At 1:51 PM 8/14/2006 -0700, "Paul Prescod" >><[EMAIL PROTECTED]> wrote: >> >On 8/14/06, Jim Jewett >> <[EMAIL P

Re: [Python-3000] Draft pre-PEP: function annotations

At 07:04 AM 8/15/2006 -0700, Paul Prescod wrote: >On 8/14/06, Guido van Rossum <[EMAIL PROTECTED]> >wrote: >> >>Haven't I said that the whole time? I *thought* that Collin's PEP >>steered clear from the topic too. At the same time, does this preclude >>having some kind o

Re: [Python-3000] Draft pre-PEP: function annotations

On 8/14/06, Guido van Rossum <[EMAIL PROTECTED]> wrote: Haven't I said that the whole time? I *thought* that Collin's PEPsteered clear from the topic too. At the same time, does this precludehaving some kind of "default" type notation in the standard library? The PEP steered TOO far of this topic.

Re: [Python-3000] Draft pre-PEP: function annotations

On 8/14/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote: At 1:51 PM 8/14/2006 -0700, "Paul Prescod" <[EMAIL PROTECTED]> wrote:>On 8/14/06, Jim Jewett <[EMAIL PROTECTED]> wrote: > > The definition of a type as an annotation should probably be either> > defined or explicitly undefined.  Earlier discussi

Re: [Python-3000] Draft pre-PEP: function annotations

On 8/14/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > At 1:51 PM 8/14/2006 -0700, "Paul Prescod" <[EMAIL PROTECTED]> wrote: > >On 8/14/06, Jim Jewett <[EMAIL PROTECTED]> wrote: > > > The definition of a type as an annotation should probably be either > > > defined or explicitly undefined. Earlie

Re: [Python-3000] Draft pre-PEP: function annotations

Phillip J. Eby wrote: > How is such a thing going to know what doc("foo") means at the time the > code is run? What about closures, dynamic imports, etc.? Annotations intended for such external processors would have to be designed not to rely on anything dynamic, i.e. be purely declarative. Ma

Re: [Python-3000] Draft pre-PEP: function annotations

At 01:19 PM 8/15/2006 +1200, Greg Ewing wrote: >Phillip J. Eby wrote: > > > The examples there are very short >>and simple; in fact the complete Message implementation, including >>imports and overload declarations is only *6 lines long*. >>So, my only guess is that the people who looked at that s

Re: [Python-3000] Draft pre-PEP: function annotations

At 01:13 PM 8/15/2006 +1200, Greg Ewing wrote: >Phillip J. Eby wrote: > >>It can't be a "separate program altogether", since to get at the >>annotations, the program must import the module that contains them. > >Why? I can imagine something like a documentation >generator or static type checker t

Re: [Python-3000] Draft pre-PEP: function annotations

Phillip J. Eby wrote: > The examples there are very short > and simple; in fact the complete Message implementation, including > imports and overload declarations is only *6 lines long*. > > So, my only guess is that the people who looked at that skimmed right > past it, looking for something

Re: [Python-3000] Draft pre-PEP: function annotations

Phillip J. Eby wrote: > It can't be a "separate program altogether", since to get at the > annotations, the program must import the module that contains them. Why? I can imagine something like a documentation generator or static type checker that just parses the source, being careful not to exe

Re: [Python-3000] Draft pre-PEP: function annotations

On 8/14/06, Collin Winter <[EMAIL PROTECTED]> wrote: > On 8/13/06, Paul Prescod <[EMAIL PROTECTED]> wrote: > > "In order for processors of function annotations to work interoperably, they > > must use a common interpretation of objects used as annotations on a > > particular function. For example,

Re: [Python-3000] Draft pre-PEP: function annotations

At 1:51 PM 8/14/2006 -0700, "Paul Prescod" <[EMAIL PROTECTED]> wrote: >On 8/14/06, Jim Jewett <[EMAIL PROTECTED]> wrote: > > The definition of a type as an annotation should probably be either > > defined or explicitly undefined. Earlier discussions talked about > > things like > > > > def f (

Re: [Python-3000] Draft pre-PEP: function annotations

On 8/14/06, Collin Winter <[EMAIL PROTECTED]> wrote: Because not having standardised meanings at the same time as thefeature becomes available says to developers, "don't use the built-intypes in your annotations because we might give them a meaninglater...or maybe we won't...but in the meantime, yo

Re: [Python-3000] Draft pre-PEP: function annotations

On 8/14/06, Paul Prescod <[EMAIL PROTECTED]> wrote: > > > "This implies that the interpretation of built-in types would be > controlled > > > by Python's developers and documented in Python's documentation. > > It also implies that the interpretation of annotations made with a > > built-in type s

Re: [Python-3000] Draft pre-PEP: function annotations

On 8/14/06, Paul Prescod <[EMAIL PROTECTED]> wrote: > On 8/14/06, Collin Winter <[EMAIL PROTECTED]> wrote: > > On 8/14/06, Paul Prescod <[EMAIL PROTECTED]> wrote: > > > Second, we can decide to do the standardization at any point. > > > > Um, "at any point"? You mean it's conceivable that this > >

Re: [Python-3000] Draft pre-PEP: function annotations

On 8/14/06, Collin Winter <[EMAIL PROTECTED]> wrote: On 8/14/06, Paul Prescod <[EMAIL PROTECTED]> wrote:> There are three issues: first, we need to RESERVE the types for> standardization by Guido and crew.You're just pushing the decision off to someone else. Regardless of who makes it, decisions in

Re: [Python-3000] Draft pre-PEP: function annotations

On 8/14/06, Paul Prescod <[EMAIL PROTECTED]> wrote: > There are three issues: first, we need to RESERVE the types for > standardization by Guido and crew. You're just pushing the decision off to someone else. Regardless of who makes it, decisions involving the built-in types are going to make some

Re: [Python-3000] Draft pre-PEP: function annotations

On 8/14/06, Jim Jewett <[EMAIL PROTECTED]> wrote: Should annotation objects with defined semantics have some standardway to indicate this?  (By analogy, new exceptions *should* inheritfrom Exception; should annotation objects inherit from an Annotationclass, at least as a mixin?) All annotation obj

Re: [Python-3000] Draft pre-PEP: function annotations

On 8/14/06, Collin Winter <[EMAIL PROTECTED]> wrote: The way I read this, it forces (more or less) eachannotation-consuming library to invent new ways to spell Python'sbuilt-in types.I think that this is related to your other question. What if an annotation consuming library wanted to use Python's

Re: [Python-3000] Draft pre-PEP: function annotations

On 8/13/06, Paul Prescod <[EMAIL PROTECTED]> wrote: > "In order for processors of function annotations to work interoperably, they > must use a common interpretation of objects used as annotations on a > particular function. For example, one might interpret string annotations as > docstrings. Anoth

Re: [Python-3000] Draft pre-PEP: function annotations

On 8/13/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > However, it's only a problem if you insist on writing brain-damaged > code. If you want interoperability here, you must write tell-don't-ask > code. ... is it really the case that > so many people don't know what tell-don't-ask code is or w

Re: [Python-3000] Draft pre-PEP: function annotations

On 8/13/06, Paul Prescod <[EMAIL PROTECTED]> wrote: > My proposed text for the PEP is as follows: Mostly good. A few remaining comments... Should annotation objects with defined semantics have some standard way to indicate this? (By analogy, new exceptions *should* inherit from Exception; shoul

Re: [Python-3000] Draft pre-PEP: function annotations

At 03:22 PM 8/14/2006 +1200, Greg Ewing wrote: >Phillip J. Eby wrote: >>Since many people seem to be unfamiliar with overloaded functions, I >>would just like to take this opportunity to remind you that the actual >>overload mechanism is irrelevant. > >I don't think it's the concept of overloadab

Re: [Python-3000] Draft pre-PEP: function annotations

At 03:22 PM 8/14/2006 +1200, Greg Ewing wrote: >Phillip J. Eby wrote: > >>Not at all. A and B need only use overloadable functions, and the >>problem is trivially resolved by adding overloads. The author of C can >>add an overload to "A" that will handle objects with 'next' attributes, >>or ad

Re: [Python-3000] Draft pre-PEP: function annotations

Phillip J. Eby wrote: > Not at all. A and B need only use overloadable functions, and the problem > is trivially resolved by adding overloads. The author of C can add an > overload to "A" that will handle objects with 'next' attributes, or add one > to "B" that handles tuples, or both. Phill

Re: [Python-3000] Draft pre-PEP: function annotations

Phillip J. Eby wrote: > Since many people seem to be unfamiliar with overloaded functions, I would > just like to take this opportunity to remind you that the actual overload > mechanism is irrelevant. I don't think it's the concept of overloadable functions that people are having trouble with

Re: [Python-3000] Draft pre-PEP: function annotations

Paul Prescod wrote: > If we get past the meta-discussion, I don't really see any disagreement > left. I'll grit my teeth and avoid commenting on the meta-discussion. ;) Ah, so I'm not the only one doing that then };> > My proposed text for the PEP is as follows: Generally +1, except for this bi

Re: [Python-3000] Draft pre-PEP: function annotations

If we get past the meta-discussion, I don't really see any disagreement left. I'll grit my teeth and avoid commenting on the meta-discussion. ;)My proposed text for the PEP is as follows:"In order for processors of function annotations to work interoperably, they must use a common interpretation of

Re: [Python-3000] Draft pre-PEP: function annotations

At 01:06 AM 8/13/2006 -0700, Paul Prescod wrote: >There is something different about annotations than everything else in >Python so far. Annotations are the first feature other than docstrings >(which are proto-annotations) in core Python where third party tools are >supposed to go trolling thro

Re: [Python-3000] Draft pre-PEP: function annotations

"Paul Prescod" <[EMAIL PROTECTED]> wrote: > On 8/13/06, Josiah Carlson <[EMAIL PROTECTED]> wrote: > > > > ... > > If we were to specify anything, I would suggest we define an order of > > annotation calling, which would also define a chaining order if > > applicable. Maybe it is completely obviou

Re: [Python-3000] Draft pre-PEP: function annotations

On 8/13/06, Josiah Carlson <[EMAIL PROTECTED]> wrote: ...If we were to specify anything, I would suggest we define an order ofannotation calling, which would also define a chaining order ifapplicable.  Maybe it is completely obvious, but one should neverunderestimate what kinds of silly things user

Re: [Python-3000] Draft pre-PEP: function annotations

Paul Prescod wrote: >> And the interpetation of: >> >> def cat(infile: [doc("input stream"), opt("i")] = sys.stdin, >> outfile: [doc("output stream"), opt("o")] = sys.stdout >> ): >> >> is likewise unambiguous, unless the creator of the documentation or >> option >> features ha

Re: [Python-3000] Draft pre-PEP: function annotations

On 8/11/06, Collin Winter <[EMAIL PROTECTED]> wrote:... What Josiah is hinting at -- and what Talin describes more explicitly-- is the problem of how exactly "chaining" annotation interpreterswill work.I don't think the question is really how to chain them. The question is how to avoid them steppi

Re: [Python-3000] Draft pre-PEP: function annotations

Sorry to write so many emails, but I want to get in one last point tonight (I'm sure I'll regret posting late at night)Jim's email seems not to have gotten through to the whole list. There's a lot of that going aruond. On 8/12/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote: >Sure there is.  There wil

Re: [Python-3000] Draft pre-PEP: function annotations

"Phillip J. Eby" <[EMAIL PROTECTED]> wrote: > At 09:16 PM 8/12/2006 -0700, Josiah Carlson wrote: > >"Phillip J. Eby" <[EMAIL PROTECTED]> wrote: > > > However, if you have: > > > > > > def myfunc( x : doc("The x coordinate"), y : doc("The y coordinate") ) > > > > > > There is no ambiguity. Lik

Re: [Python-3000] Draft pre-PEP: function annotations

And the interpetation of:def cat(infile: [doc("input stream"), opt("i")] = sys.stdin,outfile: [doc("output stream"), opt("o")] = sys.stdout):is likewise unambiguous, unless the creator of the documentation or optionfeatures has defined some other interpretation for a list than

Re: [Python-3000] Draft pre-PEP: function annotations

On 8/12/06, Calvin Spealman <[EMAIL PROTECTED]> wrote: I've been looking for a good place to pipe in with the suggestion ofdefining that a dictionary as an annotation is taken as a mapping ofannotation type names to the annotation itself, such as using {'doc':"The single character argument for the

Re: [Python-3000] Draft pre-PEP: function annotations

On 8/11/06, Collin Winter <[EMAIL PROTECTED]> wrote: >>> def chain(*decorators):>>> assert len(decorators) >= 2>> def decorate(function):>>> sig = function.__signature__>>> original = sig.annotations>> for i, dec in enumerate(decorators):>>> fake

Re: [Python-3000] Draft pre-PEP: function annotations

On 8/12/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote: I mostly like this; the main issue I see is that as long as we'rerecommending best practices, we should recommend using tell-don't-ask (viaduck typing protocols, adaptation, or overloaded functions) so that their libraries can be enhanced and ex

Re: [Python-3000] Draft pre-PEP: function annotations

On 8/13/06, Paul Prescod <[EMAIL PROTECTED]> wrote: > I made a proposal that Phillip was mostly okay with. What do other > participants in the thread think? Would it move towards resolving this > thread? > > "In order for processors of function annotations to work interoperably, they > must use a c

Re: [Python-3000] Draft pre-PEP: function annotations

At 01:29 AM 8/13/2006 -0400, Jim Jewett wrote: >On 8/13/06, Josiah Carlson <[EMAIL PROTECTED]> wrote: > >>"Phillip J. Eby" <[EMAIL PROTECTED]> wrote: >> > However, if you have: > >> > def myfunc( x : doc("The x coordinate"), y : doc("The y coordinate") ) > >> > There is no ambiguity. > >Sure th

Re: [Python-3000] Draft pre-PEP: function annotations

I made a proposal that Phillip was mostly okay with. What do other participants in the thread think? Would it move towards resolving this thread?"In order for processors of function annotations to work interoperably, they must use a common interpretation of objects used as annotations on a particul

Re: [Python-3000] Draft pre-PEP: function annotations

On 8/13/06, Josiah Carlson <[EMAIL PROTECTED]> wrote: > "Phillip J. Eby" <[EMAIL PROTECTED]> wrote: > > However, if you have: > > def myfunc( x : doc("The x coordinate"), y : doc("The y coordinate") ) > > There is no ambiguity. Sure there is. There will probably be several frameworks using

Re: [Python-3000] Draft pre-PEP: function annotations

At 09:16 PM 8/12/2006 -0700, Josiah Carlson wrote: >"Phillip J. Eby" <[EMAIL PROTECTED]> wrote: > > However, if you have: > > > > def myfunc( x : doc("The x coordinate"), y : doc("The y coordinate") ) > > > > There is no ambiguity. Likewise: > > > > def cat( infile:opt("i") = sys.stdin, ou

Re: [Python-3000] Draft pre-PEP: function annotations

At 09:05 PM 8/12/2006 -0700, Talin wrote: >What we are arguing about is how much the various inspectors/selectors >need to know about each other. And while the answer is hopefully "not >much", I hope that I have shown that it cannot be "nothing at all". As I've previously stated, they need to kn

Re: [Python-3000] Draft pre-PEP: function annotations

"Phillip J. Eby" <[EMAIL PROTECTED]> wrote: > However, if you have: > > def myfunc( x : doc("The x coordinate"), y : doc("The y coordinate") ) > > There is no ambiguity. Likewise: > > def cat( infile:opt("i") = sys.stdin, outfile:opt("o") = sys.stdout ): > > is unambiguous. And the i

Re: [Python-3000] Draft pre-PEP: function annotations

Phillip J. Eby wrote: > At 03:00 PM 8/12/2006 -0700, Talin <[EMAIL PROTECTED]> wrote: >> Phillip J. Eby wrote: >> > At 12:38 PM 8/12/2006 -0700, Paul Prescod wrote: >> >> > However, if you have: >> > >> >def myfunc( x : doc("The x coordinate"), y : doc("The y >> coordinate") ) >> > >> > There

Re: [Python-3000] Draft pre-PEP: function annotations

I am getting very tired of gmail's ingoring of the mailing-list headers in context of replying! Anyway, here is what I accidentally sent as personal messages related to this thread. Replying to Talin's long story about MIDI devices: WOW I won't even pretend to reply with anything near a similar s

Re: [Python-3000] Draft pre-PEP: function annotations

At 03:00 PM 8/12/2006 -0700, Talin <[EMAIL PROTECTED]> wrote: >Phillip J. Eby wrote: > > At 12:38 PM 8/12/2006 -0700, Paul Prescod wrote: > > > However, if you have: > > > >def myfunc( x : doc("The x coordinate"), y : doc("The y coordinate") ) > > > > There is no ambiguity. Likewise: > > > >

Re: [Python-3000] Draft pre-PEP: function annotations

At 05:05 PM 8/12/2006 -0700, Paul Prescod wrote: >It seems to me that there are two very reasonable positions being >expressed. Is the following (non-normative) text a compromise? > >"In order for processors of function annotations to work interoperably, >they must use a common interpretation of

Re: [Python-3000] Draft pre-PEP: function annotations

It seems to me that there are two very reasonable positions being expressed. Is the following (non-normative) text a compromise?"In order for processors of function annotations to work interoperably, they must use a common interpretation of objects used as annotations on a particular function. For

Re: [Python-3000] Draft pre-PEP: function annotations

Phillip J. Eby wrote: > At 12:38 PM 8/12/2006 -0700, Paul Prescod wrote: > However, if you have: > >def myfunc( x : doc("The x coordinate"), y : doc("The y coordinate") ) > > There is no ambiguity. Likewise: > >def cat( infile:opt("i") = sys.stdin, outfile:opt("o") = sys.stdout ): > >

Re: [Python-3000] Draft pre-PEP: function annotations

Paul Prescod wrote: > Phillip. I'm having trouble following the discussion. I briefly caught up > when Talin got very concrete with syntax and I would appreciate if you > could > offer some correspondingly remedial training. > > Talin's example is that metadata inventor A documents that his/her u

Re: [Python-3000] Draft pre-PEP: function annotations

At 12:38 PM 8/12/2006 -0700, Paul Prescod wrote: >Phillip. I'm having trouble following the discussion. I briefly caught up >when Talin got very concrete with syntax and I would appreciate if you >could offer some correspondingly remedial training. > >Talin's example is that metadata inventor A d

Re: [Python-3000] Draft pre-PEP: function annotations

Phillip. I'm having trouble following the discussion. I briefly caught up when Talin got very concrete with syntax and I would appreciate if you could offer some correspondingly remedial training.Talin's example is that metadata inventor A documents that his/her users should use this syntax for par

Re: [Python-3000] Draft pre-PEP: function annotations

At 12:33 AM 8/12/2006 -0400, Collin Winter wrote: >>I don't see the point of this. A decorator should be responsible for >>manipulating the signature of its return value. Meanwhile, the semantics >>for combining annotations should be defined by an overloaded function like >>"combineAnnotations(a1

Re: [Python-3000] Draft pre-PEP: function annotations

At 05:58 PM 8/12/2006 +1000, Nick Coghlan wrote: >Phillip J. Eby wrote: >>At 03:39 PM 8/12/2006 -0700, Talin <[EMAIL PROTECTED]> wrote: >>>So programmer C, who wants to incorporate both A and B's work into his >>>program, has a dilemma - each has a sharing mechanism, but the sharing >>>mechanisms a

Re: [Python-3000] Draft pre-PEP: function annotations

At 09:49 PM 8/11/2006 -0700, Talin wrote: >Phillip J. Eby wrote: >>Not at all. A and B need only use overloadable functions, and the >>problem is trivially resolved by adding overloads. The author of C can >>add an overload to "A" that will handle objects with 'next' attributes, >>or add one t

Re: [Python-3000] Draft pre-PEP: function annotations

Collin Winter wrote: > Return Values > - > > The examples thus far have omitted examples of how to annotate the > type of a function's return value. This is done like so: > > :: > def sum(*vargs: Number) -> Number: > ... > > > The parameter list can now be followed by a

Re: [Python-3000] Draft pre-PEP: function annotations

Phillip J. Eby wrote: > At 03:39 PM 8/12/2006 -0700, Talin <[EMAIL PROTECTED]> wrote: >> So programmer C, who wants to incorporate both A and B's work into his >> program, has a dilemma - each has a sharing mechanism, but the sharing >> mechanisms are different and incompatible. So he is unable to

Re: [Python-3000] Draft pre-PEP: function annotations

Phillip J. Eby wrote: > Not at all. A and B need only use overloadable functions, and the > problem is trivially resolved by adding overloads. The author of C can > add an overload to "A" that will handle objects with 'next' attributes, > or add one to "B" that handles tuples, or both. I'm s

Re: [Python-3000] Draft pre-PEP: function annotations

> I don't see the point of this. A decorator should be responsible for > manipulating the signature of its return value. Meanwhile, the semantics > for combining annotations should be defined by an overloaded function like > "combineAnnotations(a1,a2)" that returns a new annotation. There is no

Re: [Python-3000] Draft pre-PEP: function annotations

At 07:49 PM 8/12/2006 -0400, "Collin Winter" <[EMAIL PROTECTED]> wrote: >What Josiah is hinting at -- and what Talin describes more explicitly >-- is the problem of how exactly "chaining" annotation interpreters >will work. I'd prefer we not use the word "interpreters" to describe operations that

Re: [Python-3000] Draft pre-PEP: function annotations

At 03:39 PM 8/12/2006 -0700, Talin <[EMAIL PROTECTED]> wrote: >Say I want to annotate a specific argument with two pieces of >information, a type and a docstring. I have two metadata interpreters, >one which uses the type information to restrict the kinds of arguments >that can be passed in, and an

Re: [Python-3000] Draft pre-PEP: function annotations

On 8/11/06, Talin <[EMAIL PROTECTED]> wrote: > The story also has to do with people who assume things about the > behavior of other software developers - specifically, my assumption that > other people, working in isolation from one another, would come up with > the same or similar solutions to a g

Re: [Python-3000] Draft pre-PEP: function annotations

Phillip J. Eby wrote: > At 3:16 PM 8/12/2006 -0700, Talin <[EMAIL PROTECTED]> wrote: >> Phillip J. Eby wrote: >> > At 06:10 AM 8/11/2006 -0700, Talin <[EMAIL PROTECTED]> wrote: >> >> Or to put it another way: If you create a tool, and you assume that >> tool >> >> will only be used in certain spec

Re: [Python-3000] Draft pre-PEP: function annotations

At 3:16 PM 8/12/2006 -0700, Talin <[EMAIL PROTECTED]> wrote: >Phillip J. Eby wrote: > > At 06:10 AM 8/11/2006 -0700, Talin <[EMAIL PROTECTED]> wrote: > >> Or to put it another way: If you create a tool, and you assume that tool > >> will only be used in certain specific ways, but you fail to enforc

Re: [Python-3000] Draft pre-PEP: function annotations

I'll combine my replies to Josian and Talin: On 8/11/06, Josiah Carlson <[EMAIL PROTECTED]> wrote: Let us say that I have two metadata interpters. One that believes that the metadata is types and wants to verify type on function call. The other believes that the metadata is documentation. Bot

Re: [Python-3000] Draft pre-PEP: function annotations

Josiah Carlson wrote: > "Phillip J. Eby" <[EMAIL PROTECTED]> wrote: >> At 06:10 AM 8/11/2006 -0700, Talin <[EMAIL PROTECTED]> wrote: >>> Or to put it another way: If you create a tool, and you assume that tool >>> will only be used in certain specific ways, but you fail to enforce that >>> limitati

Re: [Python-3000] Draft pre-PEP: function annotations

Phillip J. Eby wrote: > At 06:10 AM 8/11/2006 -0700, Talin <[EMAIL PROTECTED]> wrote: >> Or to put it another way: If you create a tool, and you assume that tool >> will only be used in certain specific ways, but you fail to enforce that >> limitation, then your assumption will be dead wrong. The i

Re: [Python-3000] Draft pre-PEP: function annotations

At 01:46 PM 8/11/2006 -0700, Josiah Carlson wrote: >"Phillip J. Eby" <[EMAIL PROTECTED]> wrote: > > At 09:04 AM 8/11/2006 -0700, Josiah Carlson wrote: > > >I think you misunderstood Talin. While it was a pain for him to work > > >his way through implementing all of the loading/etc. protocols, I >

Re: [Python-3000] Draft pre-PEP: function annotations

"Phillip J. Eby" <[EMAIL PROTECTED]> wrote: > At 09:04 AM 8/11/2006 -0700, Josiah Carlson wrote: > >I think you misunderstood Talin. While it was a pain for him to work > >his way through implementing all of the loading/etc. protocols, I > >believe his point was that if we allow any and all arbit

Re: [Python-3000] Draft pre-PEP: function annotations

At 09:04 AM 8/11/2006 -0700, Josiah Carlson wrote: >I think you misunderstood Talin. While it was a pain for him to work >his way through implementing all of the loading/etc. protocols, I >believe his point was that if we allow any and all arbitrary metadata to >be placed on arguments to and from

Re: [Python-3000] Draft pre-PEP: function annotations

"Phillip J. Eby" <[EMAIL PROTECTED]> wrote: > > At 06:10 AM 8/11/2006 -0700, Talin <[EMAIL PROTECTED]> wrote: > >Or to put it another way: If you create a tool, and you assume that tool > >will only be used in certain specific ways, but you fail to enforce that > >limitation, then your assumption

Re: [Python-3000] Draft pre-PEP: function annotations

At 06:10 AM 8/11/2006 -0700, Talin <[EMAIL PROTECTED]> wrote: >Or to put it another way: If you create a tool, and you assume that tool >will only be used in certain specific ways, but you fail to enforce that >limitation, then your assumption will be dead wrong. The idea that there >will only be a

Re: [Python-3000] Draft pre-PEP: function annotations

Collin Winter wrote: > The idea is that each developer can pick the notation/semantics that's > most natural to them. I'll go even further: say one library offers a > semantics you find handy for task A, while another library's ideas > about type annotations are best suited for task B. Without a si

Re: [Python-3000] Draft pre-PEP: function annotations

Stefan Behnel wrote: > Collin Winter wrote: >> def compile(source: "something compilable", >> filename: "where the compilable thing comes from", >> mode: "is this a single statement or a suite?"): >> ... >> >> def sum(*vargs: Num

Re: [Python-3000] Draft pre-PEP: function annotations

Hi, Collin Winter wrote: > def compile(source: "something compilable", > filename: "where the compilable thing comes from", > mode: "is this a single statement or a suite?"): > ... > > def sum(*vargs: Number) -> Number: >

Re: [Python-3000] Draft pre-PEP: function annotations

At 14:47 8/10/2006 +1200, Greg Ewing <[EMAIL PROTECTED]> wrote: >And what are you supposed to do if you want to write >a function that has improved help messages *and* >type checking? Create a type annotation object that wraps multiple objects -- or better yet, use a list or tuple of annotations.

Re: [Python-3000] Draft pre-PEP: function annotations

On 8/9/06, Greg Ewing <[EMAIL PROTECTED]> wrote: > Collin Winter wrote: > >one library might use string-based annotations to provide > >improved help messages, like so: > > > > def compile(source: "something compilable", > > filename: "where the compilable thing

Re: [Python-3000] Draft pre-PEP: function annotations

Collin Winter wrote: > On 8/9/06, Talin <[EMAIL PROTECTED]> wrote: > >>Collin Winter wrote: >> >>> 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. >> >>I

Re: [Python-3000] Draft pre-PEP: function annotations

Collin Winter wrote: >one library might use string-based annotations to provide >improved help messages, like so: > > def compile(source: "something compilable", > filename: "where the compilable thing comes from", > mode: "is this a single st

Re: [Python-3000] Draft pre-PEP: function annotations

On 8/9/06, Talin <[EMAIL PROTECTED]> wrote: > Collin Winter wrote: > >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.

Re: [Python-3000] Draft pre-PEP: function annotations

Collin Winter wrote: >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 interpre

[Python-3000] Draft pre-PEP: function annotations

After letting the discussions from the Spring stew in my head for a few months, here's my first draft of the proto-PEP for function annotations. This is intended to lay out in a single document the basic ideas for function annotations, to get community feedback on the fundamentals before proceeding