constant in python?

[Alex Martelli]

"Paul Rubin" <phr-n2001 at nightsong.com> wrote in message
news:7xsneoijz7.fsf at ruckus.brouhaha.com...
    ...
> > Hear, hear!  Designers aren't omniscient and a language that lets
> > me workaround a limitation in the design of a framework or library
> > I need to use is just what I need.
>
> The trouble is, the very existence of a workaround is sometimes itself
> a limitation, e.g. in implementing an applet sandbox.

It would be, yes, IF untrusted code subject to restricted-mode execution
had full access to such workarounds.  Fortunately, this is not the case
with Python: the runtime knows when it's executing code 'restrictedly'
(thus, presumably, untrusted code), by the simple test of checking if
the current global namespace dictionary's __builtin__ refers to
something else than the true __builtins__.  Restricted code doesn't
have full introspection abilities, and this lets you sandbox it in.

E.g., try the following in an interactive session:

>>> realthing = __builtins__
>>> class X:
...   def f(self): print self
...
>>> x=X()
>>> x.f()
<__main__.X instance at 007994DC>
>>> x.__dict__
{}
>>> X.__dict__
{'f': <function f at 0079A18C>, '__doc__': None, '__module__': '__main__'}
>>> __builtins__=__builtins__.__dict__.copy()
>>> x.f()
<__main__.X instance at 007994DC>
>>> X.__dict__
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
RuntimeError: class.__dict__ not accessible in restricted mode
>>> __builtins__ = realthing
>>> X.__dict__
{'f': <function f at 0079A18C>, '__doc__': None, '__module__': '__main__'}
>>>

Here, we saved a reference to the real-thing builtins, so we could
proclaim ourselves trusted again by re-assigning __builtins__ (of
course, you normally wouldn't supply that 'real-thing' to untrusted
code:-).  But as long as our __builtins__ didn't refer to the
real thing, we were untrusted and thus running in restricted
mode.  Since you clearly do have to be selective in what builtins
you let a piece of untrusted code access, identifying restricted
mode with non-kosher __builtins__ kills two birds with one stone.


> > > Python is a general purpose programming language and its design should
> > > not be significantly compromised to make a particular (uncommon) usage
> > > more convenient i.e. security environments.
> >
> > Yep.  Besides, rexec and Bastion (could use some spiffying up,
> > but) are pretty good for this.
>
> I'll check into those.  However, a true general purpose language
> should be useable in all environments.

I differ from this philosophy, which seems to shade into a "one
language to bind them all" design guideline.  For example, I
consider machine-language to be "a true general purpose"
one, but that doesn't imply it has to be decenty deployable
in all environments -0- it's QUITE reasonable to require that
a binary-compatible machine or emulator thereof be part of
any environment in which the language is "useable".

In other terms, "all environments" is a serious overbid, I
believe.  Is there a good Common Lisp compiler/runtime
for a 4-bit microcontroller with 4KB ROM and 256 bytes
of RAM?  Probably not, but that doesn't mean Lisp isn't
"a true general purpose language", as long as it's deployable
in all *SUITABLE* environments -- ones 'powerful' enough
in terms of available hardware and software resources
(enough CPU power, ROM/storage, RAM, and underlying
software infrastructure).


> If Python had Scheme-like lexical closures, that might be enough
> to solve this particular problem.

It has lexical closures where a name at an intermediate
scope cannot be rebound from code in a nested scope,
somewhat like Java in this specific respect -- midway
between Scheme, that lets all names be freely rebound
(well, ALMOST all names), and Haskell, which doesn't
support the very concept of rebinding in any context
(I know there are better examples than Haskell for the
concept of single-assignment languages, it's just that
none comes to mind right now:-).


Alex