[Python-ideas] Re: SerialExecutor for concurrent.futures + Convenience constructor

I opened a bpo issue to expand upon the public API for cf.Future: https://bugs.python.org/issue39645. Any feedback would be greatly appreciated. (: On Sun, Feb 16, 2020 at 12:22 AM Guido van Rossum wrote: > > > On Sat, Feb 15, 2020 at 21:00 Kyle Stanley wrote: > >> > I've never felt the need

[Python-ideas] Re: SerialExecutor for concurrent.futures + Convenience constructor

This seems to be two separate proposals: 1) Add a new way to create and specify executor 2) Add a SerialExecutor, which does not use threads or processes So, I'll respond to each one separately. *Add a new way to create and specify executor* Jonathan Crall wrote: > The library's

[Python-ideas] Re: SerialExecutor for concurrent.futures + Convenience constructor

> I've never felt the need for either of these myself, nor have I observed it in others I worked with. In general I feel the difference between processes and threads is so large that I can't believe a realistic application would work with either. Also, ThreadPoolExecutor and ProcessPoolExecutor

[Python-ideas] Re: SerialExecutor for concurrent.futures + Convenience constructor

On Sat, Feb 15, 2020 at 21:00 Kyle Stanley wrote: > > I've never felt the need for either of these myself, nor have I observed > it in others I worked with. In general I feel the difference between > processes and threads is so large that I can't believe a realistic > application would work with

[Python-ideas] Re: SerialExecutor for concurrent.futures + Convenience constructor

On Feb 15, 2020, at 20:29, Kyle Stanley wrote: > Add a SerialExecutor, which does not use threads or processes > > Andrew Barnert wrote: > > e.g., in C++, you only use executors via the std::async function, and you > > can just pass a launch option instead of an executor to run synchronously >

[Python-ideas] Re: SerialExecutor for concurrent.futures + Convenience constructor

> No; the point of launch policies is that you can (without needing an executor object[1]) tell the task to run “async” (on its own thread[2]), “deferred” (serially[3] on first demand), or “immediate” (serially right now)[4]. You can even or together multiple policies to let the implementation

[Python-ideas] Re: Traits

On 2020-02-15 10:06 a.m., Paul Moore wrote: On Sat, 15 Feb 2020 at 12:17, Alex Walters wrote: > > Telling someone you are trying to convince to do something to go learn something else to "get on your level" as the youth would put it... is not how you get people to agree with you. > > To

[Python-ideas] Re: Traits

Hi folks, moderator here. I’m calling it for this discussion. No further discussion is called for, IMO, although I’m sure Brett and I would be happy to be overridden by private request. Stephen, thank for providing an excellent summary post on which to lay this thread to rest :) :) best,

[Python-ideas] Global thread executor

Howdy fellows, I had a thought of adding a global thread executor in python. It can use something like concurrent.futures, and be created on demand. There are times when I find myself needing to run just a single function in a thread, cause there's practically no other way. The function is a

[Python-ideas] Re: Traits

The OP's posts all seem to consist of: 1. This other thing is way better 2. I won't explain what it is, but Rust does it better 3. The other folks who have used Rust don't understand it either 4. You are all too dumb to understand this great thing 5. Python should change it's syntax to allow this

[Python-ideas] Re: Traits

All: If you're not interested in the back and forth, read my parallel post with a different subject. Soni L. writes: > I'm just gonna say learn rust since you actively refuse to accept > my explanation of rust traits. don't reply again until you've > learned rust. OK, done. > you don't

[Python-ideas] Re: Traits

On Sat, Feb 15, 2020 at 10:39 PM Soni L. wrote: > > you don't want me to be rude but when I literally explain rust traits > you throw me an "that's not traits and fuck you for being rude/trying to > get me to think". > > I'm just gonna say learn rust since you actively refuse to accept my >

[Python-ideas] Re: Traits

On Sat, 15 Feb 2020 at 12:17, Alex Walters wrote: > > Telling someone you are trying to convince to do something to go learn > something else to "get on your level" as the youth would put it... is not how > you get people to agree with you. > > To summarize this thread, as I see it so far > > *

[Python-ideas] Re: Traits

you don't want me to be rude but when I literally explain rust traits you throw me an "that's not traits and fuck you for being rude/trying to get me to think". I'm just gonna say learn rust since you actively refuse to accept my explanation of rust traits. don't reply again until you've

[Python-ideas] Re: Traits

Soni L. writes: > On 2020-02-14 11:42 p.m., Steven D'Aprano wrote: > > On Fri, Feb 14, 2020 at 07:24:48PM -0300, Soni L. wrote: > I do suggest learning Rust, at least for the traits. That's inappropriate because it's placing responsibility on us to puzzle out what you mean, rather than on you

[Python-ideas] Re: Traits

Telling someone you are trying to convince to do something to go learn something else to "get on your level" as the youth would put it... is not how you get people to agree with you. To summarize this thread, as I see it so far * you asked about adding a feature with the name "traits" to the

[Python-ideas] Why I like the idea of traits [was: Traits]

Executive summary: I'm sorry so many people have not gotten much out of the parent thread. Despite my disagreements with the OP, I find traits to be an interesting concept, and I'll probably try out Simionato's strait library[1]. I agree with several posters that traits neither need nor are

[Python-ideas] Re: Why I like the idea of traits [was: Traits]

It sounds like it would be a useful exercise to design a complete, modern Traits implementation for Python 3 (maybe starting with Simoniato's straits). An extra challenge would be to make it fit in the type system as perceived by PEP-484-based type checkers (mypy, pyre etc.) -- without this it

[Python-ideas] Re: Global thread executor

So there's one reason to put this in the stdlib: so that stdlib modules (like logging.QueueListener which you mentioned) can use it. There should still a backport so that 3rd party packages have a simple way of using this for earlier Python versions. A PEP would be the best way to make progress

[Python-ideas] Re: SerialExecutor for concurrent.futures + Convenience constructor

Having tried my hand at a simpler version for about 15 minutes, I see the reason for the fiddly subclass of Future -- it seems over-engineered because concurrent.future is complicated. I've never felt the need for either of these myself, nor have I observed it in others I worked with. In general

[Python-ideas] SerialExecutor for concurrent.futures + Convenience constructor

I'd like to propose an improvement to `concurrent.futures`. The library's ThreadPoolExecutor and ProcessPoolExecutor are excellent tools, but there is currently no mechanism for configuring which type of executor you want. Also, there is no duck-typed class that behaves like an executor, but does

[Python-ideas] Re: SerialExecutor for concurrent.futures + Convenience constructor

> On Feb 15, 2020, at 13:36, Jonathan Crall wrote: > > Also, there is no duck-typed class that behaves like an executor, but does > its processing in serial. Often times a develop will want to run a task in > parallel, but depending on the environment they may want to disable threading > or

[Python-ideas] Re: Global thread executor

On Feb 15, 2020, at 05:40, Bar Harel wrote: > > If we would have had a global ThreadPoolExecutor, we could have use it > exactly for that. The threads would be shared, the overhead would only occur > once. Users of the executor will know that it's a limited resource that may > be full at

[Python-ideas] Re: Global thread executor

> > The question is, if we added, say, a > concurrent.futures.get_shared_thread_pool_executor function today, would > people change all of the popular libraries to start using it? Probably not, > because then they’d all have to start requiring Python 3.10. In which case > we wouldn’t get the

[Python-ideas] Re: SerialExecutor for concurrent.futures + Convenience constructor

This implementation is a proof-of-concept that I've been using for awhile . Its certain that any version that made it into the stdlib would have to be more carefully designed than the implementation I threw