In terms of features, I imagine they are about the same. Here is why I think this. Maxima's function organization seems to follow and refers to the NIST Digital Library of Mathematical Functions https://dlmf.nist.gov/
Mathematica and Sympy also seem to follow this organization.
My take: I blame compatibility on the NIST Digital Library of Mathematical Functions.
Actually, no, shortening names won't speed bytecode up in the way you seem to be suggesting. Variables "are" indexed by position in some arrays like co_varnames, co_names, co_const and so on. See for example https://docs.python.org/3.8/library/dis.html?highlight=co_na...
There are maps in the code object that will turn the index back into a name, but that's only used when some sort of introspection occurs, such as you might find in a debugger or traceback.
The names found in an "import" of course is a string so there might some small advantage there in a shorter name.
As for round-tripping, I make use of that idea in testing the decompiler and/or looking for bugs (which are numerous). Python has an extensive test suite for its many library programs (in later versions in excesss of 800) which are largely written in Python.
The cool thing about a unit test program is that it is self checking.
uncompyle6 is far from perfect, so no, it doesn't roundrip all of the unit test programs that it could. (There are some unit test programs that are too fragile, like those that expect the line number to be exactly the same which might occur in tests testing a debugger).
The biggest problem as I've said many times is handling control flow properly. However that could be solved much better if someone who had more time to spend on this wanted to.
Yes and no. If you are sure that you start out with something generated by Python, then assuming the Python compiler is faithful, then of course you can always produces source code that doesn't have goto's in it. If instead someone crafts custom bytecode, like I did here: http://rocky.github.io/pycon2018-light.co/#/ it might not have a high-level Python translation.
When there is a translation, is it always unambiguous? No. The same bytecode could get decompiled "a and b" or as "if a: b".
Why this happens less often in Python, especially earlier versions fo Python, is that it's code generation is very much template driven and there very little in the way of the kinds of compiler optimization that would make decompiling control flow otherwise harder.
Using the example given above, I believe earlier versions of Python would always enclose the "then" statement/expression with "push_block", "pop_block" pairs. Even though in certain situations (no new variables are introduced in the "then" block) this isn't needed. But the fact that those two additional instructions are there can then distinguish between those two different constructs.
It is sort of like matching ancestry based on the largely "junk" DNA strands that exist in a person.
Finally, I should note that Python with its control structures with "else" clauses like "for/else" "while/else" and "try/else" make control flow detection much harder. And this is the major weakness of uncompyle6.
That's why I started https://github.com/rocky/python-control-flow to try to address this. In contrast, the current python uncompyle6 code which has a lot of hacky control flow detection, this creates a control flow graph, computes dominators and reverse domninators in support of distinguishing these high-level structures better.
Instead of taking a quick look at the description of how it works, why not instead spend a little more time to understand more, before passing judgement? I have written http://rocky.github.io/Deparsing-Paper.pdf to help people who want understand how this fits into the conventional decompiler landscape, and how things are a little different here.
Spoiler alert: no is it no more a glorified pattern-matching approach any more than a dragon-book-style compiler is.
The v8 debugger protocol rocks. The standard cli interface to it less so. For example, missing is simple frame-motion commands like "up", "down", with attendant evaluation in that context are possible from the protocol.
This tradition of cool debugger protocols with crappy CLI interfaces I first noticed in jdb. Creating a decent CLI isn't all that hard.
You might think well, no one uses CLI interfaces any more. As I watch my colleagues work, especially those who work in cloud and container-based systems, I am seeing that they are still using command-line interfaces quite a bit.
Finally, for those would-be command-line debugger interface writers, instead of inventing a new interface, why not pick an existing one to work off of? Here I selected gdb (as I've done in the 6 or so other debuggers I've done).
By doing this, as you learn any of the debuggers, you'll most likely be able to apply to the other debuggers, including gdb and vice versa.
What I have come to learn, especially with the stock node inspect, is that most people don't really know how to use the full power of what's already there. This is partly due to its differentness. But it is also partly due to its sparse documentation
Author here. Recently incorporated this into Python's traceback module: https://pypi.python.org/pypi/loctraceback
and have used this idea in Perl (which from the help of perlmonks is where I got the idea).
I am curious if it has been used in other programming languages as well.
Mathematica and Sympy also seem to follow this organization.
My take: I blame compatibility on the NIST Digital Library of Mathematical Functions.