ericvsmith

> Most US homes actually do receive 240v, it's just done in an unusual biphase configuration with two "hot" phases 180 degrees apart. If you connect a device across the phases it will receive the full 240 volts, which is often done for cookers, clothes dryers, and EV chargers.

It's technically a single phase with two hot legs and a center tap for neutral, also called "split phase". From the neutral to either leg is 120V, from leg to leg is 240V.

https://en.wikipedia.org/wiki/Split-phase_electric_power

It would technically be possible to have a reverse-Y extension cord that plugged into two outlets and gave you a 240V circuit. The two outlets would have to be on different legs, of course. This is basically what a 240V breaker is doing. I've contemplating wiring up one of these for home and buying a British tea kettle, but the aesthetics got my plan vetoed.

Something like: https://www.nooutage.com/images/adaptor-wye.jpg

I feel the same way. I'd love to use macros to implement dataclasses. But it does open the door for unreadable code.

I'm torn on the issue: I don't want to be restricted from improving dataclasses in what would be fairly obvious ways, but I'm sure the feature would be abused. But maybe this falls under the "we're all consenting adults" guideline.

I don't think you're likely to see zero overhead decorators any more than "zero overhead software" in general.

Take dataclasses: it adds a bunch of synthesized methods to a class, and needs to use "exec" to create them. How could that be zero overhead?

To help with this, I've proposed moving knowledge of dataclasses into the Python compiler, but even I don't think it's a great idea. For example, it would leave attrs in a disadvantaged position, and I don't want to do that.

Another option would be to move dataclasses before the code generator. Syntactic macros are one way to do that. Then there really would be zero overhead when loading the cached .pyc files. That's their appeal to me. Of course there are lots of other things that could be done with syntactic macros, which is both good and bad.

I’m contemplating pushing for it in 3.12, but it’s probably more than a year’s worth of work to implement and shepherd the PEP through. So 3.13 is more likely.

And I’m not sure it won’t get shot down anyway. It’s a big step for Python.

See also PEP 638 – Syntactic Macros https://peps.python.org/pep-0638/

Came here to mention unittest.subtest. It's for exactly this case.

You’re in luck! https://m.youtube.com/watch?v=FM8uRAdZ8S0

Matt’s videos have come a long way since this one, but I still refer back to it. I just sharpened a carpenter’s pencil with Matt’s method today!

This was in early March 2020 (so, just pre-Covid). I was using orders@swissmicros.com, because I was responding to the invoice they sent me. And I self-host my email server. Hope that helps.

I had the exact opposite experience. After already owning a DM42, DM41X, and a DM16L, and I bought a DM12L for a client. The screen had several LCD segments that faintly showed as always on. I wrote an email and was contacted by Michael (the founder) almost immediately. He said they'd happily take it back and send me a new one, but it would take a few weeks for shipping from Europe. Instead he suggested that I first try putting it in the oven at 70C (160F for us 'Mericans) for a few hours. So I disassembled it and put just the PCB/display unit in the oven. And sure enough: problem solved!

tl;dr: I thought their service was great.

Although I do love my real HP's, too. I own maybe a dozen. I think the 32sII is my favorite, but I dearly miss my 41CV from back in the day. Maybe I should find a used one of those.

On the programming side: I definitely agree with those saying calculators were/are an entry to programming. My first programs were on an HP-29c. I thought I had invented binary search!

dataclasses do not use metaclasses (I’m the dataclasses author).

I don't understand your point. Are you saying that `__eq__` shouldn't be implemented at all? There's a switch for that, too.

dataclasses makes it easy to just add your own `__eq__` method, if the default doesn't suit you. You just define it! Nothing else is required.

So I wouldn't be so quick to abandon dataclasses in such a case.

I wouldn't say adding dataclasses was "reactionary". One of the reasons for adding it was to use it in the stdlib itself, which is obviously something we couldn't do with attrs. And because dataclasses skipped ahead to just using type hints to define fields, it has less backward-comparability baggage than attrs has.

As I think I made clear in PEP 557, and every time I discuss this with anyone, dataclasses owes a lot to attrs. I think attrs made some great design decisions, in particular to metaclasses or base classes.

dataclasses author here.

Does the keyword-only feature in 3.10 help you at all?

dataclasses author here.

That's not true. You can use make_dataclass the same way you can use namedtuple:

  >>> from dataclasses import make_dataclass
  >>> A = make_dataclass("A", ["x", "y", "z"])
  >>> A(1, 2, 3)
  A(x=1, y=2, z=3)

