Log in

No account? Create an account

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.

Tue, Apr. 19th, 2011 12:46 am (UTC)
hollowaynz: Trailing colons - an unnecessary hassle?

This is a syntax change rather than a feature change and if it results in some ambiguity then I'd appreciate it if someone could explain why, but with if/for/while(etc) blocks I don't understand why they don't ditch the trailing ":" character and instead use whitespace, e.g.
if True:
becomes simply,
if True
The : doesn't seem to add anything for the compiler, and in the rare case that you want to do it on the same line then you could use ";" which is more consistant anyway (you can already put multiple lines of Python on a single line with ";"). E.g.
if True; pass
So is there anything wrong about this approach? I'm not so much interested in whether it's impractical to change legacy code (I agree but that could be said of many syntactic changes) and I was more wondering whether there are reasons why Python shouldn't have had that syntax since day one.