Python was designed (was Re: Multi-threading in Python vs Java)
Steven D'Aprano
steve+comp.lang.python at pearwood.info
Mon Oct 14 23:18:25 EDT 2013
On Mon, 14 Oct 2013 12:18:59 -0700, John Nagle wrote:
> No, Python went through the usual design screwups. Look at how
> painful the slow transition to Unicode was, from just "str" to Unicode
> strings, ASCII strings, byte strings, byte arrays, 16 and 31 bit
> character builds, and finally automatic switching between rune widths.
Are you suggesting that Guido van Rossum wasn't omniscient back in 1991
when he first released Python??? OH MY GOD!!! You ought to blog about
this, let the world know!!!!
But seriously... although the Unicode standard was began as early as
1987, the first official release of the standard wasn't until nine months
after the first public release of Python. Do you really consider it a
"design screwup" that Guido didn't build support for Unicode into Python
since the beginning?
Given the constraints of backwards-compatibility, and that Unicode didn't
even exist when Python was first created, I don't think the history of
Unicode support in Python is a screw-up in the least. And if it is a
screw-up, it's *Unicode's* screw-up, because they're the ones that
thought that 16-bit chars would have been enough in the first place.
While it would have been nice if Python had invented the idea of using
different rune widths back in Python 2.2, I don't think we can hold it
against GvR or the other Python devs that they didn't. They're only
human. As far as I know, only one other language does such a thing,
namely Pike, which is not exactly high-profile.
> Old-style classes vs. new-style classes. Adding a boolean type as an
> afterthought (that was avoidable; C went through that painful transition
> before Python was created). Operator "+" as concatenation for
> built-in arrays but addition for NumPy arrays.
>
> Each of those reflects a design error in the type system which
> had to be corrected.
Perhaps the first one -- had GvR not decided in the first place that
built-in types should be separate from user-defined classes, the old vs
new style class thing would have been unnecessary. But bools are not an
example. The decision to leave out bools as a separate type was, and
remains, a perfectly legitimate decision. Perhaps one might argue that
Python-with-bools is *better* than Python-without-bools, but we would be
foolish to argue that Python-without-bools was a screw-up. Bools are a
nice-to-have, not a must-have.
And as for numpy arrays, well, if a long-standing Python developer such
as yourself doesn't yet understand that this is a feature, not a mistake,
there's a serious problem, and it's not with Python. Operator overloading
exists precisely so that custom classes aren't limited to the exact same
behaviour as built-ins. The fact that the numpy devs made a different
decision as to what + means than the Python devs is not a sign that the
design was screwed up, it is a sign that the system works.
It is true that numpy has a problem with Python operators in that there
aren't enough of them. There have been various attempts to work out a
good syntax for adding arbitrary additional operators, so that numpy can
have *both* element-wise operators and array-wise operators at the same
time. But the lack of this is not a design screw-up. It's a hard problem
to solve, and sometimes it is better to do without a feature than to add
it poorly.
> The type system is now in good shape. The next step is to
> make Python fast.
Whenever I see somebody describing a *language* as "fast" or "slow",
especially when the next few sentence reveals that they are aware of the
existence of multiple *implementations*:
> Python objects have dynamic operations suited to a
> naive interpreter like CPython. [...] That's
> part of why Unladen Swallow failed and why PyPy development is so slow.
as if "fast" and "slow" were objective, concrete and most importantly
*fixed* standards that are the same for everybody, then I suspect
trolling.
Or to put it another way: Python is already fast. Using PyPy, you can
write pure-Python code that is faster than the equivalent optimized C
code compiled using gcc. Even using vanilla CPython, you can write pure
Python code that (for example) checks over 12,000 nine-digit integers for
primality per second, on a relatively old and slow computer. If that's
not *fast*, nothing is.
Whether it is *fast enough* is a completely different question, and one
which leads to the question "fast enough for what?". But people who like
to complain about "Python being slow" don't like that question.
--
Steven
More information about the Python-list
mailing list