Re: [Python-ideas] Why is design-by-contracts not widely adopted?

[Stephen J. Turnbull]

Chris Angelico writes:

 > Okay, but what is the contract that's being violated when you use
 > data= ? How would you define the contract that this would track?
 > That's what I'm asking.

The output is input to some other component.  In production, that
component would not be under your control, perhaps, but in testing it
surely is.  The contract would be associated with the other component,
and it would be "my input is JSON".

Alternatively, if "your" component is being used in a protocol that
specifies JSON, the contract could be "what I post is JSON".  Presumably
that contract can't be checked in production, but in testing it could
be.  If the inputs to your component satisfy their contracts, but JSON
isn't coming out, the problem is in your component.

Ie, I don't see how DbC can diagnose *how* a component is broken, in
general.  It *can* localize the breakage, and provide some hints based
on the particular contract that is "violated".

I think this shows that in a broad class of cases, for existing code,
DbC doesn't do much that a developer with a debugger (such as print()
;-) can't already do, and the developer can do it much more flexibly.

However, getting meta,

 > Just had a confused developer wondering why calling an API with
 > session.post(, data={...some object dict here}) didn't work
 > properly. (Solved by s/data/json)

session.post seems to be a pretty horrible API.  You'd think this
would either be

session.post_json(..., data={...})

or

session.post(..., data={...}, format='json')

with the former preferred (and session.post deprecated in favor of
session.form_encoded; I guess you could also use the latter and
require the 'format' argument).

How would this help in the DbC context?  Your server (if you own it),
or your mock server in the test suite, will complain that its contract
"my input is JSON" is being violated, because it's explicitly an entry
condition, your programmer looks at the component that's supposed to
produce JSON, sees "form_encoded" either in the function name or the
format argument's value, and the likelihood of confusion is small.

The contribution of DbC here is not in the contract itself, but in the
discipline of thinking "how would I write this contract so that its
violation would point me to the coding error?", which leads to
refactoring the 'post' method.

Is DbC better than the server doing "assert is_valid_json(input)"?
That too works best with the suggested refactoring.  Evidently it's
not better, but there are things that assert can't do.  For
example, the server might incrementally parse the JSON, yielding
useful subobjects as you go along.  Then you can't just assert
is_valid_json at the beginning of the response generator; you need to
do this at the server level.  A DbC toolkit would presumably provide a
way to decorate the server with

try:
server.accept_json_object()
except JSONParseError as e:
report_contract_violation(e)

This is, of course, all imaginary, and I have no idea whether it would
work as suggested in practice.  It will be interesting to me to see,
not only Marko's contracts in a DbC-ized module, but also places where
he demands refactoring so that an *informative* contract can be
written.

Steve

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Why is design-by-contracts not widely adopted?

[Stephen J. Turnbull]

Paul Moore writes:

 > With provisos. Figuring out contracts in sufficient detail to use
 > the code is *in many cases* simple. For harder cases, agreed. But
 > that's why this is simply a proof that contracts *can* be useful,
 > not that 100% of code would benefit from them.

Note that that is not what Marko wrote: he wrote that 100% of projects
on PyPI would benefit.  Like others, I'd like to see at least a
before/after on *one* whole project (that's not tiny, so it has
several meaningful APIs and several calls for at least a few of them),
to see *how much* of that project actually benefits, and how much of
that benefit derives from "more sophisticated than assert" DbC tech.

For now, I think the whole thread is technically speaking off-topic,
though.  Let's stipulate that DbC is a valuable technology that Python
programmers should have available.

(1) Why is it so valuable that it needs to be in the python.org
distribution?  We already have asserts for the simplest cases.
Won't PyPI do for the full-blown Meyer-style implementation?
Development discussion for that implementation should take place
on GitHub[1] or a similar channel, IMO.

(2) We don't have an implementation to include, or if you like there
are many PoCs, and there's no good reason to suppose that there
will be consensus on the candidate for inclusion in this decade.
Again, development discussions for those implementations should
take place on GitHub before coming here to discuss (a) which is
best for the stdlib, (b) whether it's good enough, and (c) whether
it's needed in the stdlib at all.  Is there a clear, leading
candidate that could be proposed "soon", icontracts maybe?

(3) The syntaxes proposed so far require inelegant constructs, like
lambdas or strs, so that decorator arguments can be evaluated
lazily.  Lazy evaluation of arguments is something that newcomers
often want after being burned by "def foo(l=[]):".  But there are
at least two plausible ways to handle this.  One is like Lisp
macros:  "defmacro mfoo(not, one, of, its, args, is, evaluated)".
Another would be a marker for args to be returned unevalled:
"def foo(eval_me, eval_me_not: unevalled, eval_me_too)".[2]

Thus, unevalled arguments *may* be a plausible syntax change that
would help support DbC as well as other possibly desirable use
cases, but we have no proposal to discuss.  Do we?

I'm not yet suggesting that this thread *should* be terminated here
(and that's not to avoid charges of hypocrisy as I post to other
subthreads ;-).  But I think we should be continuously aware of the
three questions I posed above.


Footnotes: 
[1]  Personally, I'd prefer it be GitLab. :-)

[2]  Yes, I'm teasing the type annotations folks, I doubt this syntax
will fly.


___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Why is design-by-contracts not widely adopted?

[Chris Angelico]

On Thu, Sep 27, 2018 at 3:31 PM Greg Ewing  wrote:
>
> Chris Angelico wrote:
> > if you let your API
> > docs rot when you make changes that callers need to be aware of, you
> > have failed your callers.
>
> Yes, I find that documentation auto-generated from code is
> usually a poor substitute for human-written documentation.
> Dumping your formally-written contracts into the docs makes
> the reader reverse-engineer them to figure out what the
> programmer was really trying to say.
>
> Which do you find easier to grok at a glance:
>
> all(L[i] <= L[i+1] for i in range(len(L) - 1))
>
> or
>
> # The list is now sorted
>

Well, with that particular example, you're capitalizing on the known
meaning of the English word "sorted". So to be fair, you should do the
same in Python:

postcondition: L == sorted(L)

This would be inappropriate for an actual sorting function, but let's
say you're altering the value of an item in a sorted list, and
shifting it within that list to get it to the new position, or
something like that.python-ideas 

But yes, in general I do agree: it's frequently cleaner to use an
English word than to craft a Python equivalent.

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/

Re: [Python-ideas] Why is design-by-contracts not widely adopted?

[Greg Ewing]

Chris Angelico wrote:

if you let your API
docs rot when you make changes that callers need to be aware of, you
have failed your callers.


Yes, I find that documentation auto-generated from code is
usually a poor substitute for human-written documentation.
Dumping your formally-written contracts into the docs makes
the reader reverse-engineer them to figure out what the
programmer was really trying to say.

Which do you find easier to grok at a glance:

   all(L[i] <= L[i+1] for i in range(len(L) - 1))

or

   # The list is now sorted

--
Greg
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Why is design-by-contracts not widely adopted?

[Stephen J. Turnbull]

Robert Collins writes:

 > I think the underlying problem is that you're treating this as a
 > logic problem (what does logic say applies here), rather than an
 > engineering problem (what can we measure and what does it tell us
 > about whats going on).

Pure gold.  I'm glad your name is "Robert Collins", or I would have
skipped the post and just muted the thread.

 > My suspicion, for which I have only anecdata, is that its really in c)
 > today. Kind of where TDD was in the early 2000's (and as I understand
 > the research, its been shown to be a wash: you do get more tests than
 > test-last or test-during,

That's a pretty big deal though, if it means the shop doesn't need The
Big Nurse to prod you to write more tests.

 > and more tests is correlated with quality and ease of evolution,
 > but if you add that test coverage in test-during or test-last, you
 > end up with the same benefits).

"No Silver Bullet." QED

I think Watts Humphrey should have titled his classic, "Any Discipline
for Software Engineering", and subtitled it "'Whatever' Works, as Long
as You Actually Do It".[1]  All of his books on the practice of
software engineering really do say that, by the way.  He recommends
*starting* with *his* way because it worked for him and many students,
so you can just follow the cookbook until "actually doing" becomes
natural.  Then change to doing what comes more naturally to you.


Footnotes: 
[1]  Fred Brooks would have done that, I think.  Humphrey was way too
stuffy to do that. :-)

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Why is design-by-contracts not widely adopted?

[David Mertz]

I'm not sure what to do with the repeated assurance that that various
things "are obvious."  It really is NOT the case that me, or Paul Moore, or
Hugh Fisher, or Greg Ewing are simply too simple minded to understand what
DbC is.

The off-putting evangelical quality around DbC is something like the
similar evangelical insistence that OOP solves all problems that one tended
to hear in the late-1980s to mid-1990s especially.  The fact that no one
can quite pin down just *what* this special quality of DbC is doesn't
help... the reality is that they really ARE NOT much different from
assertions, in either practice or theory.

Actually, the evangelical OOP thing connects with the evangelical DbC.  One
of the "advantages" of DbC is often stated as support for inheritance.  But
the truth is, I hardly ever use inheritance in my code, or at most very
shallow inheritance in ways where invariants are mostly not preserved.  My
use of OOP in Python is basically mixins plus magic methods... and no, it's
not because I don't understand OOP (I wrote, for example, some of the most
widely read papers on metaclass programming in Python, and designed and
wrote about making a—toy, admittedly—method resolution order and OOP system
for R; my frequent co-author wrote the canonical paper on C3 linearization,
in which I'm acknowledged for my edits, but am not an author).

I also wrote an article or two about DbC in Python in the early 2000s.
None of this is very new.

On Mon, Sep 24, 2018 at 3:47 AM Marko Ristin-Kaufmann <
marko.ris...@gmail.com> wrote:

> *Obvious benefits*
> You both seem to misconceive the contracts. The goal of the
> design-by-contract is not reduced to testing the correctness of the code,
> as I reiterated already a couple of times in the previous thread. The
> contracts document *formally* what the caller and the callee expect and
> need to satisfy when using a method, a function or a class. This is meant
> for a module that is used by multiple people which are not necessarily
> familiar with the code. They are *not *a niche. There are 150K projects
> on pypi.org. Each one of them would benefit if annotated with the
> contracts.
>

Greg Ewing, Chris Angelica, and Paul Moore make the point very well that
MOST code is simply not the sort of thing that is amenable to having
contracts.  What one needs to state is either Turing complete or trivially
reducible to type declarations.  Or the behavior is duck typed loosely
enough that it can do the right thing without being able to specify the
pre- and post-conditions more precisely than "do what this function does."
Very often, that looseness is simply NOT a problem, and is part of what
makes Python flexible and successful.

