Paul Ganssle @pganssle@qoto.org

@eric Though also the main computer is connected to the router with an Ethernet cable.

@2ck It's an Uplift V2 C-frame (I think corporate configuration - it goes very low, like 22" or so).

@eric WiFi is directly above my head, and there's no insulation overhead, so if the insulation interferes with the signal I haven't noticed.

Doesn't seem to affect my cell phone service, though, so I think it's probably not very effective RF shielding.

@Sphinx Yeah, I believe the dock is doing the work there.

@Sphinx It's the laptop. The monitors are connected to a dock. My work and home laptops are both Thinkpads so I put the main one I'm using at a given moment on the dock (which is also connected to all the various peripherals — keyboard, mouse, microphone, webcam, etc).

@freemo Haha, yeah everyone always comments on the reflective insulation. It's making me hesitate about putting accoustic damping panels on the wall behind my desk...

The workbench has taken its rightful place as a work station for electronics and such (though some of the components migrate to the main desk if I need to program a microcontroller...)

This is likely the last picture of a tidy workbench I'll get for a while.

"Bigger" here means 27" or 32". I probably would have upgraded long ago, but I find it hard to tell whether my day-to-day experience (using Linux and not playing games) would be significantly degraded by getting some of the drastically cheaper models available.

Some steps in the evolution of my workstation:

1. Workbench as desk
2-3. Switched to standing desk
4. Added monitor arms

Next steps: Get at least one bigger monitor, setup up my cable management game.

@freemo Yes, very much so! My first keynote.

I'm still a little sad that I can't do it in person, but logistically it's challenging to get there and back anyway (particularly with a family in tow), so it's probably for the best that it's virtual.

Exciting announcement: I'll be giving a keynote talk at PyConf Hyderabad, which will place December 5-6th, 2020 (virtually, this year):

https://twitter.com/pyconfhyd/status/1321728958052794368?s=20

Tickets are available here: https://pyconf.hydpy.org/2020/

CfP is still open until November 8th: https://twitter.com/pyconfhyd/status/1313690523555819522?s=20

#PyConfHyd2020 #python

@jasper I do think it's the sort of thing that hurts our ability to write optimizing compilers and such without modifying semantics. It's hard to do constant folding and such when the "constant" is actually an attribute on a mutable object (and may even be dynamically returned, see PEP 562: https://www.python.org/dev/peps/pep-0562/)

@jasper Some classes and objects can be made immutable (or, at least, immutable enough), but it's certainly not the default.

At the end of the day, I think the ability to monkey patch modules and classes is a net benefit. Everyone knows that it's a code smell, so it's not done widely, but the fact that you can do it allows you to avoid some other even worse patterns.

I just had a thread about this, actually: https://qoto.org/@pganssle/105107544104982635

@freemo Though I'm fine if it's not, it just means that I'm less likely to be able to take advantage of the features in some scenarios, which is not necessarily a big deal.

@freemo Yeah, presumably individual clients will support different features — that's one of the great benefits of choosing your own client.

The only worry I have is that if each instance implements "remote timeline" a little differently, every client needs to support every implementation. Most projects don't want to support every idiosyncratic thing on every instance, but would be happy to be "fully featured" clients if there's wide adoption of a non-standard feature.

I'm curious to know if you are developing /implementing this stuff in a siloed way, or if it's part of a broader "Mastodon+" type effort that is likely to be worth clients' effort to support.

Of course, there are legitimate reasons for this sort of dependency injection-style parameterization, but adding support for arbitrary interfaces broadens your "supported configuration surface" so much that usually it doesn't pass the YAGNI test — unless you need it for tests.

That's obviously a pithy twitter-sized take, but I think most of the time when you have some highly parameterized class / function, you aren't doing it because you actually want to support an interface where someone supplies their own provider of some core language functionality.

You do it because it makes your testing easier, and you can nominally it allows you to test using only the public interface.

That sort of thing is a necessity in languages without monkey patching, but it seems like it's a considerably worse code smell than patching in tests.

Listening to Anna-Lena Popkes on @TalkPython@twitter.com and I realized something I've never consciously understood: mocking is bad because it is tightly coupled to implementation details, but dependency injection solves this problem by promoting those details to be part of the public API.