th

It seems like a number of the "DEI is anti-merit discrimination" messages in this thread are overlooking how DEI work usually works.

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.

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.

Thank you so much for your kind words! I'm really glad you found Python Morsels useful.

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.

This is such a thorough post. Thanks Kati!

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.

It was great seeing you at PyCon! :)

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.

I've never seen a ___tunder___ method, but I've definitely seen a _sunder_ method floating around in some third-party library years back.

A simple _wondur method is probably a bit more common though.

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.

Thanks Santiago! :)

I'm curious about what browser you're using.

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).

Thanks for reporting this issue!

I think you may be taking the word oddity different than I meant it. These are things that trip up my students when they're learning Python.

I left out error messages (and occasionally other things) because Twitter.

I don't think any of the ones I put in this moment should be considered bugs. Many of these are core language features.