Re: [tlug] Coverity Scan

["Stephen J. Turnbull" <stephen@example.com>]

Josh Glover writes:

 > I think it is down to the fact that Perl was born as awk + sed, then
 > had a bunch of stuff bolted on, whereas Python was designed from the
 > start as a clean, OO (why the primitive types, Guido?)

For efficiency.  The technology of the time didn't allow both object
orientation from the word go, and efficiency.  See Zen Principle #9.
While today's C Python interpreter (VM) is pretty efficient as such
things go, note that JPython (a Python compiler targeting the Java
virtual machine) and IronPython (a Python compiler targeting the .NET
virtual machine) are both of efficiency comparable to C Python.  IOW,
technology has advanced a lot, generic VMs are now competitive with
software designed for the task.

Also, it's trivial to wrap any of the primitive types in a class if
you need that capability.  In Python 3, there no longer is a
distinction between primitive types and classes.  The implementation
is different, but the API is common.  I believe it's still impossible
to do certain things with those classes (for example, I think it's
impossible to derive subclasses from them) but this is a deliberate
restriction rather than imposed by the technology.

The only significant request for derivation from a primitive type is
for string and bytes and is IMO wrong-headed.  People in the web
framework community really want polymorphism across bytes (what you
get from the wire) and strings (what the compiler builds from ""
literals).  What it comes down to is that the *computing* world is
still very much ASCII and you can mostly get away with ignoring
8-bit-set bytes and praying you never see any ISO-2022-JP.  But "I
don't think we're in Kansas any more, Toto," and experience shows that
it's not a good idea to mix the two.  The claim that this is needed
for efficiency seems bogus, given that regexps are used a lot;
compiling one regexp takes as much time as converting 50MB of Latin-1
to Unicode.  Even complex encodings like ISO-2022-JP or UTF-8 can be
converted at 1% of that speed; response time is clearly going to be
dominated by IP latency even for them.

BTW, ISTR that Ruby also had some primitive types, at the class
level.  In Python that was never so.  Classes were objects, and could
be manipulated as such.  You pays your yen and you takes your kroner
(and the bank takes its 1% -- always).

 > language intended for pedagogy.

No, it was intended to be a useful language clean enough for pedagogy.

The communities are very different.  The Python language designers are
mostly elite professionals, while Perl hackers are, well, hackers.
Not quite as bad as Emacs developers, but the cowboy developer ethic
is still there.