I’m deeply sorry for the title of that post, but I hope that gives the topic the awareness I think it should get. In the last weeks something remarkable happened in the Python3 sources: self kinda became implicit. Not in function definitions, but in super calls. But not only self: also the class passed to super. That’s remarkable because it means that the language shifts into a completely different direction.
super was rarely used in the past, mainly because it was weird to use. In the most common use case the current class and the current instance where passed to it, and the super typed returned looked up the parent methods on the MRO for you. It was useful for multiple inheritance and mixin classes that don’t know their parent but confusing for many.
The main problem with replacing super(Foo, self).bar() with something like super.bar() is that self is explicit and the class (in that case Foo) can’t be determined by the caller. Furthermore the Python principle was always against functions doing stack introspection to find the caller. There are few examples in the stdlib or builtins that do some sort of caller introspection. Those are the special functions vars(), locals(), globals(), and __import__ and some functions in the inspect module. Four functions, and all of them do nothing more than getting the current frame and accessing the dict of locals or globals. What super in current Python 3 builds does goes way beyond that.
Currently if super is called without arguments Python performs these steps:
- getting the current frame of the caller as well as the code object.
- looking at “co_argcount” to make sure there is a first argument, if there is one it gets the object from the “f_localsplus” array on the frame object. This is btw an attribute not accessible from the Python code.
- then it checks the “co_freevars” of the code object and iterates over all of them to check if one of them is “__class__” (because accessing __class__ in Python 3 creates a special bytecode that returns the class the function was defined in).
- It it can’t find the __class__ in there it dies. How does __class__ end up there? Apparently the compiler checks if “super” or “__class__” is accessed. That’s right. It breaks if you alias super to another name and try to call that name.
- Once it has that information it uses that as two first arguments. The class and the reference to self
I’m sorry, but that’s a very, very bad idea. It’s way more magical than anything we’ve had in Python in the past and just doesn’t fit into the language. We do have an explicit self in methods and we do not have methods. Our methods are functions, just that a descriptor puts a method object around it to pass the self as first arguments. That’s an incredible cool thing and makes things very simple and non-magical. Breaking that principle by coming up with an automatic super harms the whole thing a lot. Defs in classes are not completely differently from defs in the global scope or within another def.
Another odd thing is that Python 3 starts keeping information on the C Layer we can’t access from within Python which is a shame. Super is one example — it’s currently impossible to implement that from within Python. The other good example in Python 3 are methods. They don’t have a descriptor that wraps them if they are accessed via their classes. This as such is not a problem as you can call them the same (just that you can call them with completely different receivers now) but it becomes a problem if some of the functions are marked as staticmethods. Then they look completely the same when looking at them from a classes perspective:
>>> class C:
... normal = lambda x: None
... static = staticmethod(lambda x: None)
...
>>> type(C.normal) is type(C.static)
True
>>> C.normal
<function <lambda> at 0×4da150>
As far as I can see a documentation tool has no chance to keep them apart even though they are completely different on an instance:
>>> type(C().normal) is type(C().static)
False
>>> C().normal
<bound method C.<lambda> of <__main__.C object at 0×4dbcf0>>
>>> C().static
<function <lambda> at 0×4da198>
While I was quite happy with the Python 3 progress so far, these two things are a major, major step into the wrong direction. I really hope that will be rolled back. If there is need for an automatic super self has to go away and __class__ become a free variable all the time or super a keyword. Everything else is too magical and more magical.
Update: I posted the subject on the python-dev mailing list.
About four years ago I stumbled about a promising game called “
However the game sold pretty well the first two weeks despite the bad quality of the release version and the bad reviews. It even outsold the greatest competitor at that time (Joint Operations). I was one of the early adopters and I loved to play it. Owning a bad ISDN connection at that time it was terrible lagging, especially because their netcode was a catastrophe. Still, it was great fun and the destructible environment was great. Not only that, the game was somewhat revolutionary. It was the first online game I played with an (albeit bad configured) physics engine, it used python as scripting language, it had one big map that was generated from satellite images with detailed areas where the fights took place. You could buy yourself a jet and leave the map and visit all off Siberia. Not like Battlefield Vietnam where you hit the borders of the map with a jet after roughly 15 seconds. Dammit, it would still be fun and I bet it would have been bug-less by now.
Shortly after the addon was finished the company developing that game was liquidated. The developers lost their job and the community continued developing the closed code. The group around “project zero” continued maintaining the game until that group broke apart and the gEasy team took over the work. The gEasy team was basically just the project zero team without the founder. They did an tremendous job but Jowood once again destroyed everything. They refused to pay their bills, then the gEasy team took down the master server and Ivan Ertlov appeared on the scene. He managed to resolve the problems between Jowood and gEasy team to some extend that the master server was up and running again.
Frankly I don’t know if Jowood payed or didn’t. What Jowood did was destroying the game by forcing an early release, forcing an addon when the code was still unfinished, fired the developers. Even worse: they are telling their shareholders that everything is working perfectly and that they are releasing dozens of new games. Hell, they released Spellforce 1 and 2 which both are awesome games (just happen to have the worst copy protection ever designed), the Gothic games (the 3rd part was buggy like Söldner but probably also because Jowood forced an early release). Jowood however claims that they payed and that gEasy was lying. Who is running the portal now? Apparently Ivan’s company.
What nobody really notices is that the game had a tremendous German community. Hell, some of them even took over the development! If Jowood would have noticed that earlier they could have made that game the freaking best online shooter available at that time. But because of their small horizon they just thought about their next quarter and decided to do what shareholders want, not what players want. But not only Jowood is to blame but the root of all evil in that case.