Guido van Rossum wrote:
On Thu, Mar 8, 2012 at 4:33 PM, Nick Coghlan ncogh...@gmail.com wrote:
On Fri, Mar 9, 2012 at 3:31 AM, Guido van Rossum gu...@python.org wrote:
But the __builtins__ that are actually used by any particular piece of
code is *not* taken by importing builtins. It is taken
On Fri, Mar 9, 2012 at 6:19 PM, Mark Shannon m...@hotpy.org wrote:
The Python API would be changed, but in a backwards compatible way.
exec, eval and __import__ would all gain an optional (keyword-only?)
builtins parameter.
No, some APIs effectively define *protocols*. For such APIs, *adding*
Nick Coghlan wrote:
On Fri, Mar 9, 2012 at 6:19 PM, Mark Shannon m...@hotpy.org wrote:
The Python API would be changed, but in a backwards compatible way.
exec, eval and __import__ would all gain an optional (keyword-only?)
builtins parameter.
No, some APIs effectively define *protocols*. For
The reason I am proposing this here rather than on python-ideas is that
treating the triple of [locals, globals, builtins] as a single
execution context can be implemented in a really nice way.
Internally, the execution context of [locals, globals, builtins]
can be treated a single immutable
Victor Stinner wrote:
The reason I am proposing this here rather than on python-ideas is that
treating the triple of [locals, globals, builtins] as a single
execution context can be implemented in a really nice way.
Internally, the execution context of [locals, globals, builtins]
can be treated
On 09/03/2012 12:57, Mark Shannon wrote:
No. But it won't be slower.
Cheers,
Mark
Please prove it, you have to convince a number of core developers
including, but not limited to, the BDFL :).
--
Cheers.
Mark Lawrence.
___
Python-Dev mailing
Jim J. Jewett wrote:
http://mail.python.org/pipermail/python-dev/2012-March/117395.html
Brett Cannon posted:
[in reply to Mark Shannon's suggestion of adding a builtins parameter
to match locals and globals]
It's a mess right now to try to grab the __import__()
implementation and this would
On Thu, Mar 8, 2012 at 10:06 PM, Mark Shannon m...@hotpy.org wrote:
I don't think it cleans up import, but I'll defer to Brett on that.
I've included __import__() along with exec and eval as it is a place where
new namespaces can be introduced into an execution.
There may be others I haven't
Nick Coghlan wrote:
On Thu, Mar 8, 2012 at 10:06 PM, Mark Shannon m...@hotpy.org wrote:
I don't think it cleans up import, but I'll defer to Brett on that.
I've included __import__() along with exec and eval as it is a place where
new namespaces can be introduced into an execution.
There may be
On Thu, Mar 8, 2012 at 11:40 PM, Mark Shannon m...@hotpy.org wrote:
Other code will use whatever builtins they were given at __import__.
Then they're not builtins - they're module-specific chained globals.
The thing that makes the builtins special is *who else* can see them
(i.e. all the other
On Thu, Mar 8, 2012 at 5:57 AM, Nick Coghlan ncogh...@gmail.com wrote:
On Thu, Mar 8, 2012 at 11:40 PM, Mark Shannon m...@hotpy.org wrote:
Other code will use whatever builtins they were given at __import__.
Then they're not builtins - they're module-specific chained globals.
The thing that
On 8 March 2012 12:52, Nick Coghlan ncogh...@gmail.com wrote:
2. it's already trivial to achieve such chained lookups in 3.3 by
passing a collections.ChainMap instance as the globals parameter:
http://docs.python.org/dev/library/collections#collections.ChainMap
Somewhat OT, but
On 07/03/2012 16:33, Mark Shannon wrote:
It should also help with sandboxing, as it would make it easier to
analyse and thus control access to builtins, since the execution context
of all code would be easier to determine.
pysandbox patchs __builtins__ in:
- the caller frame
- the
On Fri, Mar 9, 2012 at 3:31 AM, Guido van Rossum gu...@python.org wrote:
But the __builtins__ that are actually used by any particular piece of
code is *not* taken by importing builtins. It is taken from what the
globals store under the key __builtins__.
This is a feature that was added
On Thu, Mar 8, 2012 at 4:33 PM, Nick Coghlan ncogh...@gmail.com wrote:
On Fri, Mar 9, 2012 at 3:31 AM, Guido van Rossum gu...@python.org wrote:
But the __builtins__ that are actually used by any particular piece of
code is *not* taken by importing builtins. It is taken from what the
globals
I propose adding an optional (keyword-only?) 3rd parameter, builtins
to exec(), eval(), __import__() and any other functions that take
locals and globals as parameters.
Currently, Python code is evaluated in a context of three name spaces;
locals(), globals() and builtins.
However, eval exec
2012/3/7 Mark Shannon m...@hotpy.org:
Currently, it is impossible to allow one function access to sensitive
functions like open(), while denying it to others, as any code can then
get the builtins of another function via f.__globals__['builtins__'].
Separating builtins from globals could solve
http://mail.python.org/pipermail/python-dev/2012-March/117395.html
Brett Cannon posted:
[in reply to Mark Shannon's suggestion of adding a builtins parameter
to match locals and globals]
It's a mess right now to try to grab the __import__()
implementation and this would actually help clarify
18 matches
Mail list logo
