From: aa8vb at vislab.epa.gov (Randall Hopper)
Date: Fri, 30 Apr 1999 14:12:15 GMT
Subject: Python IS slow ! [was] Re: Python too slow for real world
In-Reply-To: <3729A9F3.75B2692B@appliedbiometrics.com>; from Christian Tismer on Fri, Apr 30, 1999 at 03:02:43PM +0200
References: <613145F79272D211914B0020AFF6401914DAD8@gandalf.digicool.com> <p5g15lmb35.fsf@bidra241.bbn.hp.com> <slrn7ieipq.8uk.wtanksle@dolphin.openprojects.net> <7g9qmo$luf$1@news.udel.edu> <372965CA.2B3FD2FE@appliedbiometrics.com> <19990430080805.B776752@vislab.epa.gov> <3729A9F3.75B2692B@appliedbiometrics.com>
Message-ID: <19990430101215.A806665@vislab.epa.gov>
Content-Length: 2095
X-UID: 406                                                  

Christian Tismer:
 |Randall Hopper wrote:
 |> Christian Tismer:
 |>  |I'm thinking of no new keyword, but a mechanism which allows me to lock a
 |>  |namespace somehow.
 |> 
 |> I like this idea in concept.  Though I would prefer a way to have
 |> namespaces "lock by default".  Examples:  After a class definition, the
 |> class function dictionary is locked.  After a module is fully read, all
 |> references are bound and the module namespace is locked.  etc.
 |
 |Well, I wouldn't do that by default. By default, everything could stay as
 |it is.  First of all, this would not break any existing code. 

Right.  I wasn't too clear.  By default, I mean I don't want to have to
insert some commands/declarations for every namespace (every class, every
method, every module, etc.) to lock them.  I want this to happen
automagically based on a switch.

A command-line option (-w), or something like Perl's "use strict"
declaration would be a reasonable way to enable this behavior.

 |Then, what would you do with classes which depend on each 
 |other? You cannot lock them immediately, this would fail.

Could you give an example?

 |Depending on how exactly will be implemented, a single line
 |at the end of a module should suffice to accomplish this stuff
 |for the standard cases.

This would prevent namespace binding and locking from occuring while the
module is being parsed, wouldn't it?  With a lock declaration at the
beginning, Python could do this as it goes.  Seems like that would be
easier (Python sees end of function -> module.symbol referenced in the
function was not defined -> flag error and abort parse).

 |As a side effect, locking a module would also find all 
 |referenced but undefined symbols.

That's the goal I'm rooting for. ;-)

 |Anyway, this is still no cakewalk and quite a lot of code
 |is involved. Needs much more thinking...

Definitely.  No doubt Guido and the other language experts have a better
feel for this than I do.  But I felt compelled to chime-in on this topic
since it's important to me (and the squeaky wheel gets the grease.  :-)

Randall




