Live data from Hacker News

Why I'm Making Python 2.8

naftaliharris.com

381–390 of 392 posts

Re: Why I'm Making Python 2.8

#381
post #335
post #304

Earlier quoted context omitted.

Julia can be a good competitor to Python, but far in the future. Now it's just not there yet. Go is interesting, but really a different (and perhaps smaller) use case. What, for instance, I do in Python? That little one-off script that converts one thing to another or calculates something - I am not sure why I would even bother thinking about Go. I have no doubt that at some point, Python will be replaced by somethin…

>C is also not based on solid foundations C is based on the solidest possible foundation: the actual hardware CPU.

The C abstract machine doesn't have that much in common with any actual hardware. I suppose it sort-of resembled the PDP-11 once.

Re: Why I'm Making Python 2.8

#382

Earlier quoted context omitted.

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

> There were generally no map/filter/fold APIs in those languages, eager or lazy. Array.FindAll, Array.Convert, etc. all existed in C# beforehand. Though maybe this is what you meant in the next sentence. > 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). This is going on a tangent but LINQ…

> Array.FindAll, Array.Convert, etc. all existed in C# beforehand. Though maybe this is what you meant in the next sentence.

Yes, it's what I had in mind. I have to admit that I completely forgot about ConvertAll (and so assumed there was no map).

I think the biggest reason why those weren't all that commonly used in practice, is because in .NET you often deal with opaque collection types (like ICollection, or ReadOnlyCollection, or even custom-made collections pre-generics) that are usually exposed on properties of objects. Since the concrete type is not known, you can't do List.ConvertAll etc.

This, by the way, is another point in the favor of lazy implementations - they don't care about input type, because the output type is always "lazy sequence". Of course, you can have an eager map similarly not care about input, but then what should be the type of its output collection by default? No matter what type you choose, someone will complain that they wanted someone else. Given Python's preference for explicitness, such design would warrant several functions like map_to_list, map_to_tuple, map_to_set etc. But, of course, if you have a lazy map, you might as well just write list(map(...)) etc.

> You have to say "using System.Linq;" at the top if you want to use the new syntax. That's like saying "from itertools import " and then using imap, which you could've always done.

It's a bit different, though. When you import itertools, it brings all those functions into your global namespace. But when you import System.Linq, it only brings one static class into your global namespace; the actual functions are extension methods that only show up on the types to which they are applicable. So the resulting namespace pollution is far less in C#.

There's also the issue of import being generally frowned upon in idiomatic Python, largely because the way conflict resolution works there (silent override). In C#, if you happen to have clashing identifiers from usings, it'll prevent you from using them unqualified, so there's no good reason to avoid it.

Re: Why I'm Making Python 2.8

#383

Earlier quoted context omitted.

`bytes` is plainly special case for historical reasons here - it's something that is not a string, but that so many people assume to be a string. So yeah, I would be fine with making an exception for it (and providing some kind of option to disable that exception, for that incredibly rare case where someone really does need b"foo" in their CSV output). And then in 5 years, flip the default of that switch, and depreca…

The entire problem, though, is people assuming bytes and strings are interchangeable. Anything which allows that assumption to go unquestioned, or without program-wrecking consequences, leads right back to where we were. And the "phase it out" model doesn't work; you proposed a ten-year phase-out, but in ten years people are just going to say "we never updated our code, we're not ready, keep it this way another ten y…

> The only thing that works is actively breaking people's programs when they try to intermix bytes and strings.

Um, this is exactly what I proposed above!

"this should be a hard error, immediately reported as such, and not just a silent behavior change."

What I'm asking for is that csv writer raises an exception if it sees bytes anywhere by default. The problem is that right now, it doesn't! It just gives you "incorrect" output, that might go undetected for a long time.

Re: Why I'm Making Python 2.8

#384

Earlier quoted context omitted.

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

The docs say that "[a] row must be an iterable of strings or numbers" [0]. So I guess an exception could be raised. However, the docs do tell a lie; non-strings are accepted and get converted to strings. You can pass any object in which has a string representation - including a byte array. It actually wouldn't be too hard to introduce a check for a bytes field, https://hg.python.org/cpython/file/3.6/Modules/_csv.c#l1…

Yes, "special cases aren't special enough to break the rules".

But "practicality beats purity".

And "errors should never pass silently"!

It's the same kind of thing that leads to safety warning stickers put on products. You may read it and think that it's something so obvious that consenting adults should know better. But then you look at the statistics about how many people did not, and realize that, yeah, a sticker along the lines of "don't stick your finger into a food processor" is actually a good idea. Especially given how cheap it is, and how expensive reattaching fingers is...

