On Sun, Feb 22, 2009, Brett Cannon wrote:
> On Sat, Feb 21, 2009 at 20:12, Aahz wrote:
>> On Sat, Feb 21, 2009, Brett Cannon wrote:
>>> On Sat, Feb 21, 2009 at 15:46, Aahz wrote:
On Sat, Feb 21, 2009, Brett Cannon wrote:
>
> I am seeing two approaches emerging. One is where pickle co
At 07:56 PM 2/22/2009 -0800, Guido van Rossum wrote:
On Sun, Feb 22, 2009 at 7:39 PM, P.J. Eby wrote:
> Just a question, but, if you just need a pure-python restricted environment
> for App Engine, why not just use the RestrictedPython package (i.e.,
> http://pypi.python.org/pypi/RestrictedPytho
On Sun, Feb 22, 2009 at 7:39 PM, P.J. Eby wrote:
> At 08:45 AM 2/22/2009 -0800, Guido van Rossum wrote:
>>
>> I've received some enthusiastic emails from someone who wants to
>> revive restricted mode. He started out with a bunch of patches to the
>> CPython runtime using ctypes, which he attached
At 08:45 AM 2/22/2009 -0800, Guido van Rossum wrote:
I've received some enthusiastic emails from someone who wants to
revive restricted mode. He started out with a bunch of patches to the
CPython runtime using ctypes, which he attached to an App Engine bug:
http://code.google.com/p/googleappengi
On Feb 22, 2009, at 9:43 PM, Guido van Rossum wrote:
I'm not familiar with Genshi -- what is the purpose of the AST
transformation here?
Sorry, I should have been clearer. If the only goal is to provide a
restricted bare interpreter, you can certainly just exec with a
restricted set of buil
On Sun, Feb 22, 2009 at 6:30 PM, Daniel Stutzbach
wrote:
> On Sun, Feb 22, 2009 at 8:25 PM, Guido van Rossum wrote:
>>
>> > Perhaps this entry in the man page is obsolete and should be removed?
>>
>> Not at all.
>
> For what it's worth, the 2.6.1 documentation states: "Deprecated since
> version
I'm not familiar with Genshi -- what is the purpose of the AST
transformation here?
Traditionally, sandboxing environments in Python usually just exec the
untrusted code in an environment with a __builtins__ dict that limits
the built-in functions and overrides __import__ so as to provide an
impor
On Sun, Feb 22, 2009 at 8:25 PM, Guido van Rossum wrote:
> > Perhaps this entry in the man page is obsolete and should be removed?
>
> Not at all.
>
For what it's worth, the 2.6.1 documentation states: "Deprecated since
version 2.6: The user module has been removed in Python 3.0." If user.py
ha
On Sun, Feb 22, 2009 at 5:58 PM, Mitchell L Model wrote:
> The python man page, dated 2005 even in 3.1, has this curious entry:
>
> ~/.pythonrc.py
> User-specific initialization file loaded by the user module;
> not
> used by default or by most applications.
>
> 1. I
The python man page, dated 2005 even in 3.1, has this curious entry:
~/.pythonrc.py
User-specific initialization file loaded by the user module; not
used by default or by most applications.
1. I couldn't figure out what the user module is.
2. I couldn't figure
On Feb 22, 2009, at 5:15 PM, Martin v. Löwis wrote:
What is the objective of this code? Is it a complete sandbox?
If not, is a complete sandbox based on it available somehow for
review?
From a cursory look at Tav's CPython patch, I'd describe it as follows:
Requires: an existing Python cod
Antoine Pitrou wrote:
> Guido van Rossum python.org> writes:
>> The svn history of those lines may have more pointers.
>
> Well this code dates back to the first checkin in the py3k branch. Apparently
> the old p3yk branch is not there anymore...
The history is available (see below), but tells no
Guido van Rossum python.org> writes:
>
> If you want to ensure buffers are flushed, why not call self.flush()
> for writable files outside the try/except? If flush() fails it *is* a
> real problem.
Well, my concern is less about flushing writable files (they will be
implemented in C and the flus
On Sun, Feb 22, 2009 at 10:29, Michael Foord wrote:
> Steven Bethard wrote:
>
>> On Fri, Feb 20, 2009 at 1:45 PM, Brett Cannon wrote:
>>
>>
>>> But there is another issue with this: the pure Python code will never
>>> call
>>> the extension code because the globals will be bound to _pypickle and
> I've already been maintaining the PJE-inspired ctypes-based approach
> and monkeypatches for various Python versions for a while now. See
> secure.py, secure25.py, secure26.py and secure30.py in:
>
>
> http://github.com/tav/plexnet/tree/9dabc570a2499689e773d1af3599a29102071f80/source/plexnet/
On Sat, Feb 21, 2009 at 20:12, Aahz wrote:
> On Sat, Feb 21, 2009, Brett Cannon wrote:
> > On Sat, Feb 21, 2009 at 15:46, Aahz wrote:
> >> On Sat, Feb 21, 2009, Brett Cannon wrote:
> >>>
> >>> I am seeing two approaches emerging. One is where pickle contains all
> >>> Python code and then uses s
[Sorry for stepping in so late]
On Thu, Feb 12 2009 at 02:05:23PM BRST, "Daniel (ajax) Diniz"
wrote:
> Victor Stinner wrote:
> > Oh, I realized that there is a component called "Unicode". So it should be
> > possible to write a request to list all issues related to unicode.
>
> Nice, I'll add s
On Sun, Feb 22, 2009 at 11:32 AM, Antoine Pitrou wrote:
> Guido van Rossum python.org> writes:
>> OTOH the is a much larger category of false positives, where a close()
>> call raise an exception for some spurious reason (see the quoted
>> comment) but no harm is done; in the past the tracebacks
Hey guys,
benjamin> Even if this patch manages to plug all the holes in the
benjamin> current Python, do we really want to commit our
benjamin> selves to maintaining it through language evolution
benjamin> which will surely introduce new subtle ways to
benjamin> circumvent the guard?
If
On Sun, Feb 22, 2009 at 12:10 PM, Greg Ewing
wrote:
>> Tav is interested in using this on app engine, which doesn't care
>> about segfaults -- the process is simply restarted, nobody gains
>> access to information they shouldn't have. App engine does care about
>> overwriting memory,
>
> That does
Greg Ewing canterbury.ac.nz> writes:
>
> I would hope that the C version could at least ensure that
> buffers are flushed properly without having to rely on any
> global variables, so that this would not be so much of an
> issue.
The C version cleans up after itself just fine :)
The issue is whe
Guido van Rossum wrote:
Tav is interested in using this on app engine, which doesn't care
about segfaults -- the process is simply restarted, nobody gains
access to information they shouldn't have. App engine does care about
overwriting memory,
That doesn't make sense -- how can something not
Antoine Pitrou wrote:
I would like to change this behaviour so that the "try/except" enclosure above
is removed, letting __del__ at least print those (unraisable) errors on the
console. Of course I also advocate doing so in the C version of the IO lib.
I would hope that the C version could at
Guido van Rossum python.org> writes:
>
> OTOH the is a much larger category of false positives, where a close()
> call raise an exception for some spurious reason (see the quoted
> comment) but no harm is done; in the past the tracebacks printed for
> __del__ by default have caused nothing but co
On Sun, Feb 22, 2009 at 11:02 AM, Antoine Pitrou wrote:
> The Python version of IO lib has taken the stance that all errors happening in
> the destructor of an IO object are silenced. Here is the relevant code in
> IOBase:
>
>def __del__(self) -> None:
>"""Destructor. Calls close()."
On Sun, Feb 22, 2009 at 9:54 AM, Benjamin Peterson wrote:
> On Sun, Feb 22, 2009 at 10:45 AM, Guido van Rossum wrote:
>> I've received some enthusiastic emails from someone who wants to
>> revive restricted mode. He started out with a bunch of patches to the
>> CPython runtime using ctypes, which
Hello,
The Python version of IO lib has taken the stance that all errors happening in
the destructor of an IO object are silenced. Here is the relevant code in
IOBase:
def __del__(self) -> None:
"""Destructor. Calls close()."""
# The try/except block is in case this is calle
Steven Bethard wrote:
On Fri, Feb 20, 2009 at 1:45 PM, Brett Cannon wrote:
But there is another issue with this: the pure Python code will never call
the extension code because the globals will be bound to _pypickle and not
_pickle. So if you have something like::
# _pypickle
def A(): r
On Fri, Feb 20, 2009 at 1:45 PM, Brett Cannon wrote:
> But there is another issue with this: the pure Python code will never call
> the extension code because the globals will be bound to _pypickle and not
> _pickle. So if you have something like::
>
> # _pypickle
> def A(): return _B()
> de
Guido van Rossum wrote:
I've received some enthusiastic emails from someone who wants to
revive restricted mode. He started out with a bunch of patches to the
CPython runtime using ctypes, which he attached to an App Engine bug:
http://code.google.com/p/googleappengine/issues/detail?id=671
Base
On Feb 21, 2009, at 2:17 PM, Brett Cannon wrote:
The other approach is having pickle contain code known not to be
overridden by anyone, import _pypickle for stuff that may be
overridden, and then import _pickle for whatever is available. This
approach has the perk of using a standard practic
On Sun, Feb 22, 2009 at 10:45 AM, Guido van Rossum wrote:
> I've received some enthusiastic emails from someone who wants to
> revive restricted mode. He started out with a bunch of patches to the
> CPython runtime using ctypes, which he attached to an App Engine bug:
>
> http://code.google.com/p/
I've received some enthusiastic emails from someone who wants to
revive restricted mode. He started out with a bunch of patches to the
CPython runtime using ctypes, which he attached to an App Engine bug:
http://code.google.com/p/googleappengine/issues/detail?id=671
Based on his code (the file se
Michael Foord wrote:
> Steve Holden wrote:
>> Steven Bethard wrote:
>>
>>> On Sat, Feb 21, 2009 at 1:11 PM, Paul Moore wrote:
>>>
PS Just for my own information, am I correct in thinking that it is
*only* Bazaar in the (D)VCS world that has this problem, to any real
extent? I
Steve Holden wrote:
Steven Bethard wrote:
On Sat, Feb 21, 2009 at 1:11 PM, Paul Moore wrote:
PS Just for my own information, am I correct in thinking that it is
*only* Bazaar in the (D)VCS world that has this problem, to any real
extent? I know old Mercurial clients can interact with n
Nick Coghlan wrote:
>
> Josiah Carlson wrote:
> >> Similarly, a 3.x list comprehension [i*i for i in x] is very roughly
> >> translated as:
> >>
> >> def _lc(arg):
> >>result = []
> >>for i in arg:
> >> result.append(i*i)
> >>return result
> >>
> >> = _lc(x)
> >
> > I was under
36 matches
Mail list logo
