3 ms·

Quick: run a shell command, split up the reply by line, run a regex on each line, and save the results to a yaml file— now, does what you wrote work correctly o

Quick: run a shell command, split up the reply by line, run a regex on each line, and save the results to a yaml file— now, does what you wrote work correctly on both Python 2.7 and Python 3.3+? Yeah that's what I thought. It's still hard to get bilingual Python correct today, and it was considerably harder before 3.3.

weberc2 7y ago
No one is arguing that upgrading would be trivial; the argument is that it's necessary work that could have been started 10 years ago. Also, if you run your unit tests on Python 2 and 3, you'll get pretty good pretty fast at writing 2-3 compatible code.
- mikepurvis 7y ago
  The comment I was specifically replying to asserted that "you could easily write Python 3 compatible code", and could have been doing so 10 years ago. This is simply untrue— there are a dozen small stumbling blocks that mean that writing bilingual code has a real cost. And it's not as easy as just having the right CI setup, especially if it's ten years ago and most of your dependencies haven't migrated.
  - weberc2 7y ago
    Ah, I see the confusion. In this case, "easily" is relative. The assertion "you could easily write Python 3 compatible code" was in response to the (implied?) assertion "you can't do anything to migrate unless your dependencies are migrated". Perhaps "simply" would have been a better word choice than "easily". To your point, writing 2-3 compatible code has a real cost, but to the GP's point, it's the obvious solution to the "can't do anything until deps are migrated" problem.
    - logifail 7y ago
      > To your point, writing 2-3 compatible code has a real cost, but to the GP's point, it's the obvious solution to the "can't do anything until deps are migrated" problem Q: Ten years ago how would you have explained to your manager that you needed your team to start writing 2-3 compatible code, which obviously takes considerably more time and effort than sticking with 2 compatible code?
      - joshuamorton 7y ago
        It doesn't take considerably more time. At this point, all the code I write is 2/3 compatible, and the things that annoy me are all py3 only features. Backwards compatibility stuff is pretty easy. Most of the easy problems are easy, and six has solved all the hard ones for like 7 years. And I've been writing some of my code 2/3 compatible since 3.4.
  - deleted 7y ago
    [deleted]
radus 7y ago
Okay, I did it. import subprocess import re import yaml output = subprocess.check_output(['ls', '-l'], universal_newlines=True) matching_lines = [] for line in output.splitlines(): if re.search(r'total', line): matching_lines.append(line) with open('matching_lines.yaml', 'w') as f: f.write(yaml.dump(matching_lines)) Python 3.7: https://repl.it/repls/PotableDamagedAutocad https://repl.it/repls/PotableDamagedAutocad Python 2.7: https://repl.it/repls/OrchidDirtyNotification https://repl.it/repls/OrchidDirtyNotification
- mikepurvis 7y ago
  Nice. Yeah my life got a lot easier when I learned about `universal_newlines` changing the subprocess return type under Python 3. The much worse case of this that I dealt with a few years ago was reading in and modifying XML files, and then saving the modified XML contents as strings in a yaml file (a keyed cache). The input XML files (which I didn't control) were not consistent about having the encoding marked, and that really made things a mess for ElementTree. A taste: https://github.com/ros-infrastructure/rosdistro/search?q=utf-8&unscoped_q=utf-8 https://github.com/ros-infrastructure/rosdistro/search?q=utf...
- deleted 7y ago
  [deleted]
- slavik81 7y ago
  This program would crash with a UnicodeEncodeError upon encountering any file with a non-latin character in its name on Windows with Python 3.5 or earlier. I know that's not the version of Python you were targeting, and I know you didn't write this program to be cross-platform, but I wrote a similar program and I was repeatedly surprised by those sorts of problems. I don't entirely agree with mikepurvis, but I do feel his pain.

weberc2 7y ago

No one is arguing that upgrading would be trivial; the argument is that it's necessary work that could have been started 10 years ago. Also, if you run your unit tests on Python 2 and 3, you'll get pretty good pretty fast at writing 2-3 compatible code.

mikepurvis 7y ago
The comment I was specifically replying to asserted that "you could easily write Python 3 compatible code", and could have been doing so 10 years ago. This is simply untrue— there are a dozen small stumbling blocks that mean that writing bilingual code has a real cost. And it's not as easy as just having the right CI setup, especially if it's ten years ago and most of your dependencies haven't migrated.
- weberc2 7y ago
  Ah, I see the confusion. In this case, "easily" is relative. The assertion "you could easily write Python 3 compatible code" was in response to the (implied?) assertion "you can't do anything to migrate unless your dependencies are migrated". Perhaps "simply" would have been a better word choice than "easily". To your point, writing 2-3 compatible code has a real cost, but to the GP's point, it's the obvious solution to the "can't do anything until deps are migrated" problem.
  - logifail 7y ago
    > To your point, writing 2-3 compatible code has a real cost, but to the GP's point, it's the obvious solution to the "can't do anything until deps are migrated" problem Q: Ten years ago how would you have explained to your manager that you needed your team to start writing 2-3 compatible code, which obviously takes considerably more time and effort than sticking with 2 compatible code?
    - joshuamorton 7y ago
      It doesn't take considerably more time. At this point, all the code I write is 2/3 compatible, and the things that annoy me are all py3 only features. Backwards compatibility stuff is pretty easy. Most of the easy problems are easy, and six has solved all the hard ones for like 7 years. And I've been writing some of my code 2/3 compatible since 3.4.
- deleted 7y ago
  [deleted]

radus 7y ago

Okay, I did it. import subprocess import re import yaml output = subprocess.check_output(['ls', '-l'], universal_newlines=True) matching_lines = [] for line in output.splitlines(): if re.search(r'total', line): matching_lines.append(line) with open('matching_lines.yaml', 'w') as f: f.write(yaml.dump(matching_lines)) Python 3.7: https://repl.it/repls/PotableDamagedAutocad https://repl.it/repls/PotableDamagedAutocad Python 2.7: https://repl.it/repls/OrchidDirtyNotification https://repl.it/repls/OrchidDirtyNotification

mikepurvis 7y ago
Nice. Yeah my life got a lot easier when I learned about `universal_newlines` changing the subprocess return type under Python 3. The much worse case of this that I dealt with a few years ago was reading in and modifying XML files, and then saving the modified XML contents as strings in a yaml file (a keyed cache). The input XML files (which I didn't control) were not consistent about having the encoding marked, and that really made things a mess for ElementTree. A taste: https://github.com/ros-infrastructure/rosdistro/search?q=utf-8&unscoped_q=utf-8 https://github.com/ros-infrastructure/rosdistro/search?q=utf...
deleted 7y ago
[deleted]
slavik81 7y ago
This program would crash with a UnicodeEncodeError upon encountering any file with a non-latin character in its name on Windows with Python 3.5 or earlier. I know that's not the version of Python you were targeting, and I know you didn't write this program to be cross-platform, but I wrote a similar program and I was repeatedly surprised by those sorts of problems. I don't entirely agree with mikepurvis, but I do feel his pain.