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

[Bruno Desthuilliers]

Steven D'Aprano a écrit :

That's a fallacious argument. Nobody is arguing that any specific version
of Python is perfect, but clearly many people do like the general design
choices of the language, that is, the way it works.

Thanks for making my point clear.

*If* you don't like the way it works, and you have a choice in the
matter, perhaps you should find another language that works more the way
you would prefer.

On the other hand... Bruno's question is unfair. It is perfectly
reasonable to (hypothetically) consider Python to be the best *existing*
language while still wanting it to be improved (for some definition of
improvement).

And that's the problem : what Paul suggests are not "improvements" but
radical design changes. The resulting language - whatever it may be
worth, I'm not making any judgement call here - would not be Python
anymore.

Just because somebody has criticisms of Python, or a wish-
list of features, doesn't mean they hate the language.

There's probably a whole range of nuances between "not liking" and
"hating". And Paul is of course perfectly right to think that a language
having this and that features from Python, but not this other one, would
be a "better" language (at least according to it's own definition of
"better"). Where I totally disagree is that it would make *Python* better.

Also, my question was not that "unfair" (even if a bit provocative). I
really wonder why peoples that seems to dislike one of the central
features of Python - it's dynamism - still use it (assuming of course
they are free to choose another language). And FWIW, I at least had a
partial answer on this.

 

[Russ P.]

Steven D'Aprano a écrit :



Thanks for making my point clear.



And that's the problem : what Paul suggests are not "improvements" but
radical design changes. The resulting language - whatever it may be
worth, I'm not making any judgement call here - would not be Python
anymore.


There's probably a whole range of nuances between "not liking" and
"hating". And Paul is of course perfectly right to think that a language
having this and that features from Python, but not this other one, would
be a "better" language (at least according to it's own definition of
"better"). Where I totally disagree is that it would make *Python* better..

Also, my question was not that "unfair" (even if a bit provocative). I
really wonder why peoples that seems to dislike one of the central
features of Python - it's dynamism - still use it (assuming of course
they are free to choose another language). And FWIW, I at least had a
partial answer on this.

I think the issue here is the distinction between hacking and software
engineering. I may be misusing the term "hacking," but I do not mean
it in a pejoritive sense. I just mean getting things done fast without
a lot of concern for safety, security, and long-term maintainability
and scalability. I'm not a computer scientist, but it seems to me that
Python is great for hacking and good for software engineering, but it
is not ideal for software engineering.

What Paul is suggesting, I think, is that Python should move in the
direction of software engineering. Whether that can be done without
compromising its hacking versatility is certainly a valid question,
but if it can be done, then why not do it?

Certainly one basic principle of software engineering is data
encapsulation. Tacking new attributes onto class instances all over
the place may be convenient and useful in many cases, but it is not
consistent with good software engineering. If the programmer could
somehow disallow it in certain classes, that could be useful,
providing that those who wish to continue doing it would be free to do
so. If class attributes could somehow be declared private, that would
be useful too. Optional explicit type declarations could also be
useful -- and I believe Python does have that now, so no need to argue
about that.

Why do I continue to use Python when I have so many "complaints" about
it? As everyone here knows, it has many good qualities. My work falls
somewhere in the middle between "hacking" and software engineering. I
am developing a research prototype of a safety-critical system. A
research prototype is not safety-critical itself, and it needs to be
flexible enough to try new ideas quickly, but it also needs to serve
as a model for a well-engineered system. Is Python the right choice? I
think so, but I don't know for sure.

 

[Paul Rubin]

And that's the problem : what Paul suggests are not "improvements" but
radical design changes.

Eh? I think of them as moderate and incremental improvements, in a
direction that Python is already moving in. Radical would be
something like a full-scale static type system.

I really wonder why peoples that seems to dislike one of the central
features of Python - it's dynamism - still use it (assuming of
course they are free to choose another language).

I certainly don't think dynamism is central to Python. In what I see
as well-developed Python programming style, it's something that is
only rarely used in any important way. I'd spend much less time
debugging if I got compiler warnings whenever I used dynamism without
a suitable annotation. The 1% of the time where I really want to use
dynamism I don't see any problem with putting in an appropriate
decorator, superclass, or whatever.

 

