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

341–350 of 392 posts

Re: Why I'm Making Python 2.8

#341

Post by int_19h »

wfunction wrote: post #325
int_19h wrote: post #296

Earlier quoted context omitted.

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.

There were generally no map/filter/fold APIs in those languages, eager or lazy.

In cases where the APIs were there, they were generally not as easily accessible (i.e. they were the equivalent of imap etc, with some hoops to jump before you could use them). The new APIs are more straightforward to use.

The reason to change the behavior of an existing API is because the default (i.e. most obvious) API should also be the most flexible, and do the right thing in as many cases as possible. This was not the case with map etc in Py2.

The disadvantage of changing an existing API like that is that it breaks code. But Py3 broke code anyway, so it was a good time to introduce breaks like that for the sake of better defaults.

Re: Why I'm Making Python 2.8

#342

Post by naftaliharris »

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…

> the writing has been officially on the wall ever since 2011 so at that point you have to admit you did choose to incur tech debt and do nothing about it, so the claimed loss of productivity is on you.

When Python 3 was released, it offered Python users a trade: In exchange for a productivity loss (porting your Python 2 code), you'd get a productivity gain (new features in Python 3 and removed cruft). Some projects and companies thought this was a good trade, and have upgraded over the years, and many have not, and haven't. The interpreter I've been working on tries to improve on the terms of that deal for people who have not switched to Python 3.

> What a terrible, terrible situation. Now you'll have "python" code that will neither run on 2.7 nor run compliantly on 3.x.

That's the point, yes. Obviously any interpreter that's backwards compatible with 2.7 but includes new features from 3.x is going to let people write code that doesn't run under 2.7 or 3.x. But what does it matter if your code doesn't run under interpreters that you aren't using and don't intend to use?

> Just call it anything else

I'll change the name.

Re: Why I'm Making Python 2.8

#344

Post by pfranz »

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 do think the split is in use-cases. I've worked in film at both small and very large places. You can get by very easily ignoring things like color management and frame rates when you're doing small, homogenous work. As soon as you need to take it seriously, the only real way to handle these things is to tag and/or convert these things at the perimeter so you can reliably handle things internally in a consistent way, then convert on the way back out. Even knowing this upfront and being highly motivated, it can take companies years to transition with pain in the meantime.

Text handling is the same. The thing is, many people just deal with ascii compatible English so they don't realize this is a problem for other people and aren't motivated to change. The reason both sides can't just do their own thing (i.e. Python2) is because of libraries and shared code makes it miserable for people using other character sets (most of the world or any company growing bigger than a certain size).

Re: Why I'm Making Python 2.8

#346

Post by BuckRogers »

int_19h wrote: post #289
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…

It's worth noting that Microsoft is still keeping VB6 on life support, in a sense. The tooling is not guaranteed to work on modern OSes (and there is a bunch of actual breakage, although community has found workarounds so far). But the runtime is still supported - in fact, it ships with the OS! If you have any non-ARM version of Windows, up to and including Win10, around, check the file named msvbvm60.dll in C:\Windo…

That's not generosity that's control. They kept maintaining 2.7 because they knew if they didn't someone would definitely have done exactly this.

They are only trying to run out the clock on other people's interest- an effort to kill Python2 so it doesn't evolve.

Re: Why I'm Making Python 2.8

#347

Post by ubernostrum »

int_19h wrote: post #295
bb611 wrote: post #162

Earlier quoted context omitted.

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…

Except if you make an exception for bytes, what about other types that might get passed into a CSV writer, whose __str__ is something "wrong" for CSV purposes? Do they also get auto-detected? Do we add a new __csv__() method just for when outputting to CSV (since it might not be "wrong" for other output formats)? Or do we ditch str()-ifying altogether, but then add back in a bunch of special cases for numeric types and other things where str() is "the right thing"?

Or do we say "CSV outputs strings, whatever is the string representation of what you passed in is what gets written out", and trust people to figure out when they're working with something that has a "wrong" string representation for their use case?

Because remember: the whole underlying cause of this was treating a dangerously non-string value as a string. Those bytes objects should have been decoded to strings long before reaching the CSV writer. Python 3 does raise more and louder exceptions when you pass bytes to things that expect strings, but the CSV writer isn't a thing that expects strings; it expects things that have a string representation, and several common use cases get much more difficult if you change that to force every user to explicitly do throwaway casts to string in the name of protecting people who keep insisting on writing dangerous "I'll treat bytes as string until it breaks, and then complain that the language did the wrong thing, not me" code.

Re: Why I'm Making Python 2.8

#348

Post by woah »

Why does Python have so many hilariously convoluted trials and tribulations over decades trying to upgrade their language when the JavaScript community is able to run smoothly across many different versions and many different interpreters simultaneously?

Re: Why I'm Making Python 2.8

#349

Post by stefantalpalaru »

guitarbill wrote: post #172
username223 wrote: post #117

Earlier quoted context omitted.

This is how you keep using those efficient, numerically-stable subroutines written by a smart guy who retired 20 years ago in your new code. Unlike Python, Fortran has managed to add significant new features without breaking old code.

Unlike Python, Fortran hasn't seen an increase in usage and hasn't brought the joy(?) of programming to thousands of new programmers in the last 10 years. So sticking to Fortran or backwards compatibility blindly doesn't solve all the problems, either. Maintenance is key. Most people don't stick around for 20 years anymore either. I know I'm going to have an easier time finding a new hire for a Python codebase. And h…

> Unlike Python, Fortran hasn't seen an increase in usage and hasn't brought the joy(?) of programming to thousands of new programmers in the last 10 years.

SciPy has Fortran code under the hood: https://github.com/scipy/scipy/search?l=FORTRAN&utf8=%E2%9C%...

Both SciPy and NumPy use LAPACK - a Fortran library. SciPy also uses BLAS - another Fortran library.

So every time you praise Python for being useful for scientific work, you're actually praising Fortran and C libraries/modules wrapped in Python.

Re: Why I'm Making Python 2.8

#350

Post by spb »

yladiz wrote: post #299
greyman wrote: post #266

Earlier quoted context omitted.

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

Last time I checked, Google's tools (like the Android SDK) require python2.
Post reply on HN