*Contracts are difficult to read.*
> David wrote:
>
>> To me, as I've said, DbC imposes a very large cost for both writers and
>> readers of code.
>>
>
> This is again something that eludes me and I would be really thankful if
> you could clarify. Please consider for an example, pypackagery (
> https://pypackagery.readthedocs.io/en/latest/packagery.html) and the
> documentation of its function resolve_initial_paths:
>

The documentation you show below is definitely beautiful  I guess that's
generated by your Sphinx enhancement, right?  There are similar systems for
pulling things out of docstrings that follow conventions, but there's a
small incremental value in making them live tests at the same time.

But reading the end-user documentation is not the *reading* I'm talking
about.  The reading I mean is looking at the actual source code files.
Stating all the invariants you want code to follow makes the definitions of
functions/methods longer and more cognitive effort to parse.  A ten line
function body is likely to be accompanied by 15 lines of invariants that
one can state about hopes for the function behavior.  That's not always
bad... but it's definitely not always good.

This is why unit tests are often much better, organizationally.  The
function definitions can remain relatively concise and clean because most
of the time when you are reading or modifying them you don't WANT to think
about those precise contracts.  Sure, maybe some tool support like folding
of contracts could make the burden less; but not less than putting them in
entirely separate files.

Most of the time, I'd like to look at the simplest expression of the code
possible.  Then on a different day, or with a different set of eyes, I can
look at the completely distinct file that has arbitrarily many unit tests
to check invariants I'd like functions to maintain.  Yes, the issues are a
little bit different in classes and nested hierarchies... but like I said,
I never write those, and tend not to like code that does.

> packagery.resolve_initial_paths(*initial_paths*)
>
> Resolve the initial paths of the dependency graph by recursively adding
> *.py files beneath given directories.
> Parameters:
>
> *initial_paths* (List[Path]) – initial paths as absolute paths
> Return type:
>
> 

Re: [Python-ideas] "while:" for the loop

[Mike Miller]

On 2018-09-25 17:46, Mikhail V wrote:

I suggest allowing "while:" syntax for the infinite loop.
I.e. instead of "while 1:"  and  "while True:" notations.

I like this idea, and would have use for it.

-Mike
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Why is design-by-contracts not widely adopted?

[Greg Ewing]

Chris Angelico wrote:

For example, matplotlib's
plt.show() method guarantees that... a plot will be shown, and the
user will have dismissed it, before it returns. Unless you're inside
Jupyter/iPython, in which case it's different. Or if you're in certain
other environments, in which case it's different again. How do you
define the contract for something that is fundamentally interactive?


Indeed, this is what bothers me about DbC fanaticism. It seems to
have been conceived by people thinking about very computer-sciency
kinds of problems, e.g. you're implenenting a data structure which
has certain important invariants that can be expressed mathematically,
and code can be written that checks them reasonably efficiently.
All very neat and self-contained.

But a lot of real-world code isn't like that -- much of the time,
the correctness of a piece of code can't be tested without reference
to things outside that piece of code, or even outside of the program
altogether. How would you write DbC contracts for a GUI, for
example? Most of the postconditions consist of "an image looking
something like this appears on the screen", where "this" is a very
complicated function of the previous state of the system and the
user's input.

IMO, the reason DbC hasn't taken off is that it assumes an idealised
model of what programming consists of that doesn't match reality
well enough.

--
Greg
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Why is design-by-contracts not widely adopted?

[Chris Angelico]

On Thu, Sep 27, 2018 at 10:07 AM Robert Collins
 wrote:
>
> On 27 September 2018 at 11:50, Chris Angelico  wrote:
>
> > Okay, but what is the contract that's being violated when you use
> > data= ? How would you define the contract that this would track?
> > That's what I'm asking.
>
> I don't know :). From a modelling perspective the correctness of the
> behaviour here depends on state in the server :/.

Exactly. It's the same problem as with trying to write contracts for
matplotlib's plt.show() - its job is fundamentally external, so you
can't define preconditions and postconditions for it. This is one of
the limitations of contracts, or at least that's my understanding.
Maybe I can be proven wrong here?

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/

Re: [Python-ideas] Why is design-by-contracts not widely adopted?

[Robert Collins]

On 27 September 2018 at 11:50, Chris Angelico  wrote:

> Okay, but what is the contract that's being violated when you use
> data= ? How would you define the contract that this would track?
> That's what I'm asking.

I don't know :). From a modelling perspective the correctness of the
behaviour here depends on state in the server :/.

-Rob
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Why is design-by-contracts not widely adopted?

[Chris Angelico]

On Thu, Sep 27, 2018 at 9:22 AM Robert Collins
 wrote:
>
> On Thu., 27 Sep. 2018, 11:00 Chris Angelico,  wrote:
>>
>> On Thu, Sep 27, 2018 at 8:53 AM Robert Collins
>>  wrote:
>> >
>> > On Thu, 27 Sep 2018 at 00:44, Marko Ristin-Kaufmann
>> >  wrote:
>> > >
>> > > P.S. My offer still stands: I would be very glad to annotate with 
>> > > contracts a set of functions you deem representative (e.g., from a 
>> > > standard library or from some widely used library). Then we can discuss 
>> > > how these contracts. It would be an inaccurate estimate of the benefits 
>> > > of DbC in Python, but it's at least better than no estimate. We can have 
>> > > as little as 10 functions for the start. Hopefully a couple of other 
>> > > people would join, so then we can even see what the variance of 
>> > > contracts would look like.
>> >
>> > i think requests would be a very interesting library to annotate. Just
>> > had a confused developer wondering why calling an API with
>> > session.post(, data={...some object dict here}) didn't work
>> > properly. (Solved by s/data/json), but perhaps illustrative of
>> > something this might help with?
>>
>> Not sure what you mean by not working; my suspicion is that it DID
>> work, but didn't do what you thought it did (it would form-encode).
>> Contracts wouldn't help there, because it's fully legal and correct.
>
>
> Giving post a data= results in form encoding, as you say.
> Giving it a json= results in json encoding.
>
> Works is a bit of a weasel word.
>
> The python code did not crash. However it did not perform as desired, either.
>
> And since that is pretty much the entire value proposition of DbC... it seems 
> like a good case to dissect.

Okay, but what is the contract that's being violated when you use
data= ? How would you define the contract that this would track?
That's what I'm asking.

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/

Re: [Python-ideas] Why is design-by-contracts not widely adopted?

[Robert Collins]

On Thu., 27 Sep. 2018, 11:00 Chris Angelico,  wrote:

> On Thu, Sep 27, 2018 at 8:53 AM Robert Collins
>  wrote:
> >
> > On Thu, 27 Sep 2018 at 00:44, Marko Ristin-Kaufmann
> >  wrote:
> > >
> > > P.S. My offer still stands: I would be very glad to annotate with
> contracts a set of functions you deem representative (e.g., from a standard
> library or from some widely used library). Then we can discuss how these
> contracts. It would be an inaccurate estimate of the benefits of DbC in
> Python, but it's at least better than no estimate. We can have as little as
> 10 functions for the start. Hopefully a couple of other people would join,
> so then we can even see what the variance of contracts would look like.
> >
> > i think requests would be a very interesting library to annotate. Just
> > had a confused developer wondering why calling an API with
> > session.post(, data={...some object dict here}) didn't work
> > properly. (Solved by s/data/json), but perhaps illustrative of
> > something this might help with?
>
> Not sure what you mean by not working; my suspicion is that it DID
> work, but didn't do what you thought it did (it would form-encode).
> Contracts wouldn't help there, because it's fully legal and correct.
>

Giving post a data= results in form encoding, as you say.
Giving it a json= results in json encoding.

Works is a bit of a weasel word.

The python code did not crash. However it did not perform as desired,
either.

And since that is pretty much the entire value proposition of DbC... it
seems like a good case to dissect.


(Unless session.post() differs from requests.post(), but I doubt that
> that'd be the case.)
>

It doesn't.

Rob

>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Why is design-by-contracts not widely adopted?

[Chris Angelico]

On Thu, Sep 27, 2018 at 8:53 AM Robert Collins
 wrote:
>
> On Thu, 27 Sep 2018 at 00:44, Marko Ristin-Kaufmann
>  wrote:
> >
> > P.S. My offer still stands: I would be very glad to annotate with contracts 
> > a set of functions you deem representative (e.g., from a standard library 
> > or from some widely used library). Then we can discuss how these contracts. 
> > It would be an inaccurate estimate of the benefits of DbC in Python, but 
> > it's at least better than no estimate. We can have as little as 10 
> > functions for the start. Hopefully a couple of other people would join, so 
> > then we can even see what the variance of contracts would look like.
>
> i think requests would be a very interesting library to annotate. Just
> had a confused developer wondering why calling an API with
> session.post(, data={...some object dict here}) didn't work
> properly. (Solved by s/data/json), but perhaps illustrative of
> something this might help with?

Not sure what you mean by not working; my suspicion is that it DID
work, but didn't do what you thought it did (it would form-encode).
Contracts wouldn't help there, because it's fully legal and correct.

(Unless session.post() differs from requests.post(), but I doubt that
that'd be the case.)

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/

Re: [Python-ideas] Why is design-by-contracts not widely adopted?

[Robert Collins]

On Thu, 27 Sep 2018 at 00:44, Marko Ristin-Kaufmann
 wrote:
>
> P.S. My offer still stands: I would be very glad to annotate with contracts a 
> set of functions you deem representative (e.g., from a standard library or 
> from some widely used library). Then we can discuss how these contracts. It 
> would be an inaccurate estimate of the benefits of DbC in Python, but it's at 
> least better than no estimate. We can have as little as 10 functions for the 
> start. Hopefully a couple of other people would join, so then we can even see 
> what the variance of contracts would look like.

i think requests would be a very interesting library to annotate. Just
had a confused developer wondering why calling an API with
session.post(, data={...some object dict here}) didn't work
properly. (Solved by s/data/json), but perhaps illustrative of
something this might help with?

-Rob
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] "old" values in postconditions

[James Lu]

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  
> 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  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  
>> 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 

Re: [Python-ideas] Why is design-by-contracts not widely adopted?

[Chris Angelico]

On Thu, Sep 27, 2018 at 5:07 AM Chris Barker  wrote:
>
> On Tue, Sep 25, 2018 at 10:10 PM Lee Braiden  wrote:
>>
>> It's the reason why type checking exists, and why bounds checking exists, 
>> and why unit checking exists too.
>
> And yet Python has none of those. They all provide safety, but also place a 
> burden on the developer.

Type checking? Depends on your definition. Since objects are typed,
Python is safe against the old "I passed an integer when it expected
an array" problem (which probably would result in a junk memory read,
in C), whether the function's arguments are type-checked or not. And
if you want actual type checking, that's available too, just not as
part of the core language (and it has language support for its
syntax).

Bounds checking? Most definitely exists. If you try to subscript a
string or list with a value greater than its length, you get an
exception.

Unit checking? If that's "unit testing", that's part of the standard
library, so yes, that definitely exists in Python.

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/

Re: [Python-ideas] Why is design-by-contracts not widely adopted?

[Chris Barker via Python-ideas]

On Tue, Sep 25, 2018 at 10:10 PM Lee Braiden  wrote:

> It's the reason why type checking exists, and why bounds checking exists,
> and why unit checking exists too.
>

And yet Python has none of those. They all provide safety, but also place a
burden on the developer.

So why use Python? I’m not arguing that all those features don’t have their
advantages, but I am wondering why add them all to Python, rather than
using a language designed for safety?

But Python has such a great ecosystem of packages! Yes, it does — but you
might ask yourself why that is.

All that being said — do go and make a nice DbC package for Python — maybe
all us naysayers will grow to love it!

But could we please stop cluttering this list with discussion of how great
or not great it is?

These meta-conversations are getting really tiresome.

-CHB


-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Why is design-by-contracts not widely adopted?

[Marko Ristin-Kaufmann]

Hi David,
I'm writing contracts for pathlib as a proof-of-concept.

See pypackagery for an example of a project on pypi that uses contracts:
https://pypi.org/project/pypackagery/

The docs with contracts are available at:
https://pypackagery.readthedocs.io/en/latest/packagery.html

Mind that the interface to icontract might change soon so I'd wait a month
or two before it stabilizes.

Cheers,
Marko

Le mer. 26 sept. 2018 à 20:12, David Stanek  a écrit :

> On Wed, Sep 26, 2018 at 12:49 AM Marko Ristin-Kaufmann
>  wrote:
> >
> >> 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.
> >
>
> I have to admit that I haven't kept up with the discussion today, but
> I was also hoping to see some proof. I'm genuinely interested in
> seeing if this is something that can help me and the teams I work
> with. I was very interested in DbC a long time ago, but never found a
> way to make it valuable to me.
>
> I'd like to see a project from PyPI converted to use DbC. This would
> make it easy to see the real world difference between an
> implementation developed using DbC compared to one that is well
> documented, tested and maybe even includes type hints. Toy or
> cherry-picked examples don't help me get a feel for it.
>
> --
> david stanek
> web: https://dstanek.com
> twitter: https://twitter.com/dstanek
> linkedin: https://www.linkedin.com/in/dstanek/
> ___
> 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/

Re: [Python-ideas] "while:" for the loop

[Mikhail V]

On Wed, Sep 26, 2018 at 4:46 PM Mark E. Haase  wrote:
>
> On Tue, Sep 25, 2018 at 8:47 PM Mikhail V  wrote:
>>
>> 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
>
> This proposal would be a lot stronger if you included those statistics
> in this thread and showed examples of stdlib code before/after the
> proposed syntax change.

I can't find the discussion with the statistics, but here two related
discussions:
https://mail.python.org/pipermail/python-ideas/2014-June/028202.html
https://mail.python.org/pipermail/python-ideas/2017-March/045344.html

The statistics was in one of 2016 or 2017 discussions, but I have failed to
find it. By any chance- maybe someone can do it here? I could do but it
would need to exclude comments/ strings from the search - I don't have a
such tool at hand.
Numbers for "while 1" and "while True" should suffice.

> I imagine that a new loop keyword could be introduced in
> a backwards-compatible way.

Now I don't know whom to believe.
In the first linked discussion, e.g. Mr. D'Aprano and Mr. Coghlan (from my
impression both from dev team) unambiguosly claimed that adding e.g.
"loop" as a loop token lead to necessity of excluding ALL
variables and functions/methods named "loop" from all sources.
https://mail.python.org/pipermail/python-ideas/2014-June/028206.html

