Should code be written to stay consistent with the unidiomatic API style of a library?

Question

I'm currently using the wxPython library to construct a GUI. One interesting aspect of the library I've noticed is that it uses CamelCase notation to write method names, as opposed to the snake_case notation that PEP 8 recommends^*. This isn't to much of a surprise however since wxPython is basically a wrapper around the wx library, meant for C++. This poses an interesting decision though.

Naturally, I'm modeling my GUI structure using OOP, sub-classing the most appropriate GUI widget. Often, I have to write extension and convince methods to complete the sub-classing. At first, I thought I'd write the methods using snake_case notation; Just because wxPython used CamelCase didn't mean I had to as well. In hindsight though, this is causing the code to look inconsistent and sloppy and I'm fairly sure the correct course of action would be to use CamelCase notation to maintain consistency. However, note that I would like to continue to use snake_case for variables, since that didn't seem to affect consistency much. But I'd like to get a second opinion before making final decision on this.

Should code be written to stay consistent with the unidiomatic API style of a library?

---

^* _{I understand that PEP 8 is only a style guide. It doesn't have to followed absolutely. However, since most Python code I've encountered is written based on PEP 8, I'd like to stay consistent.}

Answer 1

In general, I think the answer to this one is "it depends". Looking more closely at your specific example:

• If you're subclassing something, then it's probably best to stay with the style of the code you're subclassing; consumers of the class are going to be calling methods both from the original code and your code, and it's going to be simpler for them if they only have to deal with one style.
• If you're wrapping something, then you should write your code in the idiomatic style - consumers of your code are never going to have to deal with the original unidiomatic style, so give them code in the style they're going to expect for the language they're writing in.

You're always going to be able to find edge cases which don't cleanly fit into one or other of those categories, but the general principle to follow remains the same: make the code as easy to use for the people who are going to be consuming it. By default, that means writing idiomatic code, but there may be occasions on which it's better to write unidiomatic code.