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. -- Best regards, Paul mailto:pmiscml@gmail.com
On Mon, Jan 4, 2021 at 9:41 PM Paul Sokolovsky <pmiscml@gmail.com> 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
ChrisA
Hello, On Mon, 4 Jan 2021 21:47:26 +1100 Chris Angelico <rosuav@gmail.com> wrote:
On Mon, Jan 4, 2021 at 9:41 PM Paul Sokolovsky <pmiscml@gmail.com> 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
On Mon, Jan 4, 2021 at 1:30 PM Paul Sokolovsky <pmiscml@gmail.com> 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? 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. 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. Anything else?
Hello, On Mon, 4 Jan 2021 14:09:30 +0200 Alex Hall <alex.mojaki@gmail.com> wrote:
On Mon, Jan 4, 2021 at 1:30 PM Paul Sokolovsky <pmiscml@gmail.com> 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
On 4 Jan 2021, at 12:29, Paul Sokolovsky <pmiscml@gmail.com> wrote:
Hello,
On Mon, 4 Jan 2021 21:47:26 +1100 Chris Angelico <rosuav@gmail.com <mailto:rosuav@gmail.com>> wrote:
On Mon, Jan 4, 2021 at 9:41 PM Paul Sokolovsky <pmiscml@gmail.com> 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. Ronald — Twitter / micro.blog: @ronaldoussoren Blog: https://blog.ronaldoussoren.net/
Hello, On Tue, 5 Jan 2021 10:07:45 +0100 Ronald Oussoren <ronaldoussoren@mac.com> wrote:
On 4 Jan 2021, at 12:29, Paul Sokolovsky <pmiscml@gmail.com> wrote:
Hello,
On Mon, 4 Jan 2021 21:47:26 +1100 Chris Angelico <rosuav@gmail.com <mailto:rosuav@gmail.com>> wrote:
On Mon, Jan 4, 2021 at 9:41 PM Paul Sokolovsky <pmiscml@gmail.com> 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
On Tue, Jan 5, 2021 at 8:32 PM Paul Sokolovsky <pmiscml@gmail.com> 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? 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. ChrisA
Hello, On Tue, 5 Jan 2021 21:03:06 +1100 Chris Angelico <rosuav@gmail.com> wrote:
On Tue, Jan 5, 2021 at 8:32 PM Paul Sokolovsky <pmiscml@gmail.com> 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
On Tue, Jan 5, 2021 at 9:38 PM Paul Sokolovsky <pmiscml@gmail.com> 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. ChrisA
Hello, On Tue, 5 Jan 2021 23:22:03 +1100 Chris Angelico <rosuav@gmail.com> wrote:
On Tue, Jan 5, 2021 at 9:38 PM Paul Sokolovsky <pmiscml@gmail.com> 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 <pmiscml@gmail.com> wrote:
Hello,
On Tue, 5 Jan 2021 21:03:06 +1100 Chris Angelico <rosuav@gmail.com <mailto:rosuav@gmail.com>> wrote:
On Tue, Jan 5, 2021 at 8:32 PM Paul Sokolovsky <pmiscml@gmail.com> 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/
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).
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!
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".
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).
Exactly the case for bringing up "python with braces". []
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.
That's right the problem with that stuff. If Python suddenly gets alternative braces syntax, people like yourself will immediately start to sing dithyrambs to the wiseness of great helmsman who enabled Python to compete with braces languages, and how it always has been a clear path to that. That's the bravery of hindsight/a posteriori thinking. Can you make similarly brave foresight predictions of what Python *should* get? []
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.
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).
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. And "formal proposal police" which will seek and destroy anyone who goes for the heresy of writing a formal proposal themselves. That's totally not the case. "Formal" is nothing but an antonym to "informal". And informal process is what you do when you got a vague idea, and a second later already thrash on the keyboard, coding. A formal process is when you resist the urge, think it out well, and even write it down. So for example, not only you can develop something from it, but soneone else too. Or someone else can verify that what you developed is faithful enough implementation of the original idea. It's that simple, really. And the question was exactly about that, and not about anything else, like why braces are needed or not needed. [] -- Best regards, Paul mailto:pmiscml@gmail.com
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. -- Steve
On Wed, Jan 6, 2021 at 9:27 PM Steven D'Aprano <steve@pearwood.info> wrote:
I'm glad that things like Perl one-liners, obfuscated C, and sewerage treatment works exist...
:)
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.
There are some other use-cases, where something is syntactically an anonymous function, but in practice, it's a part of some larger construct. In Python, a lot of those use-cases are handled by some form of function decorator or maybe abuse of class notation, but I wouldn't rule out the possibility that there are cases where those are suboptimal. Consider UI building, for instance. You need to have event handler functions, and you need to build your UI. There are a few possibilities: 1) Magic names within a class. If you have a thing called "btn_frob", and a function called "btn_frob_clicked", then that function will automatically be called when the button is clicked. 2) Objects have function decorators as attributes, so "@btn_frob.clicked" will define the function to be called when the button is clicked. 3) Name all your event handlers and place them out of line, allowing you to use simple function parameters to associate them. 4) Define a dict with attributes, and use lambda functions to handle events eg {"clicked": lambda: ...} Nothing's perfect, and nothing ever will be, but you can see how option 4 would become more viable with multiline lambdas. The function can definitely be anonymous, it's definitely complex enough to require multiple statements (or even just a single statement, which is too much for a current Python lambda), testing and documentation apply to the entire UI rather than to any specific function (it's generally useless to try to unit-test a single event handler function outside of its context), and most importantly, defining it out of line separates relevant and related concepts. All that said, I'm not pushing strongly for multiline lambdas in Python, largely because it's one of those ideas that would stand or fall on its syntax - an ugly multiline lambda won't be better than the alternatives, and would worsen the language. But I would leave the idea on the table; if anyone comes up with a really elegant syntax, I'd love to discuss it and help with PEP authorship. But Paul's recent track record of proposals isn't like that. They're not part of the language. 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"? ChrisA
Hello, On Wed, 6 Jan 2021 22:12:53 +1100 Chris Angelico <rosuav@gmail.com> 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
Chris Angelico writes:
On Wed, Jan 6, 2021 at 9:27 PM Steven D'Aprano <steve@pearwood.info> wrote:
I'm glad that things like Perl one-liners, obfuscated C, and sewerage treatment works exist...
:)
+1
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?
That's a great exaggeration. Less so now that we have the conditional expression, comprehensions, and genexps, but still.... In Lisp, you can actually substitute a defun for a lambda because the defun returns a callable (a symbol similar to a Python function object). "It's a bold strategy, Cotton." Not sure it would pay off in Python. But see below.
There are some other use-cases, where something is syntactically an anonymous function, but in practice, it's a part of some larger construct. In Python, a lot of those use-cases are handled by some form of function decorator or maybe abuse of class notation, but I wouldn't rule out the possibility that there are cases where those are suboptimal.
Consider UI building, for instance. You need to have event handler functions, and you need to build your UI. There are a few possibilities:
1) Magic names within a class. If you have a thing called "btn_frob", and a function called "btn_frob_clicked", then that function will automatically be called when the button is clicked. 2) Objects have function decorators as attributes, so "@btn_frob.clicked" will define the function to be called when the button is clicked. 3) Name all your event handlers and place them out of line, allowing you to use simple function parameters to associate them. 4) Define a dict with attributes, and use lambda functions to handle events eg {"clicked": lambda: ...}
Nothing's perfect, and nothing ever will be, but you can see how option 4 would become more viable with multiline lambdas. The function can definitely be anonymous,
*Any* function can be anonymous. Just copy the lambda around as you need it. Inline for efficiency. ;-) The question is the tradeoff between availability of a name *in multiple contexts* and the annoyance of choosing one. In the case in point, you'd have to depend on the UI builder class to associate the event name with the anonymous handler for debugging, for example. Suppose that lambda had this syntax: lambda PARAMETER-TUPLE [NAME]: DEFINITION Then you could use a list: [lambda (context) clicked: ...]. Note that this list doesn't need to pollute the namespace (and in that sense would be anonymous). The lambda would know its own name, and the builder or the runtime would fish that out. (I can see a number of reasons why this "fishing" design would not be great, and the system might duplicate the name in an attribute for straightforward access. But I suspect that's also true of the dict design.) I am specifically suggesting that the presence of the NAME parameter gives lambda's DEFINITION the syntax of def.
testing and documentation apply to the entire UI rather than to any specific function (it's generally useless to try to unit-test a single event handler function outside of its context),
This is inaccurate in both directions. First, you generally don't need the whole UI. You need the context, which is a compact representation of the history of the UI's behavior. Second, the need for context is present any time you don't have a pure function, which in Python practice is most of the time.
and most importantly, defining it out of line separates relevant and related concepts.
There may be better examples, but I think that UI is not a good one here. For all practical purposes, a UI element is a collection of event handlers. A series of defs with descriptive names is more than sufficient to associate the related concepts. Collect them in a list, hand it to the UI, and then let the UI format them as it pleases.
an ugly multiline lambda won't be better than the alternatives,
The multiline lambda can't be worse than my suggestion above, which is just a def that returns the function object without associating it with any name in the enclosing namespace. Are defs so ugly?
[If] anyone comes up with a really elegant syntax, I'd love to discuss it and help with PEP authorship.
Before anyone asks, I'm not interested in authoring this PEP. ;-) Steve
Hello, On Wed, 6 Jan 2021 21:24:28 +1100 Steven D'Aprano <steve@pearwood.info> 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
On Thu, Jan 7, 2021 at 9:12 PM Paul Sokolovsky <pmiscml@gmail.com> 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.
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? ChrisA
Hello, On Thu, 7 Jan 2021 22:59:41 +1100 Chris Angelico <rosuav@gmail.com> wrote:
On Thu, Jan 7, 2021 at 9:12 PM Paul Sokolovsky <pmiscml@gmail.com> 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
On Thu, 7 Jan 2021 at 12:18, Paul Sokolovsky <pmiscml@gmail.com> wrote:
On Thu, 7 Jan 2021 22:59:41 +1100 Chris Angelico <rosuav@gmail.com> wrote:
On Thu, Jan 7, 2021 at 9:12 PM Paul Sokolovsky <pmiscml@gmail.com> 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). Paul
Hello, On Thu, 7 Jan 2021 12:32:11 +0000 Paul Moore <p.f.moore@gmail.com> wrote:
On Thu, 7 Jan 2021 at 12:18, Paul Sokolovsky <pmiscml@gmail.com> wrote:
On Thu, 7 Jan 2021 22:59:41 +1100 Chris Angelico <rosuav@gmail.com> wrote:
On Thu, Jan 7, 2021 at 9:12 PM Paul Sokolovsky <pmiscml@gmail.com> 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 2021-01-07 04:08, Paul Sokolovsky wrote:
Can you discuss them on pycopy-ideas then? No, we first would need to discuss that idea on python-ideas-ideas list.
This is just my perspective but. . . No, we don't. None of your recent ideas are actual proposals for changes to Python, and even if they were they would and should be rejected because they don't make any sense, so they don't belong on this list. -- Brendan Barnwell "Do not follow where the path may lead. Go, instead, where there is no path, and leave a trail." --author unknown
On Tue, Jan 5, 2021 at 10:04 AM Chris Angelico <rosuav@gmail.com> 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 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* -- Steve
On Tue, Jan 5, 2021 at 9:05 AM Steven D'Aprano <steve@pearwood.info> 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 <stdio.h> int main() <% printf("Hello, world\n"); %> Look, ma! No braces! ChrisA
Hello, On Tue, 5 Jan 2021 08:52:54 +1100 Steven D'Aprano <steve@pearwood.info> 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,
But links were already posted: https://github.com/search?o=desc&q=python+braces&s=updated&type=Repositories . That's even sorted by last updated. Not every project in that list is about "python braces", but there're enough.
have had more than one contributor, and have received even a modicum of community interest.
That's more complicated, because "every little boy and girl" who gets that bright idea gets to hacking right away without studying prior art. It takes decades of experience and contrarian nature to oppose that urge. That said, https://github.com/mathialo/bython collected 255 stars and has 2 contributors, like you wish. This one: https://github.com/umlet/pwk has only 94 stars, but even 3 contribs. More importantly, it got the motivational part right:
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.
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.
Thanks for confirming.
I'm not sure this is a productive use of your time.
Oh, no worries, I take it easy. It just was a new-year's resolution to get this matter tackled this year.
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?
I don't think that approaching committees make any sense. The committees of decent languages have thought about that long ago, I gave Scheme as an example. And I personally don't care about C++, it's all ok with it in that regard (aka there're bigger problems than braces). But if *you* want C/C++ with Python syntax, hold you monkey's paw tight: https://gitlab.com/hartsantler/tpythonpp/-/blob/master/tinypy/module_ode.aot... (I swear I saw more implementations of that, I just don't record them, because again, I'm personally not much interested in C-with-Python-syntax). And in anticipation of your query for Rust with Python syntax, this guy: https://github.com/mys-lang/mys promised to forego python classes in preference to rust traits, last time I heard him talking. Dunno how far he got, I don't follow that project closely yet (too young, have a reminder to check it in half a year).
*semi-wink*
[] -- Best regards, Paul mailto:pmiscml@gmail.com
Hi! El mar, 5 ene 2021 a las 0:35, Paul Sokolovsky (<pmiscml@gmail.com>) escribió:
Hello,
On Tue, 5 Jan 2021 08:52:54 +1100 Steven D'Aprano <steve@pearwood.info> 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 Wed, Jan 6, 2021 at 9:17 AM lasizoillo <lasizoillo@gmail.com> 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
I don't know about inferior shells, but with Bourne-compatible shells (tested in bash and dash, but probably pretty much anything), you can simply open a quote and proceed to create a multi-line command. $ python3 -c 'for n in range(1, 10):
if n % 3: print("Not a multiple of three:", n) '
Not a multiple of three: 1 Not a multiple of three: 2 Not a multiple of three: 4 Not a multiple of three: 5 Not a multiple of three: 7 Not a multiple of three: 8 $ ChrisA
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}")~}~}'
On Tue, Jan 19, 2021 at 8:58 AM Random832 <random832@fastmail.com> wrote:
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 shells that actually allow you to put newlines inside quotes? $ python3 -c 'import os
for key, value in os.environ.items(): if key.startswith("XDG"): print(f"{key}:{value}") '
ChrisA
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.
On Tue, Jan 05, 2021 at 02:35:05AM +0300, Paul Sokolovsky wrote:
But links were already posted: https://github.com/search?o=desc&q=python+braces&s=updated&type=Repositories . That's even sorted by last updated. Not every project in that list is about "python braces", but there're enough.
That's a very unimpressive collection of "Python-with-braces" projects. The most popular of them is Bython, as you say:
That said, https://github.com/mathialo/bython collected 255 stars and has 2 contributors, like you wish.
I've heard of bython. But before you get too excited over an entire 255 stars and two contributors, you should compare it to a project like Coconut: https://github.com/evhub/coconut with 3.1K stars and 20 contributors. I would be the first to acknowledge that Coconut is a niche part of the Python ecosystem, but it is more than 10 times bigger than Bython based on this simplistic measure of popularity. But here's another: https://trends.google.com.au/trends/explore?q=bython,coconut%20language
This one: https://github.com/umlet/pwk has only 94 stars, but even 3 contribs. More importantly, it got the motivational part right:
We love Python. We love them bash one-liners. We want to do one-liners in Python.
Who is "we" here? People who don't care about readability, maintainability or correctness of their code? One liners hurt all three of those.
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.
So the jewel in your crown, the most important, vital, convincing example of why Python needs braces that you could find, the killer use-case that you hoped would convince us of the value of braces, comes from a project that doesn't actually mention one-liners or braces. "Trust me, it *totally* used to say that!!!" I believe you. But perhaps rather than leaking the sad truth, the project maintainers decided that your quote was inaccurate or unnecessary. You know Paul, as an advocate for braces, you're doing a great job of convincing me that they aren't necessary. Have you considered that rather than a new dialect of Python all you need is a source code pre-processor or transformation? -- Steve
Hello, On Wed, 6 Jan 2021 11:47:08 +1100 Steven D'Aprano <steve@pearwood.info> 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
participants (11)
-
Alex Hall -
Brendan Barnwell -
Chris Angelico -
David Mertz -
lasizoillo -
Paul Moore -
Paul Sokolovsky -
Random832 -
Ronald Oussoren -
Stephen J. Turnbull -
Steven D'Aprano