Hi Steve, I'll give it a shot and implement a proof-of-concept icontrac-macro library based on macropy and see if that works. I'll keep you posted.
Cheers, Marko On Tue, 25 Sep 2018 at 12:08, Stephen J. Turnbull < turnbull.stephen...@u.tsukuba.ac.jp> wrote: > Marko Ristin-Kaufmann writes: > > > Thanks a lot for pointing us to macropy -- I was not aware of the > library, > > it looks very interesting! > > > > Do you have any experience how macropy fit > > Sorry, no. I was speaking as someone who is familiar with macros from > Lisp but doesn't miss them in Python, and who also has been watching > python-dev and python-ideas for about two decades now, so I've heard > of things like MacroPy and know how the core developers think to a > great extent. > > > I'm also a bit worried how macropy would work out in the libraries > > published to pypi -- imagine if many people start using contracts. > > Suddenly, all these libraries would not only depend on a contract > library > > but on a macro library as well. > > That's right. > > > Is that something we should care about? > > Yes. Most Pythonistas (at least at present) don't much like macros. > They fear turning every program into its own domain-specific language. > I can't claim much experience with dependency hell, but I think that's > much less important from your point of view (see below). > > My point is mainly that, as you probably are becoming painfully aware, > getting syntax changes into Python is a fairly drawnout process. For > an example of the kind of presentation that motivates people to change > their mind from the default state of "if it isn't in Python yet, > YAGNI" to "yes, let's do *this* one", see > https://www.python.org/dev/peps/pep-0572/#appendix-a-tim-peters-s-findings > > Warning: Tim Peters is legendary, though still active occasionally. > All he has to do is post to get people to take notice. But this > Appendix is an example of why he gets that kind of R-E-S-P-E-C-T.[1] > > So the whole thing is a secret plot ;-) to present the most beautiful > syntax possible in your PEP (which will *not* be about DbC, but rather > about a small set of enabling syntax changes, hopefully a singleton), > along with an extended example, or a representative sample, of usage. > Because you have a working implementation using MacroPy (or the less > pretty[2] but fewer dependencies version based on condition strings > and eval) people can actually try it on their own code and (you hope, > they don't :-) they find a nestful of bugs by using it. > > > Potential dependency hell? (I already have a bad feeling about > > making icontract depend on asttokens and considerin-lining > > asttokens into icontract particularly for that reason). > > I don't think so. First, inlining an existing library is almost > always a bad idea. As for the main point, if the user sticks to one > major revision, and only upgrades to compatible bugfixes in the > Python+stdlib distribution, I don't see why two or three libraries > would be a major issue for a feature that the developer/project uses > extremely frequently. I've rarely experienced dependency hell, and in > both cases it was web frameworks (Django and Zope, to be specific, and > the dependencies involved were more or less internal to those > frameworks). If you or people you trust have other experience, forget > what I just said. :-) > > Of course it depends on the library, but as long as the library is > pretty strict about backward compatibility, you can upgrade it and get > new functionality for other callers in your code base (which are > likely to appear, you know -- human beings cannot stand to leave a > tool unused once they install it!) > > > > Note that this means *you cannot use macros in a file that is run > > > directly*, as it will not be passed through the import hooks. > > > > That would make contracts unusable in any stand-alone script, > > right? > > Yes, but really, no: > > # The run.py described by the MacroPy docs assumes a script that > # runs by just importing it. I don't have time to work out > # whether that makes more sense. This idiom of importing just a > # couple of libraries, and then invoking a function with a > # conventional name such as "run" or "process" is quite common. > # If you have docutils install, check out rstpep2html.py. > > import macropy.activate > from my_contractful_library import main > main() > > and away you go. 5 years from now that script will be a badge of > honor among Pythonic DbCers, and you won't be willing to give it up! > Just kidding, of course -- the ideal outcome is that the use case is > sufficiently persuasive to justify a syntax change so you don't need > MacroPy, or, perhaps some genius will come along and provide some > obscure construct that is already legal syntax! > > HTH > > Footnotes: > [1] R.I.P. Aretha! > > [2] Urk, I just realized there's another weakness to strings: you get > no help on checking their syntax from the compiler. For a proof-of- > concept that's OK, but if you end up using the DbC library in your > codebase for a couple years while the needed syntax change gathers > support, that would be really bad. > >
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
