This reverts commit 3b9a0186c4.
Due to regressions found with using Tk 8.6.9.1, the python.org macOS
installers for 3.6.8 and 3.7.2 are shipping with Tcl/Tk 8.6.8 as used
in previous releases.
For 3.7.1rc1 and 3.6.7rc1 we used a pre-release development
snapshot of Tk 8.6 to pick up some post-8.6.8 fixes for macOS.
But the snapshot introduced at least one regression (bpo-34927).
For rc2, revert to using the standard release 8.6.8 for now.
This reverts commit d9cfe5ed2c.
Have macOS 10.9+ installer builds for 3.7.1rc and 3.6.7rc use a development
snapshot of Tk 8.6 (post-8.6.8) to mitigate certain scroller issues seen
with IDLE and tkinter apps.
Currently, "pip3 install --upgrade pip" unconditionally installs a
"pip" alias even for Python 3. If a user has an existing Python 3.x
installed from a python.org macOS installer and then subsequently
manually updates to a new version of pip, there may now be a stray
"pip" alias in the Python 3.x framework bin directory which can cause
confusion if the user has both a Python 2.7 and 3.x installed;
if the Python 3.x fw bin directory appears early on $PATH, "pip"
might invoke the pip3 for the Python 3.x rather than the pip for
Python 2.7. To try to mitigate this, the macOS installer script
for the ensurepip option will unconditionally remove "pip" from
the 3.x framework bin directory being updated / installed. (The
ambiguity can be avoided by using "pythonx.y -m pip".)
(cherry picked from commit 0dd80709b5)
Co-authored-by: Ned Deily <nad@python.org>
Build and link with private copy of Tcl/Tk 8.6 for the macOS 10.6+
installer. The 10.9+ installer variant already does this. This means that
the Python 3.7 provided by the python.org macOS installers no longer need or
use any external versions of Tcl/Tk, either system-provided or user-
installed, such as ActiveTcl.
Forcing the macOS IDLE.app gui process to launch in 32-mode was
a necessary hack for old versions of Tk (Aqua Carbon as in Tk 8.4
and early versions of 8.5); it is not needed for current versions
of Tk. Since 32-bit launching will no longer be supported on
future releases of macOS, allow IDLE.app to launch in 64-bit mode.
(cherry picked from commit df532ab752)
Co-authored-by: Ned Deily <nad@python.org>
This issue covers various changes for the macOS installers provided via python.org for 3.7.0.
- Provide a provisional new installer variant for macOS 10.9 and later systems with 64-bit (x86_64) architecture only. Apple has made it known that future versions of macOS will only fully support 64-bit executables and some other third-party software suppliers have chosen 10.9 as their oldest supported system.
- Support **Tcl/Tk 8.6** with the 10.9 installer variant.
- Upgrade **OpenSSL** to 1.1.0g and **SQLite** to 3.22.0.
- The compiler name used for the interpreter build and for modules built with **Distutils / pip** is now _gcc_ rather than _gcc-4.2_. And extension module builds will no longer try to force use of an old SDK if present.
* Fix multiple typos in code comments
* Add spacing in comments (test_logging.py, test_math.py)
* Fix spaces at the beginning of comments in test_logging.py
Don't rebuild generated files based on file modification time
anymore, the action is now explicit. Replace "make touch"
with "make regen-all".
Changes:
* Remove "make touch", Tools/hg/hgtouch.py and .hgtouch
* Add a new "make regen-all" command to rebuild all generated files
* Add subcommands to only generate specific files:
- regen-ast: Include/Python-ast.h and Python/Python-ast.c
- regen-grammar: Include/graminit.h and Python/graminit.c
- regen-importlib: Python/importlib_external.h and Python/importlib.h
- regen-opcode: Include/opcode.h
- regen-opcode-targets: Python/opcode_targets.h
- regen-typeslots: Objects/typeslots.inc
* Rename PYTHON_FOR_GEN to PYTHON_FOR_REGEN
* pgen is now only built by by "make regen-grammar"
* Add $(srcdir)/ prefix to paths to source files to handle correctly
compilation outside the source directory
Note: $(PYTHON_FOR_REGEN) is no more used nor needed by "make"
default target building Python.