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
I lack the relevant experience to have an opinion on most of this, but FWIW
"PyLong_FromBytes/PyLong_ToBytes' seems clearest to me out of the options
proposed.
On Sat, Aug 7, 2021 at 2:23 PM Serhiy Storchaka wrote:
> Python integers have arbitrary precision. For serialization and
> interpolation
Serhiy Storchaka wrote:
> Are your aware of contextlib.nested()? And why it was deprecated and
> removed?
Was contextlib.nested() removed primarily due to to the inconsistencies
mentioned in https://bugs.python.org/issue5251 or was it something else?
_
Andrew Barnert wrote:
> consume(print(item) for item in lst)
>From my understanding, consume() effectively provides the functionality the
author was looking for. Also, between the options of `for _ in iter:` vs
`colllections.deque(it, maxlen=0)`, how significant is the performance
difference?
I
Eric V. Smith wrote:
> In addition, I find it hard to believe someone couldn't find a sponsor
> for a well-written PEP. I'm happy to sponsor such a PEP, even if I think
> it will be rejected. Rejected PEPs serve a useful purpose, too, if only
> to point to when the same issue comes up in the fut
Steven D'Aprano wrote:
> By the way, you know that Python has a read-only global variable that
> tells you whether you are in debug mode? You can write a function to
> display anything you like, and wrap it in a test like this:
> if __debug__:
> display(locals())
Oh interesting, I wasn't awa
icularly helpful), I could definitely imagine @context being useful.
Speaking of examples, I think it would be helpful to provide a brief
example of ``object.__json__()`` being used for some added clarity. Would
it be a direct alias of ``json.dumps()`` with the same exact parameters and
usage, or would
n and readability in the right situations. The simplicity
is definitely appealing.
Thanks,
Kyle Stanley
On Sat, Aug 17, 2019 at 3:27 AM Andrew Barnert wrote:
> On Aug 16, 2019, at 20:35, Kyle Stanley wrote:
> >
> > Speaking of examples, I think it would be helpful to provide a b
Steven D'Aprano wrote:
> The interpreter should infer that a plain `def` function is actually
an `async def` from the presence of `async yield`, similar to the way
the interpreter infers that a plain `def` function is actually a
generator from the presence of a `yield`.
I would have to strongly di
George Fischoff wrote:
> So when the default is async, the user will get faster program, by
default.
Chris Angelico wrote:
> Okay, well that's the problem. An async function won't yield the
values faster, and it will not allow two things to happen
simultaneously. It just allows I/O and other such
It looks like Serhiy answered your main question, but I wanted to mention
that rather than simply printing the exception, you could also print the
full traceback using the "traceback" module:
>>> import traceback
>>> try:
... 1/0
... except Exception as e:
... traceback.print_exc()
...
Tra
> This supports my point that this ought to be handled once, correctly, in
the standard library, like the other ABCs, instead of leaving it up to
people like me to get it wrong.
It would be pretty reasonable to assume that most users would get
this incorrectly. My first assumption to this problem
> Maybe borrowing a word from a different language—record or datatype or
something—would avoid that problem?
Hmm, I don't think "record" would work. The terms "record", "struct", and
"tuple" are far too synonymous with one another (
https://en.wikipedia.org/wiki/Record_(computer_science)). This te
> That said, though, I'm not sure that this was even what you were asking
about :)
It would be significantly more helpful if the OP had an example for the
specific case where they wanted contextually defined variables to take
priority over the classdict, and explained _why_ this behavior might be
is
type of syntax would be with a linter rather than directly preventing its
usage.
(resent because the CC address was incorrect)
On Sun, Nov 17, 2019 at 6:01 AM Kyle Stanley wrote:
> > Some people find this legal syntax confusing:
>
> > A in B < C
>
> I agree, that syntax
> Please recall that chained comparisons such are
> >>> A < B < C
> is to produce simple code when B is not an identifier, but an expression.
For example
> >>> low < len(x) < high
> or
> >>> inner ** 2 < x**2 + y**2 + z**2 < outer**2
> which determines if (x, y, z) is in a spherical shell.
Even in
> If you can get by with a single literal list of words, write it once.
> ...if it's long enough to be annoying or becomes a maintenance burden,
use the `split()` idiom.
> ...if that's considered a "hack" or "bad form", then run it in the shell
once and copy/paste the result.
> ...if it might get m
> Replacing it would break backward compatibility. But adding a year
function as an alias for calendar wouldn’t. And you could note in > the
docs that year is preferred for new code, or even deprecate the old name
over a few versions if it seems worth it.
> What about prcal (as opposed to pryear)
> I happen to be teaching essential std lib modules this week, i had a
headache with how naming goes on (i was looking at how a beginner would
learn). Poor me, what could be an intuitive learning journey has some
clogs down the road.
To some degree, that's an inevitable part of the learning proc
>>> for item in data.items(): item[0], item[1]
874 µs ± 21.5 µs per loop (mean ± std. dev. of 7 runs, 1000 loops each)
>>> for key, value in data.items(): key, value
524 µs ± 4.26 µs per loop (mean ± std. dev. of 7 runs, 1000 loops each)
>>> for item in items_tuple(data): item.key, item.value
5.82
> I don't particularly care about learnability or discoverability in this
case -- I don't think beginners should be taught these operators as a major
tool in their toolbox (let them use .update()), and for anyone wondering
how to do something with a dict without access to the official docs,
there's
> FWIW, you can do it with dict already.
> o = memo.setdefault(o, o)
I don't think this has quite the same behavior as the OP is looking for,
since dict.setdefault() will insert the key and return the default when
it's not present, instead the OP wanted to raise "KeyError if the object is
not pre
> Actually there's no need to optimize the |= operator -- for strings we
have to optimize += *because* strings are immutable, but for dicts we would
define |= as essentially an alias for .update(), just like the relationship
between += and .extend() for lists, and then no unnecessary objects would
54051ec46a1cb96f52e7/Objects/listobject.c#L990
[3]:
https://github.com/python/cpython/blob/894331838b256412c95d54051ec46a1cb96f52e7/Objects/listobject.c#L996
On Tue, Dec 3, 2019 at 12:21 PM Antoine Rozo wrote:
> I think the small time difference you noticed is only due to method lookup.
>
> Le mar.
Serhiy Storchaka wrote:
> We still do not know a use case for findfirst. If the OP would show his
> code and several examples in others code this could be an argument for
> usefulness of this feature.
I'm not sure about the OP's exact use case, but using GitHub's code search
for .py files that mat
n of a new function. But, it could provide the same functionality as
the proposed re.findfirst(), without adding an entirely new function for
behavior that already exists.
On Fri, Dec 6, 2019 at 2:47 AM Serhiy Storchaka wrote:
> 05.12.19 23:47, Kyle Stanley пише:
> >
> > Serhiy Stor
ec 7, 2019 at 2:56 AM Serhiy Storchaka wrote:
> 06.12.19 23:20, Kyle Stanley пише:
> > Serhiy Storchaka wrote:
> > > It seems that in most cases the author just do not know about
> > > re.search(). Adding re.findfirst() will not fix this.
> >
> > That'
ter().group(1) (or
re.finditer.group() when there's not a subgroup). Based on the discussions
in this thread and code examples, this seems to be rather commonly
misunderstood.
On Sat, Dec 7, 2019 at 7:29 AM Kyle Stanley wrote:
> Serhiy Storchaka wrote:
> > My concern is that this w
7, 2019 at 7:47 AM Kyle Stanley wrote:
> > Code examples should of course be used sparingly, but I think
> re.finditer() could benefit from at least one
>
> Clarification: I see that there's an example of it being used in
> https://docs.python.org/3.8/library/re.html#finding-
out an hour ago. Sorry for the confusion, I wrote the reply after being
up for a while and got re.findter() and re.search() mixed up in my head.
You're correct.
On Sat, Dec 7, 2019 at 7:57 PM Andrew Barnert wrote:
> On Dec 7, 2019, at 04:51, Kyle Stanley wrote:
>
>
> Alternati
Serhiy Storchaka wrote:
> Would not adding a recipe in the itertools documentation or the tutorial
> help?
I think adding a recipe in the itertools documentation might help, but I
don't know that it would be a great fit for the tutorial. It seems a bit
too specific and could be a distraction from
> It also interns many ints, and they can't be used as names at all.
To clarify on "many ints", integers in the range of -5 to 256 (inclusive)
are interned. This can be demonstrated with the following:
```py
>>> a = 256
>>> b = 256
>>> a is b
True
>>> a = 257
>>> b = 257
>>> a is b
False
>>> a =
Tim Peters wrote:
> It's fair enough, although rather than "wrong" I'd say more that it's
> inappropriately applying design principles that work well in most of
> Python's libraries to an area where they don't. The very fact that
> half the itertools docs are devoted to "recipes" kinda suggests it
Stephen J. Turnbull wrote:
> Worse, running the same program again with the *same* set can change
> which element is first, I believe.
Yes, this is correct. For example, if you had a minimal Python file named
"some_set.py" with only the following:
```
s = set('abcdefg')
```
and then run somethin
> Python is not an OOP language. If you want to breathe and preach OOP, you
should quite frankly just use Java.
Python isn't *strictly* or *exclusively* an object-oriented programming
language, but since it does have strong support for OOP features, saying
that "Python is not an OOP language" simp
A very similar proposal was rejected:
https://www.python.org/dev/peps/pep-3136/.
Also, see the discussion in
https://mail.python.org/archives/list/[email protected]/thread/26PAGUTJ66S3BIZTL57IHUIYAHA7YOTV/#23H2S2AJFPRK46UID5MBHJJ7A3ERUBJA
.
If you'd still like to propose this, you'll have t
Marco Sulla wrote:
> First, C and assembly has no boolean type.
Not to focus on this because it's not particularly relevant to the original
topic, but this isn't true: C99 added the boolean type "_Bool", which can
be aliased as "bool" with the header.
On Thu, Dec 26, 2019 at 8:53 PM Marco Sulla
> 1. Recommend it in the official document "Using Python on Windows" [2].
> 2. Show the UTF-8 mode status in the command line mode header [3] on
Windows.
> 3. Show the link to the UTF-8 mode document in the command line mode
header too.
> 4. Add checkbox to set "PYTHONUTF8=1" environment variable
s.microsoft.com/en-us/cpp/text/general-mbcs-programming-advice?view=vs-2019
.
On Sun, Jan 12, 2020 at 1:28 AM Inada Naoki wrote:
> On Sat, Jan 11, 2020 at 11:03 AM Kyle Stanley wrote:
> >
> > > 1. Recommend it in the official document "Using Python on Windows" [2].
> Is anyone else interested in implementing this small feature for
concurrent.futures?
I would certainly be willing to look into it. We've been discussing the
possibility of a native threadpool for asyncio in the future (
https://bugs.python.org/issue32309), so it would certainly be beneficial
for
> I suggest that when you need this functionality you create your own data
> structure combining a list and a collections.Counter and keep track of
> this yourself.
I concur with the usage of collections.Counter here. Storing the count for
every single item in a list could end up being rather redu
That makes a lot more sense, thanks for the clarification.
On Wed, Jan 15, 2020 at 8:20 PM Eric V. Smith wrote:
> On 1/15/2020 7:43 PM, Kyle Stanley wrote:
> > > I suggest that when you need this functionality you create your own
> > data
> > > structure combining a l
> What if the colon were made optional, with an eye to perhaps eventually
no longer using it as the preferred style for new code?
> But if a line beginning as a compound statement and ending without a
colon is *never* going to have a valid meaning as something else... what's
the point of the colon
on was a bit more involved than I initially anticipated
(particularly for ProcessPoolExecutor), but I found it to be well worth the
effort! Both for the benefit of the new feature, and for the opportunity to
work with a part of the internals of the executors.
On Wed, Jan 15, 2020 at 5:59 PM Kyle
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 exper
> 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, c
> 2. I couldn't wrap my head around the async/await and future constructs
particularly quickly, and I was concerned that my team would also struggle
with this change.
> 3. I believe the procedural style glue code we have is quite easy to
comprehend, which I think has a positive impact on scale.
W
> I agree that is counter to the basic philosophy, though there are
potential use cases where it may be unavoidable to use threads. It seems
the best solutions when it is then are to use run_in_executor, which
automatically handles the waking up of the loop.
While this doesn't provide an immediat
Oops, I forgot to start the thread in the above example for
compute_something(), ``th.start()`` should go right after initializing the
thread but before the try-finally block
On Thu, Feb 13, 2020 at 6:15 PM Kyle Stanley wrote:
> > I agree that is counter to the basic philosophy, though
This seems to be two separate proposals:
1) Add a new way to create and specify executor
2) Add a SerialExecutor, which does not use threads or processes
So, I'll respond to each one separately.
*Add a new way to create and specify executor*
Jonathan Crall wrote:
> The library's ThreadPoolExec
> I've never felt the need for either of these myself, nor have I observed
it in others I worked with. In general I feel the difference between
processes and threads is so large that I can't believe a realistic
application would work with either.
Also, ThreadPoolExecutor and ProcessPoolExecutor bo
ifficult. Also, its
development time becomes limited by CPython's release cycle rather than
having its own.
On Sun, Feb 16, 2020 at 12:43 AM Andrew Barnert wrote:
> On Feb 15, 2020, at 20:29, Kyle Stanley wrote:
>
>
> *Add a SerialExecutor, which does not use threads or proces
I opened a bpo issue to expand upon the public API for cf.Future:
https://bugs.python.org/issue39645. Any feedback would be greatly
appreciated. (:
On Sun, Feb 16, 2020 at 12:22 AM Guido van Rossum wrote:
>
>
> On Sat, Feb 15, 2020 at 21:00 Kyle Stanley wrote:
>
>> > I&#
> FWIW, I agree with Andrew here. Being able to swap a
> ThreadPoolExecutor or ProcessPoolExecutor with a serial version using
> the same API can have benefits in various situations. One is
> easier debugging (in case the problem you have to debug isn't a race
> condition, of course :-)). Another
ame
issues coming up with custom Future and Executor classes; not to mention
the general debugging usefulness for being able to log the current state of
the future (without relying on private members).
On Sun, Feb 16, 2020 at 9:49 AM Antoine Pitrou wrote:
> On Sun, 16 Feb 2020 09:29:36 -0500
&g
ntoine Pitrou wrote:
> On Sun, 16 Feb 2020 17:41:36 -0500
> Kyle Stanley wrote:
> >
> > As a side note, are we still interested in expanding the public API for
> the
> > Future class? Particularly for a public means of accessing the state. The
> > primary motivatio
derstanding something?
On Mon, Feb 17, 2020 at 12:03 AM Guido van Rossum wrote:
> Hm, but doesn't the OP's example require *synchronously* reading and
> writing the state?
>
> On Sun, Feb 16, 2020 at 4:47 PM Kyle Stanley wrote:
>
>> > That sounds useful
on, Feb 17, 2020 at 5:08 AM Antoine Pitrou wrote:
> On Sun, 16 Feb 2020 19:46:13 -0500
> Kyle Stanley wrote:
> >
> > Based on the proposal in the OP, I had considered that it might also be
> > needed to be able to manually set the state of the future through
> something
> Anyway, I think the spelled-out “Synchronous” may be a better name, to
avoid the (very likely) case of people mistakenly reading “Sync” as short
for “Synchronized”. It’s no longer than “ProcessPool”, and, although it is
easy to typo, tab-completion or copy-paste helps, and how many times do you
n
> Isn’t the point of having a Code of Conduct that we shouldn’t have to
have these arguments? Or, if there is an argument about whether a single
figurative use as a word qualifies as “excessive swearing” per the CoC,
surely an -ideas thread isn’t the place to have it?
Yeah, I very much doubt that
Serhiy Storchaka wrote:
> 1. What special method should be added, `__keys__` or `__items__`? The
> former returns keys, it needs to call `__getitem__` repeatedly to get
> values. The latter returns key-value pairs, it does not need to call
> `__getitem__`, but you should always pay the cost of cre
> Setting PYTHONLOGGING to any log level or level name will initialize
logging.basicConfig() with that appropriate level.
This can already be done from the command line through --log=LEVEL, which
sets the logging.loglevel attribute. In the how-to section of the docs,
this is demonstrated in the fo
omething like argparse to check for a --log argument.
On Wed, Feb 19, 2020 at 9:19 PM Kyle Stanley wrote:
> > Setting PYTHONLOGGING to any log level or level name will initialize
> logging.basicConfig() with that appropriate level.
>
> This can already be done from the command line throu
tings in the warnings module and
> modify files each time you wish to enable all warnings. But then again, why
> would you?
>
> We have debugging flags for warnings, faulthandlers, asyncio etc...
> Logging I would say is the most important and trivial of all, yet we don't
> have
> Let's plan a cmdline argument then.
> Should we go for -L much like -W?
Yeah, I think a command-line argument is much more reasonable, less likely
to cause issues with other implementations of logging configuration, and
more practically useful. I'd be +1 on something like a `-L`.
On Thu, Feb 2
> One of the points of using a function is to not define it in the local
scope, but in some other namespace, so it can be reused and tested.
I consider the "tested" part to be of particular importance. Especially if
it were to become multiple layers deep, this can become a real issue.
This might
In order for this proposal to be seriously considered, I think it's
necessary to cite many realistic examples where the current behavior is
problematic enough to justify changing the current behavior, and that
adding a str.chars() and eventually removing the ability to iterate over
strings would pr
> 2. Looking it up is hard. If I Google "python ignore warnings" the top
result is a Stack Overflow question where neither the accepted answer nor
the most upvoted answer mention specifying a module. The second Google
result is the Python docs which are not easy to read through.
Hmm, I think we ma
ach module to ignore a specific warning for. I'm in favor of
making it easier to filter warnings the correct way rather than making it
more tempting to put a massive blanket filter across all modules though.
It's certainly a valid concern and I'm very much open to considering a
mea
> It would seems reasonable to have a separate _daemon_thread_queues dict
(in contrast to _threads_queues) that would not get joined upon exit.
> A "daemon" (or any better name) parameter of ThreadPoolExecutor
initialisation would allow to let it add its workers in this dict rather
than the default
> So I am sorry for the spam. Will be careful the next time.
I wouldn't worry about it too much. :)
In future, if you can establish to some degree that:
1) The feature isn't already available (if you're unsure, try python-list
as suggested above)
2) It has some realistic use cases
3) It hasn't b
cefully, so spawning it in a daemon thread or trying to interact with it
through one can interfere with that process.
On Tue, Mar 10, 2020 at 3:40 PM Antoine Pitrou wrote:
> On Tue, 10 Mar 2020 15:16:06 +0100
> Remy NOEL wrote:
> > On Mon, Mar 9, 2020 at 11:18 PM Kyle Stanley wro
Rob Cliffe wrote:
> Your docs link states "... they allow you to pass on the string quote
> character by escaping it with a backslash."
>
> I don't have access to a Python 3 version right now, but that is not
> true in Python 2:
> [snip]
The behavior is the same on Python 3.8.2:
Python 3.8.2 (def
Christopher Barker wrote:
> Is there any guarantee (or even string expectation) that the __str__ for
an object won't change?
> [snip]
> *reality check*: I imagine a LOT of code out there (doctests, who know
what else) does in fact expect the str() of builtins not to change -- so
this is probably de
I'd have to agree with Steven here, I'm -0 on the proposal since it's not
convincing (at least at the moment).
haael wrote:
> Python has more and more optional tools for formal correctness cheking.
> Why not loop invariants?
A better question would be "why add loop invariants?" rather than "why n
Steven D'Aprano wrote:
> Yes, really.
>
>
https://docs.python.org/3/reference/lexical_analysis.html#reserved-classes-of-identifiers
I remembered the existence of this rule and tried to locate it recently
(prior to this discussion), but was unable to because it doesn't explicitly
mention "dunder".
arker
wrote:
> On Fri, Mar 20, 2020 at 8:52 PM Kyle Stanley wrote:
>
>> >
>> https://docs.python.org/3/reference/lexical_analysis.html#reserved-classes-of-identifiers
>>
>> I remembered the existence of this rule and tried to locate it recently
>> (prior t
I ended up opening an issue for it at https://bugs.python.org/issue40045.
<http://bugs.python.org>
On Sun, Mar 22, 2020 at 8:33 PM Kyle Stanley wrote:
> Chistopher Barker wrote:
> > I'd suggest you make a PR on the docs.
>
> Yeah I was planning on either doing that, or
Steve Jorgensen wrote:
> Basically, it is for a sense of completeness. It feels weird that there
is a way to check whether an iterable is a subset of a set or a superset
> of a set but no way to directly ask whether it is equivalent to the set.
I can't say this has never happened historically, but
Stephen J. Turnbull wrote:
> The only cases I can remember are files named things like
> "thesis.doc.doc" in GUI environments. ;-)
For edge cases like that, something like
`"thesis.doc.doc".removesuffix(".doc").removesuffix(".doc")` should
suffice, no? It may not be the cleanest looking solution,
Brett Cannon wrote:
> There is an option to install Python to PATH on Windows if you check the
appropriate box during installation, but that's not really the
> way Windows apps typically work.
In this case of the OP, if they're mass installing Python on company
Windows devices, they might want to
> That would be nice. Does it apply to the _windows store version_, the
_traditional installer_, both ?
I believe it only applies to the traditional installer from python.org. You
will also have to verify it, as it has been a decent while since I've had
to install Python on Windows.
On Tue, Mar
e Barnes wrote:
> https://docs.python.org/3.8/using/windows.html#installing-without-ui
> gives details of all of the options. The Microsoft Store version does not
> offer any options full stop!
>
>
>
> *From:* Kyle Stanley
> *Sent:* 24 March 2020 18:10
> *To:* Frédé
Chris Angelico wrote:
> We will need a
> migration plan. Unfortunately, African swallows are non-migratory,
> severely impacting your proposal.
Well, aren't European swallows migratory? They may not be able to carry a
coconut, but certainly a migratory plan would be under their weight limit.
:-)
Paul Sokolovsky wrote:
> Roughly speaking, the answer would be about the same in idea as answers
> to the following questions:
> [snip]
I would say the difference between this proposal so far and the ones listed
are that they emphasized concrete, real-world examples from existing code
either in th
Dominik Vilsmeier wrote:
> I'm not sure if this is doable from the compiler perspective, but what
> about allowing tuples after `**` unpacking:
>
> requests.post(url, **(data, params))
>
> # similar to
> requests.post(url, data=data, params=params)
+1. I can see the practical utilit
Steven D'Aprano wrote:
> Do nothing?
> I don't have to suggest a better idea, since its not me proposing a
> change. I don't think any change is needed. It is up to you to firstly
> justify that a change is needed, and only then justify a specific
> response to that need.
[snip]
> If you persona
Soni L. wrote:
> it'd be nice if it did the same regardless of args.
Sorry, but "it'd be nice" is not a real world use case.
> inspired by PEP 559: https://www.python.org/dev/peps/pep-0559/
That PEP was rejected. It's okay to use previously rejected proposals
for inspiration, but your proposal w
I'd like to give my explicit +1 on this proposal, and for the
suggested alternative name "call_once". To me, this seems to be the
case of a common small startup optimization that's very easy to get
wrong, and to many users may be too much of a hassle to write their
own implementation to be worth us
Christopher Barker wrote:
> Is there a core developer with a particular interest in functools to be
> consulted?
Yep, Raymond Hettinger is the designated expert for the functools
module. See https://devguide.python.org/experts/#stdlib. I'm not sure
as to whether he regularly checks python-ideas,
Also, just to clearly demonstrate how the walrus operator could be
used for the OP's examples:
original:
```
if myDict.get('spam'):
print(myDict.get('spam'))
```
walrus:
```
if (x := d.get("spam")):
print(x)
```
original:
```
x = myDict.get('spam')
if x is not None:
print(x)
```
walru
While I'm -1 on the original proposal, I think the idea of PurePath.__len__
returning the number of components in the path may be worth some further
consideration. Also, I'm not convinced that having indexing is a necessary
prerequisite to pursue it further.
On Sun, May 24, 2020 at 8:14 AM Steven
Assuming the release managers are on-board with the idea (since it would
impact them the most), I'm +1. Overall, it seems like it would help
significantly to reduce the total number of different locations to update
during the release process once we get it fully configured.
> It could become more
I would like to clarify that asyncio *does* most certainly provide support
for programs that use multiple event loops and interact with a number of
different threads. So, asyncio can definitely be used outside of a purely
"single-process, single-threaded, single-event-loop
approach". However, a key
t
be a bit too soon (even more so with the release cadence being shortened
recently).
On Tue, Jun 9, 2020 at 11:09 PM Stephen J. Turnbull <
[email protected]> wrote:
> Kyle Stanley writes:
>
> > Fundamentally, OS threads and coroutines are two entirely different
While I agree that we should avoid telling people to "just use threads", I
think Chris was instead informing the OP that their desired behavior is
already present in threads, and if they don't want to be concerned at all
about context switching, OS threads should be considered as an alternative.
Of
> An await outside async def, would map to awaitable.run().
> A call to baz() would thus create a coroutine foo(), and then run() it.
-1. The `await` expression already has a well-defined purpose of suspending
the coroutine it's used within until the awaitable is completed. I think
this change in
> If
you're fine with invisible context switches, you're probably better
off with threads, because they're not vulnerable to unexpectedly
blocking actions (a common culprit being name lookups before network
transactions - you can connect sockets asynchronously, but
gethostbyname will block the curr
d to scale in volume
significantly. The fine-grained control over context switching (which can
be a pro or a con), shorter switch delay, and lower resource usage from
coroutines isn't always worth the added code complexity.
On Sun, Jun 14, 2020 at 12:43 AM Chris Angelico wrote:
> On Sun,
amble as to
how long it stalls the rest of the program, which is generally not
desirable to say the least.
On Sun, Jun 14, 2020 at 1:42 AM Kyle Stanley wrote:
> > IOW the solution to the problem is to use threads. You can see here
> why I said what I did: threads specifically avoid this proble
1 - 100 of 108 matches
Mail list logo
