Hello,
On Wed, 6 Jan 2021 21:24:28 +1100
Steven D'Aprano <st...@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:pmis...@gmail.com
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/XMM2756CJ6W5X5E3GY4SCMWWQ4CZUWOX/
Code of Conduct: http://python.org/psf/codeofconduct/
