[Python-ideas] Re: Revise using the colon ( : )

2023-09-20 Thread Dom Grigonis
My bad, you have pointed to ambiguity accurately.

Thanks for taking time to correct me.

Regards,
DG

> On 20 Sep 2023, at 16:09, Celelibi  wrote:
> 
> 2023-09-12 7:10 UTC+02:00, Dom Grigonis :
>> I don’t think your example depicts the ambiguity well.
>> 
>> 1. is the correct parsing of the Original1, 2. is the correct parsing of
>> Original2 and 3. is not correct for either of those.
>> 
>> Original1
>>> while a < b (x := c) - 42
>> Original2
>>> while a < b(x := c) - 42
> 
> They're the same. AFAIK `foo(...)` and `foo (...)` are parsed exactly
> the same way. A space in this place is irrelevant. And it's unlikely
> to change in the next few decades.
> 
>> 
>> 1. In this case, it’s obviously this one
>>> while a < b:
>>>   (x := c) - 42
> 
> Why tho? Why would this one be more obvious than the other
> alternatives? What would be the rules to decide? If I may quote the
> PEP 20:
>> In the face of ambiguity, refuse the temptation to guess.
> 
>> 2. In here your removed the space, which is not ambiguity, but rather
>> mistype
> Again, the space in this place doesn't matter. I removed it to show
> more explicitely how it could be parsed.
> 
>> 3. Same as in 2. But also, this is not an option, because if there was no
>> indent on the next line, then body exists. So this is incorrect.
>>> Or:
>>> while a < b(x := c) - 42:
>>>   # ???
> 
> I actually think this is the better parsing of the three: a SyntaxError.
> 
> 
> Celelibi
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-ideas@python.org/message/WSOJIXRMEYCNQGVNABPCJJ4S23PB6X4L/
> Code of Conduct: http://python.org/psf/codeofconduct/

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/RQBYA3FMKBL6OXZWJ55XAT26CKOPH7EU/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-ideas] Re: Revise using the colon ( : )

2023-09-20 Thread Celelibi
2023-09-12 7:10 UTC+02:00, Dom Grigonis :
> I don’t think your example depicts the ambiguity well.
>
> 1. is the correct parsing of the Original1, 2. is the correct parsing of
> Original2 and 3. is not correct for either of those.
>
> Original1
>> while a < b (x := c) - 42
> Original2
>> while a < b(x := c) - 42

They're the same. AFAIK `foo(...)` and `foo (...)` are parsed exactly
the same way. A space in this place is irrelevant. And it's unlikely
to change in the next few decades.

>
> 1. In this case, it’s obviously this one
>> while a < b:
>>(x := c) - 42

Why tho? Why would this one be more obvious than the other
alternatives? What would be the rules to decide? If I may quote the
PEP 20:
> In the face of ambiguity, refuse the temptation to guess.

> 2. In here your removed the space, which is not ambiguity, but rather
> mistype
Again, the space in this place doesn't matter. I removed it to show
more explicitely how it could be parsed.

> 3. Same as in 2. But also, this is not an option, because if there was no
> indent on the next line, then body exists. So this is incorrect.
>> Or:
>> while a < b(x := c) - 42:
>># ???

I actually think this is the better parsing of the three: a SyntaxError.


Celelibi
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/WSOJIXRMEYCNQGVNABPCJJ4S23PB6X4L/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-ideas] Re: Revise using the colon ( : )

2023-09-11 Thread Dom Grigonis
I don’t think your example depicts the ambiguity well.

1. is the correct parsing of the Original1, 2. is the correct parsing of 
Original2 and 3. is not correct for either of those.

Original1
> while a < b (x := c) - 42
Original2
> while a < b(x := c) - 42

1. In this case, it’s obviously this one
> while a < b:
>(x := c) - 42
2. In here your removed the space, which is not ambiguity, but rather mistype
> Or:
> while a < b(x := c):
>-42
3. Same as in 2. But also, this is not an option, because if there was no 
indent on the next line, then body exists. So this is incorrect.
> Or:
> while a < b(x := c) - 42:
># ???

Having that said, I think readability suffers a lot from not having a colon and 
as you indicated potentially makes parser’s job harder.

Dg.

> On 11 Sep 2023, at 20:11, Celelibi  wrote:
> 
> 2023-09-05 18:26 UTC+02:00, Dom Grigonis  >:
>> I like the idea of eliminating it if it was possible. This is one of my most
>> common syntax errors (although mostly after function signature) and I am not
>> C/C++ programmer. I am not sure about the core technical issues, but
>> readability of code, such as:
>> a = 1
>> while a < 5: a += 1
>> , would suffer:
>> a = 1
>> while a < 5 a += 1
>> So IMO, it does improve readability in certain cases.
>> 
>> Although, removing colon does sound like an idea worth thinking about. I
>> might even dare to suggest disallowing body statement on the same line, but
>> can’t do that for backwards compatibility ofc...
>> 
>> So my point is, if anyone is going to give a thought about this, please add
>> function signature to the list.
>> 
> 
> I just want to mention that without colons, one-liners could become ambiguous:
> while a < b (x := c) - 42
> 
> Is it:
> while a < b:
>(x := c) - 42
> 
> Or:
> while a < b(x := c):
>-42
> 
> Or:
> while a < b(x := c) - 42:
># ???
> 
> If anything, the colon would become optional but would definitely
> remain in the grammar. Kinda like the semi-colon, only used in
> one-liners.
> 
> When teaching python I noticed the usual uselessness of the colon
> regarding the correct parsing of correctly indented code.
> But I've never seen it as a burden and rarely if ever forgot one. It
> also allows code editors to be very simple: you see a line ending with
> a colon, you indent the next line. The keyword at the begining of the
> line doesn't matter.
> 
> Best regards,
> Celelibi
> ___
> Python-ideas mailing list -- python-ideas@python.org 
> 
> To unsubscribe send an email to python-ideas-le...@python.org 
> 
> https://mail.python.org/mailman3/lists/python-ideas.python.org/ 
> 
> Message archived at 
> https://mail.python.org/archives/list/python-ideas@python.org/message/UL3FSZWUKOVUASIPM46IPQIQPJ7GEV7Q/
>  
> 
> Code of Conduct: http://python.org/psf/codeofconduct/ 
> 
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/JQGUO6WQ4Y6H4CYNRG7W6AORWKA2TCAE/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-ideas] Re: Revise using the colon ( : )

