Mailman 3 September 2018 - Python-ideas

Dart like multi line strings identation
by Marius Räsener 08 Feb '19

08 Feb '19

Hey List, this is my very first approach to suggest a Python improvement I'd think worth discussing. At some point, maybe with Dart 2.0 or a little earlier, Dart is now supporting multiline strings with "proper" identation (tried, but I can't find the according docs at the moment. probably due to the rather large changes related to dart 2.0 and outdated docs.) What I have in mind is probably best described with an Example: print(""" I am a multiline String. """) the closing quote defines the "margin indentation" - so in this example all lines would get reduces by their leading 4 spaces, resulting in a "clean" and unintended string. anyways, if dart or not, doesn't matter - I like the Idea and I think python3.x could benefit from it. If that's possible at all :) I could also imagine that this "indentation cleanup" only is applied if the last quotes are on their own line? Might be too complicated though, I can't estimated or understand this... thx for reading, Marius

23 47

Make None a subclass of int [alternative to iNaN]
by Ken Hilton 27 Nov '18

27 Nov '18

Hi all, Reading the iNaN discussion, most of the opposition seems to be that adding iNaN would add a new special value to integers and therefore add new complexity. I propose, instead, that we make None a subclass of int (or even a certain value of int) to represent iNaN. Therefore: >>> None + 1, None - 1, None * 2, None / 2, None // 2 (None, None, None, nan, None) # mathematical operations on NaN return NaN >>> None & 1, None | 1, None ^ 1 # I'm not sure about this one. The following could be plausible: (0, 1, 1) # or this might make more sense, as this *is* NaN we're talking about: (None, None, None) >>> isinstance(None, int) True # the whole point of this idea >>> issubclass(type(None), int) True # no matter whether None *is* an int or just a subclass, this will be true as issubclass(int, int) is True I know this is a crazy idea, but I thought it could have some merit, so why not throw it out here? Sharing, Ken Hilton;

3 2

Pypi private repo's
by Nick Humrich 29 Oct '18

29 Oct '18

I am sure this has been discussed before, and this might not even be the best place for this discussion, but I just wanted to make sure this has been thought about. What if pypi.org supported private repos at a cost, similar to npm? This would be able to help support the cost of pypi, and hopefully make it better/more reliable, thus in turn improving the python community. If this discussion should happen somewhere else, let me know. Nick

5 5

Re: [Python-ideas] [Distutils] Pypi private repo's
by Nick Coghlan 28 Oct '18

28 Oct '18

On 5 April 2018 at 07:58, Jannis Gebauer <ja.geb(a)me.com> wrote: > What if there was some kind of “blessed” entity that runs these services and puts the majority of the revenue into a fund that funds development on PyPi (maybe trough the PSF)? Having a wholly owned for-profit subsidiary that provides commercial services as a revenue raising mechanism is certainly one way to approach something like this without alienating sponsors or tax authorities (although it may still alienate the vendors of now competing services). It would require a big time commitment on the PSF side to get everything set up though, as well as interest from key folks in joining what would essentially be a single-language-focused start up in an already crowded cross-language developer tools marketplace. When the PSF as a whole is still operating with only a handful of full or part time employees, it's far from clear that setting something like that up would be the most effective possible use of their time and energy. At a more basic level, that kind of arrangement technically doesn't require anyone's blessing, it could be as straightforward as downstream tooling vendors signing up as PSF sponsors and saying "please allocate our sponsorship contribution to the Packaging WG's budget so that PyPI keeps operating well and the PyPA tooling keeps improving, increasing the level of demand for our commercial Python repository management services". Historically that wouldn't have helped much, since the PSF itself has struggled with effective project management (for a variety of reasons), but one of the things I think the success of the MOSS grant has shown is the significant strides that the PSF has made in budget management in recent years, such that if funding is made available, it can and will be spent effectively. Cheers, Nick. P.S. PyPA contributors are also free agents in their own right, so folks offering Python-centric developer workflow management tools or features may decide that it's worth their while to invest more directly in smoothing out some of the rough edges that currently still exist. It's a mercenary way of looking at things, but in many cases, it is *absolutely* possible to pay for the time and attention of existing contributors, and if you can persuade them that your proposals are reasonable, they'll often have an easier time than most convincing other community contributors that it's a good way to go :) -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia

