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

[Stephen J. Turnbull]

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 exposed.
 > So -1 on lambda being required.

If you want to get rid of the lambda you can use strings and then
'eval' them in the condition.  Adds overhead.

If you want to avoid the extra runtime overhead of parsing
expressions, it might be nice to prototype with MacroPy.  This should
also allow eliminating the lambda by folding it into the macro (I
haven't used MacroPy but it got really good reviews by fans of that
kind of thing).  It would be possible to avoid decorator syntax if you
want to with this implementation.

I'm not sure that DbC is enough of a fit for Python that it's worth
changing syntax to enable nice syntax natively, but detailed reports
on a whole library (as long as it's not tiny) using DbC with a nice
syntax (MacroPy would be cleaner, but I think it would be easy to "see
through" the quoted conditions in an eval-based implementation) would
go a long way to making me sit up and take notice.  (I'm not
influential enough to care about, but I suspect some committers would
be impressed too.  YMMV)

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] JS? governance model is worth inspecting

[James Lu]

> 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 version with the new 
feature. 

To prevent splintering, the main releases would only support the main feature 
set. In a worst case scenario, people can compile incompatible code to .pyc 
before running it.
___
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]

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

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 before the 
function runs. Then you could “replace” the expression.
@post(lambda self, key, old: old.get is None and old.length + 1 ==
self.length())

Either the system would grab old.get and old.length or be greedy and grab 
old.get is None and old.length + 1. It would then replace the old.get and 
old.length with injects that only respond to is None and +1.

Or, a syntax like this 
@post(lambda self, key, old: [old.get(old.key)] is None and [old.self.length() 
+ 1] ==
self.length())

Where the stuff inside the brackets is evaluated before the decorated function 
runs. It would be useful for networking functions or functions that do 
something ephemeral, where data related to the value being accessed needed for 
the expression no longer exists after the function. 

This does conflict with list syntax forever, so maybe either force people to do 
list((expr,)) or use an alternate syntax like one item set syntax { } or double 
set syntax {{ }} or double list syntax [[ ]]. Ditto with having to avoid the 
literals for the normal meaning.

You could modify Python to accept any expression for the lambda function and 
propose that as a PEP. (Right now it’s hardcoded as a dotted name and 
optionally a single argument list surrounded by parentheses.)

I suggest that instead of “@before” it’s “@snapshot” and instead of “old” it’s 
“snapshot”.

Python does have unary plus/minus syntax as well as stream operators (<<, >>) 
and list slicing syntax and the @ operator and operators & and | if you want to 
play with syntax. There’s also the line continuation character for crazy 
lambdas.

Personally I prefer
@post(lambda self, key, old: {{old.self.get(old.key)}} and {{old.self.length() 
+ 1}} ==
self.length())

