Does Python really follow its philosophy of "Readability counts"?
tjreedy at udel.edu
Wed Jan 14 03:57:04 CET 2009
Russ P. wrote:
> On Jan 13, 5:29 pm, alex23 <wuwe... at gmail.com> wrote:
>> On Jan 14, 10:45 am, "Russ P." <Russ.Paie... at gmail.com> wrote:
>>> The Wikipedia entry for "object-oriented programming" also lists
>>> encapsulation as a "fundamental concept."
>> The Wikipedia entry for "encapsulation" defines it as "the grouping
>> together of data and functionality".
>> That sounds like Python classes & modules to me.
> Here's the definition on the Wikipedia page for object oriented
> programming (and it does *not* sound like Python classes):
> Encapsulation conceals the functional details of a class from objects
> that send messages to it. ... Encapsulation is achieved by specifying
> which classes may use the members of an object. The result is that
> each object exposes to any class a certain interface — those members
> accessible to that class. The reason for encapsulation is to prevent
> clients of an interface from depending on those parts of the
> implementation that are likely to change in future, thereby allowing
> those changes to be made more easily, that is, without changes to
> clients. For example, an interface can ensure that puppies can only be
> added to an object of the class Dog by code in that class. Members are
> often specified as public, protected or private, determining whether
public = no leading underscore
private = one leading underscore
protected = two leading underscores
Python uses encapsulation by convention rather than by enforcement.
> they are available to all classes, sub-classes or only the defining
> class. Some languages go further: Java uses the default access
> modifier to restrict access also to classes in the same package, C#
> and VB.NET reserve some members to classes in the same assembly using
> keywords internal (C#) or Friend (VB.NET), and Eiffel and C++ allow
> one to specify which classes may access any member.
More information about the Python-list