It was actually fixed in Python 3.4 with the switch to use SipHash, as the randomization introduced in Python 3.3 was still susceptible to some attacks. See https://www.python.org/dev/peps/pep-0456/
A proper security fix can only be to fix the collision resolution, never using a slower hash function. It's also 10x faster then.
Almost nobody does. For normal power-of-2 hash tables finding collisions in the lowest bits leading to a successful amplification is trivial by brute-force. Since Siphash is so slow it can last up to 4 minutes, for smaller tables still < 5s.
Which you do as an attacker by… asking politely? Or is it easy to leak the seed by accident?
In other news, there’s a relatively low-cost attack on AES when you know the key.
With static languages it's still easy when you got enough information: source code, timing info and ordering (e. g JSON). With a proper SAT solver doable.
Leaking by accident is e.g even more trivial in perl, just set a magic ENV var. But peeking the fixed offset is easiest.
It's all just security theatre. There's no real use-case for something so slow as Siphash.
while True: pass