Python Bytes - #100 The big 100 with special guests

Episode Date: October 19, 2018

Topics covered in this episode: poetry Anthony * pylama *and radon Nina * *Tools for teaching Python Dan My favorite tool of 2018: “Black” code formatter by Łukasz Langa Brett * A Web without JavaScript*: Russell Keith-Magee at PyCon AU Async WebDriver implementation for asyncio and asyncio-compatible frameworks Extras Joke See the full show notes for this episode on the website at pythonbytes.fm/100

Hello and welcome to Python Bytes, where we deliver Python news and headlines directly to your earbuds. This is episode 100. Very exciting. Very exciting. Episode 100, recorded October 10th, 2018. I'm Michael Kennedy. And I'm Brian Arkin. Hey, Brian. It's not just us this time, is it? No, we've got some wonderful guests. Yeah. So I want to welcome Anthony Shaw, Dan Bader, Brett Cannon, and Nina Zankarenko to the show, all of whom have been on the show before, but have come here to help us celebrate.

Hello, everyone. Hey, and congratulations. Hi. Hi. Thank you. Thank you, Dan. It's great to have you all here to celebrate this big episode and go a little bit deeper on some of the topics.

It's going to be a lot of fun. So before we get to the first topic, really quickly want to say thank you to DigitalOcean who helped us reach this milestone. Check them out at pythonbytes.fm slash DigitalOcean. Get a $100 credit for new users. Brian, you want to kick off our first item with something poetic? Yeah, definitely. Poetry is a Python project that a lot of people have, since we've talked about packaging quite a few times, a lot of people have said, hey, you should check out Poetry. And I just finally got a chance to. I've been taking a look at it this week, and it's kind of cool, but it's a big, this topic is actually kind of a can of worms. There's essentially Poetry on its tagline. It says Poetry is a tool to handle dependency installation as well as building and packaging of Python packages.

And it all does it with one file, the pyproject.toml file. So that replaces the setup.py, the requirements.txt, setup.cfg, manifests, and even pip file. And that's where the can of worms comes in. So this is sort of like pipenv, but with a completely different file structure behind it. It does do virtual environment support as well. So it does a lot. I'm not sure. I was surprised that you can build packages and put them up on PyPI without a setup.py file anymore. Those aren't required, I don't think.

And I was surprised that... So these are also related to PEP 517 and 518. And surprisingly enough, I was surprised to find that BrightCannon was part of those as well. So I'd like to get Brad or somebody else's opinion or information about this. Yeah, so the PEPs that Brian's talking about, PEP 517, 518, 518 actually got finished first,

and that's what's defined the pyproject.toml file, which is originally written to provide a structured file for information required to build a package. So something you would upload to PyPI. It was not originally intended for projects. So not like your website or web app or something like that. And then subsequently, PEP 517 standardized what could go in the PyProject.toml to specify how to build your package. So this is why, Brian, you don't need setup.py anymore.

These two PIPs basically supersede the need for that by standardizing because setup.py has a problem of being executable code and being fairly tied to setup tools. This completely makes it independent, which lets you use projects such as Flit or Poetry to actually build your libraries. That's really interesting

because when you do a PIP install, Bretttt you're basically executing the setup.py which like you said it could just be you know here my dependencies please register them it could be you know install this horrible thing and format my hard drive right so now is now we have a safe way to pip install thing do you foresee a thing marking a package as having no executable code on install? Well, so you actually already have that anytime you install a wheel. So wheels are specifically designed

that it's essentially a unzipping and copying some files around. There is no actual code executed as part of the build. So only source distributions are the only time you ever actually are executing code like that. And you are right there as a potential security risk. Honestly, though, the really big benefit of moving away from executable code in a setup.py to something like a pyproject.toml is it allows for better introspection.

Because before this, if you wanted to take a package SDIS file, for instance, and figure out what dependencies it had, if you had the wheel, that's in a metadata file, it's no big deal. But if you only had the setup.py, you basically had to shim out setup tools or run setup tools and not have it run its install step to find out what its dependencies were programmatically. But with PyProject.toml and this sort of specification, it allows you to get away from that. Interesting. And one of the things I wanted to mention was just that if people are considering

whether to use PIPINV or in that route or Poetry, they're just, they're different workflows. And I would recommend people just try both of them out and see which workflow fits better for you. As far as I can tell from Brett's comments offline is that both of these PIPs are provisional, but they're probably not going to go away is it is it safe for me to convert my project to uh away from setup.py and use pyproject.toml

