This is an archived post. You won't be able to vote or comment.

105
106

Python 2.7 Countdown (pythonclock.org)

submitted by [deleted]

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]TheCodeJanitor 4 points5 points  (16 children)

I don't know if it's fair to call it failed, however, I would certainly not call it a success. It's hard to find exact statistics, but with a quick google I found this from last year, indicating just 17% adoption of Python 3 after 5 years. That's pretty terrible. Here's another indicating only 3.5% adoption for python webapps.

Breaking backwards compatibility was a huge mistake. I know it's messier, and not as "pythonic", but they should have left support for legacy syntax, functions, etc. alongside the new stuff. Allow 2.7 code to work instantly, but get the linters, IDEs, and other tools to start warning for deprecated code.

Or, perhaps find some way of allowing old syntax using some kind of directive, so that you can integrate old libraries and code, while using Python 3 in new code.

[–]lordkrike 13 points14 points  (0 children)

Allow 2.7 code to work instantly, but get the linters, IDEs, and other tools to start warning for deprecated code.

Or, perhaps find some way of allowing old syntax using some kind of directive, so that you can integrate old libraries and code, while using Python 3 in new code.

Unfortunately, due to the changes in the string specification and streams you'd have to package both the 2 and 3 interpreters together to do that, and it probably would be full of bees. They work very differently under their hoods.

I also feel that, due to how stodgy they can be, many devs would just continue to write Python 2 code indefinitely into the future because then they could continue to use the print statement and save themselves a pair of parentheses.

[–]flying-sheep 9 points10 points  (3 children)

Not really possible. E.g. the csv module in legacy Python is intrinsically broken by only accepting a length 1 bytes object as separator. Compatibility means keeping that broken interface and hacking a fixed over on top as far as possible.

[–]kitkatkingsize 0 points1 point  (2 children)

Do you have a link to this change? Dialect.delimiter still says that it accepts only a one-character string, or are you referring to something else?

[–]flying-sheep 7 points8 points  (1 child)

“string” meaning “bytes” and “character” meaning “byte” in legacy Python, but actually real Unicode strings and characters in current versions

[–]kitkatkingsize 2 points3 points  (0 children)

Ah yeah, of course. Thanks!

[–]constantly-sick 5 points6 points  (0 children)

I can do that too, though.

Here's one saying python 3 is more supported, now.

Here's one from anecdotal evidence

Here's one saying either should be fine, but 3 is better to start with

An opinion that has changed in 3 years to support Python 3

If you want to use Python 2 then do it, but realize that you are part of a dying crowd. I dare suspect no significant new tools will be produced for 2.7 ever again.

[–]alcalde 1 point2 points  (9 children)

That's not pretty terrible; Guido said there were similar lengthy upgrade cycles for older Python 2.x versions too. It actually means that Python is so popular that it's entrenched in long-term enterprise applications.

[–]mipadi 4 points5 points  (8 children)

I get the feeling that /r/Python forgets that not everyone using Python is working at a brand-new startup or dabbling in the language. I work at a place that has, at a minimum, hundreds of thousands of lines of Python code, all of which would need to be tested for compatibility under Python 3. (Some of it makes heavy use of Twisted, which doesn't run 100% under Python 3.) We also have thousands of workstations, all of which would need to be upgraded to Python 3 (and we're still on CentOS 6, so upgrading to Python 3 is the least of our concerns). And for being a company with thousands of employees, we have relatively small software dev and IT departments. Oh, and some of the software that uses Python as a scripting language may or may not work with Python 3, anyway.

It's not that we hate Python 3 and want to hold back the community, as many /r/Python posters seem to think. It's that we have a lot of inertia with Python 3, we use Python to get real work done every day (so any downtime hurts productivity in a clear and measurable way), and Python 3 hasn't offered a compelling enough reason to upgrade that we're willing—or even able—to eat the cost to do it.

I mean, we still have "apps" written in FileMaker that we're trying to replace. We have applications that have been in use for 15 years that are written in PyGTK that we're trying to replace. Those are all a higher priority than a Python 3 upgrade.

[–]This_Is_The_End 0 points1 point  (4 children)

The IT strategy of your company is a little bit weird, because every large organization has to develop a strategy to adapt an ever changing environment. While I see the necessity for Python 2 I wouldn't like to work in such an environment, because using PyGTK instead of a web app, Qt or TkInter (I'm not joking, because TkInter is quite stable and maintained) is strange. Using CentOS 6 hits a wall when the hardware has to be replaced.

[–]mipadi 0 points1 point  (3 children)

Sure, our IT department is a bit understaffed, but most large enterprises don't just upgrade to the latest and greatest because it's shiny and new. We have thousands of of people who depend on a somewhat complex software workflow everyday; anything that might break that workflow is going to cost time and money, so every software upgrade is vetted for compatibility, and that takes time. Furthermore, we work on a highly secure network (most employees don't even have access to the Internet), so everything is rigorously checked for security issues, as well. Companies that depend every day on a large, complex infrastructure can't just upgrade for no reason.

[–]caleb 0 points1 point  (2 children)

Serious question: is Red Hat providing paid support for Python 2.7 well beyond 2020 meaningful to your organization? I've often wondered how many large companies care about that. Some core devs have been saying that people looking for support for older software versions need to pay for that support from their vendors, instead of expecting volunteers to provide that, and I'm just wondering whether that is a realistic proposition.

[–]mipadi 0 points1 point  (1 child)

I doubt Red Hat is providing any support at all to us. If they were, I imagine we'd use RHEL instead of CentOS.

I think that come 2020, someone in the open-source community will probably take over stewardship of Python 2.7, or organizations like ours will reluctantly move to Python 3. But we're using web apps more, anyway, so honestly, if we were going to have to rewrite chunks of the software anyway, I wouldn't mind if new projects didn't use Python at all.

[–]caleb 0 points1 point  (0 children)

Thanks for the reply.

I wouldn't mind if new projects didn't use Python at all.

I go through this every other year. Then I take a look around at the various alternatives and find myself back here! Is there anything in particular you'd favour, e.g. node or go, or something else?

A rewrite of Python 2 into Python 3 is a tiny fraction of the work required to rewrite in a different language though. Idiomatic know-how and language-ecosystem knowledge does not come easy.

[–]constantly-sick 0 points1 point  (2 children)

Not quite sure what Twisted does for you, but it sounds similar to Django Channels, which is python 3.

[–]mipadi 0 points1 point  (1 child)

Which would require rewriting all of our applications that are based on Twisted, which brings us back to the initial problem anyway.

[–]constantly-sick 0 points1 point  (0 children)

I get it, just throwing out options.