On 8/15/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> But, in general, performing this disambiguation requires
> executing the module that is making the annotations. For
> a processor that only wants to deal with the source, this
> is undesirable.
Um, when did we start off in the direction of source
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,
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
>
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
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
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
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
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
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
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),
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,
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
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
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
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
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
On 8/14/06, Collin Winter <[EMAIL PROTECTED]> wrote:
What would the rule be about top-level types? Would you have to use alist, or could a set or dict be used?I argue to restrict to a list for the following reasons:1. Better to just pick something for visual consistency (someone said they liked tup
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 them.
>
> The ones whose type they own -- which is why I see
On 8/14/06, Collin Winter <[EMAIL PROTECTED]> wrote:
> On 8/14/06, Paul Prescod <[EMAIL PROTECTED]> wrote:
> The problem with using lists is that its impossible for non-decorator
> annotation consumers to know which element "belongs" to them.
The ones whose type they own -- which is why I see at
On 8/14/06, Paul Prescod <[EMAIL PROTECTED]> wrote:
> Third, we absolutely need a standard for
> multiple independent annotations on a parameter. Using lists is a
> no-brainer. So let's do that.
The problem with using lists is that its impossible for non-decorator
annotation consumers to know whic
20 matches
Mail list logo
