On Sun, 07 Jan 2007 19:30:05 -0800, Paul Rubin wrote: > Steven D'Aprano <[EMAIL PROTECTED]> writes: >> > If you want to write bug-free code, pessimism is the name of the game. >> >> I wonder whether Paul uses snow chains all year round, even in the blazing >> summer? After all, "if you want to drive safely, pessimism is the name of >> the game". > > No. I'm willing to accept a 10**-5 chance of hitting a freak > snowstorm in summer, since I drive in summer at most a few hundred > times a year, so it will take me 100's of years before I'm likely to > encounter such a storm. There are millions of drivers, so if they all > take a similar chance, then a few times a year we'll see in the paper > that someone got caught in a storm, which is ok. Usually there's no > real consequence beyond some inconvenience of waiting for a tow truck. > > Tow truck or ambulance operators, on the other hand, should keep > chains available all year around, since they have to service the needs > of millions of users, have to be ready for freak summer storms. > > As a software developer wanting to deploy code on a wide scale, I'm > more like a tow truck operator than an individual car driver. > Alternatively, as a coder I "drive" a lot more often. If some Python > misfeature introduces a bug with probability 10**-5 per line of code, > then a 100 KLoc program is likely to have such a bug somewhere. It > doesn't take 100's of years.
That's an irrelevant argument. We're not talking about random bugs in random places of code, we're talking about one specific type of bug which can only occur in a handful of very restricted set of circumstances, e.g. you have to inherit from two classes which not only have exactly the same name but they also have the same private attribute. Your argument is that Python's strategy for dealing with private attributes is insufficiently pessimistic, because it doesn't deal with those circumstances. Fine. I agree. Python isn't pessimistic. Does it need to be? Just how often do you inherit from two identically-named classes both of which use identically-named private attributes? You suggested that coders (and by extension, Python) should behave with equal pessimism whether they are subclassing two identically-named classes or not. That's equivalent to the argument that one should use snow chains whether it is snowing or not -- it only considers the benefit of the extra protection, without considering the costs. Python's private attribute handling balances convenience and protection, giving more weight to convenience, trading off some protection. And convenience gives increased productivity, easier debugging, few bugs overall, and other Good Things. It would probably change the character of Python unacceptably much to push that balance the other way. Don't get me wrong, it is a good thing for you to alert people to the circumstances that Python's strategy breaks down, so that they can "use snow chains" in those circumstances. And, hey, if somebody reads this thread and is motivated to find a better strategy that doesn't change the nature of the language by too much, great. (This happened once before: multiple inheritance was broken in classic classes, and new classes where added partly to fix that.) But chances are, the majority of Pythonistas will think that having to use snow chains once in a very great while is an acceptable trade-off to the smooth ride Python gives the rest of the time. -- Steven D'Aprano -- http://mail.python.org/mailman/listinfo/python-list
