Transcript #100: The big 100 with special guests

00:00 Hello and welcome to Python Bytes, where we deliver Python news and headlines directly

00:04 to your earbuds. This is episode 100. Very exciting, very exciting. Episode 100,

00:10 recorded October 10th, 2018. I'm Michael Kennedy.

00:14 And I'm Brian Arkin.

00:15 Hey, Brian. It's not just us this time, is it?

00:17 No, we've got some wonderful guests.

00:18 Yeah, so I want to welcome Anthony Shaw, Dan Bader, Brett Cannon, and Nina Zankarenko

00:24 to the show, all of whom have been on the show before, but have come here to help us celebrate.

00:30 Hello, everyone.

00:31 Hey, and congratulations.

00:32 Hi.

00:33 Hi. Thank you. Thank you, Dan. It's great to have you all here to celebrate this big episode

00:39 and go a little bit deeper on some of the topics. It's going to be a lot of fun.

00:42 So before we get to the first topic, really quickly, I want to say thank you to DigitalOcean

00:47 who helped us reach this milestone. Check them out at pythonbytes.fm.com. Get a $100 credit

00:53 for new users. Brian, you want to kick off our first item with something poetic?

00:58 Yeah, definitely. Poetry is a Python project that a lot of people have, since we've talked

01:05 about packaging quite a few times, a lot of people have said, hey, you should check out

01:09 poetry. And I just finally got a chance to. I've been taking a look at it this week. And

01:16 it's kind of cool, but it's a big, this topic is actually kind of a can of worms. There's

01:22 essentially poetry on its tagline. It says poetry is a tool to handle dependency installation,

01:28 as well as building and packaging of Python packages. And it all does it with one file,

01:34 the pyproject.toml file. So that replaces the setup.py, the requirements.txt, setup.cfg,

01:41 manifests, and even pipfile. And that's where the can of worms comes in. So this is sort of like

01:48 pipenv, but with a completely different file structure behind it. It does do virtual environment

01:55 support as well. So it does a lot. I'm not sure. I was surprised that you can build packages and put

02:01 them up on PyPI without a setup.py file anymore. Those aren't required, I don't think.

02:09 And I was surprised that, so these are also related to PEP 517 and 518. And surprisingly enough,

02:17 I was surprised to find that Brett Cannon was part of those as well. So I actually could,

02:23 I'd like to get Brett or somebody else's opinion or information about this.

02:28 Yeah, so the PEPs that Brian's talking about, PEP 517, 518, 518 actually got finished first. And that's

02:36 what's defined the pyproject.toml file, which is originally written to provide a structured file

02:42 for information required to build a package. So something you would upload to PyPI. It was not

02:49 originally intended for projects. So not like your website or web app or something like that.

02:55 And then subsequently, PEP 517 standardized what could go in the pyproject.toml to specify

03:01 how to build your package. So this is why, Brian, you don't need setup.py anymore.

03:06 These two PEPs basically supersede the deed for that by standardizing. Because setup.py has a problem

03:13 of being executable code and being fairly tied to setup tools. This completely makes it independent,

03:18 which lets you use projects such as Flit or Poetry to actually build your libraries.

03:23 That's really interesting. Because when you do a pip install, Brett, you're basically executing

03:28 the setup.py, which like you said, it could just be, you know, here are my dependencies,

03:33 please register. It could be, you know, install this horrible thing and format my hard drive,

03:37 right? So now we have a safe way to pip install a thing. Do you foresee a thing marking a package as

03:45 having no executable code on install?

03:48 Well, so you actually already have that anytime you install a wheel. So wheels are specifically designed that it's

03:54 essentially a unzipping and copying some files around. There is no actual code executed as part of the build.

04:00 So only source, or SDS, source distributions are the only time you ever actually are executing code like that.

04:06 And you are right there is a potential security risk. Honestly, though, the really big benefit of moving away from executable code

04:13 and a setup.py to something like a pyproject.toml is it allows for better introspection.

04:17 Because before this, if you wanted to take a package, SDS file, for instance, and figure out what dependencies it had,

04:24 if you had the wheel, that's in a metadata file as no big deal. But if you only had the setup.py,

04:28 you basically had to shim out setup tools or run setup tools and not have it run its install step to find out what

04:35 dependencies were programmatically. But with pyproject.toml and this sort of specification, it allows you to get away from that.

04:41 Interesting.

04:42 And one of the things I wanted to mention was just that if people are considering whether to use pipenv or

04:47 in that route or poetry, they're just, they're different workflows.

04:52 And I would recommend people just try both of them out and see which workflow fits better for you.

04:57 As far as I can tell from Brett's comments offline is that both of these peps are provisional, but they're probably not going to go away.

05:05 Is it safe for me to convert my project to away from setup.py and use pyproject.toml now?

05:12 Or is there a risk that that'll go away?

05:14 No, there's absolutely no risk it's going to go away.

