Jack DeVries writes:
> What does everyone think? Can we add these two items to the .gitignore:
>
> - `.cache`
> - `compile_commands.json`
I don't see any cost to this -- .cache is uncomfortably generic, but
given the semantics of "cache" gitignoring it seems a good idea.
ISTM rather than ha
Hi All,
I use clangd. Clangd creates a .cache directory, and there are also
tools for generating a compile_commands.json file which tells clangd how
to behave. I did a quick check, and there are no naming collisions with
other files in the cpython project.
What does everyone think? Can we add the
Oh, I like that. It does feel like a property of the variable. (But can you
efficiently enumerate all context vars when creating a thread?)
I imagine that thread pools add some complication, because you don’t want
to inherit these accidentally between tasks run by the same worker.
On Thu, Aug 19,
On Thu, Aug 19, 2021 at 8:43 AM Guido van Rossum wrote:
> Perhaps we need a library for creating/managing threads that inherits all
> current context values?
>
Or is it a "kind of context variable that is shared among threads?" That
was more the direction my mind was going.
Context variables th
asyncio.to_thread creates threads that inherit the current context, according
to https://www.python.org/dev/peps/pep-0567/#rationale the decimal module
should use contextvars for this too
___
Python-ideas mailing list -- python-ideas@python.org
To unsub
Perhaps we need a library for creating/managing threads that inherits all
current context values?
On Thu, Aug 19, 2021 at 7:48 AM Paul Prescod wrote:
> There are certain values that are managed independent of any specific
> code-accessible object. The decimal precision is a good example:
>
> htt
There are certain values that are managed independent of any specific
code-accessible object. The decimal precision is a good example:
https://docs.python.org/3/library/decimal.html
We can call these context variables. As your code shows, the true "home" of the
"prec" value is not some object y
Matsuoka Takuo writes:
> >>> *(1,2),
> (1, 2)
Yes, this works, and now that I see you just want that to work in
"a[*(1,2),]", I agree, I don't know why that is a syntax error. This
works, of course:
t = *(1,2),
a[t]
(in the sense that if a is a sequence you get a TypeError because th
Thomas Grainger writes:
> Would a work stealing approach work better for you here? Then the only
> signalling overhead would be when a core runs out of work
Not sure what you're talking about with "work stealing". It sounds
conceptually more complex than the queue + worker pool approach,
which
On Thu, Aug 19, 2021 at 11:27 PM Matsuoka Takuo wrote:
>
> Dear Steve,
>
> Thank you for your detailed explanation.
>
> > > (i.e., it can be mistyped as "s[1,2,]" but without SyntaxError this
> > > time). It would at least be consistent if we got SyntaxError in
> > > both cases (namely, the syn
Dear Steve,
Thank you for your detailed explanation.
> > (i.e., it can be mistyped as "s[1,2,]" but without SyntaxError this
> > time). It would at least be consistent if we got SyntaxError in
> > both cases (namely, the syntax allowed only a single Python
> > expression here), but if we don'
11 matches
Mail list logo