[Carl Banks]

Eh?  I think of them as moderate and incremental improvements, in a
direction that Python is already moving in.

I've seen no evidence that any Python project is moving even remotely
toward data encapsulation. That would be a drastic change. Even if
it were only a minor change in the implementation (and it would not
be), it would be a major stroke in the Python community. It would
basically cause a wholescale power shift from the user to the
implementor. As a user it'd be like the difference between living in
a free democracy and a fascist dictatorship.

 Radical would be
something like a full-scale static type system.


I certainly don't think dynamism is central to Python. In what I see
as well-developed Python programming style, it's something that is
only rarely used in any important way.

You're in the minority, then.

 I'd spend much less time
debugging if I got compiler warnings whenever I used dynamism without
a suitable annotation.  The 1% of the time where I really want to use
dynamism I don't see any problem with putting in an appropriate
decorator, superclass, or whatever.

Well, I guess you are the sacrifical lamb so that everyone else can
take advantage of the dynamicism.


Carl Banks

 

[Russ P.]

I've seen no evidence that any Python project is moving even remotely
toward data encapsulation. That would be a drastic change. Even if
it were only a minor change in the implementation (and it would not
be), it would be a major stroke in the Python community. It would
basically cause a wholescale power shift from the user to the
implementor. As a user it'd be like the difference between living in
a free democracy and a fascist dictatorship.

I just googled "object oriented principles." The first site that came
up lists four princicples:

- Encapsulation
- Abstraction
- Inheritance
- Polymorphism

The Wikipedia entry for "object-oriented programming" also lists
encapsulation as a "fundamental concept."

The first line on the python.org site says:

"Python is a dynamic object-oriented programming language that can be
used for many kinds of software development."

How can that possibly be true if you see "no evidence that any Python
project is moving even remotely toward data encapsulation"?

Semantics aside, I fail to understand your hostility toward a
fundamental concept of object-oriented programming. The difference
between a free democracy and a "fascist dictatorship"? Give me a
break!

 

[alex23]

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.

 

[Russ P.]

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
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.

 

[Paul Rubin]

You do realize this is a model and not strictly a requirement. Quite
a few things in Python are done merely by convention.
Don't get caught up.

But, if something is done by convention, then departing from the
convention is by definition unconventional. If you do something
unconventional in a program, it could be on purpose for a reason, or
it could be by accident indicating a bug.

I don't understand why some folks spew such violent rhetoric against
the idea of augmenting Python with features to alert you automatically
when you depart from the convention, so that you can check that the
departure is actually what you wanted. A lot of the time, I find, the
departures are accidental and automated checks would save me
considerable debugging.

 

[James Mills]

But, if something is done by convention, then departing from the
convention is by definition unconventional. If you do something
unconventional in a program, it could be on purpose for a reason, or
it could be by accident indicating a bug.

I don't understand why some folks spew such violent rhetoric against
the idea of augmenting Python with features to alert you automatically
when you depart from the convention, so that you can check that the
departure is actually what you wanted. A lot of the time, I find, the
departures are accidental and automated checks would save me
considerable debugging.

Amen to that! Finally someone with some sense and
his/her head screwed on properly!

Kudos to your thoughtful post

cheers
James

 

[Terry Reedy]

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.

 

[James Mills]

public = no leading underscore
private = one leading underscore
protected = two leading underscores

Python uses encapsulation by convention rather than by enforcement.

As mentioned previously this is not encapsulation, but
access control. But yes correct, this is how we conventionally
define access control over members of an object. It's up to the
programmer correctly adhere to the interface(s).

--JamesMills

 

[Russ P.]

You do realize this is a model and not
strictly a requirement. Quite a few things
in Python are done merely by convention.

Don't get caught up.

--JamesMills

Yes, but the fact that you can approximate OO programming in a
particular language does not make that language object oriented. You
can approximate OO programming in C, but that does not mean that C is
an OO language.

