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

L

Luis Zarrabeitia

I suggested that maybe -- maybe! -- the versatility of Python could be
enhanced with enforced data hiding. I was careful to say several times
that I don't know if that can even be done in Python (with all its
introspection and so forth). And it would always be optional, of
course (as far as I know, no language forces anyone to declare
anything private).

I think you still fail to see that what we are objecting is not that the
original writer can "optionally" use the enforced data hiding (which, as
someone pointed out before me, can be done with tools like pylint). The
objection is about the _user_ of the library. If you don't force it into the
_user_, how is it different from the current situation? And if you do force
it, how can you say that it is optional?
 
R

Russ P.

I think you still fail to see that what we are objecting is not that the
original writer can "optionally" use the enforced data hiding (which, as
someone pointed out before me, can be done with tools like pylint). The
objection is about the _user_ of the library. If you don't force it into the
_user_, how is it different from the current situation? And if you do force
it, how can you say that it is optional?

As I have pointed out several times, the user cannot be forced to
respect data hiding if he has access to the source code (and the right
to modify it). If Python had a "private" keyword (or equivalent), for
example, the user would only need to delete it wherever necessary to
gain the desired access.
 
M

Mark Wooding

[No, my email address doesn't begin `m...@'. Fixed.]

Michele Simionato said:
I agree that CLOS is complex and that it can be compiled very
aggressively, but I do not think that it is more dynamic than Python.
What feature are you alluding to? Multimethods? There are many Python
implementations of them, they are just not in the standard library.
Or are you referring to interactive facilities, such as the one
discussed in this recipe http://code.activestate.com/recipes/160164 ?

I'm referring to a number of features:

* Redefinition of classes, yes. Interactive development is very
frustrating without this. Thanks for that link, by the way!

* CHANGE-CLASS to change the class of instances. This is more than
just assigning to mumble.__class__, since it correctly initializes
the slots present in the new class which were absent in the old.

* And all of the fancy MOP tricks you can play: inventing new slot
classes; messing with class-precedence-list orderings (Python's
MRO).

It's a shorter list than I'd hoped! Still, these features kind of
multiply up. You can redefine a class using a new metaclass and slot
options, and all the instances are updated, for example.

Anyway, I think I exaggerated when I said that CLOS was `much more
dynamic', but it is /somewhat/ more dynamic, and still amenable to
optimization; since my point was that dynamism in a language isn't
necessarily antithetical to compilation, that's still sufficient.

Thanks for keeping me honest!

-- [mdw]
 
R

Rhamphoryncus

Judging from this thread, not everyone got the memo yet. At least
three or four people on this thread alone have argued that enforced
data hiding is of no value whatsoever for any application or domain.
And more than one of them has argued that Python is perfectly
appropriate for even the largest and most safety-critical projects.

We are moving into an era of increasing dependence on computers and
software for safety-critical, mission-critical, and  financial
systems. If people who do not understand the principles  necessary for
ultra-reliable software get in charge of developing these systems, we
will have serious problems that could have been avoided.

I suggested that maybe -- maybe! -- the versatility of Python could be
enhanced with enforced data hiding. I was careful to say several times
that I don't know if that can even be done in Python (with all its
introspection and so forth). And it would always be optional, of
course (as far as I know, no language forces anyone to declare
anything private).

Several people here seem to take that suggestion as an assault on
Python and, by projection, an assault on their worldview. We all know
that Python is a fantastic language for many purposes, but it is only
a language, and failing to recognize and address its limitations
serves no useful purpose.

What you need is a middle ground. Something that can be *easily*
circumvented for debugging, unit tests, and "friend" functions/modules/
class.

Without suggesting a middle ground people are left assuming C++-style
privates/protected, which would be a significant burden on everybody.
The only way it wouldn't is if nobody actually uses it, except in
specialized high-assurance software, but at that point you might as
well fork python (or use metaclass trickery).
 
M

Mark Wooding

Russ P. said:
If Python had a "private" keyword (or equivalent), for example, the
user would only need to delete it wherever necessary to gain the
desired access.

And you obviously weren't listening when we said that having to make
source code changes to upstream modules was a serious maintenance and
distribution headache: <[email protected]>

-- [mdw]
 
L

Luis Zarrabeitia

As I have pointed out several times, the user cannot be forced to
respect data hiding if he has access to the source code (and the right
to modify it). If Python had a "private" keyword (or equivalent), for
example, the user would only need to delete it wherever necessary to
gain the desired access.

And, as others and I have pointed out several times, that would mean to
maintain a fork. Would you say that current C++ has "optional" enforced data
hiding for the user? After all, you can just fork the module (and if you
don't have the source, you could mess with pointers until you find it).

Also, I once pointed out that "access to the source code and right to modify
it" is not a given.

What you are proposing is not optional at all. You want the power to control
what others do - and while it may be your legal right, it's also everyone
else's right not go our of our ways to help you have it.
 
M

Michele Simionato

I'm referring to a number of features:

  * Redefinition of classes, yes.  Interactive development is very
    frustrating without this.  Thanks for that link, by the way!

  * CHANGE-CLASS to change the class of instances.  This is more than
    just assigning to mumble.__class__, since it correctly initializes
    the slots present in the new class which were absent in the old.

  * And all of the fancy MOP tricks you can play: inventing new slot
    classes; messing with class-precedence-list orderings (Python's
    MRO).

It's a shorter list than I'd hoped!  Still, these features kind of
multiply up.  You can redefine a class using a new metaclass and slot
options, and all the instances are updated, for example.

Anyway, I think I exaggerated when I said that CLOS was `much more
dynamic', but it is /somewhat/ more dynamic, and still amenable to
optimization; since my point was that dynamism in a language isn't
necessarily antithetical to compilation, that's still sufficient.

Thanks for keeping me honest!

Fair enough. My view is that even if apparently CLOS has some
additional feature over the standard Python object model, in practice
you can implement the same features in Python with some metaclass
trick, *without the need to change the language at the C level*. This
is why I think the Python object model is at least as dynamic as CLOS.
In particular, a metaclass can implement the functionality CHANGE-
CLASS, can mess with the __bases__ and with the MRO, etc.
If you want to see an example of how much the Python object model can
be perverted, you may be interested in this module of mine:

http://pypi.python.org/pypi/strait

The module changes the standard object system from a multiple
inheritance one to a single inheritance one plus traits.

Michele Simionato
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top