Hi, @David Mertz, Eric Fahlgren re inheritance: thank you very much for your suggestions. I will try to see how inheritance can be implemented with metaclasses and annotations and put it into icontract library.
@David Mertz re costs: > Adding a new feature, even if it is *technically* backwards compatible, > has HUGE costs. > [...] > It's a specific feature that is relatively well defined as a concept (and > precisely defined in regard to Eiffel specifically; but we might not > implement those *exact* semantics). It's also a feature that no languages > in particularly widespread use have decided to implement at the language > level. I've chatted with Meyer; he's definitely very smart and definitely > strongly opinionated, but *I also think he's wrong about the overall > importance of this feature* *versus lots of others* [emphasis Marko]. > > In my mind, this feature doesn't come close to meeting the burden of those > high costs listed above (and others I did not mention). But I don't have > any say in what the core developers will do, beyond in that they might be > influenced by my opinion here. > I am also aware of the costs; when I wrote "useful", I actually meant "useful and meaningful to implement given the costs that you mention. Please apologize for my inexact wording (I write these emails in the evening after work). Related to the text I emphasized, would you mind to explain a bit more in-depth which features you have in mind? I see contracts formally written out and automatically verified as a completely indispensable tool in large projects with multiple people involved. As I already outlined, writing them in documentation leads to code rot. Not writing assumptions about the data structures at all causes, in my opinion, tons of problems and very, very slow development since each programmer working on the legacy code needs to figure these assumptions over and over again. While testing is not substitute for thinking, I possible don't see how you can add/refactor code in big projects and consider all the interactions between the components. Unit testing can get you only as far, since you always test only for a concrete case. Contracts get you much further, not to mention the automatically generated tests which I can't conceive practical without some sort of contracts in the code. I have also to admit that I was schooled with contracts so I might have a distorted view on the matter (Bertrand Meyer taught Introduction to Programming and all the software engineering university classes; I also worked as a teaching assistant with him for the Software Architecture class). I will try to see how far we can implement contracts as a library. Personally, I would prefer dedicated syntax and I do believe that dedicated syntax merits the costs since these constructs would lead to much better programming in the Python world. If we can't get new syntax, having contracts in the standard library would do it for me as a compromise -- it would standardize, even if in ugly way (as Steven D'Aprano pointed out), how we deal with contracts in Python and would allow for integration into IDEs and static analysis tools. On Thu, 30 Aug 2018 at 05:01, Ethan Furman <et...@stoneleaf.us> wrote: > On 08/29/2018 04:53 PM, Hugh Fisher wrote: > > From: Marko Ristin-Kaufmann: > > >> There seems to be evidence that design-by-contract is useful. Let me > cite > >> Bertrand Meyer from his article "Why not program right?" that I already > >> mentioned before: > > > > I don't think that being useful by itself should be enough. I think new > features > > should also be "Pythonic" and I don't see design by contract notation as > a > > good fit. > > I don't see type annotation notation as a good fit, either, and yet we > have it. Seems to me that DbC would be just as > useful as type annotations (and I find D'Aprano's example syntax very > readable). > > > For design by contract, as others have noted Python assert statements > > work fine for simple preconditions and postconditions. > > And print statements work fine for simple debugging. New features are not > added for the simple cases, but the complex, > or non-obviously correct, or the very useful cases. > > > Yes there's more to design by contract than simple assertions, but it's > not > > just adding syntax. Meyer often uses the special "old" construct in his > post > > condition examples, a trivial example being > > > > ensure count = old.count + 1 > > I can see where that could get expensive quickly. > > > How do we do that in Python? And another part of design by contract (at > > least according to Meyer) is that it's not enough to just raise an > exception, > > but there must be a guarantee that it is handled and the post conditions > > and/or invariants restored. > > Well, we don't have to have exactly the same kind of DbC as Eiffel does. > > -- > ~Ethan~ > _______________________________________________ > Python-ideas mailing list > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ >
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
