Hello, On Mon, 4 Jan 2021 21:47:26 +1100 Chris Angelico wrote:

On Mon, Jan 4, 2021 at 9:41 PM Paul Sokolovsky wrote:

...

Hello,

There're tons of projects which introduce alternative braces (i.e. C-like) syntax for Python. Most of them are however not properly documented, and definitely not spec'ed for what they do.

I wonder, does anyone here remember more or less formal proposal for braces syntax? A "minimum viable product" criteria would be support for lossless indent -> braces -> indent syntax roundtripping.

...

...

...

from __future__ import braces File "<stdin>", line 1 SyntaxError: not a chance

Old, sour, buggy implementation from previous century. https://github.com/search?q=python+braces shows a bunch of projects ranging from 2013 from 2020-11 which add alternative braces syntax to Python, and that's only on Github (I'm sure it starts 1990-something). So people, did, do, and will add braces syntax to Python. Which leads us back to the question - did anyone of those who did that over decades ever bothered to post some kind of "spec" for this alternative syntax? For example, Scheme has alternative syntax encoded as officially incorporated "RFC document" (similar to Python's PEP): https://srfi.schemers.org/srfi-119/srfi-119.html (actually, as quick glance there shows, there was an evolution of alternative syntaxes). -- Best regards, Paul mailto:pmiscml@gmail.com

Hello, On Mon, 4 Jan 2021 14:09:30 +0200 Alex Hall wrote:

On Mon, Jan 4, 2021 at 1:30 PM Paul Sokolovsky wrote:

...

Which leads us back to the question - did anyone of those who did that over decades ever bothered to post some kind of "spec" for this alternative syntax?

Is there a lot that needs to be specified?

Well, I surely don't expect such a "spec" to be split in 3 parts, like the pattern matching proposal. (Wait, isn't pattern matching is also simple? An expression, block scope - all those are obvious ;-)). On the other hand, previously mentioned Scheme proposal does have some size in it: https://srfi.schemers.org/srfi-119/srfi-119.html , and an improvement over 2 previous specs, so there's certainly something to spec out, to explain choices available, and argue specific selections made.

I imagine that the braces would correspond to the special INDENT and DEDENT tokens in the grammar and that's the bulk of the problem solved.

Aye, except the beginning is solved.

The only remaining questions I can think of are whether you would want to keep the colons that initiate indented blocks and how to deal with ambiguity between the new blocks and existing uses of braces like set displays.

Yes, and how do we deal with the ambiguity? As I mentioned, I'd consider an MVP a syntax which allows full rountripping [on lexical level] for initial indent-based code.

Anything else?

I don't know, that's why I ask. I hate NIH and would rather start with prior art before giving my try. Otherwise, there're issues with existing implementations, e.g.: https://github.com/nekitdev/braces.py : ========= There is a known limitation in braces.py. That is, indentation like this does NOT work: def f(x) { return x; } ========= That's not compliant implementation by any reasonable spec, so where's the spec in the first place? -- Best regards, Paul mailto:pmiscml@gmail.com

Hello, On Tue, 5 Jan 2021 10:07:45 +0100 Ronald Oussoren wrote:

...

On 4 Jan 2021, at 12:29, Paul Sokolovsky wrote:

Hello,

On Mon, 4 Jan 2021 21:47:26 +1100 Chris Angelico mailto:rosuav@gmail.com> wrote:

...

On Mon, Jan 4, 2021 at 9:41 PM Paul Sokolovsky wrote:

...

Hello,

There're tons of projects which introduce alternative braces (i.e. C-like) syntax for Python. Most of them are however not properly documented, and definitely not spec'ed for what they do.

I wonder, does anyone here remember more or less formal proposal for braces syntax? A "minimum viable product" criteria would be support for lossless indent -> braces -> indent syntax roundtripping.

...

...

...

from __future__ import braces File "<stdin>", line 1 SyntaxError: not a chance

Old, sour, buggy implementation from previous century.

