Re: [Python-ideas] Pre-conditions and post-conditions

[Marko Ristin-Kaufmann]

Hi,
To clarify the benefits of the contracts, let me give you an example from
our code base:

@icontract.pre(lambda x: x >= 0)
@icontract.pre(lambda y: y >= 0)
@icontract.pre(lambda width: width >= 0)
@icontract.pre(lambda height: height >= 0)
@icontract.pre(lambda x, width, img: x + width <= pqry.opencv.width_of(img))
@icontract.pre(lambda y, height, img: y + height <= pqry.opencv.height_of(img))
@icontract.post(lambda self: (self.x, self.y) in self)
@icontract.post(lambda self: (self.x + self.width - 1, self.y +
self.height - 1) in self)
@icontract.post(lambda self: (self.x + self.width, self.y +
self.height) not in self)
def __init__(self, img: np.ndarray, x: int, y: int, width: int,
height: int) -> None:
self.img = img[y:y + height, x:x + width].copy()
self.x = x
self.y = y
self.width = width
self.height = height

def __contains__(self, xy: Tuple[int, int]) -> bool:
x, y = xy
return self.x <= x < self.x + self.width and \
   self.y <= y < self.y + self.height

We use mypy and type annotations for typing, and we don't need contracts
for that. In this particular case, contracts are very handy to formulate
how we deal with pixels. If you carefully look at the contracts, you will
see:
* pixels are indexed starting from 0 (as oppose to starting from 1)
* region-of-interest needs to fit within an image. It can not be outside of
its boundaries
* pixels within the region-of-interest are in [x, x + width), [y, y +
height) (where "[" means inclusive and ")" exclusive)

*Why not types?* These constraints are either impossible or very hard to
write as types. Moreover, I doubt that you could give such types meaningful
names, and I expect the readability to suffer immensely. I suppose any
constraints involving more than a couple of variables is hard to write as a
type.

*Benefits.* You could write all of this in human-readable informal
docstring of a class, but then it would never be verified. This way we are
sure that contracts are always there. Whenever we test, we can be sure that
all the contracted properties hold. Mind that we do not test that they hold
for that single test case -- we automatically test that they hold for all
the test cases.

This is, in my opinion, far superior to ambiguous human documentation or
print statements (which are deleted after the debugging). I suppose *any*
larger code base built by a team of more than one developer needs this kind
of rigor. The contracts are not meant to be used only in high-risk
applications -- they are meant to improve any code base.

*Problem without standard support. *The current libraries (dpcontracts,
icontract) can deal with pre and postconditions and class invariants of a
concrete class.

However, the current libraries break as soon as you have inheritance. There
is no way in python to inherit the function decorators and to modify them.
If we are to inherit from the above-mentioned class ROI, we need to make
sure that the invariants of the parent class hold (*e.g., *what is
contained in a ROI) as well as invariants of the child class. We might want
to weaken the requirements (*e.g., *a ROI that can deal with pixels outside
of an image) such that x and y can be an arbitrary numbers, not restricted
to 0 <= x < img.width and 0 <= y < img.height respectively.

Additionally, without standard approach, we do not know how to deal with
contracts when we have a third-party tool that would like to use them (*e.g.,
*for automatic generation of unit tests, static testing or visualization in
IDE or in documentation).

@Wes Turner : If I understood you correctly, you are
looking for a library that gives you verbose messages when a contract is
breached. Please have a look at icontract library:
https://github.com/Parquery/icontract

We added informative messages particularly because we wanted to have
verbose output when something goes wrong.This was helpful not only during
the development, but also in production since failure cases were hard to
reproduce and anticipate in the first place (otherwise, they wouldn't have
made it into the production). Here is an example with an error message:

>>> class B:... def __init__(self) -> None:... self.x = 7.. 
>>> def y(self) -> int:... return 2.. def __repr__(self) -> 
>>> str:... return "instance of B"...>>> class A:... def 
>>> __init__(self)->None:... self.b = B().. def __repr__(self) 
>>> -> str:... return "instance of A"...>>> SOME_GLOBAL_VAR = 13>>> 
>>> @icontract.pre(lambda a: a.b.x + a.b.y() > SOME_GLOBAL_VAR)... def 
>>> some_func(a: A) -> None:... pass...>>> an_a = A()>>> some_func(an_a)
Traceback (most recent call last):
  ...
