Python was designed (was Re: Multi-threading in Python vs Java)
Steven D'Aprano
steve at pearwood.info
Tue Oct 15 04:50:10 EDT 2013
On Tue, 15 Oct 2013 10:11:53 +1100, Chris Angelico wrote:
> On Tue, Oct 15, 2013 at 6:18 AM, John Nagle <nagle at animats.com> wrote:
>> Old-style classes vs. new-style classes.
>
> By the time I started using Python, new-style classes existed and were
> the recommended way to do things, so I never got the "feel" for
> old-style classes. I assume there was a simplicity to them, since
> new-style classes were described as having a performance cost, but one
> worth paying. My guess is it comes under the category of "would have to
> be omniscient to recognize what would happen"; Steven, maybe you can
> fill us in?
Heh, I'm not privy to why GvR decided to have built-in types and classes
be distinct :-) but it wasn't a performance issue. The very first
versions of Python didn't have user-defined types at all:
http://python-history.blogspot.com.au/2009/02/adding-support-for-user-
defined-classes.html
For a while classic classes were faster, but I don't think that's been
the case for a long while now.
You can read up more about the unification of types and classes here:
http://www.python.org/download/releases/2.2.3/descrintro/
and the associated PEPs:
http://www.python.org/dev/peps/pep-0252/
http://www.python.org/dev/peps/pep-0253/
but note that the PEPs may no longer reflect the current implementation.
The descrintro document above is interesting for its explanation of how
descriptors work.
>> Adding a
>> boolean type as an afterthought (that was avoidable; C went through
>> that painful transition before Python was created).
>
> I don't know about that. Some languages get by just fine without
> dedicated a boolean type. Python didn't have them, then it had them as
> integers, now it has them as bools.
Actually, Python's bools *are* ints :-)
If you read the whole python-history blog on blogspot, you'll see that
Python's had it's share of mistakes, design failures and other "oops!"
moments. I think that it is a testament to GvR's over-all design that the
end result has been so good, despite the mistakes, as well as Python's
conservative-but-not-too-conservative approach to changes. Compared to
(say) Firefox, which comes out with new releases seemingly twice a week,
Python is slow to change and conservative; compared to (say) Fortran,
which changes in a time-span of decades rather than years, it's quite
fast moving. I think Python has more or less hit the sweet-spot.
--
Steven
More information about the Python-list
mailing list