because it’s explicit about what it does (evaluate the expressions within {{ }} 
before the function runs. I also find it elegant.

Alternatively, inside the {{ }} could be a special scope where locals() is all 
the arguments @pre could’ve received as a dictionary. For either option you can 
remove the old parameter from the lambda. Example:
@post(lambda self, key: {{self.get(key)}} and {{self.length() + 1}} ==
self.length())

Perhaps the convention should be to write {{ expr }} (with the spaces in 
between).

You’d probably have to use the ast module to inspect it instead of the dis 
modul. Then find some way to reconstruct the expressions inside the double 
brackets- perhaps by reconstructing the AST and compiling it to a code object, 
or perhaps by finding the part of the string the expression is located. dis can 
give you the code as a string and you can run a carefully crafted regex on it.
___
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?

[Barry Scott]

> 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 the contract.
> 
> But the syntax is much nicer than icontract or dpcontracts (see these 
> packages on pypi). What if we renamed "args" argument and "old" argument in 
> those libraries to just "a" and "o", respectively? Maybe that gives readable 
> code without too much noise:

The args and old and not noise its easier to read the a and o.
a and o as aliases for more descriptive names maybe, but not as the only name.

> 
> @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 
exposed.
So -1 on lambda being required.
Also being able to supply a list of conditions was a +1.

> 
> I'll try to contact dpcontracts maintainers. Maybe it's possible to at least 
> merge a couple of libraries into one and make it a de facto standard. @Agnus, 
> would you also like to join the effort?
> 
> Cheers,
> Marko
> 
> 
> 
> 
> 
> Le lun. 24 sept. 2018 à 19:57, Barry Scott  > a écrit :
> 
> 
>> 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 
>> the appropriate tooling, validate statically too (as with all approaches). 
>> In my approach, I use a “proxy” object to allow the contract code to be 
>> defined at function definition time. It does mean that some things are not 
>> as pretty as one would like - anything that cannot be hooked into with magic 
>> methods i.e isinstance, but I think this is acceptable as it makes features 
>> like old easier. Also, one hopes that it encourages simpler contract checks 
>> as a side-effect. Feel free to take a look - 
>> https://github.com/agoose77/pyffel 
>> It is by no means well written, but a fun PoC nonetheless.
>> 
> This is an interesting PoC, nice work! I like that its easy to read the tests.
> 
> Given a library like this the need to build DbC into python seems unnecessary.
> 
> What do other people think?
> 
> Barry
> 
> 
> 
>> Regards,
>> Angus
>> 
>> ___
>> 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/ 
> 

___
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 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 (see these
packages on pypi). What if we renamed "args" argument and "old" argument in
those libraries to just "a" and "o", respectively? Maybe that gives
readable code without too much noise:

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

I'll try to contact dpcontracts maintainers. Maybe it's possible to at
least merge a couple of libraries into one and make it a de facto standard.
@Agnus, would you also like to join the effort?

Cheers,
Marko





Le lun. 24 sept. 2018 à 19:57, Barry Scott  a
écrit :

>
>
> 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 the appropriate tooling, validate statically too (as with all
> approaches). In my approach, I use a “proxy” object to allow the contract
> code to be defined at function definition time. It does mean that some
> things are not as pretty as one would like - anything that cannot be hooked
> into with magic methods i.e isinstance, but I think this is acceptable as
> it makes features like old easier. Also, one hopes that it encourages
> simpler contract checks as a side-effect. Feel free to take a look -
> https://github.com/agoose77/pyffel
> It is by no means well written, but a fun PoC nonetheless.
>
> This is an interesting PoC, nice work! I like that its easy to read the
> tests.
>
> Given a library like this the need to build DbC into python seems
> unnecessary.
>
> What do other people think?
>
> Barry
>
>
>
> Regards,
> Angus
> ​
> ___
> 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/
>
___
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?

[Barry Scott]

> 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 DbC being a feature to python's 
success.

I use DbC in my python code via the asserts and its been very useful in my 
experience.

If there was a nice way to get better then the assert method I'd use it. Like 
Angus's PoC.

I assume that developers that are not interesting in DbC would simply not use 
any
library/syntax that supported it.

Barry

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

[Barry Scott]

> 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 
> the appropriate tooling, validate statically too (as with all approaches). In 
> my approach, I use a “proxy” object to allow the contract code to be defined 
> at function definition time. It does mean that some things are not as pretty 
> as one would like - anything that cannot be hooked into with magic methods 
> i.e isinstance, but I think this is acceptable as it makes features like old 
> easier. Also, one hopes that it encourages simpler contract checks as a 
> side-effect. Feel free to take a look - https://github.com/agoose77/pyffel 
> 
> It is by no means well written, but a fun PoC nonetheless.
> 
This is an interesting PoC, nice work! I like that its easy to read the tests.

Given a library like this the need to build DbC into python seems unnecessary.

What do other people think?

Barry



> Regards,
> Angus
> 
> ___
> 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] Asynchronous exception handling around with/try statement borders

[Chris Angelico]

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 been dangerous.  KeyboardInterrupt
> > > (any interrupt really) is dangerous. Now, we can probably code a
> > > solution, but how about we remove the danger:
> > >
> > > I suggest we remove interrupts from Python, and make them act more like
> > > java.lang.Thread.interrupt(); setting a thread local bit to indicate an
> > > interrupt has occurred.  Then we can write explicit code to check for
> > > that bit, and raise an exception in a safe place if we wish.  This can
> > > be done with Python code, or convenient places in Python's C source
> > > itself.  I imagine it would be easier to whitelist where interrupts can
> > > raise exceptions, rather than blacklisting where they should not.
> >
> > The time machine strikes again!
> >
> > https://docs.python.org/3/c-api/exceptions.html#signal-handling
>
> Although my original post did not explicitly mention
> PyErr_CheckSignals() and friends, it had already taken that into
> account and it is not a silver bullet, at least w.r.t. the exact issue
> I raised, which had to do with the behavior of context managers versus
> the
>
> setup()
> try:
> do_thing()
> finally:
> cleanup()
>
> pattern, and the question of how signals are handled between Python
> interpreter opcodes.  There is a still-open bug on the issue tracker
> discussing the exact issue in greater details:
> https://bugs.python.org/issue29988

