Steven D'Aprano <st...@remove-this-cybersource.com.au> writes: > The consequence of this dynamism is that the Python VM can't do many > optimizations at all, because *at any time* somebody might mess with the > implementation. But 90% of the time nobody does, so Python is needlessly > slow 90% of the time. Wouldn't it be nice if there was a way to speed up > that 90% of the time while still allowing the 10% to take place?
There is. Compile, optimizing aggressively under the assumption that everything will be as you expect. Keep a note somewhere of the assumptions you made. If something violates those assumptions, fall back to a slow version -- or, for bonus points, recompile based on the changed assumptions. CLOS is much more complex and dynamic than Python's object system; but it can be compiled very aggressively. > The current solution to this problem is to try to push as much as > possible into functions written in C: built-ins and custom C > extensions. It's not a bad solution: most Python programs rely on > many C built-ins, which enforces real encapsulation and data > hiding. With the possible exception of mucking about with ctypes, you > simply can't access mess with the internals of (say) lists *at > all*. Is this a bad thing? > > Would it be so terrible if we could do the same thing in pure Python? > Why should I have to write in C if I want the same protection? S'funny. I always considered the lack of transparency in C extensions to be a downside, and a reason to write as much as possible in proper, honest, transparent, dynamic, mess-about-with-able Python. >>> Why leave to coding standards and company policy what can be encoded >>> right into the language? Because nobody can agree what the standards and policy ought to be. > In Unix, file names with a leading dot are hidden in the shell: Bzzt. They're silently not displayed by various things, including the shell's globber, and ls(1). > when you do a file listing, you don't see them. It's not difficult to > get to see them: you just pass -a to the ls command. See? That's ls(1). Not the shell. You did know what you were talking about. > As data hiding goes, it's pretty lame, It's not data hiding, though. It's just not cluttering the view with stuff you probably didn't care about. I'm grateful that I don't have to think about dotfiles unless I really want to -- but I'm also very grateful that I /can/ mess with them when I do want to. > but Python doesn't even suppress _ names when you call dir. Frankly, > I wish that by default it would -- 99% of the time when I call dir, I > *don't* want to see _ names. They just get in the way. That might be plausible. > No it's not. It's *practical*. There are domains where *by law* code > needs to meet all sorts of strict standards to prove safety and > security, and Python *simply cannot meet those standards*. Codswallop. One can prove stuff about Python programs using the same techniques as one uses for any other language. I've done it. Other languages have better automated tools, it's true -- but the techniques are basically the same. > No technology is failure proof. But there's no reason in the world why > most technology can't be idiot-proof. Televisions are idiot-proof, > because they protect people from casual mistakes. If televisions were > built according to the Python model, the internals of the TV would be > exposed, without even a cover. All the major parts would be plug-in > rather than soldered in, and there would be no cover over the parts that > were live. Every year, tens of thousands of people would electrocute > themselves fatally (because parts of the TV holds a massive charge for > days after you unplug them from the mains) but that would be okay, > because you never know when somebody might want to pull out the fly-back > transformer and replace it with a six ohm resistor. That sort of dynamism > is important! Very amusing; but a poor analogy. The Python television comes in a clear Perspex box, which you can undo, should you need to, without any tools. But it holds together well even so. (Real PC cases are sometimes like this.) The parts are plug-in, yes; but dangerous stuff you probably don't want to mess with is covered by a plastic shield with a note on it saying `dangerous stuff in here: if you kill yourself messing with it, it's not my fault'. The plastic shields don't fall off of their own accord, but you can remove them without much difficulty should you be so inclined. >>> To prevent that sort of thing from happening, the management could >>> decree that henceforth all "private" variable names will start with an >>> underscore. Problem solved, eh? >> >> Certainly not. The only way to solve such a problem is to fire this >> cretin. > > Again, we shouldn't enforce encapsulation and data hiding because there > are legitimate reasons for breaking it, but anyone who does break it is a > cretin. You have a very strange attitude. I suppose it depends on the circumstances. I must have missed the earlier details, but there's not enough in the stuff above to prove a charge of cretinhood. I didn't see any ill-effects noted, for a start. > It's also bad for moral when you fire somebody for messing with the > internals when you have a policy that it is allowed to mess with the > internals. That's why you picked a dynamic language like Python in the > first place, because it doesn't prevent you from messing with the > internals. And now when somebody does, you sack him? If he did it unilaterally, without consulting other people or mentioning the risks, then that's irresponsible. If there was proper consultation and the decision was made for good -- and agreed -- reasons, then, well, it's a thing to keep in mind for later. May still be a net win. Hard to say. Python can be a sharp tool. Keeping sharp tools away from those who may injure themselves and others is a good idea. That doesn't mean that we shouldn't have sharp tools. It's hard to cut meat with a tenderizer. > Perhaps it would have been better to prevent him from messing with the > internals in the first place, even at some extra cost. When you're in > business, you have to make decisions like: > > * do I write the software in Python, which will have a 99% chance of > costing $100,000 and a 1% chance of costing $100,000,000? > > * or do I write it in a B&D language like Java, which will have a 100% > chance of costing $2,000,000? Easy. 1,099,000 < 2,000,000, so stick with Python. (In real life, we don't know the probabilities in advance, so the question is trickier.) >>>> from protection import unlock > > I don't know if this scenario is even possible in Python, but pretend > that it is. Would it be so terrible? I could probably live with it. It seems like a step back towards Blub[1] to me, though. The Blub programmers already have Blub. Lock the knives in the cupboard because the village idiot sometimes cuts himself. [1] http://www.paulgraham.com/avg.html -- [mdw] -- http://mail.python.org/mailman/listinfo/python-list
