Rob,
I consider my comments in code I write to be a (silent) part of the code, or
worse, some code I commented out but want to be able to look at.
I often have code like:
# NOTE you can turn on one of the following that applies to your situation
# and comment out the others but leave them in place.
FILENAME = "C: ..."
#FILENAME = "I: ...
The second line is uncommented if this is run on another machine where the file
is on the I: drive. Often code I write is sent to someone who has to make it
work on their machine or selectively has regions turned off.
# Decide if the next section should be run by selecting the line that
represents your needed.
NORMALIZE = True
# NORMALIZE = False
if (NORMALIZE):
...
In cases like the above, which are not the majority of how I use comments,
keeping it as I defined it makes sense even if some of the commented code is
not running. It makes it easier to make customizations. I often have requests
for example to read in a .CSV and depending on the situation, make multiple
transformations to it that can include removing columns or filtering out rows,
normalizing one or more columns, dealing with outliers beyond some designated
level, creating new derived columns based on existing ones, or a Boolean
reflecting some complex condition, or grouping it some way or merging it with
other data and so on. If writing for myself, I might do it all in one pipeline.
But if writing it for someone who plays games and tries this versus that, then
something like the above, with suitable comments, lets them experiment by
turning sections on and off and other forms of customization. I consider the
presence of comments a serious part of what i deliver.
Yes, the interpreter (and sometimes compiler) strips them but leaving them in
the source file does not strike me as expensive. Once removed, I consider the
person who did it suspect and am less inclined to work with them. Consider code
with an embedded copyright of some sort (or apparently GNU has a copyleft) and
whether it is valid to separate that from the code?
And note that some code we write may be quite elegant but also rather
mysterious and seeing it again a year later it may not be easy to see why we
did that and whether some other way might not work as well. Decent comments
explaining the algorithm and why choices were made may make all the difference.
Or, they may make it easy to see how to convert the code to deal with one more
or one less variable by changing it in the right places consistently.
To answer something Chris said and was also mentioned here, I do not consider
language design to be easy let alone implementing it. Not at all. BUT I think
some changes can be straightforward. Having a symbol like a curly brace mean
three new things may be tough to implement. Allowing a new symbol in an
expanded set of characters seems more straightforward.
Consider an arrow symbol → pointing to the right and another pointing the other
way. Could we add the symbol to the language as a single character, albeit
implemented using multiple bytes? If my editor let me insert the darn thing, it
might then be a reasonable use for some construct in the language unique and
new. Maybe the language would use the notation to hold objects holding a set
and not confuse the notations for sets and dictionaries as Python ended up
doing. (Yes, I know it is NOT confusing in some ways as one holds key:value
pairs and the other just value, but making an empty set now requires the
notation of set() while an empty dictionary is {} right?
So how hard is it for a newly designed language to recognize any use of one
arrow and expect everything up to the next arrow (pointing back) to be the
contents of a set? It sounds a tad easier than now when Python interpreters
have to pause when they see an open bracket and read what follows to see if
everything beyond uses dictionary notation before it decides.
But NO, I am not volunteering to do any of that. A language with too many
symbols may be far worse. We cannot give every single object type their own
symbols. But a few more than we have now might make it easier to create objects
Python omitted and numpy and pandas and other modules had to add back the hard
way.
The only reason this is coming up is teh discussion of how various people react
to the exact choice of how to add a new feature. I doubt people will like many
choices in a new language created sort of like I describe, either. And nobody
wants a new keyboard with a thousand keys, even if their language is Chinese.
But there are days I want one a bit like that as I often write, as mentioned,
in languages with additional characters or entirely other alphabets. Sigh.
Life is complicated, then you die and it simplifies.
-----Original Message-----
From: Rob Cliffe via Python-list <python-list@python.org>
To: python-list@python.org
Sent: Thu, Mar 3, 2022 8:41 pm
Subject: Re: Behavior of the for-else construct
On 04/03/2022 00:38, Avi Gross via Python-list wrote:
> Rob,
>
> I regularly code with lots of comments like the one you describe, or mark the
> end of a region that started on an earlier screen such as a deeply nested
> construct.
So do I (and not just in Python). It's good practice.
>
> I have had problems though when I have shared such code and the recipient
> strips my comments and then later wants me to make changes or even just
> explain it! My reply tends to be unprintable as in, well, never mind!
Quite justified. But why not make changes to/explain from *your*
version, not his?
>
> This leads to a question I constantly ask. If you were free to design a brand
> new language now, what would you do different that existing languages have
> had to deal with the hard way?
That's such a big question that I can't give an adequate answer.
>
> I recall when filenames and extensions had a limited number of characters
> allowed and embedded spaces were verboten. This regularity made lots of code
> possible but then some bright people insisted on allowing spaces and you can
> no longer easily do things like expand *.c into a long line of text and then
> unambiguously work on one file name at a time. You can often now create a
> name like "was file1.c and now is file2.c" and it seems acceptable. Yes, you
> can work around things and get a vector or list of strings and not a command
> line of text and all things considered, people can get as much or more work
> done.
>
> I have seen major struggles to get other character sets into languages. Any
> new language typically should have this built in from scratch and should
> consider adding non-ASCII characters into the mix. Mathematicians often use
> lots of weird braces/brackets as an example while normal programs are limited
> to [{( and maybe < and their counterparts. This leads to odd Python behavior
> (other languages too) where symbols are re-used ad nauseam. { can mean set or
> dictionary or simply some other way to group code.
>
> So I would love to see some key that allows you to do something like L* to
> mean the combination is a left bracket and should be treated as the beginning
> of a sequence expected to end in R* or perhaps *R. That would allow many
> other symbols to be viewed as balanced entities. Think of how Python expanded
> using single and double quotes (which arguably might work better if balanced
> this way) to sometimes using triple quotes to putting letters like "b" or "f"
> in front to make it a special kind of string.
>
> But I suspect programming might just get harder for those who would not
> appreciate a language that used (many) hundreds of symbols.
+1. Just remembering how to type them all would be a burden.
> I do work in many alphabets and many of them pronounce and use letters that
>look familiar in very different ways and sound them differently and invent new
>ones. Every time I learn another human language, I have to both incorporate
>the new symbols and rules and also segregate them a bit from identical or
>similar things in the languages I already speak. It can be quite a chore. But
>still, I suspect many people are already familiar with symbols such as from
>set Theory such as subset and superset that could be used as another pair of
>parentheses of some type Having a way to enter them using keyboards is a
>challenge.
>
> Back to the topic, I was thinking wickedly of a way to extend the FOR loop
> with existing keywords while sounding a tad ominous is not with an ELSE but
> a FOR ... OR ELSE ...
>
>
> -----Original Message-----
> From: Rob Cliffe via Python-list <python-list@python.org>
> To: python-list@python.org
> Sent: Thu, Mar 3, 2022 7:13 pm
> Subject: Re: Behavior of the for-else construct
>
>
> I find it so hard to remember what `for ... else` means that on the very
> few occasions I have used it, I ALWAYS put a comment alongside/below the
> `else` to remind myself (and anyone else unfortunate enough to read my
> code) what triggers it, e.g.
>
> for item in search_list:
> ...
> ... break
> else: # if no item in search_list matched the criteria
>
> You get the idea.
> If I really want to remember what this construct means, I remind myself
> that `else` here really means `no break`. Would have been better if it
> had been spelt `nobreak` or similar in the first place.
> Rob Cliffe
>
>
> On 03/03/2022 23:07, Avi Gross via Python-list wrote:
>> The drumbeat I keep hearing is that some people hear/see the same word as
>> implying something else. ELSE is ambiguous in the context it is used.
>>
>> And naturally, since nobody desperately wants to use non-reserved keywords,
>> nobody seems ready to use a word like INSTEAD instead.
>>
>> Ideally, a language should be extendable and some languages like R allow you
>> to place all kinds of things inside percent signs to make new operators like
>> %*% or %PIPE% ...
>>
>> Just because some feature may be wanted is not a good reason to overly
>> complicate a language. Can you imagine how hard it would be both to
>> implement and read something like:
>>
>> ...
>> ELSE:
>> ...
>> OK:
>> ...
>> FINALLY:
>> ...
>> ULTIMATELY:
>> ...
>>
>> What if multiple of things like the above example need to be triggered in
>> some particular order?
>>
>> I have to wonder if some new form of wrapper might have made as much sense
>> as in you wrap your loop in something that sets up and traps various signals
>> that are then produced under conditions specified such as the loop not being
>> entered as the starting condition is sort of null, or an exit due to a break
>> or simply because the code itself throws that signal to be caught ...
>>
>> This reminds me a bit of how some programs add so much functionality because
>> someone thought of it without wondering if anyone (including the ones who
>> sponsored it) would ever want to use it or remember it is there or how. I
>> recall how a version of emacs had a transpose-letter function so after
>> typing "teh" you could hit control-t and a little mock LISP macro would go
>> back and co a cut and go forward and do a paste and leave the cursor where
>> it was. That was sometimes useful, but often just as easy to backspace and
>> retype. But I recall gleefully adding a transpose for words, sentences,
>> paragraphs and was going to add more but I was running out of keystrokes to
>> bind them to and besides it can be fairly easy to select items and yank them
>> and move to where you want them and replace them.
>>
>> To make changes in a language is sometimes really expensive but also
>> dangerous. A "free" language must be added to sparingly and with so many
>> requests, perhaps only a few non bug-fixes can seriously be considered.
>>
>>
>>
>> -----Original Message-----
>> From: Akkana Peck <akk...@shallowsky.com>
>> To: python-list@python.org
>> Sent: Thu, Mar 3, 2022 5:33 pm
>> Subject: Re: Behavior of the for-else construct
>>
>> computermaster360 writes:
>>> I want to make a little survey here.
>>>
>>> Do you find the for-else construct useful?
>> No.
>>
>>> Have you used it in practice?
>> Once or twice, but ended up removing it, see below.
>>
>>> Do you even know how it works, or that there is such a thing in Python?
>> I always have to look it up, because to my mind, "else" implies
>> it does something quite different from what it actually does.
>>
>> Which means that even if I worked hard at memorizing what it does,
>> so I didn't have to look it up, I still wouldn't use it in code,
>> because I want my code to be easily readable (including by future-me).
>> for..else makes code difficult to understand by anyone who doesn't
>> use for..else frequently: they might be misled into misunderstanding
>> the control flow.
>>
>> ...Akkana
>>
--
https://mail.python.org/mailman/listinfo/python-list
--
https://mail.python.org/mailman/listinfo/python-list