So what is the real situation?
What I can tell - simple syntax highlighting systems and syntax checkers
will not be able to tell the difference between the statement initial token
and identifier.


Speaking of a new keyword: I can see only one benefit of new keyword
in this case: it can be extended with additional usage for "loop N"

loop N:
print ("=")   # iterates N times

And I like the word "loop" slightly more than "repeat".

But still - even if it's technically possible without breaking something,
I am a bit skeptical, as it's a step towards *bloat*.
Keeping less keywords, especially for loops is much more important
than 'natural language' semantics.

BTW: Here is statistics for the C language:
https://stackoverflow.com/questions/20186809/endless-loop-in-c-c

It turns out that "for(;;)" is more frequent than "while 1" and "while true".
Since Python has "for" than maybe it is possible to use "for"
for the infinite loop:

for:
   ...

And maybe even  it could be made into "for N:"?
Now:

for N:

is SyntaxError, so it might be possible to use "for" for both cases.
What do you think?



> The meaning of "while" in natural language suggests a period of time or
> condition. It does not mean "forever". Therefore, it's not a good semantic 
> fit.

I am not much into the "what it means in natural languages" games, as long
as it's understandable and already established token.

"while True:" is the infinite loop and the "True" or "1" does not add anything
practically useful for working with sources, period. Mostly causes unwanted
attention, as I expect expression or variable there. So basically it's noise.

"while:" on the contrary is visually clean, gives 100% difference
with "while Variable:" - it just tells : here is the start of the loop.
So the semantics would be: "while:" is an infinite loop, that's it.


Mikhail
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Why is design-by-contracts not widely adopted?

[David Stanek]

On Wed, Sep 26, 2018 at 12:49 AM Marko Ristin-Kaufmann
 wrote:
>
>> 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.
>

I have to admit that I haven't kept up with the discussion today, but
I was also hoping to see some proof. I'm genuinely interested in
seeing if this is something that can help me and the teams I work
with. I was very interested in DbC a long time ago, but never found a
way to make it valuable to me.

I'd like to see a project from PyPI converted to use DbC. This would
make it easy to see the real world difference between an
implementation developed using DbC compared to one that is well
documented, tested and maybe even includes type hints. Toy or
cherry-picked examples don't help me get a feel for it.

-- 
david stanek
web: https://dstanek.com
twitter: https://twitter.com/dstanek
linkedin: https://www.linkedin.com/in/dstanek/
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] "while:" for the loop

[Kirill Balunov]

On Wed, Sep 26, 2018, 19:30 David Mertz  wrote:

> We also have:
>
> from itertools import count
> for i in count():
> ...
>
> If you want to keep track of how close to infinity you are. :-)
>

We also have:

from itertools import repeat
for i in repeat(...):
...

with kind regards,
-gdg
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Why is design-by-contracts not widely adopted?

[James Lu]

> It's easy to say that they're boolean expressions. But that's like
> saying that unit tests are just a bunch of boolean expressions too.
> Why do we have lots of different forms of test, rather than just a big
> fat "assert this and this and this and this and this and this"?
> Because the key to unit testing is not "boolean expressions", it's a
> language that can usefully describe what it is we're testing.
> Contracts aren't just boolean expressions - they're a language (or a
> mini-language) that lets you define WHAT the contract entails.
Please read the earlier discussion from Marko. Contracts are like unit tests 
but acts as documentation that is right next to the function definition. It’s 
also much shorter in number of lines to define. You can write a simple unit 
smoke test to turn a contract into a unit test. Contracts serve unit testing 
and documentation at the same time.

Sent from my iPhone

> On Sep 26, 2018, at 3:18 AM, Chris Angelico  wrote:
> 
> It's easy to say that they're boolean expressions. But that's like
> saying that unit tests are just a bunch of boolean expressions too.
> Why do we have lots of different forms of test, rather than just a big
> fat "assert this and this and this and this and this and this"?
> Because the key to unit testing is not "boolean expressions", it's a
> language that can usefully describe what it is we're testing.
> Contracts aren't just boolean expressions - they're a language (or a
> mini-language) that lets you define WHAT the contract entails.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] "while:" for the loop

[Michael Selik]

On Wed, Sep 26, 2018, 9:42 AM Tobias Kohn  wrote:

> Although I doubt it will really make it into Python's grammar, I am all +1
> for the idea of having "repeat" as a loop keyword in Python.  Actually, I
> have been using "repeat" as a keyword in Python for quite some time now,
> and found it not only convenient, but also a great help in education.
>
Guido has repeatedly (haha) rejected this proposal [0]. He has written that
he considered it, but decided that in practical code one almost always
loops over data, and does not want an arbitrary number of iterations. The
range object solves this problem.

You might notice that a repeat keyword appears in many graphics-focused
child education languages, but not many "serious" languages.

[0] I remember at least two times, but can't find them with search at the
moment.

>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Why is design-by-contracts not widely adopted?

[Paul Moore]

On Wed, 26 Sep 2018 at 16:04, Rhodri James  wrote:
> Marko is making some very big assertions about how much of a benefit
> Design by Contract is.  I flat-out don't believe him.  It's up to him to
> provide some evidence, since he's the one pressing for change.

And to be fair, he's now offered to put some time into producing such
a demonstration, so asking for some facts has had a positive outcome.
(As well as demonstrating that Marko is happy to back up his position
and not just make unsubstantiated assertions - so that in itself is
good to know).

Paul
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Why is design-by-contracts not widely adopted?

[Rhodri James]

On 25/09/18 21:09, Lee Braiden wrote:

Eh. It's too easy to cry "show me the facts" in any argument.  To do that
too often is to reduce all discussion to pendantry.


I will resist pointing out the spelling mistake... oh damn :-)

The trouble with not crying "show me the facts" is that it is very easy 
to make beautiful sounding assertions into a vacuum that fall apart the 
moment you subject them to reality.  I'm sure we can all think of 
politicians of a variety of parties and nationalities with an 
unfortunate habit of doing exactly that.


Marko is making some very big assertions about how much of a benefit 
Design by Contract is.  I flat-out don't believe him.  It's up to him to 
provide some evidence, since he's the one pressing for change.



That verifying data against the contract a function makes code more
reliable should be self evident to anyone with even the most rudimentary
understanding of a function call, let alone a library or large
application.


Let's assume that the contracts are meaningful and useful (which I'm 
pretty sure won't be 100% true; some people are bound to assume that 
writing contracts means they don't have to think).  Assuming that you 
aren't doing some kind of wide-ranging static analysis (which doesn't 
seem to be what we're talking about), all that the contracts have bought 
you is the assurance that *this* invocation of the function with *these* 
parameters giving *this* result is what you expected.  It does not say 
anything about the reliability of the function in general.


It seems to me that a lot of the DbC philosophy seems to assume that 
functions are complex black-boxes whose behaviours are difficult to 
grasp.  In my experience this is very rarely true.  Most functions I 
write are fairly short and easily grokked, even if they do complicated 
things.  That's part of the skill of breaking a problem down, IMHO; if 
the function is long and horrible-looking, I've already got it wrong and 
no amount of protective scaffolding like DbC is going to help.



It's the reason why type checking exists,


Except Python doesn't type check so much as try operations and see if 
they work.



and why bounds checking exists,


Not in C, not most of the time :-)


and why unit checking exists too.


Unit tests are good when you can do them.  A fair bit of the embedded 
code I write isn't very susceptible to automated testing, though, not 
without spending twice as long writing (and testing!) the test 
environment as the code.


--
Rhodri James *-* Kynesim Ltd
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] "while:" for the loop

[Mark E. Haase]

On Tue, Sep 25, 2018 at 8:47 PM Mikhail V  wrote:

> 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).
>

This proposal would be a lot stronger if you included those statistics in
this thread and showed examples of stdlib code before/after the proposed
syntax change.

The meaning of "while" in natural language suggests a period of time or
condition. It does not mean "forever". Therefore, it's not a good semantic
fit. Python has shown a willingness to introduce new keywords: "async" and
"await" were added in Python 3.5, which was released about 3 years ago. I
imagine that a new loop keyword could be introduced in a
backwards-compatible way.

If you dislike the look of `while True:`, you can almost always hide it
inside a generator and use a `for … in …` block with clearer meaning.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] "while:" for the loop

[Tobias Kohn]

 Hello,

Although I doubt it will really make it into Python's grammar, I am  
all +1 for the idea of having "repeat" as a loop keyword in Python.   
Actually, I have been using "repeat" as a keyword in Python for quite  
some time now, and found it not only convenient, but also a great help  
in education.


My version of "repeat" has two versions.  The primary usage is with an  
expression that evaluates to a number and specifies how many times the  
loop is to be repeated:

```
repeat :
    
```
The second version is without the number, and, indeed, stands for an  
infinite loop.

```
repeat:
    
```
I must admit, though, that I had hardly ever reason to use the second form.

The implementation is currently built on top of Jython, and uses  
something like a preprocessor to implement the "repeat"-keyword.  In  
order to keep some backward compatibility, the preprocessor does check  
a few cases to determine how it is used, and does not always treat it  
as a keyword.


Even though it is possible to write a parser that detects if "repeat"  
is used as the keyword for a loop or anything else, it will make the  
syntax very brittle.  Take, for instance:

```
repeat (3*4)
```
Now, is this supposed to be a function call, or is it a  
`repeat`-statement with a missing colon at the end? 


I therefore would strongly advise against having a word act as a  
keyword sometimes, and sometimes not.  Probably a better solution  
would be to have something like `from __features__ import repeat` at  
the beginning.


My reason for introducing "repeat" into Python in the first place was  
because of didactical considerations.  Even though it might not seem  
so, variables are indeed a very hard concept in programming,  
particularly for younger students.  And variables get particularly  
hard when combined with loops, where the value of a variable changes  
all the time (this requires a lot of abstract thinking to be properly  
understood).  Loops alone, on the other hand, are a relatively easy  
concept that could be used early one.  So, there is this dilemma: how  
do you teach loops at an early stage without using variables?  That's  
when I added the "repeat"-keyword for loops, and it has worked  
marvellously so far :).


Cheers,
Tobias

Quoting James Lu :


repeat could be only considered a keyword when it’s used as a loop

Sent from my iPhone


On Sep 26, 2018, at 8:46 AM, Brice Parent  wrote:


Le 26/09/2018 à 14:33, James Lu a écrit :
what about “repeat:”?

Sent from my iPhone


I'm not sure it was on purpose, but you replied to me only, and not  
the entire list.
I believe the adding of a new keyword to do something that is  
already straightforward (`while True:`), and that doesn't add any  
new functionality, won't probably ever be accepted.


___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideasCode 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/

Re: [Python-ideas] Why is design-by-contracts not widely adopted?

[Marko Ristin-Kaufmann]

Hi Paul,
Quite a few people replied on this thread and the previous one before the
fork that dbc is either useless in Python or at best useful in
avionics/niche applications.

I'm really only saying that contracts are a superior (complementary) tool
to informal documentation, doctests, reading the implementation, reading
the tests and trial-and-error.

For every library that have the contracts which can be written down
formally in a pragmatic way, and when the users of the library are multiple
-- then these libraries would benefit from dbc.

That's all that I'm saying and it might have come over as arrogant due to
limits of the medium. It was not my intention to sound so.

I'll have a look at pathlib then.

Cheers,
Marko



Le mer. 26 sept. 2018 à 15:15, Paul Moore  a écrit :

