Hi, Brett.
> I have been working on a design doc for restricted execution of Python
I'm excited to see that you're working on this.
> as part of my dissertation for getting Python into Firefox to replace
> JavaScript on the web.
Wow. What's your game plan? Do you have a story for convincing t
On Tue, 27 Jun 2006, Jim Jewett wrote:
> (Almost) everyone agrees that the case expressions SHOULD be run-time
> constants. The disagreements are largely over what to do when this
> gets violated.
I like your summary and understood most of it (options 1, 2, 3, 5, 6).
The only part i didn't unders
On Fri, 30 Jun 2006, Neal Norwitz wrote:
> The current list of serious bugs are in the PEP:
>
> http://www.python.org/dev/peps/pep-0356/
Among them is this one:
Incorrect LOAD/STORE_GLOBAL generation
http://python.org/sf/1501934
The question is, what behaviour is preferable for this co
On Fri, 30 Jun 2006, Andrew Koenig wrote:
> I saw messages out of sequence and did not realize that this would be a
> change in behavior from 2.4. Sigh.
Yes, this is not a good time to change it.
> I hope Py3000 has lexical scoping a la Scheme...
Me too -- that would be really nice.
-- ?!ng
_
On Fri, 30 Jun 2006, Brett Cannon wrote:
> On 6/30/06, Armin Rigo <[EMAIL PROTECTED]> wrote:
> > >>> object.__subclasses__()
> > [..., ]
> >
> > Maybe this one won't work if __subclasses__ is forbidden, but in general
> > I think there *will* be a way to find this object.
>
> Yeah, that's b
On Fri, 30 Jun 2006, Guido van Rossum wrote:
> On 6/30/06, Ka-Ping Yee <[EMAIL PROTECTED]> wrote:
> > On Fri, 30 Jun 2006, Andrew Koenig wrote:
> > > I hope Py3000 has lexical scoping a la Scheme...
> >
> > Me too -- that would be really nice.
>
&g
On Fri, 30 Jun 2006, Andrew Koenig wrote:
> The fundamental principle is that the binding of every name is determined
> during compilation, not during execution. This property does not quite
> apply to Python at present.
I think this property does apply. In your example:
> def g():
>
On Sat, 1 Jul 2006, Greg Ewing wrote:
> I don't disagree with anything you said, but I think it
> would be a good idea to avoid using phrases like "proper
> lexical scopes", which is likely to set people off on
> a tangent. The issue isn't lexicality, it's writeability.
"Fully functional" lexical
On Sat, 1 Jul 2006, Andrew Koenig wrote:
> I'd rather see a simpler rule: = never defines a variable in a surrounding
> scope. If you want to affect the binding of such a variable, you have to
> define it explicitly in the scope in which you want it.
>
> Example:
>
> x = 42
> def f():
Hi Brett,
Here are some comments on the description of the restricted execution
model that you posted.
> When referring to the state of an interpreter, it is either "trusted" or
> "untrusted". A trusted interpreter has no restrictions imposed upon any
> resource. An untrusted interpreter has at
On Wed, 5 Jul 2006, Guido van Rossum wrote:
> On 7/5/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> > Using the classic nonsense example:
> >
> > def counter(num):
> > def inc():
> > .num += 1
> > return .num
> > return inc
> >
> Would this also use
On Wed, 5 Jul 2006, Brett Cannon wrote:
> On 7/4/06, Ka-Ping Yee <[EMAIL PROTECTED]> wrote:
> > In response to Guido's comment about confusing the words "trusted" and
> > "untrusted", how about "empowered" and "restricted"?
>
After reading the messages on this thread i'm starting to think
that it would be good to clarify what kinds of threats we are
trying to defend against, and specify what invariants we are
intending to preserve.
For example, here are a few things Brett mentioned:
> Right. I am thinking more of an
On Wed, 21 Jun 2006, Brett Cannon wrote:
> I have been working on a design doc for restricted execution of Python
> as part of my dissertation for getting Python into Firefox to replace
> JavaScript on the web.
I've been doing a bunch of Firefox extension programming in Javascript
and suddenly a f
On Thu, 6 Jul 2006, Phillip J. Eby wrote:
> As much as I'd love to have the nested scope feature, I think it's only
> right to point out that the above can be rewritten as something like this
> in Python 2.5:
>
> def spam():
> local_A = do_work()
> result_1 = yield do_network
On Fri, 7 Jul 2006, Guido van Rossum wrote:
> On 7/7/06, Ka-Ping Yee <[EMAIL PROTECTED]> wrote:
> > I've been doing a bunch of Firefox extension programming in Javascript
> > and suddenly a few of the recent topics here came together in my head
> > in a silent kapow
On Fri, 7 Jul 2006, Talin wrote:
> While I was typing this, I did realize a drawback to poisoned objects,
> which I will illustrate by the following example:
>
> Suppose we want to grant to the sandboxed program permission to read and
> write cofiguration properties. We don't want to give them arbi
It sounds to me like what is being proposed amounts to essentially
"promote sys.exit to a builtin". So why not do that?
I see two options. Either:
(a) Simply let __builtins__.exit = sys.exit. Then we get:
>>> exit
which may be enough of a clue that you type "exit
On Wed, 28 Dec 2005, Fredrik Lundh wrote:
> Ka-Ping Yee wrote
> > It sounds to me like what is being proposed amounts to essentially
> > "promote sys.exit to a builtin".
> no, what's being proposed is what the subject says: a quit/exit command
> that actual
In a fair number of cases, Python doesn't follow its own recommended
naming conventions. Changing these things would break backward
compatibility, so they are out of the question for Python 2.*, but
it would be nice to keep these in mind for Python 3K.
Constants in all caps:
NONE, TRU
On Fri, 30 Dec 2005, Reinhold Birkenfeld wrote:
> Ka-Ping Yee wrote:
> > Constants in all caps:
> > NONE, TRUE, FALSE, ELLIPSIS
>
> That's ugly.
I know it looks ugly to you now. But there's a good reason why we use
capitalization for class names -
Brett Cannon wrote:
> I am fine with changing the built-in types, but changing the built-in
> singletons just looks *really* odd to me. So odd that I just don't
> want to see them changed. I mean when I think of constants, I think
> of a variable that references an object and that reference never
On Fri, 30 Dec 2005, "Martin v. Löwis" wrote:
> Ka-Ping Yee wrote:
> > That would be cool. If so, it would make sense for them to be all in
> > lowercase.
>
> And rename None to null in the process :-)
Is there a really good reason to do that? It
On Fri, 30 Dec 2005, Fred L. Drake, Jr. wrote:
> On Friday 30 December 2005 06:31, Ka-Ping Yee wrote:
> > Is there a really good reason to do that? It's not obvious to me.
>
> No more than there is to rename None to none or NONE.
For that, there is a reason: None is no
On Sun, 15 Jan 2006, Georg Brandl wrote:
> does Python have an official icon? Not py.ico from PC/, that's a bit
> ugly and does not scale. Has no designerhead ever done such a thing?
There have been a couple of proposed logos -- i found some images
at http://www.pythonology.com/logos -- but i don'
101 - 125 of 125 matches
Mail list logo