This is more a signal that you are far from the first person asking about braces in Python, and what the general opinion from the language designers is about this.

IMHO it is highly unlikely that any proposal about adding braces to Python would be accepted.

And you seem to have 2nd level miss about this miss. I'm not the 1st asking about braces in Python, hundreds of people embraced braces (sorry for the pun) in Python for decades (references are in other messages of this thread). Apparently, they forgot to ask for "acceptance", and accepted it themselves. The problem? There's high duplication of effort in that area, and the same implementation bugs are repeated again and again. So the question is whether someone who did it, tried to spec out what they did, what is the test process, etc. -- Best regards, Paul mailto:pmiscml@gmail.com

Hello, On Tue, 5 Jan 2021 21:03:06 +1100 Chris Angelico wrote:

On Tue, Jan 5, 2021 at 8:32 PM Paul Sokolovsky wrote:

...

And you seem to have 2nd level miss about this miss. I'm not the 1st asking about braces in Python, hundreds of people embraced braces (sorry for the pun) in Python for decades (references are in other messages of this thread). Apparently, they forgot to ask for "acceptance", and accepted it themselves.

The problem? There's high duplication of effort in that area, and the same implementation bugs are repeated again and again. So the question is whether someone who did it, tried to spec out what they did, what is the test process, etc.

So my question to you is: Why raise all these threads on python-ideas that have approximately zero chance of being accepted into the core language?

Simple question, simple answer: majority of stuff posted on python-ideas has approximately zero chance of being accepted into the core language. 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.

Why not create a new community of Bracey Python people, and build a language and an ecosystem around that?

Is it because you think that you wouldn't get enough people? Because... that would be a good reason not to do it, and a good reason for the core language to continue to not do it.

There were good reasons to not have string interpolation in the core language for decades then - KABOOM - there's string interpolation. You see a pattern yet? No? Oh, let's just keep watching. For everyone else who misses the point: the talk is about *alternative* (second) syntax. Nothing happens to the main indent-based syntax. Only people who need braces syntax would use it, just as they have been doing for decades. Whether a particular implementation (it's a common joke on the Python lists to mistake a language and a particular implementation) supports alternative syntax out of the box is irrelevant. It's no more different to having a separate typechecker or a separate script to run venv in a subshell (a recent case brought up here on the list).

ChrisA

-- Best regards, Paul mailto:pmiscml@gmail.com

Hello, On Tue, 5 Jan 2021 23:22:03 +1100 Chris Angelico wrote:

On Tue, Jan 5, 2021 at 9:38 PM Paul Sokolovsky wrote:

...

There were good reasons to not have string interpolation in the core language for decades then - KABOOM - there's string interpolation. You see a pattern yet? No? Oh, let's just keep watching.

Do you have evidence from the language itself, or from the BDFL, that string interpolation was out of the question? If not, then that's why I'm not seeing the pattern or correlation.

Yes, most people came to Python from other languages like Perl and PHP, which had string interpolation "forever". Request for such in Python were also around forever, I remember them since 1.5.1, when I chose Python as my language of choice. Nothing could prevent them being implemented in 1.5.2, but they were rejected exactly as not fitting Python's model of "explicit is better than implicit" (i.e. if you want to format, do format, do abuse normally looking strings with formatting magicity) and "there's one way to do it" (Python has the way to format strings - % operator, use it). Then, suddenly... Anyway, this went offtopic wrt to the original subject. In attempt to bring it back to topic, let me risk telling a fable. A fable about my friend-by-correspondence Chris (more like mind opponent). As a prelude though, scientific studies show that every programmer has a need for some braces in their life. If they don't receive a doze of braces for a while, it may bulge and break down. Most programmers receive enough doze from C/C++, younger generation from JavaScript. My friend Chris, he's more interesting. He self-describes as "Python and [censored] tutor, [irrelevant] addict, and Pike fanatic." That Pike, I immediately recognize it. Remember that choosing-a-language-of-choice event described above, culminated with selecting Python as of 1.5.1? Well, Pike was among the contenders too. Glad to hear it's alive and well. So, what can we tell to Chris? I guess "We're glad for you, that your braces needs are covered by Pike, but why are you so cruel to Python fanatics, who want braces right in Python? And just don't tell that braces from dict literals should be enough, we want more, we want one-liners with a bunch of if's and while's, we want multi-statement lambdas, we want it all." I hope you found the fable enjoyable, and not devoid of some moral. -- Best regards, Paul mailto:pmiscml@gmail.com

On 5 Jan 2021, at 11:38, Paul Sokolovsky wrote:

Hello,

On Tue, 5 Jan 2021 21:03:06 +1100 Chris Angelico mailto:rosuav@gmail.com> wrote:

...

On Tue, Jan 5, 2021 at 8:32 PM Paul Sokolovsky wrote:

...

And you seem to have 2nd level miss about this miss. I'm not the 1st asking about braces in Python, hundreds of people embraced braces (sorry for the pun) in Python for decades (references are in other messages of this thread). Apparently, they forgot to ask for "acceptance", and accepted it themselves.

The problem? There's high duplication of effort in that area, and the same implementation bugs are repeated again and again. So the question is whether someone who did it, tried to spec out what they did, what is the test process, etc.

So my question to you is: Why raise all these threads on python-ideas that have approximately zero chance of being accepted into the core language?

Simple question, simple answer: majority of stuff posted on python-ideas has approximately zero chance of being accepted into the core language.

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). 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. In some sense reading about problems folks run into with the language are in general more interesting than full formed ideas because most of us aren’t very good language designers (and I count myself in that category).

