As a design goal Python aims to be as little flexible as possible to enforce its design goal of making code readable at any and every cost.
In fact its so brittle merely small time changes to a print statement has caused nearly a 8 year backward incompatible ecosystem which is still catching up.
I can't image what would happen when some new ideas have to bought in the language to keep pace. Keep going through migration cycle every 6-7 years to handle backward incompatible changes.
The story till now was some how okayish. Basically Python was playing a catch up game with Perl to get the popular features Perl has. It still hasn't succeeded completely, and yet has a heavily fragmented ecosystem between 2.x and 3.x dev branches. I don't see anything new going into Python any time sooner.
>> As a design goal Python aims to be as little flexible as possible to enforce its design goal of making code readable at any and every cost.
I think that's a very narrow way of defining flexibility.
By your definition of flexibility, C++ must be really flexible because its template system is Turing Complete and you can do whatever you like!
By the same definition, Scheme must be a pretty inflexible language because its syntax is extremely limited (simple).
Python is flexible in that:
- it can be used in many different fields (because libraries exist for science, web -- you can find a library in Python for pretty much any task you can imagine).
- there a number of different implementations of the language to suit your needs (CPython, Pypy for speed, now Micropython for embedded). It is (somewhat) easily ported to other platforms (e.g. ARM, JVM, .NET).
- the language still allows you to do imperative, OO and to some degree functional programming. I don't think allowing Python to do everything under the Sun makes it "flexible".
- Python's dynamism (look at something like the library "sh"), ducktyping, keyword arguments make it flexible.
--
Final point: I think using Python 3's print statement as an example of Python being inflexible is dishonest. Python 3 had major internal changes made to it. The backward incompatible jump between 2 and 3 (AFAIK) was more a choice and a requirement. Guido has recently (just last year) said that he will never do anything like Python 2 -> Python 3 transition again.
> In fact its so brittle merely small time changes to a print statement has caused nearly a 8 year backward incompatible ecosystem which is still catching up.
Something which can be automatically ported with full backwards-compatibility for the last couple releases of the 2.x branch isn't a good example. You'd do better discussing the bytes / unicode growing pains since that may require a human to think about the problem.
As a design goal Python aims to be as little flexible as possible to enforce its design goal of making code readable at any and every cost.
In fact its so brittle merely small time changes to a print statement has caused nearly a 8 year backward incompatible ecosystem which is still catching up.
I can't image what would happen when some new ideas have to bought in the language to keep pace. Keep going through migration cycle every 6-7 years to handle backward incompatible changes.
The story till now was some how okayish. Basically Python was playing a catch up game with Perl to get the popular features Perl has. It still hasn't succeeded completely, and yet has a heavily fragmented ecosystem between 2.x and 3.x dev branches. I don't see anything new going into Python any time sooner.
Python is as little flexible as it gets.