On 10/2/2018 11:05 AM, Marko Ristin-Kaufmann wrote:
Hi Ned,
The idea is to polish a proof-of-concept library and then try to
introduce it into the standard libs eventually.
I'd suggest taking this off-list until such a library is developed,
then. But, if the library needs some hook provided
Hi Ned,
The idea is to polish a proof-of-concept library and then try to introduce
it into the standard libs eventually.
On Tue, 2 Oct 2018 at 16:57, Ned Batchelder wrote:
> I'm getting confused: is this still about an idea for Python, or
> development of a third-party library?
>
> --Ned.
>
>
I'm getting confused: is this still about an idea for Python, or
development of a third-party library?
--Ned.
On 10/2/18 1:14 AM, Marko Ristin-Kaufmann wrote:
Hi James,
I had another take at it. I wrote it down in the github issue
Hi James,
I had another take at it. I wrote it down in the github issue (
https://github.com/Parquery/icontract/issues/48#issuecomment-426147468):
SLOW=os.environ.get("SOME_ENVIRONMENT_VARIABLE", "") != ""
class SomeClass:
def __init__(self)->None:
self.some_prop = 1984
def
Hi Marko,
I’m going to refer to the transpiler syntax as “block syntax.”
1. How does Eiffel do formal contracts?
2. What’s the use case for preferring block syntax over lambda syntax? Is the
block syntax only better when multiple statements are needed to test a single
contract condition?
2.
Hi James,
Regarding the “transpile into Python” syntax with with statements: Can I
> see an example of this syntax when used in pathlib? I’m a bit worried this
> syntax is too long and “in the way”, unlike decorators which are before the
> function body. Or do you mean that both MockP and your