05:16 This is the future of packaging in Python to the point that we've actually, I actually updated PEP 518

05:21 maybe two months ago to take away the specification that it was meant for libraries and just to say it's a configuration file.

05:27 Because actually when poetry started using pyproject.toml, it kind of did it against the recommendation of the pep.

05:33 Because the PEP originally said it was designed for libraries and packages, not for applications.

05:38 And they started to use it that way.

05:40 And other people, such as black, which I believe we'll maybe touch on later, also started to integrate with it and such.

05:47 And various other projects have.

05:49 So we actually took away that wording.

05:50 But the provisional just basically means we reserve the right to maybe tweak some of the wording requirements.

05:56 But this is very squarely the future of Python packaging.

06:00 So they're definitely not going anywhere.

06:02 Okay, wonderful.

06:03 Yeah, very cool.

06:04 Does that mean that the person installing the package needs to have a specific version of pip?

06:11 To support the...

06:14 Because setup.py is cool because it can work with a really, really old version of pip, which is pretty common.

06:20 So the new toml file, does it need the users to actually have a newer version of pip to work?

06:26 Yes.

06:27 Only though, once again, if you're installing it from a source distribution, which is once again why wheels are so important,

06:32 that if you add a wheel, all of this is completely mute.

06:35 I mean, basically, this is just how to build a wheel.

06:38 And even the way pip's workflow now is structured, is pip basically takes the sdisk, builds a wheel, and then installs that wheel.

06:45 And that's actually what pip 517 specifies is an API to call into Python code of how to ask a build tool such as Flit, for instance, or Poetry.

06:53 Hey, can you build me a wheel?

06:55 Okay, now that you have a wheel, can you help me install it potentially or what have you?

06:59 So it is only in the newer pips.

07:03 I believe it was pip either 10 or 18 because they changed the numbering scheme recently.

07:09 They added the support.

07:10 So it's only within like the last two versions that they've had it.

07:13 But once again, if you have wheels, it's completely unnecessary technical detail.

07:17 Okay.

07:17 Dan, you were trying to jump in there.

07:18 You know, I've never really heard before of the Toml format.

07:22 And even the name is hilarious.

07:24 I think it's like, isn't this like Tom's format or something like that?

07:26 It has like the name of the inventor in there somewhere.

07:29 And I'm 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.

07:36 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 any file or something like that.

07:46 I will say that there's a very long section in the PEP explaining all the reasons we did this.

07:52 So we actually don't.

07:54 I was going to ask.

07:55 Sorry.

07:56 Have you seen a Toml file?

07:58 I just started using black more heavily, pretty much everywhere.

08:02 And it required me to set up a Toml file.

08:04 And I was like, yeah, okay.

08:05 It's pretty nice.

08:06 Pretty straightforward.

08:07 Feels like in any file.

08:08 It seems like it's a little bit different.

08:10 So I was just curious.

08:11 Yeah, I mean, compared to JSON with all the extra curly brackets or even YAML gets pretty messy.

08:17 I think it's a really nice format for configuration.

08:20 Yeah.

08:21 And one of the reasons we chose it is Rust to standardize on Toml for all their packaging details.

08:25 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.

08:36 And they said they had no regrets.

08:38 They really liked using it.

08:40 And it was basically readable without any ambiguous corner cases.

08:46 And that was basically it, really.

08:50 It was, as Nina said, JSONs can be really messy to read if you don't format it well.

08:55 YAML is decent.

08:57 But there's also some execution problems if you're not careful.

09:01 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.

09:10 And then Toml just happens to be more well established and specified.

09:14 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.

09:22 Safe load.

09:25 Safe load all the way.

09:26 Yes, exactly.

09:27 Or load safe.

09:28 I always forget.

09:29 Nina, do you use pip.inf or poetry?

09:32 Or are you just a straight pip and virtual environments person?

09:37 I actually have not heard about poetry before today.

09:39 So I'll definitely be checking it out.

09:41 But I use a mix of requirements.txt for simpler projects and pip.inf when things get more complex.

09:47 Yeah, cool.

09:48 I still haven't got my mind around pip.inf.

09:50 So I'm starting to wonder if maybe I should just learn poetry instead.

09:53 So I'm pretty excited about this, actually.

09:55 There's a pip.inf integration in VS Code.

09:59 And it's pretty nice.

10:00 It takes a lot of the thinking out of it.

10:01 Oh, that's awesome.

10:02 Yeah, very cool.

10:03 Yeah.

10:03 Anthony, so you found a way to relate llamas to Python.

10:08 Is this correct?

10:08 Yeah.

10:09 So I've been looking into tools for measuring code complexity.

10:17 So I guess the idea is that less is more.

10:19 So as an application grows, as a code base grows over time, you end up adding all these edge cases and unique customer requirements and stuff like that.

10:30 And the code can get more and more unmaintainable and complicated.

