Is Python growing?

[Matthew Dixon Cowles]

On Thu, 27 Jun 2002 23:34:36 +0100, a.clarke11
<a.clarke11 at pop.ntlworld.com> wrote:

> My question is, I use 2.1 and by the time I need to update, probably
> the version number will have reached Python 3.xx. Will that version
> have the inherent simplicity that makes 2.1 so usable? Or will it
> become more complex, and lose some of its original ease of use? By
> more complex, I mean will it have a steeper learning curve for
> newbies, will it be slower, will the download take longer, and will
> the featurelist be significantly longer?  Other things develop until
> they lose their function, eg flowers, saplings, clouds: can Python
> avoid increasing complexity, is that the present trend in
> development?

Dear Tony,
Entire flamewars have been written on the subject <wink> but here's my
opinion: I suspect that you'll be OK. Indeed, I'm placing my own bets
that way.

Here's why I think that: It's not just complexity that's good to
avoid, it's certain kinds of complexity. Python will surely get new
features, but Python doesn't have to be much harder to learn and can
be easier to use if (only) the right features are included.

Python is wonderfully easy to get started with. But someone who's new
to programming doesn't need to learn everything about Python in order
for it to be useful and fun. (That sounds obvious but it's less true
in many other languages.) So if Guido adds a feature here and there,
that doesn't necessarily make the learning curve much worse. I've been
using Python for some years now and there are corners of the standard
library that I haven't explored because I haven't needed to. Indeed,
there are aspects of the core language that I haven't found out much
about because I haven't needed them.

On the other hand, some features make Python much easier to use and
read. A while ago, I replaced:

def lengthOfLongestStr(list):
  l=len(list[0])
  for count in range(1,len(list)):
    if len(list[count])>l:
      l=len(list[count])
  return l

with

def lengthOfLongestStr(myList):
  return max([len(s) for s in myList])

To my eye, the second one is much easier to read. Similarly, writing
something like:

countWidgetsFound=countWidgetsFound+1

as

countWidgetsFound+=1

makes the intention clearer and avoids the chance of making a typo.

I'm happy to trust Guido to add the right features.

Regards,
Matt