now or is there a risk that that'll go away no there's absolutely no risk it's going to go away this is the future of packaging in python to the point that we've actually i actually updated pep 518 maybe two months ago to take away the specification that it was meant for libraries and just to say it's a configuration file because actually when poetry started using pyproject.toml it kind of did it against the recommendation of the pep because the pep originally said it was designed for libraries and packages not for applications and they started to use it that way and other people such as black which i believe we'll maybe touch on later, also started to integrate with it and such, and

various other projects have, so we actually took away that wording. But the provisional just basically means we reserved the right to maybe tweak some of the wording requirements, but this is very squarely the future of Python packaging, so they're definitely not going anywhere. Okay, wonderful.

Does that mean that the person installing the package needs to have a specific version of pip? Like, to support the... Because setup.py is cool because it can work with, like, a really, really old version of pip, which is pretty common. So the new Toml file, does it need, like, the users to actually have a newer version of pip to work?

Yes. Only though, once again, if you're installing from a source distribution, which is once again, why wheels are so important, that if you had a wheel, all of this is completely mute. I mean, basically, this is just how to build a wheel. And even the way pip's workflow now is structured, is pip basically takes the sdisk, builds a wheel, and then installs that wheel. And that's actually what pip 5.1.7 specifies is an API to call into Python code of how to ask a build tool such as flit, for instance, or poetry.

Hey, can you build me a wheel? Okay, now that you have a wheel, can you help me install it potentially, or what have you? So it is only in the newer pips. I believe it was pipIP either 10 or 18 because they changed their numbering scheme recently. They added the support.

So it's only within like the last two versions that they've had it. But once again, if you have wheels, it's completely unnecessary technical detail. Dan, you were trying to jump in there. You know, I've never really heard before of the TOML format. And even the name is hilarious.

I think it's like, isn't this like Tom's format or something like that? Has like the name of the inventor in there somewhere. And I was just curious if this is something, I don't know, established or where, for me, it's sort of like out of the left field kind of format. And I was just wondering, you know,

if this is something, what makes it so awesome by comparison to JSON or YAML or whatever the other options were, I guess, a plain.ini file or something like that. I will say that there is a very long section in the PEP explaining all the reasons we did this. So we actually don't... I was going to ask, sorry, have you seen a TOML file?

I just started using Black more heavily, pretty much everywhere, and it required me to set up a TOML file. I was like, yeah, okay, it's pretty nice, pretty straightforward. Feels like in any file, it seems like it's a little bit different. So I was just curious. Yeah, I mean, compared to JSON

with all the extra curly brackets or even YAML gets pretty messy. I think it's a really nice format for configuration. Yeah, and one of the reasons we chose it is Rust has standardized on Toml for all their packaging details. So we actually reached out to them before we did this and said, hey, we noticed you've been using Toml, which some people call the only markup language to take the creator's name out of it. And they said they had no regrets. They really liked using it. And it was basically readable without any ambiguous corner cases.

And that was basically it, really. It was, as Nina said, JSON can be really messy to read if you don't format it well. YAML is decent, but there's also some execution problems if you're not careful. INI files are underspecified and really not specified in any way other than what the module in the standard library happens to say in ini files at least in the python community and then tom will just happen to be more well established and specified so i for one am excited about a new text format that doesn't let you execute python code just by putting exclamation marks

or something in it save float save. Safe load all the way. Yes, exactly. Or load safe, I always forget. Mina, do you use pipenv or Poetry, or are you just a straight pip and virtual environments person? I actually have not heard about Poetry before today, so I'll definitely be checking it out. But I use a mix of requirements.txt for simpler projects and pipenv

when things get more complex. Yeah, cool. I still haven't got my mind around pipenv. So I'm starting to wonder if maybe I should just learn poetry instead. So I'm pretty excited about this, actually. There's a pipenv integration in VS Code, and it's pretty nice. It takes a lot of thinking out of it. Oh, that's awesome. Yeah, awesome yeah very cool yeah anthony so you found a way to relate llamas to python is this correct yeah so tell us about it i've been looking into um tools for measuring code complexity so i guess the idea is that less is more so as an application grows as a code base code base grows over time you end up adding all these edge cases and unique customer requirements and stuff like that and the code gets can get more and more unmaintainable and complicated so there's a few ways of measuring the complexity of your code