10:34 So there's a few ways of measuring the complexity of your code.

10:39 And one tool that I came across was called Radon.

10:43 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.

10:55 And one of the stats is called cyclomatic complexity, which is not unique to Python.

11:01 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.

11:10 That's cool.

11:11 One way I like to think of cyclomatic 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?

11:19 It's not exactly true, but it's sort of true because you've got to go down each path, right?

11:24 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.

11:34 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.

11:45 So that's how I kind of think of cyclomatic complexity.

11:48 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.

11:55 And also something called the house dead, which is the number of operations in your AST.

12:00 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.

12:12 And that's really cool.

12:13 So I have no experience with the radon.

12:15 I know it as a gas that like leaks out of the ground.

12:17 That can be radioactive, but that doesn't have anything to do with llamas.

12:21 What's the pi llama?

12:22 The llama.

12:23 So the llama 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 air quotes.

12:35 So pi code style, pi flakes.

12:38 It also includes gjs lint, which is a fork of js lint, which is a JavaScript linter.

12:44 I'm not sure why it includes a JavaScript linter.

12:47 I think the idea is that you run it over 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.

13:02 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.

13:12 So that's pretty cool.

13:15 Yeah, my sort of final goal was to actually write a pi test plugin that kind of benchmarks the complexity of your code in order to pass the tests.

13:25 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.

13:33 That's really cool.

13:34 I love it.

13:35 So like if cyclomatic complexity of any function gets above 10, just boom, fail the build.

13:40 That's what you're thinking.

13:42 More than it was before.

13:45 It would be really funny to plug this into a pre-commit hook where you just can't even commit your code.

13:50 We reject it.

13:53 It's too complicated.

13:54 So have you run this on one of your existing code bases?

13:58 I have done previous tools and some other code bases.

14:02 It's kind of, yeah.

14:04 How about you, Nina?

14:05 Oh, throwing it back.

14:09 I have not.

14:11 Kind of just spews out a number and you're like, okay, that's interesting.

14:14 Is that good or bad?

14:16 So it doesn't really mean anything unless you look at it historically is what I found.

14:21 And I've run a similar tool like this on .NET code bases and Java code bases, which can get extremely complicated, especially because like every feature that ends up getting added is basically just adding another if statement somewhere to deal with some weird edge case.

14:38 Yeah.

14:38 Yeah.

14:38 This is a really interesting one.

14:40 I would like to propose another measure of complexity is the number of types involved in any particular function as well.

14:46 But yeah, it's cool.

14:48 Brett, have you got any experience with any of this?

14:50 Not beyond the fact that PyLama is supported by the Python extension for VS Code.

14:55 Oh, nice.

14:55 Yeah.

14:56 So built right into the editor there.

14:57 That's cool.

14:58 Nice.

15:00 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.

15:10 So tell us about your thing.

15:12 Yeah, I'm going to be teaching a two-day workshop in spring of next year.

15:16 And I was having a hard time kind of deciding on what tool I wanted to use and what workflow I wanted to use.

15:22 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.

15:37 And so I put out a call on Twitter asking what software and tools people use to teach Python.

15:42 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.

15:51 So of the 414 votes, 27% said they use Python or IPython in a REPL.

15:57 Another 13% use the built-in IDLE, which I feel like a lot of people don't even know about.

16:04 Yeah, that's true.

16:05 There is a tool.

16:06 It's janky.

16:07 And it's baked into Python.

16:09 39% said they use an IDE or some other editor, Visual Studio Code, PyCharm, Atom.

16:15 And then 21% used other, so a mix of local and hosted Jupyter notebooks and a handful of other responses.

16:23 So I just want to cover a few tools that I learned about and a few tools that I got reminded of.

16:29 The first is the Mew editor.

16:31 Have any of you used it?

16:33 Yeah, it's really cool.

16:35 Yeah.

16:36 So it's just like a really simple Python editor, really great for those who are completely new to programming.

16:41 It's just an editor and then really large buttons at the top with some common actions.

16:46 It's got support for a bunch of educational platforms like the Adafruit Circuit Playground, the Microbit, PyGame.

16:52 There's a lot of really awesome tutorials.

16:54 On the other side of the other side of the other side of the other side of the Python plugin for VS Code and the Hydrogen plugin for Atom.

17:03 And it kind of makes this really cool interactive coding environment in your editor.

17:08 So little bits of Jupyter notebooks.

17:11 You can interactively run commands and see the output.

17:14 You can have interactive charts and graphs displayed in your editor.

17:18 Import to and from Jupyter notebooks.

17:21 So that one is geared a little bit more towards data scientists.

17:24 I really like that one.

17:25 I had never heard of Neuron.

17:26 I've heard of Hydrogen for Atom and I was excited about it, but I didn't do anything.

17:31 I don't really use Atom, but I do use VS Code sometimes.

17:34 I'm like, oh, this is pretty cool.