> On Wed, 26 Sep 2018 at 14:04, Marko Ristin-Kaufmann
>  wrote:
> >
> > @Chris Angelico  would annotating pathlib convince you that contracts
> are useful? Is it general enough to start with?
>
> Whoa - be careful here. No-one is saying that "contracts aren't
> useful" (at least not that I'd heard). We're saying that contracts
> *aren't a solution for every library in existence* (which was
> essentially your claim). Annotating pathlib can't convince anyone of
> that claim. At best (and this is all that I'm imagining) it might give
> some indication of why you have such an apparently-unreasonable level
> of confidence in contracts.
>
> I do not expect *ever* to believe you when you say that all projects
> would benefit from contracts. What I might get from such an exercise
> is a better understanding of what you're imagining when you talk about
> a real project "using contracts". Best case scenario - I might be
> persuaded to use them occasionally. Worst case scenario - I find them
> distracting and unhelpful, and we agree to differ on their value.
>
> Paul
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Why is design-by-contracts not widely adopted?

[Paul Moore]

On Wed, 26 Sep 2018 at 14:04, Marko Ristin-Kaufmann
 wrote:
>
> @Chris Angelico  would annotating pathlib convince you that contracts are 
> useful? Is it general enough to start with?

Whoa - be careful here. No-one is saying that "contracts aren't
useful" (at least not that I'd heard). We're saying that contracts
*aren't a solution for every library in existence* (which was
essentially your claim). Annotating pathlib can't convince anyone of
that claim. At best (and this is all that I'm imagining) it might give
some indication of why you have such an apparently-unreasonable level
of confidence in contracts.

I do not expect *ever* to believe you when you say that all projects
would benefit from contracts. What I might get from such an exercise
is a better understanding of what you're imagining when you talk about
a real project "using contracts". Best case scenario - I might be
persuaded to use them occasionally. Worst case scenario - I find them
distracting and unhelpful, and we agree to differ on their value.

Paul
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Why is design-by-contracts not widely adopted?

[Chris Angelico]

On Wed, Sep 26, 2018 at 11:04 PM Marko Ristin-Kaufmann
 wrote:
> @Chris Angelico  would annotating pathlib convince you that contracts are 
> useful? Is it general enough to start with?
>

I won't promise it'll convince me, but it'll certainly be a
starting-point for real discussion. Also, it's a fairly coherent
"library-style" module - a nice warm-up. So, when you're ready for a
REAL challenge, annotate tkinter :)

Actually, annotating the builtins might be worth doing too. Either
instead of or after pathlib.

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/

Re: [Python-ideas] Why is design-by-contracts not widely adopted?

[Marko Ristin-Kaufmann]

Hi Paul,

Are we talking here about coding explicit executable contracts in the
> source code of the library, or using (formally described in terms of
> (pseudo-)code) contract-style descriptions in the documentation, or
> simply using the ideas of contract-based thinking in designing and
> writing code?
>

The current implementation of icontract uses decorators to decorate the
functions and classes (and metaclasses to support inheritance of
contracts). You have an "enabled" flag which you can set on/off if you want
to disable the contract in some situations.

We are talking about the explicit executable contracts :).

You didn't address my question "does this apply to the stdlib"? If it
> doesn't, your argument has a huge hole - how did you decide that the
> solution you're describing as "beneficial to all libraries" doesn't
> improve the stdlib? If it does, then why not demonstrate your case?
> Give concrete examples - look at some module in the stdlib (for
> example, pathlib) and show exactly what contracts you'd add to the
> code, what the result would look like to the library user (who
> normally doesn't read the source code) and to the core dev (who does).
> Remember that pathlib (like all of the stdlib) doesn't use type
> annotations, and that is a *deliberate* choice, mandated by Guido when
> he first introduced type annotations. So you're not allowed to add
> contracts like "arg1 is a string", nor are you allowed to say that the
> lack of type annotations makes the exercise useless.


Sorry, I missed that point; the messages are getting long :) Yes, the
contracts would make sense in stdlib as well, I'd say.

@Chris Angelico   would annotating pathlib convince you
that contracts are useful? Is it general enough to start with?

On Wed, 26 Sep 2018 at 14:58, Paul Moore  wrote:

> On Wed, 26 Sep 2018 at 13:40, Marko Ristin-Kaufmann
>  wrote:
>
> > Please mind that I said: any library would benefit from it, as in the
> users of any library on pipy would benefit from better, formal and more
> precise documentation. That doesn't imply that all the contracts need to be
> specified or that you have to specify the contract for every function, or
> that you omit the documentation altogether. Some contracts are simply too
> hard to get explicitly. Some are not meaningful even if you could write
> them down. Some you'd like to add, but run only at test time since too slow
> in production. Some run in production, but are not included in the
> documentation (e.g., to prevent the system to enter a bad state though it
> is not meaningful for the user to actually read that contract).
> >
> > Since contracts are formally written, they can be verified. Human text
> can not. Specifying all the contracts is in most cases not meaningful. In
> my day-to-day programming, I specify contracts on the fly and they help me
> express formally to the next girl/guy who will use my code what to expect
> or what not. That does not mean that s/he can just skip the documentation
> or that contracts describe fully what the function does. They merely help
> -- help him/her what arguments and results are expected. That does not mean
> that I fully specified all the predicates on the arguments and the result.
> It's merely a help à la
> > * "Ah, this argument needs to be bigger than that argument!"
> > * "Ah, the resulting dictionary is shorter than the input list!"
> > * "Ah, the result does not include the input list"
> > * "Ah, this function accepts only files (no directories) and relative
> paths!"
> > * "Ah, I put the bounding box outside of the image -- something went
> wrong!"
> > * "Ah, this method allows me to put the bounding box outside of the
> image and will fill all the outside pixels with black!" etc.
>
> Whoops, I think the rules changed under me again :-(
>
> Are we talking here about coding explicit executable contracts in the
> source code of the library, or using (formally described in terms of
> (pseudo-)code) contract-style descriptions in the documentation, or
> simply using the ideas of contract-based thinking in designing and
> writing code?
>
> > For example, if I have an object detector operating on a
> region-of-interest and returning bounding boxes of the objects, the
> postconditions will not be: "all the bounding boxes are cars", that would
> impossible. But the postcondition might check that all the bounding boxes
> are within the region-of-interest or slightly outside, but not completely
> outside etc.
>
> I understand that you have to pick an appropriate level of strictness
> when writing contracts. That's not ever been in question (at least in
> my mind).
>
> > Let's be careful not to make a straw-man here, i.e. to push DbC ad
> absurdum and then discard it that way.
>
> I'm not trying to push DbC to that point. What I *am* trying to do is
> make it clear that your arguments (and in particular the fact that you
> keep insisting that "everything" can benefit) are absurd. If you'd
> tone back on the 

Re: [Python-ideas] "while:" for the loop

[James Lu]

repeat could be only considered a keyword when it’s used as a loop

Sent from my iPhone

> On Sep 26, 2018, at 8:46 AM, Brice Parent  wrote:
> 
>> Le 26/09/2018 à 14:33, James Lu a écrit :
>> what about “repeat:”?
>> 
>> Sent from my iPhone
> I'm not sure it was on purpose, but you replied to me only, and not the 
> entire list.
> I believe the adding of a new keyword to do something that is already 
> straightforward (`while True:`), and that doesn't add any new functionality, 
> won't probably ever be accepted.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Why is design-by-contracts not widely adopted?

[Paul Moore]

On Wed, 26 Sep 2018 at 13:43, Marko Ristin-Kaufmann
 wrote:
>
> P.S. My offer still stands: I would be very glad to annotate with contracts a 
> set of functions you deem representative (e.g., from a standard library or 
> from some widely used library). Then we can discuss how these contracts. It 
> would be an inaccurate estimate of the benefits of DbC in Python, but it's at 
> least better than no estimate. We can have as little as 10 functions for the 
> start. Hopefully a couple of other people would join, so then we can even see 
> what the variance of contracts would look like.

Our mails crossed in the ether, sorry.

Pathlib.

Paul
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] "old" values in postconditions

[Marko Ristin-Kaufmann]

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  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.ris...@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 

Re: [Python-ideas] Why is design-by-contracts not widely adopted?

[Paul Moore]

On Wed, 26 Sep 2018 at 13:40, Marko Ristin-Kaufmann
 wrote:

> Please mind that I said: any library would benefit from it, as in the users 
> of any library on pipy would benefit from better, formal and more precise 
> documentation. That doesn't imply that all the contracts need to be specified 
> or that you have to specify the contract for every function, or that you omit 
> the documentation altogether. Some contracts are simply too hard to get 
> explicitly. Some are not meaningful even if you could write them down. Some 
> you'd like to add, but run only at test time since too slow in production. 
> Some run in production, but are not included in the documentation (e.g., to 
> prevent the system to enter a bad state though it is not meaningful for the 
> user to actually read that contract).
>
> Since contracts are formally written, they can be verified. Human text can 
> not. Specifying all the contracts is in most cases not meaningful. In my 
> day-to-day programming, I specify contracts on the fly and they help me 
> express formally to the next girl/guy who will use my code what to expect or 
> what not. That does not mean that s/he can just skip the documentation or 
> that contracts describe fully what the function does. They merely help -- 
> help him/her what arguments and results are expected. That does not mean that 
> I fully specified all the predicates on the arguments and the result. It's 
> merely a help à la
> * "Ah, this argument needs to be bigger than that argument!"
> * "Ah, the resulting dictionary is shorter than the input list!"
> * "Ah, the result does not include the input list"
> * "Ah, this function accepts only files (no directories) and relative paths!"
> * "Ah, I put the bounding box outside of the image -- something went wrong!"
> * "Ah, this method allows me to put the bounding box outside of the image and 
> will fill all the outside pixels with black!" etc.

Whoops, I think the rules changed under me again :-(

Are we talking here about coding explicit executable contracts in the
source code of the library, or using (formally described in terms of
(pseudo-)code) contract-style descriptions in the documentation, or
simply using the ideas of contract-based thinking in designing and
writing code?

> For example, if I have an object detector operating on a region-of-interest 
> and returning bounding boxes of the objects, the postconditions will not be: 
> "all the bounding boxes are cars", that would impossible. But the 
> postcondition might check that all the bounding boxes are within the 
> region-of-interest or slightly outside, but not completely outside etc.

I understand that you have to pick an appropriate level of strictness
when writing contracts. That's not ever been in question (at least in
my mind).

> Let's be careful not to make a straw-man here, i.e. to push DbC ad absurdum 
> and then discard it that way.

I'm not trying to push DbC to that point. What I *am* trying to do is
make it clear that your arguments (and in particular the fact that you
keep insisting that "everything" can benefit) are absurd. If you'd
tone back on the extreme claims (as Chris has also asked) then you'd
be more likely to get people interested. This is why (as you
originally asked) DbC is not more popular - its proponents don't seem
to be able to accept that it might not be the solution to every
problem. Python users are typically fairly practical, and think in
terms of "if it helps in this situation, I'll use it". Expecting them
to embrace an argument that demands they accept it applies to
*everything* is likely to meet with resistance.

