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

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] Re: Operator ">" for functions

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

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

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

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

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 apolog

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

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" equalit

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

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

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

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

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

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): > # thi

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

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

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

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

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

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

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

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 a

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

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 op

[Python-ideas] New attribute __convert__ for classes

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

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

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 (exten

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

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

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

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

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

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 __c

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

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

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

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

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

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

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

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

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

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

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

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 refcoun

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

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

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

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

[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

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

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

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

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 ch

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

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

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

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

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

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

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

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 syn

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

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

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

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 m

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

On 15/06/20 5:11 pm, Steve Barnes wrote: 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. Or we could use floating-point reference counts... -- Greg ___

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

On Mon, Jun 15, 2020 at 06:22:34PM +1200, Greg Ewing wrote: > On 15/06/20 5:11 pm, Steve Barnes wrote: > > >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. > > Or we could use floa