"a better input"

[Gareth McCaughan]

Holger Krekel wrote:

> > I don't actually mind if an input() replacement evaluates 2+3.
> > I do mind if it is able to do arbitrary computation, where
> > "arbitrary" is fuzzily defined to cover things like
...
> IMO, don't add such things to python. If you really need
> such security use the mechanisms of your
> OS e.g. restricted execution or even Jails/Bsd or UserModeLinux
> which give you security on the *system call* level even
> if you are executing as *root*. This way you can still
> use the full power of any C-extension or cmdline-tool...
> 
> That's a fundamentally better approach than fiddling
> with some functions in python and quite possibly bloating
> the API and the language.

1. OS-level facilities cannot protect from all the things
   I think a good input() should be protected from.

2. If the only way to provide an input() function along the
   lines I prefer involves bloating the API, then it should
   not be done.

3. I don't understand what you mean about bloating the
   language. I am proposing this as something it would
   be good to add if the existing input() gets removed
   or deprecated.

-- 
Gareth McCaughan  Gareth.McCaughan at pobox.com
.sig under construc