Why I'm Making Python 2.8 • Hacker News Board

Re: Why I'm Making Python 2.8

#261

Post by Sir_Cmpwn » Sat, Dec 10, 2016, 8:10 PM UTC

ianamartin wrote: post #229

guitarbill wrote: post #171

Earlier quoted context omitted.

> So the built in csv module needs to support a reasonable behavior. Which it does not. It could be argued that the csv module's behaviour is reasonable, and NumPy's isn't. (I'm not 100% sure about all the details of this issue) Hopefully, NumPy will change it's behaviour to match Python 3, but if not you could still use the NumPy CSV routines like `loadtxt` or `genfromtxt` [0]. So then this becomes a documentation c…

I say this as someone who uses the latest version of Python available in every new project or script. Text encoding issues are absolute garbage in Python 3.x I fucking hate the way that csv module works with text encodings. As soon as I can figure out a reliable way to take latin-1 and save it as UTF-8 without breaking everything, I will try to shoehorn in a PR. Right now, it's fucking awful. My ETL pipeline hates it…

    with open('some latin-1 file', 'rb) as f:
      text = f.read().decode('latin-1')
    with open('some utf8 file', 'wb') as f:
      f.write(text.encode('utf-8'))

Python 3's string encoding support is super good. I've said it before and I'll say it again: if you use bytes as a string you are Doing It Wrong.

If you use bytes as a string you are Doing It Wrong.

Re: Why I'm Making Python 2.8

#262

Post by hartator » Sat, Dec 10, 2016, 8:11 PM UTC

Too wrote: post #244

hartator wrote: post #182

Earlier quoted context omitted.

Except Python 3.x is bringing controversial changes and was slower than Python 2.x for several years. If IE7 was slower than IE6, you can't blame people to not move over.

There's no controversial changes in python3? Except if you consider print() controversial but that's so silly it's laughable. There are however non backwards compatible changes , like unicode by default, IE7 was also non backwards compatible so the comparision still holds. (with the exception that IE had a compatibility mode if you sent some magic http headers)

It can be silly, but that was one of the reason I picked Ruby over Python 5 years ago for a project. I felt at the time, Python is awesome, however they are taking a weird path.

Re: Why I'm Making Python 2.8

#263

Post by wfunction » Sat, Dec 10, 2016, 8:11 PM UTC

js8 wrote: post #176

masklinn wrote: post #110

Earlier quoted context omitted.

> Why would you want to downvote somebody trying to help you? Misreading comments is not helping.

That's why I used the word "trying". Maybe you should read more carefully before you want to accuse others from misreading something. ;-) I think it's unfair to say that I misread his comment - he doesn't explicitly mention he is aware of the workaround I outlined for the functions, and that he is bothered with lack of tuple unpacking in lambda expressions only, not in ordinary functions. Regardless, I still think it…

> Regardless, I still think it's quite impolite to downvote somebody who wants to help you and misunderstands you

Well, I don't consider it a "misunderstanding" when there are literally just 2 things to note in my comment that you're replying to ("lambda" and "tuple unpacking") and you still somehow miss 1 of them. I think it totally deserves a downvote, because it makes me look stupid when you present a reasonable solution to a non-problem and make readers assume I was saying something other than I was, and on top of that I have to waste some 5-10 minutes of my time replying. That's not something I appreciate.

That said, like I said, I never actually downvoted that comment (because I obviously couldn't). So you don't need to worry about the internet points.

Re: Why I'm Making Python 2.8

#264

Post by wfunction » Sat, Dec 10, 2016, 8:17 PM UTC

rndgermandude wrote: post #103

wfunction wrote: post #84

Earlier quoted context omitted.

I wish I could downvote. I specifically said I hate the tuple unpacking syntax change in lambdas . That's where I used it so much to begin with, not in defs! I obviously can't put statements like that in lambdas, and until now I didn't need to do that to make my code readable. Now I have to name all of my lambdas just to make this syntax work, which is nonsense. It used to be there and it worked perfectly fine .

Lambdas are not really pythonic these days anyway list(map(lambda (some, thing): some + thing, everything)) # better list(some + thing for (some, thing) in everything) Or, as the parent suggests, just create helper function, preferably one your python environment doesn't need to set up every time your outer function is called # okish, "verbose lambda" def compute(everything): def magic(elem): some, thing = elem retur…

> Lambdas are not really pythonic these days anyway

Too much nonsense in your comment. Really now? How about you give a realistic example where syntactic sugar doesn't substitute for it? Like what am I supposed to pass to sort(key)? And incidentally, this tuple unpacking problem comes up when sorting frequently... and that's the prime example on their web page (and a realistic one at that) for where you're supposed to use lambdas: https://docs.python.org/3/tutorial/controlflow.html#lambda-e... If you're telling me this isn't Pythonic, you're really just not being sensible.

Re: Why I'm Making Python 2.8

#265

Post by upofadown » Sat, Dec 10, 2016, 8:17 PM UTC

lloeki wrote: post #33

> And the majority of Python code written does not run under any of the 3.x interpreters. This makes it harder for its users to be productive. What a load of bollocks. For new projects this only matters if libraries aren't ported, which they are for the most part. For old projects, either you're in a situation where you can spend time porting your code to Python 3, or you don't; but as TFA mentioned pep-404, the writ…

well Python 3 itself was a version hijack so it might be a little late to complain about others doing the same thing.

Re: Why I'm Making Python 2.8

#266

Post by greyman » Sat, Dec 10, 2016, 8:18 PM UTC

yladiz wrote: post #80

As others have said, maybe this project fixes some actual problems and backports some features from 3, but this isn't "Python". Beyond the fact that Python is a trademark of the Python Software Foundation, Python is more than the language, it's the community and the tools (as with every programming language). So while there are some vocal people that really dislike Python 3 (either in part or wholly), my understandin…

> much of the industry is transitioning to Python 3 (either currently doing so or planning to)

Except it isn't.

Re: Why I'm Making Python 2.8

#267

Post by upofadown » Sat, Dec 10, 2016, 8:20 PM UTC

I consider the fact that 2.7 isn't getting new features a good thing. After a point, every new feature takes away something from everything that came before.

Re: Why I'm Making Python 2.8

#268

Post by dagss » Sat, Dec 10, 2016, 8:21 PM UTC

I see many people vigorously defending Py3 but I wonder how many of these have a paying-the-bills kind of job. Where you would look at the cost of porting a large project to Py3 and get an answer like half a million USD (easily). Do you go "of course we do that, that money is easily recouped with the added programmer productivity of Py3"? No chance.

So the question is do you want to basically light that money on fire, or just keep your perfectly fine Py2.7 code running and maintained another few years.

More discussions of the monetary value of programming languages please. What is "correct" or "right" isn't all that interesting to many, for good reasons.

Kudos to this project and hope it can set us on a saner migration path to Py3. (Should totally change the name though.)

Re: Why I'm Making Python 2.8

#269

Post by smallnamespace » Sat, Dec 10, 2016, 8:21 PM UTC

dagss wrote: post #260

smallnamespace wrote: post #114

Earlier quoted context omitted.

> Changing to `unicode_literals` will likely introduce regressions on Python 2 that require an initial investment of time to find and fix. The APIs may be changed in subtle ways that are not immediately obvious. Unless you're willing to put in the time and energy to extensively test, this is basically a recipe for disaster. You're basically paying at least 80% of the cost of a full Py2 -> Py3 port (since looking for…

Being able to change things in one part of the code base at the time -- or one feature/data field at the time, is a HUGE thing. For production systems you just cannot put the backlog on pause for a month or two while porting. You can however incrementally fix over the course of some years.

That's probably true, but unicode_literals isn't the right tool to make an incremental port, because it neither obeys good py2 nor py3 text handling conventions.

It would become a substantial detour and end up being a kit more total work.

Also, porting can be done in parallel to normal dev. You aim your port at a specific release while you continue fixing bugs. When the port is done, you port over all the patches. Repeat until port and original version converge.

Re: Why I'm Making Python 2.8

#270

Post by armitron » Sat, Dec 10, 2016, 8:26 PM UTC

js8 wrote: post #227

coldtea wrote: post #193

Earlier quoted context omitted.

> You think they are doing it just for kicks? Yes. From a false sense of "we know better than you what's good for you". And also from not being connected to actual business and end user needs. > There are no issues with Python 2? That's irrelevant. There are issues with Python 3. Besides, the issues that Python 3 fixed over 2 are marginal at best and most could be retroffited to 2.x (as this 2.8 release proves). Noth…

> And also from not being connected to actual business and end user needs. I am not really personally bothered by Python 3 being incompatible (with that one Jython exception that I already mentioned). But I would like to point out the comment https://news.ycombinator.com/item?id=13146127 , I think you're the one who is wrong here. > It's more likely that Python will suffer from people moving to other languages Unlike…

Go and Julia are already reaping the benefits.

I see no future for Python be that 2 or 3. It's not great at anything, but projects a veneer of friendliness (that one should quickly outgrow) on top of a pile of bad implementation decisions and terrible design.

Its popularity is based on superficial attributes rather than solid foundations. Eventually, the entire ecosystem will collapse and the masses will flood to the next attractor.