6 ms·

> but seriously, just do the jump to python3. Or jump to another language. Here's my problem: I don't program unless I get paid, and I simply cannot sell this

by geocar 10y ago

> but seriously, just do the jump to python3. Or jump to another language. Here's my problem: I don't program unless I get paid, and I simply cannot sell this crazy idea: "hey, you know all that software you paid me to write? how about you pay me again so you can have it in python3?" It seems like if I want my programs to run for more than ten years I shouldn't be using Python.

amatix 10y ago
Sounds like you're pitching a complete rewrite, which absolutely isn't the case. Six works great and is simple to push through for side-by-side compatibility. That combined with `from __future__` for Py2.7 allows most codebases to work with small changes in a side-by-side manner.
oblio 10y ago
IMO that's the wrong approach. The correct one would be: "Hey, you know all the software you want to pay me to write? It will be in Python 3 now".
- geocar 10y ago
  I'm not going to work for free.
  - scrollaway 10y ago
    You are not reading what the person you are replying to is saying.
    - geocar 10y ago
      I said I cannot invoice the customer "convert perfectly good codebase to python3", and I said I'm not working for free. The only other option I can see you might be suggesting is to defraud my customer by converting that codebase to python3 but say I was doing something else. I don't want the reputation of being one of those people.
      - SpaceManiac 10y ago
        I believe the path being suggested is: write new software in Python 3, or at least in a 3-friendly way.
        geocar 10y ago
        That's easy to say, but Python3 isn't good enough: * Python3 is slower than Python2 * Twisted still doesn't work in Python3 * Division changed. And so on. I'm not improving Python3 since I don't get any return on it, so I'll simply use a different language for new projects. However you might want to reconsider: Other people parsed it the same way -- and one person even thought it was a good thing that they got to charge again.
        minitech 10y ago
        If you write new software in Python 3, why does it matter if division changed?
        geocar 10y ago
        First, it presupposes I'm going to write new software in Python 3 rather than justifying why I should write new software in python 3. Second, it matters because I'm thinking about python4 and python5. I've already been through this and got burned moving from python1.5 to python2, and python3 has been very uncomfortable thus far. Thirdly, it matters because I work in a lot of mature (multi-decade) codebases, and figuring out what division is supposed to mean twenty five years into development is disconcerting. Then when I'm simply not convinced python is a good investment anymore, this quippy attitude here is extremely off-putting. Do you really want to know why I don't like python as much as I used to? Or are you trying to justify your decision to further invest?
        minitech 10y ago
        > First, it presupposes I'm going to write new software in Python 3 rather than justifying why I should write new software in python 3. It does, because that’s what you were responding to: > I believe the path being suggested is: write new software in Python 3, or at least in a 3-friendly way. I assumed your list was a list of reasons not to write new software in Python 3, and found division oddly out of place.
- HelloNurse 10y ago
  The other, complementary correct approach is "Hey, you know all the software we paid you to write? We'll pay you to port it to Python 3 because we don't like running two different interpreters". And with tools and decent Unicode handling etc. in the original version, the update will be done inexpensively and on time.
- guitarbill 10y ago
  I consider Python 3 a huge benefit for a similar reason: I can avoid or charge $$$ for people still using 2.6 (e.g. on ancient RHEL). There's always somebody. 2.6 is pretty sucky, not to mention unsupported by the PSF. If you support 2.7, some "clever" manager or client will say that 2.6 support surely isn't so unreasonable. It is. 2.7 is legacy only now IMO.
  - lima 10y ago
    I'm happily using and deploying Python 3.6 on CentOS 6 using pyenv. You don't have to use the system Python unless there's a policy requiring you to do so.
    - guitarbill 10y ago
      I agree, and EPEL works fine on RHEL, too. But it wouldn't be enterprise without some BS rules. Hence why compatibility "issues" are such a blessing for detecting enterprise BS early on.
      - lima 10y ago
        You can get a more recent Python from Software Collections, too: https://www.softwarecollections.org/en/scls/?search=python https://www.softwarecollections.org/en/scls/?search=python Up to Python 3.5 and 3.6 will probably follow shortly after release. This is blessed and QA'd by Red Hat themselves, so it's as good as it gets. "My distro only has Python 2" has to be one of the worst excuses not to use Python 3 :-) Obvious exception are systems tools (did you know that Ansible modules have to compatible with Python 2.4 since that's what CentOS 5 uses?). But those are the absolute minority.