3 5

Re: [Python-ideas] Why is design-by-contracts not widely adopted?
by Hugh Fisher 09 Oct '18

09 Oct '18

> Date: Sun, 23 Sep 2018 07:09:37 +0200 > From: Marko Ristin-Kaufmann <marko.ristin(a)gmail.com> > To: Python-Ideas <python-ideas(a)python.org> > Subject: [Python-ideas] Why is design-by-contracts not widely adopted? [ munch ] > *. *After properly reading about design-by-contract and getting deeper into > the topic, there is no rational argument against it and the benefits are > obvious. And still, people just wave their hand and continue without > formalizing the contracts in the code and keep on writing them in the > descriptions. Firstly, I see a difference between rational arguments against Design By Contract (DbC) and against DbC in Python. Rejecting DbC for Python is not the same as rejecting DbC entirely. Programming languages are different, obviously. Python is not the same as C is not the same as Lisp... To me this also means that different languages are used for different problem domains, and in different styles of development. I wouldn't use DbC in programming C or assembler because it's not really helpful for the kind of low level close to the machine stuff I use C or assembler for. And I wouldn't use DbC for Python because I wouldn't find it helpful for the kind of dynamic, exploratory development I do in Python. I don't write strict contracts for Python code because in a dynamically typed, and duck typed, programming language they just don't make sense to me. Which is not to say I think Design by Contract is bad, just that it isn't good for Python. Secondly, these "obvious" benefits. If they're obvious, I want to know why aren't you using Eiffel? It's a programming language designed around DbC concepts. It's been around for three decades, at least as long as Python or longer. There's an existing base of compilers and support tools and libraries and textbooks and experienced programmers to work with. Could it be that Python has better libraries, is faster to develop for, attracts more programmers? If so, I suggest it's worth considering that this might be *because* Python doesn't have DbC. Or is this an updated version of the old saying "real programmers write FORTRAN in any language" ? If you are accustomed to Design by Contract, think of your time in the Python world as a trip to another country. Relax and try to program like the locals do. You might enjoy it. -- cheers, Hugh Fisher

20 98

Re: [Python-ideas] Simplicity of C (was why is design-by-contracts not widely)
by Hugh Fisher 07 Oct '18

07 Oct '18

> Date: Sat, 29 Sep 2018 02:45:06 +1000 > From: Steven D'Aprano <steve(a)pearwood.info> > To: python-ideas(a)python.org > Subject: Re: [Python-ideas] Why is design-by-contracts not widely > Message-ID: <20180928164506.GN19437(a)ando.pearwood.info> > Content-Type: text/plain; charset=us-ascii > > On Tue, Sep 25, 2018 at 09:59:53PM +1000, Hugh Fisher wrote: > > > C and Python (currently) are known as simple languages. > > o_O > > That's a usage of "simple" I haven't come across before. Especially in > the case of C, which is a minefield of *intentionally* underspecified > behaviour which makes it near to impossible for the developer to tell > what a piece of syntactically legal C code will actually do in practice. Oh FFS. You couldn't make the effort to read the very next sentence, let alone the next paragraph, before responding? -- cheers, Hugh Fisher

10 21

Re: [Python-ideas] Moving to another forum system where
by James Lu 03 Oct '18

03 Oct '18

