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, 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] Conventions for annotation consumers (was: Re: Draft pre-PEP: function annotations)

On 8/14/06, Collin Winter <[EMAIL PROTECTED]> wrote: > On 8/14/06, Jim Jewett <[EMAIL PROTECTED]> wrote: > > On 8/14/06, Collin Winter <[EMAIL PROTECTED]> wrote: > > > The problem with using lists is that its impossible for non-decorator > > > annotation consumers to know which element "belongs" to

Re: [Python-3000] Conventions for annotation consumers (was: Re: Draft pre-PEP: function annotations)

On 8/15/06, Collin Winter <[EMAIL PROTECTED]> wrote: > Here's the modified example > > @docstring > @typechecker > @constrain_values > def foo(a: {'doc': "Frobnication count", >'type': Number, >'constrain_values': range(3, 9)}, >b: {'type': Number, > # Th

Re: [Python-3000] Conventions for annotation consumers (was: Re: Draft pre-PEP: function annotations)

I totally do not understand the requirement for the dictionary and its extra overhead.On 8/15/06, Collin Winter < [EMAIL PROTECTED]> wrote:@typecheckerdef foo(a: {'type': Number},   b: {'type': Number}) -> {'type': Number} I'm going to raise the bar for future ideas on this subject: anyproposal

Re: [Python-3000] Conventions for annotation consumers (was: Re: Draft pre-PEP: function annotations)

On 8/15/06, Paul Prescod <[EMAIL PROTECTED]> wrote: > I totally do not understand the requirement for the dictionary and its extra > overhead. Under your proposal, annotation consumer libraries have to provide wrappers for Python's built-in types, since the only way a library has of knowing whethe

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

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] Conventions for annotation consumers (was: Re: Draft pre-PEP: function annotations)

On 8/15/06, Collin Winter <[EMAIL PROTECTED]> wrote: On 8/15/06, Paul Prescod <[EMAIL PROTECTED]> wrote:> I totally do not understand the requirement for the dictionary and its extra> overhead.Under your proposal, annotation consumer libraries have to provide wrappers for Python's built-in types, s

Re: [Python-3000] Conventions for annotation consumers (was: Re: Draft pre-PEP: function annotations)

On 8/15/06, Paul Prescod <[EMAIL PROTECTED]> wrote: > On 8/15/06, Collin Winter <[EMAIL PROTECTED]> wrote: > > Extending this same idea to static analysis tools, tools like > > pychecker or an optimising compiler would have to supply their own > > such wrapper classes. This would be a huge burden,

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] Conventions for annotation consumers (was: Re: Draft pre-PEP: function annotations)

On 8/15/06, Collin Winter <[EMAIL PROTECTED]> wrote: If multiple libraries use the same wrappers, then I can't use morethan one of these libraries at the same time. If a typecheckingconsumer, a docstring consumer and PyPy all use the same wrapper (or"syntax" -- you switch terms between sentences),

Re: [Python-3000] Conventions for annotation consumers (was: Re: Draft pre-PEP: function annotations)

On 8/15/06, Paul Prescod <[EMAIL PROTECTED]> wrote: > A Typechecking consumer and a PyPy compiler consumer might work on the same > annotations because they are both interested in TYPES (but doing different > things with them). These type consumers might also choose to implement more > than one typ

Re: [Python-3000] Conventions for annotation consumers (was: Re: Draft pre-PEP: function annotations)

On 8/15/06, Collin Winter <[EMAIL PROTECTED]> wrote: So basically what you're saying is that there would be a more-or-lessstandard wrapper for each application of function annotations. No, I explicitly said that there may or may not arise standards based upon the existence or non-existence of commu

Re: [Python-3000] Conventions for annotation consumers (was: Re: Draft pre-PEP: function annotations)

On 8/15/06, Paul Prescod <[EMAIL PROTECTED]> wrote: > On 8/15/06, Collin Winter <[EMAIL PROTECTED]> wrote: > > How is > > this significantly better than my dict-based approach, which uses > > standardised dict keys to indicate the kind of metadata? > > The dict-based approach introduces an extra na

