ericsnowcurrently

from collections import namedtuple
import logging
import os
import os.path
import re
import shutil
import subprocess
import sys
import textwrap
import time

ericsnowcurrently

⭐ - important ⬆️ - high priority ⬇️ - low priority ▫️ - normal priority

📅 - old 🥚 - new ▫️- neither

🔷 - regular contributor

ericsnowcurrently

Some of the recent discussion on DPO and discord got me thinking about the release workflow relative to locking branches and creating temporary ones and making some PRs wait through the whole RC phase.

As a result, I've thought of various possible workflows and about what might work well. We've used at least some of these for past releases, though not all. (I don't recall which approach was used for which release.)

Here are the workflows I thought of:

	3.X branch	temp branch	critical/docs PRs	other PRs
1	stays locked	---	merged by RM (3.X)	wait until final
2	only locked during release	---	merged by committers (3.X)	wait until final

ericsnowcurrently

Summary:

• C-API takes opaque context type as first arg
• context is as specific as possible
• separate Py_Main() from runtime initialization
• separate global init from interpreter init
• explicit enabling/disabling runtime components

Background Info

ericsnowcurrently

PyConfig API

most relevant:

• PyConfig (struct)
• Py_InitializeFromConfig()
• PyInterpreterState.config
• _PyInterpreterState_GetConfig()
• _Py_GetMainConfig()

ericsnowcurrently

_PyRuntimeState_GetThreadState()
    _PyRuntime.gilstate.tstate_current                                                                                  <----


_PyRuntimeGILState_GetThreadState()
    _PyRuntime.gilstate.tstate_current                                                                                  <----


_PyRuntimeGILState_SetThreadState(tstate)
    _PyRuntime.gilstate.tstate_current = tstate                                                                         <----

ericsnowcurrently

Comparing:

left: https://github.com/Kronuz/cpython/commit/553d3c10172254b190078c50eb9f8e60522c8f41 right: https://github.com/Kronuz/cpython/commit/44b7e9b87676e0bccde43103a4c954c8d79de017 (aka kronuz/lazy_imports)

No change in performance

$ bench-jobs compare req-compile-bench-1666307353-esnow-linux req-compile-bench-1666307369-esnow-linux
[snip]

ericsnowcurrently

import contextlib
import os
import sys


try:
    from io import StringIO as StdioStream
except ImportError:
    from StringIO import StringIO  # 2.7
    class StdioStream(StringIO):

ericsnowcurrently

"""
This is a script for working around the lack of ensurepip in
Ubuntu's system Python installs.
See: https://bugs.launchpad.net/ubuntu/+source/python3.4/+bug/1290847

An alternative is the following:

  $ python3 -m venv --without-pip my-venv
  $ curl https://bootstrap.pypa.io/get-pip.py
  $ my-venv/bin/python3 get-pip.py

ericsnowcurrently

API Shape for the Environments Discovery Component

Requirements

The environment component  API should support following:

1. Discover installed python interpreters: This includes identifying interpreter
   details like name, version, bit-ness, interpreter paths