17:35 So it's like it's sort of the general editing, the standard editing you have in a regular text editor, but then Jupyter-like things pop out of it, right?

17:44 Like a graph or something.

17:45 Yeah, and like a lot of interactivity.

17:47 It looks really good.

17:49 Yeah, it does.

17:49 Nice.

17:50 What else?

17:51 Someone else told me about REPL.IT, REPL.IT, and they have a project goal for zero effort setup.

17:59 And they actually sent me a really interesting tweet that I liked, so I'll read it out to you.

18:04 They said that we believe that the initial experience of programming should be the joy of writing and running code.

18:10 And delaying the setup pane is a good way to hook people and retain them to want to install locally.

18:15 Because after all, setup is merely accidental complexity that we accepted as reality.

18:20 That is cool.

18:21 Yeah, very cool.

18:22 That is good, right?

18:23 Yeah, very cool.

18:23 Open source hosted Cloud REPL.

18:25 The free tier is pretty reasonable.

18:27 You don't have to log in or do anything.

18:30 You can go to this site and get started right away.

18:32 There's three vertical panes.

18:34 There's one for files, one's your editor, and the next is your REPL.

18:38 And then it's got some other really cool stuff built in.

18:41 Visual package installation.

18:43 So you don't have to use PIP.

18:44 You can search in a little text box and just click install, which is really nice.

18:48 Great for new users.

18:50 Right?

18:51 It automatically generates a requirements.txt.

18:54 Like, that's pretty cool.

18:57 And then it also includes a debugger, which I don't know.

19:00 I don't know how they make it work, but I love it.

19:03 It's nice.

19:04 Wow.

19:04 Very cool.

19:05 Yeah.

19:05 And the last one is BPython.

19:08 So it's a different kind of command line interactive REPL.

19:11 I've used it years ago, and I was surprised to hear that it was still an active project.

19:16 But what BPython is, is a fancy cursive interface to the Python interpreter.

19:22 So you can get little pop-up boxes in your terminal and a lot of kind of really fancy UI elements, which is nice.

19:30 It also supports type hints, expected parameter lists.

19:33 And then you can do things like really easily reload imported modules.

19:37 You can also rewind your session.

19:40 And what that does is it pops the last line and then reruns the entire session and reevaluates it.

19:46 But those are really cool features that I haven't seen anywhere else.

19:50 That's a super cool one.

19:51 Then you have some honorable mentions as well, right?

19:53 I do.

19:54 So I saw a talk at EuroPython from Joshua Lowe.

19:58 Have any of you met him?

20:00 I've not met him.

20:01 Yeah, we met him at the last Python.

20:03 Nice.

20:04 Okay.

20:04 Yeah, he is 14 years old, which is amazing.

20:09 But he's a brilliant developer, and he made this open source tool called EduBlocks, which is kind of a Python version of Scratch.

20:17 It's a tool for kids that lets you drag and drop code blocks and see it executed instantly.

20:23 Open source, contribute to it.

20:25 Check out his website.

20:27 I really love that project.

20:28 Yeah, that's very cool.

20:29 Very cool.

20:29 All right.

20:30 Before we get to the next one, Dan, I want to just tell you all about our sponsor, DigitalOcean.

20:35 Thank you to DigitalOcean for making this show possible.

20:38 Like I said, previously, they've sponsored this entire show for the rest of the year.

20:43 So thank you to them.

20:44 That's great.

20:45 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.

20:52 You've heard about bring your own device.

20:54 Well, in the cloud world, that's bring your own image.

20:56 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.

21:05 So really cool.

21:07 Check them out at pythonbytes.fm/DigitalOcean.

21:09 Get $100 credit for new users.

21:11 And, yeah, it's great.

21:13 It's been working well for us, and I definitely recommend them.

21:17 So, Dan, the one that you'd like to bring up has already got a little bit of a cameo earlier, right?

21:22 Yeah, I just love this tool.

21:24 So I've become a huge fan of the Black Code Formatter by Lukasz Lange.

21:29 And, well, what's a code formatter?

21:32 It's basically a tool you run on a Python source file, and it reformats it according to a built-in code style.

21:40 It's sort of like PEP 8, but PEP 8 isn't super comprehensive, so it's ambiguous to a certain degree.

21:48 So Black just makes a decision for you and reformats your code.

21:53 You know, with this sort of tool, it's always like a love and hate relationship, I think, because if you agree with the reformating, then it can be great, right?

22:02 It's awesome.

22:02 You just write your code however you like, and then you reformat it.

22:05 Boom, it looks consistent, at least.

22:08 But if you don't like it or you have, you know, other idiosyncrasies that you want to keep, then that doesn't work out so great.

22:14 And so with Black, I found that it's actually the first tool that I have sort of developed this blind trust for.

22:21 So I pretty much started using it for everything now.

22:24 And I like the way it formats my code.

22:27 It pretty much always figures out some formatting solution that I like.

