https://github.com/python/cpython/commit/49aec1a185bb2087fc4d846bd38d9150a3…
commit: 49aec1a185bb2087fc4d846bd38d9150a357cfbd
branch: master
author: Ethan Furman <ethan(a)stoneleaf.us>
committer: ethanfurman <ethan(a)stoneleaf.us>
date: 2021-03-31T09:20:08-07:00
summary:
Enum: add (re)import of Flag for doctests (GH-25118)
Fix issue with CI doctest forgetting that ``Flag`` had already been imported.
files:
M Doc/library/enum.rst
diff --git a/Doc/library/enum.rst b/Doc/library/enum.rst
index 3a6b2aa2c50cd..bc88303b789de 100644
--- a/Doc/library/enum.rst
+++ b/Doc/library/enum.rst
@@ -518,7 +518,7 @@ Data Types
Out-of-range values cause a :exc:`ValueError` to be raised. This is the
default for :class:`Flag`::
- >>> from enum import STRICT
+ >>> from enum import Flag, STRICT
>>> class StrictFlag(Flag, boundary=STRICT):
... RED = auto()
... GREEN = auto()
@@ -535,7 +535,7 @@ Data Types
Out-of-range values have invalid values removed, leaving a valid *Flag*
value::
- >>> from enum import CONFORM
+ >>> from enum import Flag, CONFORM
>>> class ConformFlag(Flag, boundary=CONFORM):
... RED = auto()
... GREEN = auto()
@@ -548,7 +548,7 @@ Data Types
Out-of-range values lose their *Flag* membership and revert to :class:`int`.
This is the default for :class:`IntFlag`::
- >>> from enum import EJECT
+ >>> from enum import Flag, EJECT
>>> class EjectFlag(Flag, boundary=EJECT):
... RED = auto()
... GREEN = auto()
@@ -561,7 +561,7 @@ Data Types
Out-of-range values are kept, and the *Flag* membership is kept. This is
used for some stdlib flags:
- >>> from enum import KEEP
+ >>> from enum import Flag, KEEP
>>> class KeepFlag(Flag, boundary=KEEP):
... RED = auto()
... GREEN = auto()
https://github.com/python/cpython/commit/202b54644245afadf124d8043688a95d4d…
commit: 202b54644245afadf124d8043688a95d4d9c456d
branch: master
author: Julien Palard <julien(a)palard.fr>
committer: JulienPalard <julien(a)palard.fr>
date: 2021-03-31T14:31:38+02:00
summary:
Disambiguate that -m also terminates the option list in the manpage. (GH-25100)
files:
M Misc/python.man
diff --git a/Misc/python.man b/Misc/python.man
index 225376574a26a..3ea1801c644ca 100644
--- a/Misc/python.man
+++ b/Misc/python.man
@@ -165,7 +165,8 @@ Searches
.I sys.path
for the named module and runs the corresponding
.I .py
-file as a script.
+file as a script. This terminates the option list (following options
+are passed as arguments to the module).
.TP
.B \-O
Remove assert statements and any code conditional on the value of
https://github.com/python/cpython/commit/027d2cf1e5e2512888340b4cd5d2f1b5a3…
commit: 027d2cf1e5e2512888340b4cd5d2f1b5a3e8af94
branch: master
author: Łukasz Langa <lukasz(a)langa.pl>
committer: ambv <lukasz(a)langa.pl>
date: 2021-03-31T12:22:37+02:00
summary:
Document GH-24624
files:
A Misc/NEWS.d/next/Build/2021-03-31-12-20-23.bpo-43179.Qbe1OD.rst
diff --git a/Misc/NEWS.d/next/Build/2021-03-31-12-20-23.bpo-43179.Qbe1OD.rst b/Misc/NEWS.d/next/Build/2021-03-31-12-20-23.bpo-43179.Qbe1OD.rst
new file mode 100644
index 0000000000000..2d22d47208215
--- /dev/null
+++ b/Misc/NEWS.d/next/Build/2021-03-31-12-20-23.bpo-43179.Qbe1OD.rst
@@ -0,0 +1,3 @@
+Introduce and correctly use ALIGNOF_X in place of SIZEOF_X for
+alignment-related code in optimized string routines. Patch by Jessica
+Clarke.
\ No newline at end of file
https://github.com/python/cpython/commit/dec075754960dd85972ce5170df76e862f…
commit: dec075754960dd85972ce5170df76e862f966132
branch: master
author: Jessica Clarke <jrtc27(a)jrtc27.com>
committer: ambv <lukasz(a)langa.pl>
date: 2021-03-31T12:12:39+02:00
summary:
bpo-43179: Generalise alignment for optimised string routines (GH-24624)
* Remove m68k-specific hack from ascii_decode
On m68k, alignments of primitives is more relaxed, with 4-byte and
8-byte types only requiring 2-byte alignment, thus using sizeof(size_t)
does not work. Instead, use the portable alternative.
Note that this is a minimal fix that only relaxes the assertion and the
condition for when to use the optimised version remains overly strict.
Such issues will be fixed tree-wide in the next commit.
NB: In C11 we could use _Alignof(size_t) instead, but for compatibility
we use autoconf.
* Optimise string routines for architectures with non-natural alignment
C only requires that sizeof(x) is a multiple of alignof(x), not that the
two are equal. Thus anywhere where we optimise based on alignment we
should be using alignof(x) not sizeof(x).
This is more annoying than it would be in C11 where we could just use
_Alignof(x) (and alignof(x) in C++11), but since we still require only
C99 we must plumb the information all the way from autoconf through the
various typedefs and defines.
files:
M Objects/bytes_methods.c
M Objects/stringlib/codecs.h
M Objects/stringlib/find_max_char.h
M Objects/unicodeobject.c
M PC/pyconfig.h
M configure
M configure.ac
M pyconfig.h.in
diff --git a/Objects/bytes_methods.c b/Objects/bytes_methods.c
index 1512086e6131f..994fb8a73c6cd 100644
--- a/Objects/bytes_methods.c
+++ b/Objects/bytes_methods.c
@@ -115,15 +115,14 @@ _Py_bytes_isascii(const char *cptr, Py_ssize_t len)
{
const char *p = cptr;
const char *end = p + len;
- const char *aligned_end = (const char *) _Py_ALIGN_DOWN(end, SIZEOF_SIZE_T);
while (p < end) {
/* Fast path, see in STRINGLIB(utf8_decode) in stringlib/codecs.h
for an explanation. */
- if (_Py_IS_ALIGNED(p, SIZEOF_SIZE_T)) {
+ if (_Py_IS_ALIGNED(p, ALIGNOF_SIZE_T)) {
/* Help allocation */
const char *_p = p;
- while (_p < aligned_end) {
+ while (_p + SIZEOF_SIZE_T <= end) {
size_t value = *(const size_t *) _p;
if (value & ASCII_CHAR_MASK) {
Py_RETURN_FALSE;
diff --git a/Objects/stringlib/codecs.h b/Objects/stringlib/codecs.h
index b6ca404b1a2d7..b17cda18f54b3 100644
--- a/Objects/stringlib/codecs.h
+++ b/Objects/stringlib/codecs.h
@@ -26,7 +26,6 @@ STRINGLIB(utf8_decode)(const char **inptr, const char *end,
{
Py_UCS4 ch;
const char *s = *inptr;
- const char *aligned_end = (const char *) _Py_ALIGN_DOWN(end, SIZEOF_SIZE_T);
STRINGLIB_CHAR *p = dest + *outpos;
while (s < end) {
@@ -40,11 +39,11 @@ STRINGLIB(utf8_decode)(const char **inptr, const char *end,
First, check if we can do an aligned read, as most CPUs have
a penalty for unaligned reads.
*/
- if (_Py_IS_ALIGNED(s, SIZEOF_SIZE_T)) {
+ if (_Py_IS_ALIGNED(s, ALIGNOF_SIZE_T)) {
/* Help register allocation */
const char *_s = s;
STRINGLIB_CHAR *_p = p;
- while (_s < aligned_end) {
+ while (_s + SIZEOF_SIZE_T <= end) {
/* Read a whole size_t at a time (either 4 or 8 bytes),
and do a fast unrolled copy if it only contains ASCII
characters. */
@@ -496,8 +495,6 @@ STRINGLIB(utf16_decode)(const unsigned char **inptr, const unsigned char *e,
int native_ordering)
{
Py_UCS4 ch;
- const unsigned char *aligned_end =
- (const unsigned char *) _Py_ALIGN_DOWN(e, SIZEOF_LONG);
const unsigned char *q = *inptr;
STRINGLIB_CHAR *p = dest + *outpos;
/* Offsets from q for retrieving byte pairs in the right order. */
@@ -512,10 +509,10 @@ STRINGLIB(utf16_decode)(const unsigned char **inptr, const unsigned char *e,
Py_UCS4 ch2;
/* First check for possible aligned read of a C 'long'. Unaligned
reads are more expensive, better to defer to another iteration. */
- if (_Py_IS_ALIGNED(q, SIZEOF_LONG)) {
+ if (_Py_IS_ALIGNED(q, ALIGNOF_LONG)) {
/* Fast path for runs of in-range non-surrogate chars. */
const unsigned char *_q = q;
- while (_q < aligned_end) {
+ while (_q + SIZEOF_LONG <= e) {
unsigned long block = * (const unsigned long *) _q;
if (native_ordering) {
/* Can use buffer directly */
diff --git a/Objects/stringlib/find_max_char.h b/Objects/stringlib/find_max_char.h
index 3319a46461451..b9ffdfc2e352c 100644
--- a/Objects/stringlib/find_max_char.h
+++ b/Objects/stringlib/find_max_char.h
@@ -20,14 +20,12 @@ Py_LOCAL_INLINE(Py_UCS4)
STRINGLIB(find_max_char)(const STRINGLIB_CHAR *begin, const STRINGLIB_CHAR *end)
{
const unsigned char *p = (const unsigned char *) begin;
- const unsigned char *aligned_end =
- (const unsigned char *) _Py_ALIGN_DOWN(end, SIZEOF_SIZE_T);
while (p < end) {
- if (_Py_IS_ALIGNED(p, SIZEOF_SIZE_T)) {
+ if (_Py_IS_ALIGNED(p, ALIGNOF_SIZE_T)) {
/* Help register allocation */
const unsigned char *_p = p;
- while (_p < aligned_end) {
+ while (_p + SIZEOF_SIZE_T <= end) {
size_t value = *(const size_t *) _p;
if (value & UCS1_ASCII_CHAR_MASK)
return 255;
diff --git a/Objects/unicodeobject.c b/Objects/unicodeobject.c
index a7a3151547099..f6bf505b7fc74 100644
--- a/Objects/unicodeobject.c
+++ b/Objects/unicodeobject.c
@@ -5070,25 +5070,16 @@ static Py_ssize_t
ascii_decode(const char *start, const char *end, Py_UCS1 *dest)
{
const char *p = start;
- const char *aligned_end = (const char *) _Py_ALIGN_DOWN(end, SIZEOF_SIZE_T);
-
- /*
- * Issue #17237: m68k is a bit different from most architectures in
- * that objects do not use "natural alignment" - for example, int and
- * long are only aligned at 2-byte boundaries. Therefore the assert()
- * won't work; also, tests have shown that skipping the "optimised
- * version" will even speed up m68k.
- */
-#if !defined(__m68k__)
+
#if SIZEOF_SIZE_T <= SIZEOF_VOID_P
- assert(_Py_IS_ALIGNED(dest, SIZEOF_SIZE_T));
- if (_Py_IS_ALIGNED(p, SIZEOF_SIZE_T)) {
+ assert(_Py_IS_ALIGNED(dest, ALIGNOF_SIZE_T));
+ if (_Py_IS_ALIGNED(p, ALIGNOF_SIZE_T)) {
/* Fast path, see in STRINGLIB(utf8_decode) for
an explanation. */
/* Help allocation */
const char *_p = p;
Py_UCS1 * q = dest;
- while (_p < aligned_end) {
+ while (_p + SIZEOF_SIZE_T <= end) {
size_t value = *(const size_t *) _p;
if (value & ASCII_CHAR_MASK)
break;
@@ -5104,15 +5095,14 @@ ascii_decode(const char *start, const char *end, Py_UCS1 *dest)
}
return p - start;
}
-#endif
#endif
while (p < end) {
/* Fast path, see in STRINGLIB(utf8_decode) in stringlib/codecs.h
for an explanation. */
- if (_Py_IS_ALIGNED(p, SIZEOF_SIZE_T)) {
+ if (_Py_IS_ALIGNED(p, ALIGNOF_SIZE_T)) {
/* Help allocation */
const char *_p = p;
- while (_p < aligned_end) {
+ while (_p + SIZEOF_SIZE_T <= end) {
size_t value = *(const size_t *) _p;
if (value & ASCII_CHAR_MASK)
break;
diff --git a/PC/pyconfig.h b/PC/pyconfig.h
index 00a65b223da17..103e647ac8321 100644
--- a/PC/pyconfig.h
+++ b/PC/pyconfig.h
@@ -289,6 +289,7 @@ Py_NO_ENABLE_SHARED to find out. Also support MS_NO_COREDLL for b/w compat */
# define SIZEOF_FPOS_T 8
# define SIZEOF_HKEY 8
# define SIZEOF_SIZE_T 8
+# define ALIGNOF_SIZE_T 8
/* configure.ac defines HAVE_LARGEFILE_SUPPORT iff
sizeof(off_t) > sizeof(long), and sizeof(long long) >= sizeof(off_t).
On Win64 the second condition is not true, but if fpos_t replaces off_t
@@ -303,6 +304,7 @@ Py_NO_ENABLE_SHARED to find out. Also support MS_NO_COREDLL for b/w compat */
# define SIZEOF_FPOS_T 8
# define SIZEOF_HKEY 4
# define SIZEOF_SIZE_T 4
+# define ALIGNOF_SIZE_T 4
/* MS VS2005 changes time_t to a 64-bit type on all platforms */
# if defined(_MSC_VER) && _MSC_VER >= 1400
# define SIZEOF_TIME_T 8
@@ -321,6 +323,7 @@ Py_NO_ENABLE_SHARED to find out. Also support MS_NO_COREDLL for b/w compat */
#define SIZEOF_SHORT 2
#define SIZEOF_INT 4
#define SIZEOF_LONG 4
+#define ALIGNOF_LONG 4
#define SIZEOF_LONG_LONG 8
#define SIZEOF_DOUBLE 8
#define SIZEOF_FLOAT 4
diff --git a/configure b/configure
index 6ba109b3754c7..34a19a11a89c6 100755
--- a/configure
+++ b/configure
@@ -8644,7 +8644,7 @@ $as_echo "#define HAVE_GCC_UINT128_T 1" >>confdefs.h
fi
-# Sizes of various common basic types
+# Sizes and alignments of various common basic types
# ANSI C requires sizeof(char) == 1, so no need to check it
# The cast to long int works around a bug in the HP C Compiler
# version HP92453-01 B.11.11.23709.GP, which incorrectly rejects
@@ -8712,6 +8712,41 @@ cat >>confdefs.h <<_ACEOF
_ACEOF
+# The cast to long int works around a bug in the HP C Compiler,
+# see AC_CHECK_SIZEOF for more information.
+{ $as_echo "$as_me:${as_lineno-$LINENO}: checking alignment of long" >&5
+$as_echo_n "checking alignment of long... " >&6; }
+if ${ac_cv_alignof_long+:} false; then :
+ $as_echo_n "(cached) " >&6
+else
+ if ac_fn_c_compute_int "$LINENO" "(long int) offsetof (ac__type_alignof_, y)" "ac_cv_alignof_long" "$ac_includes_default
+#ifndef offsetof
+# define offsetof(type, member) ((char *) &((type *) 0)->member - (char *) 0)
+#endif
+typedef struct { char x; long y; } ac__type_alignof_;"; then :
+
+else
+ if test "$ac_cv_type_long" = yes; then
+ { { $as_echo "$as_me:${as_lineno-$LINENO}: error: in \`$ac_pwd':" >&5
+$as_echo "$as_me: error: in \`$ac_pwd':" >&2;}
+as_fn_error 77 "cannot compute alignment of long
+See \`config.log' for more details" "$LINENO" 5; }
+ else
+ ac_cv_alignof_long=0
+ fi
+fi
+
+fi
+{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_alignof_long" >&5
+$as_echo "$ac_cv_alignof_long" >&6; }
+
+
+
+cat >>confdefs.h <<_ACEOF
+#define ALIGNOF_LONG $ac_cv_alignof_long
+_ACEOF
+
+
# The cast to long int works around a bug in the HP C Compiler
# version HP92453-01 B.11.11.23709.GP, which incorrectly rejects
# declarations like `int a3[[(sizeof (unsigned char)) >= 0]];'.
@@ -8943,6 +8978,41 @@ cat >>confdefs.h <<_ACEOF
_ACEOF
+# The cast to long int works around a bug in the HP C Compiler,
+# see AC_CHECK_SIZEOF for more information.
+{ $as_echo "$as_me:${as_lineno-$LINENO}: checking alignment of size_t" >&5
+$as_echo_n "checking alignment of size_t... " >&6; }
+if ${ac_cv_alignof_size_t+:} false; then :
+ $as_echo_n "(cached) " >&6
+else
+ if ac_fn_c_compute_int "$LINENO" "(long int) offsetof (ac__type_alignof_, y)" "ac_cv_alignof_size_t" "$ac_includes_default
+#ifndef offsetof
+# define offsetof(type, member) ((char *) &((type *) 0)->member - (char *) 0)
+#endif
+typedef struct { char x; size_t y; } ac__type_alignof_;"; then :
+
+else
+ if test "$ac_cv_type_size_t" = yes; then
+ { { $as_echo "$as_me:${as_lineno-$LINENO}: error: in \`$ac_pwd':" >&5
+$as_echo "$as_me: error: in \`$ac_pwd':" >&2;}
+as_fn_error 77 "cannot compute alignment of size_t
+See \`config.log' for more details" "$LINENO" 5; }
+ else
+ ac_cv_alignof_size_t=0
+ fi
+fi
+
+fi
+{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_alignof_size_t" >&5
+$as_echo "$ac_cv_alignof_size_t" >&6; }
+
+
+
+cat >>confdefs.h <<_ACEOF
+#define ALIGNOF_SIZE_T $ac_cv_alignof_size_t
+_ACEOF
+
+
# The cast to long int works around a bug in the HP C Compiler
# version HP92453-01 B.11.11.23709.GP, which incorrectly rejects
# declarations like `int a3[[(sizeof (unsigned char)) >= 0]];'.
diff --git a/configure.ac b/configure.ac
index 0db7e60f31747..8b3ab1e16f6af 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2354,10 +2354,11 @@ AC_CHECK_TYPE(ssize_t,
AC_CHECK_TYPE(__uint128_t,
AC_DEFINE(HAVE_GCC_UINT128_T, 1, [Define if your compiler provides __uint128_t]),,)
-# Sizes of various common basic types
+# Sizes and alignments of various common basic types
# ANSI C requires sizeof(char) == 1, so no need to check it
AC_CHECK_SIZEOF(int, 4)
AC_CHECK_SIZEOF(long, 4)
+AC_CHECK_ALIGNOF(long)
AC_CHECK_SIZEOF(long long, 8)
AC_CHECK_SIZEOF(void *, 4)
AC_CHECK_SIZEOF(short, 2)
@@ -2365,6 +2366,7 @@ AC_CHECK_SIZEOF(float, 4)
AC_CHECK_SIZEOF(double, 8)
AC_CHECK_SIZEOF(fpos_t, 4)
AC_CHECK_SIZEOF(size_t, 4)
+AC_CHECK_ALIGNOF(size_t)
AC_CHECK_SIZEOF(pid_t, 4)
AC_CHECK_SIZEOF(uintptr_t)
diff --git a/pyconfig.h.in b/pyconfig.h.in
index b65004ee2e88a..9b713ac93e75e 100644
--- a/pyconfig.h.in
+++ b/pyconfig.h.in
@@ -16,6 +16,12 @@
support for AIX C++ shared extension modules. */
#undef AIX_GENUINE_CPLUSPLUS
+/* The normal alignment of `long', in bytes. */
+#undef ALIGNOF_LONG
+
+/* The normal alignment of `size_t', in bytes. */
+#undef ALIGNOF_SIZE_T
+
/* Alternative SOABI used in debug build to load C extensions built in release
mode */
#undef ALT_SOABI
https://github.com/python/cpython/commit/84694c3e7adadc97d7d8cee938fe84bbeb…
commit: 84694c3e7adadc97d7d8cee938fe84bbeb961387
branch: 3.9
author: Miss Islington (bot) <31488909+miss-islington(a)users.noreply.github.com>
committer: miss-islington <31488909+miss-islington(a)users.noreply.github.com>
date: 2021-03-30T22:44:26-07:00
summary:
bpo-42225: IDLE - document two unix-related problems. (GH-25078)
1. Bad IP masquerade rules can prevent startup.
2. X cannot handle some complex colored chars.
(cherry picked from commit 1b4a9c7956d5dc64f8002f62bf0faae2d1892f90)
Co-authored-by: Terry Jan Reedy <tjreedy(a)udel.edu>
files:
A Misc/NEWS.d/next/IDLE/2021-03-29-16-22-27.bpo-42225.iIeiLg.rst
M Doc/library/idle.rst
M Lib/idlelib/help.html
diff --git a/Doc/library/idle.rst b/Doc/library/idle.rst
index 2b9bd4b5daaa7..6ef15653eacb5 100644
--- a/Doc/library/idle.rst
+++ b/Doc/library/idle.rst
@@ -670,8 +670,16 @@ IDLE uses a socket to communicate between the IDLE GUI process and the user
code execution process. A connection must be established whenever the Shell
starts or restarts. (The latter is indicated by a divider line that says
'RESTART'). If the user process fails to connect to the GUI process, it
-displays a ``Tk`` error box with a 'cannot connect' message that directs the
-user here. It then exits.
+usually displays a ``Tk`` error box with a 'cannot connect' message
+that directs the user here. It then exits.
+
+One specific connection failure on Unix systems results from
+misconfigured masquerading rules somewhere in a system's network setup.
+When IDLE is started from a terminal, one will see a message starting
+with ``** Invalid host:``.
+The valid value is ``127.0.0.1 (idlelib.rpc.LOCALHOST)``.
+One can diagnose with ``tcpconnect -irv 127.0.0.1 6543`` in one
+terminal window and ``tcplisten <same args>`` in another.
A common cause of failure is a user-written file with the same name as a
standard library module, such as *random.py* and *tkinter.py*. When such a
@@ -709,6 +717,13 @@ If IDLE quits with no message, and it was not started from a console, try
starting it from a console or terminal (``python -m idlelib``) and see if
this results in an error message.
+On Unix-based systems with tcl/tk older than ``8.6.11`` (see
+``About IDLE``) certain characters of certain fonts can cause
+a tk failure with a message to the terminal. This can happen either
+if one starts IDLE to edit a file with such a character or later
+when entering such a character. If one cannot upgrade tcl/tk,
+then re-configure IDLE to use a font that works better.
+
Running user code
^^^^^^^^^^^^^^^^^
diff --git a/Lib/idlelib/help.html b/Lib/idlelib/help.html
index 924042d25b7ba..e80384b777522 100644
--- a/Lib/idlelib/help.html
+++ b/Lib/idlelib/help.html
@@ -5,7 +5,7 @@
<head>
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
- <title>IDLE — Python 3.10.0a5 documentation</title>
+ <title>IDLE — Python 3.10.0a6 documentation</title>
<link rel="stylesheet" href="../_static/pydoctheme.css" type="text/css" />
<link rel="stylesheet" href="../_static/pygments.css" type="text/css" />
@@ -18,7 +18,7 @@
<script src="../_static/sidebar.js"></script>
<link rel="search" type="application/opensearchdescription+xml"
- title="Search within Python 3.10.0a5 documentation"
+ title="Search within Python 3.10.0a6 documentation"
href="../_static/opensearch.xml"/>
<link rel="author" title="About these documents" href="../about.html" />
<link rel="index" title="Index" href="../genindex.html" />
@@ -71,7 +71,7 @@ <h3>Navigation</h3>
<li id="cpython-language-and-version">
- <a href="../index.html">3.10.0a5 Documentation</a> »
+ <a href="../index.html">3.10.0a6 Documentation</a> »
</li>
<li class="nav-item nav-item-1"><a href="index.html" >The Python Standard Library</a> »</li>
@@ -632,8 +632,15 @@ <h3>Startup failure<a class="headerlink" href="#startup-failure" title="Permalin
code execution process. A connection must be established whenever the Shell
starts or restarts. (The latter is indicated by a divider line that says
‘RESTART’). If the user process fails to connect to the GUI process, it
-displays a <code class="docutils literal notranslate"><span class="pre">Tk</span></code> error box with a ‘cannot connect’ message that directs the
-user here. It then exits.</p>
+usually displays a <code class="docutils literal notranslate"><span class="pre">Tk</span></code> error box with a ‘cannot connect’ message
+that directs the user here. It then exits.</p>
+<p>One specific connection failure on Unix systems results from
+misconfigured masquerading rules somewhere in a system’s network setup.
+When IDLE is started from a terminal, one will see a message starting
+with <code class="docutils literal notranslate"><span class="pre">**</span> <span class="pre">Invalid</span> <span class="pre">host:</span></code>.
+The valid value is <code class="docutils literal notranslate"><span class="pre">127.0.0.1</span> <span class="pre">(idlelib.rpc.LOCALHOST)</span></code>.
+One can diagnose with <code class="docutils literal notranslate"><span class="pre">tcpconnect</span> <span class="pre">-irv</span> <span class="pre">127.0.0.1</span> <span class="pre">6543</span></code> in one
+terminal window and <code class="docutils literal notranslate"><span class="pre">tcplisten</span> <span class="pre"><same</span> <span class="pre">args></span></code> in another.</p>
<p>A common cause of failure is a user-written file with the same name as a
standard library module, such as <em>random.py</em> and <em>tkinter.py</em>. When such a
file is located in the same directory as a file that is about to be run,
@@ -664,6 +671,12 @@ <h3>Startup failure<a class="headerlink" href="#startup-failure" title="Permalin
<p>If IDLE quits with no message, and it was not started from a console, try
starting it from a console or terminal (<code class="docutils literal notranslate"><span class="pre">python</span> <span class="pre">-m</span> <span class="pre">idlelib</span></code>) and see if
this results in an error message.</p>
+<p>On Unix-based systems with tcl/tk older than <code class="docutils literal notranslate"><span class="pre">8.6.11</span></code> (see
+<code class="docutils literal notranslate"><span class="pre">About</span> <span class="pre">IDLE</span></code>) certain characters of certain fonts can cause
+a tk failure with a message to the terminal. This can happen either
+if one starts IDLE to edit a file with such a character or later
+when entering such a character. If one cannot upgrade tcl/tk,
+then re-configure IDLE to use a font that works better.</p>
</div>
<div class="section" id="running-user-code">
<h3>Running user code<a class="headerlink" href="#running-user-code" title="Permalink to this headline">¶</a></h3>
@@ -958,7 +971,7 @@ <h3>Navigation</h3>
<li id="cpython-language-and-version">
- <a href="../index.html">3.10.0a5 Documentation</a> »
+ <a href="../index.html">3.10.0a6 Documentation</a> »
</li>
<li class="nav-item nav-item-1"><a href="index.html" >The Python Standard Library</a> »</li>
@@ -990,7 +1003,7 @@ <h3>Navigation</h3>
<br />
<br />
- Last updated on Feb 23, 2021.
+ Last updated on Mar 29, 2021.
<a href="https://docs.python.org/3/bugs.html">Found a bug</a>?
<br />
diff --git a/Misc/NEWS.d/next/IDLE/2021-03-29-16-22-27.bpo-42225.iIeiLg.rst b/Misc/NEWS.d/next/IDLE/2021-03-29-16-22-27.bpo-42225.iIeiLg.rst
new file mode 100644
index 0000000000000..59fb08bdf9ebe
--- /dev/null
+++ b/Misc/NEWS.d/next/IDLE/2021-03-29-16-22-27.bpo-42225.iIeiLg.rst
@@ -0,0 +1,2 @@
+Document that IDLE can fail on Unix either from misconfigured IP masquerage
+rules or failure displaying complex colored (non-ascii) characters.
https://github.com/python/cpython/commit/e92923b028024290a0e621b6b90e322176…
commit: e92923b028024290a0e621b6b90e3221767d14d4
branch: 3.8
author: Miss Islington (bot) <31488909+miss-islington(a)users.noreply.github.com>
committer: miss-islington <31488909+miss-islington(a)users.noreply.github.com>
date: 2021-03-30T22:40:09-07:00
summary:
bpo-42225: IDLE - document two unix-related problems. (GH-25078)
1. Bad IP masquerade rules can prevent startup.
2. X cannot handle some complex colored chars.
(cherry picked from commit 1b4a9c7956d5dc64f8002f62bf0faae2d1892f90)
Co-authored-by: Terry Jan Reedy <tjreedy(a)udel.edu>
files:
A Misc/NEWS.d/next/IDLE/2021-03-29-16-22-27.bpo-42225.iIeiLg.rst
M Doc/library/idle.rst
M Lib/idlelib/help.html
diff --git a/Doc/library/idle.rst b/Doc/library/idle.rst
index 2b9bd4b5daaa7..6ef15653eacb5 100644
--- a/Doc/library/idle.rst
+++ b/Doc/library/idle.rst
@@ -670,8 +670,16 @@ IDLE uses a socket to communicate between the IDLE GUI process and the user
code execution process. A connection must be established whenever the Shell
starts or restarts. (The latter is indicated by a divider line that says
'RESTART'). If the user process fails to connect to the GUI process, it
-displays a ``Tk`` error box with a 'cannot connect' message that directs the
-user here. It then exits.
+usually displays a ``Tk`` error box with a 'cannot connect' message
+that directs the user here. It then exits.
+
+One specific connection failure on Unix systems results from
+misconfigured masquerading rules somewhere in a system's network setup.
+When IDLE is started from a terminal, one will see a message starting
+with ``** Invalid host:``.
+The valid value is ``127.0.0.1 (idlelib.rpc.LOCALHOST)``.
+One can diagnose with ``tcpconnect -irv 127.0.0.1 6543`` in one
+terminal window and ``tcplisten <same args>`` in another.
A common cause of failure is a user-written file with the same name as a
standard library module, such as *random.py* and *tkinter.py*. When such a
@@ -709,6 +717,13 @@ If IDLE quits with no message, and it was not started from a console, try
starting it from a console or terminal (``python -m idlelib``) and see if
this results in an error message.
+On Unix-based systems with tcl/tk older than ``8.6.11`` (see
+``About IDLE``) certain characters of certain fonts can cause
+a tk failure with a message to the terminal. This can happen either
+if one starts IDLE to edit a file with such a character or later
+when entering such a character. If one cannot upgrade tcl/tk,
+then re-configure IDLE to use a font that works better.
+
Running user code
^^^^^^^^^^^^^^^^^
diff --git a/Lib/idlelib/help.html b/Lib/idlelib/help.html
index 924042d25b7ba..e80384b777522 100644
--- a/Lib/idlelib/help.html
+++ b/Lib/idlelib/help.html
@@ -5,7 +5,7 @@
<head>
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
- <title>IDLE — Python 3.10.0a5 documentation</title>
+ <title>IDLE — Python 3.10.0a6 documentation</title>
<link rel="stylesheet" href="../_static/pydoctheme.css" type="text/css" />
<link rel="stylesheet" href="../_static/pygments.css" type="text/css" />
@@ -18,7 +18,7 @@
<script src="../_static/sidebar.js"></script>
<link rel="search" type="application/opensearchdescription+xml"
- title="Search within Python 3.10.0a5 documentation"
+ title="Search within Python 3.10.0a6 documentation"
href="../_static/opensearch.xml"/>
<link rel="author" title="About these documents" href="../about.html" />
<link rel="index" title="Index" href="../genindex.html" />
@@ -71,7 +71,7 @@ <h3>Navigation</h3>
<li id="cpython-language-and-version">
- <a href="../index.html">3.10.0a5 Documentation</a> »
+ <a href="../index.html">3.10.0a6 Documentation</a> »
</li>
<li class="nav-item nav-item-1"><a href="index.html" >The Python Standard Library</a> »</li>
@@ -632,8 +632,15 @@ <h3>Startup failure<a class="headerlink" href="#startup-failure" title="Permalin
code execution process. A connection must be established whenever the Shell
starts or restarts. (The latter is indicated by a divider line that says
‘RESTART’). If the user process fails to connect to the GUI process, it
-displays a <code class="docutils literal notranslate"><span class="pre">Tk</span></code> error box with a ‘cannot connect’ message that directs the
-user here. It then exits.</p>
+usually displays a <code class="docutils literal notranslate"><span class="pre">Tk</span></code> error box with a ‘cannot connect’ message
+that directs the user here. It then exits.</p>
+<p>One specific connection failure on Unix systems results from
+misconfigured masquerading rules somewhere in a system’s network setup.
+When IDLE is started from a terminal, one will see a message starting
+with <code class="docutils literal notranslate"><span class="pre">**</span> <span class="pre">Invalid</span> <span class="pre">host:</span></code>.
+The valid value is <code class="docutils literal notranslate"><span class="pre">127.0.0.1</span> <span class="pre">(idlelib.rpc.LOCALHOST)</span></code>.
+One can diagnose with <code class="docutils literal notranslate"><span class="pre">tcpconnect</span> <span class="pre">-irv</span> <span class="pre">127.0.0.1</span> <span class="pre">6543</span></code> in one
+terminal window and <code class="docutils literal notranslate"><span class="pre">tcplisten</span> <span class="pre"><same</span> <span class="pre">args></span></code> in another.</p>
<p>A common cause of failure is a user-written file with the same name as a
standard library module, such as <em>random.py</em> and <em>tkinter.py</em>. When such a
file is located in the same directory as a file that is about to be run,
@@ -664,6 +671,12 @@ <h3>Startup failure<a class="headerlink" href="#startup-failure" title="Permalin
<p>If IDLE quits with no message, and it was not started from a console, try
starting it from a console or terminal (<code class="docutils literal notranslate"><span class="pre">python</span> <span class="pre">-m</span> <span class="pre">idlelib</span></code>) and see if
this results in an error message.</p>
+<p>On Unix-based systems with tcl/tk older than <code class="docutils literal notranslate"><span class="pre">8.6.11</span></code> (see
+<code class="docutils literal notranslate"><span class="pre">About</span> <span class="pre">IDLE</span></code>) certain characters of certain fonts can cause
+a tk failure with a message to the terminal. This can happen either
+if one starts IDLE to edit a file with such a character or later
+when entering such a character. If one cannot upgrade tcl/tk,
+then re-configure IDLE to use a font that works better.</p>
</div>
<div class="section" id="running-user-code">
<h3>Running user code<a class="headerlink" href="#running-user-code" title="Permalink to this headline">¶</a></h3>
@@ -958,7 +971,7 @@ <h3>Navigation</h3>
<li id="cpython-language-and-version">
- <a href="../index.html">3.10.0a5 Documentation</a> »
+ <a href="../index.html">3.10.0a6 Documentation</a> »
</li>
<li class="nav-item nav-item-1"><a href="index.html" >The Python Standard Library</a> »</li>
@@ -990,7 +1003,7 @@ <h3>Navigation</h3>
<br />
<br />
- Last updated on Feb 23, 2021.
+ Last updated on Mar 29, 2021.
<a href="https://docs.python.org/3/bugs.html">Found a bug</a>?
<br />
diff --git a/Misc/NEWS.d/next/IDLE/2021-03-29-16-22-27.bpo-42225.iIeiLg.rst b/Misc/NEWS.d/next/IDLE/2021-03-29-16-22-27.bpo-42225.iIeiLg.rst
new file mode 100644
index 0000000000000..59fb08bdf9ebe
--- /dev/null
+++ b/Misc/NEWS.d/next/IDLE/2021-03-29-16-22-27.bpo-42225.iIeiLg.rst
@@ -0,0 +1,2 @@
+Document that IDLE can fail on Unix either from misconfigured IP masquerage
+rules or failure displaying complex colored (non-ascii) characters.