[pylucene-dev] Bug/JCC: NumberTools.longToString
pfein at pobox.com
Thu Nov 15 17:17:55 PST 2007
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.
> I could make the argument parsing more leniant but this comes with two
> - it makes it ambiguous: if there were two java methods called
> longToString(), one taking a long and one taking an int, making the
> long one accept int would cause the wrong method to be called if long is
> checked before int.
> Sure, I could, in some cases, determine the right order for checking
> overloads (check int before long since long is wider) but this gets
> pretty complicated.
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:
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...
> - 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
> If you want to call longToString(36), use longToString(36L) and all is
Well, I'm calling it with a variable, and I can wrap it in long().
Peter Fein || 773-575-0694 || pfein at pobox.com
http://www.pobox.com/~pfein/ || PGP: 0xCCF6AE6B
irc: pfein at freenode.net || jabber: peter.fein at gmail.com
More information about the pylucene-dev