[Python-3000] Fwd: Conventions for annotation consumers (was: Re: Draft pre-PEP: function annotations)

On 8/15/06, Collin Winter <[EMAIL PROTECTED]> wrote: > On 8/15/06, Paul Prescod <[EMAIL PROTECTED]> wrote: > > On 8/15/06, Collin Winter <[EMAIL PROTECTED]> wrote: > > > How is > > > this significantly better than my dict-based approach, which uses > > > standardised dict keys to indicate the kind

Re: [Python-3000] Fwd: Conventions for annotation consumers (was: Re: Draft pre-PEP: function annotations)

On 8/15/06, Calvin Spealman <[EMAIL PROTECTED]> wrote: > On 8/15/06, Collin Winter <[EMAIL PROTECTED]> wrote: >> 1) Static analysis tools (pychecker, optimising compilers, etc) must >> be able to use the annotations > > As in any example given so far, the annotations would be instansiated > within

Re: [Python-3000] Conventions for annotation consumers (was: Re: Draft pre-PEP: function annotations)

On 8/15/06, Collin Winter <[EMAIL PROTECTED]> wrote: > Here's another stab at my earlier idea: ... > We're still using dicts to hold the annotations, but instead of having > the dict keyed on the name (function.__name__) of the annotation > consumer, the keys are arbitrary (for certain values of

Re: [Python-3000] Conventions for annotation consumers (was: Re: Draft pre-PEP: function annotations)

On 8/15/06, Collin Winter <[EMAIL PROTECTED]> wrote: > ... that users won't be using multiple type systems on the same parameter > (and if they are, that their own problem); for "doc" is that a > docstring is just a Python string, and there's really only own way to > look at that within the scope o

Re: [Python-3000] Fwd: Conventions for annotation consumers (was: Re: Draft pre-PEP: function annotations)

Collin Winter wrote: > On 8/15/06, Calvin Spealman <[EMAIL PROTECTED]> wrote: >> On 8/15/06, Collin Winter <[EMAIL PROTECTED]> wrote: >>> 1) Static analysis tools (pychecker, optimising compilers, etc) must >>> be able to use the annotations >> As in any example given so far, the annotations would

Re: [Python-3000] Fwd: Conventions for annotation consumers

At 05:29 PM 8/16/2006 -0500, "Collin Winter" <[EMAIL PROTECTED]> wrote: >On 8/15/06, Calvin Spealman <[EMAIL PROTECTED]> wrote: > > On 8/15/06, Collin Winter <[EMAIL PROTECTED]> wrote: > >> 1) Static analysis tools (pychecker, optimising compilers, etc) must > >> be able to use the annotations > >

Re: [Python-3000] threading, part 2

On 8/11/06, tomer filiba <[EMAIL PROTECTED]> wrote: > [Guido] > > I expect that Jython doesn't implement this; it doesn't handle ^C either > > AFAIK. > > threads are at most platform agnostic (old unices, embedded systems, etc. > are not likely to have thread support) I'm not sure what "platform

Re: [Python-3000] threading, part 2

On 8/11/06, Jason Orendorff <[EMAIL PROTECTED]> wrote: > On 8/11/06, tomer filiba <[EMAIL PROTECTED]> wrote: > > why is thread.raise_exc(id, excobj) a bad API? > > It breaks seemingly innocent code in subtle ways. Worse, the breakage > will always be a race condition, so it'll be especially hard t

Re: [Python-3000] threading, part 2

On 8/11/06, Jason Orendorff <[EMAIL PROTECTED]> wrote: > On 8/11/06, Josiah Carlson <[EMAIL PROTECTED]> wrote: > > Slawomir Nowaczyk <[EMAIL PROTECTED]> wrote: > > > But it should not be done lightly and never when the code is not > > > specifically expecting it. > > > > If you don't want random ex

Re: [Python-3000] threading, part 2

