Author palaviv
Recipients berker.peksag, ghaering, palaviv, r.david.murray
Date 2017-05-06.17:04:18
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1494090258.99.0.258711725158.issue30262@psf.upfronthosting.co.za>
In-reply-to
Content
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 without any concern. I for one think that I can make the sqlite3 module faster by changing them from Python objects to simple C structs.
3. Documentation - Currently both objects are part of the API. Thus they should be documented but how would you document the Statement class? Do we really want to have a generic Cache class in the sqlite3 module?

I have less experience with cpython then you. Do you think that maybe the Cache class should be moved to more appropriate place (maybe collections) and be used by others?

> At a minimum there would need to be a deprecation period, 

Is there a place that document the deprecation process? I will update the patch.
History
Date User Action Args
2017-05-06 17:04:19palavivsetrecipients: + palaviv, ghaering, r.david.murray, berker.peksag
2017-05-06 17:04:18palavivsetmessageid: <1494090258.99.0.258711725158.issue30262@psf.upfronthosting.co.za>
2017-05-06 17:04:18palavivlinkissue30262 messages
2017-05-06 17:04:18palavivcreate