On 5/29/2010 6:20 AM, Colin H wrote:
Perhaps the next step is to re-open the issue? If it is seen as a bug,
it would be great to see a fix in 2.6+ -
For the purpose of bugfix releases, a 'bug' is a discrepancy between doc
and behavior. Every new feature is seen as a 'design bug' by someone.
On 29/05/10 20:20, Colin H wrote:
Perhaps the next step is to re-open the issue? If it is seen as a bug,
it would be great to see a fix in 2.6+ - a number of options which
will not break backward compatibility have been put forward - cheers,
A new feature request requesting a "closure" mode for
Perhaps the next step is to re-open the issue? If it is seen as a bug,
it would be great to see a fix in 2.6+ - a number of options which
will not break backward compatibility have been put forward - cheers,
Colin
On Thu, May 27, 2010 at 9:05 PM, Reid Kleckner wrote:
> On Thu, May 27, 2010 at 11
By hardest to induce I mean the default compile exec(code_str, {}, {})
would still be class namespace, but it's pretty insignificant.
On Fri, May 28, 2010 at 12:32 AM, Colin H wrote:
> This option sounds very promising - seems right to do it at the
> compile stage - i.e. compile(code_str, name, "
This option sounds very promising - seems right to do it at the
compile stage - i.e. compile(code_str, name, "closure") as you have
suggested. If there were any argument against, it would be that the
most obvious behaviour (function namespace) is the hardest to induce,
but the value in knowing you
On Thu, May 27, 2010 at 11:42 AM, Nick Coghlan wrote:
> However, attaining the (sensible) behaviour Colin is requesting when such
> top level variable references exist would actually be somewhat tricky.
> Considering Guido's suggestion to treat two argument exec like a function
> rather than a cla
On 27/05/10 13:13, Greg Ewing wrote:
The way that functions get access to names in enclosing
local scopes is by having them passed in as cells, but that
mechanism is only available for optimised local namespaces,
not ones implemented as dicts.
I believe exec already includes the tapdancing need
On 27/05/10 10:38, Guido van Rossum wrote:
On Wed, May 26, 2010 at 5:12 PM, Nick Coghlan wrote:
Lexical scoping only works for code that is compiled as part of a single
operation - the separation between the compilation of the individual string
and the code defining that string means that the s
Just to put a couple of alternatives on the table that don't break
existing code - not necessarily promoting them, or suggesting they
would be easy to do -
1. modify exec() to take an optional third argument - 'scope_type' -
if it is not supplied (but locals is), then it runs as class namespace
-
Yep fair call - was primarily modifying Guido's example to make the
point about not being able to delete from the globals returned from
exec - cheers,
Colin
On Thu, May 27, 2010 at 2:09 PM, Scott Dial
wrote:
> On 5/27/2010 7:14 AM, Colin H wrote:
>> def define_stuff(user_code):
>> context = {.
On 5/27/2010 7:14 AM, Colin H wrote:
> def define_stuff(user_code):
> context = {...}
> stuff = {}
> stuff.update(context)
>
> exec(user_code, stuff)
>
> return_stuff = {}
> return_stuff.update(stuff)
>
> del return_stuff['__builtins__']
> for key in context:
> if key in retu
I needed to make a small modification to the workaround - I wasn't
able to delete from 'stuff', as the definitions in exec()'d code won't
run - they're relying on that being present at runtime. In practice
the overhead of doing this is quite noticeable if you run your code
like this a lot, and buil
Another approach to all this might be to generalise the
mechanism by which a lookup of the globals falls back
to a lookup of __builtins__.
If this were done recursively, then the "stuff" could
be attached to the globals dict, e.g.
stuff['__builtins__'] = __builtins__
g = dict(__builtins__ =
On 27/05/10 12:38, Guido van Rossum wrote:
the compiler normally uses syntactic clues to decide
whether to generate code using closures, in particular, the presence
of nested functions.
Well, the compiler could be passed a flag indicating that
the code is being compiled for an exec statement.
On 27/05/10 12:37, Colin H wrote:
This is a major use
case for exec() - defining code from strings (e.g. enabling you to
store python code in the database), and using it at runtime. It seems
to me this must have been the point of locals in the first place.
I suspect that originally it just fel
On 27/05/10 11:33, Michael Foord wrote:
On 27/05/2010 00:38, Greg Ewing wrote:
Maybe the second scope argument to exec() should
be deprecated?
Sounds good to me, certainly ends the confusion over this undoubtedly
unintuitive behaviour. :-)
Although it's a fair point that it can be useful t
Of course :) - I need to pay more attention. Your workaround should do
the trick. It would make sense if locals could be used for this
purpose, but the workaround doesn't add so much overhead in most
situations. Thanks for the help, much appreciated,
Colin
On Thu, May 27, 2010 at 2:05 AM, Guido
On Wed, May 26, 2010 at 5:53 PM, Colin H wrote:
> Thanks for the possible workaround - unfortunately 'stuff' will
> contain a whole stack of things that are not in 'context', and were
> not defined in 'user_code' - things that python embeds - a (very
> small) selection -
>
> {..., 'NameError': ,
Hi Guido,
Thanks for the possible workaround - unfortunately 'stuff' will
contain a whole stack of things that are not in 'context', and were
not defined in 'user_code' - things that python embeds - a (very
small) selection -
{..., 'NameError': , 'BytesWarning':
, 'dict': , 'input':
, 'oct': ,
On Wed, May 26, 2010 at 5:37 PM, Colin H wrote:
> Mark Dickinson wrote:
>
>> Seems to me the whole idea of being able to specify
>> separate global and local scopes for top-level code is
>> screwy in the first place. Are there any use cases for
>> it? Maybe the second scope argument to exec() shou
On Wed, May 26, 2010 at 5:12 PM, Nick Coghlan wrote:
> On 27/05/10 06:07, Colin H wrote:
>>>
>>> In original Python, the snippet would have given an error whether you
>>> thought of it as being in a class or function context, which is how
>>> anyone who knew Python then would have expected. Consis
Mark Dickinson wrote:
> Seems to me the whole idea of being able to specify
> separate global and local scopes for top-level code is
> screwy in the first place. Are there any use cases for
> it? Maybe the second scope argument to exec() should
> be deprecated?
It is running as class namespace th
On 27/05/10 06:07, Colin H wrote:
In original Python, the snippet would have given an error whether you
thought of it as being in a class or function context, which is how
anyone who knew Python then would have expected. Consistency is not a bug.
When nested function namespaces were introduced
Let me quickly jump in before someone actually deletes the feature.
Nick Coghlan and Thomas Wouters had it right; there is still a use
case. Don't kill it -- documenting it better is of course fine.
It *might* be possible to add a closure to the definition of f in the
case where globals != locals,
On 27/05/2010 00:38, Greg Ewing wrote:
Mark Dickinson wrote:
code = """\
... y = 3
... def f():
... return y
... f()
... """
exec code in {} # works fine
exec code in {}, {} # dies with a NameError
Seems to me the whole idea of being able to specify
separate global and local scopes for to
Mark Dickinson wrote:
code = """\
... y = 3
... def f():
... return y
... f()
... """
exec code in {} # works fine
exec code in {}, {} # dies with a NameError
Seems to me the whole idea of being able to specify
separate global and local scopes for top-level code is
screwy in the fi
The changes to the docs will definitely help in understanding why this
behaves as it does. I would like like to take one last stab though at
justifying why this behaviour isn't correct - will leave it alone if
these arguments don't stack up :) Appreciate the input and
discussion.
Terry Jan Reedy
Mark Dickinson wrote (with interactice prompts removed)
code = """\
y = 3
def f():
return y
. f()
"""
exec code in {} # works fine
exec code in {}, {} # dies with a NameError
Traceback (most recent call last):
File "", line 1, in
File "", line 4, in
File "", line 3, in f
NameError:
Thanks for the details on why the observed behaviour occurs - very
clear. My only query would be why this is considered correct? Why is
it running as a class namespace, when it is not a class? Is there any
reason why this is not considered a mistake? Slightly concerned that
this is being considered
On 26/05/10 23:08, Michael Foord wrote:
On 26/05/2010 13:51, Nick Coghlan wrote:
On 26/05/10 19:48, Mark Dickinson wrote:
This is a long way from my area of expertise (I'm commenting here
because it was me who sent Colin here in the first place), and it's
not clear to me whether this is a bug,
On 26/05/2010 13:51, Nick Coghlan wrote:
On 26/05/10 19:48, Mark Dickinson wrote:
This is a long way from my area of expertise (I'm commenting here
because it was me who sent Colin here in the first place), and it's
not clear to me whether this is a bug, and if it is a bug, how it
could be resol
On Wed, May 26, 2010 at 11:48, Mark Dickinson wrote:
> On Wed, May 26, 2010 at 10:15 AM, Colin H wrote:
> > issue991196 was closed being described as intentional. I've added
> > a comment in that issue which argues that this is a serious bug (also
> > aserted by a previous commenter - Armin R
On 26/05/10 19:48, Mark Dickinson wrote:
This is a long way from my area of expertise (I'm commenting here
because it was me who sent Colin here in the first place), and it's
not clear to me whether this is a bug, and if it is a bug, how it
could be resolved. What would the impact be of having t
On Wed, May 26, 2010 at 10:15 AM, Colin H wrote:
> issue991196 was closed being described as intentional. I've added
> a comment in that issue which argues that this is a serious bug (also
> aserted by a previous commenter - Armin Rigo), because it creates a
> unique, undocumented, oddly behavi
Hi,
issue991196 was closed being described as intentional. I've added
a comment in that issue which argues that this is a serious bug (also
aserted by a previous commenter - Armin Rigo), because it creates a
unique, undocumented, oddly behaving scope that doesn't apply closures
correctly. At t
35 matches
Mail list logo
