Change by Hai Shi :
--
nosy: +shihai1991
___
Python tracker
<https://bugs.python.org/issue46613>
___
___
Python-bugs-list mailing list
Unsubscribe:
Hai Shi added the comment:
> _functoolsmodule is a core bootstrap module and defined in
> Modules/Setup.bootstrap. It has no external dependencies. There is no reason
> and no point to disable the module.
+1.
> Cristian, in this case - is there a reason to keep `skipUnless
Hai Shi added the comment:
> If not, I'd like to close this (with apologies for not doing my research and
> letting Hai Shi do unmerged work).
> If a use case is found, I suspect it'll need a different solution – perhaps
> allowing PyType_Slot·s
OK, I close this bpo. W
Change by Hai Shi :
--
nosy: +shihai1991
___
Python tracker
<https://bugs.python.org/issue46368>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Hai Shi :
--
nosy: +shihai1991
___
Python tracker
<https://bugs.python.org/issue46417>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Hai Shi :
--
nosy: +shihai1991
___
Python tracker
<https://bugs.python.org/issue45691>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Hai Shi :
--
nosy: +shihai1991
nosy_count: 4.0 -> 5.0
pull_requests: +28101
pull_request: https://github.com/python/cpython/pull/29876
___
Python tracker
<https://bugs.python.org/issu
Hai Shi added the comment:
OK,thanks. If it's just only interal calling, I don't think throwing a
exception would break anything. As your pasted code shows, the modules have
judeged the tp_name is inited or not.
--
___
Python track
Change by Hai Shi :
--
nosy: +shihai1991
___
Python tracker
<https://bugs.python.org/issue43588>
___
___
Python-bugs-list mailing list
Unsubscribe:
Hai Shi added the comment:
Hi, Victor Milovanov. The memory allocated by interpreter will be freed after
calling Py_Finalize().
--
nosy: +pablogsal, shihai1991
___
Python tracker
<https://bugs.python.org/issue45
Hai Shi added the comment:
> I use the Linux operating system (openeuler), kernel version 4.19.90, GCC
> version 7.3.0. I directly run the following statement in the virtual machine
Hm. I haven't openeuler system, but I get docker container of the euler system.
The tests have p
Hai Shi added the comment:
Hi, Chuanlong. Would you mind to upload a demo for this question?
--
nosy: +shihai1991
___
Python tracker
<https://bugs.python.org/issue45
Hai Shi added the comment:
> PEP 3121 is not withdrawn; PEP 630 is not withdrawn. What is then expected of
> a new PEP? Or the other way around: what is missing from those two PEPs?
Thanks Erlend for the relative information you provided. AFAIK, the stdlib is
not the extension
Hai Shi added the comment:
>Ah, sorry, I overlooked the flags.
It's Okay.
>This does beg the question: what else from PyType_Spec will be needed?
I guess we don't want to allow additional slots/methods.
+1.
>Also, note that converting the stdlib to heap types is suspend
Hai Shi added the comment:
> In _PyStructSequence_InitType, it will check type is initialized.
It's a internal C API :)
> when type already been initialized, should return 0 rather than throw
> exception.
The another solution is to check the type status
Hai Shi added the comment:
> The only thing the proposed PR adds is a way to set ht_module, which actually
> isn't very useful (it's used for module state access.
Hm, there have some static types. so I create the
PyStructSequence_FromModuleAndDes() could receive tp_flags
Hai Shi added the comment:
> the simplest solution is calling `type_set_name`, even if that runs some
> unnecessary checks.
Hm, I haven't find any case who use dynamical tp_name of Type_Spec temporarily.
If we meet this user case, Adding a new object pointer of type name in i
Change by Hai Shi :
--
nosy: +shihai1991
___
Python tracker
<https://bugs.python.org/issue45316>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Hai Shi :
--
keywords: +patch
pull_requests: +26955
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/28573
___
Python tracker
<https://bugs.python.org/issu
Hai Shi added the comment:
> More generally, this would need solving one of the remaining limitations of
> the limited API (PEPs 489, 630): type-specific data.
Agree. We can't track and destroy the memory block created from t
Change by Hai Shi :
--
nosy: +shihai1991
___
Python tracker
<https://bugs.python.org/issue45127>
___
___
Python-bugs-list mailing list
Unsubscribe:
Hai Shi added the comment:
> But I encourage you to try, so you get a better understanding of the problem
> :)
OK, thanks, Petr. I try to add this C API to see what will happen :)
--
___
Python tracker
<https://bugs.python.org/i
hai shi added the comment:
bpo-45113: [subinterpreters][C API] Add a new function to create
PyStructSequence from Heap.
--
versions: +Python 3.11 -Python 3.10
___
Python tracker
<https://bugs.python.org/issue40
New submission from hai shi :
Copied from https://bugs.python.org/issue40512#msg399847:
Victor: PyStructSequence_InitType2() is not compatible with subinterpreters: it
uses static types. Moreover, it allocates tp_members memory which is not
released when the type is destroyed. But I'
hai shi added the comment:
> PyStructSequence_InitType2() is not compatible with subinterpreters: it uses
> static types. Moreover, it allocates tp_members memory which is not released
> when the type is destroyed. But I'm not sure that the type is ever destroyed,
>
Change by hai shi :
--
nosy: +shihai1991
___
Python tracker
<https://bugs.python.org/issue44359>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by hai shi :
--
nosy: +shihai1991
___
Python tracker
<https://bugs.python.org/issue45062>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by hai shi :
--
nosy: +shihai1991
___
Python tracker
<https://bugs.python.org/issue45020>
___
___
Python-bugs-list mailing list
Unsubscribe:
hai shi added the comment:
Is it a defined behavior?
I got this sentence from pep-3148: Deadlock can occur when the callable
associated with a Future waits on the results of another Future.
--
nosy: +shihai1991
___
Python tracker
<ht
hai shi added the comment:
This bpo isn't a bug, so I close it now. If there are some enhancements need to
be discussed, we can reopen it:)
--
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Python t
hai shi added the comment:
> Or are you saying something can be done in Python's components to
handle this use case transparently? so the user won't have to put GIL
locks in his code.
Sorry, I don't explain it good enough. You have said what I wanted to say:)
> Yes, bu
hai shi added the comment:
> which can be wrapped within the calls to PyGILState_Ensure/Release.
OK, it's a good idea. But I think this enhancement will break the back
compatibility.
> python is initialized within that entrypoint
python is initialized when you
hai shi added the comment:
How about this one?
int foo(void)
{
printf(stderr, "foo BEGIN\n");
if (!Py_IsInitialized()) {
fprintf(stderr, "python already initialized\n");
return -1;
}
const char *module_name = "foo";
PyGILState_STATE state = P
hai shi added the comment:
> Should this be closed?
Copy from PEP-632: In Python 3.10 and 3.11, distutils will be formally marked
as deprecated. All known issues will be closed at this time.
I close this bpo. If there have some block issues to discuss, we can reopen
it ag
hai shi added the comment:
> Now, I wonder if we should also introduce PyType_GetModuleName for
> __module__, or stop and close this as fixed.
IMO, I suggest to close this bpo. We can get the `tp_name` by the C API now. If
there have user want get `__module__`, we can open a new
hai shi added the comment:
> (Note that the "def->m_size == -1" means that the module does not support
> sub-interpreters, because it has global state.
Make Sense. It's more better and exact than my suggestion :)
--
__
hai shi added the comment:
> Maybe the old behavior was better: if an extension uses the old API, share
> its state between all interpreters.
+1. I create PR-27794, which use `def->m_slots` to identify the extension
module created from `PyModule_Create()` or not.
Change by hai shi :
--
keywords: +patch
pull_requests: +26263
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/27794
___
Python tracker
<https://bugs.python.org/issu
Change by hai shi :
--
nosy: +paul.j3, rhettinger
___
Python tracker
<https://bugs.python.org/issue44865>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by hai shi :
--
nosy: +paul.j3, rhettinger
___
Python tracker
<https://bugs.python.org/issue44864>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by hai shi :
--
pull_requests: +26143
pull_request: https://github.com/python/cpython/pull/27649
___
Python tracker
<https://bugs.python.org/issue42
hai shi added the comment:
> - for the qualified name you can use `PyObject_GetAttrString(t,
> "__qualname__")`
After PR-27551 merged, we can use PyType_GetQualName() to get type's
`__qualname__`.
--
___
Python tracker
<
Change by hai shi :
--
pull_requests: +26057
pull_request: https://github.com/python/cpython/pull/27551
___
Python tracker
<https://bugs.python.org/issue42
Change by hai shi :
--
nosy: +paul.j3, rhettinger
___
Python tracker
<https://bugs.python.org/issue44748>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from hai shi :
Objects/obmalloc.c hasn't use the Py_USING_MEMORY_DEBUGGER macro now. So this
line can be deleted.
https://github.com/python/cpython/blob/31bec6f1b178dadec3cb43353274b4e958a8f015/Misc/README.valgrind#L17.
--
assignee: docs@python
components: Document
hai shi added the comment:
> - there is still no way to get t.tp_name
Can we create PyType_GetDataSlot function to return the data pointer?
> If we go this way, why not add PyType_GetQualName as well?
+1. I will create another PR after PR-23903
hai shi added the comment:
Hi, Simon. Thanks for your report.
There have an relatived issue in: bpo-43145, this bpo have mentioned
`Py_Initialize()`. So I suggest to close this bpo. We can reopen it if we have
seperated questions need to be discussed in here.
> Running a Valgrind memch
hai shi added the comment:
> The following locks are leaked:
> 1.
> https://github.com/python/cpython/blob/196d4deaf4810a0bba75ba537dd40f2d71a5a634/Python/pystate.c#L78
> 2.
> https://github.com/python/cpython/blob/196d4deaf4810a0bba75ba537dd40f2d71a5a634/Python/pystate.c#L8
Change by hai shi :
--
pull_requests: +25789
pull_request: https://github.com/python/cpython/pull/27240
___
Python tracker
<https://bugs.python.org/issue37
hai shi added the comment:
I use this add_printf_to_get_details_from_race_condition.patch to get some
details of the running subinterpreter.
The successful output of test_already_running:
test_already_running (test.test__xxsubinterpreters.RunStringTests) ... In
interp_create, the current
Change by hai shi :
--
pull_requests: +25320
pull_request: https://github.com/python/cpython/pull/26733
___
Python tracker
<https://bugs.python.org/issue37
Change by hai shi :
--
pull_requests: +25182
pull_request: https://github.com/python/cpython/pull/26598
___
Python tracker
<https://bugs.python.org/issue37
hai shi added the comment:
OK, I try to take a look after Kyle leaves temporarily. But I haven't replicate
this issue in my vm in recent days :(
--
nosy: +shihai1991
versions: +Python 3.11 -Python 3.8
___
Python tracker
<https://bugs.py
Change by hai shi :
--
nosy: +shihai1991
___
Python tracker
<https://bugs.python.org/issue44263>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by hai shi :
--
pull_requests: +25045
pull_request: https://github.com/python/cpython/pull/26451
___
Python tracker
<https://bugs.python.org/issue42
hai shi added the comment:
> * functools._lru_list_elem
Looks like this type have performance in issue PR-5008 when supporting GC. I am
not sure there have other similar questions or not.
--
___
Python tracker
<https://bugs.python.org/issu
Change by hai shi :
--
versions: +Python 3.11 -Python 3.10
___
Python tracker
<https://bugs.python.org/issue4>
___
___
Python-bugs-list mailing list
Unsub
hai shi added the comment:
> METH_VARARGS and METH_KEYWORDS are part of the stable ABI.
Copy that, thanks, petr.
--
___
Python tracker
<https://bugs.python.org/issu
Change by hai shi :
--
nosy: +orsenthil
___
Python tracker
<https://bugs.python.org/issue40938>
___
___
Python-bugs-list mailing list
Unsubscribe:
hai shi added the comment:
> The main limitation to use the limited C API for stdlib is Argument Clinic
> which attempts to always emit the most efficient code, like using the
> METH_FASTCALL calling convention and use private functions like
> _PyArg_CheckPositional(
Change by hai shi :
--
pull_requests: +24719
pull_request: https://github.com/python/cpython/pull/26080
___
Python tracker
<https://bugs.python.org/issue41
hai shi added the comment:
Thanks Marc-Andre for your supplement of PEP-100.
Thanks Inada, victor for your review and merge.
After PR-23096 merged, I suggest to close this bpo.
If there have any other questions, we can reopen it again.
--
resolution: -> fixed
stage: patch rev
hai shi added the comment:
>Ideally if we did not intend to break libraries then can this be fixed?
Or if it is acceptable to have such a breaking change.
Hi, akdor1154, thanks for your notice. It was a bugfix in fact:)
https://bugs.python.org/issue37751#msg349448
> maybe this is
hai shi added the comment:
> I would like this type (and other types that have been or will be converted
> to heap types) to remain immutable.
Hi, Guido. I am interested in what have been broken in fact? or it's a
defined behavior?
> I think we may need a new flag bit mea
Change by hai shi :
--
nosy: +shihai1991
___
Python tracker
<https://bugs.python.org/issue43845>
___
___
Python-bugs-list mailing list
Unsubscribe:
hai shi added the comment:
I created PR 25226. It's a another way to solve this problem.
Compared to PR 15175, `_set_sentinel()` don't need to receive any params :)
--
___
Python tracker
<https://bugs.python.o
Change by hai shi :
--
nosy: +shihai1991
___
Python tracker
<https://bugs.python.org/issue43753>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by hai shi :
--
nosy: +shihai1991
nosy_count: 12.0 -> 13.0
pull_requests: +23963
pull_request: https://github.com/python/cpython/pull/25226
___
Python tracker
<https://bugs.python.org/issu
hai shi added the comment:
> Perhaps it would be better that compiling them not be attempted with
> configuring --with-trace-refs?
+1. The limited C API can't be build under Py_TRACE_REFS now.
--
___
Python tracker
<https://b
Change by hai shi :
--
pull_requests: +23922
pull_request: https://github.com/python/cpython/pull/25180
___
Python tracker
<https://bugs.python.org/issue41
Change by hai shi :
--
pull_requests: +23865
pull_request: https://github.com/python/cpython/pull/25115
___
Python tracker
<https://bugs.python.org/issue4
hai shi added the comment:
> By the way, maybe Py_LIMITED_API should be defined in xxlimited.c, rather
> than in setup.py.
+1. Defining Py_LIMITED_API in xxlimited.c is more direct than in setup.py. so
I created the PR-25115.
--
___
Change by hai shi :
--
pull_requests: -23859
___
Python tracker
<https://bugs.python.org/issue4111>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by hai shi :
--
keywords: +patch
pull_requests: +23864
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/25115
___
Python tracker
<https://bugs.python.org/issu
Change by hai shi :
--
nosy: +shihai1991
nosy_count: 25.0 -> 26.0
pull_requests: +23859
pull_request: https://github.com/python/cpython/pull/25115
___
Python tracker
<https://bugs.python.org/iss
hai shi added the comment:
bpo-41718
--
___
Python tracker
<https://bugs.python.org/issue41551>
___
___
Python-bugs-list mailing list
Unsubscribe:
hai shi added the comment:
There have another related issue and have been fixed now in bpo 41718.
So I suggest to close this bpo.
--
resolution: -> duplicate
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bug
Change by hai shi :
--
nosy: +barry, maxking, r.david.murray
___
Python tracker
<https://bugs.python.org/issue43554>
___
___
Python-bugs-list mailing list
Unsub
Change by hai shi :
--
nosy: +shihai1991
nosy_count: 8.0 -> 9.0
pull_requests: +23686
pull_request: https://github.com/python/cpython/pull/24922
___
Python tracker
<https://bugs.python.org/issu
hai shi added the comment:
+1 from me. 3.10.0 final haven't been released, so no one will be affected.
--
nosy: +shihai1991, vstinner
___
Python tracker
<https://bugs.python.org/is
hai shi added the comment:
> True. Is there many external users of this API? I could not find any relevant
> examples using searchcode.com.
Hm, many teams don't open their code, so we get check all user cases by
searchcode web. So I have no any better sugessti
hai shi added the comment:
> It is not "bad"; it is just more wordy.
Agree. Using sturct will be more easy check the members.
But converting the decimal c api may breaks the compatibility, because some
macros like `PyDec_TypeCheck_INDEX` have been expos
Change by hai shi :
--
keywords: +patch
nosy: +shihai1991
nosy_count: 1.0 -> 2.0
pull_requests: +23470
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/24688
___
Python tracker
<https://bugs.python.org/i
hai shi added the comment:
Hi, Chigozirim Chukwu. Thanks for your report.
There have releated comment in: https://bugs.python.org/issue17050#msg315716
--
nosy: +paul.j3, rhettinger, shihai1991
versions: +Python 3.10
___
Python tracker
<ht
hai shi added the comment:
> It would be great to have a tool to check that all symbols exported on Unix
> are also exported on Windows.
I write a demo in PR 24639(compare the stable_abi.dat to python3dll.c).
And the output result:
```
Some symbols from the limited API on windows are m
Change by hai shi :
--
keywords: +patch
nosy: +shihai1991
nosy_count: 4.0 -> 5.0
pull_requests: +23424
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/24639
___
Python tracker
<https://bugs.python.org/i
hai shi added the comment:
Maybe Guido can give you some answers.
Related commit:
https://github.com/python/cpython/commit/f26cda62b68b68c07666f2f21b1f16ded03afa37.
--
nosy: +gvanrossum, shihai1991
___
Python tracker
<https://bugs.python.
Change by hai shi :
--
nosy: +giampaolo.rodola
___
Python tracker
<https://bugs.python.org/issue43285>
___
___
Python-bugs-list mailing list
Unsubscribe:
hai shi added the comment:
> So it doesn't sound like a good idea to immediately remove these two macros.
MAYBE we can update the annotation in pyfpe.h to address that we will remove
those macros in python 4.0.
The fpe have been removed, so those macros will be removed
Change by hai shi :
--
nosy: +paul.j3, rhettinger
___
Python tracker
<https://bugs.python.org/issue43259>
___
___
Python-bugs-list mailing list
Unsubscribe:
hai shi added the comment:
>> PyCFunction_NewEx is part of the limited API as well, even though it's
>> undocumented. People can call it.
>
>Wait no, I wrote too soon.
>PyCFunction_NewEx is part of the limited API as well, even though it's
>>undocumente
Change by hai shi :
--
nosy: +paul.j3
___
Python tracker
<https://bugs.python.org/issue43160>
___
___
Python-bugs-list mailing list
Unsubscribe:
hai shi added the comment:
I found `type.__name__` has the implementation details in
https://github.com/python/cpython/blob/master/Objects/typeobject.c#L486.
IMHO, keep the consistency in `PyType_GetName()` is OK.
Victor, Petr. Do you think it make senses
hai shi added the comment:
> The _decimal API is also just an array of pointers. Should we change that to
> a struct as well?
Hi, victor. Do you have suggestion about it :)
--
___
Python tracker
<https://bugs.python.org/i
hai shi added the comment:
> The _decimal API is also just an array of pointers. Should we change that to
> a struct as well?
+1. IMHO, structure is more directly than pointer array. And there haven't
exposing this pointer array to users(no backward co
hai shi added the comment:
> It's already the case. Example
Nice, interesting case.
--
___
Python tracker
<https://bugs.python.org/issue42979>
___
_
Change by hai shi :
--
keywords: +patch
pull_requests: +23152
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/24333
___
Python tracker
<https://bugs.python.org/issu
hai shi added the comment:
> If PyCapsule_Import() fails, zoneinfomodule_exec() returns 0 (success) with
> an exception raised.
Why not return -1 directly when PyCapsule_Import() fails?
It looks like more simpler. Do I miss something?
--
nosy: +shih
hai shi added the comment:
I have checked all capi instances have been allocated in the heap memory.
So I think this bpo can be closed ;)
Thanks Erlend for your contribution.
Thanks victor, petr for your review&merge.
--
resolution: -> fixed
stage: patch review -> resol
Change by hai shi :
--
keywords: +patch
pull_requests: +23125
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/24304
___
Python tracker
<https://bugs.python.org/issu
1 - 100 of 700 matches
Mail list logo