This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author lars.gustaebel
Recipients amaury.forgeotdarc, barry, cjwatson, eric.araujo, lars.gustaebel, pitrou, python-dev, r.david.murray, terry.reedy
Date 2012-05-09.11:44:30
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1336563871.02.0.794138940424.issue13815@psf.upfronthosting.co.za>
In-reply-to
Content
In an earlier draft of my patch, I had kept ExFileObject as a subclass of BufferedReader, but I later decided against it. To use BufferedReader directly is in my opinion the cleaner solution.

I admit that the change is not fully backward compatible. But a user can still write code that works for both 3.3 and the versions before. If he didn't subclass ExFileObject his code doesn't even need a change. If he subclassed ExFileObject, he might have a problem in either case: either the ExFileObject class is missing, or he may be unable to use it the way he did before, because all that's left of it is a stub subclass of BufferedReader.

I am well aware that backward compatibility is most important, but I think it must still be allowed to change internal (and undocumented) APIs every now and then to clean things up a little.
And of course, I did a code search before too, and found no code using ExFileObject. This actually doesn't surprise me, as there is really not much you can do with it.
History
Date User Action Args
2012-05-09 11:44:31lars.gustaebelsetrecipients: + lars.gustaebel, barry, terry.reedy, amaury.forgeotdarc, pitrou, cjwatson, eric.araujo, r.david.murray, python-dev
2012-05-09 11:44:31lars.gustaebelsetmessageid: <1336563871.02.0.794138940424.issue13815@psf.upfronthosting.co.za>
2012-05-09 11:44:30lars.gustaebellinkissue13815 messages
2012-05-09 11:44:30lars.gustaebelcreate