multi-python / last-standard

The latest version of the standard library can be used in the same way as the old version of Python.
MIT License
0 stars 0 forks source link

[meta] Technical design discussion #2

Open frostming opened 3 years ago

frostming commented 3 years ago

Before starting implementing backports modules, we need to first decide how it should go. Here are some suggestions from my point of view, while others can comment to recommend alternatives.

The project name

last standard just doesn't look good to me. It is indeed "Latest" not "Last". We should pick another name for it as the PyPI canonical name, I am not good at it though. As it is going to be the name for multiple child packages, I don't recommend any name more than a single word. Some candidates I can think of that are not occupied:

  1. norme (French for "standard")
  2. ?(Unfortunately other names that come from my mind are occupied)
  3. A word coming from traditional Chinese(as you did before) with the meaning of 1) "Reducing the differences, shims or something" or 2) "Standard, normalized".

Distribution

  1. It should be a number of individual packages, each of which is a backport of a particular module/package from stdlilb. They are shipped to the end-user on their own. Downstream projects can choose from them instead of installing them all.
  2. These packages(will be referred to as "shims" afterward) must be distributed under a PEP420 namespace package with the name decided in the above topic.
  3. The package should take effect when installed, we will define an entry point group and each shim will register their entry points. So there should be a core package under the namespace to bootstrap all shims when Python starts up, this package must be depended on by all shims and be installed if any of the shims are installed. the core library will scan all submodules under that namespace and load them correctly.
  4. The core package will be shipped with a .pth file, to bootstrap all shims. It will register an import hook so that shims will be loaded, it is also responsible for clearing the existing caches in sys.modules.

Requirements for a shim

abersheeran commented 3 years ago

Basically agree. It should be split into multiple packages, which can be collectively called stdlib.xxx.

abersheeran commented 3 years ago

Each patch library of the standard library corresponds to a stdlib.xxxxx, such as stdlib.datetime. The version number composition should be python minor version + number. For example, 3.10.x means that this version of the patch library corresponds to the 3.10 version of the standard library implementation.

frostming commented 3 years ago

It seems stdlib is already taken. Agree with the version number part.

abersheeran commented 3 years ago

stdlib is a empty package. And we can use like stdlib.datetimestdlib.importlib

frostming commented 3 years ago

If we are to use namespace packages, that will cause namespace conflict, we need to ensure all submodules stdlib.xxx are shimmed modules, not anything else.

abersheeran commented 3 years ago

Why will have namespace conflict? It's just pypi package name, not module name in site-packages.

frostming commented 3 years ago

For a namespace package, the file is structure is as follows:

stdlib
    importlib
        __init__.py
    subprocess
        __init__.py
    collections
        __init__.py

Each child package installs a submodule into the stdlib parent folder(If you are not going to pick another name). It is designed to enable auto-discovery, so it shouldn't contain other non-shim modules.

BTW, if you think a meeting is necessary, let's arrange one.

abersheeran commented 3 years ago

I agree. Then we should make a template repository for stdlib.xxx.