icontract.ViolationError: Precondition violated: (a.b.x + a.b.y()) >
SOME_GLOBAL_VAR:SOME_GLOBAL_VAR was 13
a was instance of A
a.b was instance of B
a.b.x was 7
a.b.y() was 2


On Tue, 28 Aug 2018 at 03:19, Wes Turner  wrote:

> Thanks for the explanation.
>
> This may be a bit OT,
> 

Re: [Python-ideas] Pre-conditions and post-conditions

[Wes Turner]

Thanks for the explanation.

This may be a bit OT,
but is there a good way to do runtime assertions (in particular for data
validation) that's as easy as assert?

- self.assertEqual (unittest.TestCase.assertEqual) is hardly usable in
other class instances,
- pytest can be used at runtime but has somewhat nontrivial overhead
- I always end up writing e.g. _assert() and _assertEqual() that throw
AssertionErrors and helpful error messages just like unittest.


How do contracts differ from checking interfaces with e.g. zope.interface?
https://zopeinterface.readthedocs.io/en/latest/verify.html

I'll read up a bit more on design by contract. I seem to have
conceptualized dbc as a composition approach with typed interfaces and type
and value assertions, but that's not it?

If the parameter value assertions in pycontracts aren't really contracts,
and the mypy compile-time parameter and return type checks are not really
contracts, and zope.interface verifications aren't really contracts; what
does that leave in terms of abstract data types, preconditions,
postconditions, and invariants?

https://en.wikipedia.org/wiki/Design_by_contract

On Monday, August 27, 2018, Steven D'Aprano  wrote:

> On Mon, Aug 27, 2018 at 11:01:21AM -0400, Wes Turner wrote:
> > Runtime checks: data validation & code validation
> > Compile-time checks: code validation
> >
> > What sort of data validation is appropriate for assert statements or
> > contacts that may be skipped due to trading performance for more risk
> > ('optimized out')?
>
> That depends on what you mean by "data validation".
>
> Testing for bad input, or testing for predictable error states such as
> I/O errors, missing files, permission errors, server down etc is
> not appropriate for assertions (which includes contracts).
>
> The rule I use is that assertions are for:
>
> (1) testing your program state, which is under your control; and
>
> (2) communicating the intention of your program as executable
> code rather than comments.
>
> The ultimate aim of contracts and assertions is to eventually disable
> them when the program is bug-free.
>
> The Eiffel docs say:
>
> It should be clear from the preceding discussion that contracts
> are not a mechanism to test for special conditions, for example
> erroneous user input. For that purpose, the usual control
> structures [...] are available [...] An assertion is instead a
> correctness condition governing the relationship between two
> software modules (not a software module and a human, or a
> software module and an external device). ... Bluntly:
>
> Rule -- Assertion Violation: A run-time assertion violation is
> the manifestation of a bug.
>
> https://www.eiffel.org/doc/eiffel/ET-_Design_by_Contract_
> %28tm%29%2C_Assertions_and_Exceptions
>
> For detecting *external* error states (anything to do with data that
> comes from outside your program, like user input) you can never let your
> guard down and never disable the test, because servers can always go
> down, users can always give you bad data, files can always be corrupt.
> It is unsafe to disable these tests and so these should not be
> assertions.
>
> For a library function intended to be called by third-parties, the
> function arguments aren't under the control of the library author so
> should not be tested with assertions. But for an application where the
> author controls those function arguments, they are under the author's
> control and may be assertions or contracts.
>
> Design By Contract is partly a methodology and partly a set of syntax.
> Its a way of thinking about the design of your program. In practice, you
> don't have to buy 100% into DBC to get some benefit for it. A study done
> a few years back looked at 21 large projects in Eiffel, JML (Java) and
> Code Contracts for C# and found that 33% of the classes used contracts.
>
> http://se.ethz.ch/~meyer/publications/methodology/contract_analysis.pdf
>
> Like unit testing, you don't need 100% coverage to get benefit. 10% is
> better than nothing, and 20% is better than 10%.
>
> I wrote more about assertions here:
>
> https://import-that.dreamwidth.org/676.html
>
>
> --
> 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/
>
___
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] Pre-conditions and post-conditions

