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.

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.

This one is an odd one because initially most people I show this one to assume the oddity is that immutable types cannot be mutated in-place.

But tuples can be mutated in-place: >>> b = (1,) >>> b += (2,) >>> b (1, 2)

The odd thing is that lists can be in-place added (+='d) to any iterable, while tuples can only be in-place added to tuples.

I think it works this way so that += on lists works consistently with the extend method on lists, which also accepts any iterable.

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.

Inconsolata: https://en.wikipedia.org/wiki/Inconsolata

That's kind of what generator expressions are actually :)

https://www.python.org/dev/peps/pep-0289/

You can pass them into anything that expects an iterable. That's pretty much the same since iterable types will frequently consume an iterable in their constructor.

For example, here's a "tuple comprehension" (really just a generator expression passed to a tuple):

>>> tuple(x for x in [1, 2, 3])

Same thing passed to list and set constructors (which you'd never do because we have the special comprehension syntax for those:

>>> list(x for x in [1, 2, 3])

>>> set(x for x in [1, 2, 3])

I explained these in a very slightly different way in the linked webinar I linked in the post: https://youtu.be/u-mhKtC1Xh4?t=35m05s

Agreed! Haskell's list comprehensions look even more like set-builder notation: https://wiki.haskell.org/List_comprehension

I agree. I was using "List Comprehensions: Now In Color" as a working title but I thought that was too nonsensical. It was actually the colorized code and not the gifs in particular that made me think "visual".

Sorry for the misleading title!

I usually post the event details. The event is pretty much self-organizing at this point.

There is a community-contributed EditorConfig NetBeans plugin but it doesn't have a license or installation instructions: https://github.com/geertjanw/editorconfig-netbeans

If your favorite editor does not yet have an EditorConfig plugin, feel free to tweet @EditorConfig or open an issue.

The Eclipse plugin has a small bounty on it right now. Maybe someone will create one if some more money is pitched in: https://freedomsponsors.org/issue/271/support-eclipse

EditorConfig support built-in to your text editor is the pipe dream. JetBrains 9 will have EditorConfig support, but no other editors yet support it natively so all of the plugins are necessary currently.

Unfortunately many editors do not support project-level configuration files by default. A conversion tool could be a good way to make global configurations even more accessible for editors that do support project configuration files and don't have native EditorConfig support yet.

Until native support becomes more common, EditorConfig acts as an unopinionated universal editor-level linter of sorts.

We "launched" a couple years ago with support for only a handful of editors. Most of the plugins have been community-made.

No one has submitted an Eclipse plugin yet, but we would love to help make one happen.

Native support is the ultimate goal. WebStorm 9 will have EditorConfig support built-in (as noted here: https://www.jetbrains.com/webstorm/nextversion/).

I would also like an Ohlife import service (or any other API that could be used for importing).