On Feb 3, 2020, at 21:14, Random832 wrote:
>
> If we are going to have a general binary operator mechanism, maybe it should
> be something more haskell-like,
That’s exactly what I suggested—but more to argue that we don’t want a general
binary operator mechanism at all. (The right way to do
On Mon, Feb 3, 2020 at 3:58 AM Richard Damon
wrote:
>
> IF Python had a proper refactoring tool (see my other message where I
> question the ability to do that) then the nameof operator would clearly
> help keep logging/debug strings in line with the program definitions.
>
> A statement like
On Sun, Feb 2, 2020, at 11:41, MRAB wrote:
> On 2020-02-02 15:00, Karl Ramm wrote:
> > We have all shared in the observation that all but the most carefully
> > considered operator overloading tends to reduce code readability. There
> > also many programmers that feel that they need it to make
I’ve always resisted changing this, but it keeps coming up, and in other
cases we don’t restrict the grammar (except when there are real
ambiguities). So maybe the SC can accept a PRP for this?
On Mon, Feb 3, 2020 at 15:47 Ben Avrahami wrote:
> Hi all, decorators are a very powerful feature in
Hi all, decorators are a very powerful feature in python, but it's syntax
is strangely restrictive.
decorator ::= "@" dotted_name ["(" [argument_list [","]] ")"] NEWLINE
for 99% of cases this is not a hindrance, but sometimes we'd rather be able
to use full expression syntax. consider the
Sincerely I would have to agree that it's seems a bit excessive the
`cancel_on_error`, unless it enabled by default and implemented in the abstract
class it should probably not be included, that was just an idea to keep
backwards compatibility.
I will personally simply add subclass of my
On Feb 3, 2020, at 10:25, Andrew Barnert wrote:
>
> This is the same as Smalltalk, ObjC, Ruby, f-script, and all of the other
> languages that use the same dynamic type/data model as Python. And Smalltalk
> was the first language to have practical refactoring tools (although I don’t
> think
On Feb 3, 2020, at 03:59, Richard Damon wrote:
>
> On 2/3/20 12:02 AM, Bruce Leban wrote:
>> People keep mentioning refactoring. It's a red herring.
>>
>> No refactoring tool needs a nameof operator added to the language in order
>> to do its job. And certainly an operator that requires
To restate the motivation: the hope is that there is a potentially large
benefit of being able to more easily refactor code with something like a
nameof().
I am going to make the claim that:
1. this benefit is actually minimal and does not address a lot of other
existing refactoring
Thanks for all your hard work on the `cancel_futures` feature!
As you said, there is a complexity cost (both in terms of the API and the
implementation) whenever a new feature is added. The current
ProcessPoolExecutor implementation, in particular, is complex enough that I
can't easily easily
> But, it would potentially risk adding an underutilized parameter to the
> executor constructor (which contributes to feature bloat).
That's true, personally I would always enable cancel_on_error (making it
redundant and implementing it in the abstract class), but that's just my use
case. You
Why don't you define a LOCALIZE function (x → x) like in your C example?
Le lun. 3 févr. 2020 à 13:01, Soni L. a écrit :
>
>
>
> On 2020-02-02 11:29 p.m., Eric V. Smith wrote:
> > On 2/2/2020 8:28 PM, Soni L. wrote:
> >> It'd be cool to attach metadata to string literals that doesn't end
> >> up
On 2020-02-02 11:29 p.m., Eric V. Smith wrote:
On 2/2/2020 8:28 PM, Soni L. wrote:
It'd be cool to attach metadata to string literals that doesn't end
up in the resulting string object. This metadata could be used by all
sorts of tools, everything from localization to refactoring.
In C,
On 2/3/20 12:02 AM, Bruce Leban wrote:
People keep mentioning refactoring. It's a red herring.
No refactoring tool needs a nameof operator added to the language in
order to do its job. And certainly an operator that requires running
the program in order to use it is not going to be helpful.
> Then if Executor.__exit__ detects an exception it would call shutdown
with cancel_futures set to True.
Oh, I see. That should be rather simple:
```
def __exit__(self, exc_type, exc_val, exc_tb):
if exc_val is not None and self._cancel_on_error:
self.shutdown(wait=True,
> Hmm, it should be possible. Do you specifically mean cancelling the pending
> futures once a single one of the submitted functions raises an exception,
> or cancelling the pending futures when the Executor itself raises an
> exception (I.E. BrokenProcessPool)? I would assume the prior, since
Miguel Ángel Prosper wrote:
> Thank you so much for the work, I was very confused on how to even start
implementing it in the ProcessPoolExecutor, but you finished everything
super quick!
No problem! The ProcessPoolExecutor implementation wasn't immediately clear
to me either, but after some
Hi, I thought maybe a callback before the worker of a Executor finishes would
be helpful. It would allow the setup and teardown resources (such as file,
databases, connections, ...) across workers. My particular use case is for
closing down requests.Session objects, that currently its very
18 matches
Mail list logo