To be fair, your post not only didn't mention CheckSignals, but it
almost perfectly described its behaviour. So I stand by my response.
:) I don't think the system needs to be replaced; it ought to be
possible to resolve the context manager issue without tossing out the
existing code.

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] JS’ governance model is worth inspecting

[Stephen J. Turnbull]

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 are rare.  There are many hundreds of pull
requests accepted every year, but there only about 500 PEPs (including
rejected, withdrawn, and deferred PEPs) over the entire history of
Python.  Of those, quite a few are Process and Informational PEPs.

The Language Changes section is #20, and doesn't get a quick link from
the table of links in the "Contributing" section of the home page of
the DevGuide.  That's as it should be, IMO, so I'm not going to write
up a PR to add such a link.  YMMV, go right ahead.

___
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] Asynchronous exception handling around with/try statement borders

[Erik Bray]

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 dangerous. Now, we can probably code a
> > solution, but how about we remove the danger:
> >
> > I suggest we remove interrupts from Python, and make them act more like
> > java.lang.Thread.interrupt(); setting a thread local bit to indicate an
> > interrupt has occurred.  Then we can write explicit code to check for
> > that bit, and raise an exception in a safe place if we wish.  This can
> > be done with Python code, or convenient places in Python's C source
> > itself.  I imagine it would be easier to whitelist where interrupts can
> > raise exceptions, rather than blacklisting where they should not.
>
> The time machine strikes again!
>
> https://docs.python.org/3/c-api/exceptions.html#signal-handling

Although my original post did not explicitly mention
PyErr_CheckSignals() and friends, it had already taken that into
account and it is not a silver bullet, at least w.r.t. the exact issue
I raised, which had to do with the behavior of context managers versus
the

setup()
try:
do_thing()
finally:
cleanup()

pattern, and the question of how signals are handled between Python
interpreter opcodes.  There is a still-open bug on the issue tracker
discussing the exact issue in greater details:
https://bugs.python.org/issue29988
___
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] JS’ governance model is worth inspecting

[Wes Turner]

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:
https://devguide.python.org/experts/


>
> First, JS has an easy and widely supported way to modify the language for
> yourself: Babel. Babel transpires your JS to older JS, which is then run.
>
> You can publish your language modification on the JS package manager, npm.


Babel plugins are packaged for and installable with npm:
https://babeljs.io/docs/en/plugins

New ES features can run on older JS interpreter features with transpilation
by Babel.


>
> When a feature is being considered for inclusion in mainline JS, the
> proposal must first gain a champion (represented by )that is a member of
> TC-39. The guidelines say that the proposal’s features should already have
> found use in the community. Then it moves through three stages, and the
> champion must think the proposal is ready for the next stage before it can
> move on. I’m hazy on what the criterion for each of the three stages is.
> The fourth stage is approved.


Is there a link to a document describing the PEP process (with and without
BDFL)?

That would be a helpful link to add to the table here:
https://devguide.python.org/#contributing

e.g. "How to write a PEP" as an ISSUE_TEMPLATE/ might be helpful:

- [ ] Read the meta-PEPs
- [ ] and find the appropriate BDFL-delegate
- [ ] copy the PEP 12 RST template
- [ ] add the headings specified in PEP 1
- [ ] Read PEP 1

"Meta-PEPs (PEPs about PEPs or Processes)"
https://www.python.org/dev/peps/#meta-peps-peps-about-peps-or-processes

PEP 12 -- Sample reStructuredText PEP Template
https://www.python.org/dev/peps/pep-0012/

PEP 1 -- PEP Purpose and Guidelines
https://www.python.org/dev/peps/pep-0001/

PEPs
https://github.com/python/peps


> I believe the global TC39 committee meets regularly in person, and at
> those meetings, proposals can advance stages- these meetings are frequent
> enough for the process to be fast and slow enough that people can have the
> time to try out a feature before it becomes main line JS. Meeting notes are
> made public.


PEP 1 describes the PEP mailing list and editors.


>
> The language and its future features are discussed on ESDiscuss.org, which
> is surprisingly filled with quality and respectful discussion, largely from
> experts in the JavaScript language.


python-dev@, python-ideas@,


>
> I’m fairly hazy on the details, this is just the summary off the top of my
> head.
>
> —
> I’m not saying this should be Python’s governance model, just to keep JS’
> in mind.


Which features of the TC39 committee's ECMAscript (ES) language governance
model would be helpful to incorporate into the Python language governance
model?
___
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] JS’ governance model is worth inspecting

[Stephen J. Turnbull]

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, PEP 1, and so on will take place
without a PEP.  If you're serious, you'll have to put in that much
effort to get a hearing.  If you're not, you're wasting lines in my
mail client's summary screen.

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

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

