What do people think of the idea of requiring all deprecations specifying a version that the feature will be removed in (which under our annual release cadence would be at least the third release from the start of the deprecation, hence the deprecation being public for 2 years)? And that we also follow through with that removal?
Now I'm not suggesting it **must** be in three feature releases. A deprecation could be set to Python 4 if people truly feel keeping the code is as easy it gets in terms of maintenance and there's enough usage to warrant such a potential indefinite deprecation/maintenance while keeping the code and docs alive (basically "there are better ways to do this, but this works fine, too, if you were already using it"). But what I am trying to avoid is the semi-regular discussion we seem to have of what is or is not reasonable to deprecate and leave versus deprecate and eventually remove because we didn't specify what the eventual plan was for a deprecation. Also feel like it would help users to know specifically what the plan is with a deprecation rather than wondering if something will get removed in the next feature release or not because we left off a specific removal version.
If people are amenable to this idea I will update PEP 387 (which I plan to start a discussion about post-SC election) and I would also plan to add a warnings._deprecate() which I roughly outlined once at https://discuss.python.org/t/pendingdeprecationwarning-is-really-useful/1....
Today I discovered the this struct
typedef struct{
const char* name;
int basicsize;
int itemsize;
unsigned int flags;
PyType_Slot *slots; /* terminated by slot==0. */
} PyType_Spec;
with "PyTypeSlot *slots" being on line 190 of object.h causes a problem when compiled with code that brings in Qt. Qt has macro definitions of slots.
With a cursory preprocessing of the file I was working with, using the handy gcc options -dM -E, I found that
slots was defined to nothing
#define slots
and hence caused problems when object.h was brought into the mix.
I will try to make a simple reproducer tomorrow. I know this probably could be solved by header file inclusion re-ordering,
or in some cases #undef'ing slots before including Python.h, but I also thought the Python dev team would like to know
about this issue.
Tom
Hi all,
I think that PEP 573 is ready to be accepted, to greatly improve the state
of extension modules in CPython 3.9.
https://www.python.org/dev/peps/pep-0573/
It has come a long way since the original proposal and went through several
iterations and discussions by various interested people, effectively
reducing its scope quite a bit. So this is the last call for comments on
the latest version of the PEP, before I will pronounce on it. Please keep
the discussion in this thread.
Stefan
Hello!
Did we take a decision of what comes after 3.9?
Do we have a PEP for that decision? (couldn't find it)
(not arguing in favor of one or another, just want to know the
rationale behind it)
Thanks!
--
. Facundo
Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org.ar/
Twitter: @facundobatista
Hi all,
The database backing buildbot.python.org has been reset in order to
clean out old workers and builders, and to allow some relationships to
be created properly to allow future cleanups without resetting
everything. This does unfortunately mean that old links are going to
be broken, including those to particular workers or builders since
they have all been renumbered.
Apologies for the inconvenience,
Zach
Hi Folks,
Python-dev seemed to be the most appropriate email alias for this,
though please do point me somewhere else if this is not appropriate.
We are using a custom arm64 based distro built using yocto and as such
we are currently using python 3.5.6. We are hitting a failure in a python3 test case qemu running under QEMU that we would like to try to resolve if possible:
root@10:/usr/lib/python3.5# python3 --version
Python 3.5.6
root@10:/usr/lib/python3.5# python3 ctypes/test/test_structures.py
.................F....s.....
======================================================================
FAIL: test_pass_by_value (__main__.StructureTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
File "ctypes/test/test_structures.py", line 419, in
test_pass_by_value
self.assertEqual(s.first, 0xdeadbeef)
AssertionError: 195948557 != 3735928559
----------------------------------------------------------------------
Ran 28 tests in 0.457s
FAILED (failures=1, skipped=1)
root@10:/usr/lib/python3.5#
From searching the web I came across this bug which appears to match
what we are seeing:
https://bugs.python.org/issue29804 ("test_ctypes test_pass_by_value
fails on arm64 (aarch64) architecture").
However it looks like this fix is already in 3.5.6 so this isn't it.
Next set of searching led me here:
https://bugs.python.org/issue30353 and thus this patch:
https://github.com/python/cpython/commit/9ba3aa4d02a110d1a1ea464a8aff3be7...
So I applied this patch but we end up with this now:
root@10:~# cd /usr/lib/python3.5/
root@10:/usr/lib/python3.5# python3 ctypes/test/test_structures.py
Traceback (most recent call last):
File "ctypes/test/test_structures.py", line 2, in <module>
from ctypes import *
File "/usr/lib/python3.5/ctypes/__init__.py", line 7, in <module>
from _ctypes import Union, Structure, Array
ImportError: No module named '_ctypes'
root@10:/usr/lib/python3.5#
Can anyone help point me in the right direction with this failure we
are seeing? We are stuck with python 3.5.6 for now due to the version of yocto we are using, though I'm concerned since this seems to be a fairly fundamental issue which is being exposed by this testcase.
Do let me know if you require any more information from me.
Many Thanks,
Peter.
Python 3.9 is going to be the first release which will exist without any Python 2.7 overlap. Does this mean we are ready to start removing things that have been deprecated since at least Python 3.7? PEP 4 says [we are in the clear for modules](https://www.python.org/dev/peps/pep-0004/#for-modules-existing-i..., but I figured I would double-check as questions of cleaning up individual functions that have been deprecated for a very long time are now starting to come up (e.g. https://bugs.python.org/issue38916).
An unfortunate side-effect of making PyInterpreterState in Python 3.8 opaque is it removed [PEP 523](https://www.python.org/dev/peps/pep-0523/) support. https://www.python.org/dev/peps/pep-0523/ was opened to try and fix this, but there seems to be a stalemate in the issue.
A key question is at what API level should setting the frame evaluation function live at? No one is suggesting the stable ABI, but there isn't agreement between CPython or the internal API (there's also seems to be a suggestion to potentially remove PEP 523 support entirely).
And regardless of either, there also seems to be a disagreement about providing getters and setters to continue to try and hide PyInterpreterState regardless of which API level support is provided at (if any).
If you have an opinion please weight in on the issue.
