On Tue, Jan 18, 2022 at 1:15 AM Steven D'Aprano wrote:
> I would be more sympathetic to this idea if:
>
> 2. I had a guarantee that all of the bracket characters would be both
> available and easily distinguishable in any typeface I used.
>
I don't think the "distinguishable" part matters that m
Perhaps the time isn't ripe for this, and perhaps it never will be, but
UTF8 seems to be handled by just about everything these days. I suspect
this is a crazy suggestion, but on the other hand perhaps people looking
back from 2100 will think "It was crazy that they stuck exclusively with
ASCII sy
This is clearly one for me to abandon! Thanks for the explanations.
John
On Mon, Jan 17, 2022 at 7:04 PM Paul Moore wrote:
> On Mon, 17 Jan 2022 at 18:51, John Sturdy wrote:
> >
> > My idea is to support the style in which each variable comes into
> existence at a single
in C and many
other languages. It would be possible to add another statement type just
for this, I suppose, and have "let x = y in:" and a suite under it.
On Mon, Jan 17, 2022 at 5:24 PM Christopher Barker
wrote:
> On Mon, Jan 17, 2022 at 7:36 AM John Sturdy wrote:
>
>> F
One of the few things I don't like about Python is that variable scope
continues after the end of the suite the variable was created in ---
probably because I think of local variable declarations as equivalent to
lambdas that are called immediately, which works for most modern
programming languages
Thanks, Mark... I had missed that aspect entirely.
I think there might be a way round it... which actually was something I had
been thinking of including in the same suggestion but thought was perhaps
too obscure, but now I've realized it would integrate well with it. That
is to have a value-retu