...

Why not create a new community of Bracey Python people, and build a language and an ecosystem around that?

Is it because you think that you wouldn't get enough people? Because... that would be a good reason not to do it, and a good reason for the core language to continue to not do it.

There were good reasons to not have string interpolation in the core language for decades then - KABOOM - there's string interpolation. You see a pattern yet? No? Oh, let's just keep watching.

I don’t agree, in hindsight there’s a clear path to the introduction of f-strings. There’s also loads of features that have been proposed for a long while and never were added to the language, and never will for one reason or another. Anyways… That some unrelated feature was accepted is not an argument in favour of this feature.

For everyone else who misses the point: the talk is about *alternative* (second) syntax. Nothing happens to the main indent-based syntax. Only people who need braces syntax would use it, just as they have been doing for decades.

They can continue to use a 3th-party project for that. 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.

Whether a particular implementation (it's a common joke on the Python lists to mistake a language and a particular implementation) supports alternative syntax out of the box is irrelevant. It's no more different to having a separate typechecker or a separate script to run venv in a subshell (a recent case brought up here on the list).

That folks are mistaken about the distinction between the language and an implementation is to be expected, that happens with formally standardised languages as well (my code works with compiler X and not with compiler Y, therefore compiler Y is broken). Ronald — Twitter / micro.blog: @ronaldoussoren Blog: https://blog.ronaldoussoren.net/

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 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. -- Steve

Hello, On Wed, 6 Jan 2021 22:12:53 +1100 Chris Angelico wrote: []

But Paul's recent track record of proposals isn't like that. They're not part of the language.

Everything was not part of the language, until it became. And "a language" is multi-level structure in the first place. For example, module "audioop" is not part of *the language*, it's part of *the language stdlib*. And more and more voices are heard to treat such modules not as the part of *the language stdlib*, but a part of *particular implementation's bundled library*, which might even got there by accident in the first place, and treat them correspondingly: https://www.python.org/dev/peps/pep-0594/ Again, do you see a pattern here? Some things which you think as "part of the language" are actually not. Can you imagine the opposite possibility - some things are much more related to "the language" (outer layers of it) than proverbial audioop?

If I start a thread recommending that Python's int type be redefined as a 19-bit signed integer with twos complement semantics, would that be received as a sane proposal, or would people say "no, Python's integer won't change semantics, go make your own fork"?

That's why I never started such a thread ;-). But I imagine us having a discussion one of these years, about "what is the syntactic way to switch default implementation of the 'int' type for the whole runtime?"

ChrisA

-- Best regards, Paul mailto:pmiscml@gmail.com

Hello, On Wed, 6 Jan 2021 21:24:28 +1100 Steven D'Aprano 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.

I personally don't think that it's "better", it's just different syntactic paradigm, with different set of tradeoffs. Note that "indentation" paradigm won in spirit almost everyone - not properly indented source code is considered a bad thing almost universally. The common sentiments is that from there starts "the right level of indentation and brace placement wars", but Go with its format dictatorship on the language toolchain level showed how to "resolve" that: just establish one particular (hopefully, well thought out) codestyle by fiat, so anyone who try to use something different would look "antisocial". The whole point though is that if you *need* to break the rules, and e.g. write a one-liner with a couple of if's, and couple of while's, with braces syntax you just can, and with indent syntax, you just can't. That's the reason why most new languages are continued to be created with braces syntax. And it's similar argument too: almost every imperative language is also functional, but quite not every functional language is also imperative. So, functional languages remain niche, while multi-paradigm languages thrive. []

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.

Note that semicolons are now almost universally frowned upon. And I don't envision braces syntax for Python to require semicolons more than Python already has them. You see, I take that for granted, but it may be not immediately obvious. That's why it would be nice to have a "spec" which writes that down explicitly.

...

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.

If you say that, you either have in mind a rather partial view of language usecases, or just an uptight control freak ;-). You probably picture large beautiful corporate codebases (should give giggles to everyone familiar with real corporate codebases). While I picture myself typing in the random crappy REPL without any multiline support something like: dbg.hook(read=lambda a {if a == 1234 {print("foo!")} }, write=lambda a {if a == 5678 {print("bar!")} }) (re: Frida usecase mentioned previously) And I find absolutely nothing wrong with me typing stuff like that while deeply debugging some hard case. In that regard, as of 3.9, CPython, has absolutely atrocious REPL support for its own syntax. It's just barely possible at all to type multi-line statement, but doing that as painful as hell, and after typing, editing is not possible. Compare that with MicroPython, which had auto-indent and easy dedent for years (but still lacks multiline editing, yeah). It's absolutely a SHAME that CPython has REPL like that, and you need to install 3rd-party tools to get basic workable REPL. Such situation with REPL *alone* is a good reason to want braces syntax :-D.

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?

