
Hi Niklaus, Sorry for the delay. I've indeed been quite deeply into the PyPy sprint... At which level and with which style the array module should be implemented is indeed a bit unclear. If you are going for an app-level version, you should not worry too much about geninterp, I guess. The code you already started to write makes sense. Geninterp is most useful to solve bootstrapping issues, where we cannot import yet some app-level code but we can run its geninterp'ed version (e.g. for the _exceptions.py module). Of course geninterp gives some performance improvement too. The problem with array is that it is designed with the following model in mind: a bunch of memory out of which Python values can be read on demand. The other point of view -- a list of Python values that can be turned into a big string on demand -- make methods like byteswap() hard to implement, specially for arrays of floats or doubles. Not necessarily impossible, though. If this app-level approach works out, I wouldn't invest too much effort in geninterp compatibility, because at some point in the future we might have to think about a quite different approach: adding the notion of integers and floats of specific sizes, at least in the so-called "low-level" types. I guess that an efficient implementation of array should be written to take advantage of these. This will likely require as-yet-unspecified ways to interact between regular interp-level code and this low-level-typed code. In summary I guess that writing a pure app-level array module makes sense, with the buffer interface working for PyPy only. On Tue, Jul 26, 2005 at 06:15:01PM +0200, Niklaus Haldimann wrote:
I'm not sure I understand this: using StringIO in this way can be sufficiently static to be geninterped. Both the direction you started and this StringIO-based version make sense. A bientot, Armin.
participants (1)
-
Armin Rigo