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?
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
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
>
ty 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 brief
> examp
mples, 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 there be some substantial differences?
Thanks,
Kyle Stanley
On Fri, Aug 16, 2019 at
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
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
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
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?
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()
...
> 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
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 definitely seems counter-intuitive. If it came up in
> a code
> 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
> 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
> 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,
> 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
> 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
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
ality 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 Storchaka wrote:
> > > We still do not know a use case
cts/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. 3 déc. 2019 à 13:57,
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 will add co
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's definitely
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:
>
>
> Alternatively:
19 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-all-adverb
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
> 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
> 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
> 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
>>> 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
> 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
> 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"
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
> 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
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
> 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,
ion 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 Stan
rote:
> 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
> > like a `Future.set_state()`, which
> 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
> 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
> 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. 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.
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'v
> 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 :-)).
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
> 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
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 processes*
>
> Andre
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
> Kyle Stanley wrote:
&
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 motivation for it was this topic, but I
, 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 to me indeed. I assume you mean somethi
> 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
> 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
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,
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
> 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
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 a flag for it.
>
> On Thu, Feb 20, 2020, 4:24 AM Kyle Stanley w
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
> 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/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].
> > > 2.
erkill.
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
> 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
> 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
> 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
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
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/python-ideas@python.org/thread/26PAGUTJ66S3BIZTL57IHUIYAHA7YOTV/#23H2S2AJFPRK46UID5MBHJJ7A3ERUBJA
.
If you'd still like to propose this, you'll have
> 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
ad 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 wrote:
> >
> > > We're curre
> 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
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
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
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
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
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
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
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
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
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)
```
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
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".
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,
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 open
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,
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 to thi
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,
nes 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éric D
ds of reference materials that would need to be updated to
address "PAP", it doesn't seem worth the marginal at best benefit.
Regards,
Kyle Stanley
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to
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
-1. Assertions are ignored when Python is run with -O, so we definitely
don't want to encourage relying on asserts to ensure users pass the correct
value. But even if that wasn't an issue, I consider the `else:
ValueError()` to be significantly more readable.
Otherwise, the alternative offered by
> But my question is why not to apply all this patches to `CPython` to be
able to compile `CPython` on the Web ?
> Patches to CPython seems pretty straightforward ...
In order for an existing project to even be considered as a patch for
CPython as an addition to the standard library, it
I believe asyncio.wait() with "return_when=FIRST_COMPLETED" would
perform the functionality you're looking for with the
"asyncio.on_first_return()". For details on the functionality of
asyncio.wait(), see
https://docs.python.org/3/library/asyncio-task.html#asyncio.wait.
> I understand that I can
I can't say that I've ever assessed the quality of a code comment
based on how well it adheres to Strunk & White, nor have I ever been
involved with an environment that tries to strongly enforce that
specific style of writing. So FWIW, I agree that "clear and concise
English" is more relevant to
> It would only be available on the Linux platform, and one of the benefits
would be the ability to create synchronisation primitives on said platform
that can block on normal threads, and be awaited on in coroutines (without
busy looping inside said coroutine).
+1. Although it already exists as
> Instead of trying to fix the PyPi version, I can write a proof of concept
of what I described above?
That would definitely be useful, and would help us get a more solid idea of
what exactly is being proposed. I also agree that a potential version
contained in the select module should be as
> Perfect. What's the procedure now for getting that PR accepted?
Next, it will go through a PR review process prior to being included for
Python 3.10. Since it's being implemented as a wrapper for an existing OS
API, a PR and bpo issue should be adequate (as opposed to major change
proposals
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
1 - 100 of 106 matches
Mail list logo
