Alan,
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 a C way and then a C++ way and an R way or JavaScript or does only python a 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. Really? 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 fairly similar. 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 more self-documenting. 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? Avi -----Original Message----- From: Python-list <python-list-bounces+avi.e.gross=gmail....@python.org> On Behalf Of Alan Gauld Sent: Friday, March 3, 2023 4:43 AM To: python-list@python.org 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. -- Alan G 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 -- https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