[Steven D'Aprano]

On Mon, Aug 27, 2018 at 11:01:21AM -0400, Wes Turner wrote:
> Runtime checks: data validation & code validation
> Compile-time checks: code validation
> 
> What sort of data validation is appropriate for assert statements or
> contacts that may be skipped due to trading performance for more risk
> ('optimized out')?

That depends on what you mean by "data validation".

Testing for bad input, or testing for predictable error states such as 
I/O errors, missing files, permission errors, server down etc is 
not appropriate for assertions (which includes contracts).

The rule I use is that assertions are for:

(1) testing your program state, which is under your control; and

(2) communicating the intention of your program as executable 
code rather than comments.

The ultimate aim of contracts and assertions is to eventually disable 
them when the program is bug-free.

The Eiffel docs say:

It should be clear from the preceding discussion that contracts
are not a mechanism to test for special conditions, for example
erroneous user input. For that purpose, the usual control
structures [...] are available [...] An assertion is instead a 
correctness condition governing the relationship between two 
software modules (not a software module and a human, or a
software module and an external device). ... Bluntly:

Rule -- Assertion Violation: A run-time assertion violation is
the manifestation of a bug.

https://www.eiffel.org/doc/eiffel/ET-_Design_by_Contract_%28tm%29%2C_Assertions_and_Exceptions

For detecting *external* error states (anything to do with data that 
comes from outside your program, like user input) you can never let your 
guard down and never disable the test, because servers can always go 
down, users can always give you bad data, files can always be corrupt. 
It is unsafe to disable these tests and so these should not be 
assertions.

For a library function intended to be called by third-parties, the 
function arguments aren't under the control of the library author so 
should not be tested with assertions. But for an application where the 
author controls those function arguments, they are under the author's 
control and may be assertions or contracts.

Design By Contract is partly a methodology and partly a set of syntax. 
Its a way of thinking about the design of your program. In practice, you 
don't have to buy 100% into DBC to get some benefit for it. A study done 
a few years back looked at 21 large projects in Eiffel, JML (Java) and 
Code Contracts for C# and found that 33% of the classes used contracts.

http://se.ethz.ch/~meyer/publications/methodology/contract_analysis.pdf

Like unit testing, you don't need 100% coverage to get benefit. 10% is 
better than nothing, and 20% is better than 10%.

I wrote more about assertions here:

https://import-that.dreamwidth.org/676.html


-- 
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] Python-ideas Digest, Vol 141, Issue 145

[James Lu]

> As Matthew points out, you could use numpy.array. Or code your own
> class, by providing __add__ and __iadd__ methods.
>
> >>> import numpy
> >>> a = numpy.array([1, 2])
> >>> b = numpy.array([3, 4])
> >>> a + b
> array([4, 6])
> >>> a += b
> >>> a
> array([4, 6])

I could, but I don't think that justifies not having this functionality in
python
standard. From the language experience perspective, numpy is often a
pain to install on most systems. If I'm designing card games and I
just want to run a quick monte carlo simulation, the experience should be
as smooth as possible.

This is something I think most students will expect while learning python,
especially if they're implementing algorithms.

On Mon, Aug 27, 2018 at 4:24 AM  wrote:

