Hello, Just out of interest (I haven't investigated yet), py.py loads in Python 2.4a3 but 'import dis' apparently sends it into an infinite loop. It also prints 'faking <type 'module'>' just after 'import dis', which it doesn't do with Python 2.3.3. Funny. Armin
Hi, On Mon, Sep 27, 2004 at 08:25:41PM +0100, Armin Rigo wrote:
Just out of interest (I haven't investigated yet), py.py loads in Python 2.4a3 but 'import dis' apparently sends it into an infinite loop. It also prints 'faking <type 'module'>' just after 'import dis', which it doesn't do with Python 2.3.3.
This is due to opcode.py, which in 2.4 uses string formatting to build opcode names, while in 2.3 it uses concatenation. From the diff: < for op in range(256): opname[op] = '<' + `op` + '>' ---
for op in range(256): opname[op] = '<%r>' % (op,)
As it happens, string formatting is *really* *slow* in PyPy now. Every one takes about 1 second! So importing opcode.py takes several minutes. Quoting Michael, "time to make string formatting faster". Armin
[Armin Rigo Wed, Sep 29, 2004 at 09:13:35PM +0100]
< for op in range(256): opname[op] = '<' + `op` + '>' ---
for op in range(256): opname[op] = '<%r>' % (op,)
is there a deeper reason for this change, btw?
As it happens, string formatting is *really* *slow* in PyPy now. Every one takes about 1 second! So importing opcode.py takes several minutes.
Quoting Michael, "time to make string formatting faster".
which probably means to reimplement it at interpreter level ... which might be cumbersome but then it might be straight forward ... holger
hpk@trillke.net (holger krekel) writes:
[Armin Rigo Wed, Sep 29, 2004 at 09:13:35PM +0100]
< for op in range(256): opname[op] = '<' + `op` + '>' ---
for op in range(256): opname[op] = '<%r>' % (op,)
is there a deeper reason for this change, btw?
As it happens, string formatting is *really* *slow* in PyPy now. Every one takes about 1 second! So importing opcode.py takes several minutes.
Quoting Michael, "time to make string formatting faster".
which probably means to reimplement it at interpreter level ... which might be cumbersome but then it might be straight forward ...
Or work out why it's so painfully slow currently, via hotshot or whatever. One could create a half-assed interpreter level implementation by just executing the current code at interpreter level (and probably changing a few little things, like calling space.str instead of str). It almost certainly wouldn't be RPython though (esp. the floating point stuff which uses long arithmetic; the rest might be close). Not a lot of fun, though. Cheers, mwh -- Important data should not be entrusted to Pinstripe, as it may eat it and make loud belching noises. -- from the announcement of the beta of "Pinstripe" aka. Redhat 7.0
participants (3)
-
Armin Rigo
-
hpk@trillke.net
-
Michael Hudson