On Thu, 15 Nov 2007, Pete wrote:
On Thursday November 15 2007 7:49:52 pm Andi Vajda wrote:
Yes, that's the intent.
Plain ints were accepted here by PyLucene-gcj.
Yes, PyLucene-gcj was hand-written.
I see this mostly as an artifact of Python's int/long distinction, which is
kinda strange to begin with. That's why they're getting unified:
http://www.python.org/dev/peps/pep-0237/
True, but Java also has this distinction.
I could do something similar, but it's quite complicated.
If Python is merging int and longs, then the work jcc's parseArgs() would
increase as every python integral number would have to be range-checked to
see if it fits in the java int or long box.
I'd also have to order overload checking so that the int check is run first.
This is the complicated part as types can't always be neatly ordered that
way.
Out of curiosity, could Java code call longToString() with an int? From what
little I remember of my C++ days, I thought this sort of widening-cast was
handled for you...
Of course, you can call longToString(36) in Java, the casting is done for
you, with maybe a warning along the way.
- it makes things slower by trying out more things than necessary
The joy of dynamic languages. From the Python programmer's perspective, the
only difference b/w int & long is when using isinstance() and the later has
an L on the end when repr()'d. This type of casting is really un-Pythonic; I
guess we'll have to get used to a little Java in our lives if it's a pain to
fix.
Actually, no, in python today, ints are limited to 32 bits, signed.
Python longs are limited by memory.
Andi..
_______________________________________________
pylucene-dev mailing list
[email protected]
http://lists.osafoundation.org/mailman/listinfo/pylucene-dev
