On Tue, 15 Oct 2013 10:11:53 +1100, Chris Angelico wrote: > On Tue, Oct 15, 2013 at 6:18 AM, John Nagle <na...@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 -- https://mail.python.org/mailman/listinfo/python-list