[Python-ideas] Re: approximate equality operator ("PEP 485 follow-up")

[Christopher Barker]

On Sun, Jun 14, 2020 at 7:15 PM Wes Turner  wrote:

> pytest.approx
> https://docs.pytest.org/en/stable/reference.html#pytest-approx
>

Thanks Wes, somehow I never noticed that. It's pretty nifty, particularly
how it can handle dicts and the like automatically.

I'm not a fan of the defaults, but maybe that's nit picking...

Anyone know when that was added to pytest?

-CHB


-- 
Christopher Barker, PhD

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/7GCC64UKH3CYEPEKE4GVY34H6RH2EG54/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: For quicker execution, don't refcount objects that can't be deleted

[Steve Barnes]

-Original Message-
From: Ben Rudiak-Gould  
Sent: 14 June 2020 22:59
To: Jonathan Fine 
Cc: python-ideas 
Subject: [Python-ideas] Re: For quicker execution, don't refcount objects that 
can't be deleted

There isn't really any contention for these memory locations in CPython as it 
stands because only one interpreter thread can run at a time. The only time a 
cache handoff is needed is during a thread switch when the new thread is 
scheduled on a different core, which is pretty rare (at CPU timescales). Adding 
checks to every incref/decref would probably cost more time than it would save.

Something that might help performance a bit, and wouldn't hurt it, would be to 
drop explicit calls of Py_{INC,DEC}REF(Py_{None,False,True,...}), such as the 
ones in Py_RETURN_{NONE,FALSE,TRUE}, making these objects' refcounts into 
freefloating meaningless values. The refcounts would be initially set to a 
value far from zero, and on the rare occasions that they hit zero, the dealloc 
functions would just set them back to the initial value. Whether this would 
save enough time to be worth it, I don't know.

(To avoid signed wraparound undefined behavior, you'd have to either change the 
refcount type from ssize_t to size_t, or else keep the DECREF calls and set the 
initial value to something like
PY_SSIZE_T_MAX/2.)

[Steve Barnes] 
Of course if we had a NaN value for integers, int('NaN'), then we could just 
set the initial count to it and since NaN - anything = NaN all would be golden. 
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/PI4R4WAIADD2OBSCVQNSORYBMA3TRP4P/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: approximate equality operator ("PEP 485 follow-up")

[Wes Turner]

pytest.approx
https://docs.pytest.org/en/stable/reference.html#pytest-approx

```

The ``approx`` class performs floating-point comparisons using a syntax
that's as intuitive as possible::

>>> from pytest import approx
>>> 0.1 + 0.2 == approx(0.3)
True

The same syntax also works for sequences of numbers::

>>> (0.1 + 0.2, 0.2 + 0.4) == approx((0.3, 0.6))
True

Dictionary *values*::

>>> {'a': 0.1 + 0.2, 'b': 0.2 + 0.4} == approx({'a': 0.3, 'b': 0.6})
True

``numpy`` arrays::

>>> import numpy as np
# doctest: +SKIP
>>> np.array([0.1, 0.2]) + np.array([0.2, 0.4]) ==
approx(np.array([0.3, 0.6])) # doctest: +SKIP
True

And for a ``numpy`` array against a scalar::

>>> import numpy as np #
doctest: +SKIP
>>> np.array([0.1, 0.2]) + np.array([0.2, 0.1]) == approx(0.3) #
doctest: +SKIP
True

By default, ``approx`` considers numbers within a relative tolerance of
``1e-6`` (i.e. one part in a million) of its expected value to be equal.
This treatment would lead to surprising results if the expected value
was
``0.0``, because nothing but ``0.0`` itself is relatively close to
``0.0``.
To handle this case less surprisingly, ``approx`` also considers numbers
within an absolute tolerance of ``1e-12`` of its expected value to be
equal.  Infinity and NaN are special cases.  Infinity is only considered
equal to itself, regardless of the relative tolerance.  NaN is not
considered equal to anything by default, but you can make it be equal to
itself by setting the ``nan_ok`` argument to True.  (This is meant to
facilitate comparing arrays that use NaN to mean "no data".)

Both the relative and absolute tolerances can be changed by passing
arguments to the ``approx`` constructor::

>>> 1.0001 == approx(1)
False
>>> 1.0001 == approx(1, rel=1e-3)
True
>>> 1.0001 == approx(1, abs=1e-3)
True

```

On Sun, Jun 14, 2020, 9:39 PM David Mertz  wrote:

> On Sun, Jun 14, 2020 at 7:49 PM Oscar Benjamin 
> wrote:
>
>> > > I've had occasion to use math.isclose(), np.isclose(), and
>> np.allclose()
>> > > quite often.
>> > Can you elaborate a bit on the kinds of things you use them for?
>>
>> I can't elaborate on David's use but in my own experience these
>> functions are mostly useful for interactive checking or for something
>> like unit tests. They can be used extensively in the testing code for
>> projects with a lot of floating point functions.
>
>
> At times I have computations which *should be* the same mathematically,
> but are carried out through a different sequence of specific computations.
> One common example is in parallel frameworks where the order of computation
> is indeterminate because multiple workers/threads/processes are each
> calculating portions to aggregate.
>
> Another related case is when I call some library to do an operation, but I
> did not write the library, nor do I understand its guts well.  For example,
> the tensor libraries used in neural networks that will calculate a loss
> function.  Occasionally I'd like to be able to replicate (within a
> tolerance) a computation the library performs using something more general
> like NumPy.  Having a few ulps difference is typical, but counts as
> validating the "same" answer.
>
> Another occasion I encounter it is with data measurements.  Some sort of
> instrument collects measurements with a small jitter.  Two measurements
> that cannot be distinguished based on the precision of the instrument might
> nonetheless be stored as different floating point numbers.  In that case, I
> probably want to be able to tweak the tolerances for the specific case.
>
> --
> The dead increasingly dominate and strangle both the living and the
> not-yet born.  Vampiric capital and undead corporate persons abuse
> the lives and control the thoughts of homo faber. Ideas, once born,
> become abortifacients against new conceptions.
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/VJSIJ3VHKVJQUZ6ZSXWY7VCBRXSOQKVJ/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/JTW4TQUG5CQZ7P4EQAT5GHQKDHXEH2UT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: approximate equality operator ("PEP 485 follow-up")

