4 ms·

There's just a bit of hyperbole in your comment. Most major libraries have been ported to Python 3. I wonder if the opposite of what you're saying will happen--

by cname 11y ago

There's just a bit of hyperbole in your comment. Most major libraries have been ported to Python 3. I wonder if the opposite of what you're saying will happen--i.e, the libraries that don't support Python 3 will be left behind. Fabric is an example of that for me.

BuckRogers 11y ago
Of course you may be right, but obviously I don't think so at this time. I feel I made a smart, safe bet. I'm still writing valid 2.7 code that could be migrated to 3.x at any point if for any reason my current plan would fall through. It would be just as easy for me to migrate to 3.x as it would anyone else with 2.x codebases. So far, solving CPU performance in Python and removing the GIL is pretty much the holy grail. Python2 would have to completely collapse (no signs of this) for CPython3's ecosystem to outweigh the long-tail of libraries only on 2.x and the truly next-level dynamic language CPU performance. While I am enjoying "performance as a feature" and GIL-free Python at the moment, I can still migrate to Python3 at any time if I lose my safe bet with PyPy4/Py2. To me it looked and still looks like a no brainer.
- cname 11y ago
  > I'm still writing valid 2.7 code that could be migrated to 3.x at any point Well, that's kinda true, although there is somewhat of a learning curve doing 2-to-3 migrations. Depending on your situation, this may or may not matter, but if you need to "move fast" on this at some point, it'd at least be beneficial to know what's involved (even though it's not that onerous IMO).
  - BuckRogers 11y ago
    I've used (tested) Python3 many times over the years and releases. I'd consider the changes trivial. I'm not anti-Python3, I'm pro-PyPy4. In my attempts to test Python3 releases though I've ran across bugs and performance regressions from 2.x. After I continually ran into this in a few releases I eventually threw my hands up. The last release I ran tests on was 3.4 and I'm no longer interested in later releases until something as substantial as PyPy's CPU performance and removal of the GIL (PyPySTM) shows up to beat what I have now. It's slick to have the entire Python2 ecosystem, major performance boost to your code, and still leave the door open for Python3 if they ever stop bloating the language. Other than being dramatically slower than PyPy4, Python3 is also feature soup. I strongly dislike technical churn rather than true technical innovation (which is what PyPy represents). I'm more in line philosophically with Go, I'd prefer to remove features until you're down to a very concise and stable core. Python3 has many negatives, but from my perspective they keep piling on more.
- kevin_thibedeau 11y ago
  Writing valid 2.7 is not enough as you can write yourself into a non-portable corner that is hard to escape from. You need to use all of the __future__ imports and be mindful of constructs that 2to3 will handle wrong. Better yet is to bite the bullet and make your code work with automated tests running 2to3 if all of your library dependencies have py3 support. Then you can continue to write in 2.7 and anything that runs afoul of py3 will be caught early.
  - BuckRogers 11y ago
    Yes, I could do that. But as it is, I'm no worse off than anyone else with Python2 codebases. I used to use the future imports and the things you're suggesting but since my job is Python2.x I stopped. I prefer to just keep my head there all the time. If I were to migrate to CPython3 instead of PyPy4 as I've done, it would be a wholesale move. Employer moves, I move. The underlying incentives aren't there though at the moment for either of us. I'm certainly not going to push my employer into something that isn't in their best-interests (or mine, work for nothing). If anything, they need to move to PyPy for the same reasons I did. Py3 needs a bigger ecosystem than 2.x, needs an answer to PyPy4's CPU performance and removal of the GIL, and convince employers it's better than CPython2 and/or PyPy4. Those are 4 potentially insurmountable tasks. The best thing to do is start removing features rather than adding them, such as this 4th string formatting method in 3.6. It (Python3) is just very unappealing.
    - rufugee 11y ago
      Is there something fundamentally different from Py3 that makes a well-performing functional PyPy version impossible or extremely difficult?
      - BuckRogers 11y ago
        Late reply here, but no. The reason there's no non-beta PyPy3 on a later version than 3.2 is that there's not enough demand for it (or no one willing to donate large enough sums of money for it to make it the primary focus). Industry players who want to remove the Python CPU bottleneck and willing to stick with Python rather than moving on to Go or JS on Node, are donating to the 2.7 based PyPy4.
deleted 11y ago
[deleted]

by cname 11y ago

BuckRogers 11y ago

Of course you may be right, but obviously I don't think so at this time. I feel I made a smart, safe bet. I'm still writing valid 2.7 code that could be migrated to 3.x at any point if for any reason my current plan would fall through. It would be just as easy for me to migrate to 3.x as it would anyone else with 2.x codebases. So far, solving CPU performance in Python and removing the GIL is pretty much the holy grail. Python2 would have to completely collapse (no signs of this) for CPython3's ecosystem to outweigh the long-tail of libraries only on 2.x and the truly next-level dynamic language CPU performance. While I am enjoying "performance as a feature" and GIL-free Python at the moment, I can still migrate to Python3 at any time if I lose my safe bet with PyPy4/Py2. To me it looked and still looks like a no brainer.

cname 11y ago
> I'm still writing valid 2.7 code that could be migrated to 3.x at any point Well, that's kinda true, although there is somewhat of a learning curve doing 2-to-3 migrations. Depending on your situation, this may or may not matter, but if you need to "move fast" on this at some point, it'd at least be beneficial to know what's involved (even though it's not that onerous IMO).
- BuckRogers 11y ago
  I've used (tested) Python3 many times over the years and releases. I'd consider the changes trivial. I'm not anti-Python3, I'm pro-PyPy4. In my attempts to test Python3 releases though I've ran across bugs and performance regressions from 2.x. After I continually ran into this in a few releases I eventually threw my hands up. The last release I ran tests on was 3.4 and I'm no longer interested in later releases until something as substantial as PyPy's CPU performance and removal of the GIL (PyPySTM) shows up to beat what I have now. It's slick to have the entire Python2 ecosystem, major performance boost to your code, and still leave the door open for Python3 if they ever stop bloating the language. Other than being dramatically slower than PyPy4, Python3 is also feature soup. I strongly dislike technical churn rather than true technical innovation (which is what PyPy represents). I'm more in line philosophically with Go, I'd prefer to remove features until you're down to a very concise and stable core. Python3 has many negatives, but from my perspective they keep piling on more.
kevin_thibedeau 11y ago
Writing valid 2.7 is not enough as you can write yourself into a non-portable corner that is hard to escape from. You need to use all of the __future__ imports and be mindful of constructs that 2to3 will handle wrong. Better yet is to bite the bullet and make your code work with automated tests running 2to3 if all of your library dependencies have py3 support. Then you can continue to write in 2.7 and anything that runs afoul of py3 will be caught early.
- BuckRogers 11y ago
  Yes, I could do that. But as it is, I'm no worse off than anyone else with Python2 codebases. I used to use the future imports and the things you're suggesting but since my job is Python2.x I stopped. I prefer to just keep my head there all the time. If I were to migrate to CPython3 instead of PyPy4 as I've done, it would be a wholesale move. Employer moves, I move. The underlying incentives aren't there though at the moment for either of us. I'm certainly not going to push my employer into something that isn't in their best-interests (or mine, work for nothing). If anything, they need to move to PyPy for the same reasons I did. Py3 needs a bigger ecosystem than 2.x, needs an answer to PyPy4's CPU performance and removal of the GIL, and convince employers it's better than CPython2 and/or PyPy4. Those are 4 potentially insurmountable tasks. The best thing to do is start removing features rather than adding them, such as this 4th string formatting method in 3.6. It (Python3) is just very unappealing.
  - rufugee 11y ago
    Is there something fundamentally different from Py3 that makes a well-performing functional PyPy version impossible or extremely difficult?
    - BuckRogers 11y ago
      Late reply here, but no. The reason there's no non-beta PyPy3 on a later version than 3.2 is that there's not enough demand for it (or no one willing to donate large enough sums of money for it to make it the primary focus). Industry players who want to remove the Python CPU bottleneck and willing to stick with Python rather than moving on to Go or JS on Node, are donating to the 2.7 based PyPy4.

deleted 11y ago

[deleted]