I wouldn't say it necessarily has to be a new language. All too many new languages have arisen when the problem was actually with some specific part of an implementation, or could have been fixed with a careful iteration.
It might be slightly off-topic, but one of Python's strengths in my eyes has been very careful incremental improvements. Prior to 2.5 Python was of no interest to me due to various concerns that have now been fixed. Indeed the language is significantly more consistent and usable than it was in the past.
The last thing I (and many others) would want to see is yet another language created, because an an existing excellent language's implementation couldn't keep up with the times, or surmount an obstacle. Innovations like PyPy, multiprocessing, and the currently debated coroutines are what give Python a chance in the future.
I might be beating a dead dog, but the last thing Python should do is roll over and die because "it's too hard". Just wanted to point out that language != implementation.
On Tue, Nov 1, 2011 at 12:07 PM, Bruce Leban firstname.lastname@example.org wrote:
On Mon, Oct 31, 2011 at 4:19 PM, Mike Meyer email@example.com wrote:
On Mon, Oct 31, 2011 at 3:58 PM, Bruce Leban firstname.lastname@example.org wrote:
On Sun, Oct 30, 2011 at 8:11 PM, Mike Meyer email@example.com wrote:
Any attempt to mutate an object that isn't currently locked will raise an exception. Possibly ValueError, possibly a new exception class just for this purpose. This includes rebinding attributes of objects that aren't locked.
Do you mean that at any time attempting to mutate an unlocked object throws an exception?
Yes, that's the idea. There are some exceptions, but you have to explicitly work around that restriction.
That would mean that all of my current code is broken.
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."
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.
Furthermore, merely *reading* an object that isn't locked can cause problems. This code is not thread-safe: if element in dictionary: return dictionary[element] so you have to decide how much safety you want and what cost we're willing to pay for this.
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.
I think the cases where non-thread-safe code won't throw an exception are numerous, for example, the equally trivial: if element not in dictionary: dictionary[element] = 0 heck even this is not safe: dictionary[element] +=1 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). 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. --- Bruce _______________________________________________ Python-ideas mailing list Pythonfirstname.lastname@example.org http://mail.python.org/mailman/listinfo/python-ideas