Are the critiques in "All the things I hate about Python" valid?

boB Stepp robertvstepp at gmail.com
Fri Feb 16 23:54:12 EST 2018


On Fri, Feb 16, 2018 at 10:05 PM, Ben Finney <ben+python at benfinney.id.au> wrote:

> He blithely conflates “weakly typed” (Python objects are not weakly, but
> very strongly typed) with “dynamically typed” (yes, Python's name
> binding is dynamically typed). Those are two, orthognal dimensions to
> describe a language.
>
> All the assertions about “strongly typed” should instead be read as
> “statically typed”. I do not think the author understands the
> differences, nor the trade-offs involved, in the weak–strong dimension
> nor the static–dynamic dimension.

I should have caught the "weakly typed" error.  But I was too
distracted by his "type safety" train of thought.  And this is one I
am still puzzling over:  Are statically-typed languages inherently
"safer" than properly implemented dynamically-typed languages?  I can
see the advantages of catching type errors at compile time versus run
time.  And with the relatively recent introduction of type hints to
python, I was wondering if this was indeed a perceived,
need-to-correct weakness by the python devs?  But I have seen myself
the advantages of being able to rebind identifiers to differently
typed objects than what they started out being bound to.  So I do not
have enough knowledge to properly evaluate software safety or
robustness in terms of how a language is typed.

> A strong hint is in the complaint about the Global Interpreter Lock.
> This is a property of only one implementation: the CPython
> implementation. It is a known limitation and many people have worked for
> many years to ameliorate it; it is unclear whether the author knows of
> anything done in recent years (the only specific information cited is
> for 2012; a reminder, that's *six years ago*, a aeon in platform
> development).

This is another of my big technical weak spots.  I currently believe
that doing concurrent and asynchronous programming is a difficult
chore in any language, but I have yet gotten to the point of where I
know enough to start struggling myself with these forms of
programming.  I do know from some of my books that there are ways
despite the GIL to handle these types of programming problems with the
current CPython implementation.  But I do not know enough to evaluate
how well or poorly python can make use of multicore processors.

> The author also uses very old information when complaining about Python
> 2 versus Python 3. The citation of grave fears is to a 2014 article. The
> author shows no signs of awareness that the Python 3 ecosystem is very
> healthy today compared to Python 2.

I mostly dismissed out of hand this section.  The only disturbing
part, in my mind, was the claim that individual companies have python
2 vs. 3 rifts within their companies.  I hope that is not really true.

> The complaint about abstractions makes another silly conflation; the
> author seems to think any language that does object-orientation
> differently from Java, is obviously wrong. The author may benefit from
> reading <URL:http://dirtsimple.org/2004/12/python-is-not-java.html>
> (advice which is no less relevant than in 2004). But maybe not.

Again, my only concern here was software safety issue claims.  Does
locking down object attribute access by the language necessarily
improve software safety or robustness?  I actually like python's
"we're all consenting adults" mentality.  It seems to me that the
quality of the code is more reflective of the quality of the
programmers than protecting (mediocre?) programmers from themselves by
language design.  But then again, maybe these sorts of language design
restrictions make for fewer errors, even by excellent programmers,
than not doing so.  Again, I don't believe I know enough to
intelligently evaluate the pros and cons.

> The author acknowledges in the conclusion that “nothing I’ve said is
> new”. I would argue that most of what is said is not even true; the
> article should not be referenced at all, IMO.
>
Ben, I guess I am trying to be more charitable in my interpretation of
the author's intent and actual knowledge.  I was led to this article
via one of the two weekly python news collation email services that I
subscribe to, so I am hoping to learn something from the article and
everyone's feedback.  What's the old saw?  Even a blind squirrel finds
a nut once in a while?

Thanks!
-- 
boB



More information about the Python-list mailing list