Not necessarily, see above.

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.

Cost is pretty small - it's 3rd-party extension, on par with many other Python extensions. But you see, many 3rd-party typechecking extension standardized on typing's module type syntax, why that can't happen for alternative syntaxes? []

...

...

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?

Well, I don't write PEPs. I write "pseudoPEPs". Wrote 2 so far: "+=" operator for io.BytesIO/StringIO and "Strict Mode, part1". More recently, I'm trying to rebrand those as "PycoEPs", for my Pycopy dialect. Otherwise, the PEP framework definitely has everything to cover that usecase: there're "informational" PEPs, and there're "rejected" PEPs. I don't feel compelled to write PEPs, because I have too much code to write in my queue, and if I write a PEP, I don't write the code. And I'm skeptical about current "Python" process, because it's handled by CPython developers, and they're in constant conflict of interests between Python and their particular implementation. And I constantly remind them about that conflict of interest they have, and they constantly threaten to ban me in response. What PEP writing are you talking about under such conditions?

...

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.

I'm actually not surprised, and I treat discussions here as open-minded, and don't try to police responders for the kind of responses they should give (and I hope other participants do the same). It would make no sense to start discussion, and then respond right away "you don't talk about what I want you talk about" or just don't respond at all to the discussion I myself started. So yep, I try to keep up the discussion, whatever direction it goes, but if it strays too far away, I have to kindly remind that the original question was quite specific. []

