How to get rid of FutureWarning: hex/oct constants...

[Grant Edwards]

How do I get rid of the following warning?

<path>.py:233: FutureWarning: hex/oct constants > sys.maxint will return positive values in Python 2.4 and up
fcntl.ioctl(self.dev.fileno(),0xc0047a80,struct.pa ck("HBB",i,0,0))

I tried using 0xc0047a80L. That got rid of the warning, but
then I got an exception when fcntl.ioctl() was called because
the long int was too large to be converted to an int.

--
Grant Edwards grante Yow! I'm losing my
at hair...did it go to
visi.com ATLANTIC CITY??

[Terry Reedy]

"Grant Edwards" <gr****@visi.com> wrote in message
news:11*************@corp.supernews.com...

How do I get rid of the following warning?
Switch to 2.4? Or is there a command line switch to do so?
<path>.py:233: FutureWarning: hex/oct constants > sys.maxint will return
positive values in Python 2.4 and up

TJR

[Grant Edwards]

On 2005-03-25, Terry Reedy <tj*****@udel.edu> wrote:

"Grant Edwards" <gr****@visi.com> wrote in message
news:11*************@corp.supernews.com...

How do I get rid of the following warning?

Switch to 2.4? Or is there a command line switch to do so?

Too much work. I'd have to go upgrade a half-dozen machines. I
guess I'll just live with the warning. It sort of sucks that
you get warned about something which you can't fix.

<path>.py:233: FutureWarning: hex/oct constants > sys.maxint will return
positive values in Python 2.4 and up

--
Grant Edwards grante Yow! I'm CONTROLLED by
at the CIA!! EVERYONE is
visi.com controlled by the CIA!!

[Peter Hansen]

Grant Edwards wrote:

Too much work. I'd have to go upgrade a half-dozen machines. I
guess I'll just live with the warning. It sort of sucks that
you get warned about something which you can't fix.

I'm pretty sure you can disable warnings in the warnings
module. Check the docs or archives.

-Peter

[Bengt Richter]

On Thu, 24 Mar 2005 23:21:39 -0000, Grant Edwards <gr****@visi.com> wrote:

How do I get rid of the following warning?

<path>.py:233: FutureWarning: hex/oct constants > sys.maxint will return positive values in Python 2.4 and up
fcntl.ioctl(self.dev.fileno(),0xc0047a80,struct.pa ck("HBB",i,0,0))

I tried using 0xc0047a80L. That got rid of the warning, but
then I got an exception when fcntl.ioctl() was called because
the long int was too large to be converted to an int.

Lobby for a PEP for numeric literals allowing representation
of negative numbers without writing a unary minus expression.
E.g.,
16xfc0047a80
would be explicitly negative and would not overflow 32-bit representation.
The corresponding positive value
16x0c0047a80
would overflow, of course, which would be proper.

Some discussion, including analogous spellings for other bases:

http://groups-beta.google.com/group/...3131df1e919435

In the meantime, maybe (ugh):

Python 2.3.2 (#49, Oct 2 2003, 20:02:00) [MSC v.1200 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.

-2*0x40000000+0x40047a80 -1073448320 hex(-2*0x40000000+0x40047a80)

__main__:1: FutureWarning: hex()/oct() of negative int will return a signed string in Python 2.4
and up
'0xc0047a80'

That "signed string" is a unary minus expression using an absolute value forced by the inadequacy
of the literal representation syntax.
IOW, IMO '-' + hex_literal_of(abs(x)) is not a decent hex_literal_of(-x) !!
Urk and argh...

Regards,
Bengt Richter

[Bengt Richter]

On Fri, 25 Mar 2005 03:35:29 GMT, bo**@oz.net (Bengt Richter) wrote:

On Thu, 24 Mar 2005 23:21:39 -0000, Grant Edwards <gr****@visi.com> wrote:

How do I get rid of the following warning?

<path>.py:233: FutureWarning: hex/oct constants > sys.maxint will return positive values in Python 2.4 and up
fcntl.ioctl(self.dev.fileno(),0xc0047a80,struct.pa ck("HBB",i,0,0))

I tried using 0xc0047a80L. That got rid of the warning, but
then I got an exception when fcntl.ioctl() was called because
the long int was too large to be converted to an int.

Lobby for a PEP for numeric literals allowing representation
of negative numbers without writing a unary minus expression.
E.g.,
16xfc0047a80
would be explicitly negative and would not overflow 32-bit representation.
The corresponding positive value
16x0c0047a80
would overflow, of course, which would be proper.

Some discussion, including analogous spellings for other bases:

http://groups-beta.google.com/group/...3131df1e919435

In the meantime, maybe (ugh):

Python 2.3.2 (#49, Oct 2 2003, 20:02:00) [MSC v.1200 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.

-2*0x40000000+0x40047a80 -1073448320 hex(-2*0x40000000+0x40047a80) __main__:1: FutureWarning: hex()/oct() of negative int will return a signed string in Python 2.4
and up
'0xc0047a80'

That "signed string" is a unary minus expression using an absolute value forced by the inadequacy
of the literal representation syntax.
IOW, IMO '-' + hex_literal_of(abs(x)) is not a decent hex_literal_of(-x) !!
Urk and argh...

I guess you could make a convenience function to convert long literals to signed i32:

def i32(x): return (x&0x80000000L and -2*0x40000000 or 0) + int(x&0x7fffffff) ... i32(0xc0047a80L)

-1073448320

so you can use i32(0xc0047a80L) where old python accepted 0xc0047a80

Regards,
Bengt Richter

[Martin v. Löwis]

Bengt Richter wrote:

>>> hex(-2*0x40000000+0x40047a80)

__main__:1: FutureWarning: hex()/oct() of negative int will return a signed string in Python 2.4
and up
'0xc0047a80'

That "signed string" is a unary minus expression using an absolute value forced by the inadequacy
of the literal representation syntax.
IOW, IMO '-' + hex_literal_of(abs(x)) is not a decent hex_literal_of(-x) !!

This has been discussed over and over, but since you bring it up again:

There are no hex literals for negative numbers, just as there are no
decimal literals for negative number. A literal, by nature, in any
base, is non-negative.

If you disagree: Is 0xFFF6 a positive or a negative number?

Regards,
Martin

[Bengt Richter]

On Sun, 27 Mar 2005 12:48:46 +0200, =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= <ma****@v.loewis.de> wrote:

Bengt Richter wrote:

>>> hex(-2*0x40000000+0x40047a80) __main__:1: FutureWarning: hex()/oct() of negative int will return a signed string in Python 2.4
and up
'0xc0047a80'

That "signed string" is a unary minus expression using an absolute value forced by the inadequacy
of the literal representation syntax.
IOW, IMO '-' + hex_literal_of(abs(x)) is not a decent hex_literal_of(-x) !!

This has been discussed over and over, but since you bring it up again:

It seems you have a different concept of "this" than I ;-)
There are no hex literals for negative numbers, just as there are no
decimal literals for negative number. A literal, by nature, in any
base, is non-negative.
You are talking about what _is_, not what _can be_ ;-)

