Does Python really follow its philosophy of "Readability counts"?

Mark Wooding mdw at distorted.org.uk
Wed Jan 21 02:11:00 CET 2009


Steven D'Aprano <steve at 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]



More information about the Python-list mailing list