This is a response in part to Thomas Güttler's "Pre PEP: Python Literals"
but I am starting a separate thread because I think it deserves separate
discussion, and it's not a direct response to that proposal.
Here's the problem: we want to allow escaping in strings to prevent
injection in HTML, SQL
Stephen J. Turnbull wrote:
> But a
> PEP 501 i-string "just works" nicely:
> load_warning = i'Load is too high: {load}'
> while (theres_work_to_do_matey):
> if load > max_load:
> logging.warn(load_warning)
> (This assumes a future version of logging.warn that calls str() on
On 6/26/21 1:55 PM, Marc-Andre Lemburg wrote:
> On 26.06.2021 21:32, Ethan Furman wrote:
>> In most cases I would agree with you, but in this case the object is security
>> sensitive, and security should be much more rigorous in ensuring correctness.
>
> Isn't this more an issue of API design rat
I'd prefer a frozen dataclass with an explicit replace method
On Sat, 26 Jun 2021, 21:56 Marc-Andre Lemburg, wrote:
> On 26.06.2021 21:32, Ethan Furman wrote:
> > On 6/25/21 5:20 PM, Eric V. Smith wrote:
> >
> >> It seems like many of the suggestions are SSLContext specific. I don't
> think
> >
On 26.06.2021 21:32, Ethan Furman wrote:
> On 6/25/21 5:20 PM, Eric V. Smith wrote:
>
>> It seems like many of the suggestions are SSLContext specific. I don't think
> we should be adding
>> __slots__ or otherwise redefining the interface to that object. Isn't this a
> general "problem" in
>> pyth
> On Jun 26, 2021, at 3:35 PM, Ethan Furman wrote:
>
> [oops, hit Send too soon]
>
> On 6/25/21 5:20 PM, Eric V. Smith wrote:
>
> > It seems like many of the suggestions are SSLContext specific. I don't
> > think we should be adding
> > __slots__ or otherwise redefining the interface to that
[oops, hit Send too soon]
On 6/25/21 5:20 PM, Eric V. Smith wrote:
> It seems like many of the suggestions are SSLContext specific. I don't think
we should be adding
> __slots__ or otherwise redefining the interface to that object. Isn't this a general
"problem" in
> python...
In most cases I
On 6/25/21 5:20 PM, Eric V. Smith wrote:
> It seems like many of the suggestions are SSLContext specific. I don't think
we should be adding
> __slots__ or otherwise redefining the interface to that object. Isn't this a general
"problem" in
> python...
___
Thank you Thomas, that's helpful. Though I really like the future
interface, I've used it many times while I never used
`multiprocessing.pool.Pool` or its `AsyncResult`. I worry that some of the
expectations I've grown to have from `Future` objects would be broken here.
It would be nice if this fe
Thank you, that's helpful. Though I really like the future interface, I've
used it many times while I never used `multiprocessing.pool.Pool` or its
`AsyncResult`. I worry that some of the expectations I've grown to have
from `Future` objects would be broken here.
It would be nice if this feature e
Nice to see you on the list also, Santiago.
The generator is my impression of what is most useful. But someone else
might opine differently, of course.
On Sat, Jun 26, 2021, 1:50 PM wrote:
> Hey David, great to find you here!!
>
> I really like what you're proposing. I could make it a generator
Hey David, great to find you here!!
I really like what you're proposing. I could make it a generator instead of
returning a list. I returned a list because wait returns sets and I thought I
would keep returning collections. I'll play around and send a new proposal.
__
This seems useful to me. But I think it would be better if made more
eager. Let's say you have tasks A, B, C, D, E to process.
If they complete in order E, D, C, B, A then of course you can't do any
in-order processing until they've all completed.
But what if they finish in order A, B, E, D, C.
On Sat, Jun 26, 2021 at 11:59 AM Ram Rachum wrote:
> Do you think it's worthwhile to add this feature to `ProcessPoolExecutor`?
>
*restart_workers* certainly seems worth further investigation and
consideration. However, you may also be able to find a workaround using the
*initialzer* argument f
And it's on Python stdlib 3
https://docs.python.org/3/library/multiprocessing.html#multiprocessing.pool.Pool
On Sat, 26 Jun 2021, 17:24 Thomas Grainger, wrote:
> billiard a multiprocessing py2 fork/backport has
> https://billiard.readthedocs.io/en/latest/library/multiprocessing.html#multiprocess
billiard a multiprocessing py2 fork/backport has
https://billiard.readthedocs.io/en/latest/library/multiprocessing.html#multiprocessing.pool.multiprocessing.Pool
with maxtasksperchild
On Sat, 26 Jun 2021, 16:57 Ram Rachum, wrote:
> Hi guys,
>
> I want to have a version of `concurrent.futures.Pro
Hi guys,
I want to have a version of `concurrent.futures.ProcessPoolExecutor` in
which every worker process shuts down after each task. I want this because
I believe I have a memory leak in my program that I wasn't able to fix.
(Possibly it's in C extensions that I use.)
Since I'm going to use a
Hello list, it's my first email here, so let me know if this is in any way out
of order.
I've been working a lot with concurrent.futures lately. I find both `wait` and
`as_completed` very useful, but something I'm usually lacking is a `wait`
version where the order of the futures is preserved.
18 matches
Mail list logo
