I wrote a lib specially for the case of validator that would also override
the documentation : default is if name of function +args speaks by it
itself then only this is added to the docstring
ex: @require_odd_numbers() => it would add require_odd_numbers at the end
of __doc__ and the possibilitly
Hi everyone, first participation in Python’s mailing list, don’t be too hard on
me
Some suggested above to change the definition of len in the long term. Then I
think it could be interesting to define len such as :
- If has a finite length : return that length (the way it works now)
- If has a
Hi Abe,
Thanks for your suggestions! We actually already considered the two
alternatives you propose.
*Multiple predicates per decorator. *The problem is that you can not deal
with toggling/describing individual contracts easily. While you can hack
your way through it (considering the arguments in
Hi,
Property based testing is not about just generating random values till the
> heath death of the universe, but generating sensible values in a
> configurable way to cover all equivalence classes we can think of. if my
> function takes two floating point numbers as arguments, hypothesis
> "strat
>> +1. Throwing away information is almost always a bad idea.
>
> "Almost always"? Let's take this seriously, and think about the
> consequences if we actually believed that. If I created a series of
> integers:
“Almost". It’s part of my sentence. I have known about addition for many years
i
One thought I had pertains to a very narrow sub-set of cases, but may
provide a starting point. For the cases where a precondition, invariant, or
postcondition only involves a single parameter, attribute, or the return
value (respectively) and it's reasonably simple, one could write it as an
expres
OK. I know I made a mistake by saying, "computers are very good at
*exhaustively* searching multidimensional spaces." I should have said,
"computers are very good at enumerating examples from multi-dimensional
spaces" or something to that effect. Now that we've had our fun, can you
guys please cont
I was assuming it was a Numba-ized function since it's purely numeric. ;-)
FWIW, the theoretical limit of Python ints is limited by the fact
'int.bit_length()' is a platform native int. So my system cannot store ints
larger than (2**(2**63-1)). It'll take a lot more memory than my measly
4GiB to s
Marko, I have a few thoughts that might improve icontract.
First, multiple clauses per decorator:
@pre(
*lambda* x: x >= 0,
*lambda* y: y >= 0,
*lambda* width: width >= 0,
*lambda* height: height >= 0,
*lambda* x, width, img: x + width <= width_of(img),
*lambda* y, height,
But nobody is talking about exhausting the combinatoric space of all
possible values. Property Based Testing looks like Fuzzy Testing but it is
not quite the same thing.
Property based testing is not about just generating random values till the
heath death of the universe, but generating sensible
But Python integers are variable-sized, and their size is basically
limited by available memory or address space.
Let's take a typical 64-bit Python build, assuming 4 GB RAM available.
Let's also assume that 90% of those 4 GB can be readily allocated for
Python objects (there's overhead, etc.).
On Thu, Nov 29, 2018 at 10:25 AM David Mertz wrote:
>
> That's easy, Antoine. On a reasonable modern multi-core workstation, I can do
> 4 billion additions per second. A year is just over 30 million seconds. For
> 32-bit ints, I can whiz through the task in only 130,000 years. We have at
> leas
That's easy, Antoine. On a reasonable modern multi-core workstation, I can
do 4 billion additions per second. A year is just over 30 million seconds.
For 32-bit ints, I can whiz through the task in only 130,000 years. We have
at least several hundred million years before the sun engulfs us.
On Wed
I raised a related problem a while back when I found that random.sample can
only take a sequence. The example I gave was randomly sampling points on a
2D grid to initialize a board for Conway's Game of Life:
>>> def random_board(height: int, width: int, ratio: float = 0.5) ->
Set[Tuple[int, int]]:
E. Madison Bray wrote:
So I might want to check:
finite_definite = True
for it in my_map.iters:
try:
len(it)
except TypeError:
finite_definite = False
if finite_definite:
my_seq = list(my_map)
else:
# some other algorithm
If map is being passed into your functi
E. Madison Bray wrote:
I still believe
that the actual proposal of making the arguments to a map(...) call
accessible from Python as attributes of the map object (ditto filter,
zip, etc.) is useful in its own right, rather than just having this
completely opaque iterator.
But it will only help
On Wed, Nov 28, 2018 at 02:53:50PM -0500, Terry Reedy wrote:
> One of the guidelines in the Zen of Python is
> "Special cases aren't special enough to break the rules."
>
> This proposal claims that the Python 3 built-in iterator class 'map' is
> so special that it should break the rule that ite
[Antoine Pitrou]
> How long do you think it will take your computer to exhaustively search
> the space of possible input values to a 2-integer addition function?
> Do you think it can finish before the Earth gets engulfed by the Sun?
Yes, ok. I used the word "exhaustively" wrong. Sorry about tha
On Wed, 28 Nov 2018 15:58:24 -0600
Abe Dillon wrote:
> Thirdly, Computers are very good at exhaustively searching multidimensional
> spaces.
How long do you think it will take your computer to exhaustively search
the space of possible input values to a 2-integer addition function?
Do you think i
On Wed, Nov 28, 2018 at 05:37:39PM +0100, Anders Hovmöller wrote:
>
>
> > I just mentioned that porting effort for background. I still believe
> > that the actual proposal of making the arguments to a map(...) call
> > accessible from Python as attributes of the map object (ditto filter,
> > zip
[Antoinw Pitrou]
> I think utopia is the word here. Fuzz testing can be useful, but it's
> not a replacement for manual testing of carefully selected values.
First, they aren't mutually exclusive. It's trivial to add manually
selected cases to a hypothesis test.
Second, from my experience; peop
[Steven D'Aprano]
> You should look at the state of the art in Design By Contract. In
> Eiffel, DBC is integrated in the language:
> https://www.eiffel.com/values/design-by-contract/introduction/
>
> https://www.eiffel.org/doc/eiffel/ET-_Design_by_Contract_%28tm%29%2C_Assertions_and_Exceptions
>
>
E. Madison Bray wrote:
if I have a function that used to take, say,
a list as an argument, and it receives a `map` object, I now have to
be able to deal with map()s, and I may have checks I want to perform
on the underlying iterables before, say, I try to iterate over the
`map`.
This sounds lik
[Marko Ristin-Kaufmann]
>
> Have you looked at the recent discussions regarding design-by-contract on
> this list
I tried to read through them all before posting, but I may have missed some
of the forks. There was a lot of good discussion!
[Marko Ristin-Kaufmann]
> You might want to have a look
On 11/28/2018 9:27 AM, E. Madison Bray wrote:
On Mon, Nov 26, 2018 at 10:35 PM Kale Kundert wrote:
I just ran into the following behavior, and found it surprising:
len(map(float, [1,2,3]))
TypeError: object of type 'map' has no len()
I understand that map() could be given an infinite seque
> I just mentioned that porting effort for background. I still believe
> that the actual proposal of making the arguments to a map(...) call
> accessible from Python as attributes of the map object (ditto filter,
> zip, etc.) is useful in its own right, rather than just having this
> completely
Hi Madison
Is there a URL somewhere where I can view code written to port sage to
Python3? I've already found
https://trac.sagemath.org/search?q=python3
And because I'm a bit interested in cluster algebra, I went to
https://git.sagemath.org/sage.git/commit/?id=3a6f494ac1d4dbc1e22b0ecbebdbc639f6c7
I should add, I know the history here of bitterness surrounding Python 3
complaints and this is not one. I defend most things Python 3 and have
ported many projects (Sage just being the largest by orders of magnitude,
with every Python 3 porting quirk represented and often magnified). I agree
with
Probably the most proliferate reason it made things *worse* is that many
functions that can take collections as arguments--in fact probably
most--were never written to accept arbitrary iterables in the first place.
Perhaps they should have been, but the majority of that was before my time
so I and
One thing I'd like to add real quick to this (I'm on my phone so apologies
for crappy quoting):
Although there are existing cases where there is a loss of efficiency over
Python 2 map() when dealing with the opaque, iterable Python 3 map(), the
latter also presents many opportunities for enhanceme
Suppose itr_1 is an iterator. Now consider
itr_2 = map(lambda x: x, itr_1)
itr_3 = itr_1
We now have itr_1, itr_2 and itr_3. There are all, effectively, the
same iterator (unless we do an 'x is y' comparision).
I conclude that this suggestion amounts to have a __len__ for ANY
iterator, a
>
> In the end, you have to be rigorous when writing tests, and for most
> non-trivial functions it requires that you devise the distribution of
> input values depending on the implemented algorithm, not leave that
> distribution to a third-party library that knows nothing about your
> program.
>
On Wed, Nov 28, 2018 at 04:14:24PM +0100, E. Madison Bray wrote:
> For example, some function that used to expect some finite-sized
> sequence such as a list or tuple is now passed a "map", possibly
> wrapping one or more iterable of arbitrary, possibly non-finite size.
> For the purposes of some
On Wed, Nov 28, 2018 at 4:24 PM Chris Angelico wrote:
>
> On Thu, Nov 29, 2018 at 2:19 AM E. Madison Bray wrote:
> >
> > On Wed, Nov 28, 2018 at 4:14 PM Steven D'Aprano wrote:
> > >
> > > On Wed, Nov 28, 2018 at 04:04:33PM +0100, E. Madison Bray wrote:
> > >
> > > > That effort is already mostly
On Thu, Nov 29, 2018 at 2:19 AM E. Madison Bray wrote:
>
> On Wed, Nov 28, 2018 at 4:14 PM Steven D'Aprano wrote:
> >
> > On Wed, Nov 28, 2018 at 04:04:33PM +0100, E. Madison Bray wrote:
> >
> > > That effort is already mostly done and adding a helper function would
> > > not have worked as users
On Wed, Nov 28, 2018 at 4:14 PM Steven D'Aprano wrote:
>
> On Wed, Nov 28, 2018 at 04:04:33PM +0100, E. Madison Bray wrote:
>
> > That effort is already mostly done and adding a helper function would
> > not have worked as users *passing* map(...) as an argument to some
> > function just expect it
On Wed, Nov 28, 2018 at 4:04 PM Steven D'Aprano wrote:
>
> On Wed, Nov 28, 2018 at 03:27:25PM +0100, E. Madison Bray wrote:
>
> > I mostly agree with the existing objections, though I have often found
> > myself wanting this too, especially now that `map` does not simply
> > return a list. This p
On Wed, Nov 28, 2018 at 04:04:33PM +0100, E. Madison Bray wrote:
> That effort is already mostly done and adding a helper function would
> not have worked as users *passing* map(...) as an argument to some
> function just expect it to work.
Ah, that's what I was missing.
But... surely the functi
On Wed, Nov 28, 2018 at 4:04 PM Steven D'Aprano wrote:
>
> On Wed, Nov 28, 2018 at 03:27:25PM +0100, E. Madison Bray wrote:
>
> > I mostly agree with the existing objections, though I have often found
> > myself wanting this too, especially now that `map` does not simply
> > return a list. This p
On Wed, Nov 28, 2018 at 3:54 PM Chris Angelico wrote:
>
> On Thu, Nov 29, 2018 at 1:46 AM Jonathan Fine wrote:
> >
> > On Wed, Nov 28, 2018 at 2:28 PM E. Madison Bray
> > wrote:
> >
> > > I mostly agree with the existing objections, though I have often found
> > > myself wanting this too, espec
On Wed, Nov 28, 2018 at 03:27:25PM +0100, E. Madison Bray wrote:
> I mostly agree with the existing objections, though I have often found
> myself wanting this too, especially now that `map` does not simply
> return a list. This problem alone (along with the same problem for
> filter) has had a r
On Thu, Nov 29, 2018 at 1:46 AM Jonathan Fine wrote:
>
> On Wed, Nov 28, 2018 at 2:28 PM E. Madison Bray wrote:
>
> > I mostly agree with the existing objections, though I have often found
> > myself wanting this too, especially now that `map` does not simply
> > return a list. This problem alon
On Wed, Nov 28, 2018 at 2:28 PM E. Madison Bray wrote:
> I mostly agree with the existing objections, though I have often found
> myself wanting this too, especially now that `map` does not simply
> return a list. This problem alone (along with the same problem for
> filter) has had a ridiculous
On Mon, Nov 26, 2018 at 10:35 PM Kale Kundert wrote:
>
> I just ran into the following behavior, and found it surprising:
>
> >>> len(map(float, [1,2,3]))
> TypeError: object of type 'map' has no len()
>
> I understand that map() could be given an infinite sequence and therefore
> might not alway
On Tue, 27 Nov 2018 22:47:06 -0600
Abe Dillon wrote:
>
> If we could figure out a cleaner syntax for defining invariants,
> preconditions, and postconditions we'd be half-way to automated testing
> UTOPIA! (ok, maybe I'm being a little over-zealous)
I think utopia is the word here. Fuzz testing
On Tue, Nov 27, 2018 at 10:47:06PM -0600, Abe Dillon wrote:
> If we could figure out a cleaner syntax for defining invariants,
> preconditions, and postconditions we'd be half-way to automated testing
> UTOPIA! (ok, maybe I'm being a little over-zealous)
You should look at the state of the art in
46 matches
Mail list logo
