Ergonomica with Liam Schumm

Hello, and welcome to podcast dot in it, the podcast about Python and the people who make it great. I would like to thank everyone who supports us on Patreon.

Your contributions helped to make the show sustainable.

When you're ready to launch your next project, you'll need somewhere to deploy it, so you should check out Linode at www.podcastinit.com/linode

and get a $20 credit to try out their fast and reliable Linux virtual servers for running your next app. Do Do you need to learn more about how to scale your apps or learn new techniques for building them? Pluralsight has the training and mentoring you need to level up your skills. Go Go to www.podcastinit.com/pluralsite

to start your free trial today. You can visit the site to subscribe to the show, sign up for the newsletter, read the show notes,

get in touch, and support the show. To help other people find the show, please leave a review on Itunes or Google Play Music, tell your friends and coworkers, and share it on social media.

If you work with data for your job or want to learn more about how open source is powering the latest innovations in data science, then make your way to the Open Data Science Conference happening in London in October and San Francisco in November.

Follow the links in the show notes to register. Your host as usual is Tobias Macy. And today, I'm interviewing

Liam Shum about Ergonomica.

So, Liam, could you please introduce yourself?

So I am,

my name's Liam. I'm a high school student from Chicago at Walter Payton College Prep and,

a sort of a hobby Python enthusiast.

I've been programming for about

4 years.

I suppose, like, the last year and a half, more seriously and really getting into things. And I attended PyCon 2017,

which really sort of boosted my my Python enthusiasm and career. And I've just really been enjoying,

developing

open source tools on on GitHub ever since.

So do you remember what first got you introduced to programming in general and Python in particular?

So my first my first programming experience was in Python. My dad taught a class at,

the the school I was attending. And, it was just a very basic introduction to Python,

very basic pie game set up. We followed a book made little thing where you moved, moved a guy around and he caught pizza. It's just very basic applications and also, 1 of the asteroids games.

So

sort of pretty simple,

applications. And I sort of forgot about Python for 2 years since that. And then I sort of got back interested when I when I got into Minecraft. I actually got into Minecraft servers and realized that, like, programming was something that allowed you to automate the tasks that you do every day. And I found it really cool that you could just, like, write some program, and it would automatically do that. So then I started getting into since I was really into math at the time and still,

I made some very simple, like, calculators, some things that like, post simple arithmetic,

a few

things with with a command line interface.

And from there, I just

I've been creating everything I use every day in Python, like my init scripts for for my computer written in Python. I've just gradually been replacing each manual tool tool in my life with with Python and just finding more and more applications

to to use Python in my my daily life. Everything from my schoolwork to day to day tasks.

It's definitely pretty great when the light switch goes off and you start to realize that you can actually start creating the tools that you're using instead of having to purely be a consumer of them and can actually make them work the way that you want them to. Yeah. Yeah. Of course. Mhmm.

And going back to PyCon, you said that you had a good experience there. I'm just wondering if you have any other sort of similar

event that you've been to that you have can use as a comparison and what your thoughts are on PyCon in general and what was most valuable to you? So I I had a I had a really wonderful experience at PyCon. I would say that,

what was the most valuable experience to me was the the sprints.

I sprinted on the PyBee project.

I know you've interviewed Russell about about that project. And I found that,

just such a wonderful experience because I got to collaborate with people from all around the world, from Australia to Mexico.

And over,

I believe I was there for 4 days. Over 4 days just craft

friendships with other developers,

build really cool products,

and just just make connections in the Python community. Yeah, I found that the expo hall is like, kind of interesting. And I met a few people, but

overall, overall, the sprints were were the funnest part. I haven't had a great experience at at Chippy, which is the

Chicago Python users group,

but that may have just been the chance. 1, 1 event that I found great in Chicago was something called Chy Hack Night, where it also took the breakout group format in which

people just presented,

projects in civic tech that they were working on,

and anybody could join them. And there were free, like,

soda and food.

So I I think just

all of those events and as well as, like, hackathons I've went to,

the best experiences I've had have been in in group, like,

project building settings.

And so bringing the conversation around to the project that you are the main author of,

wondering if you can just briefly describe what Ergonomica is and the reason that you first created it.

