How long will Python be around?

You may not be willing to confess your causality‐defying hops to the future, but fortunately there’s someone else who is.

1 Like

I see (almost) all people here are making jokes about time travel and crystal balls. Be serious People! :stuck_out_tongue:

So, to answer Your question seriously, what do you exactly mean when you wrote “planning for the long term”? Do you afraid your knowledge of Python will be obsolete in the future?

I see it that way: even if in the future Python will still be here, it won’t be the same Python we are using today. Python evolves, new features are added, some are deprecated, other ones changes how they work, etc. We have to evolve too, and that means whatever it will be Python or some other yet not invented/unpopular language used in the future, we have MUST to “update” our knowledge about it as the time goes.

@jpivarski I love historical graphs to see trends. Do you have a link to these that anyone can see? Or is this paywalled? I’d like to save the link to the site for future use. For now I’ll save the link to this reply.

I got over 23 years of use from Perl, from 2001 to present. So yes, I have to think ahead. I’ll be retired in about 17 years.

I am liking Python the more I learn about it.

  1. Python handles UTF-8 data more easily. It was a real bear in Perl. In the future we might be able to handle Japanese spreadsheets using Python. Those might be UTF-16 or Unicode, I don’t know yet.
  2. Major Perl forums are essentially dead, or read-only now.
  3. Python is more secure for web apps.
  4. Python handles lists and dicts more easily with fewer lines of code.
  5. Python has sets that are easy.
  6. Python supports regex like Perl.
  7. Perl eventually lost a free Perl 2 Exe program. Python has a free one. This may be useful in the future.

Today I’m about to test getting data from a Postgresql database via Python. Postgres is known to be a really difficult monster to deal with, in Perl at least. It needed special db drivers installed on the machine running the Perl program, separate TLS drivers, and Perl modules.

Well, I can assure you from personal experience that PostgreSQL with Python is a joy to work with :slight_smile:

These historical trends are all screenshots from the various websites that provide them. Here are links to the most recent data. Looking at it now, Python’s lead is more extreme than when I last looked in 2022.

2 Likes

This is so true. I used to use Python 2 all the time with print statements and all. It took so long but now I’m used to and really like: f-strings, type hints (not the super complex ones to be 100% right, but simple ones that are generally right), executors, pathlib, and probably other things.

At first I definitely thought that stuff was just fluff.

The language evolves with time. I don’t see it going away, just evolving with small changes over time to make it better and better… and then big ones like free threading.

3 Likes

You have the opportunity to actively contribute to the ongoing development of the language through participation in the creation and discussion of PEPs (Python Enhancement Proposals).

Suppose, for a moment, that Python didn’t turn out to have 17 more years of maintenance and common use. Why exactly should this require planning ahead? And… what would you actually change, if you could somehow know such a thing?

It’s not as if programming languages - or any other major technologies - disappear suddenly (and it’s not as if the skills aren’t transferable, either). You, of all people, should understand this intimately - having spent more than 20 years on Perl, and personally watched it decline greatly in popularity (TIOBE has it at #29 now - below Prolog!), and seen the story of Raku unfold (development on what was supposed to be Perl 6 had just barely started when you started using Perl, and then seemingly went nowhere, forever).

I still think a lot of that stuff is fluff. But I can remember what a breath of fresh air it was when I first tried out Python 3 (with 3.2).

I hated the weird idiosyncrasies of the print statement, like the trailing commas and >>f. I hated that it was a statement - because other languages didn’t do that, because it showed no clear advantage besides avoiding some parentheses. (I’ve used the print function as HOF before, too.)

But more importantly, I hated the approach to strings. I hated having actual text encodings being conflated with “codecs” for things like base64. I hated being advised to open CSV files in binary mode for the csv module. I hated trying to read from text files with a custom encoding and also make universal newlines work properly. I hated calling an encoding method and being given an exception about decoding, or vice-versa. In my mind, having to go over some old code and add bs to literals that should have been there anyway, was a small price to pay for treating what I already saw as clearly separate types, actually separately. After all, Explicit is better than implicit.

1 Like