[Stackless] That darn GIL rant again...
senn at maya.com
Tue Apr 1 16:52:12 CEST 2008
On Apr 1, 2008, at 9:33 AM, niki wrote:
> Jeff Senn wrote:
>> About the only space between rock and hard-place I see is:
>> 1) notice that most (well-designed) systems that
>> do asynchronous messaging (in practice) send far less data
>> between "processes" than they handle locally.
>> 2) realize that declaring beforehand which data is local
>> and which is "possibly remote" is not very "Pythonic". And
>> probably difficult given the "reference heavy" nature
>> of Python objects.
>> 3) Re-vamp a python interpreter that dynamically acquires
>> locking "per-object" as it notices the object reference
>> cross a "thread boundary". (Notice that descent into the tree
>> of references is necessary for containers!)
> I disagree with point 2. "Explicit is better than implicit".
> Programmer must know where thread/process boundaries are and convey
> this to the system. This knowledge very important in order to make
> all kind of algorithmic decisions.
> Niki Spahiev
Hm. I did say: "not very Pythonic"; by which I meant: Python is a
that provides for the ability to quickly "sketch" a program out and then
go in and optimize it in stages. Python is not "type strong" in that
you don't have to figure out a whole bunch of stuff before you get a
line of code running in the probably-complex-system you are building.
Additionally Python is very introspective, in that it allows you access
to the "internals" of most everything from the interpreter itself
(i.e. it doesn't hide data behind "containers" -- though you can do that
sort of thing structurally within your code)
IMHO this is *exactly* the right balance for actually getting software
done in about 90+% of the "real world". Would I develop for the space
this way? No, probably not. So I would agree with a modified
"explicit is better than implicit *IF* you can afford the additional
cost of making things explicit"
In most highly-integrated cases (that is: passing lots of different
or dynamically scheduling execution) of multi-threaded programming,
this cost is significant
(especially since it probably involves more difficult future re-
And if you are in the category of project that is easily
able to afford that cost you are probably not using Python :-).
More information about the Stackless