Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #45620 > unrolled thread

Re: Please help with Threading

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Please help with Threading Chris Angelico <rosuav@gmail.com> - 2013-05-21 00:52 +1000

#45620 — Re: Please help with Threading

=On Mon, May 20, 2013 at 8:46 PM, Ned Batchelder <ned@nedbatchelder.com> wrote:
> On 5/20/2013 6:09 AM, Chris Angelico wrote:
>>
>> Referencing a function's own name in a default has to have one of
>> these interpretations:
>>
>> 1) It's a self-reference, which can be used to guarantee recursion
>> even if the name is rebound
>> 2) It references whatever previously held that name before this def
>> statement.
>
>
> The meaning must be #2.  A def statement is nothing more than a fancy
> assignment statement.

Sure, but the language could have been specced up somewhat
differently, with the same syntax. I was fairly confident that this
would be universally true (well, can't do it with 'print' per se in
older Pythons, but for others); my statement about CPython 3.3 was
just because I hadn't actually hunted down specification proof.

> So your "apparently recursive" print function is no more
> ambiguous "x = x + 1".  The x on the right hand side is the old value of x,
> the x on the left hand side will be the new value of x.
>
>     # Each of these updates a name
>     x = x + 1
>
>     def print(*args,print=print,lock=Lock(),**kwargs):
>       with lock:
>         print(*args,**kwargs)

Yeah. The decorator example makes that fairly clear.

> Of course, if you're going to use that code, a comment might be in order to
> help the next reader through the trickiness...

Absolutely!!

ChrisA

[toc] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web