[Python-Dev] Musings on concurrency and scoping ("replacing" Javascript)

[Ka-Ping Yee]

On Fri, 7 Jul 2006, Guido van Rossum wrote:
> On 7/7/06, Ka-Ping Yee <python-dev at zesty.ca> 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.

Yes, i would love to be able to use generators instead.  Maybe
this will be a strong selling point for Python when it's ready for
browser scripting.  (There may be a fair amount of glue required to
cope with the existing callback-based Firefox APIs though.)

> How can you ever keep track of when a '}' must be followed by a ';' ?

Hee hee -- dizzying, eh?  Actually there are no occurrences of "};"
in that example, just ");".  In JavaScript the semicolons are optional
anyway; my personal style is to use semicolons after statements but
not after function declarations.

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

That's true, but then we're talking about existing coding styles
where people aren't concerned about minimizing security risks.
Scopes are a very powerful tool for limiting access, but you might
not notice what you're missing if you haven't been faced with a
security problem and tried using them to solve it.  (It's a bit
like generators before we had them and got used to how handy they
were: substitute scopes => generators, limiting access => flow control,
security problem => concurrency problem.)

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

True.  It would be more accurate to say that local variables are
usually thought of as private, and therefore could be enforced as
private without breaking (hardly) anything.  Making instance members
private would break tons of stuff.


-- ?!ng