Why does python not have a mechanism for data hiding?

[Bruno Desthuilliers]

Mark Wooding a écrit :

I don't want to speak for whoever you were responding to, but from my
point of view...

Yes.

I understand the difference between the documented interface of a system
and the details of its implementation. But sometimes it can be useful
to take advantage of implementation details, particularly if the
published interface is inadequate in some way. Whether or not I choose
to make use of implementation details is a trade-off between immediate
convenience and maintainability, but that's something I can make a
rational decision about.

By enforcing your `data hiding', you're effectively telling me that I'm
too stupid to make rational decisions of this sort. And that's actually
extremely insulting.

I couldn't state it better. +1QOTW btw.

 

[Antoon Pardon]

As far as I remember, the primary motivation was developers experience
with the ternary operator in other languages, especially C, where it
was found to hurt readability. At least in my experience, it is much
much more common to see the ternary operator making code more
obfuscated than easing readability. Time will tell if Python's if-else
expression will be abused in the same way.

That seems strange to me. The and-or simulation that was offerd in the
FAQ allowed for about the same kind of structures as the ternary
operator in C and was used in the standard library IIRC.

So the same unreadable was already possible to write, plus that it
could cause bugs and had to be made even more unreadable in order
to work correctly. Considering this it I find it odd that hurting
readability was a motivation not to have it.

 

[Lie]

That seems strange to me. The and-or simulation that was offerd in the
FAQ allowed for about the same kind of structures as the ternary
operator in C and was used in the standard library IIRC.

So the same unreadable was already possible to write, plus that it
could cause bugs and had to be made even more unreadable in order
to work correctly. Considering this it I find it odd that hurting
readability was a motivation not to have it.

In case you didn't notice, the and-or simulation is a hack, it is not
to be used by anyone writing real code (instead of for an entry to
Obfuscated Python Code Contest) to substitute it for inline if. If
inline if is "formalized", that means the language encourages the use
of inline if, which we don't want to have.

 

[Russ P.]

Mark Wooding a écrit :






I couldn't state it better. +1QOTW btw.

Please see my previous reply to that post.

Being "insulted" by data hiding is the "QOTW"? I'd call that an insult
to everyone else who has posted on this forum in the past week. Unless
of course you mean "silliest QOTW."

 

[Russ P.]

Yes, fine. And then have to maintain a fork of the source code, and
distribute it with the application. Honking great idea. doh :-(

A client who wishes to bypass access restrictions need not maintain
any "fork." If you have access to the source code, removing my
proposed "priv" keyword from an entire library or application is a one-
liner in sed.

If you wish to remove only specific instances of its occurrences, that
is also a trivial matter, and all that needs to be maintained by the
client is a record of which instances were removed. In fact, the
client doesn't even need to do that, because when the next version
comes out they will be reminded very quickly of where they removed
"priv."

But such a client would be a real fool for depending on private data
and/or methods, of course, because those are not part of the public
API and are not guaranteed to remain unchanged. The whole reason for
private data and methods is that they give the developers freedom to
change the implementation without changing the interface.

How about some common sense here. If you, the client, are convinced
that something declared private should really be public, then perhaps
you should contact the developer and explain your reasoning. If the
developer agrees, then the problem is solved. If not, then perhaps it
is *you*, the client who does not understand the proper usage of the
code.

I don't have time to reply to all or your claims, but my lack of a
reply to any particular point should not be construed as implicit
agreement.

 

[bruno.desthuilliers]

(snip argument about s/private/public/g on a whole source tree not
being a fork, and not being by far a worse hack than monkeypatching a
small specific part of a whole lib - what can I say ?)

How about some common sense here.

Good question.

But for which definition of "common sense" ? May I remind you that,
for a long time, "common sense" dictated that the earth was flat and
at the center of the universe, and that anything heavier than air
could by no mean fly ? Or, more recently, that their was a market for
at most 5 computers on earth, and that 640kb of RAM ought to be enough
for anyone ?

If you, the client, are convinced
that something declared private should really be public, then perhaps
you should contact the developer and explain your reasoning.

Indeed. At least something we seem to agree on.

If the
developer agrees, then the problem is solved.

Indeed again. But...

But if it takes 6 month to get the mentioned developer to release
something I can use, I'm screwed up. Fine.

As strange as it might be, I prefer to *first* make it work, *then*
contact the developer. And while we're at it:

If not,

Then I prefer to be able to monkeypatch the code and only maintain my
monkeypatch than to have to maintain a whole fork of the original
lib.

But YMMV of course...

then perhaps it
is *you*, the client who does not understand the proper usage of the
code.

Do you really think that I'm fiddling with implementation stuff that
may break my code any other release because I don't *understand* that
code ? But anyway : even if it happened to be the case, it would still
be my own responsability. So what's the matter ? Should we forbid
hammers because you could use one to bang your head with ?

I don't have time to reply to all or your claims, but my lack of a
reply to any particular point should not be construed as implicit
agreement.

Sounds like a lawyer's notice. Anyway, your lack of agreement won't
keep me from happily add implentation attributes to existing objects
whenever I find it appropriate. Sorry for being more on the pragmatic
side than on the cargo-cult one.

 

[Russ P.]

But if it takes 6 month to get the mentioned developer to release
something I can use, I'm screwed up. Fine.

I've lost track of how many times I've said this now, but my
suggestion for a "priv" keyword allowed for "indirect" access to
private data through some name-mangling scheme. That could be your
temporary fix while you are waiting for the developer to release a
corrected version. And even if that option were not available, you
could simply open up the relevant source file in the editor of your
choice and remove the offending "priv" declaration. I completely fail
to see how you are "screwed."

Sorry, but when I have to keep repeating the same basic points over
and over, I can't help but think I might be wasting my time.

 

[Fuzzyman]

Mark Wooding a écrit :






I couldn't state it better. +1QOTW btw.

By telling me that I can never have a valid reason for wanting 'data
hiding' you're effectively telling me that I'm too stupid to make
rational decisions of this sort. And that's actually extremely
insulting.

Fuzzyman
http://www.ironpython.info/

 

[Antoon Pardon]

In case you didn't notice, the and-or simulation is a hack, it is not
to be used by anyone writing real code (instead of for an entry to
Obfuscated Python Code Contest) to substitute it for inline if. If
inline if is "formalized", that means the language encourages the use
of inline if, which we don't want to have.

Who is we? The last poll I know about had a majority in favor of a
ternary operator.

 

[Bruno Desthuilliers]

Russ P. a écrit :

I've lost track of how many times I've said this now, but my
suggestion for a "priv" keyword allowed for "indirect" access to
private data through some name-mangling scheme.

And I've lost track of how many times I've said this now, but we already
have this. While we're at it, why not a 'prot' keyword that would
restrict name-mangling to the addition of a single leading underscore ?

That could be your
temporary fix while you are waiting for the developer to release a
corrected version. And even if that option were not available, you
could simply open up the relevant source file in the editor of your
choice and remove the offending "priv" declaration.

Yes. And I can always edit the source code and add the methods I need
etc. You probably never used monkeypatching, so I guess you just can't
understand the difference between maintaining a monkeypatch and
maintaining a fork.

I completely fail
to see how you are "screwed."

Sorry, but when I have to keep repeating the same basic points over
and over, I can't help but think I might be wasting my time.

If you hope to get a general agreement here in favor of a useless
keyword that don't bring anything to the language, then yes, I'm afraid
you're wasting your time.

 

[Russ P.]

If you hope to get a general agreement here in favor of a useless
keyword that don't bring anything to the language, then yes, I'm afraid
you're wasting your time.

Actually, what I hope to do is to "take something away" from the
language, and that is the need to clutter my identifiers with leading
underscores.

I find that I spend the vast majority of my programming time working
on the "private" aspects of my code, and I just don't want to look at
leading underscores everywhere. So I usually just leave them off and
resort to a separate user guide to specify the public interface.

I'll bet many Python programmers do the same. How many Python
programmers do you think use leading underscores on every private data
member or method, or even most of them for that matter? I'll bet not
many. (See the original post on this thread.) That means that this
particular aspect of Python is basically encouraging sloppy
programming practices.

What I don't understand is your visceral hostility to the idea of a
"priv" or "private" keyword. If it offends you, you wouldn't need to
use it in your own code. You would be perfectly free to continue using
the leading-underscore convention (unless your employer tells you
otherwise, of course).

I get the impression that Python suits your own purposes and you
really don't care much about what purpose others might have for it. I
am using it to develop a research prototype of a major safety-critical
system. I chose Python because it enhances my productivity and has a
clean syntax, but my prototype will eventually have to be re-written
in another language. I took a risk in choosing Python, and I would
feel better about it if Python would move up to the next level with
more advanced features such as (optional) static typing and private
declarations. But every time I propose something like that, I get all
kinds of flak from people here who do their hacking and care little
about anyone else's needs.

With a few relatively small improvements, Python could expand its
domain considerably and make major inroads into territory that is now
dominated by C++, Java, and other statically compiled languages. But
that won't happen if reactionary hackers stand in the way.

Side note: I've been looking at Scala, and I like what I see. It may
actually be more appropriate for my needs, but I have so much invested
in Python at this point that the switch will not be easy.

 

[Jonathan Gardner]

I took a risk in choosing Python, and I would
feel better about it if Python would move up to the next level with
more advanced features such as (optional) static typing and private
declarations. But every time I propose something like that, I get all
kinds of flak from people here who do their hacking and care little
about anyone else's needs.

Let me share my personal insight. I used Python for a mission-critical
application that needed, in effect, almost 100% uptime with superior
throughput. In other words, it was a very fine piece of art that
needed to be precise and correct. In the end, Python delivered, under
budget, under schedule, and with superbly low maintenance costs
(practically 0 compared to other systems written in Java and C). I
didn't have to use any of the features you mentioned, and I can't
imagine why you would need them. In fact, having them in the language
would encourage others to use them and make my software less reliable.

You may think we are all a bunch of hackers who are too stupid to
understand what you are saying, but that is your loss.

Now, let me try to explain something that perhaps the previous 166
post may not have thoroughly explained. If I am duplicating what
everyone else has already said, then it's my own fault.

Short answer: You don't need these features in Python. You do need to
use the right tools for the right tasks.

Long answer:

Who cares what the type of an object is? Only the machine. Being able
to tell, in advance, what the type of a variable is is a premature
optimization. Tools like psyco prove that computers (really,
programmers) nowadays are smart enough to figure things out the right
way without any hints from the developer. Static typing is no longer
necessary in today's world.

Who cares about private declarations, or interface declarations at
all? It is only a message to the developers. If you have a problem
with your users doing the right thing, that is a social problem, not a
technical one, and the solution is social, not technical. Yes, it is
work, but it is not coding---it is explaining to other living,
breathing human beings how to do a specific task, which is what you
should have been doing from the start.

When all you have is a hammer, the world seems full of nails. Think
about that. You have more tools than Python to solve these problems,
and Python will never be the panacea you wish it was. The panacea is
you, putting the right tools to use for the right tasks.

 

[Niklas Norrthon]

I never thought of that one. I wonder what the C++ gurus would say
about that.

Let me guess. They'd probably say that the access restrictions are for
your own good, and bypassing them is bound to do you more harm than
good in the long run. And they'd probably be right. Just because you
can break into a box labeled "DANGER HIGH VOLTAGE," that doesn't make
it a good idea.

This just goes to show that the whole idea of using header files as
simple text insertions is flaky to start with, and adding the
preprocessor just compounds the flakiness. Needless to say, I'mnota
big fan of C and C++.

 

[Russ P.]

On Jun 10, 11:58 am, Jonathan Gardner

Who cares what the type of an object is? Only the machine. Being able
to tell, in advance, what the type of a variable is is a premature
optimization. Tools like psyco prove that computers (really,
programmers) nowadays are smart enough to figure things out the right
way without any hints from the developer. Static typing is no longer
necessary in today's world.

You couldn't be more wrong. Even Guido recognizes the potential value
of static typing, which is why he is easing it into Python as on
optional feature. He recognizes, correctly, that it can detect errors
earlier and facilitate more efficient execution. But there's another,
more significant potential benefit for safety-critical and mission-
critical applications: static typing facilitates advanced static
analysis of software. To get an idea of what that is about, take a
look at

http://www.sofcheck.com

Here is an excerpt from their website:

"SofCheck’s advanced static error detection solutions find bugs in
programs before programs are run. By mathematically analyzing every
line of software, considering every possible input, and every path
through the program, SofCheck’s solutions find any and all errors that
cause a program to crash or produce an undefined result."

Me again: static analysis does not replace traditional dynamic and
unit testing, but it is far more advanced and finds many errors very
quickly that might require weeks or months of dynamic testing -- or
might not be found at all with dynamic testing until the product is in
the field.

With more and more automation of safety-critical systems these days,
we need this more than ever. Your assertion that "Static typing is no
longer
necessary in today's world," is just plain naive.

Who cares about private declarations, or interface declarations at
all? It is only a message to the developers. If you have a problem
with your users doing the right thing, that is a social problem, not a
technical one, and the solution is social, not technical. Yes, it is
work, but it is not coding---it is explaining to other living,
breathing human beings how to do a specific task, which is what you
should have been doing from the start.

You may be right to an extent for small or medium-sized non-critical
projects, but you are certainly not right in general. I read something
a while back about the flight software for the Boeing 777. I think it
was something like 3,000,000 lines of Ada code. Normally, for a
project of that magnitude the final integration would be expected to
take something like three months. However, the precise interface specs
and encapsulation methods in Ada allowed the integration to be
completed in just three days.

By your recommended method of social interaction, that would be one
hell of a lot of talking!

I realize that Python is not designed for such large projects, but
don't you think certain general principles can be learned anyway?
Perhaps the benefits of interface specs and encapsulation are not as
obvious for smaller projects, but certainly they are not zero.

 

[cokofreedom]

On Jun 10, 11:58 am, Jonathan Gardner


You couldn't be more wrong. Even Guido recognizes the potential value
of static typing, which is why he is easing it into Python as on
optional feature. He recognizes, correctly, that it can detect errors
earlier and facilitate more efficient execution. But there's another,
more significant potential benefit for safety-critical and mission-
critical applications: static typing facilitates advanced static
analysis of software.

Can you provide me with any example of Guide wanting static typing to
be
optional? I haven't. Any why is it you keep going so abstract in this
discussion.

You may be right to an extent for small or medium-sized non-critical
projects, but you are certainly not right in general. I read something
a while back about the flight software for the Boeing 777. I think it
was something like 3,000,000 lines of Ada code. Normally, for a
project of that magnitude the final integration would be expected to
take something like three months. However, the precise interface specs
and encapsulation methods in Ada allowed the integration to be
completed in just three days.

Well, that isn't just because they used encapsulation, the likelihood
is well thoughtout planning, constant system testing (that DOES
require accessing of those more private methods to ensure there are no
problems throughout), and re-testing. Again since I'm not sure how
much I trust you and your statistics anymore, have you a link to
anything discussing this?

I realize that Python is not designed for such large projects, but
don't you think certain general principles can be learned anyway?
Perhaps the benefits of interface specs and encapsulation are not as
obvious for smaller projects, but certainly they are not zero.

Python is designed to be an efficient high level language for writing
clear readable code at any level. Considering the amount of use it
gets from Google, and the scope and size of many of their projects, I
find it foolish to say it is not designed for large projects. However
I do not myself have an example of a large python project, because I
don't program python at work.

I think the issue here is your want to have python perform exactly
like OO built languages such as Java, but it isn't Java, and that, is
a good thing.

 

[Bruno Desthuilliers]

Russ P. a écrit :

On Jun 10, 11:58 am, Jonathan Gardner
(snip)

You may be right to an extent for small or medium-sized non-critical
projects, but you are certainly not right in general. I read something
a while back about the flight software for the Boeing 777. I think it
was something like 3,000,000 lines of Ada code.

I can't obviously back my claim, but you could probably have the same
feature set implemented in 10 to 20 times less code in Python. Not that
I suggest using Python here specifically, but just to remind you that
kloc is not a very exact metric - it's relative to the design, the
language and the programmer(s). The first project I worked on
(professionaly) was about 100 000 locs when I took over it, and one year
later it was about 50 000 locs, with way less bugs and way more
features. FWIW, the bigger the project, the bigger the chances that you
could cut it by half with a good refactoring.

Normally, for a
project of that magnitude the final integration would be expected to
take something like three months. However, the precise interface specs
and encapsulation methods in Ada allowed the integration to be
completed in just three days.

By your recommended method of social interaction, that would be one
hell of a lot of talking!

Or just writing and reading.

I realize that Python is not designed for such large projects,

Clueless again. Python is pretty good for large projects. Now the point
is that it tends to make them way smaller than some other much more
static languages. As an average, you can count on something between 5:1
to 10:1 ratio between Java (typical and well-known reference) and Python
for a same feature set. And the larger the project, the greater the ratio.

but
don't you think certain general principles can be learned anyway?

Do you really think you're talking to a bunch of clueless newbies ? You
can bet there are quite a lot of talented *and experimented* programmers
here.

Perhaps the benefits of interface specs and encapsulation are not as
obvious for smaller projects,

Plain wrong.

but certainly they are not zero.

You still fail to get the point. Interface specifications and
encapsulation are design principles. period. These principles are just
as well expressed with documentation and naming conventions, and the
cost is way lower.

Russ, do yourself a favor : get out of your cargo-cult one minute and
ask yourself whether all python users are really such a bunch of
clueless newbies and cowboy hackers. You may not have noticed, but there
are some *very* talented and *experimented* programmers here.

 

[Bruno Desthuilliers]

Russ P. a écrit :

Actually, what I hope to do is to "take something away" from the
language, and that is the need to clutter my identifiers with leading
underscores.

I find that I spend the vast majority of my programming time working
on the "private" aspects of my code, and I just don't want to look at
leading underscores everywhere. So I usually just leave them off and
resort to a separate user guide to specify the public interface.

I'll bet many Python programmers do the same. How many Python
programmers do you think use leading underscores on every private data
member or method, or even most of them for that matter?

First point : please s/private/implementation/g. As long as you don't
get why it's primary to make this conceptual shift, the whole discussion
is hopeless.

Second point : I've read millions of lines of (production) python code
these last years, and I can assure you that everyone used this
convention. And respected it.

I'll bet not
many. (See the original post on this thread.) That means that this
particular aspect of Python is basically encouraging sloppy
programming practices.

Bullshit. Working experience is here to prove that it JustWork(tm).

What I don't understand is your visceral hostility to the idea of a
"priv" or "private" keyword.

Because it's at best totally useless.

If it offends you, you wouldn't need to
use it in your own code. You would be perfectly free to continue using
the leading-underscore convention (unless your employer tells you
otherwise, of course).

My employer doesn't tell me how to write code. I'm not a java-drone. My
employer employ me because he is confident in my abilities, not because
he needs some monkey to type the code.

The point is not *my* code, but the whole free python codebase. I
definitively do not want it to start looking anything like Java. Thanks.

I get the impression that Python suits your own purposes and you
really don't care much about what purpose others might have for it.

Strange enough, every time I read something like this, it happens that
it comes from someone who is going to ask for some fundamental change in
a language used by millions of persons for the 15+ past years just
because they think it would be better for their own current project.

I
am using it to develop a research prototype of a major safety-critical
system. I chose Python because it enhances my productivity and has a
clean syntax, but my prototype will eventually have to be re-written
in another language. I took a risk in choosing Python, and I would
feel better about it if Python would move up to the next level with
more advanced features such as (optional) static typing and private
declarations.

I'm sorry, but I don't see any of this as being "a move up to the next
level".

But every time I propose something like that,

fundamental change in the language for your own (perceived, and mostly
imaginary) needs, that is...

I get all
kinds of flak from people here who do their hacking and care little
about anyone else's needs.

No one needs another Java. Now what happens here is that *you* come here
explaining everyone that they need to adapt to the way *you* think
things should be.

With a few relatively small improvements, Python could expand its
domain considerably and make major inroads into territory that is now
dominated by C++, Java, and other statically compiled languages. But
that won't happen if reactionary hackers stand in the way.

So anyone not agreeing with you - whatever his experience, reasons etc -
is by definition a "reactionnary hacker" ? Nice to know.

Side note: I've been looking at Scala, and I like what I see. It may
actually be more appropriate for my needs, but I have so much invested
in Python at this point that the switch will not be easy.

So instead of taking time to learn the tool that would fit your needs,
you ask for fundamental changes in a language that fits millions other
persons needs ? Now let's talk about not caring about other's needs...

 

[Maric Michaud]

Le Wednesday 11 June 2008 08:11:02 Russ P., vous avez écrit :

http://www.sofcheck.com

Here is an excerpt from their website:

"SofCheck’s advanced static error detection solutions find bugs in
programs before programs are run. By mathematically analyzing every
line of software, considering every possible input, and every path
through the program, SofCheck’s solutions find any and all errors that
cause a program to crash or produce an undefined result."

Don't mix commercial discourse with technical, it desserves your point.
Theoretically, wether a program has bugs or not is not computable. Static
analysis as they imply is just nonsense.

AFAIK, the efforts needed to make good static analysis are proven, by
experience, to be at least as time consuming than the efforts needed to make
good unit and dynamic testing.

 

[Paul Boddie]

Russ P. a écrit :


I can't obviously back my claim, but you could probably have the same
feature set implemented in 10 to 20 times less code in Python.

It's easy to make claims like this knowing that people aren't likely
to try and write such a system in Python.

Not that
I suggest using Python here specifically, but just to remind you that
kloc is not a very exact metric - it's relative to the design, the
language and the programmer(s). The first project I worked on
(professionaly) was about 100 000 locs when I took over it, and one year
later it was about 50 000 locs, with way less bugs and way more
features. FWIW, the bigger the project, the bigger the chances that you
could cut it by half with a good refactoring.

Perhaps you should get in touch with the advocacy-sig mailing list and
provide them with the concrete details, because although you and I
(and many others) recognise intuitively that Python code is typically
shorter than, say, Java because the boilerplate of the latter is
unnecessary, the last big discussion I recall about Python code being
shorter than that of statically typed languages didn't really yield
much in the way of actual projects to make the case.

Or just writing and reading.

Maybe, but I'd imagine that the project mentioned is a fairly large
one with all the classic observations by Brooks highly applicable.
Such things can incur huge costs in a large project.

Clueless again. Python is pretty good for large projects.

It might be good for large projects but is it good for large projects
*such as the one mentioned*?

Now the point
is that it tends to make them way smaller than some other much more
static languages. As an average, you can count on something between 5:1
to 10:1 ratio between Java (typical and well-known reference) and Python
for a same feature set. And the larger the project, the greater the ratio.

Again, I don't doubt this intuitively, but many people do doubt it.
Citation needed!

[...]

Do you really think you're talking to a bunch of clueless newbies ? You
can bet there are quite a lot of talented *and experimented* programmers
here.

Maybe, but with the style of discourse you've been using, you're not
really speaking for them, are you?

Plain wrong.

I'm not a big fan of lots of up-front declarations when the code is
easy to understand intuitively, but what are you trying to say here?
That interface specifications and encapsulation are as essential for a
three line script as they are for a large project?

You still fail to get the point. Interface specifications and
encapsulation are design principles. period. These principles are just
as well expressed with documentation and naming conventions, and the
cost is way lower.

I guess it depends on how the documentation gets written, because from
what I've seen documentation is one of the more neglected areas of
endeavour in software development, with many development organisations
considering it a luxury which requires only a cursory treatment in
order to get the code out of the door.

Russ, do yourself a favor : get out of your cargo-cult one minute and
ask yourself whether all python users are really such a bunch of
clueless newbies and cowboy hackers. You may not have noticed, but there
are some *very* talented and *experimented* programmers here.

Maybe, but I'd hope that some of those programmers would be at least
able to entertain what Russ has been saying rather than setting
themselves up in an argumentative position where to concede any
limitation in Python might be considered some kind of weakness that
one should be unwilling to admit.

Paul

 

[Russ P.]

Maybe, but I'd hope that some of those programmers would be at least
able to entertain what Russ has been saying rather than setting
themselves up in an argumentative position where to concede any
limitation in Python might be considered some kind of weakness that
one should be unwilling to admit.

Thanks. I sometimes get the impression that Desthuilliers thinks of
this forum like a pack of dogs, where he is the top dog and I am a
newcomer who needs to be put in his place. I just wish he would take a
chill pill and give it a rest. I am not trying to challenge his
position as top dog.

All I did was to suggest that a keyword be added to Python to
designate private data and methods without cluttering my cherished
code with those ugly leading underscores all over the place. I don't
like that clutter any more than I like all those semi-colons in other
popular languages. I was originally attracted to Python for its clean
syntax, but when I learned about the leading-underscore convention I
nearly gagged.

If Desthuilliers doesn't like my suggestion, then fine. If no other
Python programmer in the world likes it, then so be it. But do we
really need to get personal about it? Python will not be ruined if it
gets such a keyword, and Desthuilliers would be perfectly free to
continue using the leading-underscore convention if he wishes. Where
is the threat to his way of life?