On 9/1/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > I would just rip it out.
>
> I don't understand this business about ripping out
> exec. I thought that exec had to be a statement so
> the compiler can tell whether to use fast locals.
> Do you have a different way of ha
Guido van Rossum wrote:
> I would just rip it out.
I don't understand this business about ripping out
exec. I thought that exec had to be a statement so
the compiler can tell whether to use fast locals.
Do you have a different way of handling that in mind
for Py3k?
--
Greg
___
Guido van Rossum wrote:
> On 9/1/06, Georg Brandl <[EMAIL PROTECTED]> wrote:
>> Guido van Rossum wrote:
>> > I would just rip it out.
>>
>> It turns out that it's not so easy. The exec statement currently can
>> modify the locals, which means that
>>
>> def f():
>> exec "a=1"
>> print a
>
On 9/1/06, Georg Brandl <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > I would just rip it out.
>
> It turns out that it's not so easy. The exec statement currently can
> modify the locals, which means that
>
> def f():
> exec "a=1"
> print a
>
> succeeds. To make that possible,
Guido van Rossum wrote:
> I would just rip it out.
It turns out that it's not so easy. The exec statement currently can
modify the locals, which means that
def f():
exec "a=1"
print a
succeeds. To make that possible, the compiler flags scopes containing
exec statements as unoptimized a
I would just rip it out.
On 9/1/06, Georg Brandl <[EMAIL PROTECTED]> wrote:
> Hi,
>
> in process of ripping out the exec statement, I stumbled over the
> following function in symtable.c (line 468ff):
>
>
> /* Che
Hi,
in process of ripping out the exec statement, I stumbled over the
following function in symtable.c (line 468ff):
/* Check for illegal statements in unoptimized namespaces */
static int
check_unoptimized(const
