Re: for -- else: what was the motivation?
Op 17/10/2022 om 04:01 schreef Chris Angelico: On Mon, 17 Oct 2022 at 10:46, wrote: My point Chris was that you can have a conversation where you are exploring and not proposing. Brainstorming, perhaps. And my point is that either a proposal is a serious one that can expect serious discussion, or it isn't. Yes, I'm aware that it wasn't you who backpedalled as soon as any criticism was posted, but your caveat comes to the same thing - if you're trying to avoid serious criticism, you have to not post an idea. Your reaction was not serious criticisme but a belligerent reaction. You made it clear you wanted a fight. I choose not to enter that fight. -- Antoon Pardon -- https://mail.python.org/mailman/listinfo/python-list
Re: for -- else: what was the motivation?
On Mon, 17 Oct 2022 at 10:46, wrote: > > My point Chris was that you can have a conversation where you are exploring > and not proposing. Brainstorming, perhaps. And my point is that either a proposal is a serious one that can expect serious discussion, or it isn't. Yes, I'm aware that it wasn't you who backpedalled as soon as any criticism was posted, but your caveat comes to the same thing - if you're trying to avoid serious criticism, you have to not post an idea. > So my POINT (and I repeat NOT a suggestion) is that I can IMAGINE ways to > add a feature to a loop, such as an extra optional argument that is called > if the loop exits from the bottom. The code you now put in the ELSE clause > might have to be in the lambda or whatever. That may not be a good fit for > Python. If you're inventing a completely new language, you can do whatever you like, but it's not very practical to discuss small features when there's no language to discuss them in. So are you discussing this as a Python feature, or just saying "hey, in a vacuum, we could do this", which is vacuously true? > What may aggravate you is that lots of people keep telling you that the ELSE > on a loop feature is not intuitive to many, sometimes even after it is > explained. I know it's unintuitive. That doesn't stop it being useful. > My suggestion is you should deal with that and not take it out on others. > Live and let live. That's unrelated. Sorry to disappoint you. > This forum may be about Python but not exclusively. I personally often enjoy > hearing how some other system does something similar, such as discussions on > how and whether Python should allow an underscore in static numbers given > other languages do so, not always identically. We can learn from such > comparisons, for good and also for bad. That's correct, but usually there's at least SOME context. And if none is given, is it or is it not reasonable to assume that people are talking about Python? > But if it makes you happy, take me off this list! I have so many things I > need to do and free up time for. I'm not in a position to do that, and my point was to show how ridiculous empty proposals are :) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
RE: for -- else: what was the motivation?
My point Chris was that you can have a conversation where you are exploring
and not proposing. Brainstorming, perhaps.
I was saying that there are many ways to signal things and in some
hypothetical new language, it may be implemented in novel ways that do not
break anything.
I note languages like JavaScript seem to love passing functions or setting
event handlers that may only be activated under unusual conditions.
So my POINT (and I repeat NOT a suggestion) is that I can IMAGINE ways to
add a feature to a loop, such as an extra optional argument that is called
if the loop exits from the bottom. The code you now put in the ELSE clause
might have to be in the lambda or whatever. That may not be a good fit for
Python.
What may aggravate you is that lots of people keep telling you that the ELSE
on a loop feature is not intuitive to many, sometimes even after it is
explained.
My suggestion is you should deal with that and not take it out on others.
Live and let live.
My view remains that something has been added and is available and won't
likely be changed so use it as-is or ignore it.
But if anyone wants to make their own language, they can feel free to design
around this any way they wish. If they design an object that encapsulates a
loop and then add attributes to the object that are guaranteed to tell you
how the loop ended and run some code if it is set there, fine.
This forum may be about Python but not exclusively. I personally often enjoy
hearing how some other system does something similar, such as discussions on
how and whether Python should allow an underscore in static numbers given
other languages do so, not always identically. We can learn from such
comparisons, for good and also for bad.
I am NOT proposing we change anything about ELSE and that was not my point.
My point was that sometimes rather than reuse an existing keyword in the
language or create new reserved keywords, there can be many possible ways to
extend functionality.
I know of languages with multiple variations on loops that do not break
existing code. If your syntax is for (...) { ...} then if you add the
ability to place some identifier ONLY in the context involved then for XXX
(...) { ...} may mean some altered functionality while YYY in the same spot
means something else and the original form continues to do what it always
did.
So are XXX and YYY keywords or something else?
Again, I do not understand why people here get so touchy.
But if it makes you happy, take me off this list! I have so many things I
need to do and free up time for.
-Original Message-
From: Python-list On
Behalf Of Chris Angelico
Sent: Sunday, October 16, 2022 6:56 PM
To: python-list@python.org
Subject: Re: for -- else: what was the motivation?
On Mon, 17 Oct 2022 at 08:22, wrote:
> I had another crazy thought that I AM NOT ASKING anyone to do. OK?
>
Here's another proposal: Let's ban you from this mailing list. Don't worry,
I AM NOT ASKING anyone to do it. OK?
Do you see how ridiculous and pointless it is to have proposals with that
kind of caveat?
Make serious proposals that we can discuss reasonably, don't make fake
proposals and hide behind a caveat.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
--
https://mail.python.org/mailman/listinfo/python-list
Re: for -- else: what was the motivation?
On Mon, 17 Oct 2022 at 08:22, wrote: > I had another crazy thought that I AM NOT ASKING anyone to do. OK? > Here's another proposal: Let's ban you from this mailing list. Don't worry, I AM NOT ASKING anyone to do it. OK? Do you see how ridiculous and pointless it is to have proposals with that kind of caveat? Make serious proposals that we can discuss reasonably, don't make fake proposals and hide behind a caveat. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
RE: for -- else: what was the motivation?
Realistically an idea about something new is easier to consider than changing what you have. Some newer languages may well be designed from the start in new ways and Julia is an example of a language that allows a wide swath of UNICODE characters to be used in identifiers. They also let you type them in even using ASCII keyboards for some level of compatibility. The original topic asked about the topic of re-using ELSE as a known keyword in a context I and some others feel is a stretch. But the alterative could be to add an ever increasing number of keywords to meet new needs. I had another crazy thought that I AM NOT ASKING anyone to do. OK? I was wondering about a sort of catch method you could use that generates a pseudo-signal only when the enclosed preceding loop exits normally as a sort of way to handle the ELSE need without the use of a keyword known by the language. All you would need is an object of the right kind that is thrown and optionally caught. Of course, even if I fleshed this out and even if anyone thought it made sense, there is no such need now as Python has made a choice that meets the need even if few may dare use it or even know about it! LOL! -Original Message- From: Python-list On Behalf Of Antoon Pardon Sent: Sunday, October 16, 2022 1:38 PM To: python-list@python.org Subject: Re: for -- else: what was the motivation? Op 16/10/2022 om 19:03 schreef Chris Angelico: > On Mon, 17 Oct 2022 at 03:57, Antoon Pardon wrote: >> >> Op 16/10/2022 om 17:05 schreef Chris Angelico: >>> On Sun, 16 Oct 2022 at 22:47, Antoon Pardon wrote: Why would I need good luck? I expressed an idea and you didn't like it. That won't affect my life in a meaningful way. >>> Well, with that attitude, it's not going to affect anyone else's >>> life either, so go ahead, carry on. >> What attitude? I just floated a little idea. It was not >> meant/expected to affect anyone else's life. So why do you react as if it was? >> > You expressed an idea that you would like to see implemented in > Python, and part of that idea was that people would be *obliged* to > write their code using non-ASCII keywords. If that were to be > implemented, it absolutely WOULD affect many people's lives. So what? I made it clear that was an if I didn't expect to happen. An idea that doesn't happen will not affect anyone, whatever the consequences tied to the idea. > So if > you're saying that your idea was not meant to affect anyone else's > life, you are saying that you floated the idea fully intending for it > to be ignored, which makes me wonder why you posted it in the first > place. People can find it interesting to discuss an idea, even if they think there is no chance the idea will be carried out. -- Antoon Pardon -- https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Re: for -- else: what was the motivation?
On 2022-10-16 19:52:47 +0200, Antoon Pardon wrote: > Op 16/10/2022 om 19:01 schreef Peter J. Holzer: > > On 2022-10-16 12:17:39 +0200, Antoon Pardon wrote: > > > Op 16/10/2022 om 00:50 schreefavi.e.gr...@gmail.com: > > > > That might not easily solve this problem. But I wonder if reserving > > > > some kind of prefix might help, so anything like extension.0nNoBreak > > > > could be added to a loop as a final clause and be treated as a > > > > non-key keyword of sorts. > > > My idea would be to reserve different unicode blocks for the keywords and > > > the identifiers. e.g. We could reserve the mathematical alphanumeric block > > > for keywords and all other letters and numbers for identifiers. Doing so > > > would allow extenting the keywords without breaking programs that already > > > use that combination as an identifier. > > Or you could go back to the old Algol idea of underlining keywords. > > > > Both have the same problem, though: They make editing with an ordinary > > text editor pretty much impossible. You need a language-aware IDE which > > makes entering these characters or markups simple. > > That is not true with my idea. The editor would just need to be able > to work with unicode characters. Vim can work with 퐝퐞퐟 just as it can > with def. Yes, vim can. But can the user? And the user's system? And vim isn't the only editor out there. So you need a system for every editor some Python programmer might want to use. While most will probably use a sufficiently powerful editor, some won't. > In vim I can also define abbreviations so that whenever I type ^Bd vim > wil insert 퐝퐞퐟 for me. Which requires the user to define and type abbreviations. Which may be hard if they can't enter the characters in the first place (Ok, that may not be a problem as most users will probably just install a package from the internet,) The same does work with underlines: d̲e̲f̲ although weirdly my terminal underlines the wrong characters (the one to the right instead of the one to the left). The pragmatic action would of course to define "def" as an abbreviation for "퐝퐞퐟" (or "d̲e̲f̲"), but then what have you won? hp -- _ | Peter J. Holzer| Story must make more sense than reality. |_|_) || | | | h...@hjp.at |-- Charles Stross, "Creative writing __/ | http://www.hjp.at/ | challenge!" signature.asc Description: PGP signature -- https://mail.python.org/mailman/listinfo/python-list
Re: for -- else: what was the motivation?
On 16/10/2022 18:43, Antoon Pardon wrote: Op 16/10/2022 om 17:03 schreef Avi Gross: Interesting idea, Anton. I would be interested in hearing more detail on how it would work. Although much of programming has been centered on the Latin alphabet and especially English, that may change. I can imagine a customized compiler or interpreter that uses key words in the local language instead of for or while or if or else or even import. Please, please please... forget about that idea. I know examples. They had no future, and have no future. Either RMS or ESR once have written in one of their book: "Please write in C". Same here: please speak in English. Although, if you like that idea who can stop you? In such a case I vote for ภาษาไทย Axy. -- https://mail.python.org/mailman/listinfo/python-list
Re: for -- else: what was the motivation?
Op 16/10/2022 om 19:01 schreef Peter J. Holzer: On 2022-10-16 12:17:39 +0200, Antoon Pardon wrote: Op 16/10/2022 om 00:50 schreefavi.e.gr...@gmail.com: That might not easily solve this problem. But I wonder if reserving some kind of prefix might help, so anything like extension.0nNoBreak could be added to a loop as a final clause and be treated as a non-key keyword of sorts. My idea would be to reserve different unicode blocks for the keywords and the identifiers. e.g. We could reserve the mathematical alphanumeric block for keywords and all other letters and numbers for identifiers. Doing so would allow extenting the keywords without breaking programs that already use that combination as an identifier. Or you could go back to the old Algol idea of underlining keywords. Both have the same problem, though: They make editing with an ordinary text editor pretty much impossible. You need a language-aware IDE which makes entering these characters or markups simple. That is not true with my idea. The editor would just need to be able to work with unicode characters. Vim can work with 퐝퐞퐟 just as it can with def. In vim I can also define abbreviations so that whenever I type ^Bd vim wil insert 퐝퐞퐟 for me. It may be useful to have an alternative keyboard definition ready to easily insert these characters into the editor but ordinary editors should already be able to treat these characters as any other unicode character. -- Antoon Pardon -- https://mail.python.org/mailman/listinfo/python-list
Re: for -- else: what was the motivation?
Op 16/10/2022 om 17:03 schreef Avi Gross: Interesting idea, Anton. I would be interested in hearing more detail on how it would work. Although much of programming has been centered on the Latin alphabet and especially English, that may change. I can imagine a customized compiler or interpreter that uses key words in the local language instead of for or while or if or else or even import. If a region of UNICODE was set aside, would it have to be as a sort of additional ALT or shift key for anything, or just English characters or would it be for abstract symbols that would be mapped to and from a long list of reserved key words that may vary by locale? I think you are carrying my idea further than I intended. I was just thinking that instead of using U+0064 U+0065 U+0066 [beinf def] we could be using U+1D41D U+1D41E U+1D41F [being 퐝퐞퐟]. -- Antoon Pardon. -- https://mail.python.org/mailman/listinfo/python-list
Re: for -- else: what was the motivation?
Op 16/10/2022 om 19:03 schreef Chris Angelico: On Mon, 17 Oct 2022 at 03:57, Antoon Pardon wrote: Op 16/10/2022 om 17:05 schreef Chris Angelico: On Sun, 16 Oct 2022 at 22:47, Antoon Pardon wrote: Why would I need good luck? I expressed an idea and you didn't like it. That won't affect my life in a meaningful way. Well, with that attitude, it's not going to affect anyone else's life either, so go ahead, carry on. What attitude? I just floated a little idea. It was not meant/expected to affect anyone else's life. So why do you react as if it was? You expressed an idea that you would like to see implemented in Python, and part of that idea was that people would be *obliged* to write their code using non-ASCII keywords. If that were to be implemented, it absolutely WOULD affect many people's lives. So what? I made it clear that was an if I didn't expect to happen. An idea that doesn't happen will not affect anyone, whatever the consequences tied to the idea. So if you're saying that your idea was not meant to affect anyone else's life, you are saying that you floated the idea fully intending for it to be ignored, which makes me wonder why you posted it in the first place. People can find it interesting to discuss an idea, even if they think there is no chance the idea will be carried out. -- Antoon Pardon -- https://mail.python.org/mailman/listinfo/python-list
Re: Find the path of a shell command [POSTPONED]
On 2022-10-16 17:21:03 +0100, Barry wrote: > > On 16 Oct 2022, at 04:53, Dan Stromberg wrote: > > > > On Wed, Oct 12, 2022 at 9:57 PM Cameron Simpson wrote: > > > >>> On 13Oct2022 03:25, Paulo da Silva > >>> wrote: > >>> There is another problem involved. The script, works fine except when > >>> launched by cron! Why? [... script deleted ...] > >> Cron's environment is very minimal. This will show you what's in > >> it. > > > > Careful. On some systems if someone restarts the cron daemon, it could > > pick up a larger environment than after being started on boot. > > That have to a old system that does not use systemd. Systemd is specific to Linux - and not even used by all Linux distributions. > Is there a specific system that still does this? Not sure. Some Unixes I've used in the past (probably including some Linux distributions) had this problem. So you had to be a bit careful when restarting daemons from the command line. I think the sysVinit system used by most Linux distributions before systemd did clean up the environment if you used it correctly (but I'm not sure and have no system anymore to test it). I haven't used Solaris or HP/UX in a long time (and other Unixes even longer) so I don't know what they do these days. And I've never used MacOS, I just know that they've used a system of their own long before systemd. Anyway he doesn't have to restart cron to add a cron-job (nor for any other reason during normal operation), so what happens if you manually restart cron is almost certainly irrelevant for the OP. hp -- _ | Peter J. Holzer| Story must make more sense than reality. |_|_) || | | | h...@hjp.at |-- Charles Stross, "Creative writing __/ | http://www.hjp.at/ | challenge!" signature.asc Description: PGP signature -- https://mail.python.org/mailman/listinfo/python-list
Re: for -- else: what was the motivation?
On 2022-10-15 23:50, avi.e.gr...@gmail.com wrote:
This has been discussed so often precisely because I swear NO CHOICE of keyword
would satisfy everybody! Most languages start with designated keywords and some
reserve a few for later use. But then things can get frozen in place to avoid
breaking existing programs or break older compilers/interpreters.
Some languages use techniques to extend themselves more harmlessly such as creating a
singleton object that has content that can be regular data as in math.pi, or
functions/methods or new ides like "Symbols" that allow all kinds of extensions
to the language in a fairly harmless way as no older program would likely have used
features that did not exist.
That might not easily solve this problem. But I wonder if reserving some kind
of prefix might help, so anything like extension.0nNoBreak could be added to a
loop as a final clause and be treated as a non-key keyword of sorts.
If you'd accept 2 words:
for child in tree.getroot():
if child.tag == 'server':
break
not break:
raise ValueError(f"server tag not found in {lfile}")
-Original Message-
From: Python-list On
Behalf Of Rob Cliffe via Python-list
Sent: Wednesday, October 12, 2022 6:20 PM
To: python-list@python.org
Subject: Re: for -- else: what was the motivation?
I too have occasionally used for ... else. It does have its uses. But oh, how I wish it had been
called something else more meaningful, whether 'nobreak' or whatever. It used to really confuse
me. Now I've learned to mentally replace "else" by "if nobreak", it confuses
me a bit less.
Rob Cliffe
On 12/10/2022 22:11, Weatherby,Gerard wrote:
As did I.
tree = ET.parse(lfile)
for child in tree.getroot():
if child.tag == 'server':
break
else:
raise ValueError(f"server tag not found in {lfile}")
I think there are other places I could be using it, but honestly I tend to
forget it’s available.
From: Python-list
on behalf of Stefan Ram
Date: Wednesday, October 12, 2022 at 2:22 PM
To: python-list@python.org
Subject: Re: for -- else: what was the motivation?
*** Attention: This is an external email. Use caution responding,
opening attachments or clicking on links. ***
Axy writes:
So, seriously, why they needed else if the following pieces produce
same result? Does anyone know or remember their motivation?
Just wrote code wherein I used "else"! This:
import locale
for name in( 'de', 'de_DE', 'deu_deu', 'deu', 'German', 'Deutsch' ):
try: locale.setlocale( locale.LC_ALL, name ); break
except locale.Error: pass
else: print( "Programm kann deutsche Schreibweise nicht einrichten." )
.
--
https://mail.python.org/mailman/listinfo/python-list
Re: for -- else: what was the motivation?
On Mon, 17 Oct 2022 at 03:57, Antoon Pardon wrote: > > > Op 16/10/2022 om 17:05 schreef Chris Angelico: > > On Sun, 16 Oct 2022 at 22:47, Antoon Pardon wrote: > >> Why would I need good luck? I expressed an idea and you didn't like it. > >> That won't affect my life in a meaningful way. > > Well, with that attitude, it's not going to affect anyone else's life > > either, so go ahead, carry on. > > What attitude? I just floated a little idea. It was not meant/expected to > affect anyone else's life. So why do you react as if it was? > You expressed an idea that you would like to see implemented in Python, and part of that idea was that people would be *obliged* to write their code using non-ASCII keywords. If that were to be implemented, it absolutely WOULD affect many people's lives. So if you're saying that your idea was not meant to affect anyone else's life, you are saying that you floated the idea fully intending for it to be ignored, which makes me wonder why you posted it in the first place. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: for -- else: what was the motivation?
On 2022-10-16 12:17:39 +0200, Antoon Pardon wrote: > Op 16/10/2022 om 00:50 schreef avi.e.gr...@gmail.com: > > That might not easily solve this problem. But I wonder if reserving > > some kind of prefix might help, so anything like extension.0nNoBreak > > could be added to a loop as a final clause and be treated as a > > non-key keyword of sorts. > > My idea would be to reserve different unicode blocks for the keywords and > the identifiers. e.g. We could reserve the mathematical alphanumeric block > for keywords and all other letters and numbers for identifiers. Doing so > would allow extenting the keywords without breaking programs that already > use that combination as an identifier. Or you could go back to the old Algol idea of underlining keywords. Both have the same problem, though: They make editing with an ordinary text editor pretty much impossible. You need a language-aware IDE which makes entering these characters or markups simple. Maybe even a specialized keyboard like they had for APL (or the Sinclair ZX computers which had special combinations for all the BASIC keywords). And if you go this way, why not go a step further and dissociate the program from its linear text representation? Add footnotes, different views, hyperlinks, format mathematical expressions like formulas, etc. hp -- _ | Peter J. Holzer| Story must make more sense than reality. |_|_) || | | | h...@hjp.at |-- Charles Stross, "Creative writing __/ | http://www.hjp.at/ | challenge!" signature.asc Description: PGP signature -- https://mail.python.org/mailman/listinfo/python-list
Re: for -- else: what was the motivation?
Op 16/10/2022 om 17:05 schreef Chris Angelico: On Sun, 16 Oct 2022 at 22:47, Antoon Pardon wrote: Why would I need good luck? I expressed an idea and you didn't like it. That won't affect my life in a meaningful way. Well, with that attitude, it's not going to affect anyone else's life either, so go ahead, carry on. What attitude? I just floated a little idea. It was not meant/expected to affect anyone else's life. So why do you react as if it was? -- Antoon Pardon -- https://mail.python.org/mailman/listinfo/python-list
Re: Find the path of a shell command [POSTPONED]
> On 16 Oct 2022, at 04:53, Dan Stromberg wrote: > > On Wed, Oct 12, 2022 at 9:57 PM Cameron Simpson wrote: > >>> On 13Oct2022 03:25, Paulo da Silva >>> wrote: >>> There is another problem involved. The script, works fine except when >>> launched by cron! Why? >> >> Record the script output: >> >> # record all output >> exec >/tmp/script.$$.out 2>&1 >> # dump the envionment >> env | sort >> # turn on execution tracing >> set -x >> ... rest of the script >> >> and have a look afterwards. Cron's environment is very minimal. This >> will show you what's in it. >> > > Careful. On some systems if someone restarts the cron daemon, it could > pick up a larger environment than after being started on boot. That have to a old system that does not use systemd. Is there a specific system that still does this? Barry > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: for -- else: what was the motivation?
On Sun, 16 Oct 2022 at 22:47, Antoon Pardon wrote: > > > > Op 16/10/2022 om 13:03 schreef Chris Angelico: > > On Sun, 16 Oct 2022 at 21:19, Antoon Pardon wrote: > > > >> My idea would be to reserve different unicode blocks for the keywords > >> and the identifiers. e.g. We could reserve the mathematical alphanumeric > >> block for keywords and all other letters and numbers for identifiers. > >> Doing so would allow extenting the keywords without breaking programs > >> that already use that combination as an identifier. > > Python currently defines identifiers as follows: > > https://docs.python.org/3/reference/lexical_analysis.html#identifiers > > > > Briefly, what it means is that (aside from some backward compatibility > > special cases) an identifier contains letters, numbers, and connector > > punctuation, and must not start with a number. It's not by blocks, > > it's by types. > > > > It's way WAY too late to change what's allowed for identifiers, as you > > will potentially be breaking programs that use the current rules. > > So? Python has broken backward compatibility before. The cost could > be acceptable. How many programs do you estimated use the mathematical > alphanumeric block for an identifier at this moment? > Why would I need good luck? I expressed an idea and you didn't like it. > That won't affect my life in a meaningful way. Well, with that attitude, it's not going to affect anyone else's life either, so go ahead, carry on. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: for -- else: what was the motivation?
Interesting idea, Anton. I would be interested in hearing more detail on how it would work. Although much of programming has been centered on the Latin alphabet and especially English, that may change. I can imagine a customized compiler or interpreter that uses key words in the local language instead of for or while or if or else or even import. If a region of UNICODE was set aside, would it have to be as a sort of additional ALT or shift key for anything, or just English characters or would it be for abstract symbols that would be mapped to and from a long list of reserved key words that may vary by locale? A serious problem I have been noting is the interactions between typographical paradigms never expected to interact. I mean special characters allowed or expected that clash. An example in Python and many other languages is regular expressions. When using a string of characters, you may have to deal with the rules for evaluating a string of that type and double up backslash characters or be carefully as a dollar sign or curly brace might invoke a side effect and interpolate something into it. But for languages that allow RE to be entered without a string as in /.../ you have to write it differently. I noted other ways in which naming conventions and even sort of keywords need special care. Consider a Javascript program in a browser that can read and manipulate HTML and CSS. The rules for names in JS do not allow hyphens while others often do. So the programmers making the structures in the DOM had to twist things. To access something like font-type you ask for font Type as an example by changing the identifier to camel case. I sometimes have programs that combine R and Python somewhat interchangeably and it highlights places the naming does not match. R allows periods as parts of names as in my.data and almost anything including spaces if you use grave accent quotes such as `one [identifier` so it is perfectly valid to have a function call like `[`(x, 5) to mean x[5] albeit explaining why that is useful is beyond the scope. Similarly you can make all kinds of in-line functions between percent signs as in %*% or %specialized computation% and you sort of make your own keywords albeit Chris and others may rightly suggest they are something else rather than the first level of syntax. My point is that your idea may need to support keywords for disparate ideas and languages. On Sun, Oct 16, 2022, 6:20 AM Antoon Pardon wrote: > Op 16/10/2022 om 00:50 schreef avi.e.gr...@gmail.com: > > This has been discussed so often precisely because I swear NO CHOICE of > keyword would satisfy everybody! Most languages start with designated > keywords and some reserve a few for later use. But then things can get > frozen in place to avoid breaking existing programs or break older > compilers/interpreters. > > > > Some languages use techniques to extend themselves more harmlessly such > as creating a singleton object that has content that can be regular data as > in math.pi, or functions/methods or new ides like "Symbols" that allow all > kinds of extensions to the language in a fairly harmless way as no older > program would likely have used features that did not exist. > > > > That might not easily solve this problem. But I wonder if reserving some > kind of prefix might help, so anything like extension.0nNoBreak could be > added to a loop as a final clause and be treated as a non-key keyword of > sorts. > > My idea would be to reserve different unicode blocks for the keywords > and the identifiers. e.g. We could reserve the mathematical alphanumeric > block for keywords and all other letters and numbers for identifiers. > Doing so would allow extenting the keywords without breaking programs > that already use that combination as an identifier. > > Python could slowly transition in this direction by first allowing the > current keywords to be in this block. Every new keyword would only be in > that unicode block. If would then be possible to write python code with > this convention but it wouldn't be obligatory. After some time the > python developers could decide to make it obligatory. > > I doubt this will idea will get from the ground, but I think it would > allow for a smoother transition into new concepts, as it is no longer a > strugle searching for a keyword that will break as little programs as > possible. > > -- > Antoon Pardon. > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: for -- else: what was the motivation?
Op 16/10/2022 om 13:03 schreef Chris Angelico: On Sun, 16 Oct 2022 at 21:19, Antoon Pardon wrote: My idea would be to reserve different unicode blocks for the keywords and the identifiers. e.g. We could reserve the mathematical alphanumeric block for keywords and all other letters and numbers for identifiers. Doing so would allow extenting the keywords without breaking programs that already use that combination as an identifier. Python currently defines identifiers as follows: https://docs.python.org/3/reference/lexical_analysis.html#identifiers Briefly, what it means is that (aside from some backward compatibility special cases) an identifier contains letters, numbers, and connector punctuation, and must not start with a number. It's not by blocks, it's by types. It's way WAY too late to change what's allowed for identifiers, as you will potentially be breaking programs that use the current rules. So? Python has broken backward compatibility before. The cost could be acceptable. How many programs do you estimated use the mathematical alphanumeric block for an identifier at this moment? Python could slowly transition in this direction by first allowing the current keywords to be in this block. Every new keyword would only be in that unicode block. If would then be possible to write python code with this convention but it wouldn't be obligatory. After some time the python developers could decide to make it obligatory. Obligatory??? Please explain how you intend to convince the entire world that non-ASCII code is an acceptable requirement. Explain to me how you're going to go to every text editor and ensure that it supports easy entry of Python keywords that aren't ASCII. And please explain how this is even better. Why should I do that? It seems you have already made your mind up. That is fine. It just makes explaining not very senseful. I doubt this will idea will get from the ground, but I think it would allow for a smoother transition into new concepts, as it is no longer a strugle searching for a keyword that will break as little programs as possible. Yeah it won't. Good luck though. Why would I need good luck? I expressed an idea and you didn't like it. That won't affect my life in a meaningful way. -- Antoon Pardon. -- https://mail.python.org/mailman/listinfo/python-list
Re: for -- else: what was the motivation?
On Sun, 16 Oct 2022 at 21:19, Antoon Pardon wrote: > > Op 16/10/2022 om 00:50 schreef avi.e.gr...@gmail.com: > > This has been discussed so often precisely because I swear NO CHOICE of > > keyword would satisfy everybody! Most languages start with designated > > keywords and some reserve a few for later use. But then things can get > > frozen in place to avoid breaking existing programs or break older > > compilers/interpreters. > > > > Some languages use techniques to extend themselves more harmlessly such as > > creating a singleton object that has content that can be regular data as in > > math.pi, or functions/methods or new ides like "Symbols" that allow all > > kinds of extensions to the language in a fairly harmless way as no older > > program would likely have used features that did not exist. > > > > That might not easily solve this problem. But I wonder if reserving some > > kind of prefix might help, so anything like extension.0nNoBreak could be > > added to a loop as a final clause and be treated as a non-key keyword of > > sorts. > > My idea would be to reserve different unicode blocks for the keywords > and the identifiers. e.g. We could reserve the mathematical alphanumeric > block for keywords and all other letters and numbers for identifiers. > Doing so would allow extenting the keywords without breaking programs > that already use that combination as an identifier. Python currently defines identifiers as follows: https://docs.python.org/3/reference/lexical_analysis.html#identifiers Briefly, what it means is that (aside from some backward compatibility special cases) an identifier contains letters, numbers, and connector punctuation, and must not start with a number. It's not by blocks, it's by types. It's way WAY too late to change what's allowed for identifiers, as you will potentially be breaking programs that use the current rules. > Python could slowly transition in this direction by first allowing the > current keywords to be in this block. Every new keyword would only be in > that unicode block. If would then be possible to write python code with > this convention but it wouldn't be obligatory. After some time the > python developers could decide to make it obligatory. Obligatory??? Please explain how you intend to convince the entire world that non-ASCII code is an acceptable requirement. Explain to me how you're going to go to every text editor and ensure that it supports easy entry of Python keywords that aren't ASCII. And please explain how this is even better. > I doubt this will idea will get from the ground, but I think it would > allow for a smoother transition into new concepts, as it is no longer a > strugle searching for a keyword that will break as little programs as > possible. Yeah it won't. Good luck though. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: for -- else: what was the motivation?
Op 16/10/2022 om 00:50 schreef avi.e.gr...@gmail.com: This has been discussed so often precisely because I swear NO CHOICE of keyword would satisfy everybody! Most languages start with designated keywords and some reserve a few for later use. But then things can get frozen in place to avoid breaking existing programs or break older compilers/interpreters. Some languages use techniques to extend themselves more harmlessly such as creating a singleton object that has content that can be regular data as in math.pi, or functions/methods or new ides like "Symbols" that allow all kinds of extensions to the language in a fairly harmless way as no older program would likely have used features that did not exist. That might not easily solve this problem. But I wonder if reserving some kind of prefix might help, so anything like extension.0nNoBreak could be added to a loop as a final clause and be treated as a non-key keyword of sorts. My idea would be to reserve different unicode blocks for the keywords and the identifiers. e.g. We could reserve the mathematical alphanumeric block for keywords and all other letters and numbers for identifiers. Doing so would allow extenting the keywords without breaking programs that already use that combination as an identifier. Python could slowly transition in this direction by first allowing the current keywords to be in this block. Every new keyword would only be in that unicode block. If would then be possible to write python code with this convention but it wouldn't be obligatory. After some time the python developers could decide to make it obligatory. I doubt this will idea will get from the ground, but I think it would allow for a smoother transition into new concepts, as it is no longer a strugle searching for a keyword that will break as little programs as possible. -- Antoon Pardon. -- https://mail.python.org/mailman/listinfo/python-list
