[Stackless] That darn GIL rant again...

[Jeff Senn]

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  
language
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  
single
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  
development work
done in about 90+% of the "real world".  Would I develop for the space  
shuttle
this way?  No, probably not.  So I would agree with a modified  
statement:

"explicit is better than implicit *IF* you can afford the additional  
development
cost of making things explicit"

In most highly-integrated cases (that is: passing lots of different  
messages around
or dynamically scheduling execution) of multi-threaded programming,   
this cost is significant
(especially since it probably involves more difficult future re- 
factoring).

And if you are in the category of project that is easily
able to afford that cost you are probably not using Python :-).

-Jas