Deprecate PEP 249 (DB-API 2.0)

Then make it, don’t try to talk about the deprecation of a perfectly good protocol.

Remember: Onus is not on us to prove that the existing system is good enough, Onus is on you to prove that it isn’t.

1 Like

we stg if it’s 2am and you can write execute(f"some {bad} shit") the language’s a failure.

a language that doesn’t protect you from being tired (or more commonly, overworked) is not a language worth using. rather, it’s a liability.

Okay. Go find yourself a language that stops you from doing anything dangerous. Meanwhile, I’ll keep using languages with actual power.

I’m done talking about this. Maybe go post about this on social media, that’s the right sort of vacuous echo chamber for this sort of proposal.

1 Like

You are just being needlessly hyperbolic at this point.

5 Likes

The logic for blocking raw SQL could also be applied to say that python shouldn’t let you try to shutil.rmtree(..) a critical system directory.

Like the same logic could say only allow rmtree to be called against a list of good paths. It’s honestly ridiculous.

Maybe we should also remove pathlib.Path because it could be used to read a file that we didn’t intend to be read.

Maybe subprocess.call should block specific executables from being called because they may do something unexpected.

The point is: You can’t inject ‘correct intent checking’ at the language level.

If you don’t like being able to execute sql code via a string, write your own lib that disallows it, post on pypi and come back if it has an overwhelming usage spike. I doubt it would but I guess I could be wrong.

3 Likes

the logic is that you should write sql like you write python

now, if you were to use python like you use sql… by storing it in strings and semi-regularly building it up at runtime… maybe we’d be willing to change our mind.

You can write it any way you want today. Your opinion of what is more secure is an opinion. Apply it in your own code and packages.

To me: It’s nonsensical.

Why even allow package resources for SQL strings if I can inject them there? You’re making it more difficult to do wrong and right things. May as well just get rid of all inserts while we’re at it.

Honestly your idea of security here is misguided.

Once again: write your own sql package, post it on pypi, see how it goes.

edit: I don’t think there is a need to change your mind, no point. Either way I don’t think any core dev would sponsor this change.

2 Likes

Not to mention everyone like me that is screaming “over my dead body.” The amount of production systems in my business this proposal would break is staggering.

1 Like

Closing as the answer here is clearly no, and we don’t need more rehashing of that given the aggressiveness of some of the responses.