Hi. [Armin Rigo] > In particular, I believe we won't need to change the way the current Python > interpreted encodes data. For example, instances currently have a > dictionary of attributes and no "fixed slots", but this is not a problem > for Psyco, which can encode instances in better ways (e.g. as a C struct) > as long as it is only accessed by Psyco-compiled Python code and no > "legacy" code. This makes sense, but I'm asking if it is affordable to have all code executed (if we aim for usage-transparency) through Psyco-compiled code (memory foot-print, compilation vs. execution trade-offs for rarely executed code) Otherwise in a mixed execution context we would pay for conversions. I can see how a dynamic compiler can deal with methods together with the interpreter that notifies when a dynamic change to hierarchy, method defs can potetianlly invalidate compiled code. I see more problems with instance data slots, because there are no strong hints in the code about which are the "official" slots of a class, and undisciplined code can treat instances just as dicts. regards, Samuele Pedroni.
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