Sure. So essentially, what Ergonomica

is is the shell language we designed from the ground up in Python.

And what inspired me to do this is I, when I first started getting into bash scripting,

I found it really cool that I could just navigate my file systems with commands, and it was so much faster than,

finder on the Mac. And

I I found it pretty cool. And eventually, once I started getting into

more advanced stuff, once I got past just like simple simple editing and like emacs,

I wanted to build scripts to, like, manage my files. And I found that really frustrating because

essentially what you had to do is you had to go on Stack Overflow

and you had to copy and paste, like, those bash scripts with,

like, tar attack

and then sea of options that nobody really has any idea,

what they what they mean. So an xkcd comic where

I believe Rob has to enter, valid tar command or in 10 seconds or the bomb will explode.

And he's he's like, sorry guys, I can't do it. Because,

like, the the traditional UNIX system is really powerful, and I think it's it's been designed

it's been designed really well. And a testament to that is just, like, how long it survived, and that stuff in my, UNIX programming environment,

book from the seventies, like, still works on a modern modern computer. It's it's been it was designed really well, but I think,

it sort of needs a modern refresh

and sort of where I took inspiration

for how I built Ergonomica from was, was from Python. So Python

is,

has very sparse syntax, has very few like symbols and special

things that you need to put in your syntax.

And in Python, whenever you want to do something, it's

obvious the way that you do it. So for example,

if you wanted to see if some element is in an array, you just say element in array.

It's as simple as that. Or for loops

for item in array.

Or, an example from PyCon, dictionary comprehension syntax. It's natural if you know list comprehension syntax to follow that syntax. Just put curly braces in it. Since dictionaries are inadorable, you have dictionary comprehension syntax. And I think that was the the motivation behind behind the prep for that. And I found it really

useful in learning Python that everything was so easily discoverable

and wish that that would be the way in Bash.

And sort of what I tried to do,

over time is find a balance between easy discoverability and, like, modern language features and also

what what's realistic in, like, a shell setting because obviously you need to be able to type commands

fast and do the same kinds of operations over and over. So I kind of

found a balance between traditional POSIX syntax,

which it's great that you can just instead of needing to have parentheses and commas, you can just have a function and then its arguments.

And then if you wanna do substitution,

you do

parentheses and a dollar sign. So that I found that syntax really useful. But then the, like, the conditional syntax, like if,

closing if block with phi, that's from algol 68,

and it's just not

doesn't make any sense. So

basically, I found a balance between, like, the POSIX sort of bash syntax

and and the Python syntax. And,

basically, aim to create something that was

not only

ergonomic

in the same way that I found Bash initially, that you could just CD to directories, alas,

that that was easy, And

then also provide, like, discoverability

and the ease of use

and, like, natural

naturalness of of the syntax,

as Python.

And building a shell is definitely a non trivial

endeavor, particularly

given the number of different overlapping standards that play into the standard terminal environment with VT 100 emulation

and escape codes and all of the different things that you have to think about. So I'm wondering, how did you

obtain the necessary

to be able to build Ergonomica

and have it useful? And what are some of the most challenging aspects that you've had to

overcome in the process?

So I mean, just just really trial and error. I remember my first, command line application. I kind of like kind of like making command line applications. It,

it took a command's arguments

and split them, and it had a separate case,

if elif,

for each, like, length of arguments. Like, if I had 1 argument, 2 arguments, 3 arguments.

And

just over time, I've

sort

of sort of through trial and error figured out the best way to approach those kinds of things. Thankfully, because of how,

the the the extensive standard library of Python with things like OS, shutil,

I actually haven't really had to dig into

system stuff with Python. I haven't had to dig into, like,

terminal escape codes.

Colorama is a great library that

allows you to, like, color output without having to deal with any of that.

So I actually,

I did not have to learn terribly many prerequisites

for for creating it initially.

As it grew, I needed to,

sort of ensure that it it was a functional language and that, like, you could do you could do the tasks you wanted in it.

So for the knowledge of, like, how a shell is typically used,

I just,

like, searched questions, typed bash

on Stack Overflow, and saw various things that, like, people could do

in the shell, tried doing them myself, and tried, like, implementing them in Ergonomica.