IMO a literal is a source-context-compatible string representing an abstract value
(which typically has an alternate representation in the running-program context).

AFAIK there is no law against representing negative numbers as such with whatever
literal spellings are deemed useful.
If you disagree: Is 0xFFF6 a positive or a negative number?

That is conventionally a positive number, because the python 2.4 hex syntax
is interpreted that way, as it should be now. With a leading 16x prefix instead of 0x
the rules would/could change. See below.

I am trying to propose an alternate (additional, not replacement) syntax, which
you could call base-complement. The base is specified by a prefixed <base>x where
<base> is encoded in decimal. Zero is not a legal base, so there is no problem
recognizing current hex literals.

The digits following <base>x result from the numeric value's being encoded with
the base radix, and the most significant _must_ be zero or base-1 and may be repeated
leftwards as far as desired without changing the value, which is computed by something like:

For digits on the right side (following the <base>x):

def bcdecode(s, B=10, digits='0123456789abcdefghijklmnopqrstuvwxyz'): ... if s == digits[0]: return 0
... acc = s[0].lower() == digits[B-1] and -B**len(s) or 0
... for i, c in enumerate(s[::-1]):
... acc += digits.index(c)*B**i
... return acc
...

For the whole literal (which you need, unless you are assuming you know the base
and that first digits are sign or sign leftwards-replications according to base-complement convention)
def blitdec(s): ... xpos = s.lower().index('x')
... base = int(s[:xpos])
... return bcdecode(s[xpos+1:], base)
... blitdec('2x011') 3 blitdec('2x00000011') 3 blitdec('2x101') -3 blitdec('2x11111101') -3 blitdec('16x0fff6') 65526 blitdec('16xffff6') -10 hex(blitdec('16x0fff6')) '0xfff6' hex(blitdec('16xffff6')) '-0xa'
Urk! ;-/
For backwards compatibility, hex will have to do that, but there IMO there should be
a base-complement output format available too, so e.g., (to give it a name)
baselit(blitdec('16xffff6'), 16) => '16xf6' #(normalized to single sign digit unless explicitly formatted)

BTW, blitdec('8x03') 3 blitdec('8x73') -5 blitdec('10x03') 3 blitdec('10x93') -7

The point is a bit-visualization-friendly literal representation (when desired,
and for which you'd normally use base 2, 8, or 16 ;-) of all integers.

And also it could be nice to be able to write (impossible now) compiler.parse('x=16xffff6','single')

and get
Module(None, Stmt([Assign([AssName('x', 'OP_ASSIGN')], Const(-10))]))

instead of (the result of what you have to write now)
Module(None, Stmt([Assign([AssName('x', 'OP_ASSIGN')], UnarySub(Const(10)))]))
BTW, I see the code above needs some cleaning and another .lower() or two
but I am too lazy to fix or optimize, and the corresponding
literal-formatting code is left as an exercise ;-)

Regards,
Bengt Richter

[J Correia]

Assuming you're just trying to get rid of the message each time the program
runs, the following suppresses it:

import warnings
warnings.filterwarnings('ignore', category=FutureWarning)
HTH,