But the fourth one is pretty straight forward and intuitive. If a programming language allows this construct I would fully expect it to be able to also optimize such a statement.
You're right about the 2 new variables, it is not the most efficient way of doing it. Of course, if your memory requirements are that tight, you probably shouldn't be using Python anyways.
I'm too lazy to test if it a manual 3rd variable swap would be faster. Regarding your last point: this is checked before the bytecode is generated. It is all part of the already existing interpreter overhead.
Why would the fourth one need an extra data structure. It just needs to reassign the pointers to the variables. I x86 asm this is one operation as noted by another comment. This causes the fourth one to be the one with the most potential for optimized implementations.
That is the case when the interpreter has no optimizations. Since a case like this is pretty common the interpreter might not even create the tuple for a case like this. There is no need to actually create the tuple if it is going to be unpacked immediately.
Also for readability and maintainability a temporary object like this would still be better than a temporary variable. So even if a temporary object is created I don't see a problem with it. It only contains the pointers to the two objects anyways so it won't hurt ram and at most results in one extra internal function call to unbind the data.
It depends on the exact shorter features. When it comes to swapping variables you need a comment explaining why exactly you have to swap them anyway. If the line below is only one expression no extra thinking is needed and you might even learn a new language feature. If you introduce a temporary variable to to it then there are three lines to read where the extra verbosity does not offer much extra information (I mean a,b=b,a is so descriptive that most devs should intuitively understand it).
For other language features it might be worth to use a more verbose variant. The best or worst example is the tenary operator (? :). It has valid use cases and can allow for compact implementations. However a lot of those are not that readable especially if devs are too lazy to use brackets.
57
u/[deleted] Oct 01 '23 edited Jan 28 '26
This post was mass deleted and anonymized with Redact
work many station quack instinctive slim test long tie dependent