And then, another another helpful thing I did was read through some old Unix books and look through the examples there and look through how they how they initially laid out the usage for the shell to be

and just tried to make

to tried to make my shell congruent to that. So thanks to Python, I really haven't had to learn terribly many technical prerequisites for for creating it.

And I'm wondering if you can dig into how you actually implemented it and the software architecture that you're using and the way that you're actually processing the inputs.

Sure. So,

I've

had 3 major regoits of the syntax. The initial 1

used

just my own tokenizer

that just went through tokens

and split them, and that was terribly buggy.

And then I moved to David Beasley's Pylexiac

for for tokenization,

which was really a major step forward because this allowed me to

specify,

like, a formal formal grammar

for Ergonomica, and that really helped,

helped the stability of the product. But I I didn't really get

context free grammars and how to, like, use how to use, well, his implementation of react very well.

So

sort of looking at Bash syntax, often, if you want

if you wanna, like, substitute in the value of command. So, for example, if you were gonna

look at the source code for the command,

I don't know, ls, you would do cat and then dollar sign parenthesis,

which ls.

And,

in that syntax,

after going through

writing

some stuff in Emacs Lisp I realized that

that syntax and then also the function and then argument syntax without the parenthesis

that

was kind of similar to Lisp.

So then

I kept that in the back of my mind for a while while still maintaining the old codebase and then ran into this article called how to write a Lisp interpreter in Python

by

a guy named, I believe, Peter Norvig.

So if you go to nor at norvig.com/lispy.html,

It basically outlines how to write a Lisp interpreter in Python.

And what's great about a Lisp interpreter in Python is,

or just a Lisp interpreter in general, is you basically

have 2 tokens. You have a parenthesis left to right, and you have,

like, an atom. And that really simplified

the parsing architecture.

And,

as the nature of like functional programming languages are,

it's a lot easier to implement,

just a simple functional programming language because each command in it

or structure in it is basically just a function aside from

the if statement

set and lambda.

And

so, essentially, basically, what it does is it reads in these tokens

and then converts them to

to Python functions because all all ergonomica functions,

at the base level are just just Python functions and then evaluates them on arguments. So the whole run time is is implemented in Python. It is implemented with, tail call optimizations, so

you're you're able to build, like, larger structures in it even though it's a functional programming language.

But, a lot of the a lot of the standard library functions that I've created have just been very simple Lambda functions in in the namespace dictionary. I just map, like, I don't know, add to a Lambda function that adds its input arguments. So it's really simple.

And I've made I've made an architecture for importing standard library functions. So it just you just import a function, stick it into a namespace, which is a standard Python,

namespace with string a dictionary with strings mapping to functions.

Just evaluate those functions based on s expressions.

When you started this project, were you aware of the some of the other alternative shells such as Xanche and or I guess they pronounce it conch and fish and other shells implemented in other languages? And if so,

did you use those to draw inspiration? Or did you decide to try and keep all of your ideas

sort of pure by not trying to crib too much from the other

options. I was actually,

inspired by by other Shell designs, and I think that all of them really bring something unique to the table.

I have friends who use ESH, friends who use Phish. I've met people who use Zonchin, or Conshant, Python. And I think that they all provide unique approaches to a shell, and I I've taken I've taken some, extensive in information from them.

So basically, it seems that each has taken, like, a unique an unique approach. So z s h or the z cell, it's 1 of the

older ones of the set. It's totally bash words, so you can essentially copy paste your bash commands into

zsh

and it'll work. And that's really convenient because that means if you want to do some operation on a file and use your standard,

stable, powerful,

fast,

UNIX utilities

to do that. You can just

use the standard syntax, and you can run shell scripts in it, just, like, natively. So

and then what it what z, z shell provides is more,

a more advanced,

extension

more advanced extension abilities.

So you can build great, like, completion engines for Z Shell. There's also some great, globbing and

file globbing and other just other usability features for for

implemented in Z Shell. And essentially Z Shell's approach was to just simply improve on bat improve upon Bash. And then Phish Phish takes a more unique approach,

though

not not nearly as radical as ergonomic,

by allowing you to

run your system commands

and run them normally with pipes and all that, all that jazz. But just replaces, like, function definition syntax and, like, if statements for statements.