You didn't address my question "does this apply to the stdlib"? If it
doesn't, your argument has a huge hole - how did you decide that the
solution you're describing as "beneficial to all libraries" doesn't
improve the stdlib? If it does, then why not demonstrate your case?
Give concrete examples - look at some module in the stdlib (for
example, pathlib) and show exactly what contracts you'd add to the
code, what the result would look like to the library user (who
normally doesn't read the source code) and to the core dev (who does).
Remember that pathlib (like all of the stdlib) doesn't use type
annotations, and that is a *deliberate* choice, mandated by Guido when
he first introduced type annotations. So you're not allowed to add
contracts like "arg1 is a string", nor are you allowed to say that the
lack of type annotations makes the exercise useless.

I think I've probably said all I can usefully say here. If you do
write up a DbC-enhanced pathlib, I'll be interested in seeing it and
may well have more to say as a result. If not, I think I'm just going
to file your arguments as "not proven".

Paul
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Why is design-by-contracts not widely adopted?

[Marko Ristin-Kaufmann]

P.S. My offer still stands: I would be very glad to annotate with contracts
a set of functions you deem representative (*e.g., *from a standard library
or from some widely used library). Then we can discuss how these contracts.
It would be an inaccurate estimate of the benefits of DbC in Python, but
it's at least better than no estimate. We can have as little as 10
functions for the start. Hopefully a couple of other people would join, so
then we can even see what the variance of contracts would look like.

On Wed, 26 Sep 2018 at 14:40, Marko Ristin-Kaufmann 
wrote:

> Hi Chris and Paul,
>
> Let me please answer your messages in one go as they are related.
>
> Paul wrote:
>
>> For most single use (or infrequently used) functions, I'd argue that the
>> trade-off *isn't* worth it.
>>
>> Here's a quick example from the pip codebase:
>>
>> # Retry every half second for up to 3 seconds
>> @retry(stop_max_delay=3000, wait_fixed=500)
>> def rmtree(dir, ignore_errors=False):
>> shutil.rmtree(dir, ignore_errors=ignore_errors,
>>   onerror=rmtree_errorhandler)
>
>
> Absolutely, I agree. If it's a single-use or infrequently used function
> that hardly anybody uses, it's not worth it. Moreover, if some contracts
> are harder to figure out than the implementation, then they are probably in
> most cases not worth the effort, too.
>
> Please mind that I said: any *library* would benefit from it, as in the
> users of any library on pipy would benefit from better, formal and more
> precise documentation. That doesn't imply that all the contracts need to be
> specified or that you have to specify the contract for *every *function,
> or that you omit the documentation altogether. Some contracts are simply
> too hard to get explicitly. Some are not meaningful even if you could write
> them down. Some you'd like to add, but run only at test time since too slow
> in production. Some run in production, but are not included in the
> documentation (*e.g., *to prevent the system to enter a bad state though
> it is not meaningful for the user to actually *read* that contract).
>
> Since contracts are formally written, they can be verified. Human text *can
> not*. Specifying all the contracts is in most cases *not *meaningful. In
> my day-to-day programming, I specify contracts on the fly and they help me
> express formally to the next girl/guy who will use my code what to expect
> or what not. That does not mean that s/he can just skip the documentation
> or that contracts describe fully what the function does. They merely help
> -- help him/her what arguments and results are expected. That *does not
> mean *that I fully specified all the predicates on the arguments and the
> result. It's merely a help à la
> * "Ah, this argument needs to be bigger than that argument!"
> * "Ah, the resulting dictionary is shorter than the input list!"
> * "Ah, the result does not include the input list"
> * "Ah, this function accepts only files (no directories) and relative
> paths!"
> * "Ah, I put the bounding box outside of the image -- something went
> wrong!"
> * "Ah, this method allows me to put the bounding box outside of the image
> and will fill all the outside pixels with black!"
>
> *etc.*
> For example, if I have an object detector operating on a
> region-of-interest and returning bounding boxes of the objects, the
> postconditions will not be: "all the bounding boxes are cars", that would
> impossible. But the postcondition might check that all the bounding boxes
> are within the region-of-interest or slightly outside, but not completely
> outside *etc.*
>
> Let's be careful not to make a straw-man here, *i.e. *to push DbC *ad
> absurdum *and then discard it that way.
>
> Also, the implicit contracts code currently has are typically pretty
>> loose. What you need to "figure out" is very general. Explicit contracts
>> are typically demonstrated as being relatively strict, and figuring out and
>> writing such contracts is more work than writing code with loose implicit
>> contracts. Whether the trade-off of defining tight explicit contracts once
>> vs inferring a loose implicit contract every time you call the function is
>> worth it, depends on how often the function is called. For most single use
>> (or  infrequently used)  functions, I'd argue that the trade-off *isn't*
>> worth it.
>
>
> I don't believe such an approach would ever be pragmatical, *i.e. *automatic
> versioning based on the contracts. It might hint it (as a warning: you
> changed a contract, but did not bump the version), but relying solely on
> this mechanism to get the versioning would imply that you specified *all *the
> contracts. Though Bertrand might have always envisioned it as the best
> state of the world, even he himself repeatedly said that it's better to
> specify rather 10% than 0% contracts and 20% rather than 10% contracts.
>
> Chris wrote:
>
>> def fibber(n):
>> return n if n < 2 else fibber(n-1) + fibber(n-2)
>
>
> It depends who 

Re: [Python-ideas] Why is design-by-contracts not widely adopted?

[Marko Ristin-Kaufmann]

Hi Chris and Paul,

Let me please answer your messages in one go as they are related.

Paul wrote:

> For most single use (or infrequently used) functions, I'd argue that the
> trade-off *isn't* worth it.
>
> Here's a quick example from the pip codebase:
>
> # Retry every half second for up to 3 seconds
> @retry(stop_max_delay=3000, wait_fixed=500)
> def rmtree(dir, ignore_errors=False):
> shutil.rmtree(dir, ignore_errors=ignore_errors,
>   onerror=rmtree_errorhandler)


Absolutely, I agree. If it's a single-use or infrequently used function
that hardly anybody uses, it's not worth it. Moreover, if some contracts
are harder to figure out than the implementation, then they are probably in
most cases not worth the effort, too.

Please mind that I said: any *library* would benefit from it, as in the
users of any library on pipy would benefit from better, formal and more
precise documentation. That doesn't imply that all the contracts need to be
specified or that you have to specify the contract for *every *function, or
that you omit the documentation altogether. Some contracts are simply too
hard to get explicitly. Some are not meaningful even if you could write
them down. Some you'd like to add, but run only at test time since too slow
in production. Some run in production, but are not included in the
documentation (*e.g., *to prevent the system to enter a bad state though it
is not meaningful for the user to actually *read* that contract).

Since contracts are formally written, they can be verified. Human text *can
not*. Specifying all the contracts is in most cases *not *meaningful. In my
day-to-day programming, I specify contracts on the fly and they help me
express formally to the next girl/guy who will use my code what to expect
or what not. That does not mean that s/he can just skip the documentation
or that contracts describe fully what the function does. They merely help
-- help him/her what arguments and results are expected. That *does not
mean *that I fully specified all the predicates on the arguments and the
result. It's merely a help à la
* "Ah, this argument needs to be bigger than that argument!"
* "Ah, the resulting dictionary is shorter than the input list!"
* "Ah, the result does not include the input list"
* "Ah, this function accepts only files (no directories) and relative
paths!"
* "Ah, I put the bounding box outside of the image -- something went wrong!"
* "Ah, this method allows me to put the bounding box outside of the image
and will fill all the outside pixels with black!"

*etc.*
For example, if I have an object detector operating on a region-of-interest
and returning bounding boxes of the objects, the postconditions will not
be: "all the bounding boxes are cars", that would impossible. But the
postcondition might check that all the bounding boxes are within the
region-of-interest or slightly outside, but not completely outside *etc.*

Let's be careful not to make a straw-man here, *i.e. *to push DbC *ad
absurdum *and then discard it that way.

Also, the implicit contracts code currently has are typically pretty loose.
> What you need to "figure out" is very general. Explicit contracts are
> typically demonstrated as being relatively strict, and figuring out and
> writing such contracts is more work than writing code with loose implicit
> contracts. Whether the trade-off of defining tight explicit contracts once
> vs inferring a loose implicit contract every time you call the function is
> worth it, depends on how often the function is called. For most single use
> (or  infrequently used)  functions, I'd argue that the trade-off *isn't*
> worth it.


I don't believe such an approach would ever be pragmatical, *i.e. *automatic
versioning based on the contracts. It might hint it (as a warning: you
changed a contract, but did not bump the version), but relying solely on
this mechanism to get the versioning would imply that you specified *all *the
contracts. Though Bertrand might have always envisioned it as the best
state of the world, even he himself repeatedly said that it's better to
specify rather 10% than 0% contracts and 20% rather than 10% contracts.

Chris wrote:

> def fibber(n):
> return n if n < 2 else fibber(n-1) + fibber(n-2)


It depends who you are writing this function for -- for example, instead of
the contract, why not just include the code implementation as the
documentation? The only *meaningful* contract I could imagine:
@pre n >= 0

Everything else would be just repetition of the function. If you
implemented some optimized and complex fibber_optimized() function, then
your contracts would probably look like:
@pre n >= 0
@post (n < 2 ) or result == fibber_optimized(n-1) + fibber_optimized(n-2)
@post not (n < 2) or result == n

> Here is my try at the contracts. Assuming that there is a list of figures
> and that they have a property "displayed" and that "State.blocked" global
> variable refers to whether the interface is blocked or not::

Re: [Python-ideas] "old" values in postconditions

[James Lu]

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  
> 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  
>> wrote:
>> On Sun, Sep 23, 2018 at 2:05 AM Marko Ristin-Kaufmann
>>  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 

[Python-ideas] Add .= as a method return value assignment operator

[Jasper Rebane]

Hi,

When using Python, I find myself often using assignment operators, like 'a
+= 1' instead of 'a = a + 1', which saves me a lot of time and hassle

Unfortunately, this doesn't apply to methods, thus we have to write code
like this:
text = "foo"
text = text.replace("foo","bar")
# "bar"

I propose that we should add '.=' as a method return value assignment
operator so we could write the code like this instead:
text = "foo"
text .= replace("foo","bar")
# "bar"
This looks cleaner, saves time and makes debugging easier

Here are a few more examples:
text = " foo "
text .= strip()
# "foo"

text = "foo bar"
text .= split(" ")
# ['foo', 'bar']

text = b'foo'
text .= decode("UTF-8")
# "foo"

foo =  {1,2,3}
bar = {2,3,4}
foo .= difference(bar)
# {1}


Rebane
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Fwd: Keyword only argument on function call

[Anders Hovmöller]

> Oh, I see that you indeed implemented a macropy version at 
> https://github.com/boxed/macro-kwargs/blob/master/test.py 
> .
> Other than use() vs grab() as the function name, it's the same thing.

Well, except that it's import time, and that you do get the tooling on the 
existence of the local variables. You still don't get any check that the 
function has the parameters you're trying to match with your keyword arguments 
so it's a bit of a half measure. 

Steve had a fun idea of using the syntax foo=☃ where you could transform ☃ to 
the real name at import time. It's similar to the MacroPy solution but can be 
implemented with a super tiny import hook with an AST transformation, and you 
get the tooling part the MacroPy version is missing, but of course you lose the 
parts you get with MacroPy. So again it's a half measure.. just the other half.

> Is it true that the macro version has no performance cost?

In python 2 pretty much since it's compile time, in python 3 no because 
MacroPy3 has a bug in how pyc files are cached (they aren't). But even in the 
python 3 case the performance impact is at import time so not really 
significant.

> So it's now perfectly straightforward to provide both a function and a macro 
> for grab(), and users can play with that API, right? Without changing Python, 
> programmers can use this "shortcut keyword arguments corresponding to local 
> names."

Sort of. But for my purposes I don't really think it's a valid approach. I'm 
working on a 240kloc code base (real lines, not comments and blank lines). I 
don't think it's a good idea, and I wouldn't be able to sell it ot the team 
either, to introduce macropy to a significant enough chunk of the code base to 
make a difference. Plus the tooling problem mentioned above would make this 
worse than normal kwarg anyway from a robustness point of view.

I'm thinking that point 4 of my original list of ideas (PyCharm code folding) 
is the way to go. This would mean I could change huge chunks of code to the 
standard python keyword argument syntax and then still get the readability 
improvement in my editor without affecting anyone else. It has the downside 
that you don't to see this new syntax in other tools of course, but I think 
that's fine for trying out the syntax.

The biggest problem I see is that I feel rather scared about trying to 
implement this in PyCharm. I've tried to find the code for soft line breaks to 
implement a much nicer version of that, but I ended up giving up because I just 
couldn't find where this happened in the code! My experience with the PyCharm 
code base is basically "I'm amazed it works at all!".

If you know anyone who feels comfortable with the PyCharm code that could point 
me in the right direction I would of course be very greatful!

/ Anders___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Fwd: Keyword only argument on function call

[David Mertz]

Oh, I see that you indeed implemented a macropy version at
https://github.com/boxed/macro-kwargs/blob/master/test.py. Other than use()
vs grab() as the function name, it's the same thing.

Is it true that the macro version has no performance cost?

So it's now perfectly straightforward to provide both a function and a
macro for grab(), and users can play with that API, right? Without changing
Python, programmers can use this "shortcut keyword arguments corresponding
to local names."

On Wed, Sep 26, 2018, 5:31 AM David Mertz  wrote:

> On Wed, Sep 26, 2018, 5:12 AM Anders Hovmöller 
> wrote:
>
>> I saw now that I missed the biggest problem with your proposal: yet again
>>> you deliberately throw away errors. I'm talking about making Python code
>>> _less_ error prone, while you seem to want to make it _more_.
>>>
>>
>> Beyond the belligerent tone, is there an actual POINT here?
>>
>> Yes, there is a point: you keep insisting that I shut up about my ideas
>> and you motivate it by giving first totally broken code, then error prone
>> and slow code and then you are upset that I point out these facts. I think
>> it's a bit much when you complain about the tone after all that. Especially
>> after you wrote "If someone steps out of line of being polite and
>> professional, just ignore it" the 9th of September in this very thread.
>>
>
> That's fine. I'm not really as bothered by your belligerent tone as I'm
> trying to find the point underneath it.
>
> I guess... and I'm just guessing from your hints... that you don't like
> the "default to None" behavior of my *TOY* code. That's fine. It's a
> throwaway demonstration, not an API I'm attached to.
>
> You're new here. You may not understand that, in Python, we have a STRONG,
> preference for doing things with libraries before changing syntax. The
> argument that one can do something using existing, available techniques is
> prima facie weight against new syntax. Obviously there ARE times when
> syntax is added, so the fact isn't an absolute conclusion.
>
> But so far, your arguments have only seemed to amount to "I (Anders) like
> this syntax." The supposed performance win, the brevity, and the
> hypothetical future tooling, are just hand waving so far.
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Fwd: Keyword only argument on function call

[David Mertz]

On Wed, Sep 26, 2018, 5:12 AM Anders Hovmöller  wrote:

> I saw now that I missed the biggest problem with your proposal: yet again
>> you deliberately throw away errors. I'm talking about making Python code
>> _less_ error prone, while you seem to want to make it _more_.
>>
>
> Beyond the belligerent tone, is there an actual POINT here?
>
> Yes, there is a point: you keep insisting that I shut up about my ideas
> and you motivate it by giving first totally broken code, then error prone
> and slow code and then you are upset that I point out these facts. I think
> it's a bit much when you complain about the tone after all that. Especially
> after you wrote "If someone steps out of line of being polite and
> professional, just ignore it" the 9th of September in this very thread.
>

That's fine. I'm not really as bothered by your belligerent tone as I'm
trying to find the point underneath it.

I guess... and I'm just guessing from your hints... that you don't like the
"default to None" behavior of my *TOY* code. That's fine. It's a throwaway
demonstration, not an API I'm attached to.

You're new here. You may not understand that, in Python, we have a STRONG,
preference for doing things with libraries before changing syntax. The
argument that one can do something using existing, available techniques is
prima facie weight against new syntax. Obviously there ARE times when
syntax is added, so the fact isn't an absolute conclusion.

But so far, your arguments have only seemed to amount to "I (Anders) like
this syntax." The supposed performance win, the brevity, and the
hypothetical future tooling, are just hand waving so far.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Fwd: Keyword only argument on function call

[Anders Hovmöller]

> I saw now that I missed the biggest problem with your proposal: yet again you 
> deliberately throw away errors. I'm talking about making Python code _less_ 
> error prone, while you seem to want to make it _more_.
> 
> Beyond the belligerent tone, is there an actual POINT here? 

Yes, there is a point: you keep insisting that I shut up about my ideas and you 
motivate it by giving first totally broken code, then error prone and slow code 
and then you are upset that I point out these facts. I think it's a bit much 
when you complain about the tone after all that. Especially after you wrote "If 
someone steps out of line of being polite and professional, just ignore it" the 
9th of September in this very thread.

> It's the middle of the night and I'm on my tablet.

Maybe you could just reply later?

> I'm not sure what sort of error, or in what circumstance, my toy code "throws 
> away" errors. Actually saying so rather than playing a coy guessing game 
> would be helpful.

You explicitly wrote your code so that it tries to pass a local variable "d" 
that does not exist and the function does not take, and it doesn't crash on 
that. I guess you forgot? You've done it several times now and I've already 
pointed this out.

> So for CPython 3.6 it's 2.587355/0.003079 = 840x times slower
> and pypy: 1.177555/0.002565 =  460x slower
> 
> Yes, for functions whose entire body consists of `pass`, adding pretty much 
> any cost to unpacking the arguments will show down the operation a lot.

If you add sleep(0.001) it's still a factor 1.3! This is NOT a trivial 
overhead. 

> Changing the basic syntax of Python to optimize NOOPs really is a non-starter.

This is not a belligerent tone you think?

> In general, changing syntax at all to avoid something easily accomplished 
> with existing forms is—and should be—a very high barrier to cross.

Sure. I'm not arguing that it should be a low barrier, I'm arguing that it's 
worth it. And I'm trying to discuss alternatives.

> I haven't used macropy. I should play with it. I'm guessing it could be used 
> to create a zero-cost `use()` that had exactly the same API as my toy `use()` 
> function. If so, you could starting using and publishing a toy version today 
> and provide the optimized version as an alternative also.

Let me quote my mail from yesterday:

"3. I have made a sort-of implementation with MacroPy: 
https://github.com/boxed/macro-kwargs/blob/master/test.py I think this is a 
dead end, but it was easy to implement and fun to try!"


Let me also clarify another point: I wanted to open up the discussion to people 
who are interested in the general problem and just discuss some ideas. I am not 
at this point trying to get a PEP through. If that was my agenda, I would have 
already submitted the PEP. I have not.

/ Anders___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Why is design-by-contracts not widely adopted?

[Paul Moore]

On Wed, 26 Sep 2018 at 09:45, Chris Angelico  wrote:
>
> On Wed, Sep 26, 2018 at 6:36 PM Paul Moore  wrote:
> >
> > On Wed, 26 Sep 2018 at 06:41, Chris Angelico  wrote:
> > >
> > > On Wed, Sep 26, 2018 at 2:47 PM Marko Ristin-Kaufmann
> > >  wrote:
> > > > * The contracts written in documentation as human text inevitably rot 
> > > > and they are much harder to maintain than automatically verified formal 
> > > > contracts.
> > >
> > > Agreed.
> >
> > Agreed, if contracts are automatically verified. But when runtime cost
> > comes up, people suggest that contracts can be disabled in production
> > code - which invalidates the "automatically verified" premise.
>
> Even if they're only verified as a dedicated testing pass ("okay,
> let's run the unit tests, let's run the contract verifier, let's run
> the type checker, cool, we're good"), they're still better off than
> unchecked comments/documentation in terms of code rot.

Absolutely. But if the contracts are checked at runtime, they are
precisely as good as tests - they will flag violations *in any
circumstances you check*. That's great, but nothing new. I understood
that one of the benefits of contracts was that it would handle cases
that you *forgot* to test - like assertions do, in essence - and would
need to be active in production (again, like assertions, if we assume
we've not explicitly chosen to run with assertions disabled) to get
that benefit.

There's certainly benefits for the "contracts as additional tests"
viewpoint. But whenever that's proposed as what people understand by
DbC, the response is "no, it's not like that at all". So going back to
the "why isn't DbC more popular" question - because no-one can get a
clear handle on whether they are "like tests" or "like assertions" or
"something else" :-)

Paul
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Why is design-by-contracts not widely adopted?

[Chris Angelico]

On Wed, Sep 26, 2018 at 6:37 PM Chris Angelico  wrote:
>
> On Wed, Sep 26, 2018 at 5:51 PM Marko Ristin-Kaufmann
>  wrote:
> >
> > Hi Chris,
> >
> >> It's easy to say that they're boolean expressions. But that's like
> >> saying that unit tests are just a bunch of boolean expressions too.
> >> Why do we have lots of different forms of test, rather than just a big
> >> fat "assert this and this and this and this and this and this"?
> >> Because the key to unit testing is not "boolean expressions", it's a
> >> language that can usefully describe what it is we're testing.
> >> Contracts aren't just boolean expressions - they're a language (or a
> >> mini-language) that lets you define WHAT the contract entails.
> >
> >
> > Sorry, I misunderstood you. You are probably referring to knowing the terms 
> > like "preconditions, postconditions, invariants, strengthening/weakening", 
> > right? In that case, yes, I agree, I presuppose that readers are familiar 
> > with the concepts of DbC. Otherwise, of course, it makes no sense to use 
> > DbC if you assume nobody could actually figure out what it is :).
> >
>
> Let's say you want to define a precondition and postcondition for this 
> function:
>
> def fibber(n):
> return n < 2 ? n : fibber(n-1) + fibber(n-2)

U

def fibber(n):
return n if n < 2 else fibber(n-1) + fibber(n-2)

Let's, uhh, pretend that I didn't just mix languages there.

For the original, we can say:

@post(raises=ProgrammerFailedSanCheckError)

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/

Re: [Python-ideas] Why is design-by-contracts not widely adopted?

[Chris Angelico]

On Wed, Sep 26, 2018 at 6:36 PM Paul Moore  wrote:
>
> On Wed, 26 Sep 2018 at 06:41, Chris Angelico  wrote:
> >
> > On Wed, Sep 26, 2018 at 2:47 PM Marko Ristin-Kaufmann
> >  wrote:
> > > * The contracts written in documentation as human text inevitably rot and 
> > > they are much harder to maintain than automatically verified formal 
> > > contracts.
> >
> > Agreed.
>
> Agreed, if contracts are automatically verified. But when runtime cost
> comes up, people suggest that contracts can be disabled in production
> code - which invalidates the "automatically verified" premise.

Even if they're only verified as a dedicated testing pass ("okay,
let's run the unit tests, let's run the contract verifier, let's run
the type checker, cool, we're good"), they're still better off than
unchecked comments/documentation in terms of code rot. That said,
though: the contract for a function and the documentation for the
function are inextricably linked *already*, and if you let your API
docs rot when you make changes that callers need to be aware of, you
have failed your callers. Wholesale use of contracts would not remove
the need for good documentation; what it might allow is easier version
compatibility testing. It gives you a somewhat automated (or at least
automatable) tool for checking if two similar libraries (eg version
X.Y and version X.Y-1) are compatible with your code. That would be of
some value, if it could be trusted; you could quickly run your code
through a checker and say "hey, tell me what the oldest version of
Python is that will run this", and get back a response without
actually running a gigantic test suite - since it could check based on
the *diffs* in the contracts rather than the contracts themselves. But
that would require a lot of support, all up and down the stack.

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/

Re: [Python-ideas] Why is design-by-contracts not widely adopted?

[Chris Angelico]

On Wed, Sep 26, 2018 at 5:51 PM Marko Ristin-Kaufmann
 wrote:
>
> Hi Chris,
>
>> It's easy to say that they're boolean expressions. But that's like
>> saying that unit tests are just a bunch of boolean expressions too.
>> Why do we have lots of different forms of test, rather than just a big
>> fat "assert this and this and this and this and this and this"?
>> Because the key to unit testing is not "boolean expressions", it's a
>> language that can usefully describe what it is we're testing.
>> Contracts aren't just boolean expressions - they're a language (or a
>> mini-language) that lets you define WHAT the contract entails.
>
>
> Sorry, I misunderstood you. You are probably referring to knowing the terms 
> like "preconditions, postconditions, invariants, strengthening/weakening", 
> right? In that case, yes, I agree, I presuppose that readers are familiar 
> with the concepts of DbC. Otherwise, of course, it makes no sense to use DbC 
> if you assume nobody could actually figure out what it is :).
>