So I can claim that Python is not strictly object oriented until it
gets encapsulation (in the sense of data hiding). That is simply a
fact, and no amount of pleading or obfuscation will change it.

Should Python get true encapsulation? I don't know. Maybe
encapsulation cannot be added without excessive overhead or without
compromising other more important aspects and features of the
language. But I do know that not having encapsulation is a limitation
to the use of Python for good software engineering. I may be in the
minority in the Python "community" on this one, but I am apparently in
the majority in the OO programming "community."

 

[Rhodri James]

But, if something is done by convention, then departing from the
convention is by definition unconventional. If you do something
unconventional in a program, it could be on purpose for a reason, or
it could be by accident indicating a bug.

I wouldn't violently object to having some means of policing class
or module privacy, but it does have consequences. When it's a
convention, you can break it; when it isn't, you can't, even if
you do have good reason. Add that to the obviousness of the
"leading underscore => private" convention, and I just don't see
a burning need for it, that's all.

 

[r]

public = no leading underscore

private = one leading underscore
protected = two leading underscores

Python uses encapsulation by convention rather than by enforcement.

Very well said Terry!

I like that python does not force me to do "everything" but does force
things like parenthesis in a function/method call whether or not an
argument is required/expected. This makes for very readable code.
Visual parsing a Python file is very easy on the eyes due to this fact
-- Thanks Guido! We do not need to add three new keywords when there
is an accepted Pythonic way to handle public/private/protected

 

[James Mills]

Yes, but the fact that you can approximate OO programming in a
particular language does not make that language object oriented. You
can approximate OO programming in C, but that does not mean that C is
an OO language.

Wrong. Not having strict and enforced access control 9_NOT_ encapsulation)
(Please stop confusing the two) is not a strict requirements of the OO model.

Remember that it is a model and not a strict set of requirements that
programming
languages must implement.

In fact, Python borrows features from the Functional Paradigm. Does this
make it a Functional Language ? No. Why ? Because one of the clear
requirements of the Functional Paradigm is that functions cannot have
side affects.

So I can claim that Python is not strictly object oriented until it
gets encapsulation (in the sense of data hiding). That is simply a
fact, and no amount of pleading or obfuscation will change it.

In fact this is true, C can be seen as an programming language
that has features of the OO model.

I think one of the things you guys are missing out
here is that there are really only two Paradigms
or Machines. Functional and Imperative. And guess
what ? As it turns out we can implement functional
machines that run on top of imperative ones!

Should Python get true encapsulation? I don't know. Maybe
encapsulation cannot be added without excessive overhead or without
compromising other more important aspects and features of the
language. But I do know that not having encapsulation is a limitation
to the use of Python for good software engineering. I may be in the
minority in the Python "community" on this one, but I am apparently in
the majority in the OO programming "community."

Again, stop confusing terminology.

Should Python get strict and enforce access control
of object members ? No. Why ? I can think of several
reasons.

Give me one use-case where you strictly require
that members of an object be private and their
access enforced as such ?

cheers
James

 

[James Mills]

Very well said Terry!

I like that python does not force me to do "everything" but does force
things like parenthesis in a function/method call whether or not an
argument is required/expected. This makes for very readable code.
Visual parsing a Python file is very easy on the eyes due to this fact
-- Thanks Guido! We do not need to add three new keywords when there
is an accepted Pythonic way to handle public/private/protected

Agreed. Furthermore there very few cases where you need
to distinguish between whether an object's attribute is public
or private or even protected.

Consider the following two pieces of code and tell me
which is more Pythonic:

class A(object):

def __init__(self):
self.x = None

def setX(self, v):
self.x = v

def getX(self):
return self.x

----------------------------------------

class A(object):

def __init__(self):
self.x = None

I'll give you a hint ... It's the simpler one

cheers
James

 

[Carl Banks]

I just googled "object oriented principles." The first site that came
up lists four princicples:

- Encapsulation
- Abstraction
- Inheritance
- Polymorphism

The Wikipedia entry for "object-oriented programming" also lists
encapsulation as a "fundamental concept."

The first line on the python.org site says:

"Python is a dynamic object-oriented programming language that can be
used for many kinds of software development."

