<br><div class="gmail_quote">On Mon, Oct 31, 2011 at 4:19 PM, Mike Meyer <span dir="ltr"><<a href="mailto:mwm@mired.org">mwm@mired.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Mon, Oct 31, 2011 at 3:58 PM, Bruce Leban <span dir="ltr"><<a href="mailto:bruce@leapyear.org" target="_blank">bruce@leapyear.org</a>></span> wrote:<br></div><div class="gmail_quote"><div class="im">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_quote">On Sun, Oct 30, 2011 at 8:11 PM, Mike Meyer <span dir="ltr"><<a href="mailto:mwm@mired.org" target="_blank">mwm@mired.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>Any attempt to mutate an object that isn't currently locked will raise<br>
an exception. Possibly ValueError, possibly a new exception class just<br>
for this purpose. This includes rebinding attributes of objects that<br>
aren't locked.<br></div></blockquote></div><div><br></div>Do you mean that at any time attempting to mutate an unlocked object throws an exception?</blockquote><div><br></div></div><div>Yes, that's the idea. There are some exceptions, but you have to explicitly work around that restriction.</div>
<div class="im">
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">That would mean that all of my current code is broken.</blockquote><div><br></div></div><div>Pretty much, yes. It's like adding garbage collection and removing alloc*/free. It's going to break a *lot* of code. That's why I said "not in 3. and possibly never in cPython."</div>
</div></blockquote><div><br></div><div><font class="Apple-style-span" color="#000099">In order to make concurrent code slightly safer, you're going to break all existing programs that don't use concurrency. That seems to me like a new language, not Python. You've been on this list long enough to see the attention that's paid to backward compatibility.</font></div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="gmail_quote"><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div><div><div><font face="arial, helvetica, sans-serif">Furthermore, merely *reading* an object that isn't locked can cause problems. This code is not thread-safe:</font></div>
<div><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="'courier new', monospace"> if element in dictionary: return dictionary[element] </font></div>
<div><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="arial, helvetica, sans-serif">so you have to decide how much safety you want and what cost we're willing to pay for this.</font></div></div>
</div></div></blockquote><div><br></div></div><div>You're right - it's not thread safe. However, it also doesn't suffer from the problem I'm trying to deal with, where you mutate an object in a way that leaves things broken, but won't be detected at that point. If it breaks because someone mutates the object underneath it, it'll throw an exception at that point. I know you can construct cases where that isn't so. </div>
</div></blockquote><div><br></div><div><font class="Apple-style-span" color="#000099">I think the cases where non-thread-safe code won't throw an exception are numerous, for example, the equally trivial:</font></div>
<div>
<font class="Apple-style-span" color="#000099"><br></font></div><div><span class="Apple-style-span" style="font-family: 'courier new', monospace; "><font class="Apple-style-span" color="#000099"> if element not in dictionary: dictionary[element] = 0</font></span></div>
<div><font class="Apple-style-span" color="#000099"><br></font></div><div><font class="Apple-style-span" color="#000099">heck even this is not safe:</font></div><div><font class="Apple-style-span" color="#000099"><br></font></div>
<div><div><span class="Apple-style-span" style="font-family: 'courier new', monospace; "><font class="Apple-style-span" color="#000099"> dictionary[element] +=1</font></span></div><div><font class="Apple-style-span" color="#000099"><br>
</font></div></div><div><font class="Apple-style-span" face="'courier new', monospace" color="#000099"><span class="Apple-style-span" style="font-family: arial; ">If you're going to tackle thread safety, it should address more of the problem. These bugs are in many ways worse than mutating "an object in a way that leaves things broken, but won't be detected at that point." The above bugs may *never* be detected. I've come across bugs like that that were in code for many years before I found them (and I'm sure that's happened to others on this list as well).</span></font></div>
<div><font class="Apple-style-span" face="'courier new', monospace" color="#000099"><span class="Apple-style-span" style="font-family: arial; "><br></span></font></div><div><font class="Apple-style-span" face="'courier new', monospace" color="#000099"><span class="Apple-style-span" style="font-family: arial; ">The first thing to do is identify the problems you want to solve and make sure that the problems are well understood. Then design some solutions. Starting with a bad solution to a fraction of the problem isn't a good start.</span></font></div>
<div><font class="Apple-style-span" face="'courier new', monospace" color="#000099"><span class="Apple-style-span" style="font-family: arial; "><br></span></font></div><div><font class="Apple-style-span" face="'courier new', monospace" color="#000099"><span class="Apple-style-span" style="font-family: arial; ">--- Bruce</span></font></div>
</div>