RELEASED Python 2.3 (final)
bokr at oz.net
Thu Jul 31 20:55:40 CEST 2003
On Thu, 31 Jul 2003 12:09:09 +0100, Robin Becker <robin at jessikat.fsnet.co.uk> wrote:
>I've been testing reportlab with 2.3 and although it's a lot faster I
>get some ominous warnings and complaints from the future.
>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.
I don't know of one, but sometimes I've wanted a way to filter sequence unpacking, e.g,
a,*,c = 1,2,3 # <=> a=1; c=3
and maybe letting ** in the tail position mean dump the rest.
>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?
> We have quite a lot of code that deals with low level binary
> formatted stuff. Changing will move it further away from the
> original C definitions.
How about just defining a C integer class that works as desired?
You could do it in C ;-)
> 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)
> Is Python moving away from the machinery? Are there efficient
> recipes for doing these 32 bit operations? Certainly cut and
> paste to and from java/c/c++ will be a lot harder.
IWT a C extension could be quite efficient. The question would be how
to minimize the editing for cut/pasted stuff. Mostly I guess it would
be wrapping C literals so x = 0x80000000 becomes x = Cint('0x80000000') or such.
>Apart from these minor troubles seems pretty solid.
More information about the Python-list