
On Mon, Jan 11, 2016 at 05:18:59AM -0500, Neil Girdhar wrote:
Here is where I have to disagree. I hate it when experts say "we'll just document it and then it's the user's fault for misusing it". Yeah, you're right, but as a user, it is very frustrating to have to read other people's documentation. You know that some elite Python programmer is going to optimize his code using this and someone years later is going to scratch his head wondering where __version__ is coming from. Is it the provided by the caller? Was it added to the object at some earlier point?
Neil, don't you think you're being overly dramatic here? "Programmer needs to look up API feature, news at 11!" The same could be said about class.__name__, instance.__class__, obj.__doc__, module.__dict__ and indeed every single Python feature. Sufficiently inexperienced or naive programmers could be scratching their head over literally *anything*. (I remember being perplexed by None the first time I read Python code. What was it and where did it come from? I had no idea.) All those words for such a simple, and minor, point: every new API feature is one more thing for programmers to learn. We get that. But the following is a good, strong argument:
Also, using this __version__ in source code is going to complicate switching from CPython to any of the other Python implementations, so those implementations will probably end up implementing it just to simplify "porting", which would otherwise be painless.
Why don't we leave exposing __version__ in Python to another PEP? Once it's in the C API (as you proposed) you will be able to use it from Python by writing an extension and then someone can demonstrate the value of exposing it in Python by writing tests.
I can't really argue against this. As much as I would love to play around with __version__, I think you're right. It needs to prove itself before being exposed as a public API. -- Steve