> Send Python-ideas mailing list submissions to
> python-ideas@python.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://mail.python.org/mailman/listinfo/python-ideas
> or, via email, send a message with subject or body 'help' to
> python-ideas-requ...@python.org
>
> You can reach the person managing the list at
> python-ideas-ow...@python.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Python-ideas digest..."
>
>
> Today's Topics:
>
>1. Re: Unpacking iterables for augmented assignment (Matthew Einhorn)
>2. Re: Unpacking iterables for augmented assignment (Jonathan Fine)
>3. Re: Pre-conditions and post-conditions (Jacco van Dorp)
>4. Re: Pre-conditions and post-conditions (Ivan Levkivskyi)
>
>
> --
>
> Message: 1
> Date: Mon, 27 Aug 2018 01:29:14 -0400
> From: Matthew Einhorn 
> To: python-ideas@python.org
> Subject: Re: [Python-ideas] Unpacking iterables for augmented
> assignment
> Message-ID:
>  ymm-fnyw3bza2hjqsgmdgtrvbua...@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> On Sun, Aug 26, 2018, 9:24 PM James Lu  wrote:
>
> > Hi Johnathan
> >
> > I echo your points. Indeed, the PEP referenced to refers to a "tuple
> > expression" in the grammatical and not the programmatic sense.
> >
> > Finally, here's something that surprised me a little bit
> >
> > >>> x = [1, 2]; id(x)
> > 140161160364616
> > >>> x += [3, 4]; id(x)
> > 140161160364616
> >
> > >>> x = (1, 2); id(x)
> > 140161159928520
> > >>> x += (3, 4); id(x)
> > 140161225906440
> >
> > Notice that '+=' creates uses the same object when the object is
> > a
> > list, but creates a new object. This raises the question: Why and
> > how
> > does Python behave in this way?
> >
> > It's because lists are mutable are tuples are immutable.
> > There's a dunder iadd method and a dunder add method.
> > iadd magic methods, operating on the left hand side, return None and
> > modify the object in-place. add magic methods return the result and
> > don't modify the object it's called on.
> > iadd is mutable add, whereas add is "return a copy with the result
> > added"
> >
> > >>> tuple.__iadd__
> > Traceback (most recent call last):
> > File "", line 1, in 
> > AttributeError: type object 'tuple' has no attribute '__iadd__'
> > type object 'tuple' has no attribute '__iadd__'
> > >>> tuple.__add__
> > 
> > >>> list.__iadd__
> > 
> > >>> list.__add__
> > 
> >
> >
> > tuple1 = tuple1.__add__(tuple2)
> >
> > list1.__iadd__(list2)
> >
> > > Does it IN PRACTICE bring sufficient benefits to users?
> >
> > I found myself needing this when I was writing a monte-carlo
> > simulation in python that required incrementing a tallying counter
> > from a subroutine.
> >
>
>
> Wouldn't a numpy array be very suited for this kind of task?
>
> >
> -- next part --
> An HTML attachment was scrubbed...
> URL: <
> http://mail.python.org/pipermail/python-ideas/attachments/20180827/a1c698af/attachment-0001.html
> >
>
> --
>
> Message: 2
> Date: Mon, 27 Aug 2018 07:25:00 +0100
> From: Jonathan Fine 
> To: python-ideas 
> Subject: Re: [Python-ideas] Unpacking iterables for augmented
> assignment
> Message-ID:
>  yf9b7erxanbvbxz2ybjr4zleyv1tphv7+u3ebo2sw08...@mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> James h

Re: [Python-ideas] A GUI for beginners and experts alike

[Brett Cannon]

On Fri, 24 Aug 2018 at 18:18 Mike Barnett  wrote:

> It’s fascinating just how many packages are being dragged out for
> examination or clobbering other than the one that I asked for
> assistance/help on.
>
>
>
> I see the code of conduct link in the thread.  Perhaps a review would be
> helpful.
>


>
>
> Unsubscribing from this mess.  “Python Ideas” ?
>

So I code of conduct review of this thread would suggest that your opening
email was inappropriate by being misleading thanks to sounding like you
were a neutral third-party to your library (luckily you admit to this
later, but it shouldn't have been done to begin with). The tone was okay,
but you state a lot of opinions as if they are fact, e.g. "GUI code is far
from compact", "you've got to be skilled to use it", etc. Those are all
opinions expressed as facts which can be misleading and potentially
insulting depending on who you're talking to (i.e. some of the people who
have worked very hard to make tkinter even work are on this mailing list).

Your initial email was also off-topic. This mailing list is about ideas to
changing Python, not announcements. Once again you later mention you wanted
to start a discussion about getting PySimpleGUI into the stdlib, but it
would have been nicer to mention that from the beginning as people would
have pointed you at
https://devguide.python.org/stdlibchanges/#adding-a-new-module and that
would have answered your question.

But as part of getting a module into the stdlib, alternatives will be
considered (especially GUI libraries as this topic is not a new one and
there are many options available, all with their own approaches). So if you
actual intent was to get PySimpleGUI into the stdlib some day then
discussing other libraries isn't off-topic at all as you will eventually
need to address why your library is better than others. Being upset that
people are doing their due diligence by bringing up alternatives as part of
your request about talking about eventually adding PySimpleGUI to the
stdlib is not a CoC violation at all and honestly your tone in your last
email is a much bigger concern and deserves the warning --which I am giving
-- more than how anyone else has behaved.

-Brett


