Assigning __class__ is a precarious stunt (look at the implementation, it
requires lots of checks for various things like __slots__ and
implementation-specific special cases). The gesture that looks like
"overriding a method" is merely setting a new instance attribute that hides
the method, and qui
My intuition differs from Steven's here. But that's fine. In any case, my
simple implementation of RingBuffer in this thread avoids either rebinding
methods or changing .__class__.
And yes, of course collections.deque is better than any of these
implementations. I was just trying to show that a
On Mon, Oct 19, 2015 at 11:41:44AM +1100, Chris Angelico wrote:
> What does this provide that collections.deque(maxlen=size_max)
> doesn't? I'm a little lost.
The Ringbuffer recipe predates deque by quite a few years. These days I
would consider it only useful in a pedagogical context, giving a
On Sun, Oct 18, 2015 at 05:35:14PM -0700, David Mertz wrote:
> In any case, redefining a method in a certain situation feels a lot less
> magic to me than redefining .__class__
That surprises me greatly. As published in the Python Cookbook[1], there
is a one-to-one correspondence between the met
On 18 October 2015 at 17:41, Chris Angelico wrote:
> On Mon, Oct 19, 2015 at 11:35 AM, David Mertz wrote:
> > That's interesting about the `self._full` variable slowing it down, I
> think
> > I'm not surprised (but obviously it depends on just how it's used). But
> one
> > can also simply defin
On Mon, Oct 19, 2015 at 11:35 AM, David Mertz wrote:
> That's interesting about the `self._full` variable slowing it down, I think
> I'm not surprised (but obviously it depends on just how it's used). But one
> can also simply define RingBuffer.isfull() using `self.max==len(self.data)`
> if you p
I'm not sure what benchmark you used to define the speed of RingBuffer.
I'm sure you are reporting numbers accurately for your tests, but there are
"lies, damn lies, and benchmarks", so "how fast" has a lot of nuance to it.
In any case, redefining a method in a certain situation feels a lot less
m
I re-coded the "too clever by half" RingBuffer to use the same design but
with delegation ... and it ran 50% slower. (Code available on request)
Then I changed it to switch implementations of append() and get() when it
got full (the code is below) and it ran at essentially the same speed as
the ori
This recipe looks like a bad design to me to start with. It's
too-clever-by-half, IMO.
If I were to implement RingBuffer, I wouldn't futz around with the
__class__ attribute to change it into another thing when it was full. A
much more obvious API for users would be simply to implement a
RingBuf
On 18 October 2015 at 05:55, Steven D'Aprano wrote:
> On Sat, Oct 17, 2015 at 03:45:19PM -0600, Eric Snow wrote:
>> So, would it make sense to establish some concrete guidelines about
>> when to use type(obj) vs. obj.__class__? If so, what would those be?
>> It may also be helpful to enumerate us
It's mostly a historical accident -- for classic classes, type(inst) was
always `instance' while inst.__class__ was the user-defined class object.
For new-style classes, the idea is that you can write a proxy class that
successfully masquerades as another class. Because __class__ is an
attribute,
11 matches
Mail list logo