Differentiate variables form everything else
Inability to visually identify a variable without looking at where its placed and/or how its used is sometimes brain damaging task when it comes to understanding code someone else wrote. In fact, i dont know any IDE that can identify python or any language variable and color them as good as Autoit version of Scite does. In Autoit, variables are prefixed with $ sign. You look at the code and you instantly know ITS A VARIABLE and it cannot be anything else. Many people search google wanting to use $ sign for variables and it is mentioned to be "not best practice". Who says "not best practice" ? If it works and works well, i see no reason to not take advantage of every great benefit it provides.
On Nov 18, 2019, at 06:05, tonycstech@gmail.com wrote:
Inability to visually identify a variable without looking at where its placed and/or how its used is sometimes brain damaging task when it comes to understanding code someone else wrote.
What’s the difference between a variable and anything else? In Python, functions, classes, modules, etc. are all just values, bound to names in the same way as any other value. Everything that looks like an identifier is a variable except for language keywords. IDEs have no problem coloring the fixed set of keywords differently from other identifiers, or coloring identifiers differently from numbers or list brackets or comments or other parts of the syntax. So you must be looking for a distinction between different kinds of variables, maybe based on how they’re defined? But if so, why? Look at this example: def f(a, b): return a**(b+1) g = partial(f, b==2) h = lambda x: f(x, 2) Python can’t tell the difference between f, g, and h; they’re all variables. An IDE could keep track of the fact that f was bound by a def statement, and g and h by assignment. But I’m not sure why you’d want it to. After all, they’re all variables with callable values. Why should f(2,3) be colored differently from g(4)? Also, why would you want to be forced to place a $ before every appearance of a, b, g, h, and x, but not f, in that code? It would make everything longer and uglier, to what benefit?
Many people search google wanting to use $ sign for variables and it is mentioned to be "not best practice". Who says "not best practice" ?
I don’t know. Who are these many people doing the search? What sites are they finding? If you don’t tell us that, how could any of us guess who’s writing those sites, or why? Since it’s illegal in most languages, and mandatory in most of the rest, I’m not sure who would bother telling you it’s “not best practice” in the first place. Maybe you’re finding Perl blogs, where the sigil $ is how you explicitly distinguish scalar variables from array or hash variables (if I’m remembering that right), there are cases where the $ is unnecessary but allowed, and maybe in some such cases people say best practice is to not use it? (Or maybe something similar with Basic, where a $ sigil means a string variable as opposed to a numeric one?) But even if my wild guess is right, I don’t see how that would be relevant to Python, or any other language but Perl.
If it works and works well, i see no reason to not take advantage of every great benefit it provides.
It doesn’t work in Python, or most other languages. Identifiers have to be made of Unicode identifier characters, and $ isn’t one of them. I suppose it could be made to work in Python, because $ is still reserved for someone to come along with an astoundingly good use for an operator or other syntax, but I don’t think this is an astoundingly good use. It seems like your argument is that even though it makes code harder to read as plain text, and to write, it helps IDEs so much that the readability is a net win? Maybe some examples would help, but it seems implausible.
On Mon, Nov 18, 2019, at 13:00, Andrew Barnert via Python-ideas wrote:
I think, more or less, "a function" can be regarded as "a *constant* whose value is callable and is not type-like" [where type-like includes types, abstract base classes, and type hint objects], regardless of how it was obtained. Opinions may differ on whether "real variables" [either locals, or globals whose values actually do vary] and/or parameters of callable types (or type-like types) should or should not be highlighted the same way as a typical non-callable variable. Highlighting these would in any case require an editor with a deep understanding of the language (far beyond the typical regex-based syntax highlighters) and probably type annotated code, but that doesn't mean it wouldn't be useful.
On Tue, Nov 19, 2019 at 5:26 AM Random832 <random832@fastmail.com> wrote:
If by "constant" you mean that they are immutable, then maybe; there aren't very many mutable callables (by comparison to the huge number of functions). But you can't assume that a function is as constant as a string literal. Closures are more akin to lists than to literals - every time you run the 'def' command, it creates you a brand new function with whichever context it was given.
Opinions may differ on whether "real variables" [either locals, or globals whose values actually do vary] and/or parameters of callable types (or type-like types) should or should not be highlighted the same way as a typical non-callable variable.
Highlighting these would in any case require an editor with a deep understanding of the language (far beyond the typical regex-based syntax highlighters) and probably type annotated code, but that doesn't mean it wouldn't be useful.
verbose = print if args.quiet: def verbose(*a, **kw): pass ... verbose("blah blah blah") Is 'verbose' now a variable, a function, a constant, a global, or what? How should it be highlighted? ChrisA
On Tue, Nov 19, 2019 at 6:15 AM Andrew Barnert <abarnert@yahoo.com> wrote:
True, they're technically mutable, though in practice they're normally treated as immutable. Generally a function isn't changed in any significant way once it's been fully prepared - even if "prepared" involves work after construction (such as might be done by a decorator). But that's more a matter of convention than actual enforcement. In any case, my point still stands, that "def foo(): ..." is a very different beast from "foo = 1,2,3,4", where the latter is truly a literal and a constant. ChrisA
On Mon, Nov 18, 2019, at 14:04, Chris Angelico wrote:
I meant a constant in the sense that the name is never intended to be and never in fact reassigned. The kind of thing that when they're *not* callable, PEP8 says should be named in ALL_CAPS.
I already conceded that this kind of thing is subjective around the edges, what more do you want? My opinion would be that it should be highlighted as a function, but I'm not sure how I'd define the criteria for this.
On Tue, Nov 19, 2019 at 8:04 AM Random832 <random832@fastmail.com> wrote:
Fair enough.
I wasn't aiming that at you, so much as pointing out how incredibly tricky it is to pin down all these definitions. So tricky, in fact, that it's almost completely not worth trying to define at all (in my opinion). ChrisA
On Nov 18, 2019, at 13:14, Chris Angelico <rosuav@gmail.com> wrote:
90% of the time it’s obvious to everyone what the answer is, and maybe the other 10% of the time there just is no answer (at least not one that isn’t too arbitrary to be useful). So maybe a big pile of heuristics and/or machine learning is the answer. On the other hand, if that were a good idea, presumably Apple and/or Google would have done it for their pet languages. I’m not sure this distinction is something we need to color-code in the first place. There are plenty of things that are easier to nail down (like local vs. cell vs. global/builtin) that IDEs don’t bother to color-code. Why? I’m guessing it’s because if you throw hundreds of color distinctions at people they cease to distinguish anything. Do people really get subconsciously micro-confused or whatever by which things are functions vs. other variables/names/values/whatever in the first place?
On 11/18/19 4:53 PM, Andrew Barnert via Python-ideas wrote:
On Nov 18, 2019, at 13:14, Chris Angelico <rosuav@gmail.com> wrote:
[...]
The most useful coloring I've ever used is what IntelliJ IDEA calls "semantic highlighting." Looks like they have it in PyCharm, too: https://blog.jetbrains.com/pycharm/2017/01/make-sense-of-your-variables-at-a... TL;DR: instead of all identifiers of a given type having the same color, each identifier gets its own color. That way, e.g., all uses of self.foo are the same color, as are all instances of self.baz. I already know which identifiers are keywords (because of the syntax); it's way more useful to notice that the color of self.conversation isn't the same as the color of self.conservation (certain forms of color blindness notwithstanding).
On Nov 18, 2019, at 10:27, Random832 <random832@fastmail.com> wrote:
Well, none of f, g, and h are immutable values, or constant names. But I take your point. An IDE that could actually understand all of these things as “functions” as distinct from other kinds of names, that would be pretty cool, if very difficult. Still, is it really the “probably not mutated or rebound” that’s the important distinction here, or just the “callable like a function” part? (Or maybe even “called like a function in this code”? I’m not sure what coloring you’d ideally want inside the body of higher-order functions, to be honest… Maybe the answer is to look at what highlighters for F#, Scala, or Haskell do, and whether anyone ever wishes for more?) While we’re at it, int is literally a type, and yet we normally think of int(s, base=16) as a function call rather than a type call. On second thought, maybe that “we” only includes people who’ve been using Python since 2.2 or longer… But the larger point that you can’t easily distinguish between types and functions is important to Python. When a function wants a “factory” you often just pass a type T rather than lambda *a, **kw: T(*a, **kw), but for less trivial cases you pass a function (or, for that matter, a classmethod intended to act as an alternate constructor). There are things in the stdlib that look like type constructors but aren’t. And so on.
On Nov 18, 2019, at 06:05, tonycstech@gmail.com wrote:
Inability to visually identify a variable without looking at where its placed and/or how its used is sometimes brain damaging task when it comes to understanding code someone else wrote.
What’s the difference between a variable and anything else? In Python, functions, classes, modules, etc. are all just values, bound to names in the same way as any other value. Everything that looks like an identifier is a variable except for language keywords. IDEs have no problem coloring the fixed set of keywords differently from other identifiers, or coloring identifiers differently from numbers or list brackets or comments or other parts of the syntax. So you must be looking for a distinction between different kinds of variables, maybe based on how they’re defined? But if so, why? Look at this example: def f(a, b): return a**(b+1) g = partial(f, b==2) h = lambda x: f(x, 2) Python can’t tell the difference between f, g, and h; they’re all variables. An IDE could keep track of the fact that f was bound by a def statement, and g and h by assignment. But I’m not sure why you’d want it to. After all, they’re all variables with callable values. Why should f(2,3) be colored differently from g(4)? Also, why would you want to be forced to place a $ before every appearance of a, b, g, h, and x, but not f, in that code? It would make everything longer and uglier, to what benefit?
Many people search google wanting to use $ sign for variables and it is mentioned to be "not best practice". Who says "not best practice" ?
I don’t know. Who are these many people doing the search? What sites are they finding? If you don’t tell us that, how could any of us guess who’s writing those sites, or why? Since it’s illegal in most languages, and mandatory in most of the rest, I’m not sure who would bother telling you it’s “not best practice” in the first place. Maybe you’re finding Perl blogs, where the sigil $ is how you explicitly distinguish scalar variables from array or hash variables (if I’m remembering that right), there are cases where the $ is unnecessary but allowed, and maybe in some such cases people say best practice is to not use it? (Or maybe something similar with Basic, where a $ sigil means a string variable as opposed to a numeric one?) But even if my wild guess is right, I don’t see how that would be relevant to Python, or any other language but Perl.
If it works and works well, i see no reason to not take advantage of every great benefit it provides.
It doesn’t work in Python, or most other languages. Identifiers have to be made of Unicode identifier characters, and $ isn’t one of them. I suppose it could be made to work in Python, because $ is still reserved for someone to come along with an astoundingly good use for an operator or other syntax, but I don’t think this is an astoundingly good use. It seems like your argument is that even though it makes code harder to read as plain text, and to write, it helps IDEs so much that the readability is a net win? Maybe some examples would help, but it seems implausible.
On Mon, Nov 18, 2019, at 13:00, Andrew Barnert via Python-ideas wrote:
I think, more or less, "a function" can be regarded as "a *constant* whose value is callable and is not type-like" [where type-like includes types, abstract base classes, and type hint objects], regardless of how it was obtained. Opinions may differ on whether "real variables" [either locals, or globals whose values actually do vary] and/or parameters of callable types (or type-like types) should or should not be highlighted the same way as a typical non-callable variable. Highlighting these would in any case require an editor with a deep understanding of the language (far beyond the typical regex-based syntax highlighters) and probably type annotated code, but that doesn't mean it wouldn't be useful.
On Tue, Nov 19, 2019 at 5:26 AM Random832 <random832@fastmail.com> wrote:
If by "constant" you mean that they are immutable, then maybe; there aren't very many mutable callables (by comparison to the huge number of functions). But you can't assume that a function is as constant as a string literal. Closures are more akin to lists than to literals - every time you run the 'def' command, it creates you a brand new function with whichever context it was given.
Opinions may differ on whether "real variables" [either locals, or globals whose values actually do vary] and/or parameters of callable types (or type-like types) should or should not be highlighted the same way as a typical non-callable variable.
Highlighting these would in any case require an editor with a deep understanding of the language (far beyond the typical regex-based syntax highlighters) and probably type annotated code, but that doesn't mean it wouldn't be useful.
verbose = print if args.quiet: def verbose(*a, **kw): pass ... verbose("blah blah blah") Is 'verbose' now a variable, a function, a constant, a global, or what? How should it be highlighted? ChrisA
On Tue, Nov 19, 2019 at 6:15 AM Andrew Barnert <abarnert@yahoo.com> wrote:
True, they're technically mutable, though in practice they're normally treated as immutable. Generally a function isn't changed in any significant way once it's been fully prepared - even if "prepared" involves work after construction (such as might be done by a decorator). But that's more a matter of convention than actual enforcement. In any case, my point still stands, that "def foo(): ..." is a very different beast from "foo = 1,2,3,4", where the latter is truly a literal and a constant. ChrisA
On Mon, Nov 18, 2019, at 14:04, Chris Angelico wrote:
I meant a constant in the sense that the name is never intended to be and never in fact reassigned. The kind of thing that when they're *not* callable, PEP8 says should be named in ALL_CAPS.
I already conceded that this kind of thing is subjective around the edges, what more do you want? My opinion would be that it should be highlighted as a function, but I'm not sure how I'd define the criteria for this.
On Tue, Nov 19, 2019 at 8:04 AM Random832 <random832@fastmail.com> wrote:
Fair enough.
I wasn't aiming that at you, so much as pointing out how incredibly tricky it is to pin down all these definitions. So tricky, in fact, that it's almost completely not worth trying to define at all (in my opinion). ChrisA
On Nov 18, 2019, at 13:14, Chris Angelico <rosuav@gmail.com> wrote:
90% of the time it’s obvious to everyone what the answer is, and maybe the other 10% of the time there just is no answer (at least not one that isn’t too arbitrary to be useful). So maybe a big pile of heuristics and/or machine learning is the answer. On the other hand, if that were a good idea, presumably Apple and/or Google would have done it for their pet languages. I’m not sure this distinction is something we need to color-code in the first place. There are plenty of things that are easier to nail down (like local vs. cell vs. global/builtin) that IDEs don’t bother to color-code. Why? I’m guessing it’s because if you throw hundreds of color distinctions at people they cease to distinguish anything. Do people really get subconsciously micro-confused or whatever by which things are functions vs. other variables/names/values/whatever in the first place?
On 11/18/19 4:53 PM, Andrew Barnert via Python-ideas wrote:
On Nov 18, 2019, at 13:14, Chris Angelico <rosuav@gmail.com> wrote:
[...]
The most useful coloring I've ever used is what IntelliJ IDEA calls "semantic highlighting." Looks like they have it in PyCharm, too: https://blog.jetbrains.com/pycharm/2017/01/make-sense-of-your-variables-at-a... TL;DR: instead of all identifiers of a given type having the same color, each identifier gets its own color. That way, e.g., all uses of self.foo are the same color, as are all instances of self.baz. I already know which identifiers are keywords (because of the syntax); it's way more useful to notice that the color of self.conversation isn't the same as the color of self.conservation (certain forms of color blindness notwithstanding).
On Nov 18, 2019, at 10:27, Random832 <random832@fastmail.com> wrote:
Well, none of f, g, and h are immutable values, or constant names. But I take your point. An IDE that could actually understand all of these things as “functions” as distinct from other kinds of names, that would be pretty cool, if very difficult. Still, is it really the “probably not mutated or rebound” that’s the important distinction here, or just the “callable like a function” part? (Or maybe even “called like a function in this code”? I’m not sure what coloring you’d ideally want inside the body of higher-order functions, to be honest… Maybe the answer is to look at what highlighters for F#, Scala, or Haskell do, and whether anyone ever wishes for more?) While we’re at it, int is literally a type, and yet we normally think of int(s, base=16) as a function call rather than a type call. On second thought, maybe that “we” only includes people who’ve been using Python since 2.2 or longer… But the larger point that you can’t easily distinguish between types and functions is important to Python. When a function wants a “factory” you often just pass a type T rather than lambda *a, **kw: T(*a, **kw), but for less trivial cases you pass a function (or, for that matter, a classmethod intended to act as an alternate constructor). There are things in the stdlib that look like type constructors but aren’t. And so on.
participants (5)
-
Andrew Barnert -
Chris Angelico -
Dan Sommers -
Random832 -
tonycstech＠gmail.com