Python was designed (was Re: Multi-threading in Python vs Java)

[Steven D'Aprano]

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