>
>
>
>
>
>
> *@mike* 
>
>
>
> *From:* Python-ideas  hotmail@python.org> *On Behalf Of *Stephan Houben
> *Sent:* Friday, August 24, 2018 9:07 PM
> *To:* Chris Barker 
> *Cc:* Python-Ideas 
>
>
> *Subject:* Re: [Python-ideas] A GUI for beginners and experts alike
>
>
>
>
>
> Op za 25 aug. 2018 02:28 schreef Chris Barker - NOAA Federal via
> Python-ideas :
>
>
>
> Too bad all the cool kids are doing web dev these days — hard to get
> help with a desktop GUI project :-(
>
>
>
> Pywebview seems interesting, uses a platform  webview to put up the UI;
>
>
>
> https://github.com/r0x0r/pywebview
> 
>
>
>
> But not so newbie-friendly I am afraid...
>
>
>
> Stephan
>
>
>
>
> > Pyjamas seems to be something like that:
> >
> > https://pypi.org/project/Pyjamas/
> 
>
> Or it was 6 years ago :-(
>
> -CHB
> ___
> 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/

[Python-ideas] Pre-conditions and post-conditions

[Wes Turner]

Runtime checks: data validation & code validation
Compile-time checks: code validation

What sort of data validation is appropriate for assert statements or
contacts that may be skipped due to trading performance for more risk
('optimized out')?
Checking the value of a Number?
Checking that a large graph has no cycles?
Checking that a database table exists and has the appropriate relations and
constraints?

assert statements are skipped at runtime with -O and -OO whether or not
they're in [reorderable] aspects applied with decorators, at the beginning
or end of a function, or in methods named something like setUp and tearDown.

https://docs.python.org/3/using/cmdline.html#envvar-PYTHONOPTIMIZE
https://docs.python.org/3/using/cmdline.html#cmdoption-o


> -O
>   Remove assert statements and any code conditional on the value of
__debug__


> PYTHONOPTIMIZE
>   If this is set to a non-empty string it is equivalent to specifying the
-O option. If set to an integer, it is equivalent to specifying -O multiple
times.


On Monday, August 27, 2018, Steven D'Aprano  wrote:

> On Mon, Aug 27, 2018 at 11:00:22PM +1000, Chris Angelico wrote:
>
> > Sometimes "type" doesn't mean the same thing to the language and to
> > the human. Suppose you're trying to create a Python script that
> > replicates a C program; you might want to declare that a variable is
> > not of type "integer" but type "32-bit unsigned integer", with
> > wrap-around. Or, wording it another way: "integer modulo 2**32". Is
> > that an assertion of type, or of type and value? As a precondition to
> > a function, requiring that a parameter be an integer no less than zero
> > and no greater than 4294967295 is, in a sense, checking its type and
> > its value; but it's kinda just asserting its type.
>
> It is making an assertion about the value of an instance of type "int".
> Its not a separate type requiring an explicit coercion or cast. Its just
> a non-negative int less than 2**32.
>
> If the compiler supports the concept of a 32-bit unsigned integer type,
> then of course we can change our implementation to use that type instead
> of our regular ints. But we can't expect to pass such a 32-bit unsigned
> integer to a function which expects a regular int unless they are
> duck-type compatible, or the compiler performs automatic coercions.
> (So-called "weak typing").
>
> A better example is the one I gave earlier, of a graph with no cycles.
> There is a deep fundamental difference between a *statically checked*
> DAG with no cycles (a graph which can never contain a cycle because the
> compiler won't let you create one) and a *dynamically checked* DAG that
> merely has no cycles *now* (it may have had cycles earlier, and it might
> have cycles later, but right now it has none).
>
> These are very different semantics, and Eiffel's contracts support the
> second kind: runtime value checks.
>
>
>
> --
> 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/
>
___
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] Pre-conditions and post-conditions

[Steven D'Aprano]

On Mon, Aug 27, 2018 at 11:00:22PM +1000, Chris Angelico wrote:

> Sometimes "type" doesn't mean the same thing to the language and to
> the human. Suppose you're trying to create a Python script that
> replicates a C program; you might want to declare that a variable is
> not of type "integer" but type "32-bit unsigned integer", with
> wrap-around. Or, wording it another way: "integer modulo 2**32". Is
> that an assertion of type, or of type and value? As a precondition to
> a function, requiring that a parameter be an integer no less than zero
> and no greater than 4294967295 is, in a sense, checking its type and
> its value; but it's kinda just asserting its type.

It is making an assertion about the value of an instance of type "int". 
Its not a separate type requiring an explicit coercion or cast. Its just 
a non-negative int less than 2**32.

If the compiler supports the concept of a 32-bit unsigned integer type, 
then of course we can change our implementation to use that type instead 
of our regular ints. But we can't expect to pass such a 32-bit unsigned 
integer to a function which expects a regular int unless they are 
duck-type compatible, or the compiler performs automatic coercions. 
(So-called "weak typing").

A better example is the one I gave earlier, of a graph with no cycles. 
There is a deep fundamental difference between a *statically checked* 
DAG with no cycles (a graph which can never contain a cycle because the 
compiler won't let you create one) and a *dynamically checked* DAG that 
merely has no cycles *now* (it may have had cycles earlier, and it might 
have cycles later, but right now it has none).

These are very different semantics, and Eiffel's contracts support the 
second kind: runtime value checks.



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

[Python-ideas] PEP 420: implicit namespace sub-package

[Gallian Colombeau]

Hello,

the PEP 420 (Implicit Namespace Packages) is quite descriptive about the 
problem and the solution implemented back in Python 3.3 but I feel there 
may be a part missing (but maybe this is categorized as an 
implementation detail).


As I understand, for a package to allow being extended in this way, it 
must be a namespace package and not contain a marker file. As a matter 
of fact, no sub-package until the top level package can have a marker file:


Lib/test/namespace_pkgs
project1
parent
child
one.py
project2
parent
child
two.py

However, what is not discussed is "implicit namespace sub-package". In 
Python 3.6 (I guess since the first implementation), if you have this 
layout:

Lib/test/namespace_pkgs
project1
parent # Regular package
__init__.py
child # Namespace package
one.py

you get "parent" as a regular package and "parent.child" as a namespace 
package and it works (although now, every package data directory became 
namespace packages and are importable, which may or may not be 
desirable). The point is, does that add any value? I wasn't able to find 
any discussion about this and, as far as I can see, there is actually no 
use case for this as there is no possible way to contribute to the 
"parent.child" namespace. Is that an intended behavior of PEP 420?


Again, I may have missed something or misinterpreted PEP 420 but this 
contributes to the "Implicit package directories introduce ambiguity 
into file system layouts." point by Nick Coghlan that was supposed to be 
addressed in PEP 395.


Wouldn't it be more appropriate to enforce a sub-package to be a regular 
package if the parent package is a regular package?


Gallian
--

*Gallian Colombeau *
*Software engineer *

hiphen-plant-logo 
*Centre INRA PACA - UMR EMMAH*
/228, route de l'aérodrome - CS 40509
84914 Avignon - Cedex 9 - France /
www.hiphen-plant.com

___
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] Pre-conditions and post-conditions

[Chris Angelico]

On Mon, Aug 27, 2018 at 10:50 PM, Steven D'Aprano  wrote:
> On Mon, Aug 27, 2018 at 12:12:22PM +0100, Ivan Levkivskyi wrote:
>> Contract in 99% of cases is just another word for type (maybe a very
>> complex type like `DAG[T] <: Graph[T]`).
>> Everything else, like `x >= y` is better expressed as an explicit assert
>> with an assert message.
>
> Contracts ARE assertions. They are assertions about the input a method
> expects, not merely the type but the value, what result it intends to
> return, and the invariants of the class after the method is called. Like
> assertions, they are called at runtime, and can be disabled.

Sometimes "type" doesn't mean the same thing to the language and to
the human. Suppose you're trying to create a Python script that
replicates a C program; you might want to declare that a variable is
not of type "integer" but type "32-bit unsigned integer", with
wrap-around. Or, wording it another way: "integer modulo 2**32". Is
that an assertion of type, or of type and value? As a precondition to
a function, requiring that a parameter be an integer no less than zero
and no greater than 4294967295 is, in a sense, checking its type and
its value; but it's kinda just asserting its type.

AIUI, that's what Ivan meant by "complex type" - something that
determines the domain of valid values as well as the concrete type.

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] Pre-conditions and post-conditions

[Steven D'Aprano]

On Mon, Aug 27, 2018 at 12:12:22PM +0100, Ivan Levkivskyi wrote:
> On Mon, 27 Aug 2018 at 11:39, Steven D'Aprano  wrote:
> 
> > On Mon, Aug 27, 2018 at 09:24:20AM +0100, Ivan Levkivskyi wrote:
> > > TBH, I think one of the main points of design by contract is that
> > contracts
> > > are verified statically.
> >
> > No, that's not correct. Contracts may be verified statically if the
> > compiler is able to do so, but they are considered runtime checks.
> >
> 
> Considered by whom? By people who prefer `assert isinstance(x, int)` over
> `x: int`? :-)

No, considered by Bertrand Meyer, the inventor of Design By Contract and 
the programming language Eiffel.

Contracts are not limited to the things which static type-checkers are 
capable of testing, but can and do involve checks which are impossible 
or impractical to test at compile-time, like "today is Tuesday" or "the 
account balance is greater than the amount you are trying to withdraw".


> Contract in 99% of cases is just another word for type (maybe a very
> complex type like `DAG[T] <: Graph[T]`).
> Everything else, like `x >= y` is better expressed as an explicit assert
> with an assert message.

Contracts ARE assertions. They are assertions about the input a method 
expects, not merely the type but the value, what result it intends to 
return, and the invariants of the class after the method is called. Like 
assertions, they are called at runtime, and can be disabled.

Using contracts to enforce type-correctness wouild be silly in Eiffel, 
because Eiffel already has a powerful static type system.

Sybtax-wise, if you're interested in what is possible in a Python-like 
language, you could do worse than check out Cobra:

http://cobra-language.com/trac/cobra/wiki/Contracts


-- 
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] Pre-conditions and post-conditions

[Jonathan Fine]

Ivan and Steve wrote

>> TBH, I think one of the main points of design by contract is that contracts
>> are verified statically.

> No, that's not correct.

> https://www.eiffel.org/doc/eiffel/ET-_Design_by_Contract_%28tm%29%2C_Assertions_and_Exceptions

The page from Steve supplied (URL above) states

> During development and testing, assertion monitoring should
> be turned on at the highest possible level. Combined with
> static typing and the immediate feedback of compilation techniques
> [...] this permits the development process  [...]
> where errors are exterminated at birth.

Based on the Eiffel docs, I find Ivan's opinion reasonable. He said it
was "one of the main points". The goal is to detect errors
immediately. Run-time assertion monitoring and static typing are two
means towards that end.

Our shared problem and goal is to have similar immediate detection of
errors in Python (when the development process requires that degree of
rigour).

-- 
Jonathan
___
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] Pre-conditions and post-conditions

