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 RingBuffer.isfull() method, perhaps supported by an underlying RingBuffer._full boolean attribute. That's much friendlier than expecting people to introspect the type of the thing for a question that only occasionally matters; and when it does matter, the question is always conceived exactly as "Is it full?" not "What class is this currently?"So I think I'm still waiting for a compelling example where type(x) != x.__class__ would be worthwhile (yes, of course it's *possible*)On Sat, Oct 17, 2015 at 10:55 PM, Steven D'Aprano <steve@pearwood.info> wrote: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 the language and to all the stdlib as I expect
> consistency there would result in fewer surprises. I realize that
> there are some places where using obj.__class__ makes more sense (e.g.
> for some proxy support). There are other places where using type(obj)
> is the way to go (e.g. special method lookup). However, the
> difference is muddled enough that usage is inconsistent in the stdlib.
> For example, C-implemented types use Py_TYPE() almost exclusively.
>
> 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__".
I for one would like to see a definitive explanation for when they are
different, and when you should use one or the other. The only
obvious example I've seen is the RingBuffer from the Python Cookbook:
http://code.activestate.com/recipes/68429-ring-buffer/
--
Steve
Unsubscribe: https://mail.python.org/mailman/options/python-dev/mertz%40gnosis.cx_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
--Keeping medicines from the bloodstreams of the sick; food
from the bellies of the hungry; books from the hands of the
uneducated; technology from the underdeveloped; and putting
advocates of freedom in prisons. Intellectual property is
to the 21st century what the slave trade was to the 16th.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: https://mail.python.org/mailman/options/python-dev/pludemann%40google.com