arigo at tunes.org
Mon Jun 16 17:09:27 CEST 2003
On Sat, Jun 14, 2003 at 08:16:52PM +0200, holger krekel wrote:
> Interesting. But the second example should still be
> def lt__Int_Int(space, i, j):
> return space.newbool(i < j)
> because using builtins in restricted python should be avoided, shouldn't it?
Not necessarily. See again
http://codespeak.net/moin/pypy/moin.cgi/RestrictedPython, "builtin functions".
> Especially in the presence of multiple object spaces this would loose
No context is needed. The built-in functions we are using here are the real
low-level essential stuff, at the same level as the " < " operator between
These have nothing to do with the functions redefined in module.builtin*; the
list of built-in functions we allow in RPython is restricted, and how you use
them too, so that they are no burden to the translator. Still, they are
nothing more and nothing less than all other operator: we allow some, and
> But the W_XXXObject is also used as a tag for a specific implementation of a
> type. IOW there is no 1:1 relationship of W_XXXObject and W_XXXType,
The names are misleading. There is one W_XXXType, but there might be a lot of
classes implementing it. The existence of one particular such class with the
exact name W_XXXObject is misleading. What I was suggesting was that a small
number of these specific W_XXXObject classes might be equal to a restricted
Python type instead of being a class at all.
> It seems to me that "restricted python" is largely vapor-ware so i have
> problems following. Or am i missing something?
This is a most interesting point. I think that trying to actually get
somewhere in this direction could be a subject of the upcoming sprint. The
first sprint was (very roughly) the interpreter, the second sprint the
stdobjspace, let the third one be the third main missing piece of the puzzle
More information about the Pypy-dev