> There are a number of crude hacks that might be solved better: the > 2-argument opcodes, for instance, could posisbly be avoided by abusing the > proposed 'extended_arg' opcode. And the patch re-uses the binary opcodes as > augmented-assignment opcodes, merely because those #defines were already > available in both ceval.c and compile.c: this would 'break' if we wanted to > incorporate a new operator in augmented-assignment without adding a new > 'normal' opcode for that operator. > > I'm still working on the PEP, really :) It's just a pretty long one, trying > to explain all the intricate details and the simple elegance of the solution > <wink>. Perhaps it'll inspire some discussion in the details of the patch, > too. Suggestion: write the VM spec first, and check that in when you're done. I bet that writing down the VM spec will clarify a lot, since it will specify the semantics (the syntax we all know). --Guido van Rossum (home page: http://dinsdale.python.org/~guido/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4