On 8/11/06, Marcin 'Qrczak' Kowalczyk <[EMAIL PROTECTED]> wrote: > I do want asynchronous exceptions, but not anywhere, only in selected > regions (or excluding selected regions). This can be designed well. Please write a proto-PEP. -- --Guido van Rossum (home page: http://www.python.org/~guido/

Re: [Python-3000] threading, part 2

On 8/14/06, Georg Brandl <[EMAIL PROTECTED]> wrote: > Guido van Rossum wrote: > > On 8/11/06, tomer filiba <[EMAIL PROTECTED]> wrote: > >> i mailed this to several people separately, but then i thought it could > >> benefit the entire group: > >> > >> http://sebulba.wikispaces.com/recipe+thread2 >

[Python-3000] Function annotations considered obfuscatory (Re: Conventions for annotation consumers)

Collin Winter wrote: > @docstring > @typechecker > @constrain_values > def foo(a: {'doc': "Frobnication count", >'type': Number, >'constrain_values': range(3, 9)}, >b: {'type': Number, > # This can be only 4, 8 or 12 >'constrain_values': [4,

Re: [Python-3000] Fwd: Conventions for annotation consumers (was: Re: Draft pre-PEP: function annotations)

On 8/15/06, Collin Winter <[EMAIL PROTECTED]> wrote: > On 8/15/06, Calvin Spealman <[EMAIL PROTECTED]> wrote: > > On 8/15/06, Collin Winter <[EMAIL PROTECTED]> wrote: > >> 1) Static analysis tools (pychecker, optimising compilers, etc) must > >> be able to use the annotations > > > > As in any exam

Re: [Python-3000] Conventions for annotation consumers

Paul Prescod wrote: > What if > two different groups start fighting over the keyword "type" or "doc" or > "lock"? Python already has a module system that allows you to use the > word "type" and me to use the word "type" without conflict But, in general, performing this disambiguation requires e

Re: [Python-3000] Conventions for annotation consumers

On 8/15/06, Greg Ewing <[EMAIL PROTECTED]> wrote: > Paul Prescod wrote: > > What if > > two different groups start fighting over the keyword "type" or "doc" or > > "lock"? Python already has a module system that allows you to use the > > word "type" and me to use the word "type" without conflict >

Re: [Python-3000] Function annotations considered obfuscatory (Re: Conventions for annotation consumers)

On 8/15/06, Greg Ewing <[EMAIL PROTECTED]> wrote: > Collin Winter wrote: > > > @docstring > > @typechecker > > @constrain_values > > def foo(a: {'doc': "Frobnication count", > >'type': Number, > >'constrain_values': range(3, 9)}, > >b: {'type': Number, > >

Re: [Python-3000] Bound and unbound methods

On 8/13/06, Greg Ewing <[EMAIL PROTECTED]> wrote: > Talin wrote: > > the compiler would note the combination of the attribute access and the > > call, and combine them into an opcode that skips the whole method > > creation step. > > Something like that could probably be made to work. You'd > want

Re: [Python-3000] Fwd: Conventions for annotation consumers (was: Re: Draft pre-PEP: function annotations)

On 8/15/06, Collin Winter <[EMAIL PROTECTED]> wrote: How exactly do they "deduce" what Bar is, just from the "from barimport Bar" line? pychecker would have to import and compile the Barmodule first. What if being able to import bar depends on some import hooks that some other module (imported befo

Re: [Python-3000] Conventions for annotation consumers

On 8/15/06, Greg Ewing <[EMAIL PROTECTED]> wrote: Paul Prescod wrote:> What if> two different groups start fighting over the keyword "type" or "doc" or> "lock"? Python already has a module system that allows you to use the > word "type" and me to use the word "type" without conflictBut, in general,

Re: [Python-3000] Bound and unbound methods

On 8/16/06, Guido van Rossum <[EMAIL PROTECTED]> wrote: > On 8/13/06, Greg Ewing <[EMAIL PROTECTED]> wrote: > > Talin wrote: > > > the compiler would note the combination of the attribute access and the > > > call, and combine them into an opcode that skips the whole method > > > creation step. > >