[pylucene-dev] Bug/JCC: NumberTools.longToString

[Andi Vajda]

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..