22:32 And it's just a really, really cool tool.

22:35 And I think it just came out in 2018.

22:37 I actually heard about it on Python Bytes earlier this year.

22:41 And I think, Brian, you found it in episode 73.

22:45 Get my notes here.

22:46 And it's, yeah, it's just an amazing tool.

22:49 And the nice thing is, you know, besides all of the auto-formatting business,

22:53 you can also use it to check the formatting of an existing project or just a single file.

22:59 So where this is nice, and this kind of touches on some of the code quality tools that we had talked about earlier,

23:05 is that you can integrate that with your continuous integration pipeline.

23:10 And then make sure that any new code that gets committed is consistent with the formatting that Black generates.

23:18 So if you have multiple developers working on a code base, this just takes away all of the formatting back and forth.

23:25 You know, it's so easy to get sucked into a conversation of like, oh, I'm reviewing your code here.

23:30 Actually, I think this works really well.

23:31 You know, your 5,000 line change.

23:33 It's awesome.

23:33 But I would really change all of these, the single quote strings to double quotes or something like that.

23:39 It just gets rid of all of these non-productive conversations and just make sure everybody uses the same formatting.

23:45 I love it.

23:46 Yeah, that's awesome.

23:46 Another one of the problems you have in these teams is if you have different formatting rules and you can run, you know,

23:52 like format my code options like VS Code or PyCharm or something, and you have different ones,

23:56 they can fight in version control, right?

23:58 Like this one changes it, this one changes it back, this one changes it, this one changes it back.

24:02 So I can just hear Nina's voice saying, that should be a pre-commit hook.

24:05 And then everyone's is the same, right?

24:07 What do you think, Nina?

24:08 Should it be a pre-commit hook?

24:09 Yeah, I love pre-commit hooks.

24:11 Absolutely.

24:12 That's awesome.

24:13 Brett, I wanted to ask you, what do you guys do on the core dev team for this problem?

24:19 Lots of handwork.

24:22 It's all manual.

24:23 Basically, we don't have any tools specifically to actually maintain this.

24:28 More or less, all the core devs have just internalized PEP 8 almost as much as you possibly can.

24:33 And we can just spot code that doesn't quite meet it, even though PEP 8 is not as rigorously defined as it potentially could be.

24:39 The idea has come up about actually adopting Black as an official formatter.

24:44 But due to the current governance situation, that hasn't really gone anywhere.

24:48 But I wouldn't be shocked if Lukash, 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.

24:57 Yeah, that's cool.

24:58 Especially since Lukash is actually, you know, he created Black and he's a core developer who's very active.

25:03 It would be not unreasonable to say, we just run Black against everything.

25:07 Yeah, it's just the trick of, can you get enough core developers to say Black's output is pretty instead of ugly?

25:14 And you can probably pull that off.

25:17 But obviously, formatting, much like naming, is a very opinionated subject.

25:21 And it's hard to get agreement on that.

25:23 It's like asking everybody to use the same editor.

25:25 Some people, somebody will be happy.

25:28 But, you know, somebody's going to be really unhappy about that.

25:31 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.

25:40 Yeah, absolutely.

25:41 Absolutely.

25:41 Very cool.

25:42 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?

25:52 Yeah.

25:53 Dan Callahan had a whole keynote kind of talking about Python and where it's been and where it could potentially go.

25:59 And one of his key points was Python was not really on the web as I think some of us wish it could be.

26:05 Yeah.

26:05 But you have your next item is about trying to make that a bit more of a reality, right?

26:10 Yeah.

26:11 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.

26:28 Because you never want a specific monopoly because it's highly restrictive.

26:31 It makes innovation and growth hard and various other usual reasons you don't want it.

26:36 So Russell gave a whole talk about the various approaches that currently exist for trying to get Python into the browser.

26:44 And he did it by using an example all the way through his talk where he implemented what's called, I think you pronounce it, the Loon algorithm.

26:51 It's basically a way to check some credit card numbers.

26:55 Right.

26:55 And when he implemented it, it was only like 0.4 kilobytes.

26:58 So really small.

26:59 And then he just subsequently wrote it in Python and ran through all the ways you can do it.

27:04 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.

27:20 Python had a 646 kilobytes bootstrap.

27:23 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.

27:33 But it has a 5 megabyte bootstrap.

27:35 And then Pyodide, which is the CPython compiled down to WASM, which is WebAssembly, which is kind of viewed by some as the future way of handling this kind of problem.

27:45 I'm very excited about Pyodide.

27:47 Yeah.

27:47 Well, it's a really cool idea.

27:48 Unfortunately, while the code was still just 0.5 kilobytes for the Python code, the bootstrap's 3 megabytes.

27:54 So it's still kind of large.

27:55 But it is a nice way to short circuit getting going.

27:59 Because if you can just take CPython and just literally compile it straight to WebAssembly, there's no re-implementation.

