I do not buy into any concept about something being pythonic or not.
Python has grown too vast and innovated quite a bit, but also borrowed from
others and vice versa.
There generally is no universally pythonic way nor should there be. Is there
language with a philosophy of what is the pythonic way?
My vague impression was that the pythonic way was somewhat of a contrast to
the way a programmer did it before coming to python. So some would argue
that although python allows loops, that some things are more naturally done
in python using a list comprehension.
I suggest that NOW for some people, it is way more natural to import modules
like numpy and pandas and use their tools using a more vectorized approach.
Is that the new pythonic in some situations?
I can also argue that if you were a contestant on Jeopardy and were in a
category for computer languages and were shown some computer code and asked
to name that language in 4 lines, then the most pythonic would not be one
saying type(var) but the one showing a dunder method! I mean what makes some
languages special is often the underlying details! On the surface, many look
Some problems not only can be solved many ways in python, but by using
combinations of different programming paradigms. It can be argued by some
that the pythonic way is to use some forms of object-oriented programming
and by others pushing for a more functional approach. Some seem to continue
pushing for efficiency and others relish at using up CPU cycles and prefer
other considerations such as what is easier for the programmer or that is
My answer remains, in this case, like yours. The dunder methods are
generally meant to be implementation details mostly visible when creating
new classes or perhaps adjusting an object. They largely implement otherwise
invisible protocols by providing the hooks the protocols invoke, and do it
in a somewhat reserved name space. If the user is writing code that just
uses existing classes, generally no dunderheads should be seen. I think
using them is not only not pythonic, but risks breaking code if some changes
to python are made. As one example, the iteration protocol now has new
dunder methods added to be used for asynchronous and calling the __iter__()
type methods will not work well and you now need to know to call the new
ones. Or, don't call them at all and use the regular functions provided.
Some things may be clearly more in the spirit of the language and sometimes
who cares. Consider the debate that since python allows you to fail and
catch an exception, why bother using if statements such as checking for
no-zero before dividing. I never understood that. Plan A works. Now you can
also chose plan B. They both work. But has anyone asked some dumb questions
about the data the code is working on? What if you have data full of zeroes
or NA or Inf or other things make a division problematic. What is the cost
of testing for something or a group of things every time versus setting up a
try/catch every time? What about lots of nesting of these things. What can
humans read better or make adjustments to?
In my mind, if the bad thing you want to avoid is rare and the testing is
costly, perhaps the exception method is best. I mean if you are working with
large numbers where primes are not common, then having to test if it is a
prime can be costly while catching a failure may be less so.
But consider how some people act as if pythonic means you should not care
about efficiency! LOL!
I leave you with the question of the day. Was Voldemort pythonic?
From: Python-list <email@example.com> On
Behalf Of Alan Gauld
Sent: Friday, March 3, 2023 4:43 AM
Subject: Re: Which more Pythonic - self.__class__ or type(self)?
On 02/03/2023 20:54, Ian Pilcher wrote: > Seems like an FAQ, and I've found a few things on StackOverflow that
> discuss the technical differences in edge cases, but I haven't found
> anything that talks about which form is considered to be more Pythonic
> in those situations where there's no functional difference.
I think avoiding dunder methods is generally considered more Pythonic.
But in this specific case using isinstance() is almost always
the better option. Testing for a specific class is likely to break
down in the face of subclasses. And in Python testing for static types
should rarely be necessary since Python uses duck typing
and limiting things to a hard type seriously restricts your code.
Author of the Learn to Program web site http://www.alan-g.me.uk/ http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at: http://www.flickr.com/photos/alangauldphotos