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 > problems: > > - 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: http://www.python.org/dev/peps/pep-0237/ 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 fix. > If you want to call longToString(36), use longToString(36L) and all is > good. Well, I'm calling it with a variable, and I can wrap it in long(). -- Peter Fein || 773-575-0694 || [EMAIL PROTECTED] http://www.pobox.com/~pfein/ || PGP: 0xCCF6AE6B irc: [EMAIL PROTECTED] || jabber: [EMAIL PROTECTED] _______________________________________________ pylucene-dev mailing list [email protected] http://lists.osafoundation.org/mailman/listinfo/pylucene-dev
