Live data from Hacker News

Metaprogramming in Python

developer.ibm.com

41–50 of 61 posts

Re: Metaprogramming in Python

#42

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 cas…

The example shows that django models uses metaclasses heavily. So I'm assuming if you needed to extend django models, you'd have to do it via metaclasses.

Too easy: Django meta-programming is one of the things that has bitten IRL. A junior dev was pulling hair out one day trying to subclass a Django HTML form object. Couldn't do it because of Django cowboy metaclass. Had to wrap it in a "factory" and modify it before returning it.

Django using metaclasses is exactly the problem I'm warning of...

You don't need metaclasses for data models nor for HTML forms. Nothing Django does requires metaclasses, and it's actively beginner-unfriendly to use them.

Re: Metaprogramming in Python

#43
post #31

This is a cool overview, and I certainly learned new things about the Python language from it. Thanks for posting! We do lots of Python metaprogramming at Mito [1], but generally avoid all of this fancy Python fluff to get it done. Specifically, we avoid metaclasses, invisible decorators, etc. Instead, we take a much simpler approach of having Python code that literally populates as template .py file, and then writes…

I personally consider code generation an anti-pattern in Python. With its dynamic nature and the two-step execution model, Python is essentially its own macro language, and any generation can be done at runtime.

unfortunately pep-484 changed all that. now you have to use static generation for basically anything that used to be at runtime previously, if you want it to have any kind of compatibility with mypy, pylance, etc.

Re: Metaprogramming in Python

#44
post #38

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've run across people in three different companies who decided to use them for no good reason at all. I was only around for one of them while he did it but it seemed pretty clear that he was insecure and trying to prove that he was a more experienced programmer by using the most advanced features. I call it "the advanced beginner metaclass trap".

Yes very much this. I've worked on two projects in the last year that used metaclasses. Neither needed them in the least and they simply added noise and complication.

In one case I think the author did believe he needed them, or was going to. He didn't, but I think he believed it was the best way to go about the inheritance he was doing.

The other case was exactly what you say. The person wanted to show how advanced their knowledge of Python was. The funny part about the second case (which included every advanced or new Python feature under the sun, including the walrus operator shoehorned in for good measure) the code simply didn't work at all. It ran but was wrong. The author was so busy demoing his advanced knowledge he forgot to make it work. And was unable to debug it in a timely fashion due to his overuse of abstractions and features. So less "advanced" me was brought in to make it work. Which I did.

Re: Metaprogramming in Python

#45

Earlier quoted context omitted.

That "smooth learning curve" applies when you are learning the language, use it by yourself or work in the ML/Data science industry. Once you get thrown in a big project that makes heavy use of type hinting (plus the whole environment of it, mypy et all), Object Oriented design and all those hidden things...you realize how much you really don't know. And that 10% is way too small. To be productive in Python, you need…

If you make a big project, you will have to use that many things with every langagues. If the language is rich, you'll learn the language. If not, you'll learn the project patterns. It's not specific to python. But 99.9999999% projects won't implement metaclasses. Most won't event implement decorators, context managers or generators. Use them, sure.

The REAL power comes from the libraries. In the Olden Days, we would call these 'subroutines' -- libraries contain the gussied-up subroutines that make it possible to do amazing things in Python with that "10% of the language" we use.

Re: Metaprogramming in Python

#46

Earlier quoted context omitted.

If you make a big project, you will have to use that many things with every langagues. If the language is rich, you'll learn the language. If not, you'll learn the project patterns. It's not specific to python. But 99.9999999% projects won't implement metaclasses. Most won't event implement decorators, context managers or generators. Use them, sure.

The REAL power comes from the libraries. In the Olden Days, we would call these 'subroutines' -- libraries contain the gussied-up subroutines that make it possible to do amazing things in Python with that "10% of the language" we use.

Python already has a bunch of built-in libraries that make it a full-fledged scripting language. Basically, it is Node.js on steroids.

In the olden days, programmers would have to make 90% of that, alone.

Maybe this is the reason why everyone and their grandma can call themselves programmers these days.

Re: Metaprogramming in Python

#47

Earlier quoted context omitted.

The REAL power comes from the libraries. In the Olden Days, we would call these 'subroutines' -- libraries contain the gussied-up subroutines that make it possible to do amazing things in Python with that "10% of the language" we use.

Python already has a bunch of built-in libraries that make it a full-fledged scripting language. Basically, it is Node.js on steroids. In the olden days, programmers would have to make 90% of that, alone. Maybe this is the reason why everyone and their grandma can call themselves programmers these days.

Yes. And all this fancy 'metaprogramming' is just syntactic sugar for how one calls subroutines.

I agree: Python has Batteries Included. But additional Batteries are Optional.

Re: Metaprogramming in Python

#48

Earlier quoted context omitted.

The example shows that django models uses metaclasses heavily. So I'm assuming if you needed to extend django models, you'd have to do it via metaclasses.

Too easy: Django meta-programming is one of the things that has bitten IRL. A junior dev was pulling hair out one day trying to subclass a Django HTML form object. Couldn't do it because of Django cowboy metaclass. Had to wrap it in a "factory" and modify it before returning it. Django using metaclasses is exactly the problem I'm warning of... You don't need metaclasses for data models nor for HTML forms. Nothing Dja…

What is an example of a good orm alternative? Don’t remember sqlalchemy being substantially different on the model definition front.

Re: Metaprogramming in Python

#49
post #31

This is a cool overview, and I certainly learned new things about the Python language from it. Thanks for posting! We do lots of Python metaprogramming at Mito [1], but generally avoid all of this fancy Python fluff to get it done. Specifically, we avoid metaclasses, invisible decorators, etc. Instead, we take a much simpler approach of having Python code that literally populates as template .py file, and then writes…

How do you deal with changes over time?

Like let's say you want to add a new required property to every type of something... like you want every encoding to have an accepts_tainted_value property. You don't want a default because you want to be forced to think through every case.

Can you regenerate the code? If so, are you keeping the "real" object specification in some other structure? Or do you just change a superclass to make the property required then fix the generated source based on the errors you get?

Re: Metaprogramming in Python

#50

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 cas…

[deleted]
Post reply on HN