Let's say you want to define a precondition and postcondition for this function:

def fibber(n):
return n < 2 ? n : fibber(n-1) + fibber(n-2)

What would you specify? Can you say, as a postcondition, that the
return value must be a Fibonacci number? Can you say that, for any 'n'
greater than about 30, the CPU temperature will have risen? How do you
describe those as boolean expressions? The art of the contract depends
on being able to adequately define the conditions.

>
> However, contracts can be useful when testing the GUI -- often it is 
> difficult to script the user behavior. What many people do is record a 
> session and re-play it. If there is a bug, fix it. Then re-record. While 
> writing unit tests for GUI is hard since GUI changes rapidly during 
> development and scripting formally the user behavior is tedious, DbC might be 
> an alternative where you specify as much as you can, and then just re-run 
> through the session. This implies, of course, a human tester.
>

That doesn't sound like the function's contract. That sounds like a
test case - of which you would have multiple, using different
"scripted session" inputs and different outputs (some of success, some
of expected failure).

> Here is my try at the contracts. Assuming that there is a list of figures and 
> that they have a property "displayed" and that "State.blocked" global 
> variable refers to whether the interface is blocked or not::
> @post(lambda: all(figure.displayed for figure in figures)
> @post(lambda: not ipython.in_pylab_mode() or not State.blocked)
> @post(lambda: not interactive() or State.blocked)
> matplotlib.pyplot.show()
>

There is no such thing as "State.blocked". It blocks. The function
*does not return* until the figure has been displayed, and dismissed.
There's no way to recognize that inside the function's state.

Contracts are great when every function is 100% deterministic and can
maintain invariants and/or transform from one set of invariants to
another. Contracts are far less clear when the definitions are
muddier.

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/

Re: [Python-ideas] Why is design-by-contracts not widely adopted?

[Paul Moore]

On Wed, 26 Sep 2018 at 06:41, Chris Angelico  wrote:
>
> On Wed, Sep 26, 2018 at 2:47 PM Marko Ristin-Kaufmann
>  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.

Also, the implicit contracts code currently has are typically pretty
loose. What you need to "figure out" is very general. Explicit
contracts are typically demonstrated as being relatively strict, and
figuring out and writing such contracts is more work than writing code
with loose implicit contracts. Whether the trade-off of defining tight
explicit contracts once vs inferring a loose implicit contract every
time you call the function is worth it, depends on how often the
function is called. For most single use (or infrequently used)
functions, I'd argue that the trade-off *isn't* worth it.

Here's a quick example from the pip codebase:

# Retry every half second for up to 3 seconds
@retry(stop_max_delay=3000, wait_fixed=500)
def rmtree(dir, ignore_errors=False):
shutil.rmtree(dir, ignore_errors=ignore_errors,
  onerror=rmtree_errorhandler)

What contract would you put on this code? The things I can think of:

1. dir is a directory: obvious from the name, not worth the runtime
cost of checking as shutil.rmtree will do that and we don't want to
duplicate work.
2. dir is a string: covered by type declarations, if we used them. No
need for contracts
3. ignore_errors is a boolean: covered by type declarations.
4. dir should exist: Checked by shutil.rmtree, don't want to duplicate work.
5. After completion, dir won't exist. Obvious unless we have doubts
about what shutil.rmtree does (but that would have a contract too).
Also, we don't want the runtime overhead (again).

In addition, adding those contracts to the code would expand it
significantly, making readability suffer (as it is, rmtree is clearly
a thin wrapper around shutil.rmtree).

> > * Figuring out contracts by trial-and-error and reading the code (the 
> > implementation or the test code) is time consuming and hard.
>
> Agreed.

With provisos. Figuring out contracts in sufficient detail to use the
code is *in many cases* simple. For harder cases, agreed. But that's
why this is simply a proof that contracts *can* be useful, not that
100% of code would benefit from them.

> > * 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.

Agreed, if contracts are automatically verified. But when runtime cost
comes up, people suggest that contracts can be disabled in production
code - which invalidates the "automatically verified" premise.

> > * 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.

Depends on what "formal statement" means. If it means "short snippet
of Python code", then yes, the reader will be familiar. But there's
only so much you can do in a short snippet of Python, without calling
out to other functions (which may or may not be "obvious" in their
behavour) so whether it's easier to read a contract is somewhat in
conflict with wanting strong contracts.

> 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 

Re: [Python-ideas] Fwd: Keyword only argument on function call

[David Mertz]

On Wed, Sep 26, 2018, 3:19 AM Anders Hovmöller  wrote:

> I saw now that I missed the biggest problem with your proposal: yet again
> you deliberately throw away errors. I'm talking about making Python code
> _less_ error prone, while you seem to want to make it _more_.
>

Beyond the belligerent tone, is there an actual POINT here?

It's the middle of the night and I'm on my tablet. I'm not sure what sort
of error, or in what circumstance, my toy code "throws away" errors.
Actually saying so rather than playing a coy guessing game would be helpful.

>
So for CPython 3.6 it's 2.587355/0.003079 = 840x times slower
> and pypy: 1.177555/0.002565 =  460x slower
>

Yes, for functions whose entire body consists of `pass`, adding pretty much
any cost to unpacking the arguments will show down the operation a lot.

I'm actually sightly surprised the win is not bigger in Pypy than in
CPython. I'd kinda expect them to optimize away the entire call when a
function call is a NOOP.

Anyway, this is 100% consistent with what I said. For functions with actual
bodies, the lookup is negligible. It could be made a lot faster, I'm sure,
if you wrote `use()` in C. Probably even just by optimizing the Python
version (`reach()` doesn't need to be a separate call, for example, it's
just better to illustrate that way).

Changing the basic syntax of Python to optimize NOOPs really is a
non-starter. In general, changing syntax at all to avoid something easily
accomplished with existing forms is—and should be—a very high barrier to
cross.

I haven't used macropy. I should play with it. I'm guessing it could be
used to create a zero-cost `use()` that had exactly the same API as my toy
`use()` function. If so, you could starting using and publishing a toy
version today and provide the optimized version as an alternative also.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Why is design-by-contracts not widely adopted?

[Marko Ristin-Kaufmann]

Hi Chris,

It's easy to say that they're boolean expressions. But that's like
> saying that unit tests are just a bunch of boolean expressions too.
> Why do we have lots of different forms of test, rather than just a big
> fat "assert this and this and this and this and this and this"?
> Because the key to unit testing is not "boolean expressions", it's a
> language that can usefully describe what it is we're testing.
> Contracts aren't just boolean expressions - they're a language (or a
> mini-language) that lets you define WHAT the contract entails.
>

Sorry, I misunderstood you. You are probably referring to knowing the terms
like "preconditions, postconditions, invariants, strengthening/weakening",
right? In that case, yes, I agree, I presuppose that readers are familiar
with the concepts of DbC. Otherwise, of course, it makes no sense to use
DbC if you assume nobody could actually figure out what it is :).

