Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Does Python really follow its philosophy of "Readability counts"?

Reply
Thread Tools

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

 
 
Luis Zarrabeitia
Guest
Posts: n/a
 
      01-27-2009
On Tuesday 27 January 2009 02:13:50 pm Russ P. wrote:
> 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?

--
Luis Zarrabeitia (aka Kyrie)
Fac. de Matemática y Computación, UH.
http://profesores.matcom.uh.cu/~kyrie
 
Reply With Quote
 
 
 
 
Russ P.
Guest
Posts: n/a
 
      01-27-2009
On Jan 27, 11:40 am, Luis Zarrabeitia <(E-Mail Removed)> wrote:

> 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.
 
Reply With Quote
 
 
 
 
Mark Wooding
Guest
Posts: n/a
 
      01-27-2009
[No, my email address doesn't begin `m...@'. Fixed.]

Michele Simionato <(E-Mail Removed)> writes:

> On Jan 21, 2:11 am, Mark Wooding <(E-Mail Removed)> wrote:
>
>> CLOS is much more complex and dynamic than Python's object system;
>> but it can be compiled very aggressively.

>
> 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]
 
Reply With Quote
 
Rhamphoryncus
Guest
Posts: n/a
 
      01-27-2009
On Jan 27, 12:13*pm, "Russ P." <(E-Mail Removed)> wrote:
> On Jan 26, 6:09 am, Steve Holden <(E-Mail Removed)> wrote:
>
> > Quite. Python is a language "for consenting adults". It has perceived
> > deficiencies for certain software engineering environments. Can we drop
> > the subject now? This horse was flogged to death long ago, and it's
> > pointless and cruel to keep on beating the remains.

>
> 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).
 
Reply With Quote
 
Mark Wooding
Guest
Posts: n/a
 
      01-27-2009
"Russ P." <(E-Mail Removed)> writes:

> 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: <(E-Mail Removed)>

-- [mdw]
 
Reply With Quote
 
Luis Zarrabeitia
Guest
Posts: n/a
 
      01-27-2009
On Tuesday 27 January 2009 02:56:51 pm Russ P. wrote:
> On Jan 27, 11:40 am, Luis Zarrabeitia <(E-Mail Removed)> wrote:
> > 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.


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.

--
Luis Zarrabeitia (aka Kyrie)
Fac. de Matemática y Computación, UH.
http://profesores.matcom.uh.cu/~kyrie
 
Reply With Quote
 
Michele Simionato
Guest
Posts: n/a
 
      01-28-2009
On Jan 27, 9:13*pm, Mark Wooding <(E-Mail Removed)> wrote:
> 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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Its a bird, its a plane, its.. um, an Attribute based System? thunk Ruby 14 04-03-2010 10:08 AM
Its a bird, its a plane, its.. um, an Attribute based System? thunk Ruby 0 04-01-2010 10:25 PM
Its a bird, its a plane, no ummm, its a Ruide thunk Ruby 1 03-30-2010 11:10 AM
Does the Python community really follow the philospy of "CommunityMatters?" r Python 16 02-02-2009 08:21 PM
Its really NOT the camera, its the PICTURE Larry Digital Photography 7 06-02-2004 06:07 AM



Advertisments