...

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.

;-) That's why I'm not trying to write PEPs, only pseudoPEPs. But I remember old good days when even PEPs were easy matter, too. I had warm vibes recently reading https://www.python.org/dev/peps/pep-0273/ , which is quite informal by the current standards ;-). -- Best regards, Paul mailto:pmiscml@gmail.com

Hello, On Thu, 7 Jan 2021 22:59:41 +1100 Chris Angelico wrote:

On Thu, Jan 7, 2021 at 9:12 PM Paul Sokolovsky wrote:

...

In that regard, as of 3.9, CPython, has absolutely atrocious REPL support for its own syntax. It's just barely possible at all to type multi-line statement, but doing that as painful as hell, and after typing, editing is not possible.

It's absolutely a SHAME that CPython has REPL like that, and you need to install 3rd-party tools to get basic workable REPL. Such situation with REPL *alone* is a good reason to want braces syntax :-D.

Or use Idle.

Good catch, but Idle doesn't work in console terminal.

...

Well, I don't write PEPs. I write "pseudoPEPs". Wrote 2 so far: "+=" operator for io.BytesIO/StringIO and "Strict Mode, part1". More recently, I'm trying to rebrand those as "PycoEPs", for my Pycopy dialect.

Can you discuss them on pycopy-ideas then?

No, we first would need to discuss that idea on python-ideas-ideas list. -- Best regards, Paul mailto:pmiscml@gmail.com

Hello, On Thu, 7 Jan 2021 12:32:11 +0000 Paul Moore wrote:

On Thu, 7 Jan 2021 at 12:18, Paul Sokolovsky wrote:

...

On Thu, 7 Jan 2021 22:59:41 +1100 Chris Angelico wrote:

...

On Thu, Jan 7, 2021 at 9:12 PM Paul Sokolovsky wrote:

...

Well, I don't write PEPs. I write "pseudoPEPs". Wrote 2 so far: "+=" operator for io.BytesIO/StringIO and "Strict Mode, part1". More recently, I'm trying to rebrand those as "PycoEPs", for my Pycopy dialect.

Can you discuss them on pycopy-ideas then?

No, we first would need to discuss that idea on python-ideas-ideas list.

Why? You've just explicitly said this is an idea for Pycopy, not for Python. Therefore posting here is essentially just wasting the time of everyone who is not interested in Pycopy (likely the vast majority of subscribers to this list).

No, I said that CPython developers have conflict of interest in regard to Python, and want to ban some discussions arbitrarily (or on the ill will). I have rate limiting for repeating that, so I won't continue discussion in this direction, thanks for understanding, -- Best regards, Paul mailto:pmiscml@gmail.com

On Tue, Jan 5, 2021 at 10:04 AM Chris Angelico wrote:

So my question to you is: Why raise all these threads on python-ideas that have approximately zero chance of being accepted into the core language?

"Approximately zero" overstates the likelihood. "Strictly equal to zero" is a more accurate description.

On Tue, Jan 5, 2021 at 9:05 AM Steven D'Aprano wrote:

On Mon, Jan 04, 2021 at 01:38:23PM +0300, Paul Sokolovsky wrote:

...

Hello,

There're tons of projects which introduce alternative braces (i.e. C-like) syntax for Python.

Got any examples of these projects? Preferably ones that are actively maintained, have had more than one contributor, and have received even a modicum of community interest.

...

I wonder, does anyone here remember more or less formal proposal for braces syntax?

I don't believe there has ever been such a proposal.

I'm not sure this is a productive use of your time. Why don't you do something more useful, like approaching the standards committee in charge of the C++ standard and try to convince them to remove braces from their language?

*semi-wink*

#include int main() <% printf("Hello, world\n"); %> Look, ma! No braces! ChrisA

Hi! El mar, 5 ene 2021 a las 0:35, Paul Sokolovsky () escribió:

Hello,