28:05 of anything, right?

28:06 Like Batavia and Python and Transcript are all big projects that are having to basically re-implement Python in one way or the other.

28:12 While Pyodide just said, well, let's just take CPython and just make it work.

28:15 Right.

28:16 Compile it to WASM and then ship it.

28:18 Exactly.

28:19 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.

28:29 I don't know.

28:30 The other thing for me is my interest in this is as a VS Code extension developer because that's all on TypeScript.

28:38 So this and VS Code is an Electron app.

28:41 So for situations where download size isn't quite as critical, something like Pyodide actually starts to become potentially feasible because shipping 3 megs as part of a hundreds of megabyte app is not a big deal.

28:53 Yeah, that's where you're right.

28:54 That's where it gets super exciting because these things where, like you say, where you say, oh, that's 3 megs, that's 5 megs of JavaScript.

29:00 That's way too much.

29:01 That's true when you're getting it off the web per request, at least per session.

29:06 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?

29:16 Exactly.

29:16 And then at that point, it's a question of which one gives the best Python to JavaScript bridge and vice versa.

29:23 And they all have different levels for that based on how they're implemented.

29:27 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 an Electron or Node situation to get Python there,

29:38 but then also to potentially look at WebAssembly and see if there's a way to do, like, a Python compiler straight to WebAssembly

29:44 and then have that be the way we target Python on client side and try to keep that number down.

29:50 Yeah, that's super cool.

29:51 Have you heard about Python Electron?

29:53 Electron Python?

29:54 I can't remember which way it goes.

29:55 Yes, I have passively seen it because I've asked on Twitter a couple times, like, I really want this.

30:02 Like, I want to write the Python extension VS Code in Python someday.

30:06 So Eric Snow, who's a core dev and also a teammate of mine, we occasionally bounce this idea back and forth.

30:12 It sometimes leaks onto Twitter and we dream in blue skies.

30:17 And people have brought up Python Electron before.

30:21 Very cool.

30:22 How about the rest of you folks?

30:23 Have you heard about Pyodide or people doing interesting things with some of these others?

30:27 What are your thoughts?

30:28 We recently added two interactive coding exercises to real Python.

30:33 So there's quizzes and parts of them are, you know, solve this, like implement this little loop or whatever.

30:38 And that's actually implemented in Python.

30:40 And so it compiles your Python code to JavaScript locally on the client and then runs that.

30:46 And it's actually been a pretty cool experience.

30:49 It's not 100% compatible.

30:51 So it's sort of like Python 3.7-ish.

30:54 And so you run into these funny edge cases, which is interesting because, well, people are trying to learn Python.

31:00 And what are they really learning with these exercises?

31:02 But for the most part, you know, it's pretty accurate.

31:05 And performance-wise, it works pretty well, too.

31:08 So on a fast connection, you know, when that bootstrap doesn't hit you that hard, it works quite well on mobile, too.

31:13 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.

31:22 So we have the option to validate your code using regexes.

31:26 And when you import RE, then it can take, I don't know, you know, five seconds even on a notebook.

31:33 And that's not ideal.

31:35 But I think for a use case like that where you have the user type in code, for us, it works really quite well.

31:40 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.

31:46 But for a code runner or code exercise tool, I think it works quite well.

31:50 Yeah, that sounds like a really cool use.

31:52 And you don't have to worry about the security.

31:53 It's not like I'm taking their code and running it and trying to do that in Docker or something.

31:58 Like, just hope my server doesn't get messed up from this.

32:00 We'll try it.

32:00 The only thing you can break is your browser.

32:02 I've hacked myself.

32:05 I'm a hacker.

32:05 Awesome.

32:06 How about the rest of you?

32:07 No, I've not checked it out.

32:09 But there's a couple of other links I'd recommend people look at.

32:12 One is Scott Hanselman's blog post on JavaScript as the assembly of the web, which is really interesting and paints some good context.

32:21 And then also from Scott, there's an interview on Hanselman's podcast between him and Patricia Oz.

32:28 And that kind of covers off the history of JavaScript engines and runtimes and also helps kind of explain why things are the way they are, which is really interesting to give you context as well.

32:41 Yeah, it's cool.

32:41 And speaking of Scott Hanselman, they're doing really interesting stuff with WebAssembly and the .NET CLR with Blazor.

32:48 I mean, if the Python community could just do that same thing.

32:51 And it looks like Pyodide is very close, but that's more focused on data science instead of SPA's front-end JavaScript stuff.

32:57 So there's definitely some interesting stuff happening there.

33:00 I'd also recommend if you haven't watched Jan Callahad's keynote from PyCon that you do.

33:05 It's really good.

33:06 Yeah, that's a great recommendation.

33:08 All right, WebAssembly.

33:09 It's going to make things amazing.

33:11 I'm looking forward to it.

33:12 All right, so we're down to our last item, and this one is mine.