But that's not the objection that is made too often -- what I really read
often is that DbC is not beneficial not because people are not familiar
with or can learn DbC, but really because reading boolean expressions is
hard. That is what I was referring to in my original message.

> Thanks for this clarification (and the download-yt example)! I actually
> only had packages-as-libraries in mind, not the executable scripts; my
> mistake. So, yes, "any Pypi package" should be reformulated to "any library
> on Pypi" (meant to be used by a wider audience than the developers
> themselves).
> >
>
> Okay. Even with that qualification, though, I still think that not
> every library will benefit from this. For example, matplotlib's
> plt.show() method guarantees that... a plot will be shown, and the
> user will have dismissed it, before it returns. Unless you're inside
> Jupyter/iPython, in which case it's different. Or if you're in certain
> other environments, in which case it's different again. How do you
> define the contract for something that is fundamentally interactive?
>
> You can define very weak contracts. For instance, input() guarantees
> that its return value is a string. Great! DbC doing the job of type
> annotations. Can you guarantee anything else about that string? Is
> there anything else useful that can be spelled easily?
>

In this case, no, I would not add any formal contracts to the function. Not
all contracts can be formulated, and not all contracts are even meaningful.
I suppose interactive functions are indeed a case that it is not possible.
If any string can be returned, than the contract is empty.

However, contracts can be useful when testing the GUI -- often it is
difficult to script the user behavior. What many people do is record a
session and re-play it. If there is a bug, fix it. Then re-record. While
writing unit tests for GUI is hard since GUI changes rapidly during
development and scripting formally the user behavior is tedious, DbC might
be an alternative where you specify as much as you can, and then just
re-run through the session. This implies, of course, a human tester.

Let me take a look at matplotlib show:
matplotlib.pyplot.show(**args*, ***kw*)[source]


Display a figure. When running in ipython with its pylab mode, display all
figures and return to the ipython prompt.

In non-interactive mode, display all figures and block until the figures
have been closed; in interactive mode it has no effect unless figures were
created prior to a change from non-interactive to interactive mode (not
recommended). In that case it displays the figures but does not block.

A single experimental keyword argument, *block*, may be set to True or
False to override the blocking behavior described above.
Here are the contracts as a toy example; (I'm not familiar at all with the
internals of matplotlib. I haven't spent much time really parsing and
analyzing the docstring -- as I'll write below, it also confuses me since
the docstring is not precise enough.)

* If in ipython with its pylab mode, all figures should be displayed.
* If in non-interactive mode, display all figures and block

I'm actually confused with what they mean with:

> In non-interactive mode, display all figures and block until the figures
> have been closed; in interactive mode *it has no effect* *unless figures
> were created prior to a change from non-interactive to interactive mode*
> (not recommended). In that case it displays the figures but does not block.
>
> A single experimental keyword argument, *block*, may be set to True or
> False to override the blocking behavior described above.
>
If only they spelled that out as a contract :)

"it has no effect": What does not have effect? The call to the function? Or
the setting of some parameter? Or the order of the calls?

