[issue39583] Remove superfluous "extern C" bits from Include/cpython/*.h

Change by STINNER Victor : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: +Python 3.10 -Python 3.9 ___ Python tracker ___

[issue25782] CPython hangs on error __context__ set to the error itself

Change by STINNER Victor : -- nosy: -vstinner ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue39583] Remove superfluous "extern C" bits from Include/cpython/*.h

STINNER Victor added the comment: New changeset b4d5a5cca29426a282e8f1e64b2271fdd1f0a23e by Skip Montanaro in branch 'master': bpo-39583: Remove superfluous "extern C" bits from Include/cpython/*.h (GH-18413) https://github.com/python/cpython/commit/b4d5a5cca29426a282e8f1e64b2271

[issue25782] CPython hangs on error __context__ set to the error itself

Chris Jerdonek added the comment: I think this issue needs deeper discussion to know how to proceed. > If there is a chain A -> B -> C -> D -> E, after assignment C.__context__ = A > we will get a chain C -> A -> B -> D -> E. No exception is lost. I understand not wanting to lose exceptions

[issue25782] CPython hangs on error __context__ set to the error itself

Change by Chris Jerdonek : -- nosy: +chris.jerdonek ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue25782] CPython hangs on error __context__ set to the error itself

Change by Dennis Sweeney : -- pull_requests: +19788 pull_request: https://github.com/python/cpython/pull/20539 ___ Python tracker <https://bugs.python.org/issue25

[issue25782] CPython hangs on error __context__ set to the error itself

Change by Serhiy Storchaka : -- pull_requests: +19787 stage: -> patch review pull_request: https://github.com/python/cpython/pull/20543 ___ Python tracker <https://bugs.python.org/issu

[issue25782] CPython hangs on error __context__ set to the error itself

Dennis Sweeney added the comment: For clarification, the existing behavior on master: When trying to raise the exception H, F -> G -> H -> I -> NULL becomes H -> F -> G -> NULL But when trying to set the exception A on top of B -> C -> D -> E -> C -> ...,

[issue25782] CPython hangs on error __context__ set to the error itself

Change by Gregory P. Smith : -- nosy: -gregory.p.smith ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue25782] CPython hangs on error __context__ set to the error itself

Serhiy Storchaka added the comment: Issue40696 is other example of creating a cycle. I think we should solve general problem preventing loops by merging one of proposed patches. -- resolution: fixed -> stage: commit review -> status: closed -> open versions: +Python 3.10, Python

[issue40642] Cpython "pystate.h" subdirectory wrong

Eric V. Smith added the comment: Thanks for the info. It's weird that this is just showing up for you, and I assume works everywhere else. How are you invoking the compiler, via make, or something else? And, what's the gcc command line look like when this specific file fails? I grepped the

[issue40642] Cpython "pystate.h" subdirectory wrong

/python3.8/Python.h:121, from cpppython.cpp:2: /usr/include/python3.8/cpython/pystate.h:9:10: fatal error: cpython/initconfig.h: No such file or directory 9 | #include "cpython/initconfig.h" | ^~ compilation terminated. Compiler ve

[issue40652] Test test_locale failed when running cpython test on Windows 10 x64 for version 3.9.0a6+

Karthikeyan Singaravelan added the comment: See also https://bugs.python.org/issue37945 -- nosy: +xtreak ___ Python tracker ___

[issue40652] Test test_locale failed when running cpython test on Windows 10 x64 for version 3.9.0a6+

New submission from kpysoze : Test test_locale failed when running cpython test on Windows 10 x64 python.bat -m test -j3 on version Python 3.9.0a6+ 0:19:51 load avg: 0.00 [209/423/2] test_locale failed test test_locale failed -- Traceback (most recent call last): File "C:\personal\cp

[issue40642] Cpython "pystate.h" subdirectory wrong

Eric V. Smith added the comment: Won't either one work, since "Include" is in the "search path"? Is this causing an actual problem? You have this marked as "compile error", but haven't shown any information about the error, such as what compiler, how it's being invoked, and what the error

[issue40642] Cpython "pystate.h" subdirectory wrong

New submission from jpelizza : Line 9 of pystate.h is: #include "cpython/initconfig.h" should be: #include "./initconfig.h" since pystate.h is already inside cpython dir. -- components: C API messages: 369019 nosy: jpelizza priority: normal severity: normal status:

[issue35134] Add a new Include/cpython/ subdirectory for the "CPython API" with implementation details

STINNER Victor added the comment: New changeset b8f704d2190125a7750b50cd9b67267b9c20fd43 by Victor Stinner in branch 'master': bpo-40421: Add Include/cpython/code.h header file (GH-19756) https://github.com/python/cpython/commit/b8f704d2190125a7750b50cd9b67267b9c20fd43

[issue35134] Add a new Include/cpython/ subdirectory for the "CPython API" with implementation details

Change by STINNER Victor : -- pull_requests: +19078 pull_request: https://github.com/python/cpython/pull/19756 ___ Python tracker <https://bugs.python.org/issue35

[issue40314] python code order of magnitude faster than equivalent CPython code for simple import statement

deekay added the comment: The times are correct. It's very noticeable even without using a stopwatch. The C version actually takes 23 seconds to execute. -- ___ Python tracker

[issue40314] python code order of magnitude faster than equivalent CPython code for simple import statement

Zachary Ware added the comment: Are you quite sure you're converting your times correctly, particularly in the C code? The units in the Python version should be seconds; does the C version actually take 23 seconds to execute? What kind of timing do you get if you time both programs with

[issue40314] python code order of magnitude faster than equivalent CPython code for simple import statement

Change by Andy Lester : -- nosy: +petdance ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue40314] python code order of magnitude faster than equivalent CPython code for simple import statement

New submission from deekay : I'm baffled by the performance difference of the following two semantically equivalent(?) programs. Python: #test.py import time starttime=time.time() import tensorflow print(f"Import took: {time.time() - starttime}") vs C usi

[issue40293] Tag libffi build and sources in cpython-source-deps for 3.9.0b1

e for beta 1. -- title: cpython-source-deps project missing release for libffi commits -> Tag libffi build and sources in cpython-source-deps for 3.9.0b1 versions: +Python 3.9 ___ Python tracker <https://bugs.pytho

[issue40293] cpython-source-deps project missing release for libffi commits

Gregory Szorc added the comment: I don't like utilizing the dynamic archive links like https://github.com/python/cpython-source-deps/archive/libffi.zip (even if you pin the commit) because GitHub does not guarantee the file content is deterministic over time. I perform SHA-256 validation

[issue40293] cpython-source-deps project missing release for libffi commits

Steve Dower added the comment: To save the clicks, here's the URL that will get the latest sources from the libffi branch: https://github.com/python/cpython-source-deps/archive/libffi.zip -- ___ Python tracker <https://bugs.python.org/issue40

[issue40293] cpython-source-deps project missing release for libffi commits

Steve Dower added the comment: In master, we build against the latest build out of that repo, which comes from the libffi branch (not the 3.3.0 RC). In 3.8 (and 3.7? I forget) we use the 3.3.0 RC build. There's no later release from libffi (last I checked), and no important fixes since then

[issue40293] cpython-source-deps project missing release for libffi commits

New submission from Gregory Szorc : The https://github.com/python/cpython-source-deps project is missing a source archive release for commits to libffi needed to support building on Windows. The latest release of libffi is version libffi-3.3.0-rc0-r1, which corresponds to https://github.com

[issue40158] MSBuild Extensions in CPython NuGet Package has Bad Expression

Steve Dower added the comment: New changeset e6685ad05385f8cb492e8e1c7c07889a94517f55 by Miss Islington (bot) in branch '3.8': bpo-40158: Fix CPython MSBuild Properties in NuGet Package (GH-19343) https://github.com/python/cpython/commit/e6685ad05385f8cb492e8e1c7c07889a94517f55

[issue40158] MSBuild Extensions in CPython NuGet Package has Bad Expression

Steve Dower added the comment: New changeset 7f70456b92c9ff0bcc4df2a2cec213ab2a897591 by Miss Islington (bot) in branch '3.7': bpo-40158: Fix CPython MSBuild Properties in NuGet Package (GH-19343) https://github.com/python/cpython/commit/7f70456b92c9ff0bcc4df2a2cec213ab2a897591

[issue40158] MSBuild Extensions in CPython NuGet Package has Bad Expression

Change by Steve Dower : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___ ___

[issue40158] MSBuild Extensions in CPython NuGet Package has Bad Expression

Change by miss-islington : -- nosy: +miss-islington nosy_count: 7.0 -> 8.0 pull_requests: +18712 pull_request: https://github.com/python/cpython/pull/19349 ___ Python tracker <https://bugs.python.org/issu

[issue40158] MSBuild Extensions in CPython NuGet Package has Bad Expression

Change by miss-islington : -- pull_requests: +18713 pull_request: https://github.com/python/cpython/pull/19350 ___ Python tracker <https://bugs.python.org/issue40

[issue40158] MSBuild Extensions in CPython NuGet Package has Bad Expression

Steve Dower added the comment: New changeset 6e623ff9d251e0ce86e9b18a01bfd6f067079d7a by Chris Martinez in branch 'master': bpo-40158: Fix CPython MSBuild Properties in NuGet Package (GH-19343) https://github.com/python/cpython/commit/6e623ff9d251e0ce86e9b18a01bfd6f067079d7a

[issue40158] MSBuild Extensions in CPython NuGet Package has Bad Expression

Change by Chris Martinez : -- keywords: +patch pull_requests: +18707 stage: -> patch review pull_request: https://github.com/python/cpython/pull/19343 ___ Python tracker <https://bugs.python.org/issu

[issue40158] MSBuild Extensions in CPython NuGet Package has Bad Expression

Steve Dower added the comment: Either of those fixes look good. I normally use IO.Path personally, which might be because it's been around longer, but anything that works on VS 2017 and later should be fine. -- ___ Python tracker

[issue40158] MSBuild Extensions in CPython NuGet Package has Bad Expression

Chris Martinez added the comment: In testing the fix, another issue has arisen. It appears the specified expression will never yield a usable path. Expression 1: $([msbuild]::GetDirectoryNameOfFileAbove($(MSBuildThisFileDirectory), "python_d.exe")) Expression 2:

[issue40158] MSBuild Extensions in CPython NuGet Package has Bad Expression

Steve Dower added the comment: The closing parentheses are needed - a PR would be appreciated for that. The quotes around a variable reference are unnecessary. At a parser level, it just changes it from a variable reference to a string literal with substitutions (unlike most shells, which

[issue40158] MSBuild Extensions in CPython NuGet Package has Bad Expression

New submission from Chris Martinez : CPython provides a NuGet package as a mechanism to support non-installed Python distributions. The package includes MSBuild support to integrate with its build process. The expressions on lines 32 and 33 in the file: https://github.com/python/cpython

[issue25878] CPython on Windows builds with /W3, not /W4

Alexander Riccio added the comment: Ok, so a draft of this produces 34 warnings, but makes way more changes to the .vcxproj and .filters files than I think it should: https://github.com/ariccio/cpython/commit/60152aa065a3ad861f0359a8ada7f2fbc83a3933 Before I submit a PR, I think I should

[issue40052] Incorrect pointer alignment in _PyVectorcall_Function() of cpython/abstract.h

Change by Matej Cepl : -- nosy: +mcepl nosy_count: 3.0 -> 4.0 pull_requests: +18539 pull_request: https://github.com/python/cpython/pull/19179 ___ Python tracker <https://bugs.python.org/issu

[issue39091] _PyErr_CreateException() must check that the result is an exception (CPython Segfault in 5 lines of code)

Change by STINNER Victor : -- title: CPython Segfault in 5 lines of code -> _PyErr_CreateException() must check that the result is an exception (CPython Segfault in 5 lines of code) ___ Python tracker <https://bugs.python.org/issu

[issue40052] Incorrect pointer alignment in _PyVectorcall_Function() of cpython/abstract.h

Andreas Schneider added the comment: I forgot, for detecting alignment issues or strict aliasing and this also falls under strict aliasing, you need to turn on optimizations. clang -O2 -Werror -Wcast-align ... -- ___ Python tracker

[issue40052] Incorrect pointer alignment in _PyVectorcall_Function() of cpython/abstract.h

Andreas Schneider added the comment: clang -Werror -Wcast-align ... rpm -q clang9 clang9-9.0.1-8.1.x86_64 Does that help? Found in CI of https://gitlab.com/cwrap/pam_wrapper -- ___ Python tracker

[issue40052] Incorrect pointer alignment in _PyVectorcall_Function() of cpython/abstract.h

Emmanuel Arias added the comment: Hi! I cannot reproduce the error. Could you provide the way to reproduce? thanks -- nosy: +eamanu ___ Python tracker ___

[issue39615] cpython/abstract.h not compatible with C90

Peter Eisentraut added the comment: 3.9.0a5 fixes my original issue. Thanks. -- ___ Python tracker ___ ___ Python-bugs-list

[issue40052] Incorrect pointer alignment in _PyVectorcall_Function() of cpython/abstract.h

Change by Andreas Schneider : -- type: -> compile error versions: +Python 3.8 ___ Python tracker ___ ___ Python-bugs-list mailing

[issue40052] Incorrect pointer alignment in _PyVectorcall_Function() of cpython/abstract.h

Change by Roundup Robot : -- keywords: +patch nosy: +python-dev nosy_count: 1.0 -> 2.0 pull_requests: +18494 stage: -> patch review pull_request: https://github.com/python/cpython/pull/19133 ___ Python tracker <https://bugs.python.org/i

[issue40052] Incorrect pointer alignment in _PyVectorcall_Function() of cpython/abstract.h

New submission from Andreas Schneider : In file included from /builds/cryptomilk/pam_wrapper/src/python/pypamtest.c:21: In file included from /usr/include/python3.8/Python.h:147: In file included from /usr/include/python3.8/abstract.h:837: /usr/include/python3.8/cpython/abstract.h:91:11: error

[issue25878] CPython on Windows builds with /W3, not /W4

Steve Dower added the comment: Thanks for all that work! We definitely don't want a noisy build to be merged, but if you submit a PR with only your most confident suppressions then it'll be easier for us to look at the others and see which are scary/not-scary. --

[issue25878] CPython on Windows builds with /W3, not /W4

m to allow the warning right now. C4389 'operator' : signed/unsigned mismatch https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-4-c4389?view=vs-2019 Instances of C4456 and C4457 are likely ok given the length of many CPython functions, but should be

[issue39615] cpython/abstract.h not compatible with C90

Serhiy Storchaka added the comment: I think we should distinguish minimal supported C standard for compiling CPython itself and for compiling extensions. We can use all C99 features supported by main compilers in the code of CPython, but C99 is not even compatible with C++, and it may

[issue38747] Slowly introduce a subset of Jupyter console (IPython) features into CPython command line interactive mode

Terry J. Reedy added the comment: > why a C extension apart and not a patch to `readline`? Search "python ctypes vs c extension". Multiple SO answers. I believe speed and language competancy are big factors. I don't think and stdlib modules use ctypes. --

[issue38747] Slowly introduce a subset of Jupyter console (IPython) features into CPython command line interactive mode

Terry J. Reedy added the comment: Not surprisingly, I agree with Steven that enhancing IDLE may be a better use of core developer time. It and Tkinter (and turtle) are options for the Windows and macOS (and some non-PSF) installers and easily installed on Linux. IDLE has most of the

[issue39615] cpython/abstract.h not compatible with C90

Benjamin Peterson added the comment: C99 is not disallowed in headers. -- nosy: +benjamin.peterson resolution: -> not a bug stage: patch review -> resolved status: open -> closed ___ Python tracker

[issue35134] Add a new Include/cpython/ subdirectory for the "CPython API" with implementation details

STINNER Victor added the comment: New changeset 8c3aee65ed3aff3668da330ccd6f9ba7b2aa4567 by Victor Stinner in branch 'master': bpo-35134: Add Include/cpython/fileutils.h header file (GH-18493) https://github.com/python/cpython/commit/8c3aee65ed3aff3668da330ccd6f9ba7b2aa4567

[issue35134] Add a new Include/cpython/ subdirectory for the "CPython API" with implementation details

STINNER Victor added the comment: New changeset 98921aeaf5879b51e2dd1870c9285cfa8d1a52c7 by Victor Stinner in branch 'master': bpo-35134: Add Include/cpython/bytesobject.h file (GH-18494) https://github.com/python/cpython/commit/98921aeaf5879b51e2dd1870c9285cfa8d1a52c7

[issue35134] Add a new Include/cpython/ subdirectory for the "CPython API" with implementation details

Change by STINNER Victor : -- pull_requests: +17867 pull_request: https://github.com/python/cpython/pull/18494 ___ Python tracker <https://bugs.python.org/issue35

[issue35134] Add a new Include/cpython/ subdirectory for the "CPython API" with implementation details

Change by STINNER Victor : -- pull_requests: +17866 pull_request: https://github.com/python/cpython/pull/18493 ___ Python tracker <https://bugs.python.org/issue35

[issue39615] cpython/abstract.h not compatible with C90

Eric V. Smith added the comment: I'd suggest mentioning this on python-dev, if you want to change the policy. -- ___ Python tracker ___

[issue39615] cpython/abstract.h not compatible with C90

Peter Eisentraut added the comment: That's fair for code internal to CPython itself, but these are header files included by third-party code that is embedding Python, so a bit more flexibility and adaptability would be welcome

[issue35134] Add a new Include/cpython/ subdirectory for the "CPython API" with implementation details

Change by STINNER Victor : -- pull_requests: +17863 pull_request: https://github.com/python/cpython/pull/18490 ___ Python tracker <https://bugs.python.org/issue35

[issue39615] cpython/abstract.h not compatible with C90

Eric V. Smith added the comment: PEP 7 says that this is allowed: Python versions greater than or equal to 3.6 use C89 with several select C99 features: ... - intermingled declarations So I don't think these changes should be accepted. -- nosy: +eric.smith

[issue39615] cpython/abstract.h not compatible with C90

Change by Peter Eisentraut : -- keywords: +patch pull_requests: +17851 stage: -> patch review pull_request: https://github.com/python/cpython/pull/18481 ___ Python tracker <https://bugs.python.org/issu

[issue39615] cpython/abstract.h not compatible with C90

/python3.9/cpython/abstract.h:74:5: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement] 74 | Py_ssize_t offset = tp->tp_vectorcall_offset; | ^~ -- components: Interpreter Core messages: 361880 nosy: petere priority: normal sever

[issue39583] Remove superfluous "extern C" bits from Include/cpython/*.h

Change by Skip Montanaro : -- nosy: +ncoghlan, vstinner ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue39583] Remove superfluous "extern C" bits from Include/cpython/*.h

Change by Skip Montanaro : -- keywords: +patch pull_requests: +17787 stage: -> patch review pull_request: https://github.com/python/cpython/pull/18413 ___ Python tracker <https://bugs.python.org/issu

[issue39583] Remove superfluous "extern C" bits from Include/cpython/*.h

New submission from Skip Montanaro : I noticed that the files in Include/cpython also have extern C declarations, despite the fact that the only files which #include them do as well. Seems like a small bit of cleanup. PR incoming... -- components: C API messages: 361628 nosy

[issue35134] Add a new Include/cpython/ subdirectory for the "CPython API" with implementation details

STINNER Victor added the comment: New changeset bec4186c67345f1e6cd3f8a531bc228f14d7ed7b by Victor Stinner in branch 'master': bpo-35134: Create Include/cpython/listobject.h (GH-18395) https://github.com/python/cpython/commit/bec4186c67345f1e6cd3f8a531bc228f14d7ed7b

[issue35134] Add a new Include/cpython/ subdirectory for the "CPython API" with implementation details

Change by STINNER Victor : -- pull_requests: +17771 pull_request: https://github.com/python/cpython/pull/18395 ___ Python tracker <https://bugs.python.org/issue35

[issue16748] Make CPython test package discoverable

Change by Brett Cannon : -- nosy: -brett.cannon ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue35134] Add a new Include/cpython/ subdirectory for the "CPython API" with implementation details

Nick Coghlan added the comment: New changeset 1e420f849d0c094098543d2c27d35eaec69b2784 by Nick Coghlan in branch 'master': bpo-35134: Migrate frameobject.h contents to cpython/frameobject.h (GH-18052) https://github.com/python/cpython/commit/1e420f849d0c094098543d2c27d35eaec69b2784

[issue35134] Add a new Include/cpython/ subdirectory for the "CPython API" with implementation details

Change by Nick Coghlan : -- pull_requests: +17475 pull_request: https://github.com/python/cpython/pull/18052 ___ Python tracker <https://bugs.python.org/issue35

[issue39091] CPython Segfault in 5 lines of code

Change by Noah : -- keywords: +patch pull_requests: +17126 stage: -> patch review pull_request: https://github.com/python/cpython/pull/17658 ___ Python tracker <https://bugs.python.org/issu

[issue39091] CPython Segfault in 5 lines of code

Noah added the comment: I'm not sure if this will actually appear as a message (I just registered for the bug tracker and I'm not sure how it works), but I wrote the gist and I can definitely make a PR. -- nosy: +coolreader18 ___ Python tracker

[issue39091] CPython Segfault in 5 lines of code

Serhiy Storchaka added the comment: Good catch! Since you already investigated the code, do you mind to create a PR which fixes a crash? I think that adding PyExceptionInstance_Check() in _PyErr_CreateException() could fix the issue. -- ___

[issue39091] CPython Segfault in 5 lines of code

Change by Serhiy Storchaka : -- nosy: +serhiy.storchaka ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue39091] CPython Segfault in 5 lines of code

Christian Heimes added the comment: I can reproduce the issue on master: >>> class E(BaseException): ... def __new__(cls, *args, **kwargs): ... return cls ... >>> def a(): yield ... >>> a().throw(E) Program received signal SIGSEGV, Segmentation fault. _Py_DECREF (op=,

[issue39091] CPython Segfault in 5 lines of code

/6dbe0be2ae2192e90e1a809f1624c694 (I'm not the author of that gist, just reporting it here). -- components: Interpreter Core messages: 358639 nosy: skrause priority: normal severity: normal status: open title: CPython Segfault in 5 lines of code type: crash versions: Python 3.6, Python 3.7, Python 3.8

Re: Writing a CPython extension - calling another sibbling method ?

Dennis, > So... extract the original args, then build a new args object with your > added argument, then call your new function with that... I wanted to respond that prepending a string to an existing argument sounds quite a bit easier than what you are describing, but than I realized that I

Re: Writing a CPython extension - calling another sibbling method ?

Michael, > If you mentioned RPi.GPIO before, I apologize for my mistake. No I didn't, there is nothing to apologize for. > That's very helpful to know. I have no clue to why it would be, as my question has got *zero* to do with it - its valid for /any/ extension using the CPython

Re: Writing a CPython extension - calling another sibbling method ?

Luciano, > Now that's a novel approach to asking for free help: pretending > to be smarter than the people who are trying to help you. What makes you think I'm /pretending/ ?*Ofcourse* I'm smarter than anyone on this earth, didn't you know ? :-D But I'll let you in on a secret: I'm rather

Re: Writing a CPython extension - calling another sibbling method ?

On 20/11/19 9:20 AM, Luciano Ramalho wrote: I apologize to all but the intended recipient for this. I’d have given him feedback in private if I knew his email. I will take leave from the list now. Keep up the good work, friendly responders. Please reconsider. Should your relationship with

Re: Writing a CPython extension - calling another sibbling method ?

spond who might know. > I did not find any example that showed me what I needed to know - simply one > CPython function calling another one.And yes, I've found multiple > documentation pages, including the "Extending and Embedding the Python > Interpreter" ones. Alas, no di

Re: Writing a CPython extension - calling another sibbling method ?

dead giveaway by >> itself ... >> >> > We're working in the dark here >> >> Are you sure ? MRAB didn't seem to have too much problems with both >> recognising and understanding what I was busy with - he posted a spot-on >> example, containing not mo

Re: Writing a CPython extension - calling another sibbling method ?

> We're working in the dark here > > Are you sure ? MRAB didn't seem to have too much problems with both > recognising and understanding what I was busy with - he posted a spot-on > example, containing not more, but also not anything less than what I was > asking for. > > > Looking at

Re: Writing a CPython extension - calling another sibbling method ?

sting examples, as well as the C API documentation I did not find any example that showed me what I needed to know - simply one CPython function calling another one.And yes, I've found multiple documentation pages, including the "Extending and Embedding the Python Interpreter" ones. Alas,

Re: Writing a CPython extension - calling another sibbling method ?

On 11/19/19 9:00 AM, Michael Torrie wrote: > Sure but the Python methods themselves are exposed and accessible and > according to your previous posts, I meant to say the class methods defined by the C code. -- https://mail.python.org/mailman/listinfo/python-list

Re: Writing a CPython extension - calling another sibbling method ?

ible and accessible from pure Python world. I can understand that the pure C stuff is not accessible of course. But the snippets you've shown so far don't show any of that. > And its just a syntax problem. I currently simply have not enough knowledge > about the CPython API lanuages one

[issue27724] PEP3119 inconsintent with actual CPython impl

once: (If this were implemented in CPython, an internal flag ``Py_TPFLAGS_ABSTRACT`` could be used to speed up this check [6]_.) -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bug

Re: Writing a CPython extension - calling another sibbling method ?

MRAB, > It could be something like this: [snip example code] Thank you very much. Your "Call the other method" line shows me that I've been overthinking things. :-( After that I decided to see if I could give the "py_proc1" function two arguments, which worked. That means that the

Re: Writing a CPython extension - calling another sibbling method ?

Michael > Does this have to be done in the C API? As far as I can tell, yes. What I need to do is not exposed by the extension itself, meaning that a wrapper class can't get access to it either. And its just a syntax problem. I currently simply have not enough knowledge about the CPyt

Re: Writing a CPython extension - calling another sibbling method ?

On 11/18/19 1:15 PM, R.Wieser wrote: > The thing is that the arguments of py_proc1 and py_proc2 are the same, but > for a single argument. Does this have to be done in the C API? Depending on how this class is used in your Python code, I would just create a new Python class that extends this

[issue27724] PEP3119 inconsintent with actual CPython impl

Change by Batuhan : -- nosy: +BTaskaya, gvanrossum versions: -Python 3.5 ___ Python tracker ___ ___ Python-bugs-list mailing list

Re: Writing a CPython extension - calling another sibbling method ?

I think I already found how to append my argument to the "args" string-object). In other words, do you have any idea of what either of those calling methods should look like ? An example perhaps ? Having only encountered the CPython API two days ago I'm still fumbling in the dark I'

Re: Writing a CPython extension - calling another sibbling method ?

dy found how to append my argument to the "args" string-object). In other words, do you have any idea of what either of those calling methods should look like ? An example perhaps ? Having only encountered the CPython API two days ago I'm still fumbling in the dark I'm afraid

Re: Writing a CPython extension - calling another sibbling method ?

On 2019-11-18 07:52, R.Wieser wrote: Hello all, I'm trying to edit a binary extension to Python, and have a situation where I would like to create method which adds a single argument, and than jumps to / calls another method. Like this: static PyObject *py_proc1(PyObject *self, PyObject

Writing a CPython extension - calling another sibbling method ?

Hello all, I'm trying to edit a binary extension to Python, and have a situation where I would like to create method which adds a single argument, and than jumps to / calls another method. Like this: static PyObject *py_proc1(PyObject *self, PyObject *args) { Py_RETURN_NONE } static

[issue38816] Clarify about fork() and the CPython runtime in the C-API docs.

Change by Eric Snow : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___ ___

[issue38816] Clarify about fork() and the CPython runtime in the C-API docs.

miss-islington added the comment: New changeset 7a5d4c7a8653cb6be126f87731802aa9a4bc90e2 by Miss Islington (bot) in branch '3.8': bpo-38816: Add notes in the C-API docs about fork in subinterpreters. (GH-17176) https://github.com/python/cpython/commit/7a5d4c7a8653cb6be126f87731802aa9a4bc90e2

[issue38816] Clarify about fork() and the CPython runtime in the C-API docs.

Change by miss-islington : -- keywords: +patch pull_requests: +16686 pull_request: https://github.com/python/cpython/pull/17178 ___ Python tracker <https://bugs.python.org/issue38

<    2   3   4   5   6   7   8   9   10   11   >