Hi James,
I agree. Having a snapshot decorator per variable also has the advantage
that we can add parameters to the decorator (e.g., snapshots also need
"enabled" and "description" argument).
How should we distinguish the two approaches? (I suppose you would also
apply them to requests, ensures
Hi James,
Sure, let's do that! I'm fine with emails, too. I needed only a bit of
structure since we lumped so many issues together, but maybe it's just my
OCD :)
Le lun. 1 oct. 2018 à 04:05, James Lu a écrit :
> Hi Marko,
>
> Regarding switching over to GitHub issues:
> * I copy-pasted the
Hi Marko,
Regarding switching over to GitHub issues:
* I copy-pasted the MockP original code to GitHub issues.
* There's a clunky way to view the discussion at
https://mail.python.org/pipermail/python-ideas/2018-September/subject.html#start
.
* The less clunky way to view the discussion is to
Hi James,
(I'm just about to go to sleep, so I'll answer the other messages tomorrow.)
Should we keep some kind of document to keep track of all the different
> proposals? I’m thinking an editable document like HackMD where we can label
> all the different ideas to keep them straight in our head.
Hi Marko,
I just found the time to reply to these.
> I reread the proposal with MockP. I still don't get the details, but if I
> think I understand the basic idea. You put a placeholder and whenever one of
> its methods is called (including dunders), you record it and finally assemble
> an AST
Hi Marko,
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
Hi Marko,
> If the documentation is clear, I'd expect the user to be able to distinguish
> the two. The first approach is shorter, and uses magic, but fails in some
> rare situations. The other method is more verbose, but always works.
I like this idea.
James Lu
> On Sep 29, 2018, at 1:36 AM,
Hi Marko,
Going back to your proposal on repeating lambda P as a convention.
I do find
@snapshot(some_identifier=P -> P.self(P.arg1),
some_identifier2=P -> P.arg1 + P.arg2)
acceptable.
Should we keep some kind of document to keep track of all the different
proposals? I’m thinking an
Hi James,
I copy/pasted the discussion re the readability tool to an issue on github:
https://github.com/Parquery/icontract/issues/48
Would you mind opening a separate issue and copy/pasting what you find
relevant re MockP approach in a separate issue?
I think it's time to fork the issues and
Hi James,
I reread the proposal with MockP. I still don't get the details, but if I
think I understand the basic idea. You put a placeholder and whenever one
of its methods is called (including dunders), you record it and finally
assemble an AST and compile a lambda function to be executed at
P.p.s. to raise a custom exception:
if not (arg1 < S.var1 < arg2):
"Some description"
raise SomeException(arg1, S.var1, arg2)
The converter enforces that only "if not" statement is allowed, only a
string description (optional) followed by a raise in the body of
if-statement.
This is
Hi James,
What about a tool that we discussed, to convert contracts back and forth to
readable form on IDe save/load with the following syntax:
def some_func(arg1:int, arg2:int)-> int:
# typing on the phone so no indent
With requiring:
Assert arg1 < arg2, "some message"
With snapshotting:
Hi James,
I'm a bit short on time today, and would need some more time and attention
to understand the proposal you wrote. I'll try to come back to you
tomorrow.
In any case, I need to refactor icontract's decorators to use conditions
like lambda P: and lambda P, result: first before adding
> The problem with readability might be easier to solve than I thought, and
> your pointer to coconut gave me the idea. What if we make a utility that
> takes the python source code, examines the decorators pre/post/inv (or
> whatever we call them) and transforms them back and forth from/to
I am fine with your proposed syntax. It’s certainly lucid. Perhaps it would be
a good idea to get people accustomed to “non-magic” syntax.
> I still have a feeling that most developers would like to store the state in
> many different custom ways.
Please explain. (Expressions like thunk(all)(a
Why couldn’t we record the operations done to a special object and replay them?
>>> Actually, I think there is probably no way around a decorator that
>>> captures/snapshots the data before the function call with a lambda (or even
>>> a separate function). "Old" construct, if we are to parse
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
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
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
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`,
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
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
> 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
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
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
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
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
You could disassemble (import dis) the lambda to biew the names of the lambdas.
@before(lambda self, key, _, length, get: self.length(), self.get(key))
Perhaps you could disassemble the function code and look at all operations or
accesses that are done to “old.” and evaluate those expressions
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
29 matches
Mail list logo
