Message160276
| 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. |
|