How can that possibly be true if you see "no evidence that any Python
project is moving even remotely toward data encapsulation"?

Is this seriously your argument? Python must be moving towards data
encapsulation because there is a line in Python.org that, if you
blindly accept the Wikipedia definition as truth, indirectly implies
that it is?

Are you *seriously* arguing this?

The argument is too ridiculous to deserve a refutation, so I'll just
point out two things:

1. Wise people don't believe everything that is written on Wikipedia.
2. The person who wrote that line in Python.org is a wise person.

Semantics aside, I fail to understand your hostility toward a
fundamental concept of object-oriented programming. The difference
between a free democracy and a "fascist dictatorship"? Give me a
break!

You know what? Computer science buzzwords mean jack squat to me. I
don't give a horse's tail whether some people label it a fundamental
concept of object-oriented programming or not. I think it's a bad
thing. And it's a bad thing for exactly the reason I said: it gives
the library implementor the power to dictate to the user how they can
and can't use the library. The cultural impact that would have on the
community is far worse, IMHO, than any short-sighted benefits like
being able to catch an accidental usage of an internal variable.
Trust would be replaced by mistrust, and programming in Python would
go from a pleasant experience to constant antagonism.

No thanks. "Software engineering" be damned. Python is better off
the way it is.


Carl Banks

 

[Carl Banks]

The cultural impact that would have on the
community is far worse, IMHO, than any short-sighted benefits like
being able to catch an accidental usage of an internal variable.
Trust would be replaced by mistrust, and programming in Python would
go from a pleasant experience to constant antagonism.

And I'll give you a perfect example:

XML-DOM versus ElementTree

XML-DOM is the sort of standard that is borne of a culture that values
encapsulation, strict type safety, and so on. It's the way it is
because designers were allowed to distrust the user, and the culture
said that it was good to distrust the user. Consequently, the
interface is a pain to use, with all kinds of boilerplate and iterator
types and such.

ElementTree was borne out of an environment where implementors are
forced to trust the user. As a consequence it was free to create an
interface that was natural and straightforward and pleasant to use,
without having to be guarded.


Carl Banks

 

[r]

[snip]
it gives

the library implementor the power to dictate to the user how they can
and can't use the library.  The cultural impact that would have on the
community is far worse, IMHO, than any short-sighted benefits like
being able to catch an accidental usage of an internal variable.
Trust would be replaced by mistrust, and programming in Python would
go from a pleasant experience to constant antagonism. [snip]
Carl Banks

I agree, the second the Python interpretor say's NO! you cant do that
or i will wrap your knuckles! is the day i leave Python forever. I
hear C programmers complain all the time about Python saying; "Well, I
like in "C" that variable types must be declared because this keeps me
from making mistakes later" -- hog wash! Just learn to think in a
dynamic way and you will never have any problems. If you need a hand
holding language i guess Python is not for you. And don't forget, you
can learn a lot from your mistakes.

They are so brainwashed by this mumbo-jumbo, i see them do this all
the time...

int_count = 0
float_cost = 1.25
str_name = "Bob"

They can't think in a dynamic way because momma "C" has done it for
them for too long. "Eat your Peas and carrots now little C coder"

 

[James Mills]

1. Wise people don't believe everything that is written on Wikipedia.
2. The person who wrote that line in Python.org is a wise person.
Agreed.

You know what? Computer science buzzwords mean jack squat to me. I
don't give a horse's tail whether some people label it a fundamental
concept of object-oriented programming or not. I think it's a bad
thing. And it's a bad thing for exactly the reason I said: it gives
the library implementor the power to dictate to the user how they can
and can't use the library. The cultural impact that would have on the
community is far worse, IMHO, than any short-sighted benefits like
being able to catch an accidental usage of an internal variable.
Trust would be replaced by mistrust, and programming in Python would
go from a pleasant experience to constant antagonism.
+1

No thanks. "Software engineering" be damned. Python is better off
the way it is.

Python ihmo is one of the best engineered programming languages
and platform I have ever had the pleasure of working with
and continue to!

--JamesMills