On Wed, May 29, 2013 at 8:37 PM, Steven D'Aprano
The loss of backwards compatibility makes this a Python 4000 idea.
Definitely this was against a hypothetical SQL API, showcasing its benefit. One could replace it with, for example, a templating library. Then the risk that is mitigated is accidental XSS vulnerabilities, rather than accidental SQL injection vulnerabilities. Templating libraries are far more common, and non-standard, so they can make this change more easily than the DB-API can.
But putting that aside, it has to be a built-in type only accessible as a literal, because if it is a function that takes a string argument, say, sql(), then you'll have exactly the same issue.
What's the problem with that? If the registry of prefix transformers is kept private by Python, then it's not easy at all to retrieve a function from that registry (although you can do it via ctypes). You can delete any references to the function that are not in the registry, and this is effectively hidden without crazy ctypes magic. And then, because this is Python, you can also add an unsafe API for users that need the flexibility and are aware of the security implications. The point isn't to make insecure code impossible -- that itself is impossible. But it'd be nice to make it obvious, when it's being done, that it is in fact insecure.
Given that Python is a language which allows the programmer to shoot themselves in the foot if they so choose, I'm not really so sure that even in Python 4000 we should be going to extraordinary efforts to prevent *this specific* toe from being shot off.
There are many instances where Python does try to protect people from shooting themselves in the foot (for example, immutable tuples*). But anyway, I think it's a little callous to dismiss at all the idea of protecting people from security-related problems. It's not programmers' feet I'm worried about. When programmers make security-related mistakes, the people that suffer are their users. It's not as if it's only a little suffering, either. It can be a lot of suffering. And I see this mistake very, very often. If adding this feature would enable better APIs in the future, that prevented pain in the future... maybe that prevented pain would outweigh the effort spent adding and maintaining yet another feature to Python, and any pain of additional work ("with unsafe"). If the only reason not to do it is a philosophical objection to helping people help themselves, then I think that philosophy should be ignored. -- Devin .. [*] The wound being prevented is that tuples could be hashable and mutable, but if they were placed inside a dict or set, and mutated in such a way that their hash changed, their bucket would not change. This makes them pseudo-invisible. A similar (but different) thing happens if you insert NaN, but Python does not protect you there. Of course, nothing is impossible when you use ctypes...