gh-126631: gh-137996: fix pre-loading of `__main__`
The `main_path` parameter was renamed `init_main_from_name`, update the
forkserver code accordingly. This was leading to slower startup times when people
were trying to preload the main module.
---------
Co-authored-by: Gregory P. Smith <greg@krypto.org>
fix potential hang.
It can happen that the child crashes right in the beginning for whatever reason. In this case, the parent will hang when writing into the pipe, because the child fd is not closed yet.
The normal pattern is to close the child fds right after the child proc is forked/executed/spawned, so when the child dies, then also the pipes will be closed, and there will be no hang (the parent gets SIGPIPE instead).
Like cygwin, MUSL defaults to utf-8 if no variables are set. I have no
idea if the existing tests pass on cygwin, but I made the modifications
such that I shouldn't break it if is. The additional checks needed for
MUSL are guarded by DEFAULT_LOCALE_IS_C being False. Based on this
flag, we expect utf-8 for the encodings and no coercion message, as
long as LC_ALL is not set to C. (That looks like a bit of an issue with
the test structure, but I'm not going to attempt to "fix" that.)
DEFAULT_ENCODING is intentionally not given a default since it is only
used when DEFAULT_LOCALE_IS_C is False, and if you use the flag you'll
need to set it.
After reading through issue 30672, looking at the source, and running a
test on Android, I *think* the current situation is that coercion will
be done if the local is set to POSIX regardless of platform. However,
if the platform doesn't make POSIX equivalent to C, the encodings when
coercion is disabled will not be the same as for C (it is utf-8 on
android, for example). This means the tests would fail if POSIX were
added unconditionally to the EXPECTED_C_LOCALE_EQUIVALENTS as envisioned
in the issue. This *could* be fixed with another flag, but I'm not sure
it is worth the effort. I'm not even sure Python is behaving optimally
in this case (assuming my analysis is correct). So I just altered the
comment and add POSIX if and only if the platform is linux.
* Don't fail trying to parse weird patterns.
* Don't fail trying to decode non-UTF-8 "robots.txt" files.
* No longer ignore trailing "?" in patterns and URLs.
* Distinguish raw special characters "?", "=" and "&" from the
percent-encoded ones.
* Remove tests that do nothing.
It should interpret the result of wcsxfrm() as a sequence of abstract
integers, not a sequence of Unicode code points or using other encoding
scheme that does not preserve ordering.