and one tool that i came across was called radon. And it's a Python tool that leverages the AST, I guess the thing which is built into Python and which turns your code into a tree that it then executes. And one of the stats is called cyclomatic complexity, which is not unique to Python. It's used in other languages as well, but it kind of measures the number of decisions within your code base by iterating through the tree which is really cool that's

cool one way i like to think of cyclometric complexity is like if i'm going to test this code what is the minimum number of unit tests i have to have to actually test all the parts it's not exactly true but it's like a it's sort of true because you've got to go down each path, right? Yeah. The way I always think of it is when you go driving somewhere, how you always try and pick the route which requires the fewest number of left or right turns. So just going, even if it takes longer, it's an easier drive if you can just pick one road and stick to it rather than taking all these back roads and having to remember all the paths and stuff. So that's how I kind of think of cyclomatic complexity and the other one that they've got is a maintainability index which is a combination of the number of lines of code that

you have and also something called the house dead which is the number of operations in your ast so yeah basically radon is a tool that you can run over your code base and it'll tell you how complex the code is or a part of your code by adding a special visitor to the AST, which is really cool. And that's really cool. So I have no experience with the Radon. I know it has a gas that like leaks out of the ground that can be radioactive, but that doesn't have anything to do with llamas. What's the llama the llama so the llama is uh is another tool that i found which brings together radon and a whole bunch of other tools used for looking at the quality of your code in in air quotes so py code style py flakes it also includes a gjs lint

which is a fork of js lint which is a javascript linter i'm not sure why it includes a javascript linter i think the idea is that you run it over um django and other projects where you've got sort of nested javascript in your code and it can basically go and give you linting in your web applications on not just the python but on the javascript as well and it also includes another tool called McCabe, which is a project that Ned Batchelder put together, which is another way of measuring complexity by looking at the number of branches. So that's pretty cool. Yeah, my sort of final goal was to actually write a PyTest plugin that kind of benchmarks the complexity of your code in order to pass the tests and then the idea was that you could make the code the tests fail if someone has basically made the behavior

the same but the code more complicated that's really cool i love it so like if cyclometric complexity of any function gets above 10 just boom fail the build that's what you're thinking more than it was before. It would be really funny to plug this into a pre-commit hook where you just can't even commit your code. We reject it. It's too complicated.

Have you run this on one of your existing codebases? I have done previous tools and some other codebases. It's kind of yeah, how about you, Nina? Oh, throwing it back. I have done previous tools and some other code bases. It's kind of, yeah. How about you, Nina? Oh, throwing it back. I have not. Kind of just spews out a number and you're like,

okay, that's interesting. Is that good or bad? So it doesn't really mean anything unless you look at it historically, is what I found. And I've run a similar tool like this on.NET codebases and Java codebases, which can get extremely complicated, especially because every feature that ends up getting added

is basically just adding another if statement somewhere to deal with some weird edge case. Yeah, this is a really interesting one. I would like to propose another measure of complexity is the number of types involved in any particular function as well. But, yeah, it's cool. Brett, have you got any experience with any of this?

Not beyond the fact that PyLama is supported by the Python extension for VS Code. Oh, nice. Yeah, so built right into the editor there. That's cool. Nice. And so, Nina, the topic you want to cover is around teaching Python, which I think everybody on this call in some way or another is pretty actively involved in that. So tell us about your thing. Yeah, I'm going to be teaching a two-day workshop in spring of next year. And I was having a hard time kind of deciding on what tool I wanted to use and what workflow I wanted to use. Because when someone's just getting started with Python,

it comes with a lot of hurdles, like the virtual environments, installing Python 3, explaining why the Python that comes with your system isn't good enough, and pip, and working with the command line and all this stuff. And so I put out a call on Twitter asking what software and tools people use to teach Python. I will link to that in the show notes, but there are about 50 responses, 414 votes, and I learned about a lot of new tools from that thread. So of the 414 votes, 27% said they use Python or IPython in a REPL. Another 13% use the built-in IDLE, which I feel like a lot of people don't even know about. Yeah, that's true. There is a tool, it's janky, and it's baked into Python. 39% said they use an IDE or some other editor,

