Python doesn't have a formal distinction between private and protected class members. Even the distinction between private and public is pretty weak, since anything can be accessed if a user tries hard enough. If a private versus protected distinction would make sense for your application, you can simply document that _foo
(or foo
) is not part of the public user interface, but can be relied upon by subclasses to always have certain semantics. (What those semantics are is up to you.)
Now, I don't know if it's really worth the documentation effort to do this for a simple read-only property (the function call overhead is likely not too bad, so subclasses can just use the property like everyone else). However, if you had a property that was doing a lot more work, like a database query or HTTP request, it might make some sense for the internals to be exposed a bit for subclasses to get at just the parts they need.
If you do think that exposing the "protected" value is desirable, the only question is whether you should put the underscore in front of the variable name or not. The underscore has a few effects on things like dir
and perhaps in documentation generating tools, but it doesn't change anything about how the code runs.
So it's really an issue of code style, and it really doesn't matter much either way. You can either leave the underscore off and put big warning text in the documentation so that users know they shouldn't be messing with the internals, or you could use the underscore and silence the pylint warnings (and if necessary, force there to be some extra docs for subclass implementors).