RELEASED Python 2.3 (final)

[Ben Finney]

On Thu, 31 Jul 2003 12:09:09 +0100, Robin Becker wrote:
> 1) SyntaxWarning: assignment to None
>    eg for None, name in colorNamePairs:
>    what is the preferred way to do this nowadays? It's fairly
>    trivial to go through and change these to for notUsed, x in ....
>    but is there a nicer way.

Seems nice enough.  You'll only be able to assign to a mutable object
anyway; None is not mutable, and will soon be a keyword.  Define (or
just go ahead and use) your own not_used name.

> 2) FutureWarning: hex/oct constants > sys.maxint will return positive  
>    values in Python 2.4 and up
>    eg self.assertEquals(ttf.read_ulong(), 0x81020304) # big-endian
>    Is there no way to preserve the clarity of the above in future?

Declare large positive constants as being longs:

    >>> foo = 0xFFFFFFFF
    <stdin>:1: FutureWarning: hex/oct constants > sys.maxint will return positive values in Python 2.4 and up
    >>> foo
    -1

    >>> foo = 0xFFFFFFFFL
    >>> foo
    4294967295L

You probably want the numbers to behave as positive anyway.

>    The same applies to
> 
>    FutureWarning: x<<y losing bits or changing sign will return a long 
>    in Python 2.4 and up
>    eg sum = (hi << 16) | (lo & 0xFFFF)

Same answer applies too:

    >>> hi = 0xDEAD
    >>> lo = 0xBEEF
    >>> sum = ( hi << 16 ) | ( lo & 0xFFFF )
    __main__:1: FutureWarning: x<<y losing bits or changing sign will return a long in Python 2.4 and up>>> sum
    -559038737

    >>> hi = 0xDEADL
    >>> lo = 0xBEEFL
    >>> sum = ( hi << 16 ) | ( lo & 0xFFFF )
    >>> sum
    3735928559L

If you want to deal consistently (across Python versions) with numbers
larger than sys.maxint, whether decimal, hex or octal, ensure you set
them up as longs to begin with.

> Is Python moving away from the machinery?

I don't see why not; fiddling with low-level bits is pretty
architecture-dependent, as these hacks show.  If you want C, you know
where to find it.

> Are there efficient recipes for doing these 32 bit operations?

Hopefully you'll agree the solutions I've presented are just as
"efficient", even if they expose the bit-fiddling hackery somewhat more.

> Certainly cut and paste to and from java/c/c++ will be a lot harder.

I've never known that to be a priority for Python.

-- 
 \     "I went to a restaurant that serves 'breakfast at any time'. So |
  `\        I ordered French Toast during the Renaissance."  -- Steven |
_o__)                                                           Wright |
Ben Finney <http://bignose.squidly.org/>