PEP 526: why ClassVar instead of ClassAttr?
Since PEP 526 is already provisionally accepted, it may be too late to bring this up, but I have a question and suggestion about the name ClassVar. I've read the PEP but didn't see an answer or rejection to this.
https://www.python.org/dev/peps/pep-0526/
Why choose ClassVar over ClassAttr when the usual terminology used in the Python community is class and instance *attributes* rather than "variables"?
I understand that, in a sense, attributes are variables (unless they're constants *wink*) but the term "class variable" sounds very Java-esque rather than Pythonic. And it is an uncomfortable fit with a language like Python where classes are first class values like ints, strings, floats etc:
- we talk about a string variable meaning a variable holding a string; - a float variable is a variable holding a float; - a list variable is a variable holding a list; - so a class variable ought to be a variable holding a class.
I get the intention: we have local, global, instance and class variables. But I feel that grouping instance/class with local/global is too abstract and "computer sciencey": in practice, instance/class vars are used in ways which are different enough from global/local vars that they deserve a different name: attributes, members or properties are common choices.
(Python of course uses attributes, and properties for a particular kind of computed attribute.)
This introduces split terminology: we now talk about annotating class attributes with ClassVar. Since there's no GlobalVar, NonLocalVar or LocalVar, there doesn't seem to be any good reason to stick with the FooVar naming system.
Can we change the annotation to ClassAttr instead?
It's "class variable" because we (at least I) also routinely use "instance variable".
On Tue, May 16, 2017 at 4:23 PM, Steven D'Aprano steve@pearwood.info wrote:
Since PEP 526 is already provisionally accepted, it may be too late to bring this up, but I have a question and suggestion about the name ClassVar. I've read the PEP but didn't see an answer or rejection to this.
https://www.python.org/dev/peps/pep-0526/
Why choose ClassVar over ClassAttr when the usual terminology used in the Python community is class and instance *attributes* rather than "variables"?
I understand that, in a sense, attributes are variables (unless they're constants *wink*) but the term "class variable" sounds very Java-esque rather than Pythonic. And it is an uncomfortable fit with a language like Python where classes are first class values like ints, strings, floats etc:
- we talk about a string variable meaning a variable holding a string;
- a float variable is a variable holding a float;
- a list variable is a variable holding a list;
- so a class variable ought to be a variable holding a class.
I get the intention: we have local, global, instance and class variables. But I feel that grouping instance/class with local/global is too abstract and "computer sciencey": in practice, instance/class vars are used in ways which are different enough from global/local vars that they deserve a different name: attributes, members or properties are common choices.
(Python of course uses attributes, and properties for a particular kind of computed attribute.)
This introduces split terminology: we now talk about annotating class attributes with ClassVar. Since there's no GlobalVar, NonLocalVar or LocalVar, there doesn't seem to be any good reason to stick with the FooVar naming system.
Can we change the annotation to ClassAttr instead?
-- Steve _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
On Tue, May 16, 2017 at 10:10 PM, Guido van Rossum guido@python.org wrote:
It's "class variable" because we (at least I) also routinely use "instance variable".
It is `getattr()`, `setattr()`, and a very long etc. in Python.
I agree with the OP that a sudden talk about "vars" is confusing, more so when Python doesn't have "vars", but "names" (etc.).
Cheers!
There was another reason too. Many things are "class attributes" e.g. methods, descriptors. But only specific things are class *variables*. Trust me, we debated this when the PEP was drafted. ClassVar is better than ClassAttr.
On Tue, May 16, 2017 at 7:54 PM, Juancarlo Añez apalala@gmail.com wrote:
On Tue, May 16, 2017 at 10:10 PM, Guido van Rossum guido@python.org wrote:
It's "class variable" because we (at least I) also routinely use "instance variable".
It is `getattr()`, `setattr()`, and a very long etc. in Python.
I agree with the OP that a sudden talk about "vars" is confusing, more so when Python doesn't have "vars", but "names" (etc.).
Cheers!
-- Juancarlo *Añez*
On Tue, May 16, 2017 at 10:11:31PM -0700, Guido van Rossum wrote:
There was another reason too. Many things are "class attributes" e.g. methods, descriptors. But only specific things are class *variables*.
Ah, that's a good reason. I can live with that.
Thanks for the explanation.
On 17 May 2017 at 19:03, Steven D'Aprano steve@pearwood.info wrote:
On Tue, May 16, 2017 at 10:11:31PM -0700, Guido van Rossum wrote:
There was another reason too. Many things are "class attributes" e.g. methods, descriptors. But only specific things are class *variables*.
Ah, that's a good reason. I can live with that.
In the specific context of type hints, there is also https://docs.python.org/3/library/typing.html#typing.TypeVar, which is used to indicate that particular variable name refers to a type variable for generics, rather than a normal runtime value. So a "type variable" and a "type attribute" are also very different things (assuming that the latter is being used as an equivalent to "class attribute").
Cheers, Nick.
On 17 May 2017 at 11:03, Steven D'Aprano steve@pearwood.info wrote:
On Tue, May 16, 2017 at 10:11:31PM -0700, Guido van Rossum wrote:
There was another reason too. Many things are "class attributes" e.g. methods, descriptors. But only specific things are class *variables*.
Ah, that's a good reason. I can live with that.
Thanks for the explanation.
This was discussed during development of PEP 526: https://github.com/python/typing/issues/258#issuecomment-242263868 Maybe we should add a corresponding subsection to "Rejected ideas"?
-- Ivan
On Wed, May 17, 2017, 09:33 Ivan Levkivskyi, levkivskyi@gmail.com wrote:
On 17 May 2017 at 11:03, Steven D'Aprano steve@pearwood.info wrote:
On Tue, May 16, 2017 at 10:11:31PM -0700, Guido van Rossum wrote:
There was another reason too. Many things are "class attributes" e.g. methods, descriptors. But only specific things are class *variables*.
Ah, that's a good reason. I can live with that.
Thanks for the explanation.
This was discussed during development of PEP 526: https://github.com/python/typing/issues/258#issuecomment-242263868 Maybe we should add a corresponding subsection to "Rejected ideas"?
If it isn't too much trouble to write them I say it's a reasonable idea.
-brett
-- Ivan
Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
On 18 May 2017 at 17:25, Brett Cannon brett@python.org wrote:
On Wed, May 17, 2017, 09:33 Ivan Levkivskyi, levkivskyi@gmail.com wrote:
On 17 May 2017 at 11:03, Steven D'Aprano steve@pearwood.info wrote:
On Tue, May 16, 2017 at 10:11:31PM -0700, Guido van Rossum wrote:
There was another reason too. Many things are "class attributes" e.g. methods, descriptors. But only specific things are class *variables*.
Ah, that's a good reason. I can live with that.
Thanks for the explanation.
This was discussed during development of PEP 526: https://github.com/python/typing/issues/258#issuecomment-242263868 Maybe we should add a corresponding subsection to "Rejected ideas"?
If it isn't too much trouble to write them I say it's a reasonable idea.
Here is a small proposed PR https://github.com/python/peps/pull/261
-- Ivan
participants (6)
-
Brett Cannon -
Guido van Rossum -
Ivan Levkivskyi -
Juancarlo Añez -
Nick Coghlan -
Steven D'Aprano