Visual Studio Code, PyCharm, Atom, and then 21% used other. So a mix of local and hosted Jupyter notebooks and a handful of other responses. So I just want to cover a few tools that I learned about and a few tools that I got reminded of. The first is the Mew editor. Have any of you used it? Yeah, it's really cool. Yeah. So it's just like a really simple Python editor. Really great for those who are completely new to programming and just an editor and then really large buttons at the top with some common actions. It's got support for a bunch of educational platforms like the Adafruit Circuit Playground, the Microbit, Pygame. There's a lot of really awesome tutorials. On the other side of the complexity scale, a few people clued me into the Neuron plugin for VS Code

and the Hydrogen plugin for Atom. And it kind of makes this really cool interactive coding environment in your editor. So little bits of Jupyter notebooks, you can like interactively run commands and see the output. You can have interactive charts and graphs displayed in your editor, import to and from Jupyter notebooks. So that one is geared a little bit more towards data scientists. I really liked that one. I had never heard of Neuron. I've heard of Hydrogen for Atom, and I was excited about it, but I didn't do anything. I don't really use Atom, but I do use VS Code sometimes. I'm like, oh, this is pretty cool. So it's like, it's sort of the general editing and the standard editing that you have in a regular text editor,

but then Jupyter-like things pop out of it, right? Like a graph or something. Yeah. And like a lot of interactivity. It looks really good. Yeah, it does. Nice. What else? Someone else told me about REPLIT, REPL.IT. And they have a project goal for zero effort setup. And they actually sent me a really interesting tweet that I liked. So I'll read it out to you. They said that we believe that the initial experience of programming should be the joy of writing and running code.

And delaying the setup pain is a good way to hook people and retain them to want to install locally. Because after all, setup is merely accidental complexity that we accepted as reality. That is cool. Yeah, very cool. This is good. Yeah, very cool.

Open source hosted Cloud REPL. The free tier is pretty reasonable. You don't have to log in or do anything. You can go to this site and get started right away. There's three vertical panes. There's one for files, one's your editor, and the next is your REPL. And then it's got some other really cool stuff built in, visual package installation. So you don't have to use PIP. You can search in a little text box and just click install, which is really nice. Right, it automatically generates a requirements.txt. Like, that's pretty cool. And then it also includes a debugger, which I don't know, I don't know how they make it work. But I love it. It's nice. Wow. Very cool.

Yeah. And the last one is B Python. So it's a different kind of command line interactive REPL. I've used it years ago, and I was surprised to hear that it was still an active project. But what B Python is, is a fancy curses interface to the Python interpreter. So you can get little pop-up boxes in your terminal and a lot of kind of really fancy UI elements, which is nice. It also supports type hints, expected parameter lists, and then you can do things like really easily reload imported modules. You can also rewind your session. And what that does is it pops the last line and then reruns the entire session and re-evaluates it but those are really cool features that i haven't seen anywhere else that's a super cool one then you have some honorable mentions as well right i do so i saw a talk at euro python from joshua low

have any of you met him i've not met him yeah we met him met him at the last PyCon. Nice. Okay. Yeah, he is 14 years old, which is amazing. But he's a brilliant developer, and he made this open source tool called Edublocks, which is kind of a Python version of Scratch. It's a tool for kids that lets you drag and drop code blocks and see it executed instantly. Open source, contribute to it, check out his website. I really love that project. Yeah, that's very cool. Very cool. All right, before we get to the next one, Dan,

I want to just tell you all about our sponsor, DigitalOcean. Thank you to DigitalOcean for making this show possible. Like I said previously, they've sponsored this entire show for the rest of the year. So thank you to them. That's great. And one of the features I want to tell you about that they're promoting these days is to bring your own image to DigitalOcean. You've heard about bringing your own device. Well, in the cloud world,

that's bringing your own image. So you can go and create a virtual machine, a Linux, some kind of Linux distribution exactly like you want it, and then just upload that image and then press a button and create new droplets based on that. So really cool. Check them out at pythonbytes.fm slash digital ocean, get $100 credit for new users. And yeah, it's great. It's been working well for us and definitely recommend them. So Dan, the one that you'd like to bring up is already got a little bit of a cameo earlier, right? Yeah, I just love this tool. So I've become a huge fan of the black code formatter by Lukasz Lange. And well, what's a code formatter? It's basically a tool you run on a Python source file, and it reformats it according to a built in code style.

It's sort of like PEP eight, but PEP 8 isn't super comprehensive, so it's ambiguous to a certain degree. So Black just makes a decision for you and reformats your code. With this sort of tool, it's always like a love and hate relationship, I think, because if you agree with