gbog 10y ago
Another language? Do you mean that Ruby, or Go, or Rust, or Javascript are less likely to force you to another jump in the next 20 years? I dislike the new print in py3, but still the python community do take things seriously and are not switch horses every 6 months. I also do Javascript and, well, I'd love the community there to hold on something and actually dig it for more than 6 months.
- Xylakant 10y ago
  Ruby is actually a good comparison: It has the same kind of switchover, ruby 1.8 didn't support unicode while ruby 1.9 and newer does. The changes happened roughly at the same time as the py2/3 switchover, but happened much much faster. No incompatible syntax changes happened, no semi-automatic translation between 1.8 and 1.9. A lot of libraries worked (and still do) flawlessly on 1.8 and 1.9, many - including rails - offered compatibility relatively early since ruby 1.9 offered significant benefits over 1.8. There were websites and tools listing the compatibility of your favorite gems[1]. So yes, it is definitely possible to make such changes more gradual and effective both by providing the technical means and by assembling sufficient community support. [1] https://github.com/seattlerb/rubygems-isit19 https://github.com/seattlerb/rubygems-isit19
- sfink 10y ago
  Javascript in particular? Yes, it's less likely to force a jump. It has to stay compatible with the web as it exists today and has existed for the last 20 years. Idiomatic JS will certainly change, but that doesn't force old code to change. Ruby and Go live on the server side, so do not have nearly as harsh a backwards compatibility constraint. Come to think of it, I wonder if JS's backcompat story is precisely what has resulted in the intense rate of churn in the libraries and frameworks written in it. Maybe if the language forced periodic change, then that would both reduce the frameworks' evolutionary pressure to change, and increase frameworks' evolutionary pressure to paper over JS's changes. As it is now, the architecture seems to be that you have an unchanging language layer so you put all of the change into the next layer up. (Well, that and the client-side delivery and execution means that framework updates are far far easier than with any server-side language/framework.)
IndianAstronaut 10y ago
>It seems like if I want my programs to run for more than ten years I shouldn't be using Python I do hope other language communities have learned from the Python2 Python3 fiasco. Dealing with no new features in a version with millions of lines of code already written, enough syntactical and other issues that require large underlying changes, etc.

by geocar 10y ago

amatix 10y ago

Sounds like you're pitching a complete rewrite, which absolutely isn't the case. Six works great and is simple to push through for side-by-side compatibility. That combined with `from __future__` for Py2.7 allows most codebases to work with small changes in a side-by-side manner.

oblio 10y ago

IMO that's the wrong approach. The correct one would be: "Hey, you know all the software you want to pay me to write? It will be in Python 3 now".

geocar 10y ago
I'm not going to work for free.
- scrollaway 10y ago
  You are not reading what the person you are replying to is saying.
  - geocar 10y ago
    I said I cannot invoice the customer "convert perfectly good codebase to python3", and I said I'm not working for free. The only other option I can see you might be suggesting is to defraud my customer by converting that codebase to python3 but say I was doing something else. I don't want the reputation of being one of those people.
    - SpaceManiac 10y ago
      I believe the path being suggested is: write new software in Python 3, or at least in a 3-friendly way.
      - geocar 10y ago
        That's easy to say, but Python3 isn't good enough: * Python3 is slower than Python2 * Twisted still doesn't work in Python3 * Division changed. And so on. I'm not improving Python3 since I don't get any return on it, so I'll simply use a different language for new projects. However you might want to reconsider: Other people parsed it the same way -- and one person even thought it was a good thing that they got to charge again.
        minitech 10y ago
        If you write new software in Python 3, why does it matter if division changed?
        geocar 10y ago
        First, it presupposes I'm going to write new software in Python 3 rather than justifying why I should write new software in python 3. Second, it matters because I'm thinking about python4 and python5. I've already been through this and got burned moving from python1.5 to python2, and python3 has been very uncomfortable thus far. Thirdly, it matters because I work in a lot of mature (multi-decade) codebases, and figuring out what division is supposed to mean twenty five years into development is disconcerting. Then when I'm simply not convinced python is a good investment anymore, this quippy attitude here is extremely off-putting. Do you really want to know why I don't like python as much as I used to? Or are you trying to justify your decision to further invest?
        minitech 10y ago
        > First, it presupposes I'm going to write new software in Python 3 rather than justifying why I should write new software in python 3. It does, because that’s what you were responding to: > I believe the path being suggested is: write new software in Python 3, or at least in a 3-friendly way. I assumed your list was a list of reasons not to write new software in Python 3, and found division oddly out of place.
