Live data from Hacker News

How to support both Python 2 and 3

ondrejcertik.blogspot.com

11–20 of 23 posts

Re: How to support both Python 2 and 3

#11
post #10
post #9

Earlier quoted context omitted.

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!

"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 . If you have to clone it, 2to3 it, fix remaining bugs, it's a hell…

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.

Re: How to support both Python 2 and 3

#12
post #11
post #10

Earlier quoted context omitted.

"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 . If you have to clone it, 2to3 it, fix remaining bugs, it's a hell…

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.

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.

Re: How to support both Python 2 and 3

#13
post #12
post #11

Earlier quoted context omitted.

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.

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,…

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.

Re: How to support both Python 2 and 3

#15
post #10
post #9

Earlier quoted context omitted.

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!

"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 . If you have to clone it, 2to3 it, fix remaining bugs, it's a hell…

> But how in hell can't you make it possible to use map(print, ..) in python2.x?

`from __future__ import print_function` lets you do that in >= 2.6.

Re: How to support both Python 2 and 3

#16
post #12

Earlier quoted context omitted.

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,…

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.

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.

Re: How to support both Python 2 and 3

#17
I really love Python, it is my language of choice, bread and butter, and I've been using it since 2005. However, this backwards compatibility break is probably the worst thing that happened to the language, as I think it's creating more project stalling and work in total than is worth any improvements specifically stemming from backwards incompatible changes. It could be because python3 still has not become my target, but that's kind of the point. When is it ever going to be?

Re: How to support both Python 2 and 3

#18
What benefits does upgrading from python 2.x to 3 have? Why would you undertake that task? I don't understand why, unless python 3 offers some extremely compelling feature, or you are one of the small percentage of developers who delivers importable python libraries as your main developmental output.

Re: How to support both Python 2 and 3

#19
post #5

this article takes awhile to get to the point, but the point is correct which is: > In other words, this is how it should be, that you write your code once, and you can use any supported language version to run it/compile it, or develop in. But for some reason, this obvious solution has been discouraged by Guido and other Python documents, as seen above. I just looked up the latest official Python docs, and that one…

> I'll start with the conclusion: making backwards incompatible version of a language is a terrible idea, and it was bad a mistake.

> So let me fix that: I do recommend a single code base as the solution.

> The original advice to think very separately about your 2.x and 3.x codebases was very wrong, has wasted a ton of time (since you end up porting to python 3 twice), and overall slowed down the adoption of py3k, a slowdown that fortunately is finally lifting.

Is this opinion common? Do Guido and the other core developers admit they were wrong?

> Python 3.0 will break backwards compatibility. Totally. We're not even aiming for a specific common subset.

That a single code base is now possible, albeit "not entirely idiomatic", does support the conclusion that the original aim to break compatibility was misguided at best, and raises questions about the governance of Python overall.

Re: How to support both Python 2 and 3

#20
post #19
post #5

this article takes awhile to get to the point, but the point is correct which is: > In other words, this is how it should be, that you write your code once, and you can use any supported language version to run it/compile it, or develop in. But for some reason, this obvious solution has been discouraged by Guido and other Python documents, as seen above. I just looked up the latest official Python docs, and that one…

> I'll start with the conclusion: making backwards incompatible version of a language is a terrible idea, and it was bad a mistake. > So let me fix that: I do recommend a single code base as the solution. > The original advice to think very separately about your 2.x and 3.x codebases was very wrong, has wasted a ton of time (since you end up porting to python 3 twice), and overall slowed down the adoption of py3k, a…

Well zed seems to agree

https://twitter.com/zedshaw/status/364118939233554432

> they've been keeping this "dual mode" option mostly a secret so as to not have to admit they fucked up

Post reply on HN