Hi Steve,
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 with current IDEs and static
linters (pylint, mypy)? I fired up pylint and mypy on the sample code from
their web site, played a bit with it an
Barry Scott writes:
> > @requires(lambda self, a, o: self.sum == o.sum - a.amount)
> > def withdraw(amount: int) -> None:
> > ...
> >
> > There is this lambda keyword in front, but it's not too bad?
>
> The lambda smells of internals that I should not have to care about
> being expos
> Which features of the TC39 committee's ECMAscript (ES) language governance
> model would be helpful to incorporate into the Python language governance
> model?
Having “beta” or “alpha” editions of features, special versions of the
interpreter people can test out to see if they prefer the versio
Perhaps it’s because fewer Python functions involve transitioning between
states. Web development and statistics don’t involve many state transition.
State transitions are where I think I would find it useful to write contracts
out explicitly.
___
Pyth
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 be
> On 24 Sep 2018, at 20:09, Marko Ristin-Kaufmann
> wrote:
>
> Hi Barry,
> I think the main issue with pyffel is that it can not support function calls
> in general. If I understood it right, and Angus please correct me, you would
> need to wrap every function that you would call from within
Hi Barry,
I think the main issue with pyffel is that it can not support function
calls in general. If I understood it right, and Angus please correct me,
you would need to wrap every function that you would call from within the
contract.
But the syntax is much nicer than icontract or dpcontracts (
> On 23 Sep 2018, at 11:33, Hugh Fisher wrote:
>
> Could it be that Python has better libraries, is faster to develop for,
> attracts
> more programmers? If so, I suggest it's worth considering that this might
> be *because* Python doesn't have DbC.
I'm not sure how you get from the lack of D
> On 23 Sep 2018, at 11:13, Angus Hollands wrote:
>
> Hi Marko,
>
> I think there are several ways to approach this problem, though am not
> weighing in on whether DbC is a good thing in Python. I wrote a simple
> implementation of DbC which is currently a run-time checker. You could, with
On Tue, Sep 25, 2018 at 1:10 AM Erik Bray wrote:
>
> On Fri, Sep 21, 2018 at 12:58 AM Chris Angelico wrote:
> >
> > On Fri, Sep 21, 2018 at 8:52 AM Kyle Lahnakoski
> > wrote:
> > > Since the java.lang.Thread.stop() "debacle", it has been obvious that
> > > stopping code to run other code has be
Wes Turner writes:
> Is there a link to a document describing the PEP process (with and
> without BDFL)?
PEP 1, and https://devguide.python.org/langchanges/#
But most changes don't need a PEP. We're only discussing this now
because Anders's proposal would need a PEP.
In general, though, PEPs
On Fri, Sep 21, 2018 at 12:58 AM Chris Angelico wrote:
>
> On Fri, Sep 21, 2018 at 8:52 AM Kyle Lahnakoski
> wrote:
> > Since the java.lang.Thread.stop() "debacle", it has been obvious that
> > stopping code to run other code has been dangerous. KeyboardInterrupt
> > (any interrupt really) is d
On Thursday, September 20, 2018, James Lu wrote:
> JS’ decisions are made by a body known as TC39, a fairly/very small group
> of JS implementers.
https://github.com/tc39/
Python has devs with committer privileges:
https://devguide.python.org/experts/
There are maintainers for many modules:
h
Michel Desmoulin writes:
> [W]e should not disregard the design policies because of these
> particular issues.
Please stop. As long as core developers don't get involved, it's just
noise.
If you must continue this thread, PEP it. No major change in the
procedures described in the DevGuide, P
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 correctness of the code,
as I reiterated already a couple of times in the pre
15 matches
Mail list logo