[Ivan Levkivskyi]

On Mon, 27 Aug 2018 at 11:39, Steven D'Aprano  wrote:

> On Mon, Aug 27, 2018 at 09:24:20AM +0100, Ivan Levkivskyi wrote:
> > TBH, I think one of the main points of design by contract is that
> contracts
> > are verified statically.
>
> No, that's not correct. Contracts may be verified statically if the
> compiler is able to do so, but they are considered runtime checks.
>

Considered by whom? By people who prefer `assert isinstance(x, int)` over
`x: int`? :-)

Contract in 99% of cases is just another word for type (maybe a very
complex type like `DAG[T] <: Graph[T]`).
Everything else, like `x >= y` is better expressed as an explicit assert
with an assert message.
But again this is rather IMO, than any kind of definition.

There is only one use case I see now where a dedicated syntax would give a
large readability gain:
something like `self.x >= self.y`. But on the other hand I think such
situations are too rare to justify any _new_ syntax.

--
Ivan
___
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] Pre-conditions and post-conditions

[Steven D'Aprano]

On Mon, Aug 27, 2018 at 09:24:20AM +0100, Ivan Levkivskyi wrote:
> TBH, I think one of the main points of design by contract is that contracts
> are verified statically.

No, that's not correct. Contracts may be verified statically if the 
compiler is able to do so, but they are considered runtime checks. 
Static checks are an optimization.

For example, the Eiffel docs describe one possible contract as "the 
graph contains no cycle" and can contain function calls.

https://www.eiffel.org/doc/eiffel/ET-_Design_by_Contract_%28tm%29%2C_Assertions_and_Exceptions



-- 
Steven
___
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] Pre-conditions and post-conditions

