[Python-ideas] Re: Comparison operator support (>= and <=) for type
On Fri, Jun 14, 2019, 13:49 Brett Cannon wrote: > I think the logic breaks down with multiple inheritance. If you make C(A, B), > then you can say C > A and C > B, but then you can't say A > B or A < B which > breaks sorting. The logic is fine. Classes can be considered as containers of their instances, and that logic is already used with Python's sets. You can even consider intersections and unions of classes (which are already used to express type constraints). That means you can define __contains__ and comparisons for classes, and the logic will be self-consistent. Mathematically, it's just set theory. Regular expression objects can also be considered as computed collections of the strings they match. You can even enumerate these collections. However, the proposed feature will reserve comparison and container operations to the classes-as-instance-containers concept. That means programmers can't use those operators for something else. If they do, their classes will not play nicely with any library that DOES use the feature, even if they themselves don't use the feature. I wonder how many codebases already use comparison and containment in their metaclasses, and how many use them for something OTHER than classes-as-instance-containers. > If you want to know if a B inherits from Base, then I think `Base in B.mro()` > will cover that just as succinctly. And if you need to know position you can > compare indexes into the MRO. Using the MRO directly will ignore virtual subclassing. `issubclass` is the right equivalent. I can't imagine a reason to need to know relative positions in the MRO, except in debugging attribute resolution. ___ 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/HW7COZRQVVAGIMR6VOMAJKW32FDPVNDM/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add «iterate non-blocking» wrapper to prevent blocking loop too long
> On 15 Jun 2019, at 10:55, Gustavo Carneiro wrote: > > > Perhaps. But using threads is more complicated. You have to worry about the > integrity of your data in the face of concurrent threads. And if inside your > task you sometimes need to call async coroutine code, again you need to be > extra careful, you can't just call coroutines from threads directly. I work on a large product that uses the twisted async framework. And I can assure you the data integrity problem exists in async code as well. At least in twisted it is easy enough to deferToThread() a background task that once complete will continue processing on the foreground thread, we do that for heavy file IO tasks. But we offload compute tasks to other processes as using threads in python does not work because of the GIL and we have to meet latency targets. Barry ___ 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/73U3X6I2WRDKUWCHMJ7NKRHOTRZ5XJRC/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add «iterate non-blocking» wrapper to prevent blocking loop too long
On Sat, 15 Jun 2019 at 00:26, Greg Ewing wrote: > Gustavo Carneiro wrote: > > 1. If you don't yield in the for loop body, then you are blocking the > > main loop for 1 second; > > > > 2. If you yield in every iteration, you solved the task switch latency > > problem, but you make the entire program run much slower. > > It sounds to me like asyncio is the wrong tool for this job. You > want a background task that can be preempted by a foreground task. > That's what threads are for. Asyncio gives you non-preemptive > task scheduling. > Perhaps. But using threads is more complicated. You have to worry about the integrity of your data in the face of concurrent threads. And if inside your task you sometimes need to call async coroutine code, again you need to be extra careful, you can't just call coroutines from threads directly. But I think you do have a point. If a developer starts reaching for `await asyncio.sleep(0)` too often, perhaps it is time to start considering running that code in the default thread pool executor, whatever the cost may be. > -- > 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/RLGF5NOLRXYGEOWTLT4N6KYAWRWXHI6J/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- Gustavo J. A. M. Carneiro Gambit Research "The universe is always one step beyond logic." -- Frank Herbert ___ 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/ALN3KUJFODLKP7HZ3SZ3QOOMVT56UC6G/ Code of Conduct: http://python.org/psf/codeofconduct/
