On behalf of the Python development community and the Python 3.8 release team, I’m pleased to announce the availability of Python 3.8.0.
Python 3.8.0 is the newest feature release of the Python language, and it contains many new features and optimizations. You can find Python 3.8.0 here:
https://www.python.org/downloads/release/python-380/ <https://www.python.org/downloads/release/python-380/>
Most third-party distributors of Python should be making 3.8.0 packages available soon.
See the “What’s New in Python 3.8 <https://docs.python.org/3.8/whatsnew/3.8.html>” document for more information about features included in the 3.8 series. Detailed information about all changes made in 3.8.0 can be found in its change log.
Maintenance releases for the 3.8 series will follow at regular bi-monthly intervals starting in December of 2019.
We hope you enjoy Python 3.8!
Thanks to all of the many volunteers who help make Python Development and these releases possible! Please consider supporting our efforts by volunteering yourself or through organization contributions to the Python Software Foundation.
https://www.python.org/psf/ <https://www.python.org/psf/>
- Ł
Python 3.7.5 is now available, the next maintenance release of Python 3.7. You can find the release files, a link to the changelog, and more information here:
https://www.python.org/downloads/release/python-375/
Note that the next feature release of Python 3, Python 3.8.0, is also now available. Python 3.8 contains many new features and optimizations. You should consider upgrading to it. We plan to continue regular bugfix releases of Python 3.7.x through mid-year 2020 and provide security fixes for it until mid-year 2023. More details are available in PEP 537, the Python 3.7 Release Schedule (https://www.python.org/dev/peps/pep-0537/).
Thanks to all of the many volunteers who help make Python Development and these releases possible! Please consider supporting our efforts by volunteering yourself or through organization contributions to the Python Software Foundation.
--
Ned Deily
nad(a)python.org -- []
On 10/14/2019 9:26 PM, Glenn Linderman wrote:
> On 10/14/2019 1:23 PM, Łukasz Langa wrote:
>> On behalf of the Python development community and the Python 3.8 release team, I’m pleased to announce the availability of Python 3.8.0.
> I look forward to using Python 3.8.0.
>
> However, having installed it, I then needed to install brotli, so I
> ran pip install brotli, and that worked, but I was very surprised to
> get told:
>
> You are using pip version 18.1, however version 19.3 is available.
> You should consider upgrading via the 'python -m pip install --upgrade
> pip' command.
>
> The upgrade worked, but why would the newest, just-released version of
> Python not include the newest version of pip?
>
> Glenn
Hmm. "worked" above only means "completed without reporting errors".
Excuse the noise, I accidentally ran Python3.6\Scripts\pip.exe. But now
running the one from Python3.8 the error message from pip references pip
version 19.2.3 as the "old version", so it is still true that Python 3.8
doesn't seem to include the latest pip. But with the numbers being
closer, I suppose that means that pip had a release after the Python 3.8
code freeze.
And sadly, I'm too fast at trying to install brotli for 3.8: it
apparently doesn't have a wheel yet, so tried to compile from source,
and couldn't find a C compiler on my machine.
On behalf of the Python development community, I'm chuffed to announce
the availability of Python 3.5.8rc1.
Python 3.5 is in "security fixes only" mode. This new version only
contains security fixes, not conventional bug fixes, and it is a
source-only release.
You can find Python 3.5.8rc1 here:
https://www.python.org/downloads/release/python-358rc1/
I think Python 3.5 may just barely outlive 2.7,
//arry/
The extern declaration for dlerror() in _ctypes/darwin/dlfcn.h does not match the declaration in the macOS 10.4/10.5 SDK, causing a compile error for dlfcn_simple.c for statically linking the interpreter and modules (for example with pyqtdeploy).
The line in question is in the following snippet. Changing "extern const char *dlerror" to "extern char *dlerror" fixes the problem. What is the rationale for the current "const char *" declaration when the macOS SDK and GNU spec uses "char *"?
#if MAC_OS_X_VERSION_MIN_REQUIRED <= MAC_OS_X_VERSION_10_2
#warning CTYPES_DARWIN_DLFCN
#define CTYPES_DARWIN_DLFCN
extern void * (*ctypes_dlopen)(const char *path, int mode);
extern void * (*ctypes_dlsym)(void * handle, const char *symbol);
extern const char * (*ctypes_dlerror)(void);
extern int (*ctypes_dlclose)(void * handle);
extern int (*ctypes_dladdr)(const void *, Dl_info *);
#else
extern void * dlopen(const char *path, int mode);
extern void * dlsym(void * handle, const char *symbol);
extern const char * dlerror(void);
extern int dlclose(void * handle);
extern int dladdr(const void *, Dl_info *);
#endif
Cheers!
The extern declaration for dlerror() in _ctypes/darwin/dlfcn.h does not match the declaration in the macOS 10.4/10.5 SDK, causing a compile error for dlfcn_simple.c for statically linking the interpreter and modules (for example with pyqtdeploy).
The line in question is in the following snippet. Changing "extern const char *dlerror" to "extern char *dlerror" fixes the problem. What is the rationale for the current "const char *" declaration when the macOS SDK and GNU spec uses "char *"?
#if MAC_OS_X_VERSION_MIN_REQUIRED <= MAC_OS_X_VERSION_10_2
#warning CTYPES_DARWIN_DLFCN
#define CTYPES_DARWIN_DLFCN
extern void * (*ctypes_dlopen)(const char *path, int mode);
extern void * (*ctypes_dlsym)(void * handle, const char *symbol);
extern const char * (*ctypes_dlerror)(void);
extern int (*ctypes_dlclose)(void * handle);
extern int (*ctypes_dladdr)(const void *, Dl_info *);
#else
extern void * dlopen(const char *path, int mode);
extern void * dlsym(void * handle, const char *symbol);
extern const char * dlerror(void);
extern int dlclose(void * handle);
extern int dladdr(const void *, Dl_info *);
#endif
Cheers!
Hello,
I try to implement a *proof of concept* of Pep-0604
<https://www.python.org/dev/peps/pep-0604/>.
To do this, the _GenericAlias must be in builtin, because I would like to
update issubclass() and isinstance() to accept Union.
These methods are in builtin, and must be run without others modules.
But, the class _GenericAlias is in typing module, with the Python
implementation in Lib/typing.py, and the C implementation is in
Modules/_ctypes.
For you, what is the best approach to move the _GenericAlias and all
dependencies in the builtin "module" ?
Philippe
The first release candidate of Python 2.7.17 is now available for download and testing. Python 2.7.17 includes 80 fixes over Python 2.7.16.
Downloads may be found on python.org:
https://www.python.org/downloads/release/python-2717rc1/
Read the full changelog at:
https://raw.githubusercontent.com/python/cpython/1c7b14197b10924e2efc1e6c99…
As always with prereleases, please test your applications and libraries and report bugs to:
https://bugs.python.org/
A final release is scheduled to follow in 12 days.
PEP 373, the Python 2.7 release schedule, calls for 2.7.17 to be the penultimate bug fix release of the Python 2.7 series. Time for Python 2 is running low!
Regards,
Benjamin
2.7 release manager