[Steven D'Aprano]

On Mon, Aug 27, 2018 at 09:04:21AM +0200, Jacco van Dorp wrote:
> Total noob speaking here, but
> 
> Those contracts are mostly important during development right ?

That assumes that production code is free of bugs.

Usual practice in the Eiffel world is, I believe, to disable post- 
condition checking and other assertions in production code, but leave 
pre-condition checks in place.

Note: for those unfamiliar with Design By Contract, pre- and post- 
condition checks and assertions are NOT used to detect predictable error 
states, such as bad user input or IO errors. They are only used for 
testing program correctness. A failed contract or assertion can only 
mean a bug in the program. In a totally bug-free program contracts can 
safely be disabled.


> Slowdown isn't that much of an issue during development.

For many cases, it isn't an issue during production either.


> So you could make a debug
> mode that enforces the contracts, and a production mode that code 
> users can use during production to stop the slowdown

In Eiffel, contracts can be disabled or enable globally, or on a 
class-by-class basis.


> - in this case, your decorators
> can return their functions/classes unaltered. If they do end up with
> problems, you can always ask them to run the same inputs with debug mode on
> to see where it goes wrong.
> 
> For the rest, i'm totally new to design by contract. I do get the draw of
> it, but im not sure if I'd ever really use it. I tend to solve my problems
> with a royal sprinkling of logger.debug(f"{val_i_need_to_check}").

The differences between design by contract and sprinkling messages in 
the log include:

- the compiler (or interpreter) never forgets to read the logs 
  looking for failures;

- when a failure occurs, the program halts, so you know its broken,
  rather than silently continuing and perhaps doing something 
  unexpected;

- you don't need to read the logs and try to remember why it is
  that you're printing the value of ``foo`` and whether its a
  good thing or a bad thing that it has the value you're seeing.


Here's an introduction to design by contract:

https://www.eiffel.org/doc/eiffel/ET-_Design_by_Contract_%28tm%29%2C_Assertions_and_Exceptions



-- 
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] Pre-conditions and post-conditions

