CoffeeScript has a feature like that, where a constructor can call parameters `@whatever` and they will be assigned to the object. For all the ways CoffeeScript borrows from Python, but somehow makes it worse, that feature is actually very nice/useful (and not super confusing, either).

you can just do

  class B:
      def __init__(self, a, b, c):
          self.__dict__.update(locals())

You really, really, really shouldn't do this under any circumstances, though. If you find yourself messing with __dict__ you're down a hole, if you find yourself mutating it you're down an even deeper hole, if you find yourself calling locals() you probably forgot your shovel, and I'd hope that for all of that you'd have a better reason than minimizing code (that's way less readable, for example). I immediately get suspicious when I read code that interacts with __dict__ and I'm only sympathetic if you're cooking a metaclass or something equally arcane.

__slots__ also makes __dict__ nonexistent.

Well, yeah, but you could implement it without __dict__ just by doing something like:

  for attr, val in locals().items():
    setattr(self, attr, val)

It still feels pretty un-Pythonic either way.

Because it is. There is zero reason to be clever here. Yeah, you have to be explicit in __init__. We are all used to it. The "a," "b," "c" examples are disingenuous though because you're often validating, enforcing types, converting, deriving other attributes...

__init__ is documentation. I read it to understand what's going on.

That makes B.self a field too, which you probably don't want.

Especially because that creates a circular reference and annoys the garbage collector.

yeah I know, I was wondering if anyone would notice