the reformatting, then it can be great. It's awesome. You just write your code however you like, and then you reformat it, and boom,, it looks consistent at least. But if you don't like it, or you have other idiosyncrasies that you want to keep, then that doesn't work out so great. And so with Black, I found that it's actually the first tool that I have sort of developed this blind trust for. So I pretty much started using it for everything now. And I like the way it formats my code. It pretty much always figures out some formatting solution that I like. And it's just a really, really cool tool. And I think it just came out in 2018. I actually heard about it on Python

bytes earlier this year. And I think Brian, you found it in episode 73. Get my notes here. And it's just an amazing tool. And the nice thing is, besides all of the auto formatting business, you can also use it to check the formatting of an existing project or just a single file. So where this is nice, and this kind of touches on some of the code quality tools that we had talked about earlier, is that you can integrate that with your continuous integration pipeline and then make sure that any new code this just takes away all of the formatting back and forth. You know, it's so easy to get sucked into a conversation of like, oh, I'm reviewing your code here. Actually, I think this works really well.

You know, your 5000 line change. It's awesome. But I would really change all of these, the single quote strings to double quotes or something like that. It just gets rid of all of these non-productive conversations and just make sure everybody uses the same formatting. I love it. Yeah, that's awesome.

Another one of the problems you have in these teams is if you have different formatting rules and you can run, you know, like format my code options, like VS Code or PyCharm or something, and you have different ones, they can fight inversion control, right? Like this one changes, this one changes it back, this one changes it, this one changes it back.

So I can just hear Nina's voice saying, that should be a pre-commit hook. And then everyone's is the same, right? What hear Nina's voice saying, that should be a pre-commit hook. And then everyone's is the same, right? What do you think, Nina? Should it be a pre-commit hook? Yeah, I love pre-commit hooks. Absolutely. That's awesome.

Brett, I wanted to ask you, what do you guys do on the core dev team for this problem? Lots of handwork. It's all manual. Basically, we don't have any tools specifically to actually maintain this. More or less, all the core devs have just internalized PetBait almost as much as you possibly can. We can just spot code that doesn't quite meet it, even though PetBait is not as rigorously defined as it potentially could be. The idea has come up about actually adopting black as an official formatter, but due to the current governance situation, that hasn't really gone anywhere. But I wouldn't be shocked if Lukasz, who is a core dev, brings that up in the future as a way to kind of make black a more or less official formatter for the language somehow.

Yeah, that's cool, especially since Lukasz is actually, you know, he created black and he's a core developer who's very active. It would be not unreasonable to say we just run Black against everything. Yeah, it's just the trick of can you get enough core developers to say Black's output is pretty instead of ugly? And you can probably pull that off. But obviously formatting, much like naming, is a very opinionated subject and it's hard to get agreement on that. It's like asking everybody to use the

same editor. Somebody will be happy, but you know, somebody's going to be really unhappy about that. One really nice thing about these tools like Black is because they're external to specific editors, being able to standardize them does help allow people to use whatever tool or editor that they want. Yeah, absolutely. Absolutely. Very cool. Well, one of the themes of the last PyCon, Brett, was one of the places where Python belongs but is not really is on the web, on the client side of the web, right? Yeah. Dan Callahan had a whole keynote kind of talking about Python and where it's been and where it could potentially go. And one of his key points was Python was not really on the web as I think some of us wish it could be. Yeah. But you have your next item is about trying to make that a bit more of a reality, right?

Yeah. So at PyCon Australia, Russell Keith McGee, who heads up the P-Ware project, gave a whole talk entitled A Web Without JavaScript, where Russell basically points out that JavaScript more or less has a monopoly on client-side programming, which is always kind of a not great thing because you never want a specific monopoly because it's highly restrictive. It makes innovation and growth hard and various other usual reasons you don't want it. So Russell gave a whole talk about the various approaches that currently exist for trying to get Python into the browser. And he did it by using an example the way through his talk, where he implemented what's called, I think you pronounce it, the Loon algorithm. It's basically a way to check some credit card numbers. And when he implemented it, it was only like 0.4 kilobytes, so really small. And then he just subsequently

wrote it in Python and ran through all the ways you can do it. And it ranged from 32 kilobytes for transcript, which transpiles Python into JavaScript, to Brython, which is a Python compiler written in JavaScript, which had 0.5 kilobytes for source because it's just Python, but had a 646 kilobyte bootstrap. Batavia, which is Russell's project that basically implements the eval loop for Python, which had a 1.2 kilobyte bytecode size, because it literally executes Python bytecode, but it has a 5 megabyte bootstrap. And then Pyodide, which is the CPython compiled down to Wasm,