Basically, products should be designed around known human weaknesses, and that includes entrenched modes of thinking by past products. It doesn't mean that new products should accommodate those entrenched modes, especially when they lead to other problems. But they should try to detect them, and issue clear and explicit warnings, to guide the person to the proper way of doing things.

Re: Why I'm Making Python 2.8

#385
post #379

Earlier quoted context omitted.

Obsolete is a funny word to use. In this case, it would mean that Python 2 is in good working order, but is no longer wanted. That's bound for a flame war, because: - There is a community that wants it (largely enterprise). - The Python team does not want it. A less controversial word is deprecated - the Python team is discouraging use of Python 2, but not prohibiting it's use or development. That's fair, and if you…

Obsolete was a wrong word to use, I admit that. But from an integrator's perspective supporting both versions is a mess. The problem is that the interpreter has the same name (python), the libraries export the same symbols (well, same names, different signatures for extra fun) etc. Like you said, Python team sees the 3.x series as the successor AND as a replacement for Python 2.x. They were never meant to exist one b…

And yet a transition period is needed.

I wonder what about this made this difficult. Was it because it's a language interpreter? Libraries have this problem sometimes, but not as much. (I never hear of issues with gstreamer between 0.10 and 1.0, for example.) Maybe it was just that a binary called python existed? Maybe we should have just said "screw it, python means python2, end of story."

Don't know. What would you have preferred?

Re: Why I'm Making Python 2.8

#386
post #307
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…

(Replying to the top-ranked comment so that as many people as possible see it) While I wish Naftali well in his efforts - I have a private Python-derived language myself! - this is not "Python 2.8." For trademark purposes, "Python" is only what is released or endorsed by the PSF. We have already reached out to Naftali and asked him to change the name of his project and update this blog post accordingly. Obviously, th…

Scorn? He's doing the CPython maintainer's job for them. He should be universally praised.

Re: Why I'm Making Python 2.8

#387
post #168

I never knew that despite Python 3 is called the future by PSF and has been around for a ling time, people still want to stick to Python 2. I mean it isn't the 2013 that libs aren't ported, most famous ones generally are ported. Don't know what the problem is.

Legacy python 2 code & an unwillingness to refactor it for python 3.

I can understand a project with millions of lines of python2 code, it would be a headache to port it all to python3

Re: Why I'm Making Python 2.8

#388
post #379

Earlier quoted context omitted.

Obsolete was a wrong word to use, I admit that. But from an integrator's perspective supporting both versions is a mess. The problem is that the interpreter has the same name (python), the libraries export the same symbols (well, same names, different signatures for extra fun) etc. Like you said, Python team sees the 3.x series as the successor AND as a replacement for Python 2.x. They were never meant to exist one b…

And yet a transition period is needed. I wonder what about this made this difficult. Was it because it's a language interpreter? Libraries have this problem sometimes, but not as much. (I never hear of issues with gstreamer between 0.10 and 1.0, for example.) Maybe it was just that a binary called python existed? Maybe we should have just said "screw it, python means python2, end of story." Don't know. What would you…

Well, in my ideal world maintainers would have put all possible effort to porting libraries to python 3 and put python 2 versions into legacy mode (e.g.: security updates, fork it if you want to continue on the 2-branch).

In my field what seemed to keep people on python 2 for a long time was numpy or scipy (or both, I do not remember which) which did not get a 3 upgrade for a long time.

Either that, or just call it something different, kind of like perl6. There is no perl6 distribution shipping a perl library or some perl.dll that clashes with perl5.

Re: Why I'm Making Python 2.8

#389
post #191

Earlier quoted context omitted.

why can't print be both a function and a statement...

The print statement has a lot of special magic like '>>' and trailing commas that uglifies the parser.

I don't get this. There's a tiny fraction of Python users who care about the complexity of the language parser. But many hate the print-tax.

Re: Why I'm Making Python 2.8

#390

Earlier quoted context omitted.

It's not dead, it's just really slow. The 2.7 release has been very long in the making, released only 18 months ago. There are stabilization releases to it still coming out. There's a tiny, but dedicated group building it and it shows. Jython 3 is possible if you're willing to put your money where your mouth is.

There's been an imminent 2.7.1 release for a while now, so that will likely eventually ship. AIUI, some of those who were paid to work on it previously are now doing so only in their spare time.

Yes, that would be true on all counts :) as one of those Jython maintainers. Jython 2.7.1 is currently bottlenecked on finalizing support on Windows for pip/setuptools. It should be the last fix.
Post reply on HN