>>29
Take TCO for instance
The problem with TCO in FIOC, as I understand it, is that the most vocal proponents of it sound like "Give us implicit TCO we want recursive fibs also u don't understand `reduce` u suck derp haskal derp derp". Of course Guido perceives that as the way to say "I have read SICP today" (which it totally is) and disregards them in bulk.
And he is right, adding implicit TCO to Python is the dumbest idea ever, because suddenly all Python scripts in existence would start producing confusing stacktraces, pdb and the rest of advanced tools that expect orderly stacktraces would have to be patched in subtle ways and so on. Adding a switch to the interpreter or maybe a special import or something wouldn't help either because TCO is not an optimisation. So that is never gonna happen.
But even if someone managed to calmly explain that, dude, what we need is a new .tailcall bytecode like in .NET and a special "tailcall return" keyword, and present a set of real-world applications for the new functionality, even then I'm afraid it would be rejected.
Because if you need TCO for your FSM, writing a trampolining decorator takes five minutes and ten lines of code. Is some minute increase in speed by implementing it in the interpreter worth the effort? And it's not only CPython that would have to be patched, mind you. No, absolutely not.
object fields are public
Start private field names with an underscore. It will mangle the names, so no one would be able to accidentally access them, while deliberate access is not different from accessing them via reflection, which every language in existence that has reflection allows anyway.