On Wed, Jan 06, 2021 at 10:38:30AM +0300, Paul Sokolovsky wrote:
Hello,
On Tue, 5 Jan 2021 14:29:03 +0100 Ronald Oussoren ronaldoussoren@mac.com wrote:
[]
In this regard, braces aren't worse than average other stuff posted here. Actually, it might be a bit more interesting, as it clearly moved people throughout the years.
That’s questionable. The primary reason I’ve seen so far is folks that dislike significant whitespace or mis the braces in they had in other languages (to put it bluntly).
My experience is like Ronald. I've seen arguments that semicolons and braces are better, because they are resilient to being transmitted over lossy channels that delete leading and trailing whitespace.
Indeed. And I daresay that we could invent syntax that would survive transmission over lossy channels that deletes braces, or for that matter vowels and digits, too.
Or we could stop using lossy channels to transmit source code, and stop designing our syntax to work around buggy-by-design software.
I sympathise with people forced to use tools that mangle their source code, but not enough to want to insert a semicolon after after line and braces surrounding every block.
And I've seen the primary reason to be able to write complex one-liners and multi-statement lambdas. Talk about the difference in perception, everyone sees what they want to see!
Complex one-liners are an anti-pattern, not something we ought to encourage. I'm glad that things like Perl one-liners, obfuscated C, and sewerage treatment works exist, but I don't want them in my community where I have to look at them every day.
Multi-statment anonymous functions are, in my opinion, overrated, and a (slight) code smell. If your lambda is so complex it requires more than a single expression, shouldn't it have documentation and tests?
I don't think this is an example of the Blub paradox. I can see that there are uses for such multi-statement lambdas, but I don't think that the benefits outweigh the costs. The benefits exist in the small niche:
- code that could be an anonymous function; - and the code is complex enough to require multiple statements; - but not so complex that it needs testing or documentation; - or an informative function name for debugging; - and putting it into a named function is a non-trivial burden; - perhaps because there is no appropriate self-descriptive name.
But as Chris has noticed there’s about 0 chance that any proposal for adding braces as an optional feature will be accepted. A lot of other proposals also have little chance of being accepted, but they do inform development of either the language or some library.
That's exactly the case for "python with braces" - "to inform".
So is it your intention to write a PEP suggesting braces, specifically to be rejected? If not, then what is your intention?
Did anybody talked about anything else on this thread? I didn't notice. Myself, I posed very specific question: was there a more or less formal proposal for braces syntax ever posted? I got my answer (only one person in the discussion bothered to answer to the actual topic of discussion, not just something related).
*shrug*
Fair enough, but this is Python-Ideas, are you surprised that we treated this as an idea for discussion? That's the purpose of this mailing list. And very early in this thread you started discussing the advantages of braces, reinforcing the impression that you wanted a discussion.
Having an formal alternative syntax at the very least sends out the signal that the language designers think that this is a good idea, and from what I’ve read in the past that’s not going to happen.
Reading that, it seems that when you read "formal proposal", you picture some old wise men in extravagant attires and headdresses, who got an exclusive and irrevocable license to write formal proposals.
I don't know about anyone else, but when I was writing my PEPs, I always wore morning dress instead of the usual trackie dacks and tshirt I'm wearing now. Evening dress would be excessive of course, but one must keep up standards.