 Well, typically, when you're ready to hear a group of people hold forth on a topic like Python 3, the first thing you want to do is to know whether they are at all qualified. And so if we could have each of you just briefly, we'd like to know how long you've been involved or touching Python 3, whether you've deployed it or not, and how long your experience has been with it. We can start over here. Hi. I started to work with Python 3 since the beginning before Python 3 existed because I am a Python Core developer and I helped to fix all this unique of issues. So currently, I'm working in OpenStack to Python 3. I can say that it is in progress and we have more and more Python 3 libraries, which are Python 3 compatible. But in fact, it's not used in production since it's not done yet. So I'm trying to do all my best to support all libraries and dependencies to Python 3. But I'm still using Python 2. So like Victor, I'm a Python Core developer and have been part of the effort for Python 3 since the beginning, as well as being part of the effort to fix all the latent Unicode defects in the Python standard library that were revealed by the transition to Python 3. And then I also work for Red Hat and we're the ones responsible for that, that people still are in Python 2.3 in production. So I'm all too well aware of the issues associated with long-term maintenance of Python 2 projects. And similarly, helping with getting Red Hat systems to the point where we can use Python 3 in production. So. Hi, I'm Alex. I first remember hearing about Python 3 during, I want to say, Guido's keynote at PyCon 2008. That's like six years ago. Since then, I've been involved in the porting to Python 3 process for Django, OpenStack, PyPy, and a whole host of smaller projects. Hi, I'm Selena. And for the past two years, I've been teaching PyLadies workshops in Portland. And most of my experience with Python 3 is when PyLadies accidentally install it. And then yeah, that's it. All right, so as the other folks here, I'm also a core developer of the Python, the C Python interpreters. I was involved with the initial effort for Python 3 around 2007 when we actually designed the language and implementing. I started to get involved using the Google Summer of Code, which actually led me to actually get a job at Google and Google actually do a lot of Python. And actually, it's very difficult for us because we have a huge enormous code base where we're unable to actually port because it's millions and millions of lines of Python. And I'm actually investigating what can we do for moving on to the next version. And so the panel is fairly evenly split between those who, so to speak, suffer Python 3 and those whose fault it is. Alex, you're involved in the PyPy project. I can't remember what its status with respect to Python 3 is because, of course, it's initial out-the-door implementation of the very, very fast, just-in-time compiled version of Python initially targeted to 7? Yeah, our current release targets 2.7. Did it start with 2.7 or 2.6? We've been evolving the same code base since at least 2.2, maybe older. What is the status of Python 3? So we have a Python 3 branch. It is very, very close to being ready for release. There's an alpha available. And at the sprints, people have been working on the 3.3 branch to get it going on the next version, our current Python 3 branch targets 3.2. The guido in his keynote, if I recall, announced, and it's now confirmed that Python 2.7, which has been the final 2 version now for five years, I believe, has been given another five years of maintenance beyond the initial five years that was promised. I'd like to hear from the panelists on whether the next five years are likely to be different than the first few, or whether it's likely that there'll be yet another. What will this be like in a sort of communism? Further five-year plans, because I have clients. I teach Python professionally at times in corporations. And there are people. I don't know how they do this. But they wind up with, like, a million line Python projects. And they kind of are afraid of Python going out from under them and not being supported anymore, Python 2 going out from under them, because there's just no good time, their bosses think, to stop everything and port a million lines to three, fearing that they might send something then out the door, thinking they've transitioned to Python 3, not knowing that there's edge cases that only their customers will find in their Unicode handling or whatever. Yeah, and so definitely the original way of porting to Python 3 that Guido and the rest of the core developers that we promoted when 3.0 was first released essentially doesn't work. So that was the big bang approach. You pick a date, and you say, we're going to go Python 3 now, and we'll switch everything over. Don't doubt that's just a bad idea. It's just a terrible way to do it. And so over the past five years, the community have basically figured out a whole bunch of ways to do ports that are, instead, incremental and opportunistic that you take parts of your code base and you incrementally upgrade them to be Python 3-compatible. Parts of the code base. Yeah, and essentially what has turned out to be possible is that even though it was explicitly a non-goal of the Python 3 project to make a large common subset of the two languages, as it turned out, we were sufficiently conservative in what we did that there actually is a very large, very usable common subset. And we've actually been making that common subset bigger by adding stuff to Python 3 releases. So like Unicode literals came back in 3.3. Various things were improved in the codec support in 3.4. Binary interpolation will be coming back in 3.5. And then in addition to that, we'll be adding some stuff into 2.7 around SSL. And essentially, the idea will be that there is a very large common subset of 2 and 3 that you can program in. And then projects like the 6th project and the future project on PyPI make that common subset larger again. And what that lets you do is program in Python 2, port things to the common subset as you go. But you're still testing and running everything in Python 2. So if you're testing and running in Python 2, what tool can tell you if your Python 2 is 3 ready? Is hitting that subset? Yeah. And so well, one thing you can do is you can just try running yourself under Python 3 and see if it works. But if a bunch of your tests are still in 2 and haven't been ported, you can do that yet. The dash 3 warning flag in Python 2 is designed to help a lot with this. At the moment, it is missing some warnings that should be there. But the thing is adding new Python 3 warnings is in scope for 2.7 maintenance releases. So we haven't had a lot of contributions to add new warnings. But those are in scope. And then the other, there's an opening for Python 2.7 to gain more features in the area of helping you identify incompatibilities. Absolutely. The other things, and so getting into the more speculative stuff is getting into more speculative stuff. So these are things that do not exist yet, but are being discussed. And that is basically from a syntactic point of view, basically taking something like Python to whatever and giving it a mode that says, is this in the common subset? And make sure you're not using any of the removed constructs. But then another potential possibility, which is even more speculative, but being discussed seriously, is the idea of a fork of Python 2.7 that doesn't add anything, but just takes away all of the stuff that didn't survive the Python 3 transition. And then the basic idea then is that you can run your stuff under the fork. And if it runs there, then yeah, you're in the common subset. And yeah, that one's entirely speculative at this point, but it seems like a good idea. Of the other panelists, how many of you have ported anything to Python 3? Just to start with a show of hands. And then so yeah, could we hear briefly, and in addition to other comments you have on what Nick said, what it was like and what you found the pain points being of getting a project and specify whether you were targeting the common subset. That is whether you're trying to make code that would just work simultaneously on both, or whether you've done anything where you just went for Python 3 that looks like Python 3. So yeah, so most of my experience has been involved with actually porting stuff with the standard library of Python. And one other thing, so for me, it was actually targeting the Python 3 and actually removing support of Python.7. And even in this case where you actually drop support, it's actually really, really difficult because you end up adding all the unicode issue that you maybe made assumptions. And these actually really hit you in the butt. At some point, because sometimes you have your APIs, actually we had the issue, for example, with the file system, actually the API wasn't designed to actually have unicode in it. So we had to come up with way and acts to actually be able to, OK, well, we assume this API that was all ASCII and that we can actually convert the characters, but actually we actually didn't know what's encoding. So we had to return, for example, there's a case for the file system paths. And there's a case where if the file system, you don't know the encoding of the file system, there's not really a whole lot you can do. And one other thing, so you have to use bytes. And so we had to extend the API to actually support when you give it a bytes path, then it will return you a bytes. It won't do any encoding. But still, at the same time, one trick we use is if you give it one unicode argument, why should we turn you into unicode? They won't do the best thing to actually try to convert it. And sometimes the best thing you can do is just use ASCII. And most often on many file systems, why should it kind of blow up? And so that was one of the issues that we faced. And for audience members who might never have tried this before or have run into this. So if I understand the problems that under Python 2, if you did something text-ish and had some unicode strings with international characters that were full strings, but also just kind of tossed some old-fashioned ASCII byte strings at it, Python 2 would guess. It would just make a kind of best effort attempt, maybe using the encoding you wanted, maybe not, to interpret the little byte string you had given it. Well, you say probably not. The issue is that very often people test their stuff with all ASCII strings. And so it looks like it's doing what they want. And if nobody ever types those French characters into their web interface, the web app just always works. And that guess that Python is making about what these bytes mean just works so often that it's later, even in the standard library of Python 3.4, it's later that you run into these cases where that leaping, flying guess that Python was making suddenly doesn't work for a particular circumstance. So actually, one thing I've been doing, so my first language is French, actually, I'm from Montreal, and one thing I've been doing, and whenever I actually had tests in Python, I actually used French strings. I put, like, exanted, and I put, like, actually, I used the streets of Montreal as some of my test case. So I'm putting my little pause and my path into the standard library. It's kind of a lot of fun. And one thing I actually had a lot of trouble, apart from unicode, is actually we organized a standard library in Python 3. That was actually a read, that actually turns out, actually, as Nick said, is a huge mistake. And a lot of the things actually come to me because I'm actually the maintainer of Pickle. And Pickle, actually, if you know about Pickleworks, it takes your class and it dumps the full path of the module and the object that you have. And a lot of the dependency that you have in your class actually end up being dumped into disk. And when you try to actually come and load these Pickle in Python 3, then where these class actually all come from, they're just like, hey, I'm trying to import, like, I don't know, like, C string. C string is gone in Python 3. So where is it now? It's like, what do you do? So in Pickle, it creates a huge map of all the change we did. So that you could load up Python 2 Pickles. Exactly. In Python 3. Actually, because one of the contract in Pickle was that every version of Python should be able to load, every forward version of Python should be able to load, like Pickle was generated by previous version of Python. And that promise, when it was made, was just about if we tweak the format, we promise to read the old one too. Exactly. Not if we rename the whole standard library, we're going to magically translate. So as you can imagine, as you can imagine, I had a lot of fun doing a summer. It took me a whole summer, actually, going through and finding all the small test kits. I spent a whole summer trying to have a whole lot of fun trying to map it too. And it's actually not fully fixed. Actually, on the sprints, if someone actually want to go and fix more of these Pickle incompatibility in Python 3, more doesn't welcome. Come and see me on the sprints. I'll have a lot of fun. I'll try to teach you how crazy this idea was. Does that mean the Pickle module is going to have a dictionary in it that maps old to new names and that? It already does, actually. So it's actually a secret module, internally, that's called a underscore-compatible Pickle. That's not going to stop me. Probably. So we probably should consider actually mapping it. And given the API. So the crazy thing is I tried to map this thing. It's like Pickle was not designed very well. And we kind of took this big hit in Python 3. And it was a lot of fun. On the way past Selena, because when we were talking about training a minute ago, it made me think of a question. So the student goes to python.org. They've been trained to always download the most recent version of anything because SSL. And which actually applies in this case. And they wind up with Python 3 and you helpfully downgrade them to the happy and safe world of 2008 or 2009. How do they then react to the fact that you want them on like this older version? Do they kind of go through the class and then never come back? Because they're like, this is weird. The Ruby people want me to use the most recent version. But the Python people are all sitting in the trenches. Untrustworthy. Leaders have written out to the front by themselves. Let's talk about Pearl 6 for a minute. It's really confusing to the students. They really don't understand why we're downgrading them. And they feel like maybe one of the things that they think that people have told me is that the Pilates classes are just crap because we're only teaching them old crap that no one uses. And then I explained the 2.4 situation with Red Hat. And also that my project, my open source project that I work on at Mozilla is still 2.6. And then they feel a little bit better that at least 2.7 is better than 2.6. So that part is very confusing. I will say that the new Python.org website design improves the situation significantly. Because instead, I don't know if you all know this, but the Python download page used to be organized alphabetically by topic. And so you would go to the download page. And the first thing that you would see is alternative implementations of Python. Seriously. Yeah, I have a screenshot. It's really great. It's on my laptop. Anyway, this is one of the examples of design failure for beginners that I share. But now the website is way, way better. But another improvement that I would suggest is not linking to a Wiki page to explain the difference between 2.6 and 3, or 2. whatever and 3.8, whatever. Anyway, although that may have been fixed by now, I don't know. No. OK. Well, suggested improvement. So I will point out that while Python.org used to be an arcane thing that people couldn't help with, it is now a Python 3.3 project on GitHub under the Python account. And so, yeah, and it's basically along with the, it's kind of part of the whole opening up the PSF thing and making it more accessible. So GitHub repo, open source, Python 3.3 Django project. Pardon? Patch is accepted. Yeah, Patch is accepted. That particular one should be going in on the CMS side. Because, yeah, it was on the Wiki because updating the old website was, yeah. We actually wanted people to be able to contribute to it, which was not true of the old website. OK, sorry. I don't know. I think that was sufficient. I mean, I could talk a little. I mean, another big barrier, I would say, to using 3.0, 3. whatever in a teaching context is that even for something as simple as a Flask app, you can't really use 3.x with the tutorials that exist today. And then if you actually go to the Flask documentation, it says that 3.x is only 1% of downloads, so we don't really recommend that you do it anyway. So there's a lot of barriers for the typical libraries that you might teach in a very beginner's class. And something that would definitely help Pilates like workshops would be for the maintainers of the introductory-type modules to support 3.0 a little more. Alex, you were when we were on the subject of experience of porting a Python 3.0, yeah. If you want to pickle, go to Schwartz's, not the Standard Lev. So every single module I've ported has been to a shared source using libraries like 6. To tell the audience what 6 is in case they've not seen it. So 6 is basically SIX, right? Yes, not the digit. Yeah, it's the Arabic letters for 6, English, Latin letters, not the Arabic numeral. It is basically a module to assist you in Python 3.0 porting. It provides all sorts of useful helpers, an example of which is if you can't use the Unicode literals because you support Python 3.2, which doesn't have them yet, you can just use the U function, which will convert your string to the Unicode on both versions. It has useful helpers like the long type was removed in Python 3. So now it exposes a thing, 6.integer types. And you can use that if you want to check if something is instance interlong. And it will work across Python 2 or Python 3. All sorts of useful helpers, or 6.interitems will do the equivalent of dict.interitems on Python 2 or dict.items on Python 3. Useful helpers like that. So we use this completely throughout Django and a bunch of the other libraries I work on. As for how the experience was, basically the experience completely didn't start until libraries like 6 came out. Like Nick said, the original, you just do it all at once. It'll be great. Approach was a complete non-starter for us. Probably one of the most interesting things I've seen is we'll do the port. We'll get all of our tests running. Someone will do the demo website, like load up the, hey, you install Django page in Python 3. It works. It's awesome. We shipped an alpha release. Then we shipped it in Django 1.5. In Django 1.6, Python 3.Sport was official. Final, we're sporting it from here on out. It'll be great. You should use it. And then we find out that there were places in the standard lib or in our own library that were under tested. And that just the Python 3 codebath was never exercised in our tests. And so we missed cases. So that was really interesting seeing those reports come in, trickle in from users. So as a project manager, yeah, projects always do this. They issue an alpha and ask people to test, and issue a beta and ask people to test, not realizing that it's issuing the real new version that's the way you ask people to test. And that's when people run into the problems. Oh, we realize it. Any other, any particular points or in Unicode was the Unicode and renaming? Six handles the renaming as well? Six handles most of the renaming, including the moved standard lib modules by letting you just do from six.moves import whatever the new name for the thing is. So that's pretty nice. Unicode is definitely the brunt of the thinking work. There's a lot of small changes. For example, the exception capturing syntax changed, got rid of the function tuple unpacking inside a function arguments, which is an obscure feature. But if you use it, you gotta make a lot of changes to your code base. Things like that ultimately take up a lot of time. I've been lately involved in the twisted porting efforts. And one of the most striking things there is twisted is something like a 15-year-old code base. And about 10 years ago, they figured out that testing was really important and you should write unit tests. And there's still five years of code older than that that does not have great test coverage. So one of the big issues the Twisted project has is you need to add tests before you can start porting any of these features because otherwise you will almost certainly break it for all of your existing users and it probably won't work for your new users either. So that's, I would say, one of the biggest impediments at least in the context of older projects that do not have universal test coverage. All right, and could we over here, any tales to tell about your porting experiences? So, so far, I keep hearing and given your positions and projects, the experiences we've heard reported on so far are libraries that were Python 2 being moved to this kind of common subset. There's no standard for it. It's just the idea of code that will be acceptable to either Python 2's interpreter or 3's. And so none of the reports you were giving were of code bases where you could just run 2 to 3 on it and fix everything and be in Python 3 land. Is that correct? Most of you guys have been, because you're serving other users that will be on both pythons, you've been moving to that common subset where you have to swear off of any specifically Python 3 advances. You don't get to have fun with the new stuff in the language because you're remaining compatible. All right. Well, the first problem of porting to Python 3 is that you have to fix all your bugs in your applications. For example, in Python 2, Unicode does just work. It doesn't work in all cases, but it almost works. It pretends to work. It pretends to work. So in Python 3, it's now forbidden. You have to fix it to all places at once. You cannot just switch a flag to say that, oh, it doesn't care of Unicode's characters. Just try to do your best. When you port, you have to fix all issues before being able to run your real application. There is also a division operator which changed and it's a pain to handle this manner operator because in Python 2, it's impossible to say that if the result will be a float or an integer. Using tools like 2.3, it's not possible to do that automatically. So you need a huge, large test suite to ensure that all the port will work on Python 2 or on Python 3. And in practice, there are very few code base which is tested. And so you're not sure that even if the code looks to work, you will probably get some errors much later on. So it's a pain. And the other problem with Python 3 is that in fact, it's not so much faster, it's not really amazing if you just port your applications to Python 3. It just works, but that's all. So if you would like to have a better application, you have to use new features of Python 3, but you cannot do that because you still want to use Python 2. And because you have to support Python 2, in fact, support edge is almost useless. So it's a pain, it's a useless, but you should do port your application to Python 3. So this situation reminds me very much of when Postgres changed, so I'm a major contributor to the Postgres project, and we changed our default encoding from SQL ASCII, which is basically anything goes, to UTF-8. And when this happened, there's another change that we did also that restricted the automatic type conversions as well. I think these things came one year after the other. And this didn't apply to existing databases. That's right, like when you created a new database, so you got a little surprise. And I will say, I think it's been five, maybe six years now and users still get caught off guard by it. And in fact, there are a couple of packages that have decided, Debian, to make the default encoding SQL ASCII in their packaging, which is sort of a shocking, special decision. But anyway, I will say that the users were initially upset and confused and angry, probably for about two years. But in the end, it was such a beneficial change in talking about these bugs that you find and these things that you're able to fix, this data corruption that you avoid. It really was ultimately the right decision. And in the end, the users supported it, but there were like two years of a lot of very angry users. I just got one more thing. I think Nick had a comment, and we're just at half time, which means that we'll switch over to audience questions. So yeah, so my comment is actually based on something Alex said a while ago, like not here, which was when you're writing software, you're either writing for the users you have or you're writing for the users you want. And so for a very long time with Python 2, we were writing for the users we had. The interesting thing that happened with Python 3 was that Python 3 was about writing code for the users we want. And one of the major contributors to the Python 3 process is Steven Turnbull, who's a Xemax, I'm not sure if he's the lead or just one of the major contributors. And so, and he lives in Japan. And so, Japan, if the issues Europeans hit with encoding issues, nothing compared to the issues East Asian countries hit. Who've been known to use non-Alatin alphabets. Yeah, yeah. And so in the days before Unicode, they had come up with all these solutions like Big Five, CJK Codex. They just out of necessity, they came up with all of their own encodings to try and deal with, to try and deal with representing Asian languages in bytes-oriented computing environments. And ASCII compatibility just was not a factor, it was. And so this move for Python was one that had to be made before we would be big in markets that need Unicode everywhere end-to-end in the language. And so this was the thing of that Python 2, if you're a Chinese user and your home directory it uses your actual name, Python 2 won't run. It won't be able to start because it can't handle the name of your user directory. And so this was a case of us going, well, okay, we are actually going to listen to the experience of the web developers, the experience of the desktop GUI developers, and that basically in the 21st century, first class Unicode support is not optional. And so we went and created Python 3, and then we released Python 3.0 and 3.1, and we went, wow, our Unicode handling is really, really broken. And Tom Christensen, I think, is a guy who's gone through a lot of the Python 2 Unicode support and just went, yeah, all these things are broken. And so people who've only used Python on Linux systems, so the Linux developers, the Linux distros always build Python 2 with four-character Unicode. And four-character Unicode in Python 2 actually mostly works. The Windows builds were not built with four-character Unicode, they were built with narrow Unicode that only used two bytes. 16-bit. That really didn't work. There was lots and lots of cases where Python 2 narrow builds would do the wrong thing. And so basically, yeah, what happened was when we created Python 3, we then went through and found, oh, okay, this doesn't work in this situation, this doesn't work in that situation. And there's basically all sorts of Unicode bugs in the Python 2 standard library that if you're mostly in an ASCII environment, you're just not gonna hit them. And if you're doing network programming where you're just pushing bytes around and you never actually translate it to text, then you're gonna be fine there as well. And this is kind of what we see with the feedback is that the developers who are most struggling with the transition of folks doing network programming where they're taking bits off the wire, pushing them back out on the wire again and operating entirely in the binary domain. And then similarly, people who like the mercurial developers who are again doing file system work. At that byte level. At that byte level. And essentially what we did in the Python 3 transition is that we went, okay, the default text model should be optimized for normal application programming. Not for the bytes and bits. Yeah, not for the bytes and networking people. But then what we've been finding over the last five years is that, oh, okay, we did make a bunch of mistakes at the binary level and that binary manipulation stuff. And that's what we're really focusing on, putting a lot of focus into for 3.5 now. Is like, okay, we've had five years of doing this. We figured out where a bunch of the mistakes are. And yeah, and that 3.5 will now be about, oh, okay. So this is, we've now got beyond a lot of the feedback was of the nature of, oh, I liked Python 2 better. Which we can't do a lot with until we figure out why did they like Python 2 better? And we think we're finally getting to that point where, okay, we're moving from, oh, I liked Python 2 to, okay, this is a specific issue in Python 3 that, yeah, it is genuinely not better than Python 2 in these cases. And we're starting to turn it into particular things. Cool. And that's very nice to hear that the networking and binary story, yes? Be careful with it, Mike. Oh, don't worry, they only explore a little. But I have something to add. In fact, we've discussed, we focused on porting to Python 2 to Python 3. But in fact, if you start a new program with Python 3, it almost just works with Unicode. You don't have to worry about the file system encoding when you can send a URL directly in Unicode, you can write data in Unicode, everything works just fine. So it's a little bit surprising because a lot of people are complaining that Python 3 sucks. But a lot of them are bad experience because of porting Python 2 to Python 3. Just try to write a new program with Python 3 and everything works. Oh, no, no. And so, and this brings us to our time. No, no, no, this is time for, and I believe that we have a first question here. Say it into the mic. Yeah, hi, I'm Matt, I'm a Rubyist. I just went through. Ha, ha, ha, ha. We just went through such a transition with Ruby 1.9 a few years back. You'll notice it's not semantic version. Anyways, so you mentioned earlier that you have none of the fun if you're building a library and you have to support both versions of Python. My question is, as a user, if I use a library that's limited in that way, that supports both, am I gonna feel those limits as well? No, okay. Maybe, usually. A little bit, okay. Totally maybe, I actually strongly disagree with that. A great example of that is Python 3.4 contains this new async.io module for doing asynchronous networking programming. It relies on a syntax feature that was only added in Python 3.3. If the library you're using for networking stuff still needs to support Python 2, it's quite likely it will make a decision not to expose this feature because it relies on a syntax that it can't even use internally. That's why you can use async.io, most of it in Python 2, because he backforted it. Ha, ha, ha. Under a different incompatible syntax. Ha, ha, ha. You can't mix that. It's only the coroutine bit, so you just have to not use the coroutine bit or only use the coroutine syntax for the version you're using. Most of it is just callbacks, the same as twisted. But if someone who's a library author just, if someone produces something naively using the yield from syntax that they see in the async.io docs, then it's Python 3 only. They have to know to use the special trick. They just have to use the callback API, the same as they would with Twisted. What fun. I'm all about callbacks. I love callbacks. Okay, you already asked. What other users? Yes, my question is, how has Python, we Python users, well, civilians, can help you like porting stuff to Python 3? Porting, help the standard, the people developing Python itself or the people who have third-party libraries. All of them. Well, we'll just start, yeah. You can start, yeah. I think the first thing you can do is actually request from library author to actually give you a Python 3 version to actually just go and say, hey, I like to use Python 3, your library is not supported, please port it and please support me. Because a lot of the things that we see is that we have this kind of problem where it's kind of like this, like this kind of heating is still because we have no way of starting. So the library author says, well, there's no user using Python 3. And so they say, oh, well, there's no user, so we won't port a library. And then you go back and the user is like, well, there's no libraries using Python 3 and supporting Python 3. So you're just like, oh, well. And another thing that you can do is if you do find a library, well, even if you find one that only partially works, if you blog about it, that is super helpful for all of the trainers to be able to see your experience and to know whether something is like partially broken, fundamentally broken or mostly works. That information is super useful from a user perspective for training. So if you go to py3readiness.org, it's got a list of the top 360 packages by downloads, pick one of the ones that's not green and help port it. Though I'll note, that's not necessarily an easy experience. Some authors don't know what to do if this huge pull request is suddenly dumped on them that. Many small pull requests. Okay. Also talk to them first. Yes. Yeah, that was my thought is that a lot of them, I'm just thinking of the experiences of Jeff Forsear. Is that his last name? Yeah. Who I think had pull requests to make Parameco, turn Parameco into Python three as of a year ago and as of last month had like five of them. And I'll have to ask him what it was like to try to get all this smattering of people's ideas of how he might move to Python three and then try to get those integrated to a code base that had been moving, even as those people had been writing and the two didn't intersect very easily. Because that's the other thing too, is a lot of projects, they do have Python three ports in various states of readiness and it's just not a priority for them at the moment. So like G event for I think has had a Python three port ready for several months, but their focus was getting to G event 1.0 and now for one dot one, they'll try and get the Python three port in. So yeah, just talk to people first. Would there be any chance of a, so we have two to three. Is there any chance of there being a two to, restricted subset script that instead? There's already two. So Python modernize, I believe still works, even though I was not working on it anymore. And then there's another module called Python future. And that comes with actually, that actually comes with two scripts. So it comes with Futurize, which moves Python two code forward into the common subset. Into the common subset, doesn't just break your Python two abilities? Like two to three, two to three will just break it. We'll just break it, but this one does not. So Futurize moves it into the common subset and then they also provide another script called passurize, which goes from Python three to the common subset, so. Oh, did you have a comment? There is a project called two to six, which converts your project to you make use of six module and your code will still work on Python two and Python three. Are those mentioned? I was going to take it over there next. All right, and she has a mic already. Hi, yes. So another civilian question. Besides the issue of libraries importing and incompatibility and so forth, if you're a human being and you want to write a Python script and it's not really using any libraries or only Python three already acceptable libraries, but you still need Python two and your machine, of course, for everything else that you do. What is the accepted best practice for moving between Python two and Python three on your machine? Do you alias Python three? Do you make virtual M somehow use Python three just for whatever script you're writing? Do you have recommendations for how people ought to do that? First question, which operating system? Unixy, personally, Debian. Okay, so most of the Linux distros have a parallel Python three stack, so which will be accessible just as Python three from the command line. And they, as of last year sometime, most of them should also be shipping a Python two alias for Python two. Hey? Red Hat doesn't have a Python three stack, so it point is moot. So, but then as a cross-platform answer that even works on Red Hat and CentOS, the continue analytics folks have their conda, conda tool for managing, so whereas virtual Envo only goes down to the package level, you can't do multiple run times, conda lets you manage the Python run time as well and do parallel installs. Virtual Envo also takes a dash P flag when you're making a new virtual Envo to just change which Python you're using and there's another tool called PyEnv I believe which will just install all sorts of pythons for you. And Python Z which will download and compile and install as many versions as you want. He has a mic already. Hello, I was just wondering, you just announced five more years do you think you're over the watershed that like after five years you've got enough of the important bits done that you're down to more details or is it their fundamental work that's... You can still get a job writing COBOL. Thank you, but I'm not even technically a developer, so. No, no, no, his point wasn't that you, no, his point was that 2.7 will be around forever like COBOL is around forever. He wasn't telling you to go away and get a COBOL job. Thank you, thank you for pointing that out. Because it was a bad question. My sarcasm detector. Yeah, my sorry, I'm sorry about that. That didn't come across properly. What he said. Yeah, Python 2.7, it's gonna be effective life for quite some time. We're basically gonna keep working on tools to, because honestly when we started the Python 3 project we didn't realize how fundamental a change the Unicode change was. That was kind of something we figured out over five years of fixing Unicode bugs in the standard library was like, oh wow, we didn't realize how broken Unicode was in Python 2, despite having people like Steven telling us it's broken. Until you experience it and you're just like, oh okay, yeah, it was broken. But yeah, so we'll keep working on providing more tools to make it easy to get to Python 3 and the tools around the common subset, the back ports on the Python package index, they'll just keep approving and evolving and we'll get there. Frankly, I'm a bit of a skeptic, but who cares what I think? The question is not for us. We shipped our libraries, we've written the new runtime. The question is to all of you to go back to your companies and the scripts in your bin directory on your local computer and for you to port those and for you to start using Python 3 for real and production and whether you do or do not will determine whether libraries like Django ever become Python 3 only. Because we can't go there before our users go there. And some of us are working to make sure certain companies are less of a dead weight. Please. One small comment regarding civilians helping the porting efforts. The PSF will be happy to support you with beer and pizza if you want to get with your best friends to port a Python package. You can find all the details on pythonsprints.org. I know what I'm doing on the weekends from now on. I have a... It doesn't seem clear to me what interest that I would have to port my code to Python 3. It's one larger. Beer and pizza, of course. But effectively, to me, it seems more important now to switch to IPv6 than to port to Python 3. Do you have anything to say about that? So one of the reasons why Guido extended the upstream end-of-life for Python 2.7 is the idea from the core developer point of view has been that end users should be able to do the Python 3 transition on their timetable rather than ours. And so the extension at the end-of-life to 2020 was specifically about making that really, really explicit that, no, it's not going away next year. It'll... People still have plenty of time. Oh, okay. How is it any better? Yeah, yeah. So the thing from our point of view is for any given person, the killer feature of Python 3 is going to be different. So like the Python 3.3 brought some big changes to the way Unicode is handled, such which should massively reduce the amount of memory that Unicode applications uses. So for some users, that'll be a big deal. Python 3.5 will bring a matrix multiplication operator. So for scientific users, that'll be the case of, well, no, you're not going to want to use Python 2 because it doesn't have an operator for matrix multiplication. And so, yeah, and so it's the case of, and then Python 3.4 has a lot more nice stuff out of the box in it like async.io that for Python 2, you have to go grab it from the Python package index, or if nobody has back-ported it yet, take it from the Python 3.standard library, move it, and then commit it. Alex mentioned another one, which is the yield-form syntax for doing nice coroutines. Again, that's Python 3.only feature. If you're not doing coroutine heavy code, you're not going to care. And you can't kind of fake coroutines pretty well with things like Twisted Inline Deferreds and the stuff Victor did in Trolleyus. Does one of you have much experience with everyone raves on Twitter about this exceptions inside of exceptions thing in Python 3? What is that about? So I think what you're referring to is the chain exceptions. So one of the things that you might not actually experience is whenever you actually catch an exception, you actually kind of like lose the information that you originally had in this exception. When what happens? So for example, you can assume, okay, let's say you're trying to open a file and this file does not exist. And maybe you don't want this exception to be raised as an IO exception. You want maybe to actually, you have maybe this code that's opening up files within a library or some module. And actually what you want to instead raise is an application error. So I have a try accept around this file operation so that I can do something friendlier when it dies. Exactly. So instead of what you can do is, so raise your application error. So what you have is like you have a try accept, like try accept IO error, then you would raise application error there, right? So it's kind of a thing that you can do in Python 2. But if you do this, what you end up doing is actually, whenever this error is being raised, you actually kind of like swallow the IO exception and all the information that was contained there. And like for example, what was the file that you actually didn't open correctly is lost. So this is actually kind of, it can be kind of very annoying for people trying to debug your software if this application layer is actually kind of very deep down. And so in Python 3, we introduce what's called chain exceptions. So instead of implicitly, what we would do is like what you could use before is that you could actually kind of take the whole exception actually and add it into your new exception. But now implicitly, it would do this for you. It will actually take the whole exception, glue it to the new one that you're actually raising. And when you go on your interpreter trace back, it will actually show you the previous exception in the trace back information. And this is great because you don't lose any information. You can actually now use it to debug your software. And in terms of myself, so like the main production application I work on is Python 2.6 because REL. And the thing where I most frequently find myself going, I wish we were using Python 3 is the classic one where you have a bug in an error handler that you haven't discovered yet because your test coverage isn't that good. And then what happens is you get a message in your debug logs or in your error log saying, oh, this formatting failed. And you're like going, oh, that formatting message is in an error handler and you have no idea what error you were trying to handle. And so you have to basically fix the formatting bug, push that fix to production and maybe someday that original error will happen again and you might have some hope of fixing it. And if you were using Python 3 instead, the trace back that showed up in your logs would actually have not only the bug in your error handler but also the original bug that you were trying to handle. And so in your case, this is where my error handler code has a problem and dies on me and itself throws an exception. But the Python, whereas you were talking about, I can choose to attach the IO error to the application. Here Python automatically when it hits an error and has to kill me, it's going to get the exception that was in progress and also have it along for the ride. Yep. Okay. And so it means that when you hit the exception trace back logging at the top level, you get all of that info in your trace, in your debug logs. And you can not only fix the bug in your error handler but also have some hope of fixing the original problem as well. Okay. Even if it never happens again. That might or might not have happened to me before. I'm not going to admit whether. I see that we have a question over here. We're getting down to the last few minutes, I think, on the clock. How close are we? Just a minute or two. So go ahead and ask your question. So in retrospect, I mean, you guys went through the pains of migrating from two to three, correcting the bugs and so forth. If you were that person that initially saw the, you know, that migration from two to three, what would you do different? Not move stuff around in the standard library. Would you have done the print statement? Actually, okay. So for the print statement, I have a proof of concept patch on the Python bug tracker that adds call statements to Python. Guido doesn't. But we don't want them for all statements. We just want them for print. The only way you will get them back is to add them for everything because print is not going to get special case again. But we don't want consistency. What about those of us who loved the special case? For whom print is just a different kind of thing than everything else in Python? Have you ever tried to redirect print to a different file, like sys.standard. No, that's not what prints for. Use this one where you're sitting down. Have you ever tried to suppress the new line at the end of a print statement? With the comma? Yeah. Yeah. No. You can get a face. Do you know how that actually works? No. It sets an attribute on sys.standard out. Or on whatever file. Or on whatever file you're printing it through. If you want to substitute a fake object for standard out, it always has to have that slot. Or you could just use keyword on the arguments in Python 3. We changed it for a reason. But personally, I'm okay with the idea of adding cool statements. So you'd have to convince Guido, though. Python 3 is supposed to be a lot better and Selina might want to throw something in here as well. But in my training, so are we ever going to get rid of the dunder main thing? I have to explain that. Every, Selina, have you ever explained that to a class? The fact that their module doesn't actually have its real name under some circumstances? That's a magnificent noise. Yeah, yeah. I don't know. Yeah, it's terrible. I'm the run-by maintainer. I know how terrible it is. I don't have any. So my perspective on it is that scripts and modules are different things and you're blending them beyond adding dash M-friendly stuff is, yeah. Don't do it. Did you have a quick question? We're at time. We have a future module to enable future feature of the language in advance in all version of Python or all version where it's not already enabled. Could we have a past module to enable the feature that we're in Python to in which are virtually impossible to safely port two million scots like maybe division So one thing you might not see is that a lot of the Python 3 features are actually kind of like very, very invasive in the interpreter itself. So actually supporting these features, it would be like a major maintenance burden on the core developers. And at the same time, we don't want people to actually kind of move away from the whole style and actually kind of, if we would give this kind of feature, people would start using it and it would be very, very difficult to actually remove it from the language. Now we need to do like Python 4 to actually remove all these pasting, which... So that actually does remind me of one of the other motives for Python 3. And so there's the concept of the cognitive burden of a language that if you create a language such that it only ever grows, then it will necessarily become more and more difficult to learn because even if there are old, crafty features that new classes say, oh, I'll never use this, when you're doing maintenance programming, you're gonna have to know it because people will use it, there will be old legacy code that uses it, that sort of thing. One of the effective consequences of Python 3 is that even if code is just being updated to run in the modern subset of two and three, you have to remove all those old legacy features. You cannot use them anymore because they don't exist in the common subset. And that actually reduces the amount of stuff to learn in order to maintain modern Python 2 code, let alone Python 3. And this is actually, from my perspective, is that if people learn Python 3 first, then that's actually the modern stuff that survived the transition. It dodges all the legacy behavior. And then at that point, it's just a matter of learning, okay, here's the actual delta that between Python 3 and Python 2. We have a second or two left if you can condense your last comment. Yeah, so one thing to remember, we're not totally against adding old feature if they significantly make the porting actually a lot easier. And this is something that we, when we listened to the Vopper for Unicode, so we actually had it back, the literal, the U prefix on string because it was actually kind of like, it helped a lot for porting old program and actually kind of increased the common subsets for a lot of the Voppers. And in this case, the feature was like pretty kind of trivial and it was easy to support without actually adding a whole lot of burden on kind of language itself. But because of that desire for 3 to be simple, we're not likely to see in 3 itself adding back in complexity that's been taken out from 2. The case where we do do that is when the case is made that it is an improvement to Python 3 itself. And so that's what we're seeing with in Python 3.5, binary interpolation will be coming back because the case was made that, no, no, no, this is something that is, that actually makes Python 3 itself better and it has the added bonus of making porting certain kinds of code much easier. All right. Thank our panel. Thank you.