It's amazing that Python 3 was 4 years old when this post was made and yet saying "Python" was still implicitly assumed by basically everyone to mean 2.x.
But that should turn around NOW, comsidering 2020 will be EOL for Python2 (except for Redhat which will have to ride that dead horse for years to come).
What I was saying is that it's amazing Python 3 failed to gain any significant traction in 4 years. I personally have been using Python 3 since ~2010 but am apparently in a tiny minority on that.
> Once you know this stuff, you'll be a much stronger debugger.
As you suggest, more accurately, you'll require the next person who debugs your code to read this, making them much better at debugging your code.
I no longer use magic and completely avoid meta programming in python. It confuses everyone, is not needed (just use a boring factory function), and severely limits who can help you work on your code, for what? A few lines of less boilerplate here and there? "Succinctness"? Some sort of "elegance"? More likely, a DSL that nobody understands but you!
The more I write, and mostly the more I interact with other people, the more I realize that code needs to be boring. No magic. I think this is why go is succeeding: no magic.
100% agree. I figure this is a big part of what turns normal developers into senior developers, and lead developers. It's easy to code. What takes wisdom is 1) knowing what not to write, and 2) self control on how you write it. As a mentor I try to convey this to the fresh new supercoders joining our team.
My reaction to this, as someone who doesn’t use many of these on a regular basis (probably guilty of overusing __new__ though) is actually that I can imagine these causing some real problems. The operator ones seem particularly tempting and dangerous at the same time.
Operator overloading, in any language that supports it, has always been controversial, so Python doesn't really add anything new there.
The thing is, it's also incredibly useful at times. Language features that are "useful when you have the use case for it, confusing when you don't" tend to provoke that reaction.
Which is a good thing, because it makes the whole arrangement a lot more consistent that languages in which this sort of thing is just magic associated with a specific primitive type (sometimes it's even inconsistent - e.g. in C#, + for ints and strings is magic, but + for decimal is an overloaded operator). In Python, all that magic is confined to the magic methods. Learn them once, and they work the same everywhere.
Oh yeah, don’t get me wrong. It’s cool as hell! I’m totally gonna use it for a GUI menu-building script interface I’m making right now :).
I have just never done it before, and I think this is the first time I have seen the concept, so the first thing that popped in my mind we’re all the things that can go wrong. But, also all the things that can go right.
Could you give an example of how you would use these methods to debug versus other methods/approaches? I'd love to hear if you're willing to share--I program mainly in Python these days but Python's magic methods are definitely something I need to understand at a deeper level.
Fluent Python has a chapter on these methods and I highly recommend it. Also, these are much better described as dunder methods (short for double underscore) than magic methods. There's really no magic to them.
A related article I got a lot out of was ‘Understanding Python Metaclasses’, an in-depth breakdown of Python class instantiation. Here’s the link to that:
It's awesome that someone has taken the time to write this all up. With reference to this section (https://rszalski.github.io/magicmethods/#descriptor) the author mentions that descriptors are "meant to be held by an owner class." which is true, however in their example, they are storing the value as `self.value` on the descriptor object itself meaning that if the user were to have two instances of `Distance` all their values would be the same for meter or foot on all instances of `Distance`. One way to solve this is to store the values in a dictionary-like structure on the descriptor, e.g. `self.data[instance] = your_stored_value`.
Django's DRY suuuuuuuucks when you're getting started. It's basically all this magic that you can't understand without already knowing Django.
Why does get_attr get called? Oh because it begins with the word "get" and there's an attribute that defines a method field called "attr".
I use Django a lot and generally it's great. But I hate that you can't follow your code paths from start to finish on the surface. You have to know about how it works underneath. Meaning you can't just be a python + web server expert. You have to also be a Django expert. So I get non-Django experts reviewing code and they have no clue why things work or break.
Just an opinion. Not saying this is objectively wrong.
Flask is great for smaller things where Django is far too verbose. Like single file webservers for basic stuff.
Its also for more complex stuff but then you have to grab additional libraries to do stuff like db management, migrations, serialization, etc.
Flask also has some, in my opinion, rather uncomfortablly unintuitive global scope stuff. Where responses aren't passed into the view function, they're available on the imported flask object.
Good to know. I haven't used Flask recently, I have used Express.js which is Node.js's version of Flask, and I really like how simple it is. Most apps these days seem to have a REST (or GraphQL) backend and dynamic (often React.js) frontend. Flask (and Flask-RESTful) would probably be a better fit for this type of app than Django.
Wierd. Maybe it's just me, but I felt that way for the first 2 days.
I have made some really dynamic stuff (like 100 domains running off a single server with each of their data separate, and to add a new domain is a click away)
. I can't imagine doing that with other frameworks
> if people think this is so magic, it's almost as if lisps, schemes, and prologs never existed.
I write quite a bit of Lisp, and the conclusion I've come to is that for 95% of software developers, Lisp, Scheme, and Prolog might as well not exist. Even here on HN, where I'd expect the bar to be a little higher, the amount of incorrect info posted about Lisp is pretty crazy.
I'm almost certain most people's only experience with Lisp(s) and Prolog was a week or two using it in their programming languages class at university.
I felt the same way as I learned Python. People told me Python had this magical framework built into the language and that I'd understand everything once I learned it. Turns out the built-in language features are syntax sugar for some __special_method__ calls. Simple and functional, but underwhelming...
But this article is just explaining operator overloading, right? Doesn't everyone learn that halfway through semester in C++ 101?
And operator overloading has nothing to do with DRY, in fact it's generally better to avoid it except for in very niche situations, like adding __add__ to a matrix type.
> Be careful, however, as there is no guarantee that __del__ will be executed if the object is still alive when the interpreter exits, so __del__ can't serve as a replacement for good coding practices (like always closing a connection when you're done with it.
When the interpreter exits, your program's resources should be reclaimed by the operating system, right? So why not just use __del__?
You almost always only want to implement __del__ if you're writing an extension in C. Otherwise, the GC generally takes care of cleanup perfectly fine.
And in cases like the one cjhanks describes, __del__ doesn't get called reliably enough. In those cases, using a contextmanager is better.
If this were the case, there would be no need for SIGTERM. The OS doesn't know the application logic and can't guarantee clean termination from the application's perspective.
As others have said, there's rarely reason to override `__del__`, and when you do you know exactly why you need it.
(The article will perhaps be a better guide to those newer; the data model page is … pretty dense.)
Also, I find is exceptionally handy to have a Chrome "search engine" for the Python docs while I work. That is, on chrome://settings/searchEngines I have added a custom search engine with this setup:
In Python 3 __cmp__ is ignored and you have to use the other methods. To make this easier, you can use https://docs.python.org/3/library/functools.html#functools.t...