Thu, Apr. 14th, 2011, 05:34 pm
Python wish list
Now that the moratorium on Python language features is over, I'll put in my thoughts on what new stuff the language could use. I don't have much to suggest, and what I do have to suggest is fairly minor. This is because I'm happy with the language.
- new on default parameters
- One of the gotchas in python is that default parameters are reused, so if you say:
def spam(eggs = ):
then eggs will get set to the same list every time, and modifications will get carried over between calls. This can be hacked like this:
def spam(eggs = None):
if eggs is None:
eggs = 
This works, but is ugly, and prevents passing in None as a value for eggs. It would be better to be able to simply say:
def spam(eggs = new ):
which should do exactly what you expect.
- ^ on bytes
- A strange oversight in Python3 is that bitwise operators don't work on byte arrays. The ^, & and | operators should work on bytes of equal length, doing exactly what they obviously should. Trying to apply them to bytes of unequal length should probably result in an error. It's easy enough to write functions to do these things, but they're slow, and there's only one reasonable semantics for what those operators should do on byte arrays anyway.
- raw binary conversion
- Maybe this has been added to the standard library and I just haven't heard about it, but a longstanding annoying missing piece of functionality is simple conversion between ints and big or little endian representations of them as bytes. Again, this is easy enough to implement, but is slow when done in Python and is hardly an obscure piece of functionality.
- dictionary scrambling
- This might be an obscure piece of functionality, but I'd like the ability to change the hashing function which dictionaries use, because I write tests which depend on my code behaving the same way every time it's run, and I'd like to be able to test that it doesn't have any dependencies on the order of iterating over dictionary keys or values.
Fri, Apr. 15th, 2011 07:21 am (UTC)
The table for the format characters seems clear enough?
Fri, Apr. 15th, 2011 04:32 pm (UTC)
Until you've gone through some examples, it's very opaque, and it really, really, would be nice if it clarified whether int sizes might be different on different platforms.
Fri, Apr. 15th, 2011 06:46 pm (UTC)
The docs really could be better (I use struct constantly, and it took me ages to realize that you can give a repetition count like "<4I"), but at least the current docs do say explicitly that if you use the 'native mode' indicator ("@", which is default), then you get whatever sizes and alignment the C compiler would use for a C struct with the given fields, and if you use one of the standardized modes ("<", ">", "=", "!") then you get the usual int sizes (and no padding) regardless of platform. So "@" is how you talk to poorly-written C code, and for network protocols or well-written binary formats you use "<" or ">".