33:16 So I'll kick it off.

33:18 So you all have heard of Selenium, right?

33:20 You can automate browsers and do web testing and stuff with it?

33:24 Yeah.

33:24 Yeah.

33:24 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.

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

33:41 Arsenic, I guess, something like that.

33:42 And it's an async version of, well, basically Selenium.

33:47 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 event loop very easily with this other project.

33:58 So it's quite cool.

33:59 I'm going to definitely have to check that out.

34:01 That is interesting.

34:01 Yeah.

34:02 So I come in here and I could create one of these sessions and say I'd like to use the Firefox browser to do this.

34:08 And then I'm going to await getting a page.

34:10 And then I could actually say, like, await session.wait for element, like H1.

34:16 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.

34:23 It's really quite neat.

34:24 Yeah.

34:25 So they say, you know, this is good for load testing, good for automated testing websites.

34:29 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.

34:35 Right.

34:35 Something like that.

34:36 And it uses real web browsers.

34:38 So it's really using Firefox in a hidden form to do this.

34:41 So it's pretty cool.

34:42 Very nice for testing, I think.

34:44 Yeah, headless browsers are awesome.

34:45 And it has a pytest.

34:46 It works with pytest.

34:47 That's cool.

34:48 Yeah, it has a special pytest support, which is cool.

34:50 So I guess, you know, this is an interesting thing for people who want to automate the web and they're doing it asynchronously.

34:55 And often that's like one of the times where AsyncIO is really helpful because you're just waiting on other servers anyway.

35:00 So you can blaze through that.

35:02 But maybe just throw it out to you all.

35:04 What are your thoughts on Async these days?

35:06 Async and await and all that stuff.

35:07 Brett, maybe start with you because you are on the inside.

35:10 And I know you've blogged on this.

35:12 Yeah, I was going to say, which makes me obviously.

35:13 extremely biased on the topic.

35:15 So I think Async's great.

35:18 I appreciate personally how we designed it because we haven't tied ourselves to a specific event loop, which has allowed some experimentation such as Trio and Curio.

35:28 And while AsyncIO has continued to evolve and learn from them, like I know Yuri Solanov has pulled a lot of ideas from Nathaniel Smith of Trio into AsyncIO.

35:41 And so there's been a nice feedback loop on that level of experimentation.

35:44 So I'm very positive on it.

35:46 I wrote an entire GitHub API library based on Async because I thought it was so great.

35:51 Yeah, that's right.

35:52 And we've covered that in the show before.

35:54 But I don't remember the number, I'm afraid.

35:55 I don't know.

35:56 I think Dan brought it up.

35:57 That's right.

35:58 Dan did bring it up.

35:59 I don't remember the number either, though.

36:01 But man, so many episodes.

36:02 I'll tell you, it's less than 100.

36:03 It's either 99 or below that.

36:05 We put a bound on it.

36:06 How's this?

36:07 Async, the rest of you guys?

36:09 No, nothing.

36:10 I still find Async and await very confusing.

36:13 And the attempts that I've had at using it, I've just ended up making a mess and causing bugs that I don't understand and can't debug.

36:21 So I just kind of gave up, which is pretty sad.

36:23 But I'm going to watch your course, Mike, at some point.

36:26 Thanks.

36:26 I need to allocate the time.

36:27 There you go.

36:28 You know, the whole threading world, there's a phrase for the bugs that are like race condition stuff called Heisen bugs.

36:34 And I just love that terminology.

36:36 I've run into a few of those.

36:38 For those who don't know, a Heisen bug only appears when you're not looking at it.

36:44 That's right.

36:45 You observe it.

36:45 It changes it too late.

36:46 Yeah.

36:46 Yeah, very cool.

36:47 All right.

36:48 Well, people out there, if you need to do some sort of automation and you were going to use Selenium, definitely check out Arsenic.

36:55 Because you can do it more in parallel if you're doing more than one sort of flow through your test.

36:59 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.

37:10 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.

37:17 That probably won't work so well.

37:18 Yeah.

37:19 Check out Selenium Grid if you want to do that.

37:21 If you want to do multiple machines and multiple browsers at the same time.

37:25 Is that grid computing for Selenium?

37:26 Kind of.

37:27 Yeah.

37:27 Oh, man.

37:29 That's pretty awesome.

37:30 All right.

37:30 Well, let's leave it there for our main topics.

37:33 So thank you, everyone, for bringing these and sharing them with everyone.

37:36 They were super interesting.

37:37 Normally, I just ask Brian if he has anything else to share.

37:40 But I know we got more than that.

37:42 So we'll screw down the list here.

37:43 I'll throw mine out first.

37:45 So hopefully this is not out too late to make this useful.

37:49 But the PSF and JetBrains last year teamed up to do the most comprehensive survey of the Python community they could.

37:56 And that is now happening again this year.

38:00 So just visit talkpython.fm/survey2018 and take that.