[David Mertz]

On Sun, Jun 14, 2020 at 7:49 PM Oscar Benjamin 
wrote:

> > > I've had occasion to use math.isclose(), np.isclose(), and
> np.allclose()
> > > quite often.
> > Can you elaborate a bit on the kinds of things you use them for?
>
> I can't elaborate on David's use but in my own experience these
> functions are mostly useful for interactive checking or for something
> like unit tests. They can be used extensively in the testing code for
> projects with a lot of floating point functions.


At times I have computations which *should be* the same mathematically, but
are carried out through a different sequence of specific computations.  One
common example is in parallel frameworks where the order of computation is
indeterminate because multiple workers/threads/processes are each
calculating portions to aggregate.

Another related case is when I call some library to do an operation, but I
did not write the library, nor do I understand its guts well.  For example,
the tensor libraries used in neural networks that will calculate a loss
function.  Occasionally I'd like to be able to replicate (within a
tolerance) a computation the library performs using something more general
like NumPy.  Having a few ulps difference is typical, but counts as
validating the "same" answer.

Another occasion I encounter it is with data measurements.  Some sort of
instrument collects measurements with a small jitter.  Two measurements
that cannot be distinguished based on the precision of the instrument might
nonetheless be stored as different floating point numbers.  In that case, I
probably want to be able to tweak the tolerances for the specific case.

-- 
The dead increasingly dominate and strangle both the living and the
not-yet born.  Vampiric capital and undead corporate persons abuse
the lives and control the thoughts of homo faber. Ideas, once born,
become abortifacients against new conceptions.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/VJSIJ3VHKVJQUZ6ZSXWY7VCBRXSOQKVJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: approximate equality operator ("PEP 485 follow-up")

[Oscar Benjamin]

On Mon, 15 Jun 2020 at 00:21, Greg Ewing  wrote:
>
> On 15/06/20 3:52 am, David Mertz wrote:
> > I've had occasion to use math.isclose(), np.isclose(), and np.allclose()
> > quite often.
>
> Can you elaborate a bit on the kinds of things you use them for?

I can't elaborate on David's use but in my own experience these
functions are mostly useful for interactive checking or for something
like unit tests. They can be used extensively in the testing code for
projects with a lot of floating point functions. It's unlikely that a
fundamental numeric algorithm would want to make use of a generic
function such as this though without explicitly setting the tolerance
which wouldn't work with an operator.

Fishing for examples in numpy testing code I quickly came across this
test file where almost every test is based on a function
assert_array_almost_equal:
https://github.com/numpy/numpy/blob/master/numpy/fft/tests/test_helper.py
The docstring for assert_array_almost_equal refers to more functions
that are variants of the idea of closeness testing but somehow not
quite the same.

--
Oscar
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/LLVOHYLGGYTDUUQWWF3SU6I4PLOZR5YW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: approximate equality operator ("PEP 485 follow-up")

[Greg Ewing]

On 15/06/20 3:52 am, David Mertz wrote:
I've had occasion to use math.isclose(), np.isclose(), and np.allclose() 
quite often.


Can you elaborate a bit on the kinds of things you use them for?

--
Greg
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/Z4EO5YYMVHHPM4RKS5XJN26AETLVNA72/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Operator ">" for functions

[Greg Ewing]

On 15/06/20 3:36 am, Paul Moore wrote:

def foo() -> {1, 2, 3}:
return 2


That is, of course, valid syntax right now. I wonder what a type
checker could do with it?


Even if it understood your intent, it probably couldn't do much,
because enforcing that constraint would require a run-time check.

--
Greg
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/5NQBLPGDD5S4W5NV7LOOCY4ZRQICUOVH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: For quicker execution, don't refcount objects that can't be deleted

[Guido van Rossum]

There's a PR for this: "Immortal instances", by Eddie Elizondo (Facebook).

Github PR: https://github.com/python/cpython/pull/19474
Bug Report: https://bugs.python.org/issue40255

On Sat, Jun 13, 2020 at 3:48 AM Jonathan Fine  wrote:

> Hi
>
> Here's something that might make code run quicker. The basic idea is to
> not refcount some objects that are sure never to be deleted. On a multicore
> machine, this might significantly reduce the number of cache invalidations
> (and perhaps misses). I lack many of the skills needed to investigate this
> further.
>
> Aside: This idea prompted by: Make `del x` an expression evaluating to `x`
>
> https://mail.python.org/archives/list/python-ideas@python.org/message/WVQNATE7KYU5G64BQB5VEWALPYVS3QPV/
>
> Consider
> >>> tuple(id(n) - id(0) for n in range(10))
> (0, 32, 64, 96, 128, 160, 192, 224, 256, 288)
>
> Why? Small integers are stored at fixed locations, hence the arithmetic
> progression. Let's look at refcounts.
> >>> import sys
> >>> tuple(sys.getrefcount(n) for n in range(10))
> (511, 837, 113, 54, 63, 35, 30, 20, 65, 17)
>
> These refcounts are variable numbers. They can be changed (within limits).
> >>> x = [0] * 10
> >>> tuple(sys.getrefcount(n) for n in range(10))
> (100510, 837, 113, 54, 63, 35, 30, 20, 65, 17)
>
> The same happens with None.
> >>> sys.getrefcount(None)
> 8475
> >>> x = [None] * 10
> >>> sys.getrefcount(None)
> 108475
>
> For me the basic idea of the implementation would be to not refcount those
> objects, whose id lies in a certain range. As stated earlier, I suspect the
> main benefit will be on multicore machines being able to make better use of
> per-core caches.
>
> If anyone is interested, I suggest starting with None, to get a rough
> estimate of the possible benefits (and cost of implementation).
>
> As well as the python-ideas thread mentioned above, related to this is:
>
> https://stackoverflow.com/questions/14139111/python-disable-reference-counting-for-some-objects
>
> --
> Jonathan
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/RYMLY4IVTCTIXZRXQAVLBKO4ZQAEH3WG/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/Q35SZXG44OSWXN5QAA6YE237LW7RO5VY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: For quicker execution, don't refcount objects that can't be deleted

[Ben Rudiak-Gould]

