On 2/23/07, Dino Viehland <[EMAIL PROTECTED]> 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. Thanks, Joe _______________________________________________ users mailing list [email protected] http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
