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
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
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
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
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
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
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
[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
> 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
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
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
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
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
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::
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
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
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
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
"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
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 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/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
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
"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
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
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
26 matches
Mail list logo