It sort of gives a modern overhaul

to bash as a as a programming language.

And the advantage of that is most most bash commands you can run-in it, but then if you want to write a shell, if you want to write a fish script, fish shell script, you can do it in a much nicer syntax than you than you would in bash, and it's still pretty close close to

what you're used to in bash. And then consh

has taken what's a really, really interesting approach and seems to seems to work kinda well

is basically to just mingle

Python and bash syntax. So you,

the advantage of this is basically you can have, like, your while loops with, like, your Python variables that are like integers, and then you can call shell commands, like, within that script. So I think that's a really cool approach because that means that

for people writing

utilities for a file and system management in Python,

they can

write their application in Python, and then just, like, put a few lines in shell of shell in there, and then integrate that with the rest of the problem with with the rest of the program and, like, set the output of those commands to variables. It offers a really great way of sort of using Python

as your shell in in in a convenient way, which is which is quite cool. And what Ergonomica has has done is instead of

staying Bashwords and supporting Bash syntax, it basically replaces all that syntax. It does support,

obviously, because, like,

binaries like git will never switch to,

a pure Python implementation.

It does, call upon,

system binaries just using subprocess,

but it's essentially over hard hold all of the language except for just the ability to call those binaries,

and essentially pulls in these these binaries just as normal Python functions and sort of completely

throws away all of the previous syntax. I have implemented,

like,

features like piping and, of course, stayed

somewhat,

POSITIX compliant. But basically,

it's an entirely different language. All the control structures are different. The way you define functions, every function's Lambda function,

it's all like a functional programming language. It's a more radical overhaul of of existing shell structures.

And why did you decide to implement it in Python, particularly given the fact that you ended up settling on a Lisp

dialect as the actual syntax for operating in the shell environment?

So I I chose,

I chose Python for implementation because Python

Python has really a wide reach in terms of in terms of,

high level programming languages. Python is used

extensively in data analysis and scientific applications.

It's used in

web applications,

the back end for Instagram,

say an example. It's used really widely, and as a result, it has a very general standard library that allows you to do some really,

simplify some some complex tasks. And because of its,

sort of commitment to being cross platform,

your OS and, shutil,

subprocess,

sys, all those libraries are

totally cross platform and just a great way of interacting with the system because Python's reach has has extended to 2 system programs. And while, many people still use shell scripts, there are there are frameworks that use, use Python for system and file management. So I I wanted to build upon both, like, the cross platformness of Python

and, like,

the existing libraries that made the system commands

super, super easy and

just sort of just harness, the community that was replacing a lot of existing commands with Python commands,

sort of rebuilding

shell, rebuilding computer specific binaries in Python for like cross platform goodness. Also to modernize things and make them easier to maintain. I wanted to harness,

the Python community in order to to create

a more usable more usable shell experience and also to make to make my job easier. And while you've been building Ergonomica,

has it primarily been just for your own utility, or do you have a sort of target audience in mind as you're working on implementing new features and improving the capabilities of the shell? So as of yet, I'm since it's terribly, maybe less less unstable, but it's been in, sort of alpha testing for a while now. I'm only the the only current user as of yet, but I guess my target user for for Ergonomica is your average user, is,

a user that just wants to open a shell, have it work not necessarily

for your,

stereotypical

Unix,

sysadmin who knows color flags like the back of his hand. I think that,

at least what I'm trying to accomplish with Ergonomica

is a shell that is

usable, is sort of like human readable and human understandable,

that is a lot easier to learn

than bash.

And that also allows you

to

to interface with it, like, through Python. So

for people writing writing more simple shell scripts, they can easily,

I mean, interface

Ergonomica since every

command and Ergonomica returns Python object, Boolean, and it's your float string. It also allows you to do, like, some some small script small scale scripting.

So I haven't since I haven't had much of an audience so far, I haven't been able to really figure out who my target audience is. But I guess it's just

people people using the shell, I suppose.

And do you have any major features planned that you would like to implement in the future or that you would like to have any help with implementing?

So

I think,

replacing a lot of so I've had a lot of frustration

working with my friends at acathons who use Windows Computers.

And, I know 1 of them has switched to Ubuntu because of because of Bash. I've had a lot of frustration,

