In article <[EMAIL PROTECTED]>,
"Terry Reedy" <[EMAIL PROTECTED]> wrote:
> "Mel Wilson" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> > Point of information, would this be the interpreter putting
> > the result of its last calculation in _ ?
>
> Yes, [ ... ]
No, actually. It'
"Mel Wilson" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Point of information, would this be the interpreter putting
> the result of its last calculation in _ ?
Yes, in interactive mode (but not in batch mode) it binds the valid name
'_' to the result of statement expressions.
[EMAIL PROTECTED] wrote:
> Lonnie> List comprehensions appear to store their temporary result in a
> Lonnie> variable named "_[1]" (or presumably "_[2]", "_[3]" etc for
> Lonnie> nested comprehensions)
>
> Known issue. Fixed in generator comprehensions. Dunno about plans to fix
> it
Ben Cartwright schrieb:
> [EMAIL PROTECTED] wrote:
>> Lonnie> List comprehensions appear to store their temporary result in a
>> Lonnie> variable named "_[1]" (or presumably "_[2]", "_[3]" etc for
>> Lonnie> nested comprehensions)
>>
>> Known issue. Fixed in generator comprehensions. Dunn
[EMAIL PROTECTED] wrote:
> Lonnie> List comprehensions appear to store their temporary result in a
> Lonnie> variable named "_[1]" (or presumably "_[2]", "_[3]" etc for
> Lonnie> nested comprehensions)
>
> Known issue. Fixed in generator comprehensions. Dunno about plans to fix
> it in li
Lonnie> List comprehensions appear to store their temporary result in a
Lonnie> variable named "_[1]" (or presumably "_[2]", "_[3]" etc for
Lonnie> nested comprehensions)
Known issue. Fixed in generator comprehensions. Dunno about plans to fix
it in list comprehensions. I believe a
