[Python-ideas] Re: Multi-threading interface idea

I'm not sure I get the benefits of this. You can write the same thing even more simply by directly using `ThreadPoolExecutor`. You don't even need `as_completed` as in your `concurrent_future_example`, because you don't want any of the values as they're completed, you only want them after

[Python-ideas] Re: Multi-threading interface idea

This looks like a very nice library to put on PyPI. But it's not an idea for change to the Python language itself, so probably this is the wrong forum. Python-list is closer. ... if it is a suggestion to change the standard library itself, I'm -1 on the idea. On Sat, Feb 8, 2020 at 6:11 PM Sean

[Python-ideas] Re: statement-scoped context managers

On Sat, Feb 8, 2020, at 18:06, Random832 wrote: > My own expectation, for what it's worth, would be something like [snip] After thinking about it some more, I realized that my idea can basically be translated to "all with-expressions in the statement get added to an implicit ExitStack, which is

[Python-ideas] Multi-threading interface idea

Hi folks, I'd like to get some feedback on a multi-threading interface I've been thinking about and using for the past year or so. I won't bury the lede, see my approach here . *Background / problem:* A

[Python-ideas] Re: statement-scoped context managers

On Sat, Feb 8, 2020, at 17:14, Soni L. wrote: > On 2020-02-08 6:53 p.m., Bruce Leban wrote: > > On Sat, Feb 8, 2020 at 1:22 PM Chris Angelico wrote: > >> Exactly how much code would be wrapped in the 'with' block? > > > > This is an intriguing idea, and in the example it's fairly easy to wrap

[Python-ideas] Re: statement-scoped context managers

On 2020-02-08 6:53 p.m., Bruce Leban wrote: On Sat, Feb 8, 2020 at 1:22 PM Chris Angelico > wrote: On Sun, Feb 9, 2020 at 8:04 AM Random832 mailto:random...@fastmail.com>> wrote: > > On Fri, Feb 7, 2020, at 13:03, Todd wrote: > What if you could

[Python-ideas] Re: statement-scoped context managers (was: Re: Pickle to/from filename or path)

On Sat, Feb 8, 2020 at 1:22 PM Chris Angelico wrote: > On Sun, Feb 9, 2020 at 8:04 AM Random832 wrote: > > > > On Fri, Feb 7, 2020, at 13:03, Todd wrote: > > > What if you could write pickle.dump(myobj, with open('myfile.p', 'wb'))? > > > > Or other similar examples such as (with

[Python-ideas] Re: statement-scoped context managers (was: Re: Pickle to/from filename or path)

On Feb 8, 2020, at 13:25, Chris Angelico wrote: > > On Sun, Feb 9, 2020 at 8:04 AM Random832 wrote: >> >>> On Fri, Feb 7, 2020, at 13:03, Todd wrote: >>> approaches like opening within the dump or load, which the wiki >>> still recommends [1]. >>> >>> So something like: >>> >>> with

[Python-ideas] Re: statement-scoped context managers (was: Re: Pickle to/from filename or path)

On Sun, Feb 9, 2020 at 8:04 AM Random832 wrote: > > On Fri, Feb 7, 2020, at 13:03, Todd wrote: > > approaches like opening within the dump or load, which the wiki > > still recommends [1]. > > > > So something like: > > > > with open('myfile.p', 'wb') as f: > > pickle.dump(myobj, f) > > > >

[Python-ideas] statement-scoped context managers (was: Re: Pickle to/from filename or path)

On Fri, Feb 7, 2020, at 13:03, Todd wrote: > approaches like opening within the dump or load, which the wiki > still recommends [1]. > > So something like: > > with open('myfile.p', 'wb') as f: > pickle.dump(myobj, f) > > Would be: > > pickle.dump(myobj, 'myfile.p') What if you could write

[Python-ideas] Re: pickle.reduce and deconstruct

On Fri, Feb 7, 2020 at 1:51 PM Andrew Barnert wrote: > Not to argue against my own proposal here, but…i was only suggesting > exposing the reduction machinery, and I think you also need the > graph-walking machinery exposed. Or would my existing proposal on its own > actually be enough for you?

[Python-ideas] Re: `raise as` to raise with current exception as cause

On Sat, Feb 8, 2020 at 12:27 PM Paul Moore wrote: > > So I'd be hesitant about calling exception chaining a failure (like > the OP, not Steven, did) for a while yet. And even then, I would't > call it a failure, just a relatively niche feature that is helpful in > some uncommon cases. > I

[Python-ideas] Re: `raise as` to raise with current exception as cause

On 2/7/2020 11:08 PM, Andrew Barnert via Python-ideas wrote: On Feb 7, 2020, at 16:11, Steven D'Aprano wrote: Shai Berger wants to set it implicily, based on where the raise is. If it is "directly" under the except line, implicitly set the cause. It seems like a truly bad idea to change the

[Python-ideas] Re: `raise as` to raise with current exception as cause

On Fri, 7 Feb 2020 at 23:14, Steven D'Aprano wrote: > YMMV and this is just my opinion, but personally I think that exception > chaining is rarely useful even at the best of times. For me, the only > time I care about "raise from" is to suppress exception chaining by > setting the cause to None.