that

your very basic utilities

that you'd expect in a UNIX system, like, less,

Vim

are not present in Windows systems.

And I've I've already found a project,

Jonathan Slender is Py Vim. He's basically implemented

a Vim clone purely in in Python and his Python prompt toolkit framework, which is basically terminal graphical framework without any curses. And I guess eventually making a clone of last would be interesting

to allow people to,

manipulate the outputs of of their commands

essentially in in any shell. And

just a variety of different standard Unix utilities that people people really use every day and that are stable and fast. I'd like to replicate those in in Python in order to

make those utilities,

1, more, like, interfaceable with Python code, and number 2, just give them a modern revamp.

Give them, like, modern features and modern,

modern standards. I guess, essentially, we design them put so they're, like, more maintainable and just essentially

essentially make those cross platform. So just building up as I have don't have much of a standard library existing.

Just building up the standard library so that it that it is a full functional

system implemented in Pure Python is is my eventual is my eventual goal, and implementing some of these utilities is a little daunting.

Have you looked at all at the work that's been going on in the conch project with their replacements for some of the core system commands in pure Python implementations.

I actually haven't. So I've actually just,

few weeks ago started using conch as my main shell on my local system as well as somewhat to on my salt master as I'm working in it because of the features that you mentioned of being able to mix the syntaxes of Python and Unix commands so that you can merge the different variables and system calls together to be able to get a much

more efficient hybrid,

workflow. And 1 of the things that they've been working on is to actually do, as you said, and reimplement some of those core commands in Python so that it's easier to integrate it and get appropriate

behavior as you're using it in the shell environment. So it'd be interesting to see how much of that work you're able to incorporate into Ergonomica

and maybe start collaboration

on a sort of universal set of Unix tool replacements

in pure Python that can be used across multiple different shell environments

as sort of a core building block to foster this ecosystem of alternative shells that are cropping up in Python?

Yeah. I think, I think also

providing those utilities I know there's a library called sh

that aims to be a subprocess replacement that allows you to do

like, from shimportls,

and then just to mingle,

standard shell commands with with the rest of your Python code as as native Python functions. But it's not terribly

useful because of, like, how, at the base level, that the shell interacts with Python because all of the

shell command standards, how they're implemented

with,

sort of, like, your c standards, they return 0

on a successful call or 1 on an unsuccessful call instead of, as you would in a modern language, like, throwing exceptions,

essentially, and and separating output by new lines, not being able to buy typed output. I think a lot of those commands

aren't in sh

or they're not really satisfying

because

they don't they're not they're not Pythonic, really. And I think making,

sort of a library

not necessarily

aimed for for a shell like, Contura Ergonomica,

but a standard library that you could just include in your regular Python code would be really great for,

just making Python a powerful

powerful systems management language. So when I was doing some research for the show and installed Ergonomica

to play around with it a bit, I noticed that 1 of the things that it does on the initial launch is to instantiate

a repository

for the EPM,

which appears to be a package manager that you're working on. So I'm wondering if you can discuss that and what your plans are there. Yeah. So I,

I've essentially created about, I think, 2 or 3 packages,

calculator package,

work points package. I've created a few very basic, packages for Ergonomica,

but I think sort of package package management and, like, extensions for Ergonomica

are where it really shines

because of the fact that each,

each ergonomica

function is just a Python

function. It makes implementation

really simple. Instead of needing to juggle fish shells syntax,

you,

you just get to use what you're used to, or what you're used to in Python syntax.

And I think that, extensions in Ergonomica, since they can just be pure pure Python files, are they're a lot easier to write because of that.

And they just allow you to interface your little Python extensions. Say you wanted to write a program to graph numbers in your terminal. You already know how to do that in Python. You can just write something up real quick and just have that in your normal in your normal shell environment. So I think that extensions

are are a major part of it because of its,

pure Python focus. And I'd I'd love to see

some of this

extension implementation

mirrored in in conch

is is where it is where it would would really shine because of because of the ease of implementing new commands in your shell, and it could help newer users,

who are not familiar with, like, how to make a shell script or how to make, like, a c standard

function. It would help them sort of customize their shell and build it,

build it to be more a more powerful tool.

