On Wed, Sep 26, 2018 at 2:47 PM Marko Ristin-Kaufmann <marko.ris...@gmail.com> wrote: > > Hi Chris, > >> An extraordinary claim is like "DbC can improve *every single project* >> on PyPI". That requires a TON of proof. Obviously we won't quibble if >> you can only demonstrate that 99.95% of them can be improved, but you >> have to at least show that the bulk of them can. > > > I tried to give the "proof" (not a formal one, though) in my previous message.
(Formal proof isn't necessary here; we say "extraordinary proof", but it'd be more accurate to say "extraordinary evidence".) > The assumptions are that: > * There are always contracts, they can be either implicit or explicit. You > need always to figure them out before you call a function or use its result. Not all code has such contracts. You could argue that code which does not is inferior to code which does, but not everything follows a strictly-definable pattern. > * Figuring out contracts by trial-and-error and reading the code (the > implementation or the test code) is time consuming and hard. Agreed. > * The are tools for formal contracts. That's the exact point you're trying to make, so it isn't evidence for itself. Tools for formal contracts exist as third party in Python, and if that were good enough for you, we wouldn't be discussing this. There are no such tools in the standard library or language that make formal contracts easy. > * The contracts written in documentation as human text inevitably rot and > they are much harder to maintain than automatically verified formal contracts. Agreed. > * The reader is familiar with formal statements, and hence reading formal > statements is faster than reading the code or trial-and-error. Disagreed. I would most certainly NOT assume that every reader knows any particular syntax for such contracts. However, this is a weaker point. So I'll give you two and two halves for that. Good enough to make do. > I then went on to show why I think, under these assumptions, that formal > contracts are superior as a documentation tool and hence beneficial. Do you > think that any of these assumptions are wrong? Is there a hole in my logical > reasoning presented in my previous message? I would be very grateful for any > pointers! > > If these assumptions hold and there is no mistake in my reasoning, wouldn't > that qualify as a proof? > It certainly qualifies as proof that SOME code MAY benefit from contracts. It does not reach the much higher bar to support the claim that "there are X projects on PyPI and every single one of them would benefit". For instance, would youtube-dl benefit from DbC? To most people, it's an application, not a library. Even if you're invoking it from within a Python script, it's usually easiest to use the main entrypoint rather than delve into its internals. Case in point: https://github.com/Rosuav/MegaClip/blob/master/megaclip.py#L71 It's actually easier to shell out to a subprocess than to call on youtube-dl as a library. Would DbC benefit youtube-dl's internal functions? Maybe, but that's for the youtube-dl people to decide; it wouldn't in the slightest benefit my app. You might argue that a large proportion of PyPI projects will be "library-style" packages, where the main purpose is to export a bunch of functions. But even then, I'm not certain that they'd all benefit from DbC. Some would, and you've definitely made the case for that; but I'm still -0.5 on adding anything of the sort to the stdlib, as I don't yet see that *enough* projects would actually benefit. People have said the same thing about type checking, too. Would *every* project on PyPI benefit from MyPy's type checks? No. Syntax for them was added, not because EVERYONE should use them, but because SOME will use them, and it's worth having some language support. You would probably do better to argue along those lines than to try to claim that every single project ought to be using contracts. ChrisA _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