On Tue, 5 Jan 2021 08:52:54 +1100 Steven D'Aprano wrote:

...

...

We love Python. We love them bash one-liners. We want to do one-liners in Python.

The most vivid real-world example of that I know is Frida the reverse-engineering framework (https://frida.re). The issue is so prominent that they admit it on the first page of the docs (https://frida.re/docs/home/):

...

...

Why a Python API, but JavaScript debugging logic?

What they write under that title is now marketing blah-blahing, but I remember when it leaked the sad truth: "We use JavaScript because its syntax more suitable for one-liners and small code snippets". If there was a generally accepted alternative syntax for Python, situation might have been different.

Sorry, but if I'm understanting the point is to make one-liners. For example, if I want to do something like: $ env | grep "^XDG" In one python one liner like $ python -c 'import os;print("\n".join([f"{key}:{value}" for key, value in os.environ.items() if key.startswith("XDG ")]))' I can, but If I have things that require indentation I must change it to something like: $ python << EOF import os for key, value in os.environ.items(): if key.startswith("XDG"): print(f"{key}:{value}") EOF and although it can be embedded in a shell script or written in command line it has more than one line. Really is better add braces to python that write some docs explaining how to use it in command line? What are the issues with multi-line command line executions? Maybe I have missed some point. But this is the best reason I've read and I don't understand why is useful. regards, Javi PD: Python not only can be used in console, Python can be the console https://ipython.org/ipython-doc/stable/interactive/shell.html

On Tue, Jan 5, 2021, at 17:17, lasizoillo wrote:

Sorry, but if I'm understanting the point is to make one-liners. For example, if I want to do something like:

$ env | grep "^XDG"

In one python one liner like

$ python -c 'import os;print("\n".join([f"{key}:{value}" for key, value in os.environ.items() if key.startswith("XDG ")]))'

I can, but If I have things that require indentation I must change it to something like:

$ python << EOF

what if we had special support for python -c (and maybe in some other places like exec(), but definitely not for source files) for the purpose of one-liners? Then the syntax wouldn't need to be suitable for general purpose use, and you could do something like "have ~{ ~} ~; as alternate spellings of INDENT, DEDENT, and NEWLINE respectively" python -c 'import os~;for key, value in os.environ.items():~{if key.startswith("XDG"):~{print(f"{key}:{value}")~}~}'

what if we had special support for python -c (and maybe in some other places like exec(), but definitely not for source files) for the purpose of one-liners? Then the syntax wouldn't need to be suitable for general purpose use, and you could do something like "have ~{ ~} ~; as alternate spellings of INDENT, DEDENT, and NEWLINE respectively"

+KILL_IT_WITH_FIRE -- The dead increasingly dominate and strangle both the living and the not-yet born. Vampiric capital and undead corporate persons abuse the lives and control the thoughts of homo faber. Ideas, once born, become abortifacients against new conceptions.

Hello, On Wed, 6 Jan 2021 11:47:08 +1100 Steven D'Aprano wrote: []

You know Paul, as an advocate for braces, you're doing a great job of convincing me that they aren't necessary.

I'm an advocate for braces in as much as I'm an advocate for 2+2=4. Braces exist, and used by people who need them. What to advocate here?

Have you considered that rather than a new dialect of Python all you need is a source code pre-processor or transformation?

ROFL. Not just me, everyone else considered that, and has been implementing it like that for decades. I just noticed that people who implement it, don't seem to describe well what they are doing, and make hilarious mistakes. As I have only limited view of such projects, I asked here whether there was ever someone who articulated well enough what they wanted to achieve. I got my answer from you, Steven, and I trust it, because I know that you're an old-timer here, and thorough participant of the discussions. (And I appreciate that!) And I'm happy about discussion bikeshedding/scope-creeping we all had here, but there's little else to it. (I.e. as there's no such a proposal, I just put writing such in my TODO list, that's all.) [] -- Best regards, Paul mailto:pmiscml@gmail.com