Re: Python child process in while True loop blocks parent
> On 5 Dec 2021, at 23:51, Jen Kris wrote: > > > By embedding, I think you may be referring to embedding Python in a C program > with the Python C API. That's not what I'm doing here -- I'm not using the > Python C API. The C program creates two threads (using pthreads), one for > itself and one for the child process. On creation, the second pthread is > pointed to a C program that calls fork-execv to run the Python program. That > way Python runs on a separate thread. The multiprocessing library > "effectively side-step[s] the Global Interpreter Lock by using subprocesses > instead of threads." https://docs.python.org/3/library/multiprocessing.html. > This way I can get the Python functionality I want on call from the C > program through pipes and shared memory. > > I don't want to use the C API because I will be making certain library calls > from the C program, and the syntax is much easier with native Python code > than with C API code. > > I hope that clarifies what I'm doing. You are confusing the threading needs of a python program and extension written in C and what you need to do to start a child process. I see no benifit from calling fork and exec from a new thread. Indeed you may encounter more issues. What ever the bug is that you and trying to fix threading has nothing to do with it. What if you change you code to run bash script instead of python? Does you C program block them? What did strace tell you was the reason that your C parent program blocked? Barry > > Jen > > > > Dec 5, 2021, 15:19 by [email protected]: > > > >>> On 5 Dec 2021, at 17:54, Jen Kris wrote: >> >> Thanks for your comments. >> >> I put the Python program on its own pthread, and call a small C program to >> fork-execv to call the Python program as a child process. > > What do you mean by putting python in it’s own pthread? > Are you embedding python in an other program? > > Barry > > >> I revised the Python program to be a multiprocessing loop using the Python >> multiprocessing module. That bypasses the GIL and allows Python to run >> concurrently with C. So far so good. >> >> Next I will use Linux pipes, not Python multiprocessing pipes, for IPC >> between Python and C. Multiprocessing pipes are (as far as I can tell) only >> for commo between two Python processes. I will have the parent thread send >> a signal through the pipe to the child process to exit when the parent >> thread is ready to exit, then call wait() to finalize the child process. >> >> I will reply back when it's finished and post the code so you can see what I >> have done. >> >> Thanks again. >> >> Jen >> >> >> Dec 4, 2021, 09:22 by [email protected]: >> >>> On 1 Dec 2021, at 16:01, Jen Kris wrote: >>> >>> Thanks for your comment re blocking. >>> >>> I removed pipes from the Python and C programs to see if it blocks without >>> them, and it does. >>> It looks now like the problem is not pipes. >> >> Ok. >> >>> I use fork() and execv() in C to run Python in a child process, but the >>> Python process blocks >> >> Use strace on the parent process to see what is happening. >> You will need to use the option to follow subprocesses so that you can see >> what goes on in the python process. >> >> See man strace and the --follow-forks and --output-separately options. >> That will allow you to find the blocking system call that your code is >> making. >> >>> because fork() does not create a new thread, so the Python global >>> interpreter lock (GIL) prevents the C program from running once Python >>> starts. >> >> Not sure why you think this. >> >>> So the solution appears to be run Python in a separate thread, which I >>> can do with pthread create. >>> See "Thread State and the Global Interpreter Lock" >>> https://docs.python.org/3/c-api/init.html#thread-state-and-the-global-interpreter-lock >>> and the sections below that "Non-Python created threads" and "Cautions >>> about fork()." >> >> I take it you mean that in the parent you think that using pthreads will >> affect python after the exec() call? >> I does not. After exec() the process has one main thread create by the >> kernel and a new address space as defined by the /usr/bin/python. >> The only state that in inherited from the parent are open file descriptors, >> the current working directory and security state like UID, GID. >> >>> I'm working on that today and I hope all goes well :) >> >> You seem to be missing background information on how processes work. >> Maybe "Advanced Programming in the UNIX Environment" would be helpful? >> >> https://www.amazon.co.uk/Programming-Environment-Addison-Wesley-Professional-Computing-dp-0321637739/dp/0321637739/ref=dp_ob_image_bk >> >> >> It's a great book and covers a wide range of Unix systems programming topics. >> >> Have you created a small C program that just does the fork and exec of a >> python program to test out yo
Re: threading and multiprocessing deadlock
Hi!, in short your code should work.
I think that the join-joined problem is just an interpretation problem.
In pseudo code the background_thread function does:
def background_thread()
# bla
print("join?")
# bla
print("joined")
When running this function in parallel using threads, you will probably
get a few "join?" first before receiving any "joined?". That is because
the functions are running in parallel.
The order "join?" then "joined" is preserved within a thread but not
preserved globally.
Now, I see another issue in the output (and perhaps you was asking about
this one):
join?
join?
myfnc
myfnc
join?
join?
joined.
joined.
So you have 4 "join?" that correspond to the 4 background_thread
function calls in threads but only 2 "myfnc" and 2 "joined".
Could be possible that the output is truncated by accident?
I ran the same program and I got a reasonable output (4 "join?", "myfnc"
and "joined"):
join?
join?
myfnc
join?
myfnc
join?
joined.
myfnc
joined.
joined.
myfnc
joined.
Another issue that I see is that you are not joining the threads that
you spawned (background_thread functions).
I hope that this can guide you to fix or at least narrow the issue.
Thanks,
Martin.
On Mon, Dec 06, 2021 at 12:50:11AM +0100, Johannes Bauer wrote:
Hi there,
I'm a bit confused. In my scenario I a mixing threading with
multiprocessing. Threading by itself would be nice, but for GIL reasons
I need both, unfortunately. I've encountered a weird situation in which
multiprocessing Process()es which are started in a new thread don't
actually start and so they deadlock on join.
I've created a minimal example that demonstrates the issue. I'm running
on x86_64 Linux using Python 3.9.5 (default, May 11 2021, 08:20:37)
([GCC 10.3.0] on linux).
Here's the code:
import time
import multiprocessing
import threading
def myfnc():
print("myfnc")
def run(result_queue, callback):
result = callback()
result_queue.put(result)
def start(fnc):
def background_thread():
queue = multiprocessing.Queue()
proc = multiprocessing.Process(target = run, args = (queue,
fnc))
proc.start()
print("join?")
proc.join()
print("joined.")
result = queue.get()
threading.Thread(target = background_thread).start()
start(myfnc)
start(myfnc)
start(myfnc)
start(myfnc)
while True:
time.sleep(1)
What you'll see is that "join?" and "joined." nondeterministically does
*not* appear in pairs. For example:
join?
join?
myfnc
myfnc
join?
join?
joined.
joined.
What's worse is that when this happens and I Ctrl-C out of Python, the
started Thread is still running in the background:
$ ps ax | grep minimal
370167 pts/0S 0:00 python3 minimal.py
370175 pts/2S+ 0:00 grep minimal
Can someone figure out what is going on there?
Best,
Johannes
--
https://mail.python.org/mailman/listinfo/python-list
--
https://mail.python.org/mailman/listinfo/python-list
Re: threading and multiprocessing deadlock
Am 06.12.21 um 13:56 schrieb Martin Di Paola:
> Hi!, in short your code should work.
>
> I think that the join-joined problem is just an interpretation problem.
>
> In pseudo code the background_thread function does:
>
> def background_thread()
> # bla
> print("join?")
> # bla
> print("joined")
>
> When running this function in parallel using threads, you will probably
> get a few "join?" first before receiving any "joined?". That is because
> the functions are running in parallel.
>
> The order "join?" then "joined" is preserved within a thread but not
> preserved globally.
Yes, completely understood and really not the issue. That these pairs
are not in sequence is fine.
> Now, I see another issue in the output (and perhaps you was asking about
> this one):
>
> join?
> join?
> myfnc
> myfnc
> join?
> join?
> joined.
> joined.
>
> So you have 4 "join?" that correspond to the 4 background_thread
> function calls in threads but only 2 "myfnc" and 2 "joined".
Exactly that is the issue. Then it hangs. Deadlocked.
> Could be possible that the output is truncated by accident?
No. This is it. The exact output varies, but when it hangs, it always
also does not execute the function (note the lack of "myfnc"). For example:
join?
join?
myfnc
join?
myfnc
join?
myfnc
joined.
joined.
joined.
(only three threads get started there)
join?
myfnc
join?
join?
join?
joined.
(this time only a single one made it)
join?
join?
join?
myfnc
join?
myfnc
joined.
myfnc
joined.
joined.
(three get started)
> I ran the same program and I got a reasonable output (4 "join?", "myfnc"
> and "joined"):
>
> join?
> join?
> myfnc
> join?
> myfnc
> join?
> joined.
> myfnc
> joined.
> joined.
> myfnc
> joined.
This happens to me occasionally, but most of the time one of the
processes deadlocks. Did you consistently get four of each? What
OS/Python version were you using?
> Another issue that I see is that you are not joining the threads that
> you spawned (background_thread functions).
True, I kindof assumed those would be detached threads.
> I hope that this can guide you to fix or at least narrow the issue.
Depending on what OS/Python version you're using, that points in that
direction and kindof reinforces my belief that the code is correct.
Very curious.
Thanks & all the best,
Joe
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python child process in while True loop blocks parent
I can't find any support for your comment that "Fork creates a new
process and therefore also a new thread." From the Linux man pages
https://www.man7.org/linux/man-pages/man2/fork.2.html, "The child process is
created with a single thread—the one that called fork()."
I have a one-core one-thread instance at Digital Ocean available running Ubuntu
18.04. I can fork and create a new process on it, but it doesn't create a new
thread because it doesn't have one available.
You may also want to see "Forking vs Threading"
(https://www.geekride.com/fork-forking-vs-threading-thread-linux-kernel), "Fork
vs Thread" (https://medium.com/obscure-system/fork-vs-thread-38e09ec099e2), and
"Linux process and thread" (https://zliu.org/post/linux-process-and-thread)
("This means that to create a normal process fork() is used that further calls
clone() with appropriate arguments while to create a thread or LWP, a function
from pthread library calls clone() with relvant flags. So, the main difference
is generated by using different flags that can be passed to clone() funciton(to
be exact, it is a system call").
You may be confused by the fact that threads are called light-weight processes.
Or maybe I'm confused :)
If you have other information, please let me know. Thanks.
Jen
Dec 5, 2021, 18:08 by [email protected]:
> On 2021-12-06 00:51:13 +0100, Jen Kris via Python-list wrote:
>
>> The C program creates two threads (using pthreads), one for itself and
>> one for the child process. On creation, the second pthread is pointed
>> to a C program that calls fork-execv to run the Python program. That
>> way Python runs on a separate thread.
>>
>
> I think you have the relationship between processes and threads
> backwards. A process consists of one or more threads. Fork creates a new
> process and therefore also a new thread.
>
> hp
>
> --
> _ | Peter J. Holzer| Story must make more sense than reality.
> |_|_) ||
> | | | [email protected] |-- Charles Stross, "Creative writing
> __/ | http://www.hjp.at/ | challenge!"
>
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python child process in while True loop blocks parent
On Tue, Dec 7, 2021 at 4:10 AM Jen Kris via Python-list wrote: > > I can't find any support for your comment that "Fork creates a new > process and therefore also a new thread." From the Linux man pages > https://www.man7.org/linux/man-pages/man2/fork.2.html, "The child process is > created with a single thread—the one that called fork()." > > I have a one-core one-thread instance at Digital Ocean available running > Ubuntu 18.04. I can fork and create a new process on it, but it doesn't > create a new thread because it doesn't have one available. > A CPU core is capable of running one or more threads *concurrently*, and having multiple cores obviously multiplies that out. But for what you're doing here, there's no material difference between threads running concurrently and threads switching out between themselves (other than performance, of course). From the operating system and application perspectives, a "thread" is one runnable thread. Every Unix process must contain a minimum of one thread. As a rough rule of thumb, a process owns resources, a thread runs code. Without a thread, you can't run any code. Forking a process creates a child process and leaves the parent running. The child process must by definition have a minimum of one thread, and the man page is stating that one thread is all it gets. Hope that helps explain things a bit. I don't know exactly what's going on in your code, but maybe that'll clarify the word "thread". ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python child process in while True loop blocks parent
> On 6 Dec 2021, at 17:09, Jen Kris via Python-list
> wrote:
>
> I can't find any support for your comment that "Fork creates a new
> process and therefore also a new thread." From the Linux man pages
> https://www.man7.org/linux/man-pages/man2/fork.2.html, "The child process is
> created with a single thread—the one that called fork()."
You just quoted the evidence!
All new processes on unix (may all OS) only ever have one thread when they
start.
The thread-id of the first thread is the same as the process-id and referred to
as the main thread.
>
> I have a one-core one-thread instance at Digital Ocean available running
> Ubuntu 18.04. I can fork and create a new process on it, but it doesn't
> create a new thread because it doesn't have one available.
By that logic it can only run one process...
It has one hardware core that support one hardware thread.
Linux can create as many software threads as it likes.
> You may also want to see "Forking vs Threading"
> (https://www.geekride.com/fork-forking-vs-threading-thread-linux-kernel),
> "Fork vs Thread"
> (https://medium.com/obscure-system/fork-vs-thread-38e09ec099e2), and "Linux
> process and thread" (https://zliu.org/post/linux-process-and-thread) ("This
> means that to create a normal process fork() is used that further calls
> clone() with appropriate arguments while to create a thread or LWP, a
> function from pthread library calls clone() with relvant flags. So, the main
> difference is generated by using different flags that can be passed to
> clone() funciton(to be exact, it is a system call").
>
> You may be confused by the fact that threads are called light-weight
> processes.
No Peter and I are not confused.
>
> Or maybe I'm confused :)
Yes you are confused.
>
> If you have other information, please let me know. Thanks.
Please get the book I recommended, or another that covers systems programming
on unix, and have a read.
Barry
>
> Jen
>
>
> Dec 5, 2021, 18:08 by [email protected]:
>
>> On 2021-12-06 00:51:13 +0100, Jen Kris via Python-list wrote:
>>
>>> The C program creates two threads (using pthreads), one for itself and
>>> one for the child process. On creation, the second pthread is pointed
>>> to a C program that calls fork-execv to run the Python program. That
>>> way Python runs on a separate thread.
>>>
>>
>> I think you have the relationship between processes and threads
>> backwards. A process consists of one or more threads. Fork creates a new
>> process and therefore also a new thread.
>>
>> hp
>>
>> --
>> _ | Peter J. Holzer| Story must make more sense than reality.
>> |_|_) ||
>> | | | [email protected] |-- Charles Stross, "Creative writing
>> __/ | http://www.hjp.at/ | challenge!"
>>
>
> --
> https://mail.python.org/mailman/listinfo/python-list
--
https://mail.python.org/mailman/listinfo/python-list
Re: threading and multiprocessing deadlock
> On 5 Dec 2021, at 23:50, Johannes Bauer wrote:
>
> Hi there,
>
> I'm a bit confused. In my scenario I a mixing threading with
> multiprocessing. Threading by itself would be nice, but for GIL reasons
> I need both, unfortunately. I've encountered a weird situation in which
> multiprocessing Process()es which are started in a new thread don't
> actually start and so they deadlock on join.
>
> I've created a minimal example that demonstrates the issue. I'm running
> on x86_64 Linux using Python 3.9.5 (default, May 11 2021, 08:20:37)
> ([GCC 10.3.0] on linux).
>
> Here's the code:
I suggest that you include the threading.current_thread() in your messages.
Then you can see which thread is saying what.
Barry
>
>
> import time
> import multiprocessing
> import threading
>
> def myfnc():
> print("myfnc")
>
> def run(result_queue, callback):
> result = callback()
> result_queue.put(result)
>
> def start(fnc):
> def background_thread():
> queue = multiprocessing.Queue()
> proc = multiprocessing.Process(target = run, args = (queue,
> fnc))
> proc.start()
> print("join?")
> proc.join()
> print("joined.")
> result = queue.get()
> threading.Thread(target = background_thread).start()
>
> start(myfnc)
> start(myfnc)
> start(myfnc)
> start(myfnc)
> while True:
> time.sleep(1)
>
>
> What you'll see is that "join?" and "joined." nondeterministically does
> *not* appear in pairs. For example:
>
> join?
> join?
> myfnc
> myfnc
> join?
> join?
> joined.
> joined.
>
> What's worse is that when this happens and I Ctrl-C out of Python, the
> started Thread is still running in the background:
>
> $ ps ax | grep minimal
> 370167 pts/0S 0:00 python3 minimal.py
> 370175 pts/2S+ 0:00 grep minimal
>
> Can someone figure out what is going on there?
>
> Best,
> Johannes
> --
> https://mail.python.org/mailman/listinfo/python-list
>
--
https://mail.python.org/mailman/listinfo/python-list
Re: threading and multiprocessing deadlock
Johannes Bauer wrote at 2021-12-6 00:50 +0100: >I'm a bit confused. In my scenario I a mixing threading with >multiprocessing. Threading by itself would be nice, but for GIL reasons >I need both, unfortunately. I've encountered a weird situation in which >multiprocessing Process()es which are started in a new thread don't >actually start and so they deadlock on join. The `multiprocessing` doc (--> "https://docs.python.org/3/library/multiprocessing.html#module-multiprocessing";) has the following warning: "Note that safely forking a multithreaded process is problematic." Thus, if you use the `fork` method to start processes, some surprises are to be expected. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python child process in while True loop blocks parent
Here is what I don't understand from what you said. "The child process is created with a single thread—the one that called fork()." To me that implies that the thread that called fork() is the same thread as the child process. I guess you're talking about the distinction between logical threads and physical threads. But the main issue is your suggestion that I should call fork-execv from the thread that runs the main C program, not from a separate physical pthread. That would certainly eliminate the overhead of creating a new pthread. I am working now to finish this, and I will try your suggestion of calling fork-execv from the "main" thread. When I reply back next I can give you a complete picture of what I'm doing. Your comments, and those of Peter Holzer and Chris Angelico, are most appreciated. Dec 6, 2021, 10:37 by [email protected]: > > >> On 6 Dec 2021, at 17:09, Jen Kris via Python-list >> wrote: >> >> I can't find any support for your comment that "Fork creates a new >> process and therefore also a new thread." From the Linux man pages >> https://www.man7.org/linux/man-pages/man2/fork.2.html, "The child process is >> created with a single thread—the one that called fork()." >> > > You just quoted the evidence! > > All new processes on unix (may all OS) only ever have one thread when they > start. > The thread-id of the first thread is the same as the process-id and referred > to as the main thread. > >> >> I have a one-core one-thread instance at Digital Ocean available running >> Ubuntu 18.04. I can fork and create a new process on it, but it doesn't >> create a new thread because it doesn't have one available. >> > > > By that logic it can only run one process... > > It has one hardware core that support one hardware thread. > Linux can create as many software threads as it likes. > >> You may also want to see "Forking vs Threading" >> (https://www.geekride.com/fork-forking-vs-threading-thread-linux-kernel), >> "Fork vs Thread" >> (https://medium.com/obscure-system/fork-vs-thread-38e09ec099e2), and "Linux >> process and thread" (https://zliu.org/post/linux-process-and-thread) ("This >> means that to create a normal process fork() is used that further calls >> clone() with appropriate arguments while to create a thread or LWP, a >> function from pthread library calls clone() with relvant flags. So, the main >> difference is generated by using different flags that can be passed to >> clone() funciton(to be exact, it is a system call"). >> >> You may be confused by the fact that threads are called light-weight >> processes. >> > > No Peter and I are not confused. > >> >> Or maybe I'm confused :) >> > > Yes you are confused. > >> >> If you have other information, please let me know. Thanks. >> > > Please get the book I recommended, or another that covers systems programming > on unix, and have a read. > > Barry > >> >> Jen >> >> >> Dec 5, 2021, 18:08 by [email protected]: >> >>> On 2021-12-06 00:51:13 +0100, Jen Kris via Python-list wrote: >>> The C program creates two threads (using pthreads), one for itself and one for the child process. On creation, the second pthread is pointed to a C program that calls fork-execv to run the Python program. That way Python runs on a separate thread. >>> >>> I think you have the relationship between processes and threads >>> backwards. A process consists of one or more threads. Fork creates a new >>> process and therefore also a new thread. >>> >>> hp >>> >>> -- >>> _ | Peter J. Holzer| Story must make more sense than reality. >>> |_|_) || >>> | | | [email protected] |-- Charles Stross, "Creative writing >>> __/ | http://www.hjp.at/ | challenge!" >>> >> >> -- >> https://mail.python.org/mailman/listinfo/python-list >> -- https://mail.python.org/mailman/listinfo/python-list
Re: Python child process in while True loop blocks parent
> On 6 Dec 2021, at 21:05, Jen Kris wrote: > > Here is what I don't understand from what you said. "The child process is > created with a single thread—the one that called fork()." To me that implies > that the thread that called fork() is the same thread as the child process. > I guess you're talking about the distinction between logical threads and > physical threads. The thread that called fork is cloned into a new thread in the new process. It has a clone of the processor registers of the thread, stack memory segment of that thread, which means that it has all the stack variables and stack frames from the parent process's thread. > But the main issue is your suggestion that I should call fork-execv from the > thread that runs the main C program, not from a separate physical pthread. > That would certainly eliminate the overhead of creating a new pthread. Forget about physical threads, they only matter when you are performance tuning your code. > I am working now to finish this, and I will try your suggestion of calling > fork-execv from the "main" thread. When I reply back next I can give you a > complete picture of what I'm doing. > > Your comments, and those of Peter Holzer and Chris Angelico, are most > appreciated. Barry > > > Dec 6, 2021, 10:37 by [email protected]: > > On 6 Dec 2021, at 17:09, Jen Kris via Python-list > wrote: > > I can't find any support for your comment that "Fork creates a new > process and therefore also a new thread." From the Linux man pages > https://www.man7.org/linux/man-pages/man2/fork.2.html, "The child process is > created with a single thread—the one that called fork()." > > You just quoted the evidence! > > All new processes on unix (may all OS) only ever have one thread when they > start. > The thread-id of the first thread is the same as the process-id and referred > to as the main thread. > > I have a one-core one-thread instance at Digital Ocean available running > Ubuntu 18.04. I can fork and create a new process on it, but it doesn't > create a new thread because it doesn't have one available. > > > By that logic it can only run one process... > > It has one hardware core that support one hardware thread. > Linux can create as many software threads as it likes. > You may also want to see "Forking vs Threading" > (https://www.geekride.com/fork-forking-vs-threading-thread-linux-kernel), > "Fork vs Thread" > (https://medium.com/obscure-system/fork-vs-thread-38e09ec099e2), and "Linux > process and thread" (https://zliu.org/post/linux-process-and-thread) ("This > means that to create a normal process fork() is used that further calls > clone() with appropriate arguments while to create a thread or LWP, a > function from pthread library calls clone() with relvant flags. So, the main > difference is generated by using different flags that can be passed to > clone() funciton(to be exact, it is a system call"). > > You may be confused by the fact that threads are called light-weight > processes. > > No Peter and I are not confused. > > Or maybe I'm confused :) > > Yes you are confused. > > If you have other information, please let me know. Thanks. > > Please get the book I recommended, or another that covers systems programming > on unix, and have a read. > > Barry > > Jen > > > Dec 5, 2021, 18:08 by [email protected]: > On 2021-12-06 00:51:13 +0100, Jen Kris via Python-list wrote: > The C program creates two threads (using pthreads), one for itself and > one for the child process. On creation, the second pthread is pointed > to a C program that calls fork-execv to run the Python program. That > way Python runs on a separate thread. > > I think you have the relationship between processes and threads > backwards. A process consists of one or more threads. Fork creates a new > process and therefore also a new thread. > > hp > > -- > _ | Peter J. Holzer | Story must make more sense than reality. > |_|_) | | > | | | [email protected] | -- Charles Stross, "Creative writing > __/ | http://www.hjp.at/ | challenge!" > > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
[RELEASE] Python 3.10.1 is available
I hope you like bug fixes, because we have a whole shipment of them! Python 3.10.1 is the first maintenance release of Python 3.10 as we have packed more than 330 commits of fixes and general improvements. You can get it here: https://www.python.org/downloads/release/python-3101/ # This is the first maintenance release of Python 3.10 Python 3.10.1 is the newest major release of the Python programming language, and it contains many new features and optimizations. # Major new features of the 3.10 series, compared to 3.9 Among the new major new features and changes so far: * [PEP 623](https://www.python.org/dev/peps/pep-0623/) -- Deprecate and prepare for the removal of the wstr member in PyUnicodeObject. * [PEP 604](https://www.python.org/dev/peps/pep-0604/) -- Allow writing union types as X | Y * [PEP 612](https://www.python.org/dev/peps/pep-0612/) -- Parameter Specification Variables * [PEP 626](https://www.python.org/dev/peps/pep-0626/) -- Precise line numbers for debugging and other tools. * [PEP 618 ](https://www.python.org/dev/peps/pep-0618/) -- Add Optional Length-Checking To zip. * [bpo-12782](https://bugs.python.org/issue12782): Parenthesized context managers are now officially allowed. * [PEP 632 ](https://www.python.org/dev/peps/pep-0632/) -- Deprecate distutils module. * [PEP 613 ](https://www.python.org/dev/peps/pep-0613/) -- Explicit Type Aliases * [PEP 634 ](https://www.python.org/dev/peps/pep-0634/) -- Structural Pattern Matching: Specification * [PEP 635 ](https://www.python.org/dev/peps/pep-0635/) -- Structural Pattern Matching: Motivation and Rationale * [PEP 636 ](https://www.python.org/dev/peps/pep-0636/) -- Structural Pattern Matching: Tutorial * [PEP 644 ](https://www.python.org/dev/peps/pep-0644/) -- Require OpenSSL 1.1.1 or newer * [PEP 624 ](https://www.python.org/dev/peps/pep-0624/) -- Remove Py_UNICODE encoder APIs * [PEP 597 ](https://www.python.org/dev/peps/pep-0597/) -- Add optional EncodingWarning [bpo-38605](https://bugs.python.org/issue38605): `from __future__ import annotations` ([PEP 563](https://www.python.org/dev/peps/pep-0563/)) used to be on this list in previous pre-releases but it has been postponed to Python 3.11 due to some compatibility concerns. You can read the Steering Council communication about it [here]( https://mail.python.org/archives/list/[email protected]/thread/CLVXXPQ2T2LQ5MP2Y53VVQFCXYWQJHKZ/) to learn more. # More resources * [Changelog](https://docs.python.org/3.10/whatsnew/changelog.html#changelog ) * [Online Documentation](https://docs.python.org/3.10/) * [PEP 619](https://www.python.org/dev/peps/pep-0619/), 3.10 Release Schedule * Report bugs at [https://bugs.python.org](https://bugs.python.org). * [Help fund Python and its community](/psf/donations/). # And now for something completely different The Meissner effect (or Meissner–Ochsenfeld effect) is the expulsion of a magnetic field from a superconductor during its transition to the superconducting state when it is cooled below the critical temperature. This expulsion will repel a nearby magnet. The German physicists Walther Meissner and Robert Ochsenfeld discovered this phenomenon in 1933 by measuring the magnetic field distribution outside superconducting tin and lead samples. The experiment demonstrated for the first time that superconductors were more than just perfect conductors and provided a uniquely defining property of the superconductor state. The ability for the expulsion effect is determined by the nature of equilibrium formed by the neutralization within the unit cell of a superconductor. You can do [ver cool things](https://www.youtube.com/watch?v=HRLvVkkq5GE) with it! # We hope you enjoy the new releases! Thanks to all of the many volunteers who help make Python Development and these releases possible! Please consider supporting our efforts by volunteering yourself or through organization contributions to the Python Software Foundation. https://www.python.org/psf/ Your friendly release team, Ned Deily @nad https://discuss.python.org/u/nad Steve Dower @steve.dower https://discuss.python.org/u/steve.dower Pablo Galindo Salgado @pablogsal https://discuss.python.org/u/pablogsal -- https://mail.python.org/mailman/listinfo/python-list
