[Originally misposted to python-dev]
Nick Coghlan gmail.com> writes:
> There are three big use cases:
>dict.keys
>dict.values
>dict.items
> Currently these all return lists, which may be expensive in terms of copying.
> They all have iter* variants which while memory efficient, are far
On 3/31/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Alex Martelli wrote:
>
> > If the framework consuming X requested adaptation-to-X on all objects
> > it's passed,
>
> This is the part that bothers me, I think. It
> seems like all these adaptation requests would
> be a huge burden on the framewo
Taro Ogawa wrote:
> [Originally misposted to python-dev]
> Nick Coghlan gmail.com> writes:
>> There are three big use cases:
>>dict.keys
>>dict.values
>>dict.items
>> Currently these all return lists, which may be expensive in terms of copying.
>> They all have iter* variants which whi
Alex Martelli wrote:
> If the framework consuming X requested adaptation-to-X on all objects
> it's passed,
That's not generally the way Zope 3 does it (and doesn't sound like a
good idea to me).
There are three ways (as I see it) adaptation is used in Z3. First, the
traditional idea of an "ad
Benji York wrote:
> Alex Martelli wrote:
>
>>If the framework consuming X requested adaptation-to-X on all objects
>>it's passed,
>
>
> That's not generally the way Zope 3 does it (and doesn't sound like a
> good idea to me).
>
> There are three ways (as I see it) adaptation is used in Z3. Fi
On 3/30/06, Alex Martelli <[EMAIL PROTECTED]> wrote:
> Consider __index__, and a user of gmpy, assuming
> gmpy didn't rush out a 2.5 release with tp_index support.
> The user of gmpy would be stuck -- no way he could
> use a gmpy.mpz as an index into a list, because
> the ad-hoc-adaptation of __ind
Paul Moore wrote:
> The "traditional" solution, __index__, requires co-operation
> from all classes that want to support the new protocol. Adaptation
> doesn't - it can be added externally.
I don't follow that. Adaptation only works if the
framework author has thought to make an adaptation
call a
Benji York wrote:
> If I, as the user of the interface, have something I want to
> pass in that doesn't match I it to the appropriate interface the burden
> is on me to create something that matches expectations. People do that
> all the time today without an interface/adaption framework, they
On Thu, 2006-03-30 at 21:56 -0800, Guido van Rossum wrote:
> > Adam DePrince wrote:
> > > No reason we can't make other string operations views as well ...
> > > concatenation is one example. If I recall, that's how snobol handles
> > > strings, view upon view upon view.
>
> But that's irrelevant
On Fri, 2006-03-31 at 14:34 +1200, Greg Ewing wrote:
> Adam DePrince wrote:
> > Views
> > are not generated, they are either directly implemented, or returned.
>
> If you're thinking that the object would keep a set of
> pre-allocated views, there's a problem with that --
> the views need to have
On Thu, 2006-03-30 at 23:37 -0800, Neal Norwitz wrote:
> On 3/30/06, Terry Reedy <[EMAIL PROTECTED]> wrote:
> >
> > "Aahz" <[EMAIL PROTECTED]> wrote in message
> > news:[EMAIL PROTECTED]
> > > What do we want to tell people who have code like this:
> > >
> > > keys = d.keys()
> > > keys.sort()
> >
On Fri, 2006-03-31 at 07:44 +1000, Nick Coghlan wrote:
> Adam DePrince wrote:
> > There seemed to be a concensus in the community on the size of the view
> > proposal, and I'm reimplementing the PEP to reflect that. But what I
> > can't resolve is the other anciliary issue: "To list or iter." I'm
Adam DePrince wrote:
> On Thu, 2006-03-30 at 23:37 -0800, Neal Norwitz wrote:
>> On 3/30/06, Terry Reedy <[EMAIL PROTECTED]> wrote:
>>> "Aahz" <[EMAIL PROTECTED]> wrote in message
>>> news:[EMAIL PROTECTED]
What do we want to tell people who have code like this:
keys = d.keys()
On Mar 31, 2006, at 3:47 PM, Jim Jewett wrote:
> On 3/30/06, Alex Martelli <[EMAIL PROTECTED]> wrote:
>> Consider __index__, and a user of gmpy, assuming
>> gmpy didn't rush out a 2.5 release with tp_index support.
>> The user of gmpy would be stuck -- no way he could
>> use a gmpy.mpz as an inde
On 3/31/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Not a good idea, since the long history of "list.sort()" encourages people to
> think of the sort() method as an inplace operation, which it wouldn't be on a
> view.
Right. This is degenerating quickly. :-(
> "sorted()", on the other hand, alr
Alex Martelli wrote:
> Rather, look (e.g.) at copy_reg for the typical
> kludge that's used to reimplement that crucial design pattern that is
> adaptation, over and over and over again.
I don't see what copy_reg has to do with adaptation.
What does it adapt, and to what?
You seem to be talki
On Mar 31, 2006, at 10:37 PM, Greg Ewing wrote:
> Alex Martelli wrote:
>> Rather, look (e.g.) at copy_reg for the typical
>> kludge that's used to reimplement that crucial design pattern
>> that is
>> adaptation, over and over and over again.
>
> I don't see what copy_reg has to do with adapt
17 matches
Mail list logo