There isn't really any contention for these memory locations in
CPython as it stands because only one interpreter thread can run at a
time. The only time a cache handoff is needed is during a thread
switch when the new thread is scheduled on a different core, which is
pretty rare (at CPU timescales). Adding checks to every incref/decref
would probably cost more time than it would save.

Something that might help performance a bit, and wouldn't hurt it,
would be to drop explicit calls of
Py_{INC,DEC}REF(Py_{None,False,True,...}), such as the ones in
Py_RETURN_{NONE,FALSE,TRUE}, making these objects' refcounts into
freefloating meaningless values. The refcounts would be initially set
to a value far from zero, and on the rare occasions that they hit
zero, the dealloc functions would just set them back to the initial
value. Whether this would save enough time to be worth it, I don't
know.

(To avoid signed wraparound undefined behavior, you'd have to either
change the refcount type from ssize_t to size_t, or else keep the
DECREF calls and set the initial value to something like
PY_SSIZE_T_MAX/2.)
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/76JRO673TWG7WNPWPD76ZCRLA4PM6EJA/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Operator ">" for functions

[Wes Turner]

icontract supports preconditions with decorators (that are compatible with
type information stored in annotations :

```

@icontract.require(lambda x: x > 3)
def some_func(x: int, y: int = 5)->None:
pass

```

PyContracts supports a few different syntaxes for specifying preconditions:
decorator, annotations, docstrings. Unfortunately, AFAIU, the annotations
syntax is not compatible with MyPy/typeshed capitalizations:

http://andreacensi.github.io/contracts/

```

Specifying contracts: Contracts can be specified in three ways:

Using the ``@contract`` decorator:

@contract(a='int,>0', b='list[N],N>0', returns='list[N]')
def my_function(a, b):
...
Using annotations (for Python 3):

@contract
def my_function(a : 'int,>0', b : 'list[N],N>0') -> 'list[N]':
 # Requires b to be a nonempty list, and the return
 # value to have the same length.
 ...
Using docstrings, with the :type: and :rtype: tags:

@contract
def my_function(a, b):
""" Function description.
:type a: int,>0
:type b: list[N],N>0
:rtype: list[N]
"""
...
Deployment: In production, all checks can be disabled using the function
contracts.disable_all(), so the performance hit is 0.

```

PEP-316 proposed a docstring syntax which also predates py3k annotations.

On Sun, Jun 14, 2020, 5:47 PM Wes Turner  wrote:

> Such preconditions (checks of input parameters beyond their type at
> compile-tine) are a feature of DbC: Design by Contract.
>
> https://en.wikipedia.org/wiki/Design_by_contract
>
> Python is listed under "Languages with third-party support" :
>
> > Python, using packages like icontract, PyContracts, Decontractors,
> dpcontracts, zope.interface, PyDBC or Contracts for Python. A permanent
> change to Python to support Design by Contracts was proposed in PEP-316,
> but deferred
>
> https://www.python.org/dev/peps/pep-0316/ (2003)
>
>
> "Contracts in python -- a report & next steps" (2018)
>
> https://mail.python.org/archives/list/python-ideas@python.org/thread/3TDEJI4M4LLS56IUHII6W5DLPNPW7BGU/
>
> ... https://github.com/Parquery/icontract :
>
> > Second, icontract allows inheritance of the contracts and supports
> weakining of the preconditions as well as strengthening of the
> postconditions and invariants. Notably, weakining and strengthening of the
> contracts is a feature indispensable for modeling many non-trivial class
> hierarchies. Please see Section Inheritance. To the best of our knowledge,
> there is currently no other Python library that supports inheritance of the
> contracts in a correct way.
>
> On Sun, Jun 14, 2020, 12:29 PM Christopher Barker 
> wrote:
>
>> On Sun, Jun 14, 2020 at 8:41 AM Paul Moore  wrote:
>>
>>> As Chris A says, I'd be inclined to see how far we can get with
>>> (extended) type hints before going for new syntax, though.
>>>
>>> > def foo() -> {1, 2, 3}:
>>> >return 2
>>>
>>> That is, of course, valid syntax right now. I wonder what a type
>>> checker could do with it? Similarly,
>>>
>>
>> Well, the thing is that there is no way to know at compile time what
>> Value is getting passed in -- this is really more a way to catch a
>> ValueError than TypeError, so can't be done with static type checking.
>>
>> Unless you do, as ChrisA suggests, crate a Type (and Enum) that you can
>> then check for.
>>
>> But while I like the idea of Enums, particularly for, say multi-valued
>> flags, They require an extra name and extra typingthat I find annoying
>> (annoying enough that I haven't used one yet in my code. That is, I prefer,
>> so use Chris A's example:
>>
>> some_function(1, 2)
>> ...
>>
>> to:
>>
>> from some_module import Spam
>>
>> some_function(Spam(1), 2)
>>...
>>
>> That being said, if you want your API to be "safe" and type-chackable,
>> then Enum is the way to go.
>>
>> As for the OP, who was asking for a run-time check, if:
>>
>> def fun(a, b):
>> if a not in {1,2,3}:
>> raise ValueError("a has to be one of these values: 1, 2, 3")
>>
>> is too verbose, you can always write a utility function (or a callable
>> class or closure that stores the options) to make it a simple one-liner:
>>
>> def fun(a, b):
>> value_check(a, options= {1, 2, 3})
>>
>> -CHB
>>
>> --
>> Christopher Barker, PhD
>>
>> Python Language Consulting
>>   - Teaching
>>   - Scientific Software Development
>>   - Desktop GUI and Web Development
>>   - wxPython, numpy, scipy, Cython
>> ___
>> Python-ideas mailing list -- python-ideas@python.org
>> To unsubscribe send an email to python-ideas-le...@python.org
>> https://mail.python.org/mailman3/lists/python-ideas.python.org/
>> Message archived at
>> https://mail.python.org/archives/list/python-ideas@python.org/message/MPST6DZ2WF2XBIO4U26II2WJGTHRL3OL/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to 

[Python-ideas] Re: Operator ">" for functions

[Wes Turner]

Such preconditions (checks of input parameters beyond their type at
compile-tine) are a feature of DbC: Design by Contract.

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

Python is listed under "Languages with third-party support" :

> Python, using packages like icontract, PyContracts, Decontractors,
dpcontracts, zope.interface, PyDBC or Contracts for Python. A permanent
change to Python to support Design by Contracts was proposed in PEP-316,
but deferred

https://www.python.org/dev/peps/pep-0316/ (2003)


"Contracts in python -- a report & next steps" (2018)

https://mail.python.org/archives/list/python-ideas@python.org/thread/3TDEJI4M4LLS56IUHII6W5DLPNPW7BGU/

... https://github.com/Parquery/icontract :

> Second, icontract allows inheritance of the contracts and supports
weakining of the preconditions as well as strengthening of the
postconditions and invariants. Notably, weakining and strengthening of the
contracts is a feature indispensable for modeling many non-trivial class
hierarchies. Please see Section Inheritance. To the best of our knowledge,
there is currently no other Python library that supports inheritance of the
contracts in a correct way.

On Sun, Jun 14, 2020, 12:29 PM Christopher Barker 
wrote:

> On Sun, Jun 14, 2020 at 8:41 AM Paul Moore  wrote:
>
>> As Chris A says, I'd be inclined to see how far we can get with
>> (extended) type hints before going for new syntax, though.
>>
>> > def foo() -> {1, 2, 3}:
>> >return 2
>>
>> That is, of course, valid syntax right now. I wonder what a type
>> checker could do with it? Similarly,
>>
>
> Well, the thing is that there is no way to know at compile time what Value
> is getting passed in -- this is really more a way to catch a ValueError
> than TypeError, so can't be done with static type checking.
>
> Unless you do, as ChrisA suggests, crate a Type (and Enum) that you can
> then check for.
>
> But while I like the idea of Enums, particularly for, say multi-valued
> flags, They require an extra name and extra typingthat I find annoying
> (annoying enough that I haven't used one yet in my code. That is, I prefer,
> so use Chris A's example:
>
> some_function(1, 2)
> ...
>
> to:
>
> from some_module import Spam
>
> some_function(Spam(1), 2)
>...
>
> That being said, if you want your API to be "safe" and type-chackable,
> then Enum is the way to go.
>
> As for the OP, who was asking for a run-time check, if:
>
> def fun(a, b):
> if a not in {1,2,3}:
> raise ValueError("a has to be one of these values: 1, 2, 3")
>
> is too verbose, you can always write a utility function (or a callable
> class or closure that stores the options) to make it a simple one-liner:
>
> def fun(a, b):
> value_check(a, options= {1, 2, 3})
>
> -CHB
>
> --
> Christopher Barker, PhD
>
> Python Language Consulting
>   - Teaching
>   - Scientific Software Development
>   - Desktop GUI and Web Development
>   - wxPython, numpy, scipy, Cython
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/MPST6DZ2WF2XBIO4U26II2WJGTHRL3OL/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/4LLFUISHAPYMYIGE22I7DHUTSIKLJ74S/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: For quicker execution, don't refcount objects that can't be deleted

[Christopher Barker]

well, the problem is that the code calling the refcount doen'st know those
objects are "special", and thus need to call  Py_INCREF and Py_DECREF
anyway.

So are you suggesting that Py_INCREF and Py_DECREF do a check to see if the
objects is "special" in this way, and not actually change the refcount?
Would that really help performance at all?

BTW, you could probably check this with little understanding of cPython
internals by simply hacking those two functions (macros?) to be no-ops, and
and see how it affects performance.

-CHB


On Sat, Jun 13, 2020 at 3:49 AM Jonathan Fine  wrote:

> Hi
>
> Here's something that might make code run quicker. The basic idea is to
> not refcount some objects that are sure never to be deleted. On a multicore
> machine, this might significantly reduce the number of cache invalidations
> (and perhaps misses). I lack many of the skills needed to investigate this
> further.
>
> Aside: This idea prompted by: Make `del x` an expression evaluating to `x`
>
> https://mail.python.org/archives/list/python-ideas@python.org/message/WVQNATE7KYU5G64BQB5VEWALPYVS3QPV/
>
> Consider
> >>> tuple(id(n) - id(0) for n in range(10))
> (0, 32, 64, 96, 128, 160, 192, 224, 256, 288)
>
> Why? Small integers are stored at fixed locations, hence the arithmetic
> progression. Let's look at refcounts.
> >>> import sys
> >>> tuple(sys.getrefcount(n) for n in range(10))
> (511, 837, 113, 54, 63, 35, 30, 20, 65, 17)
>
> These refcounts are variable numbers. They can be changed (within limits).
> >>> x = [0] * 10
> >>> tuple(sys.getrefcount(n) for n in range(10))
> (100510, 837, 113, 54, 63, 35, 30, 20, 65, 17)
>
> The same happens with None.
> >>> sys.getrefcount(None)
> 8475
> >>> x = [None] * 10
> >>> sys.getrefcount(None)
> 108475
>
> For me the basic idea of the implementation would be to not refcount those
> objects, whose id lies in a certain range. As stated earlier, I suspect the
> main benefit will be on multicore machines being able to make better use of
> per-core caches.
>
> If anyone is interested, I suggest starting with None, to get a rough
> estimate of the possible benefits (and cost of implementation).
>
> As well as the python-ideas thread mentioned above, related to this is:
>
> https://stackoverflow.com/questions/14139111/python-disable-reference-counting-for-some-objects
>
> --
> Jonathan
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/RYMLY4IVTCTIXZRXQAVLBKO4ZQAEH3WG/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
Christopher Barker, PhD

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/DO7NA4TT2HQYUUZKO7V5RP7EZFIIELQY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: New attribute __convert__ for classes

[Christopher Barker]

On Sun, Jun 14, 2020 at 9:04 AM Oleg Broytman  wrote:

> On Sun, Jun 14, 2020 at 03:33:16PM -, artem6191  <
> artem129...@gmail.com> wrote:
> > This attribute will use for convertion classes to other types, i.e.
> int(MyClass) will return __convert__ result in MyClass
>Define ``__int__`` or ``__index__``.
>

or __float__

But the problem is that we need a dunder for each type you want to support.
I think the idea here is that you could specify, in your own custom class,
which type(s) you can convert to, and it could be any type.

That being said, to the OP:

what are your use cases here? adding a dunder requires compelling use
cases, and in this case, why having a dunder would be more helpful that
simply writing a convert to this type method on your class.

And when would that dunder be called? I'm having trouble figuring that out.

-CHB




>See
> https://docs.python.org/3/reference/datamodel.html#special-method-names
>
> Oleg.
> --
> Oleg Broytmanhttps://phdru.name/p...@phdru.name
>Programmers don't die, they just GOSUB without RETURN.
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/PTAVFYSXD4KTUYJCBWO7GB7F5QOH6Z5N/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
Christopher Barker, PhD

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/FNXMKLLJ665DMQCRQCQ6DZERNGQGC43N/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: New attribute __convert__ for classes

[Jason Madden]

zope.interface provides an implementation of PEP 246. That PEP defines a 
`__conform__` method objects can use to adapt themselves to a prototype:

>>> from zope.interface.common.numbers import IIntegral
>>> class MyClass:
...   def __init__(self, number: int):
...  self.number = number
...   def __conform__(self, prototype):
...   if prototype is IIntegral:
...  return self.number * 5
...
>>> IIntegral(MyClass(1))
5
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/4ONUXMAHPJMPH2RC2QYTFWXLOLHJ6VXO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Operator ">" for functions

[Christopher Barker]

On Sun, Jun 14, 2020 at 8:41 AM Paul Moore  wrote:

> As Chris A says, I'd be inclined to see how far we can get with
> (extended) type hints before going for new syntax, though.
>
> > def foo() -> {1, 2, 3}:
> >return 2
>
> That is, of course, valid syntax right now. I wonder what a type
> checker could do with it? Similarly,
>

Well, the thing is that there is no way to know at compile time what Value
is getting passed in -- this is really more a way to catch a ValueError
than TypeError, so can't be done with static type checking.

Unless you do, as ChrisA suggests, crate a Type (and Enum) that you can
then check for.

But while I like the idea of Enums, particularly for, say multi-valued
flags, They require an extra name and extra typingthat I find annoying
(annoying enough that I haven't used one yet in my code. That is, I prefer,
so use Chris A's example:

some_function(1, 2)
...

to:

from some_module import Spam

some_function(Spam(1), 2)
   ...

That being said, if you want your API to be "safe" and type-chackable, then
Enum is the way to go.

As for the OP, who was asking for a run-time check, if:

def fun(a, b):
if a not in {1,2,3}:
raise ValueError("a has to be one of these values: 1, 2, 3")

is too verbose, you can always write a utility function (or a callable
class or closure that stores the options) to make it a simple one-liner:

def fun(a, b):
value_check(a, options= {1, 2, 3})

-CHB

-- 
Christopher Barker, PhD

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/MPST6DZ2WF2XBIO4U26II2WJGTHRL3OL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: New attribute __convert__ for classes

[Soni L.]

On 2020-06-14 12:33 p.m., artem6191 wrote:

This attribute will use for convertion classes to other types, i.e. 
int(MyClass) will return __convert__ result in MyClass

Example:
class MyClass:
def __init__(self, numer: int):
   self.number = number
def __convert__(self, type):
   assert type == int # Only integer is allowed
   return self.number*5 # Example

test = MyClass(1)
test_2 = MyClass(5)

print( int(test) ) # 5
print( int(test2) ) # 25


This is wrong. Do not use assert like this.


___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/IOJVYBX2PXGBMJ4G4TJQ5APIQHHKSXND/
Code of Conduct: http://python.org/psf/codeofconduct/

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/C2TGR6B53TGIVLRMJDFHSVMNQIJ7L3M4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: approximate equality operator ("PEP 485 follow-up")

[Christopher Barker]

On Sun, Jun 14, 2020 at 6:34 AM Wes Turner  wrote:

> https://docs.python.org/3/reference/expressions.html#index-61
>
> > The unary ~ (invert) operator yields the bitwise inversion of its
> integer argument. The bitwise inversion of x is defined as -(x+1). It only
> applies to integral numbers.
>

yes, the tilde would be good, but, well, is already a unary operator, not a
binary one. And If we were to add a new operator, it should have the same
precedence as == currently does, so we can't really re-use any others
either.

But ~= would read well for those of us accustomed it its use in math.

Or, if ever Python goes to full on Unicode: ≈

https://numpy.org/doc/stable/reference/generated/numpy.allclose.html
>


> > The above equation is not symmetric in a and b, so that allclose(a, b)
> might be different from allclose(b, a) in some rare cases.
>

There are a number of issues with the numpy implementations, one of which
is this. We really wouldn't want an asymmetric equality-like operator. But
that's one reason why math.isclose doesn't use that same algorithm: it is
symmetric.

But that being said, I don't think this is a good idea, because of two
issues:

1) as stated by Greg Ewing, if you are comparing floats, you really should
be thinking about what tolerance makes sense in your use case.

2) Even more critical, isclose() has the absolute tolerance set to zero, so
that nothing will compare as "close" to zero. So you can't really use it
without thinking about what value makes sense in your use case.

Both of which lead to a basic concept: there is no single
definition of"close", and operators can only have a single definition.

NOTE:

A way to get around that would be to have a global setting for the
tolerances, or a context manager:

with close_tolerances(rel_tol=1e-12, abs_tol=1e-25):
if something ~= something_else:
do_something()


but frankly, the overhead of writing the extra code overwhelms that hassle
of writing is_close().

So: -1 from me.

However, to Alex's point: if someone posts some motivating examples where
the operator would really make the code more readable, *maybe* we could be
persuaded.

-CHB


-- 
Christopher Barker, PhD

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/TLMZ7XACLMUQOJHPFDA4677STNEG6AQW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: New attribute __convert__ for classes

[Oleg Broytman]

On Sun, Jun 14, 2020 at 03:33:16PM -, artem6191   
wrote:
> This attribute will use for convertion classes to other types, i.e. 
> int(MyClass) will return __convert__ result in MyClass
> 
> Example:
> class MyClass:
>def __init__(self, numer: int):
>   self.number = number
>def __convert__(self, type):
>   assert type == int # Only integer is allowed
>   return self.number*5 # Example
> 
> test = MyClass(1)
> test_2 = MyClass(5)
> 
> print( int(test) ) # 5
> print( int(test2) ) # 25

   Define ``__int__`` or ``__index__``.

   See https://docs.python.org/3/reference/datamodel.html#special-method-names

Oleg.
-- 
Oleg Broytmanhttps://phdru.name/p...@phdru.name
   Programmers don't die, they just GOSUB without RETURN.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/PTAVFYSXD4KTUYJCBWO7GB7F5QOH6Z5N/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: approximate equality operator ("PEP 485 follow-up")

[Paul Sokolovsky]

Hello,

On Mon, 15 Jun 2020 00:30:19 +1000
Chris Angelico  wrote:

> On Sun, Jun 14, 2020 at 10:41 PM Sebastian M. Ernst
>  wrote:
> >
> > Hi all,
> >
> > after just having typed tons of `math.isclose` (see PEP 485 [1]) and
> > `numpy.isclose` calls (while basically using their default
> > tolerances most of the time), I was wondering whether it makes
> > sense to add a matching operator.
> >  
> 
> -1. I don't see that Python needs a different comparison operator,
> with all the debates that will come through about "when should I use
> == and when should I use the other". Especially since it'll almost
> certainly refuel the argument that you should never compare floats for
> equality.
> 
> If you're doing a lot with isclose, you can always "from math import
> isclose as cl" and use a shorter name. But please don't encourage
> everyone to use isclose() in place of all comparisons.

All that makes good sense.

I'd encourage everyone who thinks "I need a very special operator
just for me", instead think in terms "Python needs ability to define
custom operators". Needless to say, that doesn't have anything to do
with changes to a core implementation. Instead, you're looking to be
able to define a custom parser/tokenizer/AST transformer for your
source. And all that is possible already yesterday.

Recent example: implementation of "from __future__ import braces":
https://github.com/NeKitDS/braces.py .

> 
> ChrisA

[]

-- 
Best regards,
 Paul  mailto:pmis...@gmail.com
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/NDT7TTQZH3NLQ7UTVCST3HBR6DPSPNSM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: approximate equality operator ("PEP 485 follow-up")

[David Mertz]

On Sun, Jun 14, 2020, 10:22 AM Greg Ewing 
wrote:

> On 15/06/20 12:39 am, Sebastian M. Ernst wrote:
> > It's such a common problem when dealing with floating point numbers
>
> Is it really? I've done quite a lot of work with floating
> point numbers, and I've very rarely needed to compare two
> of them for almost-equality. When I do, I always want to
> be in control of the tolerance rather than have a default
> tolerance provided for me.
>

I've had occasion to use math.isclose(), np.isclose(), and np.allclose()
quite often. And most of the time, the default tolerances are good enough
for my purpose. Note that NumPy and math use different algorithms to define
closeness, moreover.

But it's more often than rare that I want to choose a different tolerance
(or switch between absolute and relative tolerance). Adding an operator
adds an impediment to refactoring to change tolerance. I'm more concerned
about that problem than I am with the few extra characters needed to call a
function.

>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/PVKZZC2GFQDWPUHI2QU7LKP2SBLA7C2G/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Operator ">" for functions

[Paul Moore]

On Sun, 14 Jun 2020 at 08:16, Stephen J. Turnbull
 wrote:
> That could be checked by MyPy, without global dataflow analysis.

"MyPy can check this" is a good point that I hadn't considered (I've
not used mypy much myself, yet).

As Chris A says, I'd be inclined to see how far we can get with
(extended) type hints before going for new syntax, though.

> def foo() -> {1, 2, 3}:
>return 2

That is, of course, valid syntax right now. I wonder what a type
checker could do with it? Similarly,

>>> def foo(a: {0, 1, 2}) -> {1, 2, 3}:
...   return a+1
...
>>> signature(foo)
 {1, 2, 3}>
>>>

Paul
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/RN6WYZIOO6RFV3Y4LMM5AH5QSHHNBJS4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] New attribute __convert__ for classes