[Ivan Levkivskyi]

TBH, I think one of the main points of design by contract is that contracts
are verified statically.
For runtime contract checking I would rather recommend hypothesis library
(or similar).

--
Ivan



On Mon, 27 Aug 2018 at 08:05, Jacco van Dorp  wrote:

> Total noob speaking here, but
>
> Those contracts are mostly important during development right ? Slowdown
> isn't that much of an issue during development. So you could make a debug
> mode that enforces the contracts, and a production mode that code users can
> use during production to stop the slowdown - in this case, your decorators
> can return their functions/classes unaltered. If they do end up with
> problems, you can always ask them to run the same inputs with debug mode on
> to see where it goes wrong.
>
> For the rest, i'm totally new to design by contract. I do get the draw of
> it, but im not sure if I'd ever really use it. I tend to solve my problems
> with a royal sprinkling of logger.debug(f"{val_i_need_to_check}").
> ___
> 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] Pre-conditions and post-conditions

[Jacco van Dorp]

Total noob speaking here, but

Those contracts are mostly important during development right ? Slowdown
isn't that much of an issue during development. So you could make a debug
mode that enforces the contracts, and a production mode that code users can
use during production to stop the slowdown - in this case, your decorators
can return their functions/classes unaltered. If they do end up with
problems, you can always ask them to run the same inputs with debug mode on
to see where it goes wrong.

For the rest, i'm totally new to design by contract. I do get the draw of
it, but im not sure if I'd ever really use it. I tend to solve my problems
with a royal sprinkling of logger.debug(f"{val_i_need_to_check}").
___
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] Unpacking iterables for augmented assignment

[Jonathan Fine]

James has suggested that Python be enhanced so that
>>> a, b += c, d
is a short-hand for
>>> a += c
>>> b += d

Myself, James and Matthew wrote

>> > Does it IN PRACTICE bring sufficient benefits to users?

>> I found myself needing this when I was writing a monte-carlo
>> simulation in python that required incrementing a tallying counter
>> from a subroutine.

> Wouldn't a numpy array be very suited for this kind of task?

Perhaps, James, you might like to refactor your code so that
>>> tally += simulation(args)
does what you want.

As Matthew points out, you could use numpy.array. Or code your own
class, by providing __add__ and __iadd__ methods.

>>> import numpy
>>> a = numpy.array([1, 2])
>>> b = numpy.array([3, 4])
>>> a + b
array([4, 6])
>>> a += b
>>> a
array([4, 6])

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