On Tue, Feb 11, 2020 at 07:10:18PM -, jdve...@gmail.com wrote:
> I have been taught that assertions must not produce side effects at all.
That's good practice, but saying that they "must not" is too strong.
The risk here is not the side-effect, but relying on that side-effect
(which may be
Hi,
I would like if the DictWriter would be able to write escape characters (\n and
\r and their combinations such as \n\n\n and \r\n) as literal characters.
At the moment, DictWriter writes \n:s as new lines (shown in notepad or Excel)
and I would like it to just write "\n" characters in my csv
On 02/11/2020 01:49 PM, Steven D'Aprano wrote:
Oh, definitely for the best. This now allows us to write complex
assertions much more easily and efficiently:
assert log(flag := complex_expression) or flag
That doesn't seem very useful: for that assert to fail, `flag` would have to be
fal
On 12/02/2020 08:15, allu.matikai...@hotmail.com wrote:
Hi,
I would like if the DictWriter would be able to write escape characters (\n and
\r and their combinations such as \n\n\n and \r\n) as literal characters.
At the moment, DictWriter writes \n:s as new lines (shown in notepad or Excel) and
> assert log(flag := complex_expression) or flag
>
> That doesn't seem very useful: for that assert to fail, `flag` would have
> to be falsey, and if falsey, then surely the log of it is not helpful?
Unless complex_expression produces an object that has useful information
when Falsey.
But
On Thu, Feb 13, 2020 at 1:50 AM Ethan Furman wrote:
>
> On 02/11/2020 01:49 PM, Steven D'Aprano wrote:
>
> > Oh, definitely for the best. This now allows us to write complex
> > assertions much more easily and efficiently:
> >
> > assert log(flag := complex_expression) or flag
>
> That doesn'
On Feb 12, 2020, at 06:11, allu.matikai...@hotmail.com wrote:
>
> I would like if the DictWriter would be able to write escape characters (\n
> and \r and their combinations such as \n\n\n and \r\n) as literal characters.
I don’t think you’re asking to write escape sequences, but how to write a
On Feb 12, 2020, at 06:49, Ethan Furman wrote:
>
> On 02/11/2020 01:49 PM, Steven D'Aprano wrote:
>
>> Oh, definitely for the best. This now allows us to write complex
>> assertions much more easily and efficiently:
>> assert log(flag := complex_expression) or flag
>
> That doesn't seem ve
On 02/12/2020 10:00 AM, Andrew Barnert wrote:
On Feb 12, 2020, at 06:49, Ethan Furman wrote:
On 02/11/2020 01:49 PM, Steven D'Aprano wrote:
Oh, definitely for the best. This now allows us to write complex
assertions much more easily and efficiently:
assert log(flag := complex_expressio
Currently asyncio.futures.Future.set_result will result in any callbacks
being scheduled using loop.call_soon instead of
loop.call_soon_threadsafe. However in situations where the future's
result is set from a different thread, the loop might not wake up as a
result of this if it is currently sleep
Sharing futures between threads like that goes counter to asyncio's basic
philosophy (which is not to use threads :-).
You already showed the solution:
future._loop.call_soon_threadsafe(future.set_result, ...). If that's
unacceptable for you, maybe you can wrap the future in a wrapper class that
c
11 matches
Mail list logo