> Is that really an issue here? I personally haven't seen threads where > Brett tried to stop an active discussion, but people ignored him and > kept fighting. Not personally with Brett, but I have seen multiple people try to stop the “reword or remove beautiful is better than ugly in Zen of Python.” The discussion was going in circles and evolved into attacking each other’s use of logical fallacies. Other than that, my biggest issues with the current mailing system are: * There’s no way to keep a updated proposal of your own- if you decide to change your proposal, you have to communicate the change. Then, if you want to find the authoritative current copy, since you might’ve forgotten or you want to join he current discussion, then you have to dig through the emails and recursively apply the proposed change. It’s just easier if people can have one proposal they can edit themselves. * I’ve seen experienced people get confused about what was the current proposal because they were replying to older emails or they didn’t see the email with the clear examples. * The mailing list is frankly obscure. Python community leaders and package maintainers often are not aware or do not participate in Python-ideas. Not many people know how to use or navigate a mailing list. * No one really promotes the mailing list, you have to go out of your way to find where new features are proposed. * Higher discoverability means more people can participate, providing their own use cases or voting (I mean using like or dislike measures, consensus should still be how things are approved) go out of their way to find so they can propose something. Instead, I envision a forum where people can read and give their 2 cents about what features they might like to see or might not want to see. * More people means instead of having to make decisions from sometimes subjective personal experience, we can make decisions with confidence in what other Python devs want. Since potential proposers will find it easier to navigate a GUI forum, they can read previous discussions to understand the reasoning, precedent behind rejected and successful features. People proposing things that have already been rejected before can be directed to open a subtopic on the older discussion. > On Sep 18, 2018, at 3:19 PM, python-ideas-request(a)python.org wrote: > > Is that really an issue here? I personally haven't seen threads where > Brett tried to stop an active discussion, but people ignored him and > kept fighting.

19 44

"while:" for the loop
by Mikhail V 02 Oct '18

02 Oct '18

I suggest allowing "while:" syntax for the infinite loop. I.e. instead of "while 1:" and "while True:" notations. IIRC, in the past this was mentioned in python-list discussions as alternative for the "while True:"/"while 1:" syntax. I even had impression that there was nothing rational against this (apart from the traditional "don't change anything" principle) My opinion: 1. I think it'd definitely improve clarity. Although it's not extremely frequent statement, it still appears in algorithms, where additional noise interfers the reader's concentration. 2. This should become the answer to the "how should I denote an infinte loop?" question. 3. In schools/unis they teach algorithms with Python syntax so it will be easier to remember and to write. Adoption of this spelling is natural and straightforward. 4. It does seem to be a rare case of a very easy to implement syntax change (an expert note needed) Also I have personal sympathy for this because I like to use explicit "break" in the loop body, even though I could use "while expression:" syntax, but I prefer this: while 1: ... if i == N : break instead of this: while i < N: ... It helps me to concentrate by reading, especially in nested loops and those situations with multiple break points. So by me this syntax would definitely achieve an extra +. There were alternative suggestions, e.g. introducing a new keyword "loop", but obviously a new keyword is much harder to do now. I don't know what to add to this actually, I think the idea is understood. I see, it is not the most important problem, but if there is nothing serious against this, I think it's worth it and would be quite a positive (small) improvement and a nice gift to those involved in algorithms. As for statistics - IIRC someone gave statistics once, but the only thing I can remember - "while 1/True" is used quite a lot in the std lib, so the numbers exceeded my expectation (because I expected that it's used mostly in algorithms). Mikhail

9 12

Suggestion: Extend integers to include iNaN
by Steve Barnes 01 Oct '18

01 Oct '18

One of the strengths of the IEEE float, (to set against its many weaknesses), is the presence of the magic value NaN. Not a Number, or NaA, is especially useful in that it is a valid value in any mathematical operation, (always returning NaN), or comparison, (always returning False). In functional programming this is especially useful as it allows the chain to complete after an error while retaining the fact that an error occurred, (as we got NaN). In languages such as C integers can only be used to represent a limited range of values in integers and a less limited range of values, (but still limited), with a limited accuracy. However, one of Pythons strengths is that its integers can represent any whole number value, (up to the maximum available memory and in exchange for slow performance when numbers get huge). This is accomplished by Python Integers being objects rather than a fixed number of bytes. I think that it should be relatively simple to extend the Python integer class to have a NaN flag, possibly by having a bit length of 0, and have it follow the same rules for the handling of floating point NaN, i.e. any mathematical operation on an iNaN returns an iNaN and any comparison with one returns False. One specific use case that springs to mind would be for Libraries such as Pandas to return iNaN for entries that are not numbers in a column that it has been told to treat as integers. We would possibly need a flag to set this behaviour, rather than raising an Exception, or at the very least automatically (or provide a method to) set LHS integers to iNaN on such an exception. I thought that I would throw this out to Python Ideas for some discussion of whether such a feature is: a) Desirable? b) Possible, (I am sure that it could be done)? c) Likely to get me kicked off of the list? -- Steve (Gadget) Barnes Any opinions in this message are my personal opinions and do not reflect those of my employer. --- This email has been checked for viruses by AVG. https://www.avg.com

