3 ms·

Will this will make people less likely to use Python in future for some projects? I'm no developer or manager but I figure there'd be a thought in the back of m

by LIV2 7y ago

Will this will make people less likely to use Python in future for some projects? I'm no developer or manager but I figure there'd be a thought in the back of my head thinking "what if we need to rewrite this all again for the next major release"

xemdetia 7y ago
I don't think it will make people less likely to use Python overall, but for certain categories of projects there are some things that are just done better in other languages. Both Java and Go for example have specific programming language constructs and contracts to ensure that codebases can move from version to version easily and I do not feel like there is a dynamic/untyped language that really provides that same level of stability. The ones that do get close to that are the ones that are extremely small in scope and are not in the same class of batteries included language, and because of their small scope they have a general limit of change. At a certain point this sort of compatibility/forward motion of a codebase through big language revisions is something that has to be designed as part of the language in either being able to break it down into small enough chunks to chew through in pieces (updating a submodule with the updated language without affecting anything else), completely transparent to the code being run through it (this happens for compilers for C for different standards), or to have a version to version automated rewriting mechanism that is so reliable the outcome of the automated tool is not in question (tools like Go's gofmt). Python in my opinion only has partial solutions to all of those answers so it turns into a lot of hand work. So while there are other languages that may do other things better there are still a class of programs that are very effective to write in Python, and that's plenty enough reason to keep it around. Do not forget that Python 2 was released in 2000 and Python 3 was released almost a decade later. The general time scale makes worrying about the next release for many people, but for people who do they start considering other languages because that's important to them.
twblalock 7y ago
What I've been seeing is people using Python 3 for new projects but leaving their older projects on Python 2. As a result of that, Python 2 will continue to be supported internally at a lot of companies, even though it is "officially" end of life. Nobody wants to rewrite the stuff they finished years ago that is now in maintenance mode.
- JohnFen 7y ago
  I considered doing this myself, but decided that I didn't want the hassle of having two versions of Python hanging around. If/when the day comes that using Python 2 isn't realistic, I may go with 3, or I may choose a different language, depending on the project. I'll cross that bridge when I come to it.
gowld 7y ago
Rewriting your code once every 20 years is a ferrari problem.
user5994461 7y ago
You're not gonna have to rewrite it in a few years. Languages only go through the mess of retrofitting unicode once. Besides Java and Python already discussed, another big mess of a transition was from Qt 4 to Qt 5, where all the strings became unicode.

by LIV2 7y ago

xemdetia 7y ago

I don't think it will make people less likely to use Python overall, but for certain categories of projects there are some things that are just done better in other languages. Both Java and Go for example have specific programming language constructs and contracts to ensure that codebases can move from version to version easily and I do not feel like there is a dynamic/untyped language that really provides that same level of stability. The ones that do get close to that are the ones that are extremely small in scope and are not in the same class of batteries included language, and because of their small scope they have a general limit of change. At a certain point this sort of compatibility/forward motion of a codebase through big language revisions is something that has to be designed as part of the language in either being able to break it down into small enough chunks to chew through in pieces (updating a submodule with the updated language without affecting anything else), completely transparent to the code being run through it (this happens for compilers for C for different standards), or to have a version to version automated rewriting mechanism that is so reliable the outcome of the automated tool is not in question (tools like Go's gofmt). Python in my opinion only has partial solutions to all of those answers so it turns into a lot of hand work. So while there are other languages that may do other things better there are still a class of programs that are very effective to write in Python, and that's plenty enough reason to keep it around. Do not forget that Python 2 was released in 2000 and Python 3 was released almost a decade later. The general time scale makes worrying about the next release for many people, but for people who do they start considering other languages because that's important to them.

twblalock 7y ago

What I've been seeing is people using Python 3 for new projects but leaving their older projects on Python 2. As a result of that, Python 2 will continue to be supported internally at a lot of companies, even though it is "officially" end of life. Nobody wants to rewrite the stuff they finished years ago that is now in maintenance mode.

JohnFen 7y ago
I considered doing this myself, but decided that I didn't want the hassle of having two versions of Python hanging around. If/when the day comes that using Python 2 isn't realistic, I may go with 3, or I may choose a different language, depending on the project. I'll cross that bridge when I come to it.

gowld 7y ago

Rewriting your code once every 20 years is a ferrari problem.

user5994461 7y ago

You're not gonna have to rewrite it in a few years. Languages only go through the mess of retrofitting unicode once. Besides Java and Python already discussed, another big mess of a transition was from Qt 4 to Qt 5, where all the strings became unicode.