> > print(child_pid) # child_pid is undefined
>
> Why on earth would it be undefined?
>
Indeed, users would expect the new uses of "as" to behave as the previous
ones. The problem is that "with" and "except" do things differently:
In [*1*]: *import* *os*
In [*2*]: *with*
[Tim, on Rebol/Red]
>> >> x: 12 y: 13
>> == 13
>> >> [x y]
>> == [x y]
>> >>
>> >> do [x y]
>> == 13
[Greg Ewing ]
> How does scoping work? If you pass a block to a function
> which evaluates it, how are names in the block resolved?
Too involved, but basically a form
On Sun, May 20, 2018 at 10:57:39AM -0700, Mike Miller wrote:
> You seem determined to throw out requirements when it suits. One of which
> was for newer languages.
YOU are the one who changed the requirements: first you said "newer
languages", then you changed it to industry standard.
I
On Sun, May 20, 2018 at 02:53:46PM -0400, Juancarlo Añez wrote:
> This shouldn't be:
>
> if os.fork() as child_pid:
> parent(child_pid)
> else:
>child()
>
> print(child_pid) # child_pid is undefined
Why on earth would it be undefined?
Anyway, if you want to propose an alternative to
Tim Peters wrote:
x: 12 y: 13
== 13
[x y]
== [x y]
do [x y]
== 13
How does scoping work? If you pass a block to a function
which evaluates it, how are names in the block resolved?
--
Greg
___
Python-ideas mailing list
Python-ideas@python.org
[Tim]
>> I was an early REBOL user, and my head still hurts ;-) It was ...
>> different, for sure.
[Steven D'Aprano ]
> Yeah, to me it looks more like a prefix version of Forth than Lisp.
> Complete with "anything can be a name":
The example I gave just strung "words"
Anyone can trivially construct a scope that limits applicable cases to
support a specific point. This thread is pointless without full context.
On Sun, May 20, 2018, 11:05 Mike Miller wrote:
> For more background, this is the thread that inspired this one:
>
>
> What would be the benefit of adding the "as child_pid" syntax? The
> full assignment expression syntax completely covers all the jobs that
> you can do with a capturing if statement.
>
>
The "as" syntax over "if" and "while" may go in with all the restrictions
and caveats already discussed.
The
For more background, this is the thread that inspired this one:
https://mail.python.org/pipermail/python-dev/2018-April/153071.html
-Mike
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
You seem determined to throw out requirements when it suits. One of which was
for newer languages. While this thread's original post was not so specific on
that, in a previous post (I believe you read) defined that as created in the
"last decade or so". The ones created to address
On Mon, May 21, 2018 at 1:19 AM, Juancarlo Añez wrote:
> IMPORTANT NOTE:
>
> Enabling "as" in "if" and "while" doesn't have to be at the expense of some
> form of assignment expression. We've been having this discussion as if has
> to be either one or the other, and there's no
On Sun, May 20, 2018 at 1:35 AM, Steven D'Aprano
wrote:
>
> but maybe when languages are weird enough they all look the same :-)
>
>
https://www.dreamsongs.com/WorseIsBetter.html
Look at what happened with PERL...
IMPORTANT NOTE:
Enabling "as" in "if" and "while"
Steven D'Aprano wrote:
Yeah, to me it looks more like a prefix version of Forth than Lisp.
Throf?
--
Greg
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct:
13 matches
Mail list logo