HelloNurse 10y ago
The other, complementary correct approach is "Hey, you know all the software we paid you to write? We'll pay you to port it to Python 3 because we don't like running two different interpreters". And with tools and decent Unicode handling etc. in the original version, the update will be done inexpensively and on time.
guitarbill 10y ago
I consider Python 3 a huge benefit for a similar reason: I can avoid or charge $$$ for people still using 2.6 (e.g. on ancient RHEL). There's always somebody. 2.6 is pretty sucky, not to mention unsupported by the PSF. If you support 2.7, some "clever" manager or client will say that 2.6 support surely isn't so unreasonable. It is. 2.7 is legacy only now IMO.
- lima 10y ago
  I'm happily using and deploying Python 3.6 on CentOS 6 using pyenv. You don't have to use the system Python unless there's a policy requiring you to do so.
  - guitarbill 10y ago
    I agree, and EPEL works fine on RHEL, too. But it wouldn't be enterprise without some BS rules. Hence why compatibility "issues" are such a blessing for detecting enterprise BS early on.
    - lima 10y ago
      You can get a more recent Python from Software Collections, too: https://www.softwarecollections.org/en/scls/?search=python https://www.softwarecollections.org/en/scls/?search=python Up to Python 3.5 and 3.6 will probably follow shortly after release. This is blessed and QA'd by Red Hat themselves, so it's as good as it gets. "My distro only has Python 2" has to be one of the worst excuses not to use Python 3 :-) Obvious exception are systems tools (did you know that Ansible modules have to compatible with Python 2.4 since that's what CentOS 5 uses?). But those are the absolute minority.

gbog 10y ago

Another language? Do you mean that Ruby, or Go, or Rust, or Javascript are less likely to force you to another jump in the next 20 years? I dislike the new print in py3, but still the python community do take things seriously and are not switch horses every 6 months. I also do Javascript and, well, I'd love the community there to hold on something and actually dig it for more than 6 months.

Xylakant 10y ago
Ruby is actually a good comparison: It has the same kind of switchover, ruby 1.8 didn't support unicode while ruby 1.9 and newer does. The changes happened roughly at the same time as the py2/3 switchover, but happened much much faster. No incompatible syntax changes happened, no semi-automatic translation between 1.8 and 1.9. A lot of libraries worked (and still do) flawlessly on 1.8 and 1.9, many - including rails - offered compatibility relatively early since ruby 1.9 offered significant benefits over 1.8. There were websites and tools listing the compatibility of your favorite gems[1]. So yes, it is definitely possible to make such changes more gradual and effective both by providing the technical means and by assembling sufficient community support. [1] https://github.com/seattlerb/rubygems-isit19 https://github.com/seattlerb/rubygems-isit19
sfink 10y ago
Javascript in particular? Yes, it's less likely to force a jump. It has to stay compatible with the web as it exists today and has existed for the last 20 years. Idiomatic JS will certainly change, but that doesn't force old code to change. Ruby and Go live on the server side, so do not have nearly as harsh a backwards compatibility constraint. Come to think of it, I wonder if JS's backcompat story is precisely what has resulted in the intense rate of churn in the libraries and frameworks written in it. Maybe if the language forced periodic change, then that would both reduce the frameworks' evolutionary pressure to change, and increase frameworks' evolutionary pressure to paper over JS's changes. As it is now, the architecture seems to be that you have an unchanging language layer so you put all of the change into the next layer up. (Well, that and the client-side delivery and execution means that framework updates are far far easier than with any server-side language/framework.)

IndianAstronaut 10y ago

>It seems like if I want my programs to run for more than ten years I shouldn't be using Python I do hope other language communities have learned from the Python2 Python3 fiasco. Dealing with no new features in a version with millions of lines of code already written, enough syntactical and other issues that require large underlying changes, etc.