> Hello from your @PyCon Diversity Chair. % PyCon talks by women: (2011: 1%), (2012: 7%), (2013: 15%), (2014/15: 33%), (2016: 40%). #pycon2016
Increased diversity in communities usually comes from active outreach work. PyCon's talk selection process starts blinded.
If 300 people submit talks and 294 are men, then 98% of talks will likely be from men.
If 500 people submit talks and 394 are men, then ~79% will likely be by men.
Outreach to encourage folks to apply/join/run/etc. can make a big difference in the makeup of applicants and the makeup of the end results. Bucking the trend even during just one year can start a snowball effect that moves the needle further in future years.
The world doesn't run on merit. Who you know, whether you've been invited in to the club, and whether you feel you belong all affect where you end up. So unusually homogenous communities (which feel hard for outsiders to break into) can arise even without deliberate discrimination.
Organizations like the PSF could choose to say "let's avoid outreach work and simply accept the status quo forever", but I would much rather see the Python community become more diverse and welcoming over time.
I created a tool over the weekend to guess the f-string you seek: http://pym.dev/format
I'm also the author of https://fstring.help/cheat/ (though not of the homepage) and I haven't yet linked back to that new tool. I was surprised to the cheat sheet here today but not the format guesser.
Something important to note: many folks take their masks off for a picture, then put their masks back on. This leads non-candid photos having far few masks in them.
I think this post will be great for PyCon newcomers. Getting the chance to experience a play-by-play of a past PyCon before attending your first PyCon might be even more useful than reading the various "how to have a great first PyCon" posts that many of us have written.
Al Sweigart, Eric Matthes, Reuven Lerner (also in this comment section), and so many folks who've made blog posts, books, code, or something else that's inspired you really do love it when you tell them. I know I'm always please when someone who likes something I've done introduces themselves and says so.
We're all just people. Meeting someone in-person who enjoys something you've done is enjoyable for nearly everyone. Fawning is a bit much, but a "thank you for what you do" is really lovely.
If you're not sure how to "break in": keep the Pac-Man rule that's often embraced at PyCon in mind. If there's an open spot in a huddled group or if the group seems to notice you eyeing them and make a spot for you, join the group. Feel free to just fish bowl the conversation. Most of the time I've seen this happen, eventually someone chats with whoever just joined the conversation. Don't be afraid to either keep fish bowling or walk away if the conversation isn't what you were expecting. Either are acceptable.
You noted that you're afraid of being rude. That means you're exactly the person most folks would love to chat with since you're probably both humble and kind. :)
Until the 3.13 release, here's a trick on pasting: the paste function from https://nedbatchelder.com/blog/201904/startuppy.html will accept pasted input and then evaluate it as code (after EOF is sent via Ctrl+D on Linux/Mac or Ctrl+Z Enter on Windows).
Adding that function to a $PYTHONSTARTUP file will make it available automatically every time you launch the REPL.
It's definitely a hack, but it's a pretty decent workaround for now. I'll likely continue to use it even after the new REPL launches because the textwrap.dedent call will auto-unindent indented code (when pasting from a markdown or reStructuredText file for example).
> Trey, if you're reading this, hello from a former TA!
Hi former TA! It's been a long time.
> Unfortunately in almost every case, dunder methods made it harder for me to collaborate with other people on the same codebase.
I see dunder methods as methods that should usually (with the exception of __init__, __repr__, and __eq__) be used much more often than they're read.
I typically use dunder methods when implementing a library or framework that's meant to be used by others who would be looking at its documentation but not necessarily its code.
For example the dramatic library I published over the weekend relies on __enter__, __exit__, and __del__ (which is a very uncommon one typically): https://pypi.org/project/dramatic/
Users of that code shouldn't need to look at the code.
For code that's modified by newer Python users often, using dunder methods might be more difficult to justify. Though you might be able to get away with making a library which that could could use.
Great point. I do agree that those who use sets heavily should probably know about frozenset. :)
I've never very rarely seen these used in production code though. I'm also not as strongly biased toward them because set objects in my own code are often pretty short-lived so their mutability rarely matters.
Thanks for noting this. I rarely look at my site on mobile and hadn't noticed how big that widget was. I just spent a few minutes making it less visually obtrusive. I may figure out more ways to improve it later.
Side note: I typically bold many sentences in my articles, but this is the first article in a while where I actually bolded nearly no words at all. I wonder what my other articles look like in your browser.
It's also not an issue in Python's dictionary literal syntax:
>>> {{'a': 1}, {'a': 2}}
{'a': 2}
So the multiple keyword argument problem isn't an inherent issue with so much as it's a problem with keyword arguments being specified twice (which has been a restriction since before they allowed multiple to be used).
I think they're pretty much a collection of tweets. This was the first time I used moments and I'm not sure where I saw them used before I made this.
They're mostly by me because I made a goal for myself to tweet out one of these every week for a year. Others have shared their own and I've tweeted my own since then, but Twitter's hashtag search is pretty bad so I made a moment.
Thanks for the critique. I'm not sure I added much to that analysis on Stack Overflow outside of headers, a few more opinions, and a little bit more explanation. I mostly wrote to have something to link my students to because this question has come up before and I didn't find any of the more comprehensive SO answers to be easily digestible/skim-able.
The python-ideas thread from last year about using + on dictionaries was also an inspiration. I don't recommend reading it in full (there's some painful debating) but there were some really interesting concerns brought up on there in regards to this particular problem.
In regards to newcomers being scared away by criticism on Stack Overflow: I completely sympathize with this point of view. New Python programmers and new programmers especially should not worry about what is "pythonic" until they've become comfortable with their own Python programming abilities. Working and readable code is most important, idiomatic code is simply icing on the cake.
I do however value discussions of what is "pythonic". I often discuss "pythonic" in my classes to instill the idea that community norms change from language to language and even between frameworks and projects.
I really hope the wording of this post didn't come off as elitist. If so, I will certainly need to reconsider my wording for the next one.
A relevant tweet from 2016 (https://x.com/jessicamckellar/status/737299461563502595):
> Hello from your @PyCon Diversity Chair. % PyCon talks by women: (2011: 1%), (2012: 7%), (2013: 15%), (2014/15: 33%), (2016: 40%). #pycon2016
Increased diversity in communities usually comes from active outreach work. PyCon's talk selection process starts blinded.
If 300 people submit talks and 294 are men, then 98% of talks will likely be from men.
If 500 people submit talks and 394 are men, then ~79% will likely be by men.
Outreach to encourage folks to apply/join/run/etc. can make a big difference in the makeup of applicants and the makeup of the end results. Bucking the trend even during just one year can start a snowball effect that moves the needle further in future years.
The world doesn't run on merit. Who you know, whether you've been invited in to the club, and whether you feel you belong all affect where you end up. So unusually homogenous communities (which feel hard for outsiders to break into) can arise even without deliberate discrimination.
Organizations like the PSF could choose to say "let's avoid outreach work and simply accept the status quo forever", but I would much rather see the Python community become more diverse and welcoming over time.