Ronald Oussoren wrote: >I'm not happy with the way that the Carbon wrappers work, adding Carbon >functions as methods of seemingly related classes. This makes it harder to map >documentation for Carbon to Python. It is also ugly. But this might not be a >problem with bgen itself. > >I'd prefer to see the function wrapped as functions in the Carbon module.
That would be my preference as well, at least for any new work. Stick with plain functions + opaque types. I'd rather deal with a well designed ADT-based API than a not-so-well designed OO one. Part of bgen's problem is that it's a victim of its own cleverness: it tries to do much more than it actually needs to, which ends up creating additional complexity; i.e. more things to learn, more things to go wrong. >If needed one could add convenience methods to type wrappers as well, but with >a more pythonic interface. That would require more work because you'd have to >make up a nice interface and document it. I'd suggest writing any new OO wrappers as Python classes. Less work than doing it in C, and it'd make it much quicker and easier to tweak and polish the high-level API design. has -- http://freespace.virgin.net/hamish.sanderson/ _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
