Dumb python questions

[Alex Martelli]

"Paul Rubin" <phr-n2001 at nightsong.com> wrote in message
news:7x66bkjzbj.fsf at ruckus.brouhaha.com...
> "Alex Martelli" <aleaxit at yahoo.com> writes:
> > GMP is pretty fast, and so is its wrapper GMPY.  See
> > gmpy.sf.net.  I don't think it's a "weird kludge" to wrap
> > a good multiprecision library to get at its functionality
> > from Python -- I think it's rather Pythonic, actually.
>
> Yes, using gmpy works pretty well if it's available.  But it's not a
> standard Python module.  It's kind of a strange idea though, that
> Python has built-in long ints but I have to use an add-on package if I
> want to do simple operations like find out how large a number is.

A good point, and therefore maybe Python longs should expose
more methods/readonly properties to give you direct access to
the underlying binary representation (or module struct should
have a format-code to handle that, but that sits badly with its
present architecture, where the struct.calcsize only depends on
the format string, not on the data being packed/unpacked).


> I guess I'll probably use gmpy in my application if I can, because
> it's quite a bit faster than Python's built-in arithmetic, though
> Python's is quite respectable and useable (as compared to, say, perl's
> Math::BigInt package.

I remember there used to be a freely downloadable adjunct to
Visual C++ to let it produce code for Windows CE, which as you
explain later is your target environment -- I dunno if it's still
available and if so on what terms.  One would have to start by
porting the Gnu MP library though -- presumably in the C-only
version (CE targets quite a few different CPU's, right?)... maybe
a Python fork to expose a couple of readonly properties and a
factory function for long/binary-string interconversion would be
easier (of course, one would still have to have a C compiler for
WinCE to rebuild the forked Python, sigh).


Alex