On Mon, 7 Feb 2000, Barry A. Warsaw wrote: > >>>>> "MZ" == Moshe Zadka <moshez@math.huji.ac.il> writes: > > MZ> Don't think of it as "-X", think of it as "could not find > MZ> exceptions.py, reverting to string exceptions" (or whatever > MZ> the error message is). Be sure it won't change to "could not > MZ> find exceptions.py, I don't think I feel like running" > > Absolutely. If string-based standard exceptions are removed for 1.6, > we need a fool-proof way of getting exceptions.py. Remember, my first > attempt at this stuff made that Python code a BACS[*] that got > exec'd. I'm sure there are better ways of doing that now, and I think > exceptions.py has settled down enough to warrant cooling it for 1.6. To possibly improve startup time and heap-memory usage, I added a feature into 1.5.2 that applies to freezing code. Specifically, a code object no longer requires a PyStringObject for the bytecodes. Any object exporting the buffer interface will work. This means that you don't have to copy the bytecodes onto the heap before using them. However, before this part can work properly, some special un-marshalling would need to happen. Currently, frozen code is a marshalled code object. When that is unmarshalled, the bytes will be copied. Instead, it would be nice to call PyCode_New() manually with all the various parameters and a "code" argument that is a PyBufferObject that points to the BACS. The alternative is to beef up the PyMarshal stuff so that it knows it can create buffers that point into a passed-in PyStringObject. Just some rambling thoughts... Cheers, -g -- Greg Stein, http://www.lyra.org/
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