Message: 4 Date: Tue, 21 Nov 2017 18:05:17 +0000 From: ????? email@example.com To: Chris Barker firstname.lastname@example.org Cc: Python-Ideas email@example.com Subject: Re: [Python-ideas] Should Python have user-defined constants?
It was mentioned that there are related conventions in Python. Good point. But they are not as strong as the "convention" that tuples and strings cannot change, and this is useful in reasoning about code - in understanding the program, essentially.
When I read "final int x = 5;" in Java, I don't have to think about it anymore - it's 5. When I read "X = 5" in Python, it might be a constant, but it might also be a misnomer, or something that used to be a constant, or a class reassigned. I still have to watch whether it will be changed, intentionally or accidentally, by this or other module. It does not even communicate intention in an unambiguous way.
Here I strongly disagree. The uppercase convention for things you really should not be assigning to has been in Python for ages and well understood. math.pi is the usual example brought up by people who want const/final, perhaps as a glaring exception to the rule. (Can math.PI be added to the standard library?)
I think that adding const/let/final to Python would decrease readability and the ability to reason about the code for me, because now I would be reading foo += 1 and I could not easily decide whether this was wrong or not, because it might have been declared as immutable. Textual conventions are popular in many programming languages, not just Python, because they are easier to remember than individual type/attribute declarations.
In my opinion, the inability to control mutation in Python is the biggest readability issue of the language (thank god monkey-patching is discouraged).
I think this is a separate issue to const/let/final. (And have you read PEP 351?)
I don't miss simple scalar const/#define values in Python. In C/Java/Ada/... they are necessary to define array bounds, but everything in Python is dynamic and you can ask an array or whatever how big it is. In C/Ada/C#/... const protects again accidentally passing a value by reference/address and modifying it, but Python doesn't have pass by reference. No pointer aliasing in Python...
As for monkey patching, or even just math.pi = 3.0 that is being unable to make dictionaries read-only.
I agree, I get frustrated when I've accidentally misspelled an attribute name and Python just creates a new instance value instead of reporting an error. But this kind of dynamic object creation is so fundamental to how Python works, and also the source of so much power and flexibility, that I think it is worth living with the occasional glitch.
I would not want to see Python allow module or class writers to declare "my code is perfect and not to be changed". But I would not mind if I could write code "I should not be changing this module/class/object , raise an exception if I do".