Restrictive APIs for Python

[Gabriel Genellina]

On 15 dic, 13:46, "Will Ware" <will.w... at gmail.com> wrote:
> Gabriel Genellina wrote:
> > In Python, the usual way of saying "don't play with me" is prepending
> > an underscore: _private
> Thanks, I am familiar with that.
So enforce it instead of going against the nature of the language.

> > BTW, have you *ever* tested your code?
> Yes, we have a QA process.
> The problem is not that the code doesn't
> work, it does.

Does it?

>>> c = ClassUnderTest(1)
>>> print c
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "<stdin>", line 22, in __getattr__
KeyError: 'self'
>>>

Even if you try to correct this, c is no more an instance of the
intended class, it's a "newklas" now, so isinstance() wont work
anymore. It has lost his docstring so you don't know its purpose and
intended usage anymore; you cannot inspect its methods using dir() so
editors and other tools can't help you writting and documenting code.
And a lot of other things upon which a lot of Python programs relies
on.
Don't go *against* the language, learn to use it the right way on your
own advantage.

> It was developed by a mix of more and less experienced
> programmers, and early in the code's history, some hadn't been trained
> on the benefits of complying to an API, or Pythonic idioms like the
> leading underscore. So the code varies in its clarity, and some
> maintenance chores aren't as pleasant as they might be.
You can use tools like pylint or pychecker to try to detect and fix
those issues.

> I have found that the work of more experienced programmers often
> includes improving the quality of code written by less experienced
> programmers. Is this inconsistent with your own experience?
If the less experienced guys get the feedback, I feel that's Ok.
Just cut them a finger phalanx each time someone breaks the rules and
see how well your programmers behave :)

-- 
Gabriel Genellina