Timeline for Should I really use all uppercase for my constants?
Current License: CC BY-SA 3.0
16 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| May 24, 2019 at 18:10 | comment | added | MetricSystem | @ThomasJunk on the contrary I also develop in Scala, but I do agree that if you can't maintain respectful discourse this conversation is over. | |
| May 24, 2019 at 7:25 | comment | added | Thomas Junk | @Metric System Have you been bullied by the JAVA/SCALA community? I think we should stop chitchating here. | |
| May 23, 2019 at 22:48 | comment | added | MetricSystem | @ThomasJunks And my other point is that what you're suggesting has nothing to do with PEP8. PEP8 says constants should be uppercase, not that module level variables should be constant. | |
| May 23, 2019 at 18:21 | comment | added | MetricSystem | @ThomasJunk strict static compile-time type checkers can provide a lot of safety from complexity too, so we should all ditch Python for Scala? Python has never been a language that prioritized purity over pragmatism, it's not exclusively used in big complex projects and shouldn't be beholden to guidelines for them. If you have to make special exceptions for the most popular frameworks just because they're popular, you're doing it wrong. My only real point, is that ideally pylint would have more fine-grained rules that let you keep variable naming rules but allow lowercase module names. | |
| May 23, 2019 at 7:19 | comment | added | Thomas Junk | @MetricSystem The point for me to (mostly) avoid mutable globals is simple: reducing complexity. On the one hand you might argue, it might be easier to modify, so it reduces complexity where the variable is used and modified. OTOH: understanding what mutates the state becomes really hard. It may work for projects, like it does work for you to cross the street without traffic checking: The only problem is, when you have to explain, why you were hit by a car. But, perhaps it doesn't happen. | |
| May 22, 2019 at 18:27 | comment | added | MetricSystem | @ThomasJunk I think mutable module level variables are fine and often elegant. Flask is one of the most popular libraries and pylint whitelisted app as a result (violating Zen of Python: special cases aren't special enough to break the rules). It's a bit like a Java programmer asking Python programmers why you would ever need something outside of a class. You can put everything in a class, but why? You can move everything from a module into some wrapper function, but why? | |
| May 22, 2019 at 7:53 | comment | added | Thomas Junk | @MetricSystem what - in your opinion - function would a module level variable have besides being a constant? Should it be mutable? | |
| May 21, 2019 at 21:57 | comment | added | MetricSystem | Pylint is definitely in the wrong, in that it read "constants should be module level" and assumed the converse "module level should be constants". But because it's otherwise a good, useful tool seems we're getting stuck with it. | |
| Aug 8, 2018 at 8:02 | comment | added | Jules | I'd distinguish between an immutable variable (i.e. something that's set at runtime and not changed) and a constant (i.e. something that is the same in every program run, and if the language provides the option to do it could be computed at compile time) ... the point is that because there's a lack of any way of specifying the distinction to python, pylint assumes the latter even when the former is the case. | |
| Aug 8, 2018 at 7:27 | comment | added | Thomas Junk | @Jules I would call variables set once and changing during runtime never again a constant, hence exists in many languages (e.g. in JS) a const keyword. Although the initial value is different, other than maybe PI. | |
| Mar 21, 2018 at 8:46 | comment | added | Jules | On the other hand, it's entirely possible for pylint to get it wrong. Python doesn't provide a way of distinguishing a constant from a variable, other than that the constant is expected to always have the same value. pylint assumes that anything that is only set once and doesn't ever change is a constant, but unless it's intended to be a constant, that could just be an artifact of the implementation. And specifically the code given in the comment to the question has values that will be different on each run, therefore should not be considered constants even if pylint thinks they are. | |
| S Mar 21, 2018 at 8:15 | history | suggested | Stevoisiak | CC BY-SA 3.0 | Fixed minor typos |
| Mar 20, 2018 at 19:05 | review | Suggested edits | |||
| S Mar 21, 2018 at 8:15 | |||||
| Feb 17, 2017 at 4:59 | history | edited | Thomas Junk | CC BY-SA 3.0 | added 1 character in body |
| Feb 16, 2017 at 14:09 | history | edited | Thomas Junk | CC BY-SA 3.0 | added 563 characters in body |
| Feb 16, 2017 at 14:01 | history | answered | Thomas Junk | CC BY-SA 3.0 |