[Python-Dev] Breaking calls to object.init/new (original) (raw)
Guido van Rossum guido at python.org
Thu Mar 22 22:28:33 CET 2007
- Previous message: [Python-Dev] Breaking calls to object.__init__/__new__
- Next message: [Python-Dev] Breaking calls to object.__init__/__new__
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Can we move this to c.l.py or python-ideas? I don't think it has any bearing on the decision on whether object.init() or object.new() should reject excess arguments. Or if it does I've lost the connection through the various long articles.
I also would like to ask Mr. Olsen to tone down his rhetoric a bit. There's nothing unpythonic about designing an API using positional arguments.
--Guido
On 3/22/07, Adam Olsen <rhamph at gmail.com> wrote:
On 3/22/07, Thomas Wouters <thomas at python.org> wrote: > On 3/22/07, Adam Olsen <rhamph at gmail.com> wrote: > > In general. Too many things could fail without errors, so it wasn't > > obvious how to use it correctly. None of the articles I've read > > helped either. > > I've been thinking about writing an article that explains how to use > super(), so let's start here :) This is a long post that I'll probably > eventually copy-paste-and-edit into an article of some sort, when I get the > time. Please do comment, except with 'MI is insane' -- I already know that. > Nevertheless, I think MI has its uses.
I'm going to be blunt, and I apologize if I offend. In short, your article is no better than any of the others. TOOWTDI What you've done is list off various ways why multiple inheritance and super() can fail, and then provide a toolbox from which a programmer can cobble together a solution to fit their exact needs. It's not pythonic. What we need is a single style that can be applied consistently to 90+% of problems while still requiring minimal effort to read later. Using keyword arguments and consuming them is the best I've seen so far. Sure it's a little verbose, but the verbosity is repetitive and easy to tune out. It also requires the classes to cooperate. News flash: Python isn't C++ or Java. Python uses a shared dict rather than private namespaces in each class. Python always requires the classes to cooperate. If you want to combine uncooperative classes you need to use delegation. I'm sure somebody could whip up a metaclass to automate it, especially with the new metaclass syntax, not to mention ABCs to say "I'm string-ish" when you're delegating str. -- Adam Olsen, aka Rhamphoryncus
-- --Guido van Rossum (home page: http://www.python.org/~guido/)
- Previous message: [Python-Dev] Breaking calls to object.__init__/__new__
- Next message: [Python-Dev] Breaking calls to object.__init__/__new__
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]