Carl Banks wrote:
> Because the concerns of thousands of legitimate programmers who want
> good performance out of their sorts outweigh the concerns of the one or
> two hax0r d00ds who think it would be cool to hook into sort internals.
... and haven't yet realized that using sorted() and convert
OKB (not okblacke) wrote:
> Carsten Haese wrote:
>
> > You can change the behavior of a list's sort method by overriding
> > sort. You can't change the behavior of sort by overriding
> > __getitem__ and __setitem__, because sort does not call __getitem__
> > or __setitem__.
>
> Why doesn't it
Michalis Giannakidis wrote:
> I perfectly understand that this adds significant penalty to the execution of
> code. But in the way things are, I have to know ( or guess ?) how its
> function has been implemented.
and that's different from how object orientation usually works in
exactly what wa
On Tuesday 28 November 2006 06:12, OKB (not okblacke) wrote:
> Carsten Haese wrote:
> > You can change the behavior of a list's sort method by overriding
> > sort. You can't change the behavior of sort by overriding
> > __getitem__ and __setitem__, because sort does not call __getitem__
> > or __se
OKB (not okblacke) wrote:
> Why doesn't it?
because whoever wrote the class didn't do things that way, mostly for
efficiency reasons. there's nothing in Python that keeps you from using
template methods if you want, but that's a costly approach, so it's not
very common.
I suggest reading up
Carsten Haese wrote:
> You can change the behavior of a list's sort method by overriding
> sort. You can't change the behavior of sort by overriding
> __getitem__ and __setitem__, because sort does not call __getitem__
> or __setitem__.
Why doesn't it?
--
--OKB (not okblacke)
Brendan B
On Mon, 2006-11-27 at 19:14 +, OKB (not okblacke) wrote:
> Duncan Booth wrote:
>
> >> And is there a mechanism in Python that will allow me to override
> >> the operators of a class, for all its occurrences, even the ones
> >> implemented on C built-in objects?
> >
> > No.
>
> For wha
Duncan Booth wrote:
>> And is there a mechanism in Python that will allow me to override
>> the operators of a class, for all its occurrences, even the ones
>> implemented on C built-in objects?
>
> No.
For what it's worth, which is undoubtedly nothing, this is
something that I think n
Fredrik Lundh wrote:
> Michalis Giannakidis wrote:
>
> > Could someone please explain the reasoning/behabiour of these?
>
> in general, methods on C objects are implemented in terms of operations
> on the internal data structures, not in terms of a subset of the methods
> already provided by the ob
Michalis Giannakidis wrote:
>> "obj[index] = value" maps to "obj.__setitem__(index, value)". reading
>> the documentation might help; start here:
>>
>> http://docs.python.org/ref/specialnames.html
>
> In this documentation page it also says:
> --snip---
> then x[i] is equivalent3.2 to x.__g
Michalis Giannakidis <[EMAIL PROTECTED]> wrote:
> On Monday 27 November 2006 11:50, Fredrik Lundh wrote:
>
>> "obj[index] = value" maps to "obj.__setitem__(index, value)".
>> reading the documentation might help; start here:
>>
>> http://docs.python.org/ref/specialnames.html
>
> In this do
On Monday 27 November 2006 11:50, Fredrik Lundh wrote:
> "obj[index] = value" maps to "obj.__setitem__(index, value)". reading
> the documentation might help; start here:
>
> http://docs.python.org/ref/specialnames.html
In this documentation page it also says:
--snip---
then x[i] is equival
Michalis Giannakidis wrote:
>> in general, methods on C objects are implemented in terms of operations
>> on the internal data structures, not in terms of a subset of the methods
>> already provided by the object.
>
> But what is the reason that the assignment
> l[2] = 6
> call my function, but
> in general, methods on C objects are implemented in terms of operations
> on the internal data structures, not in terms of a subset of the methods
> already provided by the object.
But what is the reason that the assignment
l[2] = 6
call my function, but
l.append(3)
doesn't ?
Also, why can'
Michalis Giannakidis wrote:
> Could someone please explain the reasoning/behabiour of these?
in general, methods on C objects are implemented in terms of operations
on the internal data structures, not in terms of a subset of the methods
already provided by the object.
--
http://mail.python
Dear all
I tried to override methods of build in Python types, so as to change their
behavior.
I tried to override list.__getitem__ list.__setitem__ and some others alike
The test case is:
#!/usr/bin/env python
class L(list):
def __getitem__(self, i):
print 'G', i
16 matches
Mail list logo