It is true that if you want to use @dataclass you have to use annotations, just the way you do with typing.NamedTuple. But as others have noted, the annotation is mostly ignored.

[edited for formatting]

nuitka is at https://nuitka.net/

I find that hard to believe, but I'm willing to be wrong. My Apple TV HD is in a cabinet with solid sides and doors (3/4" MDF). The television is wall mounted above it, outside the cabinet, and maybe 12" behind the Apple TV. And yet the Siri Remote controls the volume on the TV. I'm pretty sure it's using IR from the remote to the television to control the television's volume. I guess there's some small chance the volume is being controlled with HDMI ARC, although I've never been able to get my iPhone to control the volume on the television.

Unfortunately I can't find any definitive source on the internet to confirm exactly what's going on.

You'd be better off using "...".format_map(your_dict). This case is exactly why it exists.

f-strings are so much faster that I've seen an increase in speed over %-formatting for logging. If there's even a 10% chance that a string will be actually logged (and therefore %-formatting will take place), I'll replace it with an f-string and not care about the deferred formatting.

Executing user-provided code isn't possible. f-strings must be literals, so there's no user-defined strings involved.

You could of course eval something the user provided, but there's no more of a risk with f-strings than there is with regular code.

This is addressed in PEP 498.

The more efficient version of this is .format_map(locals())

There would be a __future__ import to turn it on, at least for some number of releases. But yeah, I'm not sure it should ever be the default behavior. It makes most sense to me as a per-module opt-in, but then a __future__ import doesn't make sense. And we've resisted having per-module pragmas, so maybe it's dead in the water.

I've put together a proposal to have all strings be f-strings by default.

Then you could drop the "f" prefix. I also propose adding a "p" prefix (for "plain") to remove the f-string parsing behavior.

I talked about it at the last Python core sprint, and it only got lukewarm support, so I'm not sure I'm going to pursue it.

This is because of how f-strings were initially implemented: I piggy-backed them off of "regular" strings, then post-parsed inside that string. But the restriction is that the entire f-string (after the f) needs to be a valid regular Python string.

Since this:

"this is a "regular" string"

isn't valid, then neither is this:

f"dict lookup: {d["key"]}"

However, we've talked about changing f-string parsing from a "post-process regular strings" mode, to instead having the tokenizer and parser themselves aware of f-strings. When we do that, the f-string example above will work.

(edit for formatting)

Yes, attrs is the spiritual parent of dataclasses, including the decision to not use metaclasses. Thanks for mentioning this: I try to always give credit to Hynek and attrs.

Maybe that would have worked better with a metaclass.

But still, I think not using a metaclass is the more flexible design. Maybe I'll add the "add_slots" behavior into the @dataclass decorator in 3.10, even though it would need to return a new class. At least it could be well documented, and I doubt it's a concern for most people.

> Thanks for working on dataclasses :) - as I said, it's my #1 new feature in Python.

I'm offended! I also wrote f-strings, but maybe that's not considered new anymore. In any event, you're welcome!

I have a decorator to add support for slots: https://github.com/ericvsmith/dataclasses/blob/master/datacl... (although I'll admit I haven't tested it in a while).

The reason it's not an option by default is because it would be the one case where the decorator would have to return a new class, and I didn't want to do that on the first version. As it is, @dataclass just modifies an existing class. I might bite the bullet add a slots option, and we've had discussions on adding a language feature to automatically add slots to a class, based on annotations and maybe some other magic. If we did that, we wouldn't need to return a new class. But it's not a front-burner task for me.

Author of dataclasses here.

> (Example - enums are implemented with a metaclass and dataclasses with a class decorator - arguably the latter is the wrong choice, because it is already evident it limits what kind of features can be added to dataclasses).

I'm curious about what features can't be added to dataclasses because it's not using a metaclass.

If anything, I think that not using a metaclasses is a good thing: it allows you to use @dataclass with classes that do require a metaclass. That metaclass would likely be incompatible with the metaclass that such a hypothetical @dataclass implementation would use.

My bad: it's exec(), not eval(). And I wrote dataclasses, so you'd think I'd know better!

The issue is that it's dynamically generating methods. There has to be a way to get dynamically created code into python for this use case.

namedtuple and dataclasses both use eval(), so if you want to give up eval(), you'd need to give them up, too.