Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why I'm Making Python 2.8

naftaliharris.com

Post reply on HN
Print view View original

61–70 of 392 posts

Re: Why I'm Making Python 2.8

#61

Post by supergreg »

gigatexal wrote: post #12

Python programmers and companies with python code should spend the time and effort to move to python 3 instead of spending that time and effort to backport stuff to python 2 because python 2 is deprecated and the future is python 3. Python 3 I think people and businesses with python 2 code would be better off moving their code bases to python 3 instead of doing things like this.

What about not spending time and money and just keep using python 2 for software that already uses it. And only use python 3 for new code bases.

Re: Why I'm Making Python 2.8

#62

Post by wfunction »

js8 wrote: post #37
wfunction wrote: post #31

Earlier quoted context omitted.

What makes something obsolete in your eyes then? Just because some people want A to replace B, that makes B obsolete? For reference, Oxford dictionaries define (..."define"? are multiple dictionaries involved here?) "obsolete" as: 1. no longer produced or used; out of date. Clearly Python 2.7 is in widespread use, and version 2.7.12 came out just a few months ago, so it's neither "no longer produced" nor "no longer u…

Python 2.7 is outdated by Python 3.5. The fact that there is a bugfix release doesn't change that. I mean look at other things. You can still program in C 89 or FORTRAN 77 or COBOL 74 (and no doubt there is somebody still supporting compilers and runtimes for those), but they are all obsolete standards. Addendum: I think for standards like programming language semantics (which in case of Python is directly embodied i…

> Addendum: I think for standards like programming language semantics (which in case of Python is directly embodied in the C implementation), "obsolete" means there is a new standard by some official body (say, the developer of the old standard) that addresses shortcomings of the old standard.

Really? So even if no one ever uses it, it still renders the old one obsolete?!

Re: Why I'm Making Python 2.8

#63

Post by xrisk »

wfunction wrote: post #27
gigatexal wrote: post #12

Python programmers and companies with python code should spend the time and effort to move to python 3 instead of spending that time and effort to backport stuff to python 2 because python 2 is deprecated and the future is python 3. Python 3 I think people and businesses with python 2 code would be better off moving their code bases to python 3 instead of doing things like this.

> Python programmers and companies with python code should spend the time and effort to move to python 3 instead of spending that time and effort to backport stuff to python 2 because python 2 is deprecated and the future is python 3. I hate Python 3's removal of the (lambda (key, value): blah) tuple unpacking syntax, and the forcing of parentheses for print statements. They might seem minor but they aren't for me. S…

So you _hate_ Python 3 because of two changes in syntactic sugar? I would understand if you hated it because of the real breaking changes, but no...

I think you just don't comprehend the multitude of problems that Python 3 fixes by handling strings correctly... Maybe you've never handled Unicode before.

Re: Why I'm Making Python 2.8

#65

Post by ubernostrum »

jzwinck wrote: post #32
gigatexal wrote: post #12

Python programmers and companies with python code should spend the time and effort to move to python 3 instead of spending that time and effort to backport stuff to python 2 because python 2 is deprecated and the future is python 3. Python 3 I think people and businesses with python 2 code would be better off moving their code bases to python 3 instead of doing things like this.

Companies with Python code are probably better off keeping their working, tested code than switching to an incompatible interpreter and set of libraries which among other things will print "b'Hello',b'World'" into their mission critical CSV files. Yes, the built in csv module really does that in Python 3.

Yes, the built in csv module really does that in Python 3.

If you pass it bytes, yes, it does. If you pass it strings, no, it doesn't.

If what you pass to the built-in CSV writer is not a string, the CSV writer will call str() to get a string representation it can write out. The string representation of a bytes object includes the 'b' prefix.

Meanwhile, you discovered your bug: you were treating bytes as text, which is likely to blow up on you sooner or later, and thanks to how Python now handles text, it blew up on you immediately as a way to remind you not to treat bytes as text.

What you probably think you want is for the CSV writer to realize it got a bytes object and, instead of calling str(), call its decode() method to get text it can write. But that is once again a dangerous operation, and sort of the whole point of Python 3's text changes is it won't let you get away with that stuff anymore.

Re: Why I'm Making Python 2.8

#66

Post by singularity2001 »

jzwinck wrote: post #32
gigatexal wrote: post #12

