Re: [Python-Dev] type(obj) vs. obj.__class__

On 20 October 2015 at 10:21, Serhiy Storchaka wrote: > On 18.10.15 00:45, 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

Re: [Python-Dev] type(obj) vs. obj.__class__

On 18.10.15 00:45, 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 use cases for "type(obj) is not obj.__class__". My conclusion of this discussion. In

Re: [Python-Dev] type(obj) vs. obj.__class__

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

Re: [Python-Dev] type(obj) vs. obj.__class__

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

Re: [Python-Dev] type(obj) vs. obj.__class__

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

Re: [Python-Dev] type(obj) vs. obj.__class__

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

Re: [Python-Dev] type(obj) vs. obj.__class__

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

Re: [Python-Dev] type(obj) vs. obj.__class__

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

Re: [Python-Dev] type(obj) vs. obj.__class__

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

Re: [Python-Dev] type(obj) vs. obj.__class__

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).

Re: [Python-Dev] type(obj) vs. obj.__class__

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

Re: [Python-Dev] type(obj) vs. obj.__class__

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,

Re: [Python-Dev] type(obj) vs. obj.__class__

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

Re: [Python-Dev] type(obj) vs. obj.__class__

On 18.10.15 00:45, Eric Snow wrote: In a recent tracker issue about OrderedDict [1] we've had some discussion about the use of type(od) as a replacement for od.__class__. It came up because the pure Python implementation of OrderedDict uses self.__class__ in 3 different methods (__repr__,

Re: [Python-Dev] type(obj) vs. obj.__class__

On Sat, Oct 17, 2015 at 03:45:19PM -0600, Eric Snow wrote: > In a recent tracker issue about OrderedDict [1] we've had some > discussion about the use of type(od) as a replacement for > od.__class__. [...] > The more general question of when we use type(obj) vs. obj.__class__ > applies to both

[Python-Dev] type(obj) vs. obj.__class__

In a recent tracker issue about OrderedDict [1] we've had some discussion about the use of type(od) as a replacement for od.__class__. It came up because the pure Python implementation of OrderedDict uses self.__class__ in 3 different methods (__repr__, __reduce__, and copy). The patch in that