tags:

views:

785

answers:

5

I'm wondering if Python has anything like the C# anonymous classes feature. To clarify, here's a sample C# snippet:

var foo = new { x = 1, y = 2 };
var bar = new { y = 2, x = 1 };
foo.Equals(bar); // "true"

In Python, I would imagine something like this:

foo = record(x = 1, y = 2)
bar = record(y = 2, x = 1)
foo == bar  # true

The specific requirement is being able to create an object with specified fields in expression context (e.g. usable in lambdas and other places where statements aren't allowed), with no additional external declarations, and ability to access individual components by name via the normal member access syntax foo.bar. The created object should also implement structural comparison by component names (not by position, as tuples do).

In particular: tuples isn't it because their components are not named; classes isn't it because they require a declaration; dicts isn't it because they have undesired foo["bar"] syntax to access components.

namedtuple isn't it, because it still requires a name even if you define the type inline, and the comparison is position-based, not name-based. In particular:

 def foo(): return namedtuple("Foo", "x y")(x = 1, y = 2)
 def bar(): return namedtuple("Foo", "y x")(x = 1, y = 2)
 foo() == bar()   # False because fields are compared in order, and not by name
                  # True would be desired instead

I know how to write such a thing in Python if needed. But I would like to know if there's anything like that in the Python standard library, or any popular third-party libraries.

[EDIT]

Just for the sake of it, here's a single-expression solution that combines two very informative answers by Ken and alanlcode, yielding structural equality without any extra outside declarations:

type("", (), { \
    "__init__": (lambda self, **kwargs: self.__dict__.update(kwargs)), \
    "__eq__": (lambda self, other: self.__dict__ == other.__dict__) } \
)(x = 1, y = 2)

Technically, it satisfies all the requirements of the question, but I sincerely hope that no-one ever uses it (I definitely won't).

+14  A: 

The pythonic way would be to use a dict:

>>> foo = dict(x=1, y=2)
>>> bar = dict(y=2, x=1)
>>> foo == bar
True

Meets all your requirements except that you still have to do foo['x'] instead of foo.x.

If that's a problem, you could easily define a class such as:

class Bunch(object):
    def __init__(self, **kwds):
        self.__dict__.update(kwds)

    def __eq__(self, other):
        return self.__dict__ == other.__dict__

Or, a nice and short one

class Bunch(dict):
    __getattr__, __setattr__ = dict.get, dict.__setitem__

(but note that this second one has problems as Alex points out in his comment!)

dF
From the question - " ... dicts isn't it because they have undesired foo["bar"] syntax to access components."
too much php
this works, except to access things it is foo['x'], not foo.x
Mike Cooper
as I mentioned in my main comment, dictionaries also have a 'get' method for retireving a key's value: foo.get('bar')
monkut
Nonetheless, the request is what it is, and this doesn't answer it. I also fail to see how it is "un-Pythonic", considering the existence of `namedtuple`, which gives most of the syntactic sugar that I want.
Pavel Minaev
I think "Bunch" (first form) is the right answer (but I'm biased since I coined the name, 8+ years ago -- see http://code.activestate.com/recipes/52308/ which btw is the top google hit for the search [bunch python];-). The second form has deep and somewhat subtle problems, do x=Bunch(update=23) and see what x.update *IS*;-) -- you call that NICE?-)
Alex Martelli
@Alex: How about setting `__getattribute__ = dict.get`? Ugly, yes, but does it still have problems?
dF
Well, it seems that there isn't any good answer that satisfies all my criteria, and this one is the most extensive otherwise, covering both the "you don't really want to" angle and the "but anyway here's how" angle :) - so I'm accepting it.
Pavel Minaev
+4  A: 

I don't remember offhand if there's a builtin but writing it yourself is shorter than typing your question. :-)

class record(object):
  def __init__(self, **kwargs): self.__dict__ = kwargs
  def __eq__(self, r2): return self.__dict__ == r2.__dict__
  def __neq__(self, r2): return self.__dict__ != r2.__dict__

foo = record(x=1, y=2)
bar = record(y=2, x=1)
foo == bar  # => true
Ken
Neat (I knew how to do this in general, but didn't realize it's that simple). Now, on to the real question: would you be willing to submit a PEP for the above? :)
Pavel Minaev
By the way, is `__neq__` really needed? Isn't the default definition as `not __eq__` provided automatically?
Pavel Minaev
Pavel: that's what I initially thought, but when I tried it, it didn't seem to work that way (though it's quite possible I screwed up).
Ken
+2  A: 

Quoted from this page:

 class Struct:
     def __init__(self, **entries): self.__dict__.update(entries)
     def __eq__(self, other): return self.__dict__ == other.__dict__
     def __neq__(self, other): return self.__dict__ != other.__dict__

 options = Struct(answer=42, linelen = 80, font='courier')
 options.answer
 >>> 42
 options.answer = 'plastics'
 vars(options)
 >>> {'answer': 'plastics', 'font': 'courier', 'linelen': 80}
jonwd7
+1  A: 

1) See http://uszla.me.uk/space/blog/2008/11/06. You can create an anonymous object with slightly ugly syntax by using the type built-in function:

 anon_object_2 = type("", (), {})()

where the 3rd parameter is the dict that will contain the fields of your object.

 foo = type("", (), dict(y=1))()
 foo.y == 1

2) Another variation is proposed by Peter Norvig at http://norvig.com/python-iaq.html. It is also similar to the answer posted by Ken.

class Struct:
    def __init__(self, **entries): self.__dict__.update(entries)

>>> options = Struct(answer=42, linelen = 80, font='courier')
>>> options.answer
42

The benefit of this method is that you can implement equality by contents of the dict, which the first option doesn't have.

alanlcode
+2  A: 

The type(...) form will fail the structural comparison requirement (without getting really ugly). The dict(...) form doesn't meet the attribute accessor requirement.

The attrdict seems to fall in the middle somewhere:

class attrdict(dict):
    def __init__(self, *args, **kwargs):
        dict.__init__(self, *args, **kwargs)
        self.__dict__ = self

a = attrdict(x=1, y=2)
b = attrdict(y=2, x=1)

print a.x, a.y
print b.x, b.y
print a == b

But it means defining a special class.

OK, I just noticed the update to the question. I'll just note that you can specify dict for the bases parameter and only need to specify the constructor then (in the icky type expression). I prefer attrdict. :-)

ars
Very neat hack, thank you.
Pavel Minaev
Setting self.__dict__ = self causes a memory leak, so I'd advise against this. http://bugs.python.org/issue1469629
sysrqb