Steven D'Aprano said:
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.
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.
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.)
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]
