Hi Steve and others,
After some thinking, I'm coming to a conclusion that it might be wrong to
focus too much about how the contracts are written -- as long as they are
formal, easily transformable to another representation and fairly
maintainable.
Whether it's with a lambda, without, with "args"
Hi Mario,
yes I'd pass in some kind of 'old' object as a proxy to the old object
state.
My demo can handle function calls, unless they themselves ultimately call
something which can't be proxies e.g is instance (which delegates to the
test class, not the instance), or boolean evaluation of some ex
On Mon, 24 Sep 2018 at 19:47, Marko Ristin-Kaufmann
wrote:
>
> Hi,
>
> Thank you for your replies, Hugh and David! Please let me address the points
> in serial.
>
> Obvious benefits
> You both seem to misconceive the contracts. The goal of the
> design-by-contract is not reduced to testing the c
Marko Ristin-Kaufmann writes:
> Thanks a lot for pointing us to macropy -- I was not aware of the library,
> it looks very interesting!
>
> Do you have any experience how macropy fit
Sorry, no. I was speaking as someone who is familiar with macros from
Lisp but doesn't miss them in Python,
Angus Hollands writes:
> yes I'd pass in some kind of 'old' object as a proxy to the old object
> state.
Mostly you shouldn't need to do this, you can copy the state:
def method(self, args):
import copy
old = copy.deepcopy(self)
This is easy but verbose to do with a decora
Hi,
I'd like to reopen this discussion if anyone is interested. Some things
have changed since I wrote my original proposal so I'll first summarize:
1. People seem to prefer the syntax `foo(=a)` over the syntax I suggested.
I believe this is even more trivial to implement in CPython than my
or
Have you looked at the built-in AST module, ast?
https://docs.python.org/3/library/ast.html
I don’t see anything preventing you from walking the AST Python itself can give
you- you’d look for two Set AST nodes if we were to do {{ }}.
There’s also the parser built-in module. You can use it if yo
> Date: Mon, 24 Sep 2018 09:46:16 +0200
> From: Marko Ristin-Kaufmann
> To: Python-Ideas
> Subject: Re: [Python-ideas] Why is design-by-contracts not widely
> adopted?
> Message-ID:
>
> Content-Type: text/plain; charset="utf-8"
[munch]
> Their users would hugely benefit from a
I'm still not sure why all this focus on new syntax or convoluted IDE
enhancements. I presented a very simple utility function that accomplishes
exactly the started goal of DRY in keyword arguments.
Yes, I wrote a first version that was incomplete. And perhaps these 8-9
lines miss some corner case
> Date: Mon, 24 Sep 2018 09:46:16 +0200
> From: Marko Ristin-Kaufmann
> To: Python-Ideas
> Subject: Re: [Python-ideas] Why is design-by-contracts not widely
> adopted?
[munch]
> Python is easier to write and read, and there are no libraries which are
> close in quality in Eiffel space (
> I'm still not sure why all this focus on new syntax or convoluted IDE
> enhancements. I presented a very simple utility function that accomplishes
> exactly the started goal of DRY in keyword arguments.
And I’ve already stated my reasons for rejecting this specific solution, but
I’ll repeat
On 25/09/18 12:59, Hugh Fisher wrote:
Thank you for a very well thought out post, Hugh. I completely agree.
I just wanted to pull out one comment:
Adding new syntax or semantics to a programming language very often adds
accidental complexity.
This is, in my view, the main reason why the ba
On Tue, Sep 25, 2018 at 8:32 AM Anders Hovmöller
wrote:
> > I'm still not sure why all this focus on new syntax or convoluted IDE
> enhancements. I presented a very simple utility function that accomplishes
> exactly the started goal of DRY in keyword arguments.
>
> And I’ve already stated my rea
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 f
Hmm, I was wrong: there is no reliable way to get the code of a lambda
function.
If it was possible to execute all code paths of the function, we could monkey
patch the builtins so { } used our own custom set class.
Alternatively, the decorator could also accept a string.
Or maybe we could s
Those arguments are rules of thumb, which may or may not apply to DbC,
and speculation, based on why DbC isn't more popular, to explain why
DbC isn't more popular. They are general arguments for features in
general, whereas Marko has been giving arguments for why DbC in
particular is good or why it
Hi Robert,
You'll lose folks attention very quickly when you try to tell folk
> what they do and don't understand.
I apologize if I sounded offending, that was definitely not my intention. I
appreciate that you addressed that.
I suppose it's cultural/language issue and the wording was probably
Hi Steve,
I'll give it a shot and implement a proof-of-concept icontrac-macro library
based on macropy and see if that works. I'll keep you posted.
Cheers,
Marko
On Tue, 25 Sep 2018 at 12:08, Stephen J. Turnbull <
[email protected]> wrote:
> Marko Ristin-Kaufmann writes:
>
>
Ew, magic. `{{foo}}` is already valid syntax (though it will always
fail). I don't like this path. If the proposal requires new syntax or
magic, it will be less likely to get accepted or even pip'd. Remember
also that PyPy, IronPython, and Jython are still alive, and the latter
two are still aiming
> I'm surprised you haven't found
>inspect.getsource(func)
I did. That’s exactly what I was describing in the paragraph. It wouldn’t work
in interactive mode and it includes everything on the same line of the lambda
definition.
___
Python-ideas mai
Hi Hugh,
Software projects, in any language, never have enough time to do everything.
> By your own example, the Python developers of numpy, OpenCV, nlk, and
> sklearn; *who most certainly weren't writing contracts;* produced better
> quality
> software than the Eiffel equivalent developers who (I
Hi James and Franklin,
getsource() definitely does not work. I tried for a long, long time to make
it work and finally gave up. I parse in icontract the whole file where the
lambda function resides and use asttokens to locate the node of the lambda
(along some tree traversing upwards and making as
Hi Hugh,
> As soon as you need to document your code, and
> > this is what most modules have to do in teams of more than one person
> > (especially so if you are developing a library for a wider audience), you
> > need to write down the contracts. Please see above where I tried to
> > explained t
Ah. It wasn't clear to me from the thread that James was using `inspect`.
As it happens, not only does getsource give more than it should, it
also gives less than it should. The following bug still exists in
3.6.1. It was closed as a wontfix bug back in Python 2 because, I
presume, fixing it would
On Wed, Sep 26, 2018 at 3:19 AM Marko Ristin-Kaufmann
wrote:
>> 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 "
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.
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 cal
On Wed, Sep 26, 2018 at 6:09 AM 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.
>
> That verifying data against the contract a function makes code more reliable
> should be self evident to anyo
I use DbC occasionally to clarify my thoughts during a refactoring, and
then only in the places that continue to make mistakes. In general, I am
not in a domain that benefits from DbC.
Contracts are code: More code means more bugs. Declarative contracts are
succinct, but difficult to debug when w
On Wed, Sep 26, 2018 at 7:59 AM Kyle Lahnakoski wrote:
> I use DbC occasionally to clarify my thoughts during a refactoring, and then
> only in the places that continue to make mistakes. In general, I am not in a
> domain that benefits from DbC.
>
> Contracts are code: More code means more bugs.
I suggest allowing "while:" syntax for the infinite loop.
I.e. instead of "while 1:" and "while True:" notations.
IIRC, in the past this was mentioned in python-list discussions as
alternative for the
"while True:"/"while 1:" syntax. I even had impression that there was nothing
rational against
On Tue, Sep 25, 2018 at 8:46 PM Mikhail V wrote:
> I suggest allowing "while:" syntax for the infinite loop.
> I.e. instead of "while 1:" and "while True:" notations.
>
> My opinion:
> 1. I think it'd definitely improve clarity.
I prefer the explicit phrase, ``while True:``. Saying "while" with
On Wed, Sep 26, 2018 at 12:35 PM Michael Selik wrote:
>
> On Tue, Sep 25, 2018 at 8:46 PM Mikhail V wrote:
> > I suggest allowing "while:" syntax for the infinite loop.
> > I.e. instead of "while 1:" and "while True:" notations.
> >
> > My opinion:
> > 1. I think it'd definitely improve clarity
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.
>
> Chr
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 KeyboardIn
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`, `let
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
Hi Kyle,
6) The name of the method
> 7) How the method is called throughout the codebase
>
10) relying on convention inside, and outside, the application
>
Sorry, by formulating 2) as "docstring" I excluded names of the methods as
well as variables. Please assume that 2) actually entails those as
Hi Chris,
It's easy to show beautiful examples that may actually depend on other
> things. Whether that's representative of all contracts is another
> question.
I agree. There are also many contracts which are simply too hard to write
down formally. But many are also easily captured in formal ma
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
>
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 "extraordi
40 matches
Mail list logo
