On Thu, May 10, 2018 at 6:34 PM, Mikhail V <mikhail...@gmail.com> wrote: > On Wed, May 9, 2018 at 6:25 AM, Steven D'Aprano > <steve+comp.lang.pyt...@pearwood.info> wrote: >> On Tue, 08 May 2018 23:16:23 +0300, Mikhail V wrote: >> > >>> but I propose Tab-separated elements. >> >> We already have tab-separated elements in Python. It is allowed to use >> tabs between any whitespace separated tokens. > > Yes, exactly. So in the proposed syntactic construct, it is *not* > allowed to insert tabs between _any_ tokens. > Namely if you will insert tabs _inside_ equations, > like: > a + b
Then these are not ordinary expressions, are they? They're a different type of expression and will require a modified parser. This adds complexity. >>> If I allow commas as well, this will become not so simple, probably. >>> Also I don't propose syntax for e-mail code exchange, but rather syntax >>> for *work* an this can potentially help a lot of people in everyday >>> work. >> >> /head-desk >> >> You: "I have invented amazing new syntax that cannot be exchanged by >> email. Here, let me email some examples to you." > > "GvR have invented amazing new syntax that cannot be preserved > by sending it by e-mail"! > (not me) > > Do you understand that basically any python code sent by e-mail converts tabs > to > spaces, thus the only way to receive it - is to send binary file? Um, no, this is false. We send Python code by email all the time. There are essentially three cases of tabs that can occur in Python: 1) Tabs as indentation: Python permits the use of both tabs and spaces as indentation, but it requires consistency; if one line is indented with a tab and three spaces, then the next line in the same block must also use a tab and three spaces. Therefore, if the tabs are converted to spaces, they will be converted to the same number of spaces throughout the block. Indents and dedents remain intact, indentation is therefore not ruined, and the meaning of the program is not changed. 2) Tabs as other whitespace: Other tabs in the program, such as in expressions, don't matter at all. They can safely be replaced with spaces, and the meaning of the program is not changed. 3) Tabs that appear in strings: This one I'll grant you. A replaced tab inside a string may alter the meaning of the program. However, note two things: tabs are rarely used in strings, and when they do appear it's usual to write them as \t rather than with an actual tab character. In any case, the use of tabs is entirely optional. For the most part, programs can be safely emailed whether they contain tabs or not, the exception being tabs in strings which are better written as \t. In the case of your proposed syntax however, the tabs are *required*, and it is not possible to email a program containing such a construct at all. Contrary to your assertion, this is *far* different from the status quo. >>> Also I don't know what kind of human thinks that this: >>> a + b >>> is two elements "a" and "+ b" >>> What is "+ b"? >> >> It is unary plus followed by b. >> >> If you don't know Python's existing syntax, how can you possibly expect >> to invent new syntax? > > Wow! Uncle Steven knows Python operators. > My question was: why would you have "+ b" in > the first place in your code? So you treat the worst-case scenario > as a normal case - interesting approach indeed! When you're designing a language syntax, you need to account for *all* the cases, not just the ones that you personally would use. > By the way, since you are into unrealistic worst-case scenarios: > Imagine you start with Python learning, how you'd like such constructs: > > L = [a + b, c, d] > L = [a + b, (c, d)] > > For a starter, reading this will be quite painful. I don't know, I find that much less painful than: L === T: a + b c d > Yes, I have told already that there are _some_ cases when > tabulation formatting can cause visual confusion. > *But why do you blame me*? > It just the issues with editor's incompleteness. > Simple feature like "set the minimal tab size" would have solved > this issue by 100%. Maybe it even exists in some editors, > I would not be surprised at least. That's great, but if I'm editing a file on an embedded system over a serial port and the only editor I have available is nano, I should be able to use it. You can't just assume that everybody has a fully featured editor (and knows how to use it -- what was that point you made just above about beginners?) > I hope you are not seriously thinking that there is good syntax > that gives retro-tools, wacky people, not wacky people, > pros, etc. same opportunities. Why not? The existing Python syntax is fine for this. > For instance, there is real demand on adding new control characters > to syntax, so as IDE developers can utilize those for making > better user experience. If you apply same one-sided principles here > then you behave good to one group of people, but just ignorant > to other group of people who want better new experience. Please link the approved PEP that is going to add syntactically meaningful control characters. >>> I don't want spaces or tabs visible - there is toggle "show tabs" >>> and "toggle show space" for that >> >> /head-desk >> >> You: "This syntax doesn't need tabs and spaces to be visible. Just use >> the Show Tabs and Show Spaces commands on your editor to make them >> visible." > > Yep! Just toggle them if you want to find out. That's a good feature! Needing to fiddle with editor settings in order to determine how the code in front of me that somebody else wrote is organized doesn't sound to me like a good feature. That sounds to me like poor readability. >>>> - the first one can include nested data structures, while >>>> the second cannot. >>> >>> Why it can't? did you read the original e-mail? >> >> Of course I did. You said: >> >> "So the idea is to cover only first two levels of >> nesting of course." >> >> With bracket syntax, I can cover unlimited levels of nesting. Yours >> cannot. > > Ok, that was a typo, it must be: > > "So the idea is to _hide brackets for_ first two levels of > nesting of course." In other words, this syntax is really not appropriate for more than two levels of nesting due to the mental gymnastics required to keep track of how the current level of nesting should be expressed. -- https://mail.python.org/mailman/listinfo/python-list