Because 3 is incompatible with 2 I evaluate the cost/benefit of using it compared against all other languages, not just 2.
From that POV, I find that e.g. Julia, Haskell, or Prolog are much more compelling than Python 3. Python 3 doesn't add anything radically better than 2.
(Most of the new language "features" to me seem like they should be libraries instead: fstrings, enums, dataclasses; I can't understand why people think asyncio is cool but ignore Twisted (which is a huge treasure chest of amazing capabilities!))
Since I see 3 as only marginally better than 2, the main difference between them is that 2 is stable and mature while 3 is in flux, and that consideration mashes the cost/benefit ratio waaaay over in favor of 2, IMO.
Porting a python 2 project to Julia/Haskell/Prolog is rewriting the entire codebase. Porting py2 to py3 is a little more than a few men-month of work. In my company we have >2 million line of py2 code and we spent a few weeks converting all to py3 (biggest problems being str/unicode and None comparison) and less than a month later our prod runs py3.
I don't want to come off condescending, I really want to understand your point. But I have no idea what you're trying to say.
Sure, technically py2 and py3 are different languages. So what?
> I don't want to come off condescending, I really want to understand your point.
Same here! Well met.
> But I have no idea what you're trying to say.
Sorry, I'll try again.
> Porting a python 2 project to Julia/Haskell/Prolog is rewriting the entire codebase.
Sorry, I was thinking of new projects there.
To understand my point keep in mind that I'm assuming a world where Python 2 stays stable and maintained (if only because I'm maintaining it) so the option of not converting to Python 3 is on the table. In that world, I don't see a compelling reason to adopt Python 3 when Python 2 still exists and is stable. (And FWIW I think some of the py3 folks realize this and that's why they are so eager to "cannibalize" the old for the new, precisely because py3 can't really compete on its own merit against its entrenched incumbent ancestor, eh?)
> In my company we have >2 million line of py2 code and we spent a few weeks converting all to py3 (biggest problems being str/unicode and None comparison) and less than a month later our prod runs py3.
You paid a modest but non-zero cost to convert and then what did you get? Was it faster? You didn't convert 2M loc py2 to, say, 1.8M loc py3?
If Python 2 wasn't going away (my premise) would you have converted to Python 3? If so, why?
PyPy is delivering speed improvements, and to me it seems like most if not all of the other language features of py3 can be done in py2 with libraries. Other than compatibility with py3, what was the payoff?
> Sure, technically py2 and py3 are different languages. So what?
Two things: first, the whole reason this mess is happening is IMO because py3 interpreter can't run py2 code. If it could I think the transition would have gone smoothly and been done by now. It wasn't necessarily a bad thing to correct some warts, but it was a deliberate choice to "kill" Python 2 despite the obvious fact that we're going to be stuck with it for years to come (COBOL! FORTRAN! Like Elder Gods, these things don't die.) Really, i don't mind py3! It's the effort to throw py2 onto the funeral pyre while it's still kicking ("I feel happy! I feel happy!") that I find objectionable.
Second, and IMO this is the big deal: py2 is stable while py3 is in flux.
If the language stops changing that means people can work on the tooling and implementation instead. If I was managing a codebase the size of yours I would be much more interested in PySonar (or Cython or Nuitka) than anything that py3 brings to the table. Changes in the language require changes in the tooling (even just your syntax highlighters) so IMO they should be really good to pay for the expense of learning them and supporting them. For example, algebraic data-structures with pattern matching would be a nice addition to Python. (But then, you can do that in a library too!)
In sum, the very fact that py2 is now stable and unchanging is a killer feature (IMO) that differentiates it from py3!
Yeah I see your point. To me it's all about trade-offs. A year from now Py3 will have a larger community than whatever replaces Py2. So, investing time to port my code to Py3 was worth it.
> In sum, the very fact that py2 is now stable and unchanging is a killer feature (IMO) that differentiates it from py3!
This is a good point, but I disagree. As long as they make future py3 versions backwards compatible, it doesn't affect me if they keep changing py3. To me, it's more important that the world will be operating on py3 as opposed to py2; this is the killer feature of py3.
> A year from now Py3 will have a larger community than whatever replaces Py2.
> the world will be operating on py3 as opposed to py2
You're right, but like I said, for new stuff I'm using Haskell or Prolog or something, not Python {2,3}.
I don't want to advance Python 2 --well, by adding and improving libraries and tooling I do, but not because I plan to make new stuff in py2, rather to make maintenance cheaper-- I just want to prevent it from dying. I'm really only interested in maintenance. Otherwise I would just contribute to Tauthon, but they're modifying the interpreter/language whereas I just want to make the existing thing more solid.
Because 3 is incompatible with 2 I evaluate the cost/benefit of using it compared against all other languages, not just 2.
From that POV, I find that e.g. Julia, Haskell, or Prolog are much more compelling than Python 3. Python 3 doesn't add anything radically better than 2.
(Most of the new language "features" to me seem like they should be libraries instead: fstrings, enums, dataclasses; I can't understand why people think asyncio is cool but ignore Twisted (which is a huge treasure chest of amazing capabilities!))
Since I see 3 as only marginally better than 2, the main difference between them is that 2 is stable and mature while 3 is in flux, and that consideration mashes the cost/benefit ratio waaaay over in favor of 2, IMO.