It seems like so long as there's a distinction in the language between
ints and longs, there should be a way to create ints reliably.


int(foo % sys.maxint)

is such a call, great. Is this guaranteed to work? I don't know.

Basically, if you're going to say ints and longs are separate types, I
think there should be a way to makes ints from longs fairly reliably. I
don't think that's a niche, I think it's something a consistent language
should provice.

Maybe python is moving towards a day where ints and longs are completely
indistinguishable. This probably wouldn't be a bad thing, from many
standpoints. But until that day comes, I think that there should be a way
to construct an object without getting an exception. I guess it's more a
matter of taste whether the implentation or the interface-user should do
it, but since one still allows the other, I'd say the implementation
probably should.

I like the flexibility python provides, but it seems that there might be
cracks where orthogonality or consistency of interface have cracks; which
makes sense in an evovling language. If I managed to arrive at python at
a point where this "problem" was just begotten and there's a good chance
it will go away soon, perfect. But I stil think there's an elegant
solution to be had, that works across implementations. Is it sys.maxint?
Maybe. Silent exceptions, like Java will do for math stuff? Maybe. I'm
getting the impression the solution is maxint, so great. Thanks.

On Wed, 26 Mar 2003, Alex Martelli wrote:

Daniel Timothy Bentley wrote:
Am I so far off in thinking maybe this should be provided by the language?
IMHO, you are. "integral types with N bits ignoring overflows" is
a very marginal "niche" requirement; the language would grow far too
big if it was to provide all such marginalia! It's easy, when one is
developing in a focused way in a specific application area, to start
wishing for one's language to provide just the primitives that would
be most convenient for that specific need. But unless a primitive
has WIDE use over a large variety of application areas, the language
IS better off without it -- that's what LIBRARIES are for!

Some way to create an int, using some (perhaps implementation-defined)
method of changing a long to an int?
Why? What's wrong with int(thelong & amask)?
Some way to ensure that I don't
misguess on what themask is? What if I'm programming on a machine with 36
bit longs? Or where 64 bits is the atomic datatype?
I see you've already been advised to use sys.maxint, which is fine if
what you want is to use "integers of the exact number of bits which
happen to be provided by this specific piece of hardware". I did not
think you wanted that variability in your "C interpreter", so I chose
to provide, instead, "32-bit integers" anyway, ignoring the underlying

Isn't it WONDERFUL that the language does NOT provide a hard-coded
"way to create an int from a long", so you can easily CHOOSE depending
on your application's need how and whether to truncate longs that
are too large?

For example, if you're interested in simulating a decimal machine,
where integers have N digits rather than N bits, then instead of
bitmasking you just use int(thelong % biggie) where biggie00000
or whatever. Isn't that the cat's pajamas?


Search Discussions

Discussion Posts


Follow ups

Related Discussions



site design / logo © 2023 Grokbase