hex(-5) => Futurewarning: ugh, can't we have a better hex than '-'[:n<0]+hex(abs(n)) ??

[Michael Peuser]

"Juha Autero" <Juha.Autero at iki.fi> schrieb im Newsbeitrag
news:mailman.1061182647.31076.python-list at python.org...
> Freddie <oinkfreddie at oinkshlick.oinknet> writes:
>
> >> There is a thread from this morning ("bitwise not ...") - this should
be an
> >> excellent contribution!
> >> I have no mercy with someone writing hex(-5)
> >>
> >> Kindly
> >> Michael P
> >>
> >>
> >
> > What about crazy people like myself? If you generate a crc32 value with
zib,
> > you occasionally get a negative number returned. If you try to convert
that
> > to hex (to test against a stored CRC32 value), it spits out a
FutureWarning
> > at me.
>
> Read the thread about bitwise not. Tell Python how many bits you
> want. In case of CRC32 that is of course 32 bits:
> hex(-5&2**32-1)
>
> Two questions: What is the best way to generate bitmask of n bits all
> ones?

Why do you object to 2**n-1? This is just fine I think.

> And would sombody explain why hexadecimal (and octal) literals
> behave differently from decimal literals? (see:
> http://www.python.org/doc/current/ref/integers.html ) Why hexadecimal
> literals from 0x80000000 to 0xffffffff are interpetred as negative
> numbers instead of converting to long integers?

Most of all this has practical reasons because of the use most programmers
have for stating hexadecimal literals.

Of couse some hex literals are not interpreted as negative numbers but the
memory contents, because it has become undistinguishable what the origin had
been.

One will not expect
        print int(0xffffffff )
do something different from
        x=0xffffffff
        print int(x)

Kindly
Michael P
>
> --
> Juha Autero
> http://www.iki.fi/jautero/
> Eschew obscurity!
>
>