[artem6191]

This attribute will use for convertion classes to other types, i.e. 
int(MyClass) will return __convert__ result in MyClass

Example:
class MyClass:
   def __init__(self, numer: int):
  self.number = number
   def __convert__(self, type):
  assert type == int # Only integer is allowed
  return self.number*5 # Example

test = MyClass(1)
test_2 = MyClass(5)

print( int(test) ) # 5
print( int(test2) ) # 25
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/IOJVYBX2PXGBMJ4G4TJQ5APIQHHKSXND/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: approximate equality operator ("PEP 485 follow-up")

[Chris Angelico]

On Sun, Jun 14, 2020 at 10:41 PM Sebastian M. Ernst
 wrote:
>
> Hi all,
>
> after just having typed tons of `math.isclose` (see PEP 485 [1]) and
> `numpy.isclose` calls (while basically using their default tolerances
> most of the time), I was wondering whether it makes sense to add a
> matching operator.
>

-1. I don't see that Python needs a different comparison operator,
with all the debates that will come through about "when should I use
== and when should I use the other". Especially since it'll almost
certainly refuel the argument that you should never compare floats for
equality.

If you're doing a lot with isclose, you can always "from math import
isclose as cl" and use a shorter name. But please don't encourage
everyone to use isclose() in place of all comparisons.

