Re: empty classes as c structs?

From: Michael Spencer (mahs_at_telcopartners.com)
Date: 02/08/05 

To: python-list@python.org
Date: Mon, 07 Feb 2005 17:33:29 -0800

Steven Bethard wrote:

> Do you mean there should be a separate Namespace and Bunch class? Or do
> you mean that an implementation with only a single method is less useful?

The former.
>
> If the former, then you either have to repeat the methods __repr__,
> __eq__ and update for both Namespace and Bunch, or one of Namespace and
> Bunch can't be __repr__'d, __eq__'d or updated.

I see no problem in repeating the methods, or inheriting the implementation.
However, if namespace and bunch are actually different concepts (one with
reference semantics, the other with copy), then __repr__ at least would need to
be specialized, to highlight the difference.

So, on balance, if copy semantics are important to bunch uses, and references
for namespace (though Nick changed his mind on this, and I don't yet know why) I
think they would be better as two small implementations. I remain unsure about
why you need or want copying, aside from matching the behavior of the builtins.

>
> If the latter (setting aside the fact that the implementation provides 4
> methods, not 1), I would argue that even if an implementation is only
> one method, if enough users are currently writing their own version,
> adding such an implementation to the stdlib is still a net benefit.

Yes, I agree with this: I was not picking on the class size ;-)

...
>
> Another way to avoid the problem is to use *args, like the current Bunch
> implementation does:
>
> def update(*args, **kwargs):
> """bunch.update([bunch|dict|seq,] **kwargs) -> None

Sure - nice trick to avoid shadowing self too

...
> Is it that much worse to require the following code:
>
> Namespace.update(namespace, obj.__dict__)
> or:
> namespace.udpate(obj.__dict__)
>
> if you really want to update a Namespace object with the attributes of a
> non-Namespace object?

No problem at all - just a question of what the class is optimized for, and
making the interface as convenient as possible, given the use case. I agree
that for straight attribute access to a dictionary, your update interface is
clearly superior.

>
> For that matter, do you have a use-case for where this would be useful?
> I definitely see the view-of-a-dict example, but I don't see the
> view-of-an-object example since an object already has dotted-attribute
> style access...

Yes, I have various cases in mind relating to argument-passing, dispatching,
interface-checking and class composition. Here the class becomes useful if it
grows some namespace-specific semantics.

For example, I could write something like:
namespace(obj1) >= namespace(obj2) to mean obj1 has at least the attributes of obj2

implemented like:

def __ge__(self, other):
     for attrname in other.__dict__.keys():
         if not attrname in self.__dict__:
             return False
     return True

I realize that interfaces may be addressed formally by a current PEP, but, even
if they are, this "cheap and cheerful" approach appeals to me for duck-typing.

However, as I think more about this, I realize that I am stretching your concept
past its breaking point, and that whatever the merits of this approach, it's not
helping you with bunch. Thanks for knocking the ideas around with me.

Cheers

Michael

Relevant Pages

  • Re: empty classes as c structs?
    ... Alex Martelli wrote: ... > wrapping a dict in a bunch gives you for further getting and setting ... in this context) of calling this 'namespace' in part because it can lead to ... The class interface implements the protocol and little else. ...
    (comp.lang.python)
  • Re: How to fix awkward ATL namespace clash?
    ... Renaming my own namespace doesn't work because I'm not getting a namespace ... I'm getting an Interface collision. ... By the time the compiler parses my typelib the OLEDB IAccessor ...
    (microsoft.public.vc.atl)
  • [RFC] dev_acpi: support for userspace access to acpi
    ... provides userspace access to ACPI namespace using a simple character ... For further discussion of the interface, ... I've been tossing around sysfs and device file interfaces to the ACPI ... information in namespace to not provide a userspace interface to it. ...
    (Linux-Kernel)
  • Re: COM
    ... Durch die Tlbs werden zwei Klassen in unterschiedlichen Namespaces erzeugt ... Namespace Ventura für die Version 10. ... Interface implementieren. ...
    (microsoft.public.de.german.entwickler.dotnet.csharp)
  • Re: Inherits Object not able to be cast
    ... TheirOrg.SEED.User can create their class based on that interface? ... > the XML type name, User, from namespace. ... > specify a unique XML name and/or namespace for the type. ... > As the exception message says, both are using the same Xml type name. ...
    (microsoft.public.dotnet.framework)