Python programmers and companies with python code should spend the time and effort to move to python 3 instead of spending that time and effort to backport stuff to python 2 because python 2 is deprecated and the future is python 3. Python 3 I think people and businesses with python 2 code would be better off moving their code bases to python 3 instead of doing things like this.

Companies with Python code are probably better off keeping their working, tested code than switching to an incompatible interpreter and set of libraries which among other things will print "b'Hello',b'World'" into their mission critical CSV files. Yes, the built in csv module really does that in Python 3.

"b'Hello',b'World'" this (and 1001 similar)

Re: Why I'm Making Python 2.8

#67

Post by angusp »

nzjrs wrote: post #21

I can't fault a single thing in his justification. This should have been the approach to modernising python all along.

as mentioned in a comment above, the choice to take 2.7 behaviour when 3 behaves differently means this wannabe-python '2.8' is neither backward nor forward compatible

Re: Why I'm Making Python 2.8

#68

Post by silent1mezzo »

What another load of crap. Call it something else but this isn't Python. I'd never use this because it's not official. Who knows if or how long it'd be supported for or if any backdoors would/could be introduced.

I've scheduled time this year for my teams project to update to Python 3. It's expensive in the short term but in the long term we get continued support and new features which is a huge win.

Re: Why I'm Making Python 2.8

#69

Post by wfunction »

xrisk wrote: post #63
wfunction wrote: post #27

Earlier quoted context omitted.

> Python programmers and companies with python code should spend the time and effort to move to python 3 instead of spending that time and effort to backport stuff to python 2 because python 2 is deprecated and the future is python 3. I hate Python 3's removal of the (lambda (key, value): blah) tuple unpacking syntax, and the forcing of parentheses for print statements. They might seem minor but they aren't for me. S…

So you _hate_ Python 3 because of two changes in syntactic sugar? I would understand if you hated it because of the real breaking changes, but no... I think you just don't comprehend the multitude of problems that Python 3 fixes by handling strings correctly... Maybe you've never handled Unicode before.

> So you _hate_ Python 3 because of two changes in syntactic sugar?

First of all, the tuple unpacking one is a HUGE readability AND maintainability issue; it's not just syntactic sugar. var[0][1][2] is not only far less readable than the unpacking notation, it doesn't even have the same semantics (doesn't enforce the structure of the tuple).

That means Python 2.7 helped me catch more bugs. Think about that!

Second, no, I just listed the two that irritated me the most every time I tried to switch, because they were the first things that came up by far the earliest and most frequently. Small inconveniences can be amplified through their frequencies. There are lots of things I don't like about it though... division becoming floating point division, having to say list(foo.items()) or list(map(...)) instead of just foo.items(), etc... again, more verbosity and typing for common cases where I really didn't mind the old way. If I wanted imap(), I could've just used imap; they could've just moved that to __builtin__ and made my life easier that way.

By the way -- the lazy nature of map(), etc. also means you catch fewer bugs now. Again, think about that! Just because it looks more efficient, that doesn't mean it's actually better. If there's anything I've learned, it's that even the smallest things tend to come with non-obvious tradeoffs.

Finally, regarding strings: if you look at my earlier comments, yes, I already acknowledged the Unicode changes were for the better. Awesome. I agree. Cool? OK, but there are other things in the language besides Unicode though, and they're not as awesome. I don't spend my entire programming life dealing with Unicode strings, so I care about other things too, and they make my life harder. Simple as that.

Re: Why I'm Making Python 2.8

#70

Post by ubernostrum »

sirclueless wrote: post #44
masklinn wrote: post #24

Earlier quoted context omitted.

> This should have been the approach to modernising python all along. The core driver for the Python 3 break was the fix in text model, this is what allowed literally everything else as it completely broke existing code. And I, for one, think it's one of the most important improvements of Python 3, the text model of Python 2 is a giant mess and makes it very hard to correctly deal with non-ascii text for any non-triv…

> the text model of Python 2 is a giant mess and makes it very hard to correctly deal with non-ascii text for any non-trivial software There are counter-arguments to this. Armin Ronacher, author of (among other software) the excellent Flask web framework, thinks that Python 2's system of codecs and byte streams is better in practice [1][2]. Reasons include: You can do byte -> byte conversions with codecs that are no…

You should be aware Armin now has a more-or-less followup post telling people not to do what you just did (i.e., reference his 2011 post as an authoritative "Python 3 is bad" explanation, because both Python 3 and his own opinions have evolved since he wrote that post).
Post reply on HN