which is WebAssembly, which is kind of being viewed by some as the future way of handling this kind of problem. I'm very excited about Pyodide. Yeah, well, it's a really cool idea. Unfortunately, while the code was still just 0.5 kilobytes for the Python code, the bootstrap's 3 megabytes, so it's still kind of large.

But it is a nice way to short-circuit getting going, because if you can just take CPython and just literally compile it straight to WebAssembly, there's no reimplementation of anything, right? Like Batavia and Brython and Transcript are all big projects that are having to basically reimplement Python in one way or the other. Well, Pyodide just said, like, well, let's just take CPython and just make it work. Right, compile it to Wasm and then ship it. Exactly. which I think is why some people at least are hopeful Wasm could somehow do this, whether that's writing a Python compiler straight to Wasm

so we can maybe ditch the bootstrap situation or what, I don't know. The other thing for me is my interest in this is as a VS Code extension developer, because that's all in TypeScript. So this and VS Code is an Electron app. So for situations where download size isn't quite as critical, something like PioDyte actually starts to become potentially feasible because shipping three megs as part of a hundreds of megabyte app is not a big deal. Yeah, that's where you're right. That's where it gets

super exciting because these things were like you say, where you say, oh, that's three megs. That's five megs of JavaScript. That's way too much. That's true when you're getting it off the web per request, at least per session. But if it's, like you said, shipped and it just runs in the Chrome that powers the whole Electron system, well, then it's no big deal, right? Exactly. And then at that point, it's a question of which one gives the best Python to JavaScript bridge and vice versa. And they all have different levels for that

based on how they're implemented. But for me, I think there's an opportunity here to not only come up with a solution that has good bridging, that can work in a Electron or Node situation to get Python there, but then also to potentially look at WebAssembly and see if there's a way to do like a Python compiler

straight to WebAssembly and then have that be the way we target Python client side and try to keep that number down. Yeah, that's super cool. Have you heard about Python Electron? Electron Python? I can't remember which way it goes. Yes, I have passively seen it because I've asked on Twitter a couple times, like, I really

want this. Like, I want to write the Python extension vs code in python someday so i can't i eric snow who's the core dev and also a teammate of mine we occasionally bounce this idea back and forth and it sometimes leaks onto twitter and we dream in blue skies and yeah and people have brought up uh python uh electron before very cool how about the rest of you folks have you Have you heard about Pyodide or people doing interesting things with some of these others? What are your thoughts?

We recently added two interactive coding exercises to real Python. So there's quizzes and parts of them are, you know, solve this, like implement this little loop or whatever.

And that's actually implemented in Brython. And so it compiles your Python code to JavaScript locally on the client and then runs that. And it's actually been a pretty cool experience. It's not 100% compatible. So it's sort of like Python 3.7-ish. And so you run into these funny edge cases, which is interesting because, well, people are trying to learn Python. And what are they really learning with these exercises? But for the most part, it's, it's pretty accurate. And performance wise, it works pretty well too. So on a fast

connection, you know, when that bootstrap doesn't hit you that hard, it works quite well on mobile too. The only thing I found where it's really starting to just churn the CPU is when you load in a bunch of stuff from their standard library. So we have the option to validate your code using reg access. And when you import RE, then it can take, I don't know, you know, five seconds on even on a notebook. And that's not ideal. But I think for a use case like that, where you have to user type in code, for us, it works really quite well.

I'm not sure if I would want to rewrite like all of the front end JavaScript, just a part of that's part of the website but for a code runner or code exercise tool i think it works quite well yeah that sounds like a really cool use and you don't have to worry about the security it's not like i'm taking their code and running it and trying to do that in docker or something like just hope my server doesn't get messed up from this we'll try it the only thing you can break is your browser so i've hacked myself i'm a hacker awesome how about the rest thing you can break is your browser I've hacked myself I'm a hacker

awesome how about the rest of you no I've not checked it out but there's a couple of other links I'd recommend people look at one is

Scott Hanselman's blog post on JavaScript as the assembly of the web which is really interesting and paints some good context

and then also from Scott there's an interview on Hanselman, it's podcast between him and Patricia Ors. And that kind of covers off like the history of JavaScript engines and runtimes and also helps kind of explain