"unless ...to interactive mode": this would be actually really more
readable as a formal contract. It would imply some refactoring to add a
property when a figure was created (before 

Re: [Python-ideas] "while:" for the loop

[Brice Parent]

Le 26/09/2018 à 05:36, Chris Angelico a écrit :

On Wed, Sep 26, 2018 at 1:29 PM Mikhail V  wrote:

On Wed, Sep 26, 2018 at 5:38 AM Chris Angelico  wrote:


I like saying while "something": where the string describes the loop's
real condition. For instance, while "moar data": if reading from a
socket, or while "not KeyboardInterrupt": if the loop is meant to be
halted by SIGINT.

ChrisA

if doing so, would not it be more practical
to write is as an in-line comment then?
with new syntax it could be like this:
"""
while:  # not KeyboardInterrupt
 asd asd asd
 asd asd asd
 asd asd asd
"""
Similar effect, but I would find it better at least because it would
be highlighted as a comment and not as a string, + no quotes noise.

A comment is not better than an inline condition, no. I *want* it to
be highlighted as part of the code, not as a comment. Because it isn't
a comment - it's a loop condition.
For what it's worth, I'm not a fan of either solutions. In both cases 
(string or comment), KeyboardInterrupt seems to be the only way to get 
out of the loop, which which even if it were the case, it would breaks 
the DRY idea, because if you add in the future a reason to break out of 
the loop, you'd have to write the condition+break and update the 
comment/string to still be consistent.


I don't think `while True:` is not explicit. If you think about it, True 
will always evaluate positively (right??), so it can't be the hardest 
part of learning Python.
But in some cases, mostly when I work on tiny microptyhon projects that 
I share with non-python experts, where I avoid complicated code 
fragments like comprehensions, I usually use `while "forever":` or 
`while FOREVER:` (where forever was set to True before). In these case, 
I don't need them to understand exactly why the loop is indeed infinite, 
I just want them to know it is. But all these solutions are available 
right now, without any syntax change.


About the original proposal, even though I'm not a native English 
speaker, writing `while:` seems like an wobbling sentence, we are 
waiting for it to be completed. My mind says "while what?" and tries to 
find out if it's infinite or if it has to find the condition elsewhere 
in the code (like some kind of do...until or do...while loop).


-Brice
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Fwd: Keyword only argument on function call

[Anders Hovmöller]

David,

I saw now that I missed the biggest problem with your proposal: yet again you 
deliberately throw away errors. I'm talking about making Python code _less_ 
error prone, while you seem to want to make it _more_. Anyway, I'll modify your 
reach() to not have the if in it that has this error hiding property, it also 
simplifies it a lot. It should look  like this:

def reach(name):
return inspect.stack()[-2][0].f_locals[name]


> 1. Huge performance penalty
> 
> Huh? Have you actually benchmarked this is some way?!  A couple lookups into 
> the namespace are really not pricey operations.  The cost is definitely more 
> than zero, but for any function that does anything even slightly costly, the 
> lookups would be barely in the noise.

I'm talking about using this for all or most function calls that aren't 
positional only. So no, you can absolutely not assume I only use it to call 
expensive functions. And yea, I did benchmark it, and since you didn't define 
what you would think is acceptable for a benchmark you've left the door open 
for me to define it. This is the result of a benchmark for 10k calls (full 
source at the very end of this email):

CPython 3.6

time with use: 0:00:02.587355
time with standard kwargs: 0:00:00.003079
time with positional args: 0:00:00.003023

pypy 6.0

time with use: 0:00:01.177555
time with standard kwargs: 0:00:00.002565
time with positional args: 0:00:00.001953

So for CPython 3.6 it's 2.587355/0.003079 = 840x times slower
and pypy: 1.177555/0.002565 =  460x slower

I'm quite frankly a bit amazed pypy is so good. I was under the impression it 
would be much worse there. They've clearly improved the speed of the stack 
inspection since I last checked.

>  
> 2. Rather verbose, so somewhat fails on the stated goal of improving 
> readability
> 
> The "verbose" idea I propose is 3-4 characters more, per function call, than 
> your `fun(a, b, *, this, that)` proposal.  It will actually be shorter than 
> your newer `fun(a, b, =this, =that)` proposal once you use 4 or more keyword 
> arguments.

True enough. 

> 3. Tooling* falls down very hard on this
> 
> It's true that tooling doesn't currently support my hypothetical function.  
> It also does not support your hypothetical syntax. 

If it was included in Python it would of course be added super fast, while the 
use() function would not. This argument is just bogus.

> It would be *somewhat easier* to add special support for a function with a 
> special name like `use()` than for new syntax.  But obviously that varies by 
> which tool and what purpose it is accomplishing.

Easier how? Technically? Maybe. Politically? Absolutely not. If it's in Python 
then all tools _must_ follow. This solved the political problem of getting tool 
support and that is the only hard one. The technical problem is a rounding 
error in this situation.

> Of course, PyCharm and MyPy and PyLint aren't going to bother special casing 
> a `use()` function unless or until it is widely used and/or part of the 
> builtins or standard library.  I don't actually advocate for such inclusion, 
> but I wouldn't be stridently against that since it's just another function 
> name, nothing really special.


Ah, yea, I see here you're granting my point above. Good to see we can agree on 
this at least.

/ Anders


Benchmark code:
---

import inspect
from datetime import datetime


def reach(name):
return inspect.stack()[-2][0].f_locals[name]

def use(names):
kws = {}
for name in names.split():
kws[name] = reach(name)
return kws

def function(a=11, b=22, c=33, d=44):
pass

def foo():
a, b, c = 1, 2, 3
function(a=77, **use('b'))

c = 1

start = datetime.now()
for _ in range(c):
foo()
print('time with use: %s' % (datetime.now() - start))


def bar():
a, b, c = 1, 2, 3
function(a=77, b=b)


start = datetime.now()
for _ in range(c):
bar()
print('time with standard kwargs: %s' % (datetime.now() - start))


def baz():
a, b, c = 1, 2, 3
function(77, b)


start = datetime.now()
for _ in range(c):
baz()
print('time with positional args: %s' % (datetime.now() - start))

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Why is design-by-contracts not widely adopted?

[Chris Angelico]

On Wed, Sep 26, 2018 at 5:10 PM Marko Ristin-Kaufmann
 wrote:
> The original objection was that DbC in general is not beneficial; not that 
> there are lacking tools for it (this probably got lost in the many messages 
> on this thread). If you assume that there are no suitable tools for DbC, then 
> yes, DbC is certainly not beneficial to any project since using it will be 
> clumsy and difficult. It's a chicken-and-egg problem, so we need to assume 
> that there are good tools for DbC in order for it to be beneficial.
>
>> Disagreed. I would most certainly NOT assume that every reader knows
>> any particular syntax for such contracts. However, this is a weaker
>> point.
>
>
> The contracts are written as boolean expressions. While I agree that many 
> programmers have a hard time with boolean expressions and quantifiers, I 
> don't see this as a blocker to DbC. There is no other special syntax for DbC 
> unless we decide to add it to the core language (which I don't see as 
> probable). What I would like to have is a standard library so that 
> inter-library interactions based on contracts are possible and an ecosystem 
> could emerge around it.
>

It's easy to say that they're boolean expressions. But that's like
saying that unit tests are just a bunch of boolean expressions too.
Why do we have lots of different forms of test, rather than just a big
fat "assert this and this and this and this and this and this"?
Because the key to unit testing is not "boolean expressions", it's a
language that can usefully describe what it is we're testing.
Contracts aren't just boolean expressions - they're a language (or a
mini-language) that lets you define WHAT the contract entails.

>> 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.
>
>
> Thanks for this clarification (and the download-yt example)! I actually only 
> had packages-as-libraries in mind, not the executable scripts; my mistake. 
> So, yes, "any Pypi package" should be reformulated to "any library on Pypi" 
> (meant to be used by a wider audience than the developers themselves).
>

Okay. Even with that qualification, though, I still think that not
every library will benefit from this. For example, matplotlib's
plt.show() method guarantees that... a plot will be shown, and the
user will have dismissed it, before it returns. Unless you're inside
Jupyter/iPython, in which case it's different. Or if you're in certain
other environments, in which case it's different again. How do you
define the contract for something that is fundamentally interactive?

You can define very weak contracts. For instance, input() guarantees
that its return value is a string. Great! DbC doing the job of type
annotations. Can you guarantee anything else about that string? Is
there anything else useful that can be spelled easily?

> I totally agree. The discussion related to DbC in my mind always revolved 
> around these use cases where type annotations are beneficial as well. Thanks 
> for pointing that out and I'd like to apologize for the confusion! For the 
> future discussion, let's focus on these use cases and please do ignore the 
> rest. I'd still say that there is a plethora of libraries published on Pypi 
> (Is there a way to find out the stats?).
>

Ugh I would love to say "yes", but I can't. I guess maybe you
could look at a bunch of requirements.txt files and see which things
get dragged in that way? All you'll really get is heuristics at best,
and even that, I don't know how to provide. Sorry.

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/

Re: [Python-ideas] Why is design-by-contracts not widely adopted?

[Marko Ristin-Kaufmann]

Hi Chris,

> * 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.
>

Well, you need to know what to supply to a function and what to expect, at
least subconsciously. The question is just whether you can formulate these
contracts or not; and whether you do or not.

> * 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 original objection was that DbC in general is not beneficial; not that
there are lacking tools for it (this probably got lost in the many messages
on this thread). If you assume that there are no suitable tools for DbC,
then yes, DbC is certainly *not *beneficial to any project since using it
will be clumsy and difficult. It's a chicken-and-egg problem, so we need to
assume that there are good tools for DbC in order for it to be beneficial.

Disagreed. I would most certainly NOT assume that every reader knows
> any particular syntax for such contracts. However, this is a weaker
> point.


The contracts are written as boolean expressions. While I agree that many
programmers have a hard time with boolean expressions and quantifiers, I
don't see this as a blocker to DbC. There is no other special syntax for
DbC unless we decide to add it to the core language (which I don't see as
probable). What I would like to have is a standard library so that
inter-library interactions based on contracts are possible and an ecosystem
could emerge around it.

Quite some people object that DbC should be rejected as their "average
programmer Joe/Jane" can't deal with the formal expressions. Some readers
have problems parsing "all(i > 0 for i in result) or len(result) < 3" and
can only parse "All numbers in the result are positive and/or the result
has fewer than 3 items". There are also programmers who have a hard time
reading "all(key == value.some_property for key, value in result.items())"
and could only read "The resulting values in the dictionary are keyed by
their some_property attribute.".

I hope that education in computer science is improving and that soon
programmers will be able to read these formal expressions. I'm also not
sure if that is the case for non-English speakers. Hence I assumed that the
readers of the contracts are familiar with formal boolean expressions. If
you assume that readers have hard time parsing quantifiers and boolean
logic then DbC is again certainly not beneficial.

It would make me sad if a feature is rejected on grounds that we have to
accept that many programmers don't master the basics of computer science
(which I consider the boolean expressions to be).

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.
>

Thanks for this clarification (and the download-yt example)! I actually
only had packages-as-libraries in mind, not the executable scripts; my
mistake. So, yes, "any Pypi package" should be reformulated to "any library
on Pypi" (meant to be used by a wider audience than the developers
themselves).

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.


I totally agree. The discussion related to DbC in my mind always revolved
around these use cases where type annotations are beneficial as well.
Thanks for pointing that out and I'd like to apologize for the confusion!
For the future discussion, let's focus on these use cases and please do
ignore the rest. I'd still say that there is a plethora of libraries
published on Pypi (Is there a way to find out the stats?).

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.
>

Please see my previous message -- could you maybe say what would convince
you that enough projects would actually benefit from formal contracts?

Cheers,
Marko

On Wed, 26 Sep 2018 at 07:40, Chris Angelico  wrote:

> On Wed, Sep 26, 2018 at 2:47 PM Marko Ristin-Kaufmann
>  wrote:
> >
> > Hi Chris,
> >
> >> An extraordinary claim is like "DbC can improve *every single project*
> >> on PyPI". 

Re: [Python-ideas] Why is design-by-contracts not widely adopted?

[Robert Collins]

On Wed, 26 Sep 2018 at 05:19, Marko Ristin-Kaufmann
 wrote:
>
> Hi Robert,
...
>> Claiming that DbC annotations will improve the documentation of every
>> single library on PyPI is an extraordinary claim, and such claims
>> require extraordinary proof.
>
>
> I don't know what you mean by "extraordinary" claim and "extraordinary" 
> proof, respectively.

Chris already addressed this.

> I tried to show that DbC is a great tool and far superior to any other tools 
> currently used to document contracts in a library, please see my message 
> https://groups.google.com/d/msg/python-ideas/dmXz_7LH4GI/5A9jbpQ8CAAJ. Let me 
> re-use the enumeration I used in the message and give you a short summary.

> When you are documenting a method you have the following options:
> 1) Write preconditions and postconditions formally and include them 
> automatically in the documentation (e.g., by using icontract library).
> 2) Write precondtions and postconditions in docstring of the method as human 
> text.
> 3) Write doctests in the docstring of the method.
> 4) Expect the user to read the actual implementation.
> 5) Expect the user to read the testing code.

So you can also:

0) Write clear documentation

e.g. just document the method without doctests. You can write doctests
in example documentation, or even in unit tests if desired: having use
cases be tested is often valuable.


> The implicit or explicit contracts are there willy-nilly. When you use a 
> module, either you need to figure them out using trial-and-error or looking 
> at the implementation (4), looking at the test cases and hoping that they 
> generalize (5), write them as doctests (3) or write them in docstrings as 
> human text (2); or you write them formally as explicit contracts (1).
>
> I could not identify any other methods that can help you with expectations 
> when you call a function or use a class (apart from formal methods and 
> proofs, which I omitted as they seem too esoteric for the current discussion).
>
> Given that:
> * There is no other method for representing contracts,
> * people are trained and can read formal statements and
> * there is tooling available to write, maintain and represent contracts in a 
> nice way
>
> I see formal contracts (1) as a superior tool. The deficiencies of other 
> approaches are:
> 2) Comments and docstrings inevitably rot and get disconnected from the 
> implementation in my and many other people's experience and studies.
> 3) Doctests are much longer and hence more tedious to read and maintain, they 
> need extra text to signal the intent (is it a simple test or an example how 
> boundary conditions are handled or ...). In any non-trivial case, they need 
> to include even the contract itself.
> 4) Looking at other people's code to figure out the contracts is tedious and 
> usually difficult for any non-trivial function.
> 5) Test cases can be difficult to read since they include much broader 
> testing logic (mocking, set up). Most libraries do not ship with the test 
> code. Identifying test cases which demonstrate the contracts can be difficult.

I would say that contracts *are* a formal method. They are machine
interpretable rules about when the function may be called and about
what it may do and how it must leave things.
https://en.wikipedia.org/wiki/Formal_methods

The critique I offer of DbC in a Python context is the same as for
other formal methods: is the benefit worth the overhead. If you're
writing a rocket controller, Python might not be the best language for
it.

> Any function that is used by multiple developers which operates on the 
> restricted range of input values and gives out structured output values 
> benefits from contracts (1) since the user of the function needs to figure 
> them out to properly call the function and handle its results correctly. I 
> assume that every package on pypi is published to be used by wider audience, 
> and not the developer herself. Hence every package on pypi would benefit from 
> formal contracts.

In theory there is no difference between theory and practice, but in
practice there may be differences between practice and theory :).

Less opaquely, you're using a model to try and extrapolate human
behaviour. This is not an easy thing to do, and you are very likely to
be missing factors. For instance, perhaps training affects perceived
benefits. Perhaps a lack of experimental data affects uptake in more
data driven groups. Perhaps increased friction in changing systems is
felt to be a negative.

And crucially, perhaps some of these things are true. As previously
mentioned, Python has wonderful libraries; does it have more per
developer than languages with DbC built in? If so then that might
speak to developer productivity without these formal contracts: it may
be that where the risks of failure are below the threshold that formal
methods are needed, that we're better off with the tradeoff Python
makes today.

> Some predicates are hard to formulate,