Petr Viktorin added the comment:
> What is the problem between _Py_IDENTIFIER and multi-phase initialisation
> modules?
AFAIK there is no problem now, except possibly a race condition when
initializing the identifiers.
It seems it's too easy to conflate porting to multi-phase ini
Petr Viktorin added the comment:
PR for removing __version__ from mock:
https://github.com/python/cpython/pull/17977
--
nosy: +petr.viktorin
___
Python tracker
<https://bugs.python.org/issue31
Change by Petr Viktorin :
--
stage: patch review -> needs patch
___
Python tracker
<https://bugs.python.org/issue31826>
___
___
Python-bugs-list mai
Petr Viktorin added the comment:
IMO, PyCFunction* should be a CPython-specific implementation detail: alternate
implementations of the C-API don't need to support them, and extension authors
should be fine without using them. (And if not, more efforts like PEP 590
Vectorcall should ma
Petr Viktorin added the comment:
I'm with Stefan on "Definitely 3.8". It's a bug fix (for a rarely used feature).
--
___
Python tracker
<https://bug
Change by Petr Viktorin :
--
pull_requests: +17834
pull_request: https://github.com/python/cpython/pull/18460
___
Python tracker
<https://bugs.python.org/issue39
Change by Petr Viktorin :
--
pull_requests: +17837
pull_request: https://github.com/python/cpython/pull/18464
___
Python tracker
<https://bugs.python.org/issue37
Petr Viktorin added the comment:
New changeset ffd9753a944916ced659b2c77aebe66a6c9fbab5 by Petr Viktorin in
branch 'master':
bpo-39245: Switch to public API for Vectorcall (GH-18460)
https://github.com/python/cpython/commit/ffd9753a944916ced659b2c77aebe6
Petr Viktorin added the comment:
New changeset f3fda374685dffa31ebda9e681e00ef7032b8a1d by Victor Stinner in
branch 'master':
bpo-38644: Rephrase What's New entry (GH-18461)
https://github.com/python/cpython/commit/f3fda374685dffa31ebda9e681e00ef7032b8a1d
--
nosy:
Change by Petr Viktorin :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Petr Viktorin added the comment:
The current return type already is Py_ssize_t, exactly for the reason you
mention – compatibility with all other "argument count" values in Python. (It
would be more correct to use unsigned, but that ship has sailed.)
The *argument* type is unsig
Petr Viktorin added the comment:
Closing; please reopen if we're somehow misunderstanding each other :)
--
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.pyth
Petr Viktorin added the comment:
New changeset d77e77116fa7a9fc85be1d9f417c7e9e33fe1296 by Miss Islington (bot)
in branch '3.8':
bpo-39555: Fix distutils test to handle _d suffix on Windows debug build
(GH-18357) (GH-18548)
https://github.com/python/cpyt
Petr Viktorin added the comment:
Indeed, builds are green: https://buildbot.python.org/all/#/builders/449
Thanks Victor for reporting and Harris for fixing this.
--
nosy: +petr.viktorin
resolution: -> fixed
stage: -> resolved
status: open -&g
Petr Viktorin added the comment:
Why "sys.python_libdir"? Isn't that too public? A lot of similar path-related
info is in sysconfig; why shouldn't it be there?
How does "sys.python_libdir" work on other platforms?
--
Petr Viktorin added the comment:
The call:
struct.unpack('>?', b'\xf0')
means to unpack a "native bool", i.e. native size and alignment. Internally,
this does:
static PyObject *
nu_bool(const char *p, const formatdef *f)
{
_Bool x;
Petr Viktorin added the comment:
C compiler dev that it's indeed undefined behavior.
> Quick and obvious fix:
>
> static PyObject *
> nu_bool(const char *p, const formatdef *f)
> {
> char x;
> memcpy((char *)&x, p,
Change by Petr Viktorin :
--
pull_requests: +18122
pull_request: https://github.com/python/cpython/pull/18766
___
Python tracker
<https://bugs.python.org/issue39
Change by Petr Viktorin :
--
pull_requests: +18123
pull_request: https://github.com/python/cpython/pull/18766
___
Python tracker
<https://bugs.python.org/issue38
Petr Viktorin added the comment:
The fix introduced a regression, see bpo-39761
--
___
Python tracker
<https://bugs.python.org/issue38960>
___
___
Python-bug
Petr Viktorin added the comment:
Yes. Can you use PyObject_Call instead (or one of the non-Vectorcall variants
listed in https://docs.python.org/3.9/c-api/call.html#object-calling-api )
Vectorcall is mainly a speed optimization over PyObject_Call. We want to allow
the C compiler to inline
Petr Viktorin added the comment:
IMO:
- The "native" format should use native _Bool, and we should only test
unpacking 0 and 1
- The "standard" format should use portable char semantics: continue to treat
any non-zero value as true
- The docs should grow a warning that f
Change by Petr Viktorin :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Petr Viktorin added the comment:
Viewing the oss-fuzz bug requires login. Is there any interesting public info
in it?
--
___
Python tracker
<https://bugs.python.org/issue39
Petr Viktorin added the comment:
No, in Python 2 the PyInt object (`int` in Python 2) always did fit into a C
long -- that was the underlying storage. If it didn't fit, a PyLong object
(`long` in Python 2) was used.
Python 3 doesn't have PyInt, it only has PyLong (`int` i
Petr Viktorin added the comment:
If you use a module subclass that needs some additional C-level infrastructure,
it would be more appropriate to override tp_clear/tp_free directly.
IMO limiting m_clear/m_free to work just with the module state won't hurt. But
it is an API c
Petr Viktorin added the comment:
New changeset 3c97e1e457033bbb8bbe0b7198bd13fc794a12b0 by Petr Viktorin in
branch 'master':
bpo-39761: Fix dtrace build with empty $DFLAGS (GH-18766)
https://github.com/python/cpython/commit/3c97e1e457033bbb8bbe0b7198bd13
Petr Viktorin added the comment:
New changeset 3c97e1e457033bbb8bbe0b7198bd13fc794a12b0 by Petr Viktorin in
branch 'master':
bpo-39761: Fix dtrace build with empty $DFLAGS (GH-18766)
https://github.com/python/cpython/commit/3c97e1e457033bbb8bbe0b7198bd13
Petr Viktorin added the comment:
> our unittest assuming that b'\xf0' should be true when interpreted as a bool
> is wrong.
> just get rid of that value from the loop in the test?
That could be the proper thing to do, but it does make it easy to invoke C
undefined behavi
Change by Petr Viktorin :
--
keywords: +patch
pull_requests: +18277
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/18925
___
Python tracker
<https://bugs.python.org/issu
Change by Petr Viktorin :
--
nosy: +petr.viktorin
nosy_count: 4.0 -> 5.0
pull_requests: +18280
pull_request: https://github.com/python/cpython/pull/18928
___
Python tracker
<https://bugs.python.org/issu
Petr Viktorin added the comment:
The memoryview module does the same thing as struct, and its tests expect the
same behavior as with struct.
So, whatever we do in struct should be also done in memoryview.
--
title: test_struct failure on s390x Fedora Clang buildbot -> struct
Petr Viktorin added the comment:
> > > maybe we should be raising an error if the bytes are not a valid platform
> > > _Bool pattern?
> >
> > That's quite hard to test for.
>
> How so? We just make the same assumption you're making that true =
Petr Viktorin added the comment:
Oh! I just reead the docs more carefully; they say:
For the '?' format character, the return value is either True or False. When
packing, the truth value of the argument object is used. Either 0 or 1 in the
native or standard bool representati
Change by Petr Viktorin :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Petr Viktorin added the comment:
> So I vote for not handling incorrectly packed values and removing
"and any non-zero value will be True when unpacking" from the docs,
which does not seem to make any sense for _Bool.
I disagree. I don't think struct module's job is
Change by Petr Viktorin :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Petr Viktorin added the comment:
> The docs for native mode (we now always assume C99):
>
> "The '?' conversion code corresponds to the _Bool type defined by C99."
But, nowhere is it suggested that conversion is "do memcpy and then interpret
the bit pat
Petr Viktorin added the comment:
> You are the one who wanted to *introduce* a hack by dereferencing
as char and then cast to _Bool. :-)
Yes, I did change my mind after reading the documentation.
The docs say two contradicting things:
1. The '?' conversion code corresponds to t
Petr Viktorin added the comment:
I think we are speaking past each other.
In my (current) view, the semantics are spelled out in the documentation: "any
non-zero value will be True when unpacking".
There's also a mention that this corresponds to the _Bool type in C. While thi
Petr Viktorin added the comment:
I see. Thanks for your patience explaining this to me!
I will merge and continue in a different issue.
--
___
Python tracker
<https://bugs.python.org/issue39
Petr Viktorin added the comment:
Moved to Discourse, IMO that's a better place for maintainers of other
PEP-3118-compatible libraries to chime in:
https://discuss.python.org/t/behavior-of-struct-format-native-bool/3774
--
___
Python tr
Petr Viktorin added the comment:
The change to dict() was not covered by the smaller PRs.
That one will need more thought, but AFAIK it wasn't yet rejected.
--
status: closed -> open
___
Python tracker
<https://bugs.python.org
Petr Viktorin added the comment:
Definitely!
--
___
Python tracker
<https://bugs.python.org/issue37207>
___
___
Python-bugs-list mailing list
Unsubscribe:
Petr Viktorin added the comment:
> Can I submit the patch?
Yes!
If you think a patch is ready for review, just submit it. There's not much we
can comment on before we see the code :)
(I hope that doesn't contradict what you
Petr Viktorin added the comment:
As discussed briefly in Mark's PR, benchmarks like this are now slower:
ret = dict(**{'a': 2, 'b': 4, 'c': 6, 'd': 8})
Python 3.8: Mean +- std dev: 281 ns +- 9 ns
Change by Petr Viktorin :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Petr Viktorin added the comment:
I got a report from a library that ties together asyncio and some other async
libraries, getting errors like this:
tests/test_taskgroups.py:60: in test_run_natively
module.run(testfunc())
/usr/lib64/python3.9/asyncio/runners.py:48: in run
Petr Viktorin added the comment:
I'm working on the implementation as my time allows, here:
https://github.com/encukou/cpython/pull/3 .
Would it help to create a proper PR for CPython now? That would mean I could no
longer do rebases/force-pushes, so the commits would be less readable
Petr Viktorin added the comment:
reportlab reported failures on code like:
norm=lambda m: m+(m and(m[-1]!='\n'and'\n'or'')or'\n')
Note that `or` has a `r` in it.
--
nosy: +petr.viktorin
___
Python trac
Change by Petr Viktorin :
--
pull_requests: +19251
pull_request: https://github.com/python/cpython/pull/19936
___
Python tracker
<https://bugs.python.org/issue38
Petr Viktorin added the comment:
That seems reasonable. See the discussion around
https://bugs.python.org/issue38140 for context.
Note that __dictoffset__ and __weaklistoffset__ are also exposed as members (in
PyMemberDef type_members) and documented (Doc/c-api/structures.rst). A new
Petr Viktorin added the comment:
So, the failure is expected. Python's ABI can change until the 3.9.0 final
release, so wheels built for different commits can be incompatible.
This applies to alphas/betas as well, as you say.
There is the PEP 384 stable ABI, which is much stricter (and
Petr Viktorin added the comment:
> For example, Objects/longobject.c defines "PyTypeObject PyLong_Type =
> {...};". This type is exposed in the limited C API (!)
Technically, it is not, see https://www.python.org/dev/peps/pep-0384/#structures
Structures like PyLong_Type are *
Petr Viktorin added the comment:
I guess I'll need to clarify the documentation here.
Call `PyType_GetModule` on the *defining class*, not on type(self). See the PEP
for details.
The associated module is not inherited; each class in the MRO can be defined in
a different m
Petr Viktorin added the comment:
When was the visibility changed to hidden?
--
___
Python tracker
<https://bugs.python.org/issue42599>
___
___
Python-bugs-list m
Petr Viktorin added the comment:
Is it really necessary to add a slot/flag for this?
It can be done in about 10 lines as below, without complications like a global
(or per-interpreter) registry of singleton modules.
Are there many modules that need to be per-interpreter singletons, but may be
Petr Viktorin added the comment:
Are there any other examples?
In my view, atexit is very special, and very closely tied to interpreter. I
don't think it's good to design general API for one module.
--
___
Python tracker
<https://bu
Petr Viktorin added the comment:
This change goes directly against PEP 387.
--
nosy: +petr.viktorin
___
Python tracker
<https://bugs.python.org/issue30
Petr Viktorin added the comment:
> The change respects the documentation which always documented the result type
> as "void".
Then, IMO, the documentation should be fixed.
> My expectation is that apart py-qt4, no project abuse these 3 macros.
That's not true
Petr Viktorin added the comment:
When does this actually happen? Is there a common situation where you'd
mistakenly pass NULL to PyState_AddModule?
--
___
Python tracker
<https://bugs.python.org/is
Petr Viktorin added the comment:
Thanks! Indeed, that's an even better solution than I had in mind.
It follows PEP 630 quite nicely:
https://www.python.org/dev/peps/pep-0630/#managing-global-state
I will close this issue and PRs.
I don't agree with adding a general API for d
Petr Viktorin added the comment:
New changeset 6a02b384751dbc13979efc1185f0a7c1670dc349 by Petr Viktorin in
branch 'master':
bpo-14935: Remove static state from the _csv module (GH-23224)
https://github.com/python/cpython/commit/6a02b384751dbc13979efc1185f0a7
Change by Petr Viktorin :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Petr Viktorin added the comment:
Let me summarize the original issue with the following quote from the
python-dev thead:
> doing some sys.modules acrobatics and re-importing suddenly
changes the internal state of a previously imported [_csv] module.
The issue is now solved; both reproduc
Petr Viktorin added the comment:
Thank you for working on this!
It took several years and some new C-API to get it right (see PEP 630), but I
believe this and the related issues bpo-18710 and bpo-34533 can now be closed.
--
resolution: -> fixed
stage: patch review -> resolved
Petr Viktorin added the comment:
PEP 630 is now Active. I believe the vast majority of modules can now be
ported, and it should be helpful for early adopters (including CPython stdlib).
But there are still Open Issues and the API not battle-tested on all the edge
cases.
The PEP is written
Petr Viktorin added the comment:
I'll be happy to review adding a PyType_GetName function.
--
___
Python tracker
<https://bugs.python.org/issue42035>
___
___
Petr Viktorin added the comment:
IMO, these flags are useless. Both the stable ABI and the version-specific
builds of extension modules use the memory layout of the current interpreter
and fill unset slots with NULL.
Py_TPFLAGS_HAVE_AM_SEND is new in 3.10, so it can be removed (or replaced
Petr Viktorin added the comment:
Thanks, Victor, for explaining!
You'll also see NULL checks in existing code where they aren't strictly
necessary, but removing them would be too much trouble.
--
___
Python tracker
<https://bu
Petr Viktorin added the comment:
Documentation for developers *of* CPython should generally go in the dev guide,
a comment in the code, or in issues like this.
--
___
Python tracker
<https://bugs.python.org/issue41
Change by Petr Viktorin :
--
nosy: +petr.viktorin
nosy_count: 4.0 -> 5.0
pull_requests: +22841
pull_request: https://github.com/python/cpython/pull/23999
___
Python tracker
<https://bugs.python.org/issu
Petr Viktorin added the comment:
> I'm only aware of PyQt which uses the stable ABI. Is there other projects
> using it? Do these projects check for Py_TPFLAGS_HAVE_VERSION_TAG or
> Py_TPFLAGS_HAVE_FINALIZE flag?
I think there are. Who knows how many; they're not r
Petr Viktorin added the comment:
The Check code is now commented out, and the issue of type checking is
mentioned in PEP 630.
(The xxlimited_35 module still contains XxoObject_Check, among other historical
code.)
--
resolution: -> postponed
stage: needs patch -> resolved
Petr Viktorin added the comment:
New changeset 75bf107c62fbdc00af51ee4f6ab69df4bd201104 by Erlend Egeberg
Aasland in branch 'master':
bpo-40077: Convert arraymodule to use heap types and establish module state
(GH-23124)
https://github.com/python/cpyt
Petr Viktorin added the comment:
New changeset b8eb3765908c0063f0739595ba4b296cc8863d19 by Erlend Egeberg
Aasland in branch 'master':
bpo-40077: Add traverse/clear/free to arraymodule (GH-24066)
https://github.com/python/cpython/commit/b8eb3765908c0063f0739595ba4b29
Petr Viktorin added the comment:
Yes, please keep _testcapimodule.c as it is. Static types are still supported
and need to be tested.
--
___
Python tracker
<https://bugs.python.org/issue40
Petr Viktorin added the comment:
Let me just point out there's an official process for making incompatible
changes now:
https://www.python.org/dev/peps/pep-0387/#making-incompatible-changes
A warning must be emitted (not just mentioned in docs) for two releases before
a feature is re
Petr Viktorin added the comment:
Should the process be changed?
--
___
Python tracker
<https://bugs.python.org/issue36543>
___
___
Python-bugs-list mailin
Change by Petr Viktorin :
--
nosy: +petr.viktorin
nosy_count: 11.0 -> 12.0
pull_requests: +22949
pull_request: https://github.com/python/cpython/pull/24119
___
Python tracker
<https://bugs.python.org/issu
Petr Viktorin added the comment:
I noticed an issue in one of the newly added tests; see GH-24119
--
___
Python tracker
<https://bugs.python.org/issue41
Petr Viktorin added the comment:
New changeset 6e72ab909de58e89b5a7cd6899587e203cf129a3 by Miss Islington (bot)
in branch '3.9':
[3.9] bpo-40052: Fix alignment issue in PyVectorcall_Function() (GH-23999)
(GH-24005)
https://github.com/python/cpyt
Change by Petr Viktorin :
--
pull_requests: +22951
pull_request: https://github.com/python/cpython/pull/24120
___
Python tracker
<https://bugs.python.org/issue40
Petr Viktorin added the comment:
New changeset 4db8988420e0a122d617df741381b0c385af032c by Serhiy Storchaka in
branch 'master':
bpo-41994: Fix refcount issues in Python/import.c (GH-22632)
https://github.com/python/cpython/commit/4db8988420e0a122d617df741381b0c385af032c
-
Petr Viktorin added the comment:
New changeset 187f76def8a5bd0af7ab512575cad30cfe624b05 by Petr Viktorin in
branch '3.8':
[3.8] bpo-40052: Fix alignment issue in PyVectorcall_Function() (GH-23999)
(GH-24120)
https://github.com/python/cpython/commit/187f76def8a5bd0af7ab512575cad3
Petr Viktorin added the comment:
In GH-23598, PyModule_AddObjectRef was added as EXPORT_DATA. Shouldn't it be
EXPORT_FUNC?
--
___
Python tracker
<https://bugs.python.org/issu
Change by Petr Viktorin :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Change by Petr Viktorin :
--
nosy: -petr.viktorin
___
Python tracker
<https://bugs.python.org/issue42962>
___
___
Python-bugs-list mailing list
Unsubscribe:
Petr Viktorin added the comment:
Is there anything I can help with to move this forward?
Investigating buildbot failures continues to be very annoying.
--
nosy: +petr.viktorin
___
Python tracker
<https://bugs.python.org/issue41
Change by Petr Viktorin :
--
keywords: +patch
pull_requests: +23077
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/24119
___
Python tracker
<https://bugs.python.org/issu
Petr Viktorin added the comment:
New changeset 65cf1ad6723b6b4489fa7dda04283bb2466be531 by Petr Viktorin in
branch 'master':
bpo-41818: Close file descriptors in test_openpty (#GH-24119)
https://github.com/python/cpython/commit/65cf1ad6723b6b4489fa7dda04283b
Petr Viktorin added the comment:
The PyOS_InitInterrupts function is still listed in PC/python3dll.c.
--
nosy: +petr.viktorin
___
Python tracker
<https://bugs.python.org/issue41
Petr Viktorin added the comment:
Now that I see the implementation (and now that I'm spending a lot of time
trying to formalize what is good stable API), I see a problem with
PyType_GetName: it effectively returns a borrowed reference.
The proposed docs say:
Callers can hold [the re
Petr Viktorin added the comment:
When we're talking just about API, not the stable ABI (which contains only a
few structs), reordering and additions should be fair game.
> Rather than go through this tortuous analysis for all headers, it might be
> better to document which struc
Petr Viktorin added the comment:
Sorry, I lost this bug in my TODO list :(
> > I don't think it's necessary here.
>
> Did you read my rationale (first message)? Do you mean that per-interpreter
> GIL is not worth it?
Right, I mean that it it is not worth breaking t
Petr Viktorin added the comment:
The bigger problem is that currently, it's not clear what is limited API and
what is not.
I am working to propose a PEP to fix this. It will also cover documentation:
https://discuss.python.org/t/pre-pep-maintaining-the-stable-abi/6986
--
Petr Viktorin added the comment:
> Is there a test suite that checks that the limited API functions can all be
> linked against?
Not yet. There's not even consensus about exactly what functions are part of
the limited API.
I plan to address both issues in PEP 652 (currently in D
Petr Viktorin added the comment:
I want to address this in PEP 652.
--
___
Python tracker
<https://bugs.python.org/issue43235>
___
___
Python-bugs-list mailin
Petr Viktorin added the comment:
I plan to do this slightly differently, see PEP 652.
--
nosy: +petr.viktorin
___
Python tracker
<https://bugs.python.org/issue23
New submission from Petr Viktorin :
PyCFunction_New is part of the Stable ABI (see bpo-21354), but it is not
declared as PyAPI_FUNC, and thus not exported with GCC's -fvisibility=hidden.
To match Windows, it should be declared.
(I don't think this has any real impact, I just want
401 - 500 of 950 matches
Mail list logo
