Alex Martelli wrote:
> robert <[EMAIL PROTECTED]> 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
--
http://mail.python.org/mailman/listinfo/python-list
