Sorry to harass the hn community over this one more time, but does anyone knows if optional static typing is even being discussed as a future evolution for python ?
I know about the pep for annotations that could be used for that ( but in a non standardized way ), i know about the mypy project ( which seems like a one man project), but is that all ?
Well there is Cython, which is compatible with your every day python, but it might not be what you're looking for. Rpython has some type inference, but it's designed exclusively to be used to make interpreters; no standard libraries or anything.
Personally I think the most amazing and practical (but possibly difficult) thing to do is to add global type inferencing (Hindley–Milner?) to (a fork of?) Jython.
There's also python-like languages with static typing already like boo: http://boo.codehaus.org/
> Sorry to harass the hn community over this one more time, but does anyone knows if optional static typing is even being discussed as a future evolution for python ?
there's also pytyp, which is pure-python (inefficient) but integrates with ABCs as well as annotations. no-one uses it, as far as i know, but i thought i'd throw it out there in case you were interested - http://www.acooke.org/pytyp/
i also have a vague memory of there being discussions on the python ideas list (which i don't read regularly). you might look there.
They still list SHA-3 as one of the features, even though the standard isn't released yet, and it will surely change details from the keccak submission (has been hinted at several conferences).
By introducting functions like `sha3_256` they are setting themselves up for a big compatibility fiasco.
I cannot conceive of the world in which substantive changes would be made between now and publication. The algorithm has been vetted as-is, any changes would need extensive reevaluation. It would basically be starting the process over.
It's not substantive changes, but any change is enough to change compatibility. If you doubt me, go to the NIST website for SHA-3 standardization and check out the conference talks they linnk to.
I didn't realize they hadn't selected final parameters yet. I guess I blindly assumed they wouldn't be so reckless as to run the clock down this far. Another reason not to trust NIST's judgement.
Nonetheless, you're still panicking over nothing. 3.4.0 won't be released until next year.
I don't understand why it would be a bad thing for them to take their time to make the standard as good as possible. It's going to live for pretty long.
They're doing the exact opposite. They chose an underspecified "winner". The public vetting period for what actually becomes SHA-3 will now be a mere 90 days.
It didn't make the cut for the first alpha, but it is still slated for inclusion in 3.4. The release schedule, including other candidate features, is at http://www.python.org/dev/peps/pep-0429/
In my opinion, the enum module will do very little to improve your life. It uses a great deal of machinery to solve a somewhat shallow problem.
Yes, there will be a few cases when it will improve code and help manage complexity. But it introduces its own complexities as well (i.e. learning two distinct enumeration types, serialization issues, etc).
One example of an unexpected complication is the effect on serialization. Python is having to change (and slow down) its JSON module just to accommodate integer enums (http://bugs.python.org/issue18264). Third-party modules will need to adapt as well. Another example is the awkward __module__ attribute that you will need to support pickles.
That said, the real issue is that for many everyday needs, it is hard to beat the simplicity of what people were already doing. For example, sometime you only need a couple of constant references into list positions: PREV=1; NEXT=2; link_next[PREV] = link_prev[NEXT]. Or you need a handful of self-describing constants that can be compared for equality: ROUND_DOWN = 'ROUND_DOWN'; ROUND_UP = 'ROUND_UP'. Both of these examples were taken from code in the standard library. Both work just fine and do not need any of the high-powered machinery in the enum module.
Once in a while, having an enum will be nice, but you can expect people to go wild with it and use them everywhere. This will churn your code without producing any visible benefit for end users. Just as with PEP 8, the enum module will attract fools like moths to a flame.
Do yourself a favor and don't push for enums to be used everywhere. Show restraint and save them for cases like the socket module where we really did need a way to manage the menagerie of constants.
