Re-use of standard library across implementations

Okay, I would like to submit a PEP for the idea of categorizing the standard library into subfolders. Is there a core developer who would like to sponsor me on this PEP?

First hi all , and pardon me if i mess up with post rules since i’m new to this. I’m also a portability “extremist” so i don’t expect people to even like my position.

You can even go a bit further and say : does the the python standard library belong to the CPython implementation for supported platforms ?

cpython itself can’t even load its own library on android or wasm, an obvious example is “asyncio” pulling threading and multiprocessing that are forbidden on WASI/WASM
it can get not only hard to get a stdlib for a new VM but for porting cpython itself too …

Thanks for all the past and future platforms what will never get decent cpython support then. (Pardon me but i will really laugh out loud if micropython node makes it in visual code before cpython)

indeed, that’s exactly why i love micropython VM attitude, C modules are just forbidden to enter core or platform support (called ports) until it’s proven to be really not possible to have a pure python counterpart FIRST even a very slow one.

The stdlib - really - bored me both on Android kitkat and ASM.js - especially asyncio - ( and still is on WASM) and that’s why i embraced micropython and it’s asyncio “light”. For writing python tools on win32 i use MSYS2 cpython3 and can’t wait for midipix to be released since i don’t even want to hear of msvc stdlib “features” anymore when i just want to open … an UART in 2018!.

i don’t have time to lose for that i want to have fun, not go back in my old dayjob (useless) porting nightmares.

Alan since you want my opinion, i’d say any stdlib not able to run on a WASI polyfill or strict POSIX ( including aio but without pthread ) is of very low interest for the future (yes i’m looking at you win32 ).

aio:
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/aio.h.html
wasi:

pure python stdlibs are wanted:



https://github.com/pmp-p/pydk/tree/master/sources.em uses a pure python stdlib and threadless asyncio.

We decided some time ago that CPython would require threading support from the OS. This eases maintenance a lot for us. You may take a different stance based on which platforms you are interested in, and it’s fine to use (or even write) a different implementation for that purpose. But I think we’re unlikely to switch back to make threading support optional.

Hmm, so what? Personally I don’t care whether Visual Code (I assume you’re talking about the text editor) has a “micropython node” or whatever else. I don’t think you’ll find any CPython core developer who gets frustrated at the idea that other implementations may be selected for specific use cases…

Well, that’s your opinion about the future :wink: Other opinions are valid. For example, personally, I think a platform that doesn’t offer any kind of threading support isn’t very interesting as a general-purpose computing platform.

Well, a bunch of people have been saying that for many years, and it still seems to have trouble happening. Perhaps there’s a reason why. Perhaps it’s not that easy, and there’s a scarcity of people willing to do the necessary hard work. But pressuring CPython developers to do it for you won’t work either.

Sometimes we may rewrite C code as Python code when it helps make the code better-architected, more reasonable to maintain, evolve and think about (e.g. importlib or zipimport). However, in many cases, there is no such concern, and rewriting C code that works fine and that’s performant into pure Python is not our priority.

You may find other projects that have priorities more aligned with yours. Good, so why not use those projects and contribute to them? At the moment, you sound like someone who complains to the Linux developers that they didn’t choose the same priorities as NetBSD…

Yeah, as i said at the top “i don’t expect people to even like my position”.

But just to be clear as OP is talking of an STDLIB written in Python not cpython written in C and C dependants stdlibs bits.

Sorry but Python3 is Python3 to me i don’t care about VM implementation l leave that to core dev of rust / java / javascript / C / C++ / whatever the VM is.

for my few needs, i can (try to) write my own preemtible stackless vm instead of going complaining in bpo/ideas/else ( but i love to rant loud on IRC some french people know that already).
So far as i’m concerned i use cpython3.7+ when i need it for Panda3d and it does its job to the perfection *

helloworld.c give same result on GNU/Linux or any BSD flavour or wasi platform/ internet browser, but yeah even with my poor C skills i know that’s more about stdio and not C stdlib.

So - and i mean no disrespect, it’s just light mood criticism - please let’s build more cpython toolchains and transpilers for each platform available to have the best optimized low level stdlibs ever with handcrafted bleeding edge Python opcodes pulling direct syscalls no other VM can afford paid dev. to implement.

indeed, i’m aligned with people who want to write and SHARE Python portable code. not put cpython non portable code to the freezer**.

I love all pythons vm equally, but it would be really nice if they could live in the same stdlib.

  • on supported platforms.
    ** except for supported platforms.

@pmp-p I edited your post to remove some inappropriate comparisons, without changing the meaning. Please keep in mind that this forum has a diverse international audience, and keep things professional. Thanks!

@njs, thanks for clarification i’ll try to keep that in mind :slight_smile:

Usually, how is this writing effort coordinated? Do you recommend some online tool?

And: is ok to start writing or is advisable to wait for a core developer sponsorship before start a draft?

Personally, I’d like to see some more detail before sponsoring this. I think writing up a draft so people can understand your approach and its tradeoffs would be important in this case.

1 Like