On Tue, Oct 15, 2013 at 6:18 AM, John Nagle <na...@animats.com> wrote: > On 10/12/2013 3:37 PM, Chris Angelico wrote: >> "Designed". >> >> You simply can't get a good clean design if you just let it grow by >> itself, one feature at a time. > > 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. 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.
Oh, Python's design wasn't perfect - that's a pretty much impossible goal anyway. Sometimes you don't learn what you ought to have done till it's been in production for a while - that's why, for instance, these happened: https://wiki.theory.org/YourLanguageSucks#Fixed_in_Python_3 You'd have to be completely omniscient to avoid that kind of misjudgment, and breaking backward compatibility is such a major cost that sometimes design errors just have to be kept. But you'll still end up with something far cleaner than would come from ad-hoc undirected changes; it'll be a design with warts, rather than a lack of design. > The type system is now in good shape. The next step is to > make Python fast. Python objects have dynamic operations suited > to a naive interpreter like CPython. These make many compile > time optimizations hard. At any time, any thread can monkey-patch > any code, object, or variable in any other thread. The ability > for anything to use "setattr()" on anything carries a high > performance price. That's part of why Unladen Swallow failed > and why PyPy development is so slow. Yeah, this does make things hard. But that dynamism is a fundamental part of Python's design, even if it's used by almost nothing. I'd say this isn't proof of a design error, just a consequence of a design decision. Python isn't for everyone, nor for every task - sometimes it'll be too slow for what you want. So be it! There are plenty of places where it's good. And there are similar languages (hi Pike!) for when you want a bit more performance. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
