Change by Caleb Hattingh :
--
nosy: +cjrh
___
Python tracker
<https://bugs.python.org/issue39232>
___
___
Python-bugs-list mailing list
Unsubscribe:
Caleb Hattingh added the comment:
The traditional way this done is with a finite number of workers pulling work
off a queue. This is straightforward to set up with builtins:
from uuid import uuid4
import asyncio, random
async def worker(q: asyncio.Queue):
while job := await q.get
Caleb Hattingh added the comment:
Kyle is correct. By analogy with Kyle's example, the following example has no
gather, only two nested futures:
```
# childfut.py
import asyncio
async def f(fut):
await fut
async def g(t):
await asyncio.sleep(t)
async def main():
Caleb Hattingh added the comment:
Can reproduce also on 3.8. Another version that "works" (raises the exception)
is
task = loop.create_task(test())
del task
Suggests there's something going on with reference counting or garbage
collection. In the version that &quo
Caleb Hattingh added the comment:
The dict unpacking generalizations that I posted were added in Python 3.5,
which is pretty old by now. (But, true, is in Python 3 and not Python 2). This
is the PEP: https://www.python.org/dev/peps/pep-0448/
The new syntax that Brandt posted will indeed
Caleb Hattingh added the comment:
dict syntax tools make it fairy easy to compose new dicts from old ones with
overrides:
subprocess.run(..., env={**os.environ, 'FOO': ..., 'BAR', ...}, ...)
Would this be sufficient to avoid the copy/pasting boilerplate?
--
Caleb Hattingh added the comment:
This change seems fine.
Markus,
I'm curious if there is a specific reason you prefer to use the default
executor rather than replacing it with your own? Is it just convenience or are
there other reasons?
--
nosy:
Caleb Hattingh added the comment:
@dontbugme This is a very old problem with threads and sub-processes. In the
general case (cross-platform, etc) it is difficult to kill threads and
sub-processes from the outside. The traditional solution is to somehow send a
message to the thread or
Caleb Hattingh added the comment:
Hmm, my recent comment looks rude but I didn't intend it to be that way. What I
mean is: there are many, many more users of asyncio.run than there are of
teleton, so any change made to asyncio.run is going to affect more people than
the other way roun
Caleb Hattingh added the comment:
@heckad You should instead ask the maintainers of teleton how to use their
library with asyncio.run, not the other way round.
--
nosy: +cjrh
___
Python tracker
<https://bugs.python.org/issue39
Change by Caleb Hattingh :
--
nosy: +cjrh
___
Python tracker
<https://bugs.python.org/issue39010>
___
___
Python-bugs-list mailing list
Unsubscribe:
Caleb Hattingh added the comment:
Ok, I see now. The improvement with only a single producer/consumer might be
marginal, but the proposition that `queue.cancel()` might simplify the
situation with multiple producers and/or consumers is more compelling.
Usually, assuming M producers and N
Change by Caleb Hattingh :
--
nosy: +cjrh
___
Python tracker
<https://bugs.python.org/issue38529>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Caleb Hattingh :
--
nosy: +cjrh
___
Python tracker
<https://bugs.python.org/issue38501>
___
___
Python-bugs-list mailing list
Unsubscribe:
Caleb Hattingh added the comment:
We can't allow both an `executor=` kwarg, as well as **kwargs for the target
func, unfortunately. If we do `executor=`, we'll again have to force users to
use functools.partial to wrap their functions that t
Caleb Hattingh added the comment:
Even before task groups land, this API can be easily improved by adding
asyncio.run_in_executor(func, *args, **kwargs)
- Only valid inside a coro or async context (uses get_running_loop internally)
- Analogous to how `loop.create_task` became
Caleb Hattingh added the comment:
> asyncio.wait_for is still confusing
Perhaps the confusion can be fixed with improvements to the docs? To me, these
specific docs seem pretty clear now, but I might not be a good judge of that.
> However, we still have the case where a misbehaving Ta
Change by Caleb Hattingh :
--
nosy: +cjrh
___
Python tracker
<https://bugs.python.org/issue38164>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Caleb Hattingh :
--
nosy: +cjrh
___
Python tracker
<https://bugs.python.org/issue38242>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Caleb Hattingh :
--
nosy: +cjrh
___
Python tracker
<https://bugs.python.org/issue34037>
___
___
Python-bugs-list mailing list
Unsubscribe:
Caleb Hattingh added the comment:
I'm interested in how this change would affect the pattern of shutting down a
queue-processing task.
How would one decide between whether to cancel the queue or the task? (I'm
asking for real, this is not an objection to the PR). For example,
Caleb Hattingh added the comment:
I'm removing the GUI section of the chat case study. Yury was right, it's not
going to add anything useful. The CLI chat client will work well because
prompt-toolkit has actual support for asyncio. Tkinter does not, and I think
it'll be bett
Caleb Hattingh added the comment:
FYI I'm going to be using the 3rd-party prompt-toolkit for the chat client.
(The server depends only on asyncio only). I put several hours research into
finding a way for the CLI chat client to be not terrible, but it gets very
complicated trying to m
Caleb Hattingh added the comment:
That was an long two months, apologies. I've made some fixes based on review
comments and cleaned up some more of the code samples. The primary outstanding
pieces are the client component of the chat application case study, and the GUI
integration se
Caleb Hattingh added the comment:
Somehow I missed that there's been an open issue on this. Like others I've
written a bunch of different incarnations of an "elapsed" context manager over
the years. Always for the more crude "how long did this take" reason li
Caleb Hattingh added the comment:
A quick note to say I have not abandoned this, it's just that life got
complicated for me in late 2018. I intend to pick up progress again within the
next month or two.
--
___
Python tracker
&
Caleb Hattingh added the comment:
@cheryl.sabella I am ok with closing this, but the original motivation for this
work was from @zack.ware so he should weigh in.
I am not going to work on this any further for the forseeable future (I've got
my hands full already with the asyncio doc
Caleb Hattingh added the comment:
I've added a few ideas for items in the "cookbook" page, which you'll see in
the PR. If anyone has suggestions for more or better cookbook entries
(recipes?), feel free to mention here or in the PR, I check both places. I
expect to get
Change by Caleb Hattingh :
--
nosy: +cjrh
___
Python tracker
<https://bugs.python.org/issue35036>
___
___
Python-bugs-list mailing list
Unsubscribe:
Caleb Hattingh added the comment:
I tested the Python 3.7.0 release version for Mac, the download called "macOS
64-bit installer" with checksum ae0717a02efea3b0eb34aadc680dc498 on this page:
https://www.python.org/downloads/release/python-370/
I downloaded, installed that on a ma
Caleb Hattingh added the comment:
I set up a basic structure under "Doc/library/asyncio-tutorial" as suggested,
and opened a PR to show you how that looks. When I make
more progress on a section, I'll post an update here.
--
___
Change by Caleb Hattingh :
--
keywords: +patch
pull_requests: +9134
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue34831>
___
___
Py
Caleb Hattingh added the comment:
A CLI client is a necessary step along the way anyway, so that sounds good by
me.
You suggested:
> I'd organize the tutorial in a dedicated directory like
> "Doc/library/asyncio-tutorial/"
I had a look at the source tree, there
Caleb Hattingh added the comment:
> * I think we should stick to your structure and push things to
> docs.python.org as soon as every next section is somewhat ready.
Ok. I'll get a PR going for the start page of the tutorial.
> * Every big section should probably have its own
New submission from Caleb Hattingh :
Hi Yury,
As discussed, below is a very rough outline of a proposed TOC for an asyncio
tutorial. No content has been written yet (only what you see below). I think we
should nail down the TOC first.
Asyncio Tutorial
Proposed Table of
Caleb Hattingh added the comment:
Yep, sounds good.
--
___
Python tracker
<https://bugs.python.org/issue30487>
___
___
Python-bugs-list mailing list
Unsubscribe:
Caleb Hattingh added the comment:
It looks like the check for an existing sphinx-build passes, and so no new venv
is made, but this also means that blurb doesn't get installed. I was concerned
about this, but figured that at least the buildbots would create new envs each
time, and
Caleb Hattingh added the comment:
Hi Ned
It's still supposed to allow both. It sounds like it's not working properly.
I'll have a look. FYI, I worked on this for Zach Ware who is the primary
stakeholder for this feature.
Rgds
Caleb
> On 28 Nov 2017, at 7:12 AM
Caleb Hattingh added the comment:
No worries. I've made a new PR 4346. The old one was unsalvagable I'm afraid.
Too many other people got added to the notifications list as a result of my
incorrect rebase. The new one is fine.
--
Change by Caleb Hattingh :
--
keywords: +patch
pull_requests: +4303
___
Python tracker
<https://bugs.python.org/issue30487>
___
___
Python-bugs-list mailin
Caleb Hattingh added the comment:
I messed up the PR through a failed rebase (trying to rebase my PR on top of
upstream). I closed the PR as a result. I have now fixed up my feature branch,
but I have not resubmitted the PR. Since the PR was left alone for many
months, I'm ok with le
Caleb Hattingh added the comment:
This looks like a dupe, or at least quite closely related to
https://bugs.python.org/issue26259. If the PR resolves both issues that one
should be closed too.
--
nosy: +cjrh
___
Python tracker
<ht
New submission from Caleb Hattingh:
Under guidance from zware during Pycon sprints, I've changed the Doc/ Makefile
to automatically create a virtual environment and install Sphinx, all as part
of the `make html` command.
--
assignee: docs@python
components: Documentation
mes
Caleb Hattingh added the comment:
The PR has been merged by Mariatta so I think this can be closed.
--
___
Python tracker
<http://bugs.python.org/issue30
Caleb Hattingh added the comment:
Oops, sorry! The PR was wrong because it auto-assumes the main cpython repo,
but my PR is in the devguide repo. This is the URL for the PR:
https://github.com/python/devguide/pull/206
--
___
Python tracker
<h
Changes by Caleb Hattingh :
--
pull_requests: -1812
___
Python tracker
<http://bugs.python.org/issue30433>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Caleb Hattingh:
The official devguide at https://github.com/python/devguide does not include
instructions on exactly how to build the docs! If, after cloning, you simply
type `make`, you get some helpful output:
$ make
Please use `make ' where is one of
html
Changes by Caleb Hattingh :
--
nosy: +cjrh
___
Python tracker
<http://bugs.python.org/issue15663>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Caleb Hattingh :
--
nosy: +cjrh
___
Python tracker
<http://bugs.python.org/issue12294>
___
___
Python-bugs-list mailing list
Unsubscribe:
Caleb Hattingh added the comment:
Presumably PEP488 (and the 4 years of inactivity) means that this issue could
be closed?
--
nosy: +cjrh
___
Python tracker
<http://bugs.python.org/issue12
Changes by Caleb Hattingh :
--
nosy: +cjrh
___
Python tracker
<http://bugs.python.org/issue11602>
___
___
Python-bugs-list mailing list
Unsubscribe:
Caleb Hattingh added the comment:
I struggled with this issue, and eventually found the recommendations about
linking with homebrew's OpenSSL on StackOverflow or similar, and then only
later found this issue here (and with it the link to the devguide); but the
*first* places I looked wer
Changes by Caleb Hattingh :
--
nosy: +cjrh
___
Python tracker
<http://bugs.python.org/issue25572>
___
___
Python-bugs-list mailing list
Unsubscribe:
53 matches
Mail list logo
