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 Tue, Nov 19, 2019 at 5:26 AM Random832 wrote:

On Mon, Nov 18, 2019, at 13:00, Andrew Barnert via Python-ideas wrote:

...

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)?

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.

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 Nov 18, 2019, at 11:07, Chris Angelico 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).

Functions are mutable. You can edit their __defaults__, or even replace their __code__. In fact, there aren’t very many _immutable_ callables (by comparison to the huge number of functions).

On Mon, Nov 18, 2019, at 14:04, Chris Angelico 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.

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.

verbose = print if args.quiet: def verbose(*a, **kw): pass

Is 'verbose' now a variable, a function, a constant, a global, or what? How should it be highlighted?

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 Nov 18, 2019, at 13:14, Chris Angelico wrote:

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).

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?