Live data from Hacker News

Why I'm Making Python 2.8

naftaliharris.com

291–300 of 392 posts

Re: Why I'm Making Python 2.8

#291
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…

> I don't know what recourse the PSF has but maybe they should even go all in and defend the "Python" name so as to prevent confusion and stop a potential community fracture. Just call it anything else but "Python 2.8" is not Python. This! A thousand times! I love open source and free software. I absolutely love the fact that you can fork the code and adapt it to your needs. If you find others who like it great! But…

contribute, then, instead of complaining:

https://github.com/naftaliharris/python2.8/issues/47

Re: Why I'm Making Python 2.8

#292
post #284
post #268

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…

You can keep your py2.x code running, absolutely; but you cannot expect other people working for free to help you pay your bills. Honestly, the level of self-entitlement through all 2vs3 threads is staggering.

I don't want the CPython core devs to do anything different and are not angry with them at all. It is their pet and they can do what they want. I fully agree with what you say in that sense.

But I do mind people saying in these discussions "you should all move to Py3 now or you are stupid/evil".

No. There are legitimate reasons for staying with Py2.7 and embracing it.

So I hope "Python 2.8" gets a cool name, perhaps even some funding from a company who wants to keep their Py2.7 code alive and invigorated, and the community part as friends.

Is that self-entitlement in any sense?

All I want is for people who I think have a huge blind spot to stop calling me ignorant for decisons I make about MY code. I totally don't expect core CPython devs help me out though.

Re: Why I'm Making Python 2.8

#293

Earlier quoted context omitted.

Oh we are perfectly well aware of our encoding issues. In NumPy, one of the most important libraries in Python 2 or 3, strings always take one byte per character. And it's not going to change. So the built in csv module needs to support a reasonable behavior. Which it does not. If a company tries Python 3 and discovers basic things like CSV produce utter gibberish, they would do well to opt out. And they do--in drove…

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

> It could be argued that the csv module's behaviour is reasonable

I don't see how silently printing a binary literal, if that is indeed what it does, is reasonable. Simply put, b"foo" is not meaningful CSV.

What it should do is 1) raise an exception by default, informing the user that they need to be supplying strings and not bytes, and 2) provide an explicit switch to treat binary data as pass-thru, which would be useful in scenarios where you're just reading a file and dumping it elsewhere, and don't want to spend time decoding and then encoding everything.

Re: Why I'm Making Python 2.8

#294
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.

According to what data?

Re: Why I'm Making Python 2.8

#295
post #162

Earlier quoted context omitted.

I had this problem. It doesn't "blow up". If it blew up and retired, I would have seen the problem. The problem, like several python 2/3 incompatibilities, is that Python 3 merrily did something different, without telling anyone, until eventually we track down what has changed. I spent quite a while on this very bug myself, and it, along with others, persuaded me to switch to a different language (serious I know, but…

It's unreasonable to say "merrily did something different, without telling anyone" when fixing the string implementation was a significant reason for creating backwards-incompatible Python3 in the first place. It's not a bug, it's a fix for an architectural error in Python 2, and it was quite well announced at the time: https://docs.python.org/3.0/whatsnew/3.0.html

Fixing the string mess in Py2 was a good thing.

But the fact that the same code now silently does the always wrong thing in Py3 wrt CSV is clearly a bug.

Actually, the design defect here is calling str() on everything, and assuming that the output is sensible for CSV. It may be a decent rule of thumb, but it clearly does not apply to bytes. Given the likelihood that someone might mistakenly use bytes as a string (for example, because they're porting a legacy Py2 codebase), this should be a hard error, immediately reported as such, and not just a silent behavior change.

Re: Why I'm Making Python 2.8

#296
post #63

Earlier quoted context omitted.

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

Regarding laziness of map() - lazy is a good default, because you can always make eager out of lazy, but not the other way around. Lazy is also more general, because it can handle both lazy and eager inputs, while eager will always force a lazy input.

This has been the general trend in mainstream languages lately, not just in Python. E.g. in C#, all LINQ operations are lazy. in Java, the new stream API, to be used with lambdas, is lazy.

Re: Why I'm Making Python 2.8

#297

Earlier quoted context omitted.

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

> Like what am I supposed to pass to sort(key)? And incidentally, this tuple unpacking problem comes up when sorting frequently...

I suggest you look at namedtuple: https://docs.python.org/3/library/collections.html#collectio...

I think you should watch some Raymond Hettinger's talks, he is discussing many little things like this.

Re: Why I'm Making Python 2.8

#298

People don't seem to be considering the possibility that a stagnant python 2.7 may actually be a reason to like that version of the language. I must admit it is nice to not have those oh-so-keen python developers messing with my favorite language. However, I recently had a gig working in py3. Apart from screwing up every single print statement for a long time, it was entirely drama-free, and actually pretty great. Th…

Oh, people are considering that possibility very much. But the notion of Python 2.8, with new features backported from 3.x, is kinda the opposite of that approach, and is very much "developers messing with my favorite language".

Re: Why I'm Making Python 2.8

#299
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.

As I said, it's my understanding working with Python as well as seeing what others work with in the community and so it could be wrong. Do you have data to back up that people aren't?

Re: Why I'm Making Python 2.8

#300
post #292
post #284

Earlier quoted context omitted.

You can keep your py2.x code running, absolutely; but you cannot expect other people working for free to help you pay your bills. Honestly, the level of self-entitlement through all 2vs3 threads is staggering.

I don't want the CPython core devs to do anything different and are not angry with them at all. It is their pet and they can do what they want. I fully agree with what you say in that sense. But I do mind people saying in these discussions "you should all move to Py3 now or you are stupid/evil". No. There are legitimate reasons for staying with Py2.7 and embracing it. So I hope "Python 2.8" gets a cool name, perhaps…

> I don't want the CPython core devs to do anything different

It's not just CPython, it's the Python specification of which CPython is the reference implementation. The specification couldn't move forward in significant ways without making some of the changes that came with Python 3.

> All I want is for people who I think have a huge blind spot to stop calling me ignorant

The level of vitriol in 2vs3 threads has been way too high from the start, because people always hate change. You are obviously free to do what you want, you always were. Don't mind the haters, but please don't be one either.

Post reply on HN