Issue876198
This issue tracker has been migrated to GitHub,
and is currently read-only.
For more information,
see the GitHub FAQs in the Python's Developer Guide.
Created on 2004-01-13 16:43 by mwh, last changed 2022-04-11 14:56 by admin. This issue is now closed.
Files | ||||
---|---|---|---|---|
File name | Uploaded | Description | Edit | |
easy-peasy.diff | mwh, 2004-01-13 16:43 | mwh's patch #1 |
Messages (9) | |||
---|---|---|---|
msg45286 - (view) | Author: Michael Hudson (mwh) | Date: 2004-01-13 16:43 | |
I've always been a bit suspicious of the machinery to allow arbitrary objects that support the read buffer interface as the co_code attribute of code objects, but didn't realise that hacking it out improved pystone by a repeatable 1%! Greg, according to CVS this is your feature I'm proposing removing -- can you explain its value? |
|||
msg45287 - (view) | Author: Raymond Hettinger (rhettinger) * | Date: 2004-02-06 18:57 | |
Logged In: YES user_id=80475 Guido, I think this is reasonable, but it is an API change. Do you see any reason to support non-string co_code arguments? |
|||
msg45288 - (view) | Author: Tim Peters (tim.peters) * | Date: 2004-02-06 20:18 | |
Logged In: YES user_id=31435 IIRC, this was to allow small platforms to store code in ROM (or flash ROM) and run it directly from there, without needing to make a copy in limited RAM. I don't know whether anyone has done that. |
|||
msg45289 - (view) | Author: Raymond Hettinger (rhettinger) * | Date: 2004-02-06 23:00 | |
Logged In: YES user_id=80475 Consider making it a compilation option for small builds (turned-off by default). |
|||
msg45290 - (view) | Author: Guido van Rossum (gvanrossum) * | Date: 2004-02-07 04:54 | |
Logged In: YES user_id=6380 1% is not something that can be measured reliably IMO (try it again with a different phase of the moon, or on a different box). OTOH I don't think that anyone has ever actually made use of this feature -- it was a request from Greg Stein but I doubt he got to use it. OT3H, compilation options like this tend to break the first time someone updates the affected code -- nobody is going to test with all possible combinations of weird compilation options. How's that for a non-answer. :-) |
|||
msg45291 - (view) | Author: Michael Hudson (mwh) | Date: 2004-02-11 16:30 | |
Logged In: YES user_id=6656 > 1% is not something that can be measured reliably IMO (try > it again with a different phase of the moon, or on a > different box). I have. I was astonished that the difference was noticable, so I tried it in quite a few places and styles. But *shrug*. I don't support making this a compile time option. If you want it, it's easy enough to put back in for yourself (and if the flash ROM thing is your motivation, you'll be doing your own build anyway...). > How's that for a non-answer. :-) It's certainly not an answer <wink>. |
|||
msg45292 - (view) | Author: Raymond Hettinger (rhettinger) * | Date: 2004-02-11 17:57 | |
Logged In: YES user_id=80475 I think the patch should be accepted as originally proposed. Why have all the common environments pay for Flash ROM support which is likely not being used anyway? Precisely measuring the improvement isn't important. On the face of it, the patch does less work and is simpler -- that's good enough for me. |
|||
msg45293 - (view) | Author: Guido van Rossum (gvanrossum) * | Date: 2004-02-11 18:11 | |
Logged In: YES user_id=6380 agreed |
|||
msg45294 - (view) | Author: Michael Hudson (mwh) | Date: 2004-02-12 15:46 | |
Logged In: YES user_id=6656 OK, I checked in Include/compile.h revision 2.41 Misc/NEWS revision 1.931 Python/ceval.c revision 2.377 |
History | |||
---|---|---|---|
Date | User | Action | Args |
2022-04-11 14:56:02 | admin | set | github: 39814 |
2004-01-13 16:43:03 | mwh | create |