[issue30262] Don't expose sqlite3 Cache and Statement

Change by Berker Peksag : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: +Python 3.8 -Python 3.7 ___ Python tracker ___

[issue30262] Don't expose sqlite3 Cache and Statement

Berker Peksag added the comment: New changeset e6576248e5174ca5daa362cfd610c07e7eb3a2ae by Berker Peksag (Aviv Palivoda) in branch 'master': bpo-30262: Don't expose private objects in sqlite3 (GH-1440) https://github.com/python/cpython/commit/e6576248e5174ca5daa362cfd610c07e7eb3a2ae

[issue30262] Don't expose sqlite3 Cache and Statement

Alexey Izbyshev added the comment: Some additional motivation for removing Cache: it may be used to crash the interpreter (#31734). -- nosy: +izbyshev ___ Python tracker ___

[issue30262] Don't expose sqlite3 Cache and Statement

Aviv Palivoda added the comment: I opened a separate PR for the deprecation of the Cache and Statement. > I would think you could replace those entries with calls to wrapper functions > that issue the deprecation and then call the real function. I made wrapper deprecation classes that issue

[issue30262] Don't expose sqlite3 Cache and Statement

Changes by Aviv Palivoda : -- pull_requests: +1668 ___ Python tracker ___ ___

[issue30262] Don't expose sqlite3 Cache and Statement

R. David Murray added the comment: I don't do much with the C API, but since your goal is to remove them from the PyMODINIT_FUNC, I would think you could replace those entries with calls to wrapper functions that issue the deprecation and then call the real function. --

[issue30262] Don't expose sqlite3 Cache and Statement

Aviv Palivoda added the comment: I am not sure how to raise the deprecation waning in this case. We use both the Cache and Statement objects as part of the sqlite3 module internal flow. How can I only warn the user when he creates this classes directly and not when the sqlite3 module uses

[issue30262] Don't expose sqlite3 Cache and Statement

R. David Murray added the comment: They are not part of the API, that is why they are not documented. The convention of "always" using _ prefixed names for non-API stuff is (relatively) recent. It used to be we just didn't document the non-API stuff. Your second argument is a good

[issue30262] Don't expose sqlite3 Cache and Statement

Aviv Palivoda added the comment: I have 3 argument for the motivation for this change: 1. Cleaner API - Both objects are internal implementation details. I think that we can look on exposing them as a bug. 2. Easier development - When you remove these objects from the API you can change them

[issue30262] Don't expose sqlite3 Cache and Statement

R. David Murray added the comment: No, I'm arguing purely from a generic backward compatibility perspective. There does not seem to be me be sufficient benefit to removing them to justify doing it. -- ___ Python tracker

[issue30262] Don't expose sqlite3 Cache and Statement

Berker Peksag added the comment: > Someone somewhere may be using them for something, they've been around for a > long time. Well, you can use the same argument for every issue on the tracker. People can even rely on real bugs that are still open for 10 years, but that doesn't mean they

[issue30262] Don't expose sqlite3 Cache and Statement

R. David Murray added the comment: That's the same motivation, not a new one :) Someone somewhere may be using them for something, they've been around for a long time. I hope not, though. -- ___ Python tracker

[issue30262] Don't expose sqlite3 Cache and Statement

Berker Peksag added the comment: Even if users somehow managed to create Cache and Statement objects themselves, they are basically implementation details of the module and there is no way to use them to mess with the internal state of the module via using the current API (e.g.

[issue30262] Don't expose sqlite3 Cache and Statement

R. David Murray added the comment: Sorry, by "real motivation" I meant something beyond just cleaning up the API...that's a real motivation, it may just not be enough. -- ___ Python tracker

[issue30262] Don't expose sqlite3 Cache and Statement

R. David Murray added the comment: If these objects have been exposed in the past, we won't simply delete them. At a minimum there would need to be a deprecation period, but is there a real motivation for deleting them? -- nosy: +r.david.murray

[issue30262] Don't expose sqlite3 Cache and Statement

Changes by Aviv Palivoda : -- pull_requests: +1538 ___ Python tracker ___ ___

[issue30262] Don't expose sqlite3 Cache and Statement

New submission from Aviv Palivoda: Both the Cache and Statement objects are internally used and should not be exposed to the user from the sqlite3 module. They are not mentioned in the documentation as well. -- components: Extension Modules messages: 292936 nosy: berker.peksag,