ChrisA
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/A7EODHQB5O637RMUGLVCSX6VLRXGYYNU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: await outside async function could map to asyncio.run ?

[Chris Angelico]

On Sun, Jun 14, 2020 at 10:38 PM J. Pic  wrote:
>
> Well correct me if I'm wrong (I did a bit of homework), but threads are hard 
> to get right because they may switch at any time.
>
> When we do async instead of threads, it's because we want task switch on 
> blocking operations only.
>

That's an oversimplification, but yes. If you have code like this:

limit = 10
def spam(some,stuff):
global limit
if limit:
limit -= 1
spam(more,stuff)

then yes, you are extremely at risk of multiple threads messing you
up, because between "if limit" and "limit -= 1", another thread could
run the same code. Doing the same thing with an async function and
"await spam(more,stuff)" wouldn't have this risk, because you know for
sure that there can be no context switch outside of that "await"
keyword.

But the problem here isn't threads. The problem is mutable globals,
and not having any sort of lock to keep it safe. Threads aren't
inherently dangerous in the sense that everything will suddenly break
the instant you create a second thread; what happens is that
vulnerable code can work in a single-threaded situation without ever
being triggered.

So async/await is easier to get right because it behaves like
single-threaded code but with well-defined context switches, but
multi-threaded code isn't THAT hard to get right.