why things the way are the way they are, which is really interesting to give you context as well. So yeah, it's cool. And, you know, speaking of Scott Hanselman, they're doing really interesting stuff with WebAssembly and the.NET CLR with Blazor. I mean, if the Python community could just do that same thing, and it looks like Pyodide is very close, but that's more focused

on data science instead of SPAS front-end JavaScript stuff. So there's definitely some interesting stuff happening there. I'd also recommend if you haven't watched Dan Callahead's keynote from PyCon that you do. It's really good. Yeah, that's a great recommendation. All right. WebAssembly, it's going to make things amazing. I'm looking forward to it. All right. So we're down to our last item and this one is mine. So I'll kick it off. So you all have heard of Selenium, right? You can automate browsers and do web testing and stuff with it. Yeah. So if I wanted to use that in an async and await, in an async method, as in async def, I'm going to call a Selenium thing, there is no async option for that. And they actually talked about it on GitHub and decided they weren't going to do it because there's this other project, which I had never heard of, called Arsenic, Arsenic, I guess, something like that.

And it's an async version of, well, basically selenium. So if you're writing any async code, code that you're interacting with a bunch of sites, you're testing them or something like this, you could do it in an async IO event loop very easily with this other project. So it's quite cool. I'm going to definitely have to check that out. That is interesting. Yeah. So I come in here and like, I could create one of these sessions and say, I'd like to use the Firefox browser to do this. And then I'm going to await getting a page.

And then I could actually say like await session dot wait for element like H1. And so you can say, you know, sort of put your part of the event loop to sleep until the element, you know, H1 appears and you can get the title from it and stuff. It's really quite neat. Yeah. So they say, you know, this is good for load testing, good for automated testing of websites. You know, if you want to say like, well, we have the CMS and people can just type stuff into it, but let's make sure there's no broken links, right? Something like that.

And it uses real web browsers. So it's really using Firefox in a hidden form to do this. So it's pretty cool. Very nice for testing, I think. Yeah. Headless browsers are awesome. And it has a PyTest. It works with PyTest. So it's pretty cool. Very nice for testing, I think. Yeah, headless browsers are awesome. And it has a PyTest. It works with PyTest.

That's cool. Yeah, it has a special PyTest support, which is cool. So I guess, you know, this is an interesting thing for people who want to automate the web and they're doing it asynchronously. And often that's like one of the times where AsyncIO is really helpful because you're just waiting on other servers anyway.

So you can blaze through that. But maybe just throw it out to you all. What are your thoughts on Async these days? Async await and all that stuff brett maybe start with you because you're on the inside and i know you've blogged on this yeah i was gonna say which makes me obviously extremely biased on the topic so i think async's great i appreciate personally how we designed it because it's we haven't tied ourselves to a specific event loop, which has allowed some experimentation, such as Trio and Curio,

while AsyncIO has continued to evolve and learn from them. Like I know Yuri Solonov has pulled a lot of ideas from Nathaniel Smith of Trio into AsyncIO. And so there's been a nice feedback loop on that level of experimentation. So I'm very positive on it. I wrote an entire GitHub API library based on async because I thought it was so great. So yeah, that's right.

And we've covered that in the show before, but I don't remember the number. I'm afraid. I don't know. I think Dan brought it up. Oh, yeah. That's right. Dan did bring it up. I don't remember the number either, though.

But man, so many episodes. I'll tell you, it's less than 100. It's either 99 or below that. We put a bound on on it how's this he's think the rest of you guys no nothing i'm i still find async in a way very confusing and the attempts that i've um had at using it i've just ended up making a mess and causing bugs that i don't understand they can't debug so i just kind of gave up which is pretty sad but i'm gonna going to watch your course, Mike, at some point. Thanks. I need to allocate the time.

There you go. You know, the whole threading world, there's a phrase for the bugs that are like race condition stuff called Heisenbugs. And I just love that terminology. I run into a few of those. For those who don't know, a Heisenbug only appears when you're not looking at it.

That's right. You observe it, it changes it too late. Yeah. Yeah, very cool. All right. Well, people out there, if you need to do some sort of automation and you were going to use Selenium, definitely check out Arsenic because you can do it more in parallel if you're doing more than one sort of flow through your tests.

