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
The documentation at
https://docs.python.org/3.2/library/profile.html
contains the sentence
For example, if your_integer_time_func() returns times measured in
thousands of seconds, you would construct the Profile instance as follows:
"thousands of seconds" should ISTM be "thousandths of a second".
There is essentially the same thing in the Python 2 docs at
https://docs.python.org/2/library/profile.html
viz.
For example, if the timer returns times measured in _thousands_ of
seconds, the time unit would be |.001|.
Just trying for perfection!
Best wishes
Rob Cliffe
Hi,
I dislike having to do that, but I had to make a last minute change in
my PEP 587 "Python Initialization Configuration" to allow to modify
the structure in the future without breaking the backward
compatibility. I added a "struct_size" field to PyPreConfig and
PyConfig:
* https://bugs.python.org/issue38304
* https://github.com/python/peps/commit/afa38c0bef7738b8fcc3173daee8488e04208…
The example:
PyConfig config;
PyStatus status = PyConfig_InitPythonConfig(&config);
...
must now be written:
PyConfig config;
config.struct_size = sizeof(PyConfig);
PyStatus status = PyConfig_InitPythonConfig(&config);
...
At the beginning, I used a private "_config_version" field which was
initialized statically by a macro. But it was decided to replace
macros with functions. I only noticed today that the conversion to
function broke the API/ABI future compatibility.
PyConfig_InitPythonConfig() got uninitialized memory and didn't know
the size of the config variable.
With my change, the function now requires the "struct_size" field to
be set, and so it can support internally different versions of the
PyConfig structure.
Storing the structure size directly in the structure is a common
practice in the Windows API which is a good example of long term ABI
compatibility.
--
By the way, last week, Pablo Galindo Salgado reported to me a
regression in PyInstaller caused by the implementation of my PEP.
I fixed different issues related to the "Path Configuration" (sys.path
in short), but I also added a lot of tests for this code. Previously,
there was simply no test on the path configuration!
I added a lot of comments to the C code, and I completed the public
documentation:
https://docs.python.org/dev/c-api/init_config.html#path-configuration
Please test the incoming Python 3.8.0rc1 release with your project if
you embed Python into your application. Please test also projects like
PyInstaller, PyOxidizer, etc.
Note: PyInstaller requires my fix for 3.8 (not merged yet):
https://github.com/pyinstaller/pyinstaller/pull/4440
Victor
--
Night gathers, and now my watch begins. It shall not end until my death.