38:05 But if you hear this, do that as soon as possible because there's only a week or two left of it being open.

38:09 So, all right.

38:10 Anthony, you've got one you'd like to share.

38:11 Yeah.

38:12 3.7.1 is around the corner.

38:14 The first release candidate came out a week ago.

38:19 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,

38:25 take a look through the release notes.

38:27 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

38:34 and talking about the whole landscape and the comparisons with Flit and Poetry and PipHend and the reasons behind them.

38:41 It's a really in-depth piece, and I think it's worth a good read.

38:44 That's awesome.

38:45 I definitely think some comparison and exploration is needed because there's just so many ways to start solving this problem these days.

38:51 But I think something will emerge, and I'm kind of hopeful for Poetry, actually.

38:54 Nina, how about you?

38:55 I have a few things as well.

38:56 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,

39:04 and there are lots of new features, automatic environment activation in the terminal,

39:09 some debugging improvements, and a lot more.

39:11 So you can check out the blog post in the show notes for some more information.

39:15 Brett, I don't know why you're being so shy.

39:17 You should be the one bringing this up.

39:22 That's fine.

39:24 And then there's one more thing I wanted to mention.

39:26 Py Cascades is a really nice, smaller Python conference.

39:30 It's happening February of 2019 in Seattle.

39:34 And right now the call for proposals is open.

39:36 It closes on October 21st.

39:39 So you should still hopefully have a little bit of time.

39:42 And they're doing something great that I haven't seen from too many conferences before,

39:46 which is offering mentorship.

39:48 Yeah, this is for like new speakers and stuff who maybe want to speak, but they're like, I've never done this.

39:52 I'm a little unsure that this is actually a good idea.

39:54 Could really use some help.

39:55 That type of thing.

39:56 Yeah.

39:57 Yeah, it's really great.

39:59 I've been volunteering as a mentor and it's been a really rewarding experience

40:02 to kind of coach people through all their fears.

40:05 Because at the end of the day, we can all speak at a Python conference.

40:09 Yeah, absolutely.

40:09 That's awesome.

40:10 I'm glad you brought those up.

40:11 I've already booked my travel and submitted three talks.

40:14 And I even put Brian's name on one.

40:15 So he has to come now too.

40:16 Awesome.

40:19 I'll say last year was my favorite conference probably potentially ever was the inaugural

40:24 PyCascades.

40:25 So you should definitely go if you can make it.

40:27 I agree.

40:27 That was up in Vancouver where you and Dan are, but this time it's moving down to Seattle.

40:32 And then later it comes to visit us here in Portland.

40:34 So I think it's a great one as well, Brett.

40:36 That's right.

40:37 2020.

40:37 That's right.

40:38 It'll be here.

40:39 I'll drive.

40:40 I won't have to stay in a hotel.

40:41 It'll be great.

40:42 All right.

40:42 The rest of you, anything else?

40:44 Dan, Brian, you want to share anything before we hit the road?

40:46 I just want to say the upcoming, I've got a recording with a guy named Anthony Shaw.

40:52 Oh, that guy.

40:52 Yeah.

40:53 I've heard he's good on the podcast.

40:54 Yeah.

40:54 We're going to talk about flaky tests on testing code.

40:57 So that should be fun.

40:58 Right on.

40:59 Dan, anything?

41:00 No, I got nothing.

41:01 I hope you invite me back for episode 200.

41:03 Yeah.

41:04 You all already have an invite.

41:05 We'll be there in just about two years.

41:07 So you all hang in there and we'll do this again.

41:10 Thank you all for coming.

41:11 This was really great.

41:12 And thanks for help with the show throughout the last two years and today, of course.

41:17 Thanks for having us.

41:18 Yeah.

41:18 Thanks for doing it.

41:19 Yeah.

41:19 And congrats again.

41:20 Yeah.

41:20 Thanks.

41:21 Bye, everyone.

41:21 And Brian, special thanks.

41:22 You've been here for all 100 of them.

41:24 Well, maybe 99 because we each bowed out at one or two, but that's all good.

41:28 Yeah.

41:28 All right.

41:29 Thanks, man.

41:29 Bye, everyone.

41:30 Thanks.

41:30 Bye.

41:31 Bye.

41:31 Bye.

41:32 Bye.

41:34 Bye.

41:35 Bye.

41:35 Bye.

41:35 Bye.

41:35 Bye.

41:35 Bye.

41:36 Bye.

41:36 Follow the show on Twitter via at Python Bytes.

41:39 That's Python Bytes as in B-Y-T-E-S.

41:42 And get the full show notes at pythonbytes.fm.

41:45 If you have a news item you want featured, just visit pythonbytes.fm and send it our way.

41:49 We're always on the lookout for sharing something cool.

41:52 On behalf of myself and Brian Okken, this is Michael Kennedy.

41:55 Thank you for listening and sharing this podcast with your friends and colleagues.