>>38
The backtrace myth has already been argued extensively elsewhere and I'm not going to bother repeating it.
Implementing backtrace compression means further complicating all existing interpreters, all tools from debuggers to profilers to code coverage analyzers (for all existing platforms) and so on. To put it bluntly: it's a nice hack that can work for a toy language that simply doesn't have all that ecosystem around. For a real language it's not worth it even if you do it from the very beginning, much less when you are considering such a drastic change after shy of twenty years of evolution.
they preserve proper object oriented abstractions
I have a vague recollection of what you're talking about, I remember deciding that for such a contrived case you are better off implementing your code flow explicitly. I could reconsider if you give me the chance, by providing a link.
Name mangling always was and always will be a hack and relies on you playing nice, which undermines the whole encapsulation point.
No. The point of encapsulation is not in providing security. When you want to run a code that was written by someone who might have not been "playing nice", you need much more than encapsulation to prevent him from formatting your hard drive, and the effort is much better applied at other points and larger scales. Python's name mangling does exactly what it supposed to do with minimal effort, providing a zero chance that someone might not "play nice"
accidentally and doing nothing more, not getting in the way of reflection for example.
We complain about it in languages like C which don't have namespaces, why shouldn't we complain about it in python.
I'm sorry, but this makes me think that you don't have an idea of what are you talking about. I hope you are able to find your way to Python reference describing how its name mangling works without my assistance.