A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2006-June/066683.html below:

[Python-Dev] doc for new restricted execution design for Python

[Python-Dev] doc for new restricted execution design for Python [Python-Dev] doc for new restricted execution design for PythonJim Jewett jimjjewett at gmail.com
Wed Jun 28 15:42:05 CEST 2006
On 6/27/06, Neal Norwitz <nnorwitz at gmail.com> wrote:
> On 6/27/06, Brett Cannon <brett at python.org> wrote:
> >
> > > (5)  I think file creation/writing should be capped rather than
> > > binary; it is reasonable to say "You can create a single temp file up
> > > to 4K" or "You can create files, but not more than 20Meg total".

> > That has been suggested before.  Anyone else like this idea?

> [ What exactly does the limit mean?  bytes written?  bytes currently stored?  bytes stored after exit?]

IMHO, I would prefer that it limit disk consumption; a deleted or
overwritten file would not count against the process, but even a
temporary spike would need to be less than the cap.

That said, I would consider any of the mentioned implementations an
acceptable proxy; the point is just that I might want to let a program
save data without letting it have my entire hard disk.

-jJ
More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4