3 ms·

I seriously hope you're trolling. Yes, the transition is harsh, but it's getting better. On your points 1) that's a problem with Archlinux then, not Python. It

by bru 13y ago

I seriously hope you're trolling. Yes, the transition is harsh, but it's getting better. On your points 1) that's a problem with Archlinux then, not Python. It was dumb to set 3 as default that sound 2) `3to2` works pretty nice for porting code 3) So you have to put parenthesis because it's now a real function. That's so bad. Also you can do stuff like `map(print, myiterable)` which you could not before, what a pain!

d0m 13y ago
"Yes, the transition is harsh, but it's getting better". Exactly. It's getting better, but it was a hell of an annoying time to be between both. Thus why I've come to hate python. I gave three simple examples of things that annoyed me. You can't just dismiss them like they're not worth anything. The process is supposed to be simple. I.e. pip install <library>. If you have to clone it, 2to3 it, fix remaining bugs, it's a hell of a pain in the ass.. and just a plain waste of productivity and time. It would have definitely been possible to have python3 backward compatible or slightly incompatible. What happened however is more of a "Let's screw up all existing code to fix a couple things". To take on your example, yes, using print as a function is cool. But how in hell can't you make it possible to use map(print, ..) in python2.x? It's just about being anal about consistency that print should be a function and not a statement, thus screwing all existing code. My point is not about if python3 is useful or not.. but more about the way it happened. If you want to make something fully incompatible, fine, but don't do it by screwing everyone who's been using your framework/language/library. It's like someone deciding that red lights on the road should now be green, and green lights be blue. Let's just change it. Who cares how many accidents will happen? You might think I'm trolling but I'm not. It's just frustration of literally wasting hours and hours of fixing stuff that was already working (!!!!!!!!!!!!) but isn't anymore. Now, take this time, and multiply it for every production servers that I have running slightly different builds or OS. How in hell something that's been working for 2 years isn't anymore because I updated my os to the latest version? Oh yeah, right, there's a new python version that screwed up every existing scripts. Let's make that the default executable.
- pekk 13y ago
  You are running production servers on Arch Linux, and then pulling updates which change the default Python to 3 without review? Sounds like you were asking for it.
  - d0m 13y ago
    Yeah, I won't ever, ever, run production servers on ArchLinux. (Even though I still use arch for my own machine). Doing that is asking for unnecessary pain. I was used with slackware, gentoo, debian and ubuntu to make frequent update to make sure I had the latest security fixes. On archlinux, it's a different story. "Updating" means "Take a gamble to update the system hoping important packages haven't been changed, renamed or deleted.". Ok, it's not really a gamble because you're supposed to read the archlinux news to know if your next update will fuck up everything. I learned it the hard way... Once, I had to update a server to get a more recent version of a package.. which ended up deleting all rc.d in favor of using systemd. No warning, no nothing. The only answer I could get is "Why are you updating without reading the archlinux news". Fun couple all nighters time.
    - icebraining 13y ago
      Both problems would be caught if you had some kind of testing server (even a VM) and had updated it first. Frankly, you're wrongly blaming the tool.
      - d0m 13y ago
        All problems (or almost all of them) can be caught by using better testing.. That doesn't mean that some tools aren't better than others. On my production servers, I don't care about not being on the very edge of all technology. I'd prefer something highly secure and stable where all the code can run safely. I also want a very strong community with outstanding documentation. So, all in all, for my use cases, I think going with Ubuntu is a smarter choice. It doesn't mean that I don't use archlinux every day on my own machines where I can have fun screwing it up and hacking it back. And, just for the notice, that were only small examples, but I'm talking more generally about backward compatibility and expected behavior. A very good example is jquery.. I'm not worried about getting the last update. It's not like ".click" would stop working. Contrast that to others less mature technology (such as express for node.js) where it can be pretty scary to update packages. You better have a gigantic test suites to upgrade without fear of breaking something.

by bru 13y ago

d0m 13y ago

"Yes, the transition is harsh, but it's getting better". Exactly. It's getting better, but it was a hell of an annoying time to be between both. Thus why I've come to hate python. I gave three simple examples of things that annoyed me. You can't just dismiss them like they're not worth anything. The process is supposed to be simple. I.e. pip install <library>. If you have to clone it, 2to3 it, fix remaining bugs, it's a hell of a pain in the ass.. and just a plain waste of productivity and time. It would have definitely been possible to have python3 backward compatible or slightly incompatible. What happened however is more of a "Let's screw up all existing code to fix a couple things". To take on your example, yes, using print as a function is cool. But how in hell can't you make it possible to use map(print, ..) in python2.x? It's just about being anal about consistency that print should be a function and not a statement, thus screwing all existing code. My point is not about if python3 is useful or not.. but more about the way it happened. If you want to make something fully incompatible, fine, but don't do it by screwing everyone who's been using your framework/language/library. It's like someone deciding that red lights on the road should now be green, and green lights be blue. Let's just change it. Who cares how many accidents will happen? You might think I'm trolling but I'm not. It's just frustration of literally wasting hours and hours of fixing stuff that was already working (!!!!!!!!!!!!) but isn't anymore. Now, take this time, and multiply it for every production servers that I have running slightly different builds or OS. How in hell something that's been working for 2 years isn't anymore because I updated my os to the latest version? Oh yeah, right, there's a new python version that screwed up every existing scripts. Let's make that the default executable.

pekk 13y ago
You are running production servers on Arch Linux, and then pulling updates which change the default Python to 3 without review? Sounds like you were asking for it.
- d0m 13y ago
  Yeah, I won't ever, ever, run production servers on ArchLinux. (Even though I still use arch for my own machine). Doing that is asking for unnecessary pain. I was used with slackware, gentoo, debian and ubuntu to make frequent update to make sure I had the latest security fixes. On archlinux, it's a different story. "Updating" means "Take a gamble to update the system hoping important packages haven't been changed, renamed or deleted.". Ok, it's not really a gamble because you're supposed to read the archlinux news to know if your next update will fuck up everything. I learned it the hard way... Once, I had to update a server to get a more recent version of a package.. which ended up deleting all rc.d in favor of using systemd. No warning, no nothing. The only answer I could get is "Why are you updating without reading the archlinux news". Fun couple all nighters time.
  - icebraining 13y ago
    Both problems would be caught if you had some kind of testing server (even a VM) and had updated it first. Frankly, you're wrongly blaming the tool.
    - d0m 13y ago
      All problems (or almost all of them) can be caught by using better testing.. That doesn't mean that some tools aren't better than others. On my production servers, I don't care about not being on the very edge of all technology. I'd prefer something highly secure and stable where all the code can run safely. I also want a very strong community with outstanding documentation. So, all in all, for my use cases, I think going with Ubuntu is a smarter choice. It doesn't mean that I don't use archlinux every day on my own machines where I can have fun screwing it up and hacking it back. And, just for the notice, that were only small examples, but I'm talking more generally about backward compatibility and expected behavior. A very good example is jquery.. I'm not worried about getting the last update. It's not like ".click" would stop working. Contrast that to others less mature technology (such as express for node.js) where it can be pretty scary to update packages. You better have a gigantic test suites to upgrade without fear of breaking something.