And does your reason for building your own package management system for that because it simplifies

the distribution

among a smaller group of people so that you can build up your own personal library

of plugins? Or,

I'm curious why you decided to go that approach rather than just leaning on the existing Python package,

repository. So,

my, my reasoning behind,

behind creating EPM was I I just wanted something very simple that downloaded

Python files into your ergonomica packages directory. I haven't actually given terribly much thought into,

into

its superiority

over,

existing

existing package management tools, PyPy and pip.

It don't really,

tickle my fancy. I I don't really, like, enjoy how they're structured. Pip versus,

other package management systems such as NPM is kind of bare bones. It works. But,

yeah, I haven't given,

I haven't, like, formally decided whether I would continue with EPM or whether I mean, potentially Conda because of its its goal of cross language. Just general package installation might might be fit for that. That that's not something that I've I've just planned out. It's

essentially using

wget or a Python implementation of

I think it actually uses requests. It's just a very simple thing that pulls down packages from from a GitHub repository. But,

1 1 feature of it that I that I like is that all packages are essentially GitHub packages. And,

if you've used a Mac, brew is really nice because of how

any,

brew package is just

or or a tap is just a repository. And as a result, it makes it really easy for for hobbyists to set up their own their own packages, add them to the to the standard

package listing, create their own taps for their own sets of packages, and I found that tool,

super powerful. And I think that

going in whatever direction, whether that would be continuing the development of VPN or switching to another package manager

that, facilitated

download through GitHub or similar version control system, I I might pursue. I just, for now, like how that's implemented,

and

it's just been what's what's most simple for me as of yet. Yeah. There's definitely a lot to be said for stripping away a lot of the formality

of distributing the packages and just downloading a file or a set of files without having to have all the associated metadata and infrastructure necessary for

infrastructure necessary for listing on the Python package index,

particularly given the fact that, some of the target audience for Ergonomica are people who don't necessarily

have or want to have all of the requisite knowledge that goes along with

bundling up those,

additional pieces of information. Mhmm. Though,

I I must, I must say, like, I think that, you've got to balance, like, your sort of hobbyist approach,

like, that Homebrew has taken in in making these package a GitHub repository.

And then also,

balance that simplicity with,

like, some power. So dependency management

and good dependency management is something that

PIP isn't terribly great at. Once you,

like, use virtual lens, that's, somewhat remedied. And I know

that, to bring back up Conda,

they they have

they've created a virtual lens alternative

in that. And I think that,

if I were to want this project to grow, to allow you to say

on some

even production server,

have some ergonomica

script to manage your files or allow you to use ergonomica to manage the file system. I would like more powerful,

dependency management, depend dependency resolving,

so you can build sort of a a robust

package package setup.

Another platform that would be worth looking into for inspiration

is the Nix package manager because of the fact that it does allow for having multiple versions of the same packages installed simultaneously

without stepping on each other, which is 1 of the areas where

Python and a number of other languages have issues. And that's where we end up with solutions such as virtualenv

or gem sets from RVM, things like that. So, is it this,

nixos.org/nixapillyfunctionalpacketemanager?

Yep. Yep. That's the 1. I've heard about that.

So as as you mentioned at the beginning of the episode, you're currently a high school student.

And looking through your websites and your GitHub repositories, it looks like you've been able to build up a fairly

comprehensive

list of different projects that you've been involved in. So I'm wondering how your age has factored into the kinds of projects that you've been engaged in and the experiences that you've had engaging with the open source community. So,

my my age has

actually driven me to open source development in the fact that sort of when you're initially getting started with making software,

you're not doing it for a company. You're just tinkering around. At least that's what I what I experienced. And,

once I started making tools a little bit more and collaborating with a few friends on projects,

on Python projects,

I discovered GitHub and realized that version control was a lot better than just sending files back and forth. And so I just started posting

my projects on GitHub. And eventually,

I

decided to reach out, look at other projects, and also contribute on my friend's projects. And

that basically drove me to open source development because

I I remember

after making countless

random tools that were essentially

useless,

I

on on Ergonomica on a very early alpha of Ergonomica a while back, somebody posted on a Hacker News

and I got suddenly

influx of of people starring the repository and people making pull requests and issues. And that really sort of catalyzed my

drive to to continue into open source development. I found it really cool that you had people all over the world basically contributing for free on on products.

And I found it I found it just really cool that,

I mean, if you take, take a look at very large projects that have been been maintained by open source communities,

such as, I mean, Linux.

You get a sense of, like, the power of that kind of development. And once I once I really experienced that, I realized,

number 1, that I could contribute to anybody's repository on GitHub

regardless

of where I was in the world, my status. I could, as a a high schooler,

contribute to any project I wanted on GitHub as long as my contribution was was valuable. And I I gradually made a few open source contributions over time, and then after PyCon,

started making

a few more on on Pyb. And, essentially,

up to

now, my being in high school and my not having, like, the status of being a professionally employed software engineer has meant that I've created free and open source software. And it's been a very helpful community for me to to learn programming and for me to work on,

increasingly

complex tasks and even just contribute to to the tools I use every day. Well, for anybody who wants to follow the work that you're up to or get in touch to discuss some of the projects that you're involved in, I'll have you add your preferred contact information to the show notes. And so with that, I'll move us to the picks. And my pick this week is a board game that I picked up recently to play with my kids called Magic the Gathering Arena of the Planeswalkers.

And I actually picked up the

the Shadows Over Innistrad

expansion release, which can also be used as a base set. And it's a fun meld of a deck building game that uses some of the same kinds of ideas as Magic the Gathering with a miniatures game, and it also has a,

physical board that you can add different types of terrain to that impacts the way that your units can move around the field. So it's got a really great,

dynamic instead of,

rules, and the gameplay is very adaptable and malleable. But at the same time, it's also still constrained and simple enough

to be able to appeal to a very broad range of ages.

So it's a lot of fun, and it has a, it seems seems like it's gonna have a decent amount of staying power as you add some of the different expansions or just modify the terrain using your own different,

pieces that you can build for it. So, definitely fun game to check out. And with that, I'll pass it to you. What are your picks for us this week, Liam? So this week, I have a few picks. The first 1, probably most of you have have,

have tried out or or at least aware of, but I just like to emphasize that this is this is something that I've used really extensively.

GitLab Community Edition is a great,

is a great way to host,

free organizational,

Git repositories.

I've used it with groups of friends to essentially manage the repositories that we didn't wanna

necessarily put public on GitHub.

It's completely free and just allows you to self host your own GitHub clone. And GitLab as an organization,

they they're really committed to transparency,

and they're coming up with new features every day. Their continuous integration system is really innovative,

uses Go and allows you to, like, spin up nodes whenever you want. It's a really a great innovative way of of managing your git repositories. The second is something that I heavily

utilized for for ergonomica for its, terminal support, which is Python prompt toolkit,

Jonathan Slender's,

package that is essentially

an encurses clone, but with sort of your modern amenities of something like qt

that allows you to create

interactive,

terminal applications.

And it's you don't necessarily have to harness it for for creating terminal applications. You can use it to create very simple, very simple prompts, prompt based applications. So you can integrate autocomplete. You can have it automatically suggest previous commands you've typed based on what you've, what you've already typed. You can scroll through history.

It allows you to to create and also provide syntax highlighting, just just a variety of different different things that you would need for for creating a interactive command line prompt. And then my 3rd pick is something that, I've gotten a lot of my old programming books from, like or not necessarily old, but,

like, Lexaniac,

the the UNIX book I have. It essentially allows you to buy used books

at a discounted price. And as a result, you can buy really classic,

programming books and all of your

O'Reilly books for essentially $5 a pop, which makes it great because you can just, for the price of, I don't know, 2 coffees, learn a new learn a new language with the de facto manual. So it's it's a great resource for, for programming and I I believe other other academic books. Thriftbooks is definitely a great shop. I've used it for a number of different additions to my personal library as well, and I continue to go back because it does have a very broad selection of material and, great availability and pricing. Alright. So with that, I would like to say I appreciate you taking the time out of your day to share your work on Ergonomica and your experience in the Python community. And I hope you enjoy the rest of your night. No problem. Thank you.

The Python Podcast.init

Summary

Preface

Interview

Keep In Touch

Picks

Links

The Python Podcast.__init__