Both async/await and Python threads are vulnerable to the problem that
a *spinning* thread will prevent other tasks from running, but with
async/await, ANY big job will block, whereas with threads, it has to
be something keeping the CPU busy while holding the GIL. So threads
are safer against that sort of thing, while being vulnerable to a
different sort of thing (a thing which, IMO, is a coding error
anyway).

ChrisA
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/HW4WGOEA7C6VMKRN36UV2TGOA2MQYNGE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: approximate equality operator ("PEP 485 follow-up")

[Greg Ewing]

On 15/06/20 12:39 am, Sebastian M. Ernst wrote:

It's such a common problem when dealing with floating point numbers


Is it really? I've done quite a lot of work with floating
point numbers, and I've very rarely needed to compare two
of them for almost-equality. When I do, I always want to
be in control of the tolerance rather than have a default
tolerance provided for me.

I'm inclined to suspect that if you think you need
something like this, you're using an unreliable algorithm.

--
Greg
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/DUAAHLPG27HAYGOG765NP3N37HEKYQWT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: approximate equality operator ("PEP 485 follow-up")

[Alex Hall]

On Sun, Jun 14, 2020 at 3:14 PM Sebastian M. Ernst 
wrote:

>
> Am 14.06.20 um 14:56 schrieb Alex Hall:
> > It would help a lot if you could show some examples.
>
> There you go:
>
> > ```python
> >
> > import math
> > a = 1.01
> > b = 0.99
> >
> > print( a == b ) # prints "False"
> > print( math.isclose(a, b) ) # prints "True"
> >
> > class demo(float):
> > # this could actually become `__ce__` or similar:
> > def __mod__(self, other: float) -> bool:
> > return math.isclose(self, other)
> >
> > ad = demo(a)
> > bd = demo(b)
> >
> > print( ad == bd ) # prints "False" as before
> >
> > # this could actually become `ad ~= bd` or similar:
> > print( ad % bd ) # prints "True"
> >
> > ```
>
> I hope this helps.
>