Please do re-read my previous messages on the topic a bit more attentively.
These two pages I also found informative and they are quite fast to read
(<15 min):
https://www.win.tue.nl/~wstomv/edu/2ip30/references/design-by-contract/index.html
https://gleichmann.wordpress.com/2007/12/09/test-driven-development-and-design-by-contract-friend-or-foe/

Here is a quick summary of the argument.

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.

Here is what seems obvious to me. *Please do point me to what is not
obvious to you* because that is the piece of puzzle that I am missing (*i.e.
*why this is not obvious and what are the intricacies). I enumerated the
statements for easier reference:

a) Using 1) is the only option when you have to deal with inheritance.
Other approaches can no do that *without much repetition *in practice
*.*

b) If you write contracts in text, they will become stale over time
(*i.e. *disconnected
from the implementation and *plain wrong and misleading*). It is a common
problem that the comments rot over time and I hope it does not need further
argument (please let me know if you really think that the comments *do not
rot*).

c) Using 3), doctests, means that you need mocking as soon as your method
depends on non-trivial data structures. Moreover, if the output of the
function is not trivial and/or long, you actually need to write the
contract (as postcondition) just *after *the call in the doctest.
Documenting preconditions includes writing down the error that will be
thrown. Additionally, you need to write that what you are documenting
actually also holds for all other examples, not just for this particular
test case (*e.g.*, in human text as a separate sentence before/after the
doctest in the docstring).

d) Reading other people's code in 4) and 5) is not trivial in most cases
and requires a lot of attention as soon as the method includes calls to
submethods and functions. This is impractical in most situation*s *since *most
code is non-trivial to read* and is subject to frequent changes.

e) Most of the time, 5) is not even a viable option as the testing code is
not even shipped with the package and includes going to github (if the
package is open-sourced) and searching through the directory tree to find
the test. This forces every user of a library to get familiar with the *testing
code *of the library.

f) 4) and 5) are *obviously* a waste of time for the user -- please do
explain why this might not be the case. Whenever I use the library, I do
not expect to be forced to look into its test code and its implementation.
I expect to read the documentation and just use the library if I'm
confident about its quality. I have rarely read the implementation of the
standard libraries (notable exceptions in my case are ast and subprocess
module) or any well-established third-party library I frequently use
(numpy, opencv, sklearn, nltk, zmq, lmdb, sqlalchemy). If the documentation
is not clear about the contracts, I use trial-and-error to figure out the
contracts myself. This again is *obviously* a waste of time of the *user *and
it's far easier to read the contracts directly than use trial-and-error
*.*


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

List[Path]
Returns:

list of initial files (*i.e.* no directories)
Requires:

   - 

Re: [Python-ideas] JS’ governance model is worth inspecting

[Michel Desmoulin]

Le 22/09/2018 à 20:27, James Lu a écrit :
> > To my mind, there is one very big reason we should be cautious about
> > adopting JS language-design policies, namely, that they have led to a
> > very, very poorly designed language.  No doubt a good deal of that is
> > baggage from early stages in which JS had a poor to nonexistent language
> > design governance model.  Nonetheless, the failure of JS to fix its
> > numerous fundamental flaws, and especially the rapid feature churn in
> > recent years, suggests to me that their model should be viewed with
> > skepticism.
> I disagree. The language is often very flexible and effective in its
domains. I don’t know what you mean by “rapid feature churn”, churn
usually means existing features are superseded by newer ones- this isn’t
the case.
>
> JS is much more nuanced than it appears on the surface. It’s
understandable that those with only a glossing of JS look down on it,
because JS really was a primitive language a few years ago.
>
> You can learn about JS in depth with the poorly-named “You don’t know
JS” free online book.
>

I worked with JS for the last 10 years, and I agree that "we should be
cautious about
adopting JS language-design policies", particularly about the fact they
completly ignored readability in their concerns.

But still, using the old JS baggages to justify we reject what they are
doing currently is not a good argument:

  - they can't break the whole Web so deprecation is very hard. Python 2
=> 3 should make us understand that. Yes it sucks you can still declare
a variable global by default. It also sucked we had to rewrite most good
python modules during the last decade.
  - the new JS features have been so far a good fit for the language and
overall made it better.
  - fast pace evolution is only for the JS ecosystem (and I agree it's
terrible). But the spec and implementations
have been very reasonable in their progress.

Now it's hard to know if it's because of the design policy or in spite
of it. But while I still dislike JS, it IS a vastly better language that
it used to be and we should not disregard the design policies because of
these particular issues.


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