"RuntimeError: dictionary changed ... & Ruby

[robert]

Alex Martelli wrote:

> robert <no-spam at no-spam-no-spam.com> wrote:
>    ...
> 
>>99.99% no. I would have to use a lock everywhere, where I add or remove
>>something into a dict or list of the struct. Thats not the purpose of
>>big thread locks. Such simple operations are already atomic by the 
>>definition of Python - and thanks to the global interpreter lock. 
>>(Otherwise I would leave the Python language, God beware ... :-) )
> 
> You have misread the Python Language Reference -- if you can give the
> URL on which you have read any such promise of atomicity, I will be glad
> to fix the docs to make that unambiguous.
> 
> There is no such promise (there may be implementation accidents in some
> specific implementation which happen to make some operation atomic, but
> NO guarantee even there that the next bugfix won't break that).

What? When I add/del an item to a dict or list, this is not an atomic 
thread-safe operation?
E.g.:
One thread does things like  d['x']='y'
Another thread reads d['z'] or sets  d['z']='w' or dels something.

If those operations are not atomic, then you'd have to use locks all the 
time to not get RuntimeErrors and worse !?

Infact I rely on that all the time and standard python modules also do 
so AFAIK

The only problem I know, is that on iteration over dicts/lists you get 
this type of error and this is understandable. But usually one solves 
this situations with .keys().

I think cPickle has not necessarily to iterate free over native dicts. 
Whats does copy/deepcopy/[:] ?

> Farwell and best of luck in finding other languages which support
> threads in a way that is more to your liking than Python -- maybe Ruby
> suits you, I don't know for sure though.

I looked several times on Ruby, but stay with Python. Ruby is featured, 
but ill designed.

* Ruby code is very very ugly @!{}&%$||endendend ..... egyptology. 
Nearly back to Perl.

* try to translate this into Ruby:

def f(): return 1
def g(x): return x()
g(f)

=> Then you'll receive a doctor hat about the OO paradigm and the famous 
"Ruby way". But you'll know, why functional programming is a stronger 
religion. Translating OO to Python, you'll often not even notice that 
Python's OO is attached to funcs and dicts. OO is naturally attached! 
The Ruby paradigm is more stilted.

* Ruby doesn't lead to disciplined code. So much names for loops and 
everything => you are thinking and choosing 2x time and receive double 
mud. With Python you write happy and choiceless - but have all and more 
power.

* Ruby without refcounts provides no deterministic __del__ in 
non-circular refs ==> your type  finally finally finally .close .close 
.close all the time

* Rubys module and class namespaces are rewriteable from everywhere 
without any barriers. Thats mostly negative for serious apps. 'require' 
is the same random as C's #include. You scribble and change here - a 
bomb explodes in another module. That kills big projects. Modularization 
and consistency of modular code is 3x better in Python with its local 
module objects and other shielding stuff.

* Ruby threads are not real OS threads, but the Ruby interpreter itself 
switches AFAIK.  a Pro or Con regarding the requirements. The Python 
method is more powerfull for bigger apps

* Ruby so far has no real (simple) generators, but in fact only block 
callbacks (bad readable also). In Ruby there is no framework for delayed 
execution - only a rudimentary error-prone 'callcc'. Thus they 
don't/can't have real iterators. So they also don't know of these kind 
of problems :-). Python is more powerful in that, but things like 
cPickle.dump and deepcopy should be writen with discipline to not break 
code unnecessarily when Python evolves.

* Ruby code executes 2x..4x slower, (but startup of very small scripts 
is 30% faster;)

* etc etc ...

Robert