[3.11] Fix v3.11.0 release merge problems (GH-98622)

When merging the v3.11.0 tag into 3.11, some files were incorrectly updated and some others were not properly deleted.

Automerge-Triggered-By: GH:pablogsal

Author: pablogsal

Doc/library/venv.rst

@@ -129,19 +129,6 @@ You can deactivate a virtual environment by typing ``deactivate`` in your shell.
 The exact mechanism is platform-specific and is an internal implementation
 detail (typically, a script or shell function will be used).
 
-.. warning:: Because scripts installed in environments should not expect the
-   environment to be activated, their shebang lines contain the absolute paths
-   to their environment's interpreters. Because of this, environments are
-   inherently non-portable, in the general case. You should always have a
-   simple means of recreating an environment (for example, if you have a
-   requirements file ``requirements.txt``, you can invoke ``pip install -r
-   requirements.txt`` using the environment's ``pip`` to install all of the
-   packages needed by the environment). If for any reason you need to move the
-   environment to a new location, you should recreate it at the desired
-   location and delete the one at the old location. If you move an environment
-   because you moved a parent directory of it, you should recreate the
-   environment in its new location. Otherwise, software installed into the
-   environment may not work as expected.
 
 .. _venv-api:
 

Doc/whatsnew/3.11.rst

@@ -4,6 +4,7 @@
 
 :Release: |release|
 :Date: |today|
+:Editor: Pablo Galindo Salgado
 
 .. Rules for maintenance:
 
@@ -1590,10 +1591,6 @@ Changed/removed opcodes
   :opcode:`!POP_BLOCK`, :opcode:`!SETUP_FINALLY` and :opcode:`!YIELD_FROM`.
 
 
-.. _whatsnew311-deprecated:
-.. _whatsnew311-python-api-deprecated:
-
-
 .. _whatsnew311-deprecated:
 .. _whatsnew311-python-api-deprecated:
 
@@ -1769,9 +1766,6 @@ Standard Library
   (Contributed by Erlend E. Aasland in :issue:`5846`.)
 
 
-.. _whatsnew311-pending-removal:
-.. _whatsnew311-python-api-pending-removal:
-
 .. _whatsnew311-pending-removal:
 .. _whatsnew311-python-api-pending-removal:
 

Include/patchlevel.h

@@ -23,7 +23,7 @@
 #define PY_RELEASE_SERIAL       0
 
 /* Version as a string */
-#define PY_VERSION              "3.11.0rc2+"
+#define PY_VERSION              "3.11.0+"
 /*--end constants--*/
 
 /* Version as a single 4-byte hex number, e.g. 0x010502B2 == 1.5.2b2.

Lib/test/test_frame.py

@@ -326,69 +326,5 @@ def f():
                 gc.enable()
 
 
-    @support.cpython_only
-    def test_sneaky_frame_object(self):
-
-        def trace(frame, event, arg):
-            """
-            Don't actually do anything, just force a frame object to be created.
-            """
-
-        def callback(phase, info):
-            """
-            Yo dawg, I heard you like frames, so I'm allocating a frame while
-            you're allocating a frame, so you can have a frame while you have a
-            frame!
-            """
-            nonlocal sneaky_frame_object
-            sneaky_frame_object = sys._getframe().f_back
-            # We're done here:
-            gc.callbacks.remove(callback)
-
-        def f():
-            while True:
-                yield
-
-        old_threshold = gc.get_threshold()
-        old_callbacks = gc.callbacks[:]
-        old_enabled = gc.isenabled()
-        old_trace = sys.gettrace()
-        try:
-            # Stop the GC for a second while we set things up:
-            gc.disable()
-            # Create a paused generator:
-            g = f()
-            next(g)
-            # Move all objects to the oldest generation, and tell the GC to run
-            # on the *very next* allocation:
-            gc.collect()
-            gc.set_threshold(1, 0, 0)
-            # Okay, so here's the nightmare scenario:
-            # - We're tracing the resumption of a generator, which creates a new
-            #   frame object.
-            # - The allocation of this frame object triggers a collection
-            #   *before* the frame object is actually created.
-            # - During the collection, we request the exact same frame object.
-            #   This test does it with a GC callback, but in real code it would
-            #   likely be a trace function, weakref callback, or finalizer.
-            # - The collection finishes, and the original frame object is
-            #   created. We now have two frame objects fighting over ownership
-            #   of the same interpreter frame!
-            sys.settrace(trace)
-            gc.callbacks.append(callback)
-            sneaky_frame_object = None
-            gc.enable()
-            next(g)
-            # g.gi_frame should be the the frame object from the callback (the
-            # one that was *requested* second, but *created* first):
-            self.assertIs(g.gi_frame, sneaky_frame_object)
-        finally:
-            gc.set_threshold(*old_threshold)
-            gc.callbacks[:] = old_callbacks
-            sys.settrace(old_trace)
-            if old_enabled:
-                gc.enable()
-
-
 if __name__ == "__main__":
     unittest.main()