[Python-Dev] int/long FutureWarning

Mark Hammond mhammond@skippinet.com.au
Sat, 30 Nov 2002 09:28:53 +1100


[Martin]

> "Mark Hammond" <mhammond@skippinet.com.au> writes:
>
> > I am sure I am missing something, but I can't see it.  I am
> > ready to feel foolish <wink>.  It would certainly be easier
> > for me to work on such a strategy than to convert all my
> > extensions.

> It is a violation of the principle
>
> Errors should never pass silently.
> Unless explicitly silenced.

Ah-ha - elementary now you point it out <wink>

> If you have a function
>
>    my_account.add_amount_of_money(0x80000000L)
>
> and the implementation is a C function with an "i" converter, this
> currently gives an indication of the error. Under your proposed
> change, it would remove money from the account.

True.  But can you come up with a reasonable example?  A few of us have this
problem, and almost everyone has agreed that hex constants are generally
used in operations where the numeric value is not important, but the bit
pattern is.  I haven't seen a real example of where your scenario actually
exists - not to mention that any such code would have to be new (as that
constant does not work with "i" today) so therefore the author should use
the new correct type code!

I'm not sure if you are playing devil's advocate, or your contempt for our
problem is real?

> If we think that the case "large numbers are bitmaps" is more common
> than the case "large numbers are large numbers", we should drop the
> range check for the existing converters, and add new converters in
> case somebody wants large numbers instead of bitmaps, which then do
> the range checks.

No - no one is trying to say any of that at all.  The problem is simply
breaking existing code.  That code was *not* broken in the first place.  We
understand the rationale - just we also have lots of existing code.

[Jack]
> This would be ideal, of course. But note that for me changing the
> format char is a minor issue, as long as the behavior of the new
> format char is as expected
...
> But of course I don't know how this would be for Mark...

Well, I wouldn't be happy, but it wouldn't kill me, but would have to be a
semi-blind replace to keep me sane (Maybe I would just write a script to
convert all my .py files with hex constants to decimal - the bitwise ops
will still get me, but locating them may be OK.)  Of course, someone will
have to update PyXPCOM in the Mozilla tree, and any thing else using hex
constants in that way but not actively maintained may struggle and become
unavailable for a little while.  Plenty of extension authors not on
python-dev (including plenty of home-grown extensions taking win32con
constants, for example), and obviously I can't speak for them. And as Jack's
latest mail points out, supporting multiple versions of Python becomes
almost impossible.  The cost is real, and not able to be borne only by
people on this list.

Ultimately though, the end result is likely to be everyone just
mass-replaces "i" with "?" in any set of code where they *may* have the
problem - but carefully avoiding code where hex constants are passed as
currency values <wink>

Mark.