2023-09-11 Thread Stephen J. Turnbull
Celelibi writes:
 > I just want to mention that without colons, one-liners could become
 > ambiguous:

I have no sympathy for optional colons.  No colons, no one-liners.

(Of course optional colons are a great strategy for trying it out, but
in your test programs you should maintain no-colon discipline.)

STeve
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/B46LYKE7W5XHDUDTFA75OI2NIR25ISWI/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-ideas] Re: Revise using the colon ( : )

2023-09-11 Thread Celelibi
2023-09-05 18:26 UTC+02:00, Dom Grigonis :
> I like the idea of eliminating it if it was possible. This is one of my most
> common syntax errors (although mostly after function signature) and I am not
> C/C++ programmer. I am not sure about the core technical issues, but
> readability of code, such as:
> a = 1
> while a < 5: a += 1
> , would suffer:
> a = 1
> while a < 5 a += 1
> So IMO, it does improve readability in certain cases.
>
> Although, removing colon does sound like an idea worth thinking about. I
> might even dare to suggest disallowing body statement on the same line, but
> can’t do that for backwards compatibility ofc...
>
> So my point is, if anyone is going to give a thought about this, please add
> function signature to the list.
>

I just want to mention that without colons, one-liners could become ambiguous:
while a < b (x := c) - 42

Is it:
while a < b:
(x := c) - 42

Or:
while a < b(x := c):
-42

Or:
while a < b(x := c) - 42:
# ???

If anything, the colon would become optional but would definitely
remain in the grammar. Kinda like the semi-colon, only used in
one-liners.

When teaching python I noticed the usual uselessness of the colon
regarding the correct parsing of correctly indented code.
But I've never seen it as a burden and rarely if ever forgot one. It
also allows code editors to be very simple: you see a line ending with
a colon, you indent the next line. The keyword at the begining of the
line doesn't matter.

Best regards,
Celelibi
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/UL3FSZWUKOVUASIPM46IPQIQPJ7GEV7Q/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-ideas] Re: Revise using the colon ( : )

2023-09-05 Thread Dom Grigonis
I like the idea of eliminating it if it was possible. This is one of my most 
common syntax errors (although mostly after function signature) and I am not 
C/C++ programmer. I am not sure about the core technical issues, but 
readability of code, such as:
a = 1
while a < 5: a += 1
, would suffer:
a = 1
while a < 5 a += 1
So IMO, it does improve readability in certain cases.

Although, removing colon does sound like an idea worth thinking about. I might 
even dare to suggest disallowing body statement on the same line, but can’t do 
that for backwards compatibility ofc...

So my point is, if anyone is going to give a thought about this, please add 
function signature to the list.


— One small step towards deferred evaluation, one huge leap for… —
Dg

> On 1 Sep 2023, at 13:26, Morteza Mirzakhan  
> wrote:
> 
> Dear Python Developers,
> 
> I would like to share my thoughts on the use of the colon mark “:” in Python 
> code.
> 
> In my opinion, using a colon after keywords such as `if`, `elif`, `else`, 
> `for`, `while`, `try`, `except`, and `finally` is quite unnecessary.
> 
> Using mandatory indentation in Python to group commands into a block is 
> similar to how curly braces `{}` are used in ‘curly-bracket languages’ like 
> C-family, Perl, Java, PHP, etc. to group multiple commands into a single 
> statement.
> 
> While those compilers don't differentiate between one or more ‘space’ or 
> ‘return’ characters, so they don't recognize new lines and indents, the 
> indentation is also used, not forced but traditionally, to increase 
> readability. However, when it comes to writing just one instruction after the 
> head command, you can omit the curly braces `{}` and simply write it in a new 
> line, traditionally indented in C-family languages.
> 
> So Python is one step forward by not requiring curly braces `{}` whether the 
> block includes one or more lines.
> 
> In contrast, the requirement to use a colon after those keywords in Python is 
> a drawback!
> 
> The colon “:” doesn't improve readability but adds unnecessary complexity, 
> increases the potential for errors, and requires more effort to code. This is 
> because the requirement does not have a logical meaning while the block is 
> made obvious by indentation, so coders may forget to include the colon and 
> face errors.
> 
> This can be particularly frustrating for those who are used to coding in 
> languages such as C and C++, where blocks of code are traditionally indented 
> and no curly braces `{}` are used when the following tail is a singe-command 
> instruction.
> 
> The suggestion is removing the need by interpreter for the use of colon after 
> keyword syntaxes (and making it optional due to Backward Compatibility) in 
> the new revision of Python.
> 
> I believe this change would make Python code easier to read, less prone to 
> errors, and require less effort to code.
> 
> Thank you for your time and attention.
> 
> Best regards,
> Morteza Mirzakhan 
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-ideas@python.org/message/E7LCNY6LBWQ5HHI6BHWRDXFE2MMIBZCC/
> Code of Conduct: http://python.org/psf/codeofconduct/

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/TH2SHGK6FIVBPUSWCUW42VMWNDEOLLTR/
Code of Conduct: http://python.org/psf/codeofconduct/