14 55

Re: [Python-ideas] "old" values in postconditions
by James Lu 01 Oct '18

01 Oct '18

I am fine with your proposed syntax. It’s certainly lucid. Perhaps it would be a good idea to get people accustomed to “non-magic” syntax. > I still have a feeling that most developers would like to store the state in many different custom ways. Please explain. (Expressions like thunk(all)(a == b for a, b in P.arg.meth()) would be valid.) > I'm thinking mostly about all the edge cases which we would not be able to cover (and how complex that would be to cover them). Except for a > b > c being one flat expression with 5 members, it seems fairly easy to recreate an AST, which can then be compiled down to a code object. The code object can be fun with a custom “locals()” Below is my concept code for such a P object. from ast import * # not done: enforce Singleton property on EmptySymbolType class EmptySymbolType(object): ... EmptySymbol = EmptySymbolType() # empty symbols are placeholders class MockP(object): # "^" is xor @icontract.pre(lambda symbol, astnode: (symbol is None) ^ (astnode is None)) def __init__(self, symbol=None, value=EmptySymbol, astnode=None, initsymtable=(,)): self.symtable = dict(initsymtable) if symbol: self.expr = Expr(value=Name(id=symbol, ctx=Load())) self.symtable = {symbol: value} else: self.expr = astnode self.frozen = False def __add__(self, other): wrapped = MockP.wrap_value(other) return MockP(astnode=Expr(value=BinOp(self.expr, Add(), wrapped.expr), initsymtable={**self.symtable, **wrapped.symtable}) def compile(self): ... def freeze(self): # frozen objects wouldn’t have an overrided getattr, allowing for icontract to manipulate the MockP object using its public interface self.frozen = True @classmethod def wrap_value(cls, obj): # create a MockP object from a value. Generate a random identifier and set that as the key in symtable, the AST node is the name of that identifier, retrieving its value through simple expression evaluation. ... thunk = MockP.wrap_value P = MockP('P') # elsewhere: ensure P is only accessed via valid “dot attribute access” inside @snapshot so contracts fail early, or don’t and allow Magic like __dict__ to occur on P. > On Sep 27, 2018, at 9:49 PM, Marko Ristin-Kaufmann <marko.ristin(a)gmail.com> wrote: > > Hi James, > > I still have a feeling that most developers would like to store the state in many different custom ways. I see also thunk and snapshot with wrapper objects to be much more complicated to implement and maintain; I'm thinking mostly about all the edge cases which we would not be able to cover (and how complex that would be to cover them). Then the linters need also to work around such wrappers... It might also scare users off since it looks like too much magic. Another concern I also have is that it's probably very hard to integrate these wrappers with mypy later -- but I don't really have a clue about that, only my gut feeling? > > What about we accepted to repeat "lambda P, " prefix, and have something like this: > > @snapshot( > lambda P, some_name: len(P.some_property), > lambda P, another_name: hash(P.another_property) > ) > > It's not too verbose for me and you can still explain in three-four sentences what happens below the hub in the library's docs. A pycharm/pydev/vim/emacs plugins could hide the verbose parts. > > I performed a small experiment to test how this solution plays with pylint and it seems OK that arguments are not used in lambdas. > > Cheers, > Marko > > >> On Thu, 27 Sep 2018 at 12:27, James Lu <jamtlu(a)gmail.com> wrote: >> Why couldn’t we record the operations done to a special object and replay them? >> >>>>> Actually, I think there is probably no way around a decorator that captures/snapshots the data before the function call with a lambda (or even a separate function). "Old" construct, if we are to parse it somehow from the condition function, would limit us only to shallow copies (and be complex to implement as soon as we are capturing out-of-argument values such as globals etc.). Moreove, what if we don't need shallow copies? I could imagine a dozen of cases where shallow copy is not what the programmer wants: for example, s/he might need to make deep copies, hash or otherwise transform the input data to hold only part of it instead of copying (e.g., so as to allow equality check without a double copy of the data, or capture only the value of certain property transformed in some way). >> >> >> from icontract import snapshot, P, thunk >> @snapshot(some_identifier=P.self.some_method(P.some_argument.some_attr)) >> >> P is an object of our own type, let’s call the type MockP. MockP returns new MockP objects when any operation is done to it. MockP * MockP = MockP. MockP.attr = MockP. MockP objects remember all the operations done to them, and allow the owner of a MockP object to re-apply the same operations >> >> “thunk” converts a function or object or class to a MockP object, storing the function or object for when the operation is done. >> >> thunk(function)(<MockP expression>) >> >> Of course, you could also thunk objects like so: thunk(3) * P.number. (Though it might be better to keep the 3 after P.number in this case so P.number’s __mult__ would be invoked before 3’s __mult__ is invokes. >> >> >> In most cases, you’d save any operations that can be done on a copy of the data as generated by @snapshot in @postcondiion. thunk is for rare scenarios where 1) it’s hard to capture the state, for example an object that manages network state (or database connectivity etc) and whose stage can only be read by an external classmethod 2) you want to avoid using copy.deepcopy. >> >> I’m sure there’s some way to override isinstance through a meta class or dunder subclasshook. >> >> I suppose this mocking method could be a shorthand for when you don’t need the full power of a lambda. It’s arguably more succinct and readable, though YMMV. >> >> I look forward to reading your opinion on this and any ideas you might have. >> >>> On Sep 26, 2018, at 3:56 PM, James Lu <jamtlu(a)gmail.com> wrote: >>> >>> Hi Marko, >>> >>>> Actually, following on #A4, you could also write those as multiple decorators: >>>> @snpashot(lambda _, some_identifier: some_func(_, some_argument.some_attr) >>>> @snpashot(lambda _, other_identifier: other_func(_.self)) >>> >>> Yes, though if we’re talking syntax using kwargs would probably be better. >>> Using “P” instead of “_”: (I agree that _ smells of ignored arguments) >>> >>> @snapshot(some_identifier=lambda P: ..., some_identifier2=lambda P: ...) >>> >>> Kwargs has the advantage that you can extend multiple lines without repeating @snapshot, though many lines of @capture would probably be more intuitive since each decorator captures one variable. >>> >>>> Why uppercase "P" and not lowercase (uppercase implies a constant for me)? >>> >>> To me, the capital letters are more prominent and explicit- easier to see when reading code. It also implies its a constant for you- you shouldn’t be modifying it, because then you’d be interfering with the function itself. >>> >>> Side node: maybe it would be good to have an @icontract.nomutate (probably use a different name, maybe @icontract.readonly) that makes sure a method doesn’t mutate its own __dict__ (and maybe the __dict__ of the members of its __dict__). It wouldn’t be necessary to put the decorator on every read only function, just the ones your worried might mutate. >>> >>> Maybe a @icontract.nomutate(param=“paramname”) that ensures the __dict__ of all members of the param name have the same equality or identity before and after. The semantics would need to be worked out. >>> >>>> On Sep 26, 2018, at 8:58 AM, Marko Ristin-Kaufmann <marko.ristin(a)gmail.com> wrote: >>>> >>>> Hi James, >>>> >>>> Actually, following on #A4, you could also write those as multiple decorators: >>>> @snpashot(lambda _, some_identifier: some_func(_, some_argument.some_attr) >>>> @snpashot(lambda _, other_identifier: other_func(_.self)) >>>> >>>> Am I correct? >>>> >>>> "_" looks a bit hard to read for me (implying ignored arguments). >>>> >>>> Why uppercase "P" and not lowercase (uppercase implies a constant for me)? Then "O" for "old" and "P" for parameters in a condition: >>>> @post(lambda O, P: ...) >>>> ? >>>> >>>> It also has the nice property that it follows both the temporal and the alphabet order :) >>>> >>>>> On Wed, 26 Sep 2018 at 14:30, James Lu <jamtlu(a)gmail.com> wrote: >>>>> I still prefer snapshot, though capture is a good name too. We could use generator syntax and inspect the argument names. >>>>> >>>>> Instead of “a”, perhaps use “_”. Or maybe use “A.”, for arguments. Some people might prefer “P” for parameters, since parameters sometimes means the value received while the argument means the value passed. >>>>> >>>>> (#A1) >>>>> >>>>> from icontract import snapshot, __ >>>>> @snapshot(some_func(_.some_argument.some_attr) for some_identifier, _ in __) >>>>> >>>>> Or (#A2) >>>>> >>>>> @snapshot(some_func(some_argument.some_attr) for some_identifier, _, some_argument in __) >>>>> >>>>> — >>>>> Or (#A3) >>>>> >>>>> @snapshot(lambda some_argument,_,some_identifier: some_func(some_argument.some_attr)) >>>>> >>>>> Or (#A4) >>>>> >>>>> @snapshot(lambda _,some_identifier: some_func(_.some_argument.some_attr)) >>>>> @snapshot(lambda _,some_identifier, other_identifier: some_func(_.some_argument.some_attr), other_func(_.self)) >>>>> >>>>> I like #A4 the most because it’s fairly DRY and avoids the extra punctuation of >>>>> >>>>> @capture(lambda a: {"some_identifier": some_func(a.some_argument.some_attr)}) >>>>> >>>>> On Sep 26, 2018, at 12:23 AM, Marko Ristin-Kaufmann <marko.ristin(a)gmail.com> wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> Franklin wrote: >>>>>>> The name "before" is a confusing name. It's not just something that >>>>>>> happens before. It's really a pre-`let`, adding names to the scope of >>>>>>> things after it, but with values taken before the function call. Based >>>>>>> on that description, other possible names are `prelet`, `letbefore`, >>>>>>> `predef`, `defpre`, `beforescope`. Better a name that is clearly >>>>>>> confusing than one that is obvious but misleading. >>>>>> >>>>>> James wrote: >>>>>>> I suggest that instead of “@before” it’s “@snapshot” and instead of “old” it’s “snapshot”. >>>>>> >>>>>> >>>>>> I like "snapshot", it's a bit clearer than prefixing/postfixing verbs with "pre" which might be misread (e.g., "prelet" has a meaning in Slavic languages and could be subconsciously misread, "predef" implies to me a pre-definition rather than prior-to-definition , "beforescope" is very clear for me, but it might be confusing for others as to what it actually refers to ). What about "@capture" (7 letters for captures versus 8 for snapshot)? I suppose "@let" would be playing with fire if Python with conflicting new keywords since I assume "let" to be one of the candidates. >>>>>> >>>>>> Actually, I think there is probably no way around a decorator that captures/snapshots the data before the function call with a lambda (or even a separate function). "Old" construct, if we are to parse it somehow from the condition function, would limit us only to shallow copies (and be complex to implement as soon as we are capturing out-of-argument values such as globals etc.). Moreove, what if we don't need shallow copies? I could imagine a dozen of cases where shallow copy is not what the programmer wants: for example, s/he might need to make deep copies, hash or otherwise transform the input data to hold only part of it instead of copying (e.g., so as to allow equality check without a double copy of the data, or capture only the value of certain property transformed in some way). >>>>>> >>>>>> I'd still go with the dictionary to allow for this extra freedom. We could have a convention: "a" denotes to the current arguments, and "b" denotes the captured values. It might make an interesting hint that we put "b" before "a" in the condition. You could also interpret "b" as "before" and "a" as "after", but also "a" as "arguments". >>>>>> >>>>>> @capture(lambda a: {"some_identifier": some_func(a.some_argument.some_attr)}) >>>>>> @post(lambda b, a, result: b.some_identifier > result + a.another_argument.another_attr) >>>>>> def some_func(some_argument: SomeClass, another_argument: AnotherClass) -> SomeResult: >>>>>> ... >>>>>> "b" can be omitted if it is not used. Under the hub, all the arguments to the condition would be passed by keywords. >>>>>> >>>>>> In case of inheritance, captures would be inherited as well. Hence the library would check at run-time that the returned dictionary with captured values has no identifier that has been already captured, and the linter checks that statically, before running the code. Reading values captured in the parent at the code of the child class might be a bit hard -- but that is case with any inherited methods/properties. In documentation, I'd list all the captures of both ancestor and the current class. >>>>>> >>>>>> I'm looking forward to reading your opinion on this and alternative suggestions :) >>>>>> Marko >>>>>> >>>>>>> On Tue, 25 Sep 2018 at 18:12, Franklin? Lee <leewangzhong+python(a)gmail.com> wrote: >>>>>>> On Sun, Sep 23, 2018 at 2:05 AM Marko Ristin-Kaufmann >>>>>>> <marko.ristin(a)gmail.com> wrote: >>>>>>> > >>>>>>> > Hi, >>>>>>> > >>>>>>> > (I'd like to fork from a previous thread, "Pre-conditions and post-conditions", since it got long and we started discussing a couple of different things. Let's discuss in this thread the implementation of a library for design-by-contract and how to push it forward to hopefully add it to the standard library one day.) >>>>>>> > >>>>>>> > For those unfamiliar with contracts and current state of the discussion in the previous thread, here's a short summary. The discussion started by me inquiring about the possibility to add design-by-contract concepts into the core language. The idea was rejected by the participants mainly because they thought that the merit of the feature does not merit its costs. This is quite debatable and seems to reflect many a discussion about design-by-contract in general. Please see the other thread, "Why is design-by-contract not widely adopted?" if you are interested in that debate. >>>>>>> > >>>>>>> > We (a colleague of mine and I) decided to implement a library to bring design-by-contract to Python since we don't believe that the concept will make it into the core language anytime soon and we needed badly a tool to facilitate our work with a growing code base. >>>>>>> > >>>>>>> > The library is available at http://github.com/Parquery/icontract. The hope is to polish it so that the wider community could use it and once the quality is high enough, make a proposal to add it to the standard Python libraries. We do need a standard library for contracts, otherwise projects with conflicting contract libraries can not integrate (e.g., the contracts can not be inherited between two different contract libraries). >>>>>>> > >>>>>>> > So far, the most important bits have been implemented in icontract: >>>>>>> > >>>>>>> > Preconditions, postconditions, class invariants >>>>>>> > Inheritance of the contracts (including strengthening and weakening of the inherited contracts) >>>>>>> > Informative violation messages (including information about the values involved in the contract condition) >>>>>>> > Sphinx extension to include contracts in the automatically generated documentation (sphinx-icontract) >>>>>>> > Linter to statically check that the arguments of the conditions are correct (pyicontract-lint) >>>>>>> > >>>>>>> > We are successfully using it in our code base and have been quite happy about the implementation so far. >>>>>>> > >>>>>>> > There is one bit still missing: accessing "old" values in the postcondition (i.e., shallow copies of the values prior to the execution of the function). This feature is necessary in order to allow us to verify state transitions. >>>>>>> > >>>>>>> > For example, consider a new dictionary class that has "get" and "put" methods: >>>>>>> > >>>>>>> > from typing import Optional >>>>>>> > >>>>>>> > from icontract import post >>>>>>> > >>>>>>> > class NovelDict: >>>>>>> > def length(self)->int: >>>>>>> > ... >>>>>>> > >>>>>>> > def get(self, key: str) -> Optional[str]: >>>>>>> > ... >>>>>>> > >>>>>>> > @post(lambda self, key, value: self.get(key) == value) >>>>>>> > @post(lambda self, key: old(self.get(key)) is None and old(self.length()) + 1 == self.length(), >>>>>>> > "length increased with a new key") >>>>>>> > @post(lambda self, key: old(self.get(key)) is not None and old(self.length()) == self.length(), >>>>>>> > "length stable with an existing key") >>>>>>> > def put(self, key: str, value: str) -> None: >>>>>>> > ... >>>>>>> > >>>>>>> > How could we possible implement this "old" function? >>>>>>> > >>>>>>> > Here is my suggestion. I'd introduce a decorator "before" that would allow you to store whatever values in a dictionary object "old" (i.e. an object whose properties correspond to the key/value pairs). The "old" is then passed to the condition. Here is it in code: >>>>>>> > >>>>>>> > # omitted contracts for brevity >>>>>>> > class NovelDict: >>>>>>> > def length(self)->int: >>>>>>> > ... >>>>>>> > >>>>>>> > # omitted contracts for brevity >>>>>>> > def get(self, key: str) -> Optional[str]: >>>>>>> > ... >>>>>>> > >>>>>>> > @before(lambda self, key: {"length": self.length(), "get": self.get(key)}) >>>>>>> > @post(lambda self, key, value: self.get(key) == value) >>>>>>> > @post(lambda self, key, old: old.get is None and old.length + 1 == self.length(), >>>>>>> > "length increased with a new key") >>>>>>> > @post(lambda self, key, old: old.get is not None and old.length == self.length(), >>>>>>> > "length stable with an existing key") >>>>>>> > def put(self, key: str, value: str) -> None: >>>>>>> > ... >>>>>>> > >>>>>>> > The linter would statically check that all attributes accessed in "old" have to be defined in the decorator "before" so that attribute errors would be caught early. The current implementation of the linter is fast enough to be run at save time so such errors should usually not happen with a properly set IDE. >>>>>>> > >>>>>>> > "before" decorator would also have "enabled" property, so that you can turn it off (e.g., if you only want to run a postcondition in testing). The "before" decorators can be stacked so that you can also have a more fine-grained control when each one of them is running (some during test, some during test and in production). The linter would enforce that before's "enabled" is a disjunction of all the "enabled"'s of the corresponding postconditions where the old value appears. >>>>>>> > >>>>>>> > Is this a sane approach to "old" values? Any alternative approach you would prefer? What about better naming? Is "before" a confusing name? >>>>>>> >>>>>>> The dict can be splatted into the postconditions, so that no special >>>>>>> name is required. This would require either that the lambdas handle >>>>>>> **kws, or that their caller inspect them to see what names they take. >>>>>>> Perhaps add a function to functools which only passes kwargs that fit. >>>>>>> Then the precondition mechanism can pass `self`, `key`, and `value` as >>>>>>> kwargs instead of args. >>>>>>> >>>>>>> For functions that have *args and **kwargs, it may be necessary to >>>>>>> pass them to the conditions as args and kwargs instead. >>>>>>> >>>>>>> The name "before" is a confusing name. It's not just something that >>>>>>> happens before. It's really a pre-`let`, adding names to the scope of >>>>>>> things after it, but with values taken before the function call. Based >>>>>>> on that description, other possible names are `prelet`, `letbefore`, >>>>>>> `predef`, `defpre`, `beforescope`. Better a name that is clearly >>>>>>> confusing than one that is obvious but misleading. >>>>>>> >>>>>>> By the way, should the first postcondition be `self.get(key) is >>>>>>> value`, checking for identity rather than equality? >>>>>> _______________________________________________ >>>>>> Python-ideas mailing list >>>>>> Python-ideas(a)python.org >>>>>> https://mail.python.org/mailman/listinfo/python-ideas >>>>>> Code of Conduct: http://python.org/psf/codeofconduct/

2 14