On 01/03/2012 22:59, Victor Stinner wrote:
I challenge anymore to break pysandbox! I would be happy if anyone
breaks it because it would make it more stronger.
Results, one week later. Nobody found a vulnerability giving access to
the filesystem or to the sandbox.
Armin Rigo complained that
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 05/03/2012 23:11, Victor Stinner wrote:
3 tests are crashing pysandbox:
- modify a dict during a dict lookup: I proposed two different fixes
in issue #14205
- type MRO changed during a type lookup (modify __bases__ during the
lookup): I proposed a fix in issue #14199 (keep a reference to
On Wed, Mar 7, 2012 at 2:36 PM, Vinay Sajip wrote:
> Armin Ronacher active-4.com> writes:
>
>> What are you trying to argue? That the overall Django testsuite does
>> not do a lot of string processing, less processing with native strings?
>>
>> I'm surprised you see a difference at all over the
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 2012-03-08, at 22:08 , Mark Janssen wrote:
> I just noticed something in Guido's example. Something gives me a strange
> feeling that using a variable as a key doesn't smell right. Presumably
> Python just hashes the variable's id, or uses the id itself as the key
Python calls ``hash`` on the
On Thu, Feb 9, 2012 at 5:18 PM, Guido van Rossum wrote:
> A dictionary would (then) be a SET of these. (Voila! things have already
>> gotten simplified.)
>>
>
> Really? So {a:1, a:2} would be a dict of length 2?
>
Eventually, I also think this will seque and integrate nicely into Mark
>> Shan
2012/3/8 Antoine Pitrou :
> On Thu, 8 Mar 2012 14:36:06 -0600
> Benjamin Peterson wrote:
>> 2012/3/8 Stefan Behnel :
>> > Would that be acceptable for CPython as well or would you prefer full
>> > fledged normalisation?
>>
>> I think we have to normalize for correctness. Consider that it may be
>>
On Thu, 8 Mar 2012 14:36:06 -0600
Benjamin Peterson wrote:
> 2012/3/8 Stefan Behnel :
> > Would that be acceptable for CPython as well or would you prefer full
> > fledged normalisation?
>
> I think we have to normalize for correctness. Consider that it may be
> some StopIteration subclass which
2012/3/8 Stefan Behnel :
> Would that be acceptable for CPython as well or would you prefer full
> fledged normalisation?
I think we have to normalize for correctness. Consider that it may be
some StopIteration subclass which set "value" on construction.
--
Regards,
Benjamin
___
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
Stefan Behnel, 07.03.2012 21:40:
> I found a problem in the current "yield from" implementation
... and here's another one, also in genobject.c:
"""
int
PyGen_FetchStopIterationValue(PyObject **pvalue) {
PyObject *et, *ev, *tb;
PyObject *value = NULL;
if (PyErr_ExceptionMatches(PyExc
Hi Stefan,
On Wed, Mar 7, 2012 at 23:16, Stefan Behnel wrote:
> Well, there's a bug tracker that lists some of them, which is not *that*
> hard to find. Does your claim about "a significantly harder endeavour"
> refer to finding a crash or to finding a fix for it?
Are you talking about the vario
Hi,
2012/3/8 Ethan Furman :
>>> A little more experimentation shows that not all is well, however:
>>>
>>> --> dir(Test)
>>> Traceback (most recent call last):
>>> File "", line 1, in
>>> TypeError: unorderable types: int() < str()
>>
>>
>> So what conclusion do you draw?
>
>
> That other change
Guido van Rossum wrote:
On Thu, Mar 8, 2012 at 8:22 AM, Ethan Furman wrote:
Guido van Rossum wrote:
On Wed, Mar 7, 2012 at 11:43 PM, Ethan Furman wrote:
Are you able to modify classes after class creation in Python 3? Without
using a metaclass?
Yes, by assignment to attributes. The __dict_
On Thu, Mar 8, 2012 at 5:41 AM, Antoine Pitrou wrote:
> For the record (I had to look it up), PEP 412 is Mark Shannon's
> "Key-Sharing Dictionary", an optimization that decreases memory
> consumption of instances.
> http://www.python.org/dev/peps/pep-0412/
Thanks for reminding us. I've gotten int
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 Wed, Mar 7, 2012 at 5:39 PM, Victor Stinner wrote:
> Hi,
>
> During the Language Summit 2011 (*), it was discussed that PyPy and
> Jython don't support non-string key in type dict. An issue was open to
> emit a warning on such dict, but the patch has not been commited yet.
It should be noted th
On Thu, Mar 8, 2012 at 2:43 AM, Ethan Furman wrote:
>
> PJ Eby wrote:
>>
>> Short version: AddOns are things you can use to dynamically extend
instances -- a bit like the "decorator" in "decorator pattern" (not to be
confused with Python decorators). Rather than synthesize a unique string
as a di
On Thu, Mar 8, 2012 at 8:22 AM, Ethan Furman wrote:
> Guido van Rossum wrote:
>
>> On Wed, Mar 7, 2012 at 11:43 PM, Ethan Furman wrote:
>>>
>>> Are you able to modify classes after class creation in Python 3? Without
>>> using a metaclass?
>>
>>
>> Yes, by assignment to attributes. The __dict__ is
Guido van Rossum wrote:
On Wed, Mar 7, 2012 at 11:43 PM, Ethan Furman wrote:
Are you able to modify classes after class creation in Python 3? Without
using a metaclass?
Yes, by assignment to attributes. The __dict__ is a read-only proxy,
but attribute assignment is allowed. (This is because th
On Thu, Mar 8, 2012 at 1:10 AM, Lennart Regebro wrote:
> On Thu, Mar 8, 2012 at 08:46, Ethan Furman wrote:
>> I think it would be sad to lose that functionality.
>>
>> If we are going to, though, we may as well check the string to make sure
>> it's a valid identifier:
>
> That would break even mo
Nick Coghlan wrote:
On Fri, Mar 9, 2012 at 12:06 AM, Mark Shannon wrote:
The text of the PEP seems to implicitly assume that all sub-iterators
will be generators, so it is not clear on the above points.
On the contrary, this question is explicitly addressed in the PEP:
http://www.python.org/d
Just to follow up. With Robin's help over in wxPython land I have
given Robin a patch to wxPython to fix the site-packages issue.
Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
ht
On Fri, Mar 9, 2012 at 12:06 AM, Mark Shannon wrote:
>
> The text of the PEP seems to implicitly assume that all sub-iterators
> will be generators, so it is not clear on the above points.
On the contrary, this question is explicitly addressed in the PEP:
http://www.python.org/dev/peps/pep-0380/#
On Thu, Mar 8, 2012 at 11:45 PM, Mark Shannon wrote:
> It really ought say that "yield from" is equivalent to inlining
> in the PEP.
That's what the motivation section is about. There's also an entire
subsection called "The Refactoring Principle" that describes this
intent. However, we needed som
Hi,
The scenario is this:
A generator, G, has a non-generator sub-iterator, S,
(ie G includes a "yield from S" experssion and S is not a generator)
and either G.close() or G.throw(GeneratorExit) is called.
In the current implementation, S.close() is called and,
if that call raises an exception,
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
On Wed, 7 Mar 2012 18:52:43 -0500
Brett Cannon wrote:
> Since PEP 412 has code that doesn't break tests anymore (thanks to hash
> randomization), it was just accepted. Mark, can you make sure there is an
> up-to-date patch in the tracker so people can potentially look at the code
> at the sprints
Nick Coghlan wrote:
On Thu, Mar 8, 2012 at 9:52 PM, Mark Shannon wrote:
First of all, the semantics described in the PEP do not match the tests.
If you substitute the supposedly semantically equivalent code
based on normal yields for each yield from in the test code
(Lib/test/test_pep380.py) an
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 08, 2012 at 06:39:42PM +0530, Ejaj Hassan wrote:
>I am a novice python programmer and am learning to be able to solve
> some issues. Well following the steps given in the PSF website, I have
> installed vc++ 2008 and even finished till building the cpython
> code and I have got the
On Thu, Mar 8, 2012 at 11:09 PM, Ejaj Hassan wrote:
> Hi,
> I am a novice python programmer and am learning to be able to solve
> some issues. Well following the steps given in the PSF website, I have
> *> installed vc++ 2008 and even finished till building the cpython
> code and I have got the
Hi,
I am a novice python programmer and am learning to be able to solve
some issues. Well following the steps given in the PSF website, I have
*> installed vc++ 2008 and even finished till building the cpython
code and I have got the console for python 3.0x
>Having done this, I am not able to qu
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.
On Thu, Mar 8, 2012 at 9:52 PM, Mark Shannon wrote:
> First of all, the semantics described in the PEP do not match the tests.
> If you substitute the supposedly semantically equivalent code
> based on normal yields for each yield from in the test code
> (Lib/test/test_pep380.py) and run it, then
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
On Thu, Mar 8, 2012 at 9:52 PM, Mark Shannon wrote:
> I would recommend changing one of two things in the PEP:
> Either, close and throw should not close/throw in subiterators
> (this would simplify the semantics and implementation immensely)
> Or, only allow subgenerators, not subiterators
> (thi
Stefan Behnel wrote:
Hi,
I found a problem in the current "yield from" implementation that I think
is worth discussing:
http://bugs.python.org/issue14220
[snip]
I've been experimenting with the implementation of PEP 380, and I found
a couple of interesting things.
First of all, the semant
On Thu, Mar 8, 2012 at 08:46, Ethan Furman wrote:
> I think it would be sad to lose that functionality.
>
> If we are going to, though, we may as well check the string to make sure
> it's a valid identifier:
That would break even more code. I have encountered many cases of
attributes that aren't
Nick Coghlan wrote:
On Thu, Mar 8, 2012 at 11:42 AM, Benjamin Peterson wrote:
2012/3/7 Victor Stinner :
Can't we simply raise an error if the dict contains
non-string keys?
Sounds okay to me.
For 3.3, the most we can do is trigger a deprecation warning, since
removing this feature *will* br
42 matches
Mail list logo
