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 lis
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 treate
> 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 im
Nick Coghlan wrote:
On Fri, Mar 9, 2012 at 6:19 PM, Mark Shannon 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, *
On Fri, Mar 9, 2012 at 6:19 PM, Mark Shannon 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*
parameters
Guido van Rossum wrote:
On Thu, Mar 8, 2012 at 4:33 PM, Nick Coghlan wrote:
On Fri, Mar 9, 2012 at 3:31 AM, Guido van Rossum 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 t
On Thu, Mar 8, 2012 at 4:33 PM, Nick Coghlan wrote:
> On Fri, Mar 9, 2012 at 3:31 AM, Guido van Rossum 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
On Fri, Mar 9, 2012 at 3:31 AM, Guido van Rossum 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 specifically for
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 interprete
On 8 March 2012 12:52, Nick Coghlan 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 collections.ChainMap is really
On Thu, Mar 8, 2012 at 5:57 AM, Nick Coghlan wrote:
> On Thu, Mar 8, 2012 at 11:40 PM, Mark Shannon 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 i
On Thu, Mar 8, 2012 at 11:40 PM, Mark Shannon 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 code in the pro
Nick Coghlan wrote:
On Thu, Mar 8, 2012 at 10:06 PM, Mark Shannon 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
On Thu, Mar 8, 2012 at 10:06 PM, Mark Shannon 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 though of.
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 a
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 clarif
On Wed, Mar 7, 2012 at 10:56, Benjamin Peterson wrote:
> 2012/3/7 Mark Shannon :
> > 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__['builti
2012/3/7 Mark Shannon :
> 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 this.
I l
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
19 matches
Mail list logo
