Why I'm Making Python 2.8 • Hacker News Board

Re: Why I'm Making Python 2.8

#321

Post by js8 » Sat, Dec 10, 2016, 9:50 PM UTC

dagss wrote: post #292

toyg wrote: 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…

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

It has already been explained elsewhere in this discussion by other people, I would strongly advise against that. If you for whatever reason have to stay on 2.7, then make sure your new code is 2.7 only (and best if it works with 3 without changes if you decide to change your mind later).

Consider what's more likely in the far future (after PSF will give up on 2.7 support in 2020). That somebody will support 2.7 as it is, or that this guy will support his Python 2.8 hybrid?

Also consider what happens (in the far future) when some library you use will drop Python 2 support. It's not likely it will be easy to run on this Python 2.8 hybrid, either.

And if you for any reason must use Python 3 features in your code base, just bite the bullet and port it.

Re: Why I'm Making Python 2.8

#322

Post by isotropy » Sat, Dec 10, 2016, 9:56 PM UTC

jl6 wrote: post #306

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…

Name suggestion: Pythoff.

Pythed-off.

Re: Why I'm Making Python 2.8

#323

Post by naftaliharris » Sat, Dec 10, 2016, 10:08 PM UTC

Author here. Imagine my surprise when I got back from a day of sightseeing (I'm on vacation in Spain) and saw that this had blown up. I had intended to "release" this project after New Years, after I'd gotten back and a week or two after 3.6 is released [1], and didn't expect this to get picked up since the project has been on Github for over a year (although inactive for much of that time) and since my blog usually doesn't get much traffic.

A lot of people here have strong opinions about the name "Python 2.8". I don't mind changing it, and intend to do so, (https://github.com/naftaliharris/python2.8/issues/47). I picked it initially since when talking with friends about this project it conveyed pretty darn immediately what the project is and does. I'd be very keen to hear people's suggestions for alternate names!

For those of you with 2.7 codebases or projects, I'd be extremely interested in hearing about whether you were able to get this interpreter to run your code. Personally, the biggest challenges I've had so far are with dependencies that check for `sys.version_info[:2] == (2, 7)` as opposed to something like `sys.version_info[0] [1] A minor and somewhat pedantic point: The interpreter I've been working on includes PEP 515 (underscores in numeric literals), which is new in 3.6. I didn't think it was right for me to "take credit" for this new feature before it was even out in Python 3.6. Obviously, the real credit for this feature existing (in 3.6 or in any interpreter) goes to the CPython core devs, and especially Georg Brandl.

Re: Why I'm Making Python 2.8

#324

Post by kstrauser » Sat, Dec 10, 2016, 10:14 PM UTC

nercht12 wrote: post #318

jimnotgym wrote: post #213

Earlier quoted context omitted.

Except it kinda is the current version to lots of us. I moved to Python as a hobbyist from .net languages and loved the freedom of not having an IDE and working with Linux. The first decent book I read was on Python 3 so I learned Python 3. Lots of us 'newcomers' (not so new in my case) learnt on Python 3, find perfectly good library support in Python 3. In fact the 'old guard', sound a bit like my Dad talking about…

The fact that there's a huge split in the community over the issue shows just how divisive Python 3 is. That said, 3 > 2 in version number doesn't make it better or more "current" (and I've seen a number of projects where the "latest" version wasn't even the latest - it was often an experimental). Yes, you could do just about everything you need to in Python 3 that you can do in Python 2, except that it can be much m…

> I found it's easy enough to add the line:

For the record, that's not what anyone's talking about when they mention Python 3's unicode support.

Re: Why I'm Making Python 2.8

#325

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

int_19h wrote: post #296

wfunction wrote: post #69

Earlier quoted context omitted.

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

Notice in said languages they added lazy APIs. They did not remove eager APIs. Python already had imap, ifilter, izip, etc... I already said this and I'll repeat: I would've been just fine if they made those easier to use (e.g. no import). There was no need to change the behavior of existing APIs.

Re: Why I'm Making Python 2.8

#326

Post by slmyers » Sat, Dec 10, 2016, 10:24 PM UTC

Is the xkcd Appropriate Standards strip appropriate here?

Re: Why I'm Making Python 2.8

#327

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

wfunction wrote: post #264

rndgermandude wrote: post #103

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…

Yes, Really Now! Your disdain for the answers people are giving you, and your abrasive demeanor tell me I can spend my time better than to discuss this further with you.

Re: Why I'm Making Python 2.8

#328

Post by naftaliharris » Sat, Dec 10, 2016, 10:28 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…

> It's also especially irresponsible and hubristic to attempt to make a language that is seemingly compatible with both Python 2 and 3, because 1) I trust that if it was possible Guido and the other developers would have made it

It is possible actually, that's kind of the point! The interpreter I've been working on passes the 2.7 unit tests (i.e. those in Lib/test/), and as well as unit tests for the new features that have been backported from Python 3.

Even if you don't believe me, it's interesting to note that, e.g., while Python 3.0 was being developed, function annotations and keyword-only arguments coexisted with tuple unpacking. I built the code and ran it myself, in fact: https://twitter.com/naftaliharris/status/784421498291310592. Tuple unpacking was actually removed later, introducing the backwards incompatibility after the new functionality had been added. Timeline:

Oct 2006, keyword-only arguments.

Dec 2006, function annotations.

Mar 2007, removing tuple unpacking.

There was also a promising backport of keyword only arguments to CPython 2.6 (!) that was never merged, (http://bugs.python.org/issue1745), due to lack of follow-through.

Re: Why I'm Making Python 2.8

#329

Post by js8 » Sat, Dec 10, 2016, 10:33 PM UTC

wfunction wrote: post #259

js8 wrote: post #104

Earlier quoted context omitted.

Why would you want to downvote somebody trying to help you? In any case, I think I see your problem. You are not the sole user of Python language. There are features that other people like (such as using '*' in unpacking), and so features you like are weighted against their use cases, and a reasonable compromise is made. And frankly, I think if you like to use lambdas that much, you really want to program in a langua…

> In any case, I think I see your problem. You are not the sole user of Python language. I'm glad I'm not. Otherwise I probably wouldn't be using it either. Not sure how that is my "problem". > There are features that other people like (such as using [asterisk] in unpacking), and so features you like are weighted against their use cases, and a reasonable compromise is made. I like that [asterisk] syntax too. > And fr…

> Not sure how that is my "problem".

It's your problem in e.g. where you want list returned by default where Python 3 returns an iterator by default. Why is that useful for many people was already explained.

> I like that [asterisk] syntax too.

Funny, AFAIK it is Python 3 only.. https://www.python.org/dev/peps/pep-3132/

> Or I could just keep using Python 2.7 which works just fine, and not move to version 3 where I'm not welcome.

You are welcome to use Python 3, but - suit yourself. :-)

Re: Why I'm Making Python 2.8

#330

Post by Manishearth » Sat, Dec 10, 2016, 10:34 PM UTC

hsivonen wrote: post #317

Manishearth wrote: post #38

Earlier quoted context omitted.

This approach could not have worked for modernizing python. The whole point of the Python 3 thing was to be able to remove warts in the language that could not have been fixed without breaking backwards compatibility. One core part of this is unicode support -- Python had a horrible story for international text before this. The fact that there are some parts of "modern" Python which could have been implemented in Pyt…

It's super-sad that "Unicode" is a prominent stated motivation for Python 3. Unicode in Python 2 was fundamentally broken in that whether it had UTF-16 semantics or UTF-32 semantic depended on how the interpreter was compiled. That's a terrible, terrible idea. However, they could have fixed it by sticking to one option: UTF-16 (which provided compatibility with some interesting things that Python interoperated with l…

To be clear, I don't agree with py3s Unicode model. I think it sucks for the same reasons you do.

I also think that default Unicode is a major improvement over py2 and is enough to justify breaking the language because modern languages should at least have that.