It does say be careful, though, because while you can asynchronously start calling functions, you're interacting with like a hidden real browser, which itself can't do more than one thing at a time. And so, you know, it's more for, I want to test a bunch of links or a bunch of paths, not I'm trying to make this one sequence of events go faster. That probably won't work so well. Yeah, check out Selenium Grid if you want to do that.

If you want to do multiple machines and multiple browsers at the same time. Is that grid computing for Selenium? Kind of, yeah. Oh man, that's pretty awesome. All right, well, let's leave it there for our main topics. So thank you everyone for bringing these and sharing them with everyone. They were super interesting. Normally, I just ask Brian if he has anything else to share, but I know we got more than that. So we'll just go down the list here. I'll throw mine out first. So hopefully this is not out too late to make this useful, but the PSF and JetBrains last year teamed up to do the most comprehensive survey of the Python community they could. And that is now

happening again this year. So just visit talkpython.fm slash survey2018 and take that. But if you hear this, do that as soon as possible because there's only a week or two left of it being open. So, all right, Anthony, you got one you'd like to share. Yeah, 3.7.1 is around the corner. The first release candidate came out a week ago. So if you're running on 3.7 and you want to try to see if any of the bugs that you may have come across have been fixed. And take a look through the release notes. And then the next one is that on the topic of Python packaging, there's a great article that I've linked to in the show notes.

And talking about the whole landscape and the comparisons with Flit and Poetry and Pipend and the reasons behind them. It's a really in-depth piece and I think it's worth a good read. That's awesome. I definitely think some comparison and exploration is needed because there's just so many ways to start solving this problem these days. But I think something will emerge, and I'm kind of hopeful for poetry, actually. Nina, how about you? I have a few things as well. We brought up VS Code a few times during the podcast,

and there's a new September release of the Python extension for VS Code, and there are lots of new features, automatic environment activation in the terminal, some debugging improvements, and a lot more. So you can check out the blog post in the show notes for some more information. Brett, I don't know why you're being so shy. You should be the one bringing this up. That's fine. And then there's one more thing I wanted to mention. PyCascades is a really nice, smaller Python conference that's happening February of 2019 in Seattle.

And right now the call for proposals is open. It closes on October 21st. So you should still hopefully have a little bit of time. And they're doing something great that I haven't seen from too many conferences before, which is offering mentorship. Yeah, this is for like new speakers and stuff who maybe want to speak, but they're like, I've never done this.

I'm a little unsure that this is actually a good idea. Could really use some help, that type of thing. Yeah. Yeah, it's really great. I've been volunteering as a mentor and it's been a really rewarding experience to kind of coach people through all their fears because at the end of the day we can all speak at a python conference yeah absolutely

that's awesome i'm glad you brought those up i've already booked my travel and submitted three talks and i even put brian's name on one so he has to come now too awesome last year was my favorite conference probably potentially ever was the inauguralago Pipe Cascades. So you should definitely go if you can make it. I agree. That was up in Vancouver where you and Dan are. But this time it's moving down to Seattle. And then later it comes to visit us here in Portland.

So I think it's a great one as well, Brett. That's right. 2020. That's right. It'll be here. I'll drive. I won't have to stay at a hotel. It'll be great.

All right. The rest of you, anything else? Dan, Brian, you want to share anything before we hit the road? I just want to say the upcoming, I've got a recording with a guy named Anthony Shaw. Oh, that guy. Yeah. I've heard he's good on the podcast. Yeah.

We're going to talk about flaky tests on testing code. So that should be fun. Right on. Dan, anything? No, I got nothing. I hope you invite me back for episode 200. Yeah, you all already have an invite. We'll be there in just about two years.

So you all hang in there and we'll do this again. Thank you all for coming. This was really great. And thanks for help with the show throughout the last two years and today, of course. Thanks for having us. Thanks for doing this. And congrats again. Thanks.

Bye, everyone. And Brian, special thanks. You've been here for all 100 of them. Well, maybe 99 because we each bowed out at one or two, but that's all good. Yeah. All right. Thanks, man. Bye, everyone. Thanks. Bye. Bye. Bye. Thank you for listening to Python Bytes. Follow the show on Twitter via at Python Bytes. That's Python Bytes as in B-Y-T-E-S. And get the full show notes at PythonBytes.fm. If you have a news item you want featured, just visit pythonbytes.fm and send it our way. We're always on the lookout for sharing

something cool. On behalf of myself and Brian Auchin, this is Michael Kennedy. Thank you for listening and sharing this podcast with your friends and colleagues.