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
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
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
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
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/
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
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 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
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
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
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
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()."
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
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 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
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
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
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 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
[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 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
> 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 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
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
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
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
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 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
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
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 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
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
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 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 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, 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
36 matches
Mail list logo
