joesox at gmail.com
Fri Feb 23 22:14:29 CET 2007
On 2/23/07, Dino Viehland <dinov at exchange.microsoft.com> wrote:
> We're basically doing the same thing that the array.py is doing - the difference truly is just the item size. Python is implicitly doing the check by calling range(n) and doing the size check on each read. We're reading everything in at once and doing the same basic size check just doing it before intsead of at each read. They should both be equivalent though.
> Is there an issue w/ switching to using the I type for the array instead of the L type?
I tried this but was unsuccessful. It still results in the same
exception being thrown. If I am understanding everything, the only
typecode that uses 8 bytes is floating point 'd'.
> If that seems too cumbersome we could consider changing the default size of L to match CPython (I suspect this means 4 bytes on a 32-bit platform and 8 bytes on 64-bit but I don't have a 64-bit install of CPython).
This is an interesting solution and I wish others onlist that use
array could test also to provide additional feedback. If I had more
time I could try to test with a rebuild of 1.1B and get back to you.
I am not sure if I would be modifying correctly though, at this point
I just quickly glanced at how you guys constructed the typecodes.
I wouldn't think that modeling CPython's 4 bytes would be a bad thing,
if an IP goal is to enable user modules to work both in IP and
CPython. I think this is why many of us like IP because you can have
something in CPython and easily use it in a .NET platform, or IP to
CPython. I true cross-platform module would be my goal.
More information about the Ironpython-users