No, I mean show the difference in readability in real code with real logic,
or close to real. Show us the tests you refactored in two versions: with
math.isclose, and with `~=`.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/BGSMSXNQBSGVL7STGDBLI2CNNYQTP7EA/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: approximate equality operator ("PEP 485 follow-up")

[Wes Turner]

https://en.wikipedia.org/wiki/List_of_mathematical_symbols#Symbols_based_on_equality

https://en.wikipedia.org/wiki/Tilde#As_a_relational_operator

- https://patsy.readthedocs.io/en/latest/formulas.html


https://docs.python.org/3/reference/expressions.html#index-61

> The unary ~ (invert) operator yields the bitwise inversion of its integer
argument. The bitwise inversion of x is defined as -(x+1). It only applies
to integral numbers.

https://numpy.org/doc/stable/reference/generated/numpy.allclose.html

>  If the following equation is element-wise True, then allclose returns
True.
>
> absolute(a - b) <= (atol + rtol * absolute(b))
>
> The above equation is not symmetric in a and b, so that allclose(a, b)
might be different from allclose(b, a) in some rare cases.
>
> The comparison of a and b uses standard broadcasting, which means that a
and b need not have the same shape in order for allclose(a, b) to evaluate
to True. The same is true for equal but not array_equal.

Presumably, tensor comparisons have different broadcasting rules but
allclosr is similarly defined.


> “Euclid’s first common notion is this,” says Lincoln in the film, “Things
which are equal to the same thing are equal to each other. That’s a rule of
mathematical reasoning. It’s true because it works. Has done and always
will do. In his book, Euclid says this is ‘self-evident.’ You see, there it
is, even in that 2,000-year-old book of mechanical law. It is a
self-evident truth that things which are equal to the same thing are equal
to each other.”

On Sun, Jun 14, 2020, 8:43 AM Sebastian M. Ernst 
wrote:

> Hi all,
>
> after just having typed tons of `math.isclose` (see PEP 485 [1]) and
> `numpy.isclose` calls (while basically using their default tolerances
> most of the time), I was wondering whether it makes sense to add a
> matching operator.
>
> "Strict" equality check as usual: `a == b`
> "Approximate" equality check:
> -> `a ?= b` (similar to `!=`)
> -> `a ~= b` (my preference)
> -> `a === b` (just to confuse the JS crowd)
>
> A corresponding method could for instance be named `__ic__` (Is Close),
> `__ae__` (Approximate Equal) or `__ce__` (Close Equal).
>
> It's such a common problem when dealing with floating point numbers or
> similar data types (arrays of floats, float-based geometries etc). An
> operator of this kind would make many people's lives much easier, I bet.
> I have overloaded the modulo operator in some test code and it actually
> helps a lot to make some logic more readable.
>
> Best regards,
> Sebastian
>
>
> 1: https://www.python.org/dev/peps/pep-0485/
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/KD45D5JKJS72PF7NRHC4MMQQEOB7MLRX/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/WMRW3PGCO2KLWVWMDNF7KU5Z6DZDQ5NF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: approximate equality operator ("PEP 485 follow-up")

[Sebastian M. Ernst]

Am 14.06.20 um 14:56 schrieb Alex Hall:
> It would help a lot if you could show some examples. 

There you go:

> ```python
> 
> import math
> a = 1.01
> b = 0.99
> 
> print( a == b ) # prints "False"
> print( math.isclose(a, b) ) # prints "True"
> 
> class demo(float):
> # this could actually become `__ce__` or similar:
> def __mod__(self, other: float) -> bool:
> return math.isclose(self, other)
> 
> ad = demo(a)
> bd = demo(b)
> 
> print( ad == bd ) # prints "False" as before
> 
> # this could actually become `ad ~= bd` or similar:
> print( ad % bd ) # prints "True"
> 
> ```

I hope this helps.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/6HM6YBG2KVFQ2CTICA2KV2J2BCHAVY7V/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: approximate equality operator ("PEP 485 follow-up")

[Alex Hall]

On Sun, Jun 14, 2020 at 2:44 PM Sebastian M. Ernst 
wrote:

> I have overloaded the modulo operator in some test code and it actually
> helps a lot to make some logic more readable.
>

It would help a lot if you could show some examples.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/G6T5POWP5Q76QFZM56ZMVYJOIB6VX4VT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: await outside async function could map to asyncio.run ?

[J. Pic]

> This proposal would elevate it to a very special status,
making it effectively part of the language rather than just a module
in the stdlib.

Indeed, thank you Greg for the clarification
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/JKQISKYWFRIR42RNMYZV32JIHMWCCNF6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] approximate equality operator ("PEP 485 follow-up")

[Sebastian M. Ernst]

Hi all,

after just having typed tons of `math.isclose` (see PEP 485 [1]) and
`numpy.isclose` calls (while basically using their default tolerances
most of the time), I was wondering whether it makes sense to add a
matching operator.

"Strict" equality check as usual: `a == b`
"Approximate" equality check:
-> `a ?= b` (similar to `!=`)
-> `a ~= b` (my preference)
-> `a === b` (just to confuse the JS crowd)

A corresponding method could for instance be named `__ic__` (Is Close),
`__ae__` (Approximate Equal) or `__ce__` (Close Equal).

It's such a common problem when dealing with floating point numbers or
similar data types (arrays of floats, float-based geometries etc). An
operator of this kind would make many people's lives much easier, I bet.
I have overloaded the modulo operator in some test code and it actually
helps a lot to make some logic more readable.

Best regards,
Sebastian


1: https://www.python.org/dev/peps/pep-0485/
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/KD45D5JKJS72PF7NRHC4MMQQEOB7MLRX/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: await outside async function could map to asyncio.run ?

[J. Pic]

Well correct me if I'm wrong (I did a bit of homework), but threads are
hard to get right because they may switch at any time.

When we do async instead of threads, it's because we want task switch on
blocking operations only.

The thing that is still not quite clear to me, and really I must apologize
because I know you kind people have gone through quite some effort to
clarify this for me, and I'm feeling pretty bad enough about it, I don't
want to be the vampire of the list, I welcome all criticism on my behaviour
even off list, as some of you know, I'm just a script-kiddie that became a
script-daddy (don't worry I'm not going to apologize all the time, at least
now it's done for this list !), anyway, given that:

- a blocking call is caused by sleeps and io,
- we want blocking calls to cause a task switch,
- await serves to signal the coder of a potential task switch.

A coder *should* know if a function is going to do a sleep or a blocking
call, if i'm calling git.push() for example, there's definitely going to be
some subprocess, networking, fs work etc. As such, I feel like I'm
*already* supposed to know that this implies blocking calls, and that a
task switch may occur if calling git.push() in an async job, otherwise
would I really be doing a good job at being a developer ?

Some have said that sending people who don't get so much satisfaction
(getting some, but not "so much") writing async code to just use threading,
wouldn't gevent be the closest alternative to suggest ?

Thanks a heap for all your replies and for keeping the list open,

Have a great Sunday ;)
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/3V3YZFIZX3QKONBFR3VMZY6LZLPWP543/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Operator ">" for functions

[Chris Angelico]

On Sun, Jun 14, 2020 at 5:18 PM Stephen J. Turnbull
 wrote:
>
> Paul Moore writes:
>
>  > Personally, I find the version I wrote, that works in existing
>  > versions of Python, much more readable than your version, so you;d
>  > have a hard time persuading me that the new syntax is worth it :-)
>
> I think it's an interesting idea, although I'm with Alex on the color
> of the bikeshed.  Using Alex's 'in' and sets instead of sequences,
> consider
>
> def food() in {2}:
> return 2
>
> def bar(n in {1, 2, 3}):
> pass
>
> def main():
> bar(food())# Paul doesn't think it tastes so great. :-)
>
> That could be checked by MyPy, without global dataflow analysis.
>
> Maybe
>
> def foo() -> {1, 2, 3}:
> return 2
>
> is more readable, and probably just as implementable.
>

This definitely looks like a job for type hints, not new syntax. What
you're asking for here is that something be one of a specific set of
options, and that's really sounding like an enumeration to me.
Consider:

from enum import IntEnum

class Spam(IntEnum):
foo = 1
bar = 2
quux = 3

def some_function(a: IntEnum, b):
print("Got a:", a)

some_function(1, 2)
some_function(4, 2)

Unfortunately, MyPy (tested with version 0.78) doesn't accept integers
as valid parameters when IntEnum is expected, so this can't be done
seamlessly. But if you're doing something like this, you probably
should be working with the enum for other reasons anyway, so your code
would be more like this:

some_function(Spam.foo, 2)
some_function(..., 2)

and right there you can see that there's no way to get a Spam with a
value of 4. If you actually need to do it dynamically, you can do a
runtime cast:

some_function(Spam(1), 2)
some_function(Spam(4), 2)

And then you get the runtime ValueError like you were wanting.

ChrisA
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/RHLAEXZCEKRWQOA4VPY52QWQA7UKRVO5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Operator ">" for functions

[Stephen J. Turnbull]

Paul Moore writes:

 > Personally, I find the version I wrote, that works in existing
 > versions of Python, much more readable than your version, so you;d
 > have a hard time persuading me that the new syntax is worth it :-)

I think it's an interesting idea, although I'm with Alex on the color
of the bikeshed.  Using Alex's 'in' and sets instead of sequences,
consider

def food() in {2}:
return 2

def bar(n in {1, 2, 3}):
pass

def main():
bar(food())# Paul doesn't think it tastes so great. :-)

That could be checked by MyPy, without global dataflow analysis.

Maybe

def foo() -> {1, 2, 3}:
return 2

is more readable, and probably just as implementable.

Steve
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/TGSWHQ3PYT5MJ4Z2Q2FPWXYDW5JXYDPB/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Bringing the print statement back

[Stephen J. Turnbull]

Greg Ewing writes:

 > If the latter, I can imagine some creative abuses as people
 > contrive for their favourite function of the moment to be called
 > 'print' so that they can call it without parens...

+1 on creative abuse!  At least in David Beazley lectures. ;-)

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/2JVM4LAVISJXEK7HACTFLSDEPWOWJZCY/
Code of Conduct: http://python.org/psf/codeofconduct/