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 of thoughts. This is kind of a side note to the
> security discussion, but they're all interconnected: network
> programming, concurrency, lexical scoping, security.
Hm... I wonder if this style has become so popular in JS because it's
all they have? I find callback-style programming pretty inscrutable
pretty soon.
> Client-side web scripting tends to have a callback/continuation-ish
> concurrency style because it has to deal with network transactions
> (which can stall for long periods of time) in a user interface that
> is expected to stay always responsive. The Firefox API is full of
> listeners/observers, events, and continuation-like things. So one
> thing to consider is that, when Python is used for these purposes,
> it may be written in a specialized style.
>
> As i write JavaScript in this style i find i use nested functions
> a lot. When i want to set up a callback that uses variables in the
> current context, the natural thing to do is to define a new function
> in the local namespace. And if that function has to also provide a
> callback, then it has another function nested within it and so on.
>
> function spam() {
> var local_A = do_work();
> do_network_transaction(
> new function(result_1) {
> var local_B = do_work(result_1);
> do_network_transaction(
> new function(result_2) {
> do_work(local_A, local_B, result_1, result_2);
> ...
> }
> );
> }
> );
> }
How can you ever keep track of when a '}' must be followed by a ';' ?
> So it is a possible consequence of embedding Python in Firefox that
> people will be using nested functions and lexical scoping in Python
> more often, which makes the recent discussion about access to
> enclosing scopes more significant.
>
> This is even related to security as well. Namespaces and lexical
> scoping are a natural and visually apparent way to limit access.
> If, for example, result_1 and result_2 in the above example are
> security-sensitive objects like secret keys or networking functions,
> you can see just by inspection that they cannot leak outside of
> spam() except by directly being passed in an outgoing function call.
>
> The standard Pythonic response to nested functions is to translate
> them into classes. But the nested function style has two advantages:
>
> 1. Variables are more appropriately scoped; they exist
> only where they are meaningful. (In a class, all the
> variables would be mixed into one namespace, where
> some of them would be invalid some of the time.)
This doesn't strike me as very important. The same can happen in a
local scope and doesn 't seem to bother anyone there.
> 2. Local variables are private. (Class instances don't
> get their own private namespaces to play in.)
Hmm... I wouldn't be so sure of that. Exception handlers have access
to locals of stack frames above and below the current frame.
> The first becomes more significant when in a more continuation-y
> style because it helps keep the various continuations from
> interfering with each other. The second becomes more significant
> if you care about restricting untrusted Python code.
I would rather come up with a more Pythonic style of asynchronous
event handling, e.g. based on yield as shown by Phillip.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
