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
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
"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
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
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
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
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
"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
Guido van Rossum wrote:
> On 8/9/06, Talin <[EMAIL PROTECTED]> wrote:
> For the majority of Python developers it's probably the other way
> around. It's been 15 years since I wrote C++, and unlike C, that
> language has changed a lot since then...
>
> It would be a complete rewrite; I prefer doing
One of the items in PEP 3100 is getting rid of unbound methods. I want
to explore a heretical notion, which is getting rid of bound methods as
well.
Now, to be honest, I rather like bound methods. I like being able to
capture a method call, store it in a variable, and call it later.
However, I
Talin wrote:
> Guido van Rossum wrote:
>> On 8/9/06, Talin <[EMAIL PROTECTED]> wrote:
>> For the majority of Python developers it's probably the other way
>> around. It's been 15 years since I wrote C++, and unlike C, that
>> language has changed a lot since then...
>>
>> It would be a complete re
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
On 8/13/06, Talin <[EMAIL PROTECTED]> wrote:
> One of the items in PEP 3100 is getting rid of unbound methods. I want
> to explore a heretical notion, which is getting rid of bound methods as
> well.
I believe you're suggesting that the code that I just wrote moments
ago would stop working::
Talin <[EMAIL PROTECTED]> wrote:
>
> One of the items in PEP 3100 is getting rid of unbound methods. I want
> to explore a heretical notion, which is getting rid of bound methods as
> well.
>
> Now, to be honest, I rather like bound methods. I like being able to
> capture a method call, store
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
Josiah Carlson wrote:
> Talin <[EMAIL PROTECTED]> wrote:
>> One of the items in PEP 3100 is getting rid of unbound methods. I want
>> to explore a heretical notion, which is getting rid of bound methods as
>> well.
>>
>> Now, to be honest, I rather like bound methods. I like being able to
>> cap
On 8/13/06, Talin <[EMAIL PROTECTED]> wrote:
HI wonder if it could be me made to work in abackwards-compatible way. In other words, suppose the existing logic ofcreating a method object were left in place, however the'obj.instancemethod()' pattern would bypass all of that. In other words,
t
> However, I also realize that requiring every access to a class variable
> to instantiate a new method object is expensive, to say the least.
Why does every access to a class variable have to instantiate a new method
object?
___
Python-3000 mailing li
[Josiah]
> I'm -1 for instantiating all methods (for the infinite cost reasons),
> and -1 for int, long, list, tuple, dict, float (method access is
> generally limited for these objects). I'm +0 for offering a suitable
> metaclass and/or decorator, but believe it would be better suited for
> the P
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
Talin wrote:
> Anyway, I just wanted to throw that out there. Feel free to -1 away... :)
Based on the later discussion, I see two interesting possibilities:
1. A special CALL_METHOD opcode that the compiler emits when it spots the
".NAME(ARGS)" pattern. This could simply be an optimisation perfo
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 to be careful to do the optimisation only when the
attribute
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
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
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
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
26 matches
Mail list logo
