[Tutor] Tutor Digest, Vol 228, Issue 18
Alphonsus
phonokoye at gmail.com
Thu Feb 23 14:36:22 EST 2023
Hello Dennis Lee Bieber, Alan Gauld, Mats Wichmann, and everyone on
this mailing list.
This message is to thank you all for your helpful replies and
references and to let you know that it is greatly appreciated. I am
still working on the code for now, and there is not much to that.
The skies are blue
Your efforts are valued
This I needed to do
So I say Thank you
Have a nice day/night ahead
On Wed, Feb 22, 2023 at 6:01 PM <tutor-request at python.org> wrote:
>
> Send Tutor mailing list submissions to
> tutor at python.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://mail.python.org/mailman/listinfo/tutor
> or, via email, send a message with subject or body 'help' to
> tutor-request at python.org
>
> You can reach the person managing the list at
> tutor-owner at python.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Tutor digest..."
> Today's Topics:
>
> 1. Re: What exactly does await do? (ThreeBlindQuarks)(David)
> (Alan Gauld)
> 2. Re: What exactly does await do? (ThreeBlindQuarks)(David)
> (Mats Wichmann)
>
>
>
> ---------- Forwarded message ----------
> From: Alan Gauld <alan.gauld at yahoo.co.uk>
> To: tutor at python.org
> Cc:
> Bcc:
> Date: Tue, 21 Feb 2023 19:28:07 +0000
> Subject: Re: [Tutor] What exactly does await do? (ThreeBlindQuarks)(David)
> On 19/02/2023 11:20, Alphonsus wrote:
>
> > question, I am actually writing a gui program but it is expected to do
> > a ton of request and on request by the user read a file, but while the
> > file is being read, I do not expect the program gui loop to stop, and
> > this is the same with the request.
>
> This is a classic scenario for threading. You could do it with async
> but that means running an async loop inside the gui loop which gets
> messy. The easiest way is to launch an async thread to run its loop.
> But if you are launching a thread then why not just read the file
> in the thread instead?
>
> There are some well publicised(over publicised?) issues with Python
> threading but those don't apply to I/O intesive operations like
> reading files.
>
> > Normally I read a file using something like this:
> > with open(filename, 'r') as file_object:
> > file_object.read()
>
> And thats fine inside a thread too.
> Just make sure you sabe the data into a variable accessible once
> the thread completes and set some kind of semaphore/flag to
> indicate when the data is safe to use. (ie you've finished
> the thread)
>
> > but it is my experience that this will stop the gui loop temporarily
> > and this becomes noticeable if the file is large. Looking at the
> > python docs, there are three candidates to solve this problem,
> > asyncio, threading or multiprocessing
>
> Generalizing very broadly
> - Asyncio is best for building transaction processors. I don't
> tend to use it with GUI driven programs. Its better in a
> server role IMHO.
>
> - Multiprocessing is good where the task is long running and
> indeterminate in nature (reading a file is relatively short
> and has a determinate end - when the file is read) For
> example if you had a "server" process that yout GUI used
> to perform calculations on an ad-hoc basis during the life
> of the program. Then starting a concurrent process to do
> the background processing makes sense. Also, due to
> Python's threading design processor intensive work would
> make sense. Say you had an IDE program and wanted to
> run compilations of your code in the background I'd probably
> choose to use a concurrent process rather than a thread.
> Or in a Video editor rendering the video could be another case.
>
> - Threads are good for quick(relatively) tasks that would
> block the GUI but will definitely terminate in "user
> time". Examples being to read a data file, do a spell
> check etc.
>
> Of course, it's not black and white and many will probably
> disagree with my arbitrary choices above. You can do parallel
> processing in many ways and there are no absolute rules.
>
> > I should also add that I found aiofiles package for reading to files
>
> A new one on me!
>
> > There are still things I do not understand but in trying to keep
> > things simple, I will ask only one question at a time and only if I
> > have understood and still find it necessary do I proceed with another
> > question?
>
> That's a good approach because asking multiple questions
> leads to confusing responses where it's not clear which
> question is being answered!
>
> > mind), I am looking for information of the objects that will appear in
> > the code, what the object will be doing, the functions that will be
> > needed in the code, what the functions will be doing, the loop and
> > what will be happening each time through the loop. Just general
> > information from which I can research further on. I just wish to
> > understand the concepts, not burden anyone with my tasks.
>
> In my tutorial(see below) I have three topics (in the advanced
> section) devoted to parallel processing using fork(), threading
> and multiprocessing. The examples may be too simple for your
> purposes but you might find the discussion useful.
>
> --
> Alan G
> Author of the Learn to Program web site
> http://www.alan-g.me.uk/l2p2
> http://www.amazon.com/author/alan_gauld
> Follow my photo-blog on Flickr at:
> http://www.flickr.com/photos/alangauldphotos
>
>
>
>
>
>
>
> ---------- Forwarded message ----------
> From: Mats Wichmann <mats at wichmann.us>
> To: tutor at python.org
> Cc:
> Bcc:
> Date: Tue, 21 Feb 2023 15:13:44 -0700
> Subject: Re: [Tutor] What exactly does await do? (ThreeBlindQuarks)(David)
> On 2/21/23 12:28, Alan Gauld via Tutor wrote:
>
> > And thats fine inside a thread too.
> > Just make sure you sabe the data into a variable accessible once
> > the thread completes and set some kind of semaphore/flag to
> > indicate when the data is safe to use. (ie you've finished
> > the thread)
>
> the queue module is often used for passing information back from threads
> (and sometimes to them as well). I know this is "well known" but as it's
> a largely beginner-oriented list it seems worthwhile to mention here in
> case anyone stumbles across this thread in the future.
>
>
>
> _______________________________________________
> Tutor maillist - Tutor at python.org
> https://mail.python.org/mailman/listinfo/tutor
More information about the Tutor
mailing list