Funny how stuff like this plays out sometimes:

My cog tool has been having a resurgence of late: a number of people are discovering it’s useful to run a little bit of Python code inside otherwise static files.

He goes on to list out a bunch of tweets from people finding it useful for various tasks and even got to talk about the project on podcast.__init__. Cool tool, cool story.

Ned Batchelder, after reading some code to termine whether or not it was “Pythonic”:

My first response was that I don’t like this code, because I had to read it with my eyebrows. That is, I furrow my brow, and read slowly, and scowl at the code as I puzzle through it. This code is dense and tricky.

Is it Pythonic? I guess in the sense that it uses a number of Python-specific constructs and tools, yes. But not in the sense of Python code being clear and straightforward. It uses Python thoroughly, but misses the spirit.

(He then rewrites it in a way that he likes. Which solution do you prefer?)

I’m no Pythonista, so I don’t know what is or isn’t “Pythonic”. However, I do know that I love the phrase, “read it with my eyebrows”, because I’ve quite literally done this my entire career. I used to invoke my eyebrows and conclude that I was just bad at reading code. Now when I invoke them I conclude that the code I’m reading is bad.

Ned Batchelder asks the question:

“How do you make a space that is good for beginners when there are too many experts who also want to help?”

He has a few ideas, but mostly Ned is looking for advice/ideas from others. This is a challenging problem for many reasons. How would you approach it?

Ned Batchelder:

Helping people online is difficult. We expect technical questions and discussions, but everyone involved are just people, so it doesn’t always go smoothly. There’s no way to guarantee a good outcome, but there are things we as helpers can do to improve the interactions.

Ned shares a dozen ways we can work to be more helpful online. Excellent stuff. 👌

Mocking is a powerful technique for isolating tests from undesired interactions among components. But often people find their mock isn’t taking effect, and it’s not clear why. Hopefully this explanation will clear things up.

Mocking isn’t always the best test isolation technique, but if/when you use it, you might as well use it correctly. Ned’s here to help you do just that.

In this episode we’re shinning our maintainer spotlight on Ned Batchelder. Ned is one of the lucky ones out there that gets to double-dip — his day job is working on open source at edX, working on the Open edX community team. Ned is also a “single maintainer” of coverage.py - a tool for measuring code coverage of Python programs. This episode with Ned kicks off the first of many in our maintainer spotlight series where we dig deep into the life of an open source software maintainer. We’re producing this series in partnership with Tidelift. Huge thanks to Tidelift for making this series possible.

Ned Batchelder:

if you want someone to do something, you have to give them a compelling reason to do it, and you have to make it as easy as possible for them to do it. That is, you need to have good answers to Why? and How?

Let’s look at the Why and How model as it applies to corporations funding open source. They don’t do it because the answers to Why and How are really bad right now.

I interviewed Ned for an upcoming maintainer-focused series of The Changelog. He’s been in the game a long time and has a lot of interesting things to say.