Live data from Hacker News

Metaprogramming in Python

developer.ibm.com

21–30 of 61 posts

Re: Metaprogramming in Python

#21

It is shocking how much vodoo magic there is in a programming language marketed as "easy to learn and use". And with the recent addition of new syntax, I would hardly call Python easy.

Ran into this face-first, just yesterday. I'm converting a rather old, rather big API (~400 endpoints) from Python 2.7 into 3, and apparently in Python 2, _hasattr(something, someattribute)_ just returns False if attribute access throws an exception! Specifically, if you have

  class A():
    @property
    def a(self): 
      raise Exception('go away')

  a = A()
 
then hasattr(a, 'a') will return False in Python 2.7 (and throw as expected in Python3)

A true WTF moment, the tests and the API have been slightly broken for years, without anyone noticing.

Re: Metaprogramming in Python

#22
This oft-repeated quote is always relevant on Python metaclass posts:

“[Metaclasses] are deeper magic than 99% of users should ever worry about. If you wonder whether you need them, you don’t (the people who actually need them know with certainty that they need them, and don’t need an explanation about why).”

Tim Peters, Inventor of the timsort algorithm and prolific Python contributor

https://www.oreilly.com/library/view/fluent-python/978149194...

https://en.m.wikipedia.org/wiki/Tim_Peters_(software_enginee...

I would then also concur with the other comment that if you “know” you need metaclasses, 99% of the time actually you only need __subclass_init__.

A lot of online literature about Python meta programming misses out __subclass_init__ as it was only added to Python 3.6 in 2015 via PEP 487.

https://peps.python.org/pep-0487/

Re: Metaprogramming in Python

#23
post #8

The reason why you have to reinvent lisp when you go deep enough is that if you are not, it is getting too hard and too confusing.

This is why any CS curriculum worth its salt should provide a summary of / introduction to Lisp and Smalltalk at or very near the start, so that in the second and third year of study or shortly after graduation, any encounters with so-called "voodoo" will elicit an "ah yes, sounds like CLOS MOP" response or something similar, rather than wide-eyed excitement leading to uninformed evangelism.

(Mine didn't have it, and I've been ruing it, and compensating for it, ever since.)

Re: Metaprogramming in Python

#24
This is awesome! Now, never ever do it.

Python is powerful and flexible enough that you don't need metaprogramming.

(I mean this quite literally: I sincerely doubt that there any code in Python using metaclasses etc., that wouldn't be more clear and maintainable if rewritten in "plain old" Python without them.)

(With the caveat that I'm not including "art" projects, I'm talking about working production code.)

(In case it's not clear, this is one of those "Prove Me Wrong" scenarios... If you think you have a counter-example to my claim, please don't keep it to yourself, "Shout it out so the whole theatre can hear you!")

Re: Metaprogramming in Python

#25

This oft-repeated quote is always relevant on Python metaclass posts: “[Metaclasses] are deeper magic than 99% of users should ever worry about. If you wonder whether you need them, you don’t (the people who actually need them know with certainty that they need them, and don’t need an explanation about why).” Tim Peters, Inventor of the timsort algorithm and prolific Python contributor https://www.oreilly.com/library…

I think you mean `__init_subclass__`

Re: Metaprogramming in Python

#26

It is shocking how much vodoo magic there is in a programming language marketed as "easy to learn and use". And with the recent addition of new syntax, I would hardly call Python easy.

That's not uncommon, when you make something easy* to learn and use you obfuscate certain things that are more "advanced" to streamline the onboarding experience, and then when you want to break out of the streamlining you gotta learn to circumvent those "stops" somewhat, which often end up being pretty non ergonomic. It compounds as well because the ones developing the language will have a bias towards what it currently offers and the "unorthodox" side keeps getting set aside.

*and by easy there I mean streamlined and more intuitive on most expected "common" tasks than the alternatives

Re: Metaprogramming in Python

#27
post #25

This oft-repeated quote is always relevant on Python metaclass posts: “[Metaclasses] are deeper magic than 99% of users should ever worry about. If you wonder whether you need them, you don’t (the people who actually need them know with certainty that they need them, and don’t need an explanation about why).” Tim Peters, Inventor of the timsort algorithm and prolific Python contributor https://www.oreilly.com/library…

I think you mean `__init_subclass__`

I do, thanks!

Re: Metaprogramming in Python

#28
The article's reference to "classobj" is wrong for Python 3 (that was the type of old-style classes in Python 2). In Python 3:

    >>> class SomeClass:
    ...     pass
    ...
    >>> type(SomeClass)
    

Re: Metaprogramming in Python

#29

It is shocking how much vodoo magic there is in a programming language marketed as "easy to learn and use". And with the recent addition of new syntax, I would hardly call Python easy.

Most Python programmers never need to worry about the "voodoo magic". But for writing tools and libraries that can nicely encapsulate a desired behavior and make it simple for other programmers, Python's "voodoo magic" is great.

Re: Metaprogramming in Python

#30
post #4

Small typo at the start of the code examples. We define the instance as: someobject = SomeClass() but then we refer to it as someobj and some_object

Small typos everywhere. Init functions without the dunders, move_ahead in an abstract class then moveahead later.
Post reply on HN