"a better input"

[holger krekel]

Gareth McCaughan wrote:
> 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.

maybe i don't see how you could do that.

> 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.

why not just get rid of it :-)

seriously, i was a little bit out of this thread so i might
have stepped in too rudely. But my general point is
that thinking too much about tiny increases of security 
can bloat the language, the APIs and your programs 
without gaining you enough of the desired protection.

regards,

    holger