 Like I know what I'm doing. Hi, I'm Thursday. I am here to talk to you about naming Python projects because I'm a word nerd and I've been writing about Python for a while. And as a result, I have some very strong opinions that I would like to share with all of you. So I'm a fan of telling you what I'm going to tell you before I tell it to you. So let's start with a couple of content notes. This talk does touch on codes of conduct, colonization, national disasters, ageism, racism, interpersonal violence, and actual snakes. We'll also be covering this outline. Why names matter, Python's naming schemas, actually naming things, and assessing name ideas effectively. So I think we can all agree that naming matters. Nameset expectations, a conference with a location name and its title is probably going to be set in that location. A Python module with the word test in it will probably do something to do with testing. If North Bay Python took place South of the Bay, we'd all have some questions, right? So names create first impressions. Just reading the name of a project can immediately tell somebody whether they're going to contribute, whether they're going to use it. I've seen plenty of offensive library names out there, and I've decided not to use those libraries just because of their names. I don't need to look if they even have a code of conduct if there's a name like that. I don't need to look at their quality of the code. I can just move on. I'm not going to give any examples of those names in this talk, because I don't want to say them on a stage. If you really want to talk about those later, I would be happy to talk about that in private. There's also a business case against using software modules with problematic names if you work at one of those companies or organizations that requires a business case to do the right thing. So if you're looking at a library or a module with a problematic name, the person who's the core maintainer, the team that's maintaining it, has proven themselves unable to respond to feedback about their name. I don't even want to think about how poorly a group like that is going to be able to consider security risks that don't impact them directly. If a library can't be secured, most organizations don't want to use it. So let's talk about how names endure. Think about where we are right now. We're in Petaluma. We're in Sonoma County. We're in California. We're in the United States of America. Well, the US got its name during the American Revolution. It was purposely structured to make sure that a bunch of colonies sounded like they were working together, sounded like they knew what they were doing. It was kind of a marketing ploy. California is named for a magical island from a 16th century Spanish romance novel. So yeah, this state, we use name from a bunch of Spanish conquistadors thinking fondly about love stories they grew up with. And then there's Sonoma and Petaluma. Both those words, both those names, come from coastal Miwok words made to sound more acceptable to the Europeans who colonized this area. Sonoma's root word means Valley of the Moon. Petaluma was the name of the Miwok town located roughly here prior to the area being controlled by the Spanish, the English, the Spanish, again, the Russians, the Mexican Empire, the Mexican Republic, the California Republic, the United States of America. I think that brings us up to today. Most of the dialects of Miwok are now extinct due to the US's genocidal policies with some European colonizing help. Before 1579, coastal Miwok tribal land included all of Marin County plus Southern Sonoma County. By 1817, the only land still directly controlled by the coastal Miwok was the Pacific coast of the Marin Peninsula just from Point Reyes North to Bodega Bay. In 1920, Miwok and southern Pomo tribes tried to move on to the sort of reservation or trust-held land the government had designated for them, a whopping 15 acres, only to find that only three of those acres were habitable. The US government dissolved that reservation, that trust, in 1958, and up until 2000, there was no federal recognition that the people who gave us the name for this town even existed. There's been a restoration act passed in 2000, but there's still no land. There's still nothing available with that. So sorry, but the point there is that the name of Petaluma has endured. It has lasted through all of those different eras of control and still means something to each of us here. That's because humans relate to names in very deeply emotional and often entirely unnoticed ways. So for a slightly more happy kind of example, I want to talk about natural disasters. This is the fun talk, right? So University of Michigan researchers wanted to determine if people gave more to hurricane aid causes based on any connection they formed with the name of the hurricane. And they found that there was a significant impact. People who shared a first initial with the name of the hurricane in question were significantly more likely to donate. So Kellys and Kais and Khadijas were much more likely to donate to relief efforts for Hurricane Katrina than Hurricane Mitch. Correlation, of course, isn't causation, but I will guarantee you that there is someone out there trying to figure out a new naming schema for hurricanes so that they can raise more money. They just have to match the first initial distribution of the general population. All of this is to say that names don't exist in a vacuum. We have to understand the context and the nuances and how other people see those names in order to make sure that they're effective. So who here knows where Python programming got its name? Let's just hear it. That's right. So Monty Python is a British sketch troupe who have turned 45 episodes made between 1969 and 1973 into this whole cultural thing. They've made movies, they've made books, games, musical, and all of these other things. And I'm saying all of this. I'm making sure to describe exactly what Monty Python is because we can't assume that everyone using the Python programming language is also culturally fluent in Monty Python. I have heard, and this makes me feel a little old, but I've heard from an actual programmer in the Python community, Monty Python, I think my grandparents watched that. Kids these days on my lawn. But part of that is because Monty Python turns 50 next year. The next year is the 50th anniversary. We might as well be asking new programmers to get references to the Beverly Hillbillies, Petticoat Junction, a little Green Anchors. And none of that is a problem in and of itself. But some shows, some pieces of culture, age better than others. Monty Python is not aging as well as one might hope. So by expecting Python programmers to be familiar with Monty Python's body of work, we're sending them to look at lists of sketches and episode titles that include derogatory terms, including the N-word. I don't think any of us want to accidentally endorse something like that. So all of this is not to say that you can't ever make a Monty Python reference again. Instead, we have to consider the context of our references before we slap them on projects we want to share with the whole world. Monty Python will always be a part of our Python programming community. But that doesn't say that all of our references, all of our internal culture, have to be based on one TV show that is a little bit older than some of our programmers. We have far more options. So in the Python programming committee, we have established some standard naming schemas, both formally and informally. Pep 8 is the style guide for Python code. And one of the pieces that includes is some naming conventions for variables, method names, those other pieces. It doesn't directly include suggestions for how to name projects, but there is a piece of advice that I would like to have engraved on something shiny and put in front of all of us while we are choosing names. So this one right here. I want you to avoid using names that include the lowercase letter I, the uppercase letter O, or the uppercase letter I, because they are harder to read. They're less accessible. And if somebody is trying to type them in a hurry, if they're trying to start using a library for the first time, those are pieces that make it just a little bit harder. If we can make names easier to read and retype, more people will remember them, more people will use the libraries associated. We also have some less formal systems, especially for group names or project names. For instance, many Python conferences and user groups include the city that they're located in as part of their organizational name. Geography is a relatively easy way to disambiguate different local communities from a larger overarching community. We can tell that PyLadies Atlanta and PyLadies Santo Domingo are two separate groups just based on that geographic indicator. And in some ways, geography is an even better option because there are set three-letter codes, unique identifiers for most cities, any city with an airport. Those are called IATA codes. An IATA is an organization that makes sure that these codes are unique, since there are some very important differences between Portland, Oregon, and Portland, Maine. Aside from being very far apart, my cats are in Portland, Oregon, and they would like me to come back and feed them. So buying my ticket matters to them. And these IATA codes become very popular as nicknames or identifiers. I'm part of PyLadies PDX, for example. Not all cities' IATA codes are exactly intuitive. Chicago, I am looking at your airports right now because I will never remember that tickets to both ORD and MDW will get me to Chicago. Luckily, the computer figures that part out. But the Py part of PyLadies has become a very important piece that is memorable. It's a prefix that's used in a lot of different modules and a lot of different projects as an indicator that it has something to do with Python. Some projects have chosen words whose letters already include Py, like Pyramid, Pyramid, sorry. PI, spelled with an I instead of a Y, is also pronounced the same way, at least in English. So there are some names that use non-standard spelling, like Project Jupiter. And then there's the word Py, P-I-E, which sounds like Py, P-U-I, but is more delicious. And we've seen projects with that as a naming schema like Cherry Pie. A lot of projects also develop their own internal naming schemas, and for good reason. When a project has multiple pieces that are branded together, users are more likely to realize that they can use all the different pieces you create and that they plug in together. Beware, for instance, uses a combination of bees, history, and a slightly absurd number of puns to create very descriptive names for each piece of the project. First off, Beware itself has a subtitle. It's a full name, if you will. It's Beware, the IDEs of Python, as in what Julius Caesar heard in the Shakespeare play of the same name, slightly before a bunch of guys in Toga's assassinated him, except we're talking about interactive development environments instead of the middle of March, same difference. As it happens in Beware, Toga is the name of a library which produces wrappers, specifically, yes, wrappers. Specifically, it's wrappers for GUI APIs. And in fine Beware form, the name of Beware's pre-validator is B4 with two E's. Yeah. If it sounds like I'm saying a lot of names, that's because I am, we name a lot of things. That might, in fact, be the human conditionist pointing to something and say, hey, I'm gonna call that something. And we name things pretty fast, too. We've got so many new projects coming out that if we aren't paying attention to what's already out there, it's very easy to name projects with names that are already in use. For example, I think everybody in here has at least heard of Django, the Python web framework. But how many of you have heard of Django software, which is a piece of tablature software for musicians? If you just search for Django software for this piece of music, you're gonna get Python results, even though that's not necessarily what you're looking for. Name collisions like these are pretty annoying. It's annoying when you're debugging a program, but it's a full-on pain in the rear when you were trying to search for help online. How many times have you walked out of a meetup or a conference with a module that you wanna try to remember and look up when you get home? Well, you might remember it if the project name is memorable. Maybe one of the people at the conference or the meetup might send you the link, or you wind up having to go through search engines and adding and subtracting key words until you get what you're looking for. It's like you have to come up with the right incantation to summon the library you wanna work with. And if you're looking for Python modules to help you with herpetology research, I don't even know what to tell you to search for. Except some other herpetologists have made things worse by naming a species of Python snakes after Monty Python. So, I think we can very easily conclude that name collisions are everywhere and they are our future and they are awful. So I went over all of that first set of material with you so that we could talk about this checklist. This is the slide you're probably going to wanna photograph of. In short, we wanna go through a due diligence process when we choose and finalize the name for a new project. Some of these steps can happen in different orders but I want you to try to check off every step on this list before buying that sweet, sweet domain name you just found. And if you're concerned that following these rules will limit your choices on domain names, I promise you they don't. I try to follow these rules whenever I buy a new domain name and I have so many domain names that it's ridiculous. There are plenty of good ones still out there. So, as you're doing your due diligence, you're gonna wanna check for how this name may be used elsewhere. That can be as simple as just doing a couple of online searches to start with. Go to Google or DuckDuckGo or whatever flavor of search engine you prefer and just type in what you're looking for. Type in that word. Go a couple of pages deep in the results. Depending on the words, you may luck out and get a Wikipedia disambiguation page which does like 90% of this work for you. Not always, but sometimes we like luck out. But on a practical level, we're looking for some very specific things. We wanna look at that computing section on the Wikipedia page if we find it and we wanna look for other software related terms because most people aren't going to mistake a snake for a line of Python code but if it was a library for something like Ruby that happened to be named Python, nobody would ever find anything again. You're gonna wanna do the same on some social media platforms. Twitter can be a pretty good option. You wanna click around and see what tweets mention the keywords you're thinking about, what user names already have them. One of the reasons that Twitter is really helpful is when people are launching new projects, they're likely to put it on social media. So Twitter has kind of almost more up-to-date list of who's using certain keywords than anybody else. I've also found that it's pretty helpful for surfacing name collisions in other languages that I don't speak because it just pulls up everything. You should also go to Urban Dictionary and search there. But before you type anything in, thank you, I wanna point out that it is not safe for work, routinely. In this case, though, I want you to look for those not-safe-for-work terms because if they relate to your name, you might be too mature to respond to that opportunity, but others might giggle or find it offensive and I might make a joke because I'm terrible. I also recommend don't send an intern or a first-time contributor to Urban Dictionary. I don't know if it falls under a code of conduct or anything, but it just seems like a bad idea. But basically, we're looking for who's using that word, what ways are they using it, and any terrible ways that a board 13-year-old can twist your project name. We won't ever catch everything, but we can make it a little bit harder for those bad jokes to creep through. You're also going to wanna check in with your potential users about your name. Spend just as much time talking to potential users as you do on more visual user experiences. Check how they spell the name when they hear it for the first time. Check how they pronounce it when they read it for the first time. These might sound like marketing exercises, but it's really a question of accessibility and usability. If somebody can't figure out how to spell your tool to search for it, they're dealing with a higher level of friction that can kind of prevent them from even considering your tool. They don't even have to scroll around to figure it out because they can't find it. I also wanna make a point of recommending that you talk to people outside of tech. You will never ever be able to guess all the things that people will associate with a word, and you won't be able to guess where things pop up. I like using my family members as one of these people, just one because they're very similar to me and I want as many varieties of opinions as possible, but my family in medicine often has questions about Bitcoin. You can't prevent people from getting technical information no matter how many family members you wanna ban from cryptocurrencies. I also really like asking small children because you will get every poop joke you could ever imagine about your name, and a lot of adults are strangely uncomfortable bringing up possible scatological references. Lastly, I want you to think about in-jokes. A person with a little distance from your project can kind of help you catch names that rely too much on in-jokes because in-jokes, they may seem obvious if you're already using a tool, but if you aren't, you may not get it. And having to try to figure out that just adds another level of complex when somebody's trying to learn a new library. Maybe talk to a lawyer depending on the situation. I am not a lawyer, you should not take my legal advice, but I usually don't feel the need to talk to a lawyer before setting a name for a new project. It's like edge cases, like if you're accidentally using something that a multinational corporation has already claimed. Lastly, I want you to treat listening as a separate step because we don't just want first impressions. We wanna know the jokes that take people a minute to remember. We wanna hear after they go away, oh crap, do you know what that sounds like? We want all of those comments. All right. Luckily, oh, I'm at two minutes. I'm going to speed up a little bit. So one of the big things about new projects is checking if you can get the domain names, the GitHub repos, all those different pieces. If it's a project that is a little bit older, you may have to go and talk to somebody about if it's actually still happening. If it's defunct, you might be able to get them to let you have the domain name or the account names. In Python, we can often assume that everybody here is a little bit technically savvy enough to use domain names that aren't .coms. So we can look at options like .io. And by options, I mean options for more research because the .io domain name is assigned to the part of the Indian Ocean currently referred to as the British Indian Ocean Territory. This is an area that was previously known as the Shagos Islands, mostly to the Shagosians who the British forcibly removed from the islands in 1966. Oh look, another terrible example of how names reflect colonization. You can use a .io address, but you have to take into account that there are people online talking about decolonizing that address and what it means. I also want you to write down everything about your name in your documentation, please, for my sake. One of the reasons I got into all of this is because PyCute doesn't have its pronunciation listed anywhere. This was the first result in Google for how to pronounce PyCute. Any sort of details that you can include, anything, any problems that you can head off, you should totally put those in the documentation. And go ahead and tell any jokes that go along with your project's name in the documentation. Humor is amazingly memorable, but we only get that memory boost when we get the joke. Jokes are still funny when they're shared. All right, takeaways. This is what we went over. We talked about why names matter. Maybe Monty Python isn't the awesomest for naming conventions, and do your due diligence. This is my contact information. This is the link to the Style Guide supplement that I'm writing about Python. I have watched all of Monty Python. I have read 29 years' worth of blog posts and mailing lists and release notes, and now none of you have to, because I'm writing it all down. If you have any questions, you can reach me there. You can find me later. And lastly, please go vote on Tuesday for all of us. So last year, when I was at PyCon US and started floating the idea of running a Python conference up here in Petaluma, I told lots of people the idea, and every single time I told people the idea, they're like, oh, PyTaluma. Thank you, Thursday, for making me feel smug about making the right decision for naming this event. You did. You made the right decision. Here's a wonderful design in Petaluma Camelback water bottle. And finally, we on the team have all made extensive use of the Responsible Communication Style Guide. Thank you so much for helping make our communications in the conference better. Everybody, Thursday, Bram. Thank you.