[Python-Dev] Consenting adults considered beneficial [was: How far to go with user-friendliness]

Robert Collins robertc at robertcollins.net
Wed Jul 15 05:08:43 CEST 2015


On 15 July 2015 at 15:00, Stephen J. Turnbull <stephen at xemacs.org> wrote:
> Robert Collins writes:
>
>  > What I am doing is rejecting the argument that because we can't fix
>  > every mis-use users might make, we therefore should not fix the cases
>  > where we can fix it.
>
> This involves a value judgment, every time a new fix is proposed, as
> to whether it's a mis-use that deserves fixing or a permitted-to-
> consenting-adults behavior.  IMO, it's a bad idea to institutionalize
> that kind of bikeshedding, especially when such "fixes" involve
> overriding user choices that are permitted everywhere else.

I'm thoroughly confused by this.

> Arbitrary choices that *some* users want to be protected from ("stop
> me before I 'assret' again!") belong in linters, not in Python or the
> stdlib.

I agree with this.

> To be frank, I think you have the Pythonic approach exactly backwards
> here (though I am no authority on Pythonicity).  ISTM that in general
> Python takes the attitude that if a particular "mis-use" seems to be
> common, then we should figure out what it is about Python that
> encourages that "mistake", or makes an otherwise arbitrary user choice
> into a "mistake", and fix Python -- not restrict users.
>
> Of course that's not always possible, but that's the first choice
> AIUI.

And these two paragraphs confuse me again.

Lets be really specific here.

Mock today has the following behaviour:
x = Mock()
x.foo()
x.bar()
...

all will just work and are mock methods that magically appear on demand.

And it includes some methods:
x.assert_called_with()

which are not mock methods, can't be mocked, and if you make a typo
you got *no* signal back to say that you'd messed up, until the patch
that added assert_ and assret_ prefix checking was added.

Which part of that API is Pythonic?

I rejected an argument that just because some APIs are are
intrinsically able to be misused, that we should not try to write
better APIs.

I then gave an plan, for this case, which appears to have been
enthusiastically recieved by a bunch of long-time Python devs.

In what way is that unPythonic behaviour or design?

Confusedly-yrs.
Rob


-- 
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud


More information about the Python-Dev mailing list