[issue36329] use the right python "make -C Doc/ serve"

Hugo van Kemenade added the comment: I've made PRs for this: CPython Docs: https://github.com/python/cpython/pull/32354 Devguide: https://github.com/python/devguide/pull/826 Also set this bpo for Python 3.11. -- versions: +Python 3.11 -Python 3.8

[issue36329] use the right python "make -C Doc/ serve"

Change by Hugo van Kemenade : -- nosy: +hugovk nosy_count: 4.0 -> 5.0 pull_requests: +30406 pull_request: https://github.com/python/cpython/pull/32354 ___ Python tracker ___

[issue22781] ctypes: Differing results between Python and C.

Change by Eryk Sun : -- stage: -> resolved status: open -> closed ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue40993] Don't run Python and C coverage jobs of Travis CI on pull requests

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

[issue40993] Don't run Python and C coverage jobs of Travis CI on pull requests

hai shi added the comment: > Coverage jobs are still run with my changes. > https://codecov.io/gh/python/cpython is still updated. Copy that, thanks. -- ___ Python tracker

[issue40993] Don't run Python and C coverage jobs of Travis CI on pull requests

STINNER Victor added the comment: > coverage jobs can tell us how many features need add unit tests. Coverage jobs are still run with my changes. https://codecov.io/gh/python/cpython is still updated. My change only stops running coverage jobs on pull requests. --

[issue40993] Don't run Python and C coverage jobs of Travis CI on pull requests

hai shi added the comment: > Attached PR skips these jobs on pull requests. I am not familiar with travis ci. coverage jobs can tell us how many features need add unit tests. Can we use other CI services to do this job? MAYBE in checks gate or something other services like

[issue40993] Don't run Python and C coverage jobs of Travis CI on pull requests

miss-islington added the comment: New changeset 071bed842eeff9673bc5c4f64e3916a151132d2a by Miss Islington (bot) in branch '3.8': bpo-40993: Don't run Travis CI coverage on PRs (GH-20916) https://github.com/python/cpython/commit/071bed842eeff9673bc5c4f64e3916a151132d2a --

[issue40993] Don't run Python and C coverage jobs of Travis CI on pull requests

miss-islington added the comment: New changeset 3cf809475a93228a3cb310b4d10d38f3b9d44c1f by Miss Islington (bot) in branch '3.9': bpo-40993: Don't run Travis CI coverage on PRs (GH-20916) https://github.com/python/cpython/commit/3cf809475a93228a3cb310b4d10d38f3b9d44c1f --

[issue40993] Don't run Python and C coverage jobs of Travis CI on pull requests

Change by hai shi : -- nosy: +shihai1991 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue40993] Don't run Python and C coverage jobs of Travis CI on pull requests

Change by miss-islington : -- pull_requests: +20097 pull_request: https://github.com/python/cpython/pull/20918 ___ Python tracker ___

[issue40993] Don't run Python and C coverage jobs of Travis CI on pull requests

Change by miss-islington : -- nosy: +miss-islington nosy_count: 1.0 -> 2.0 pull_requests: +20096 pull_request: https://github.com/python/cpython/pull/20917 ___ Python tracker

[issue40993] Don't run Python and C coverage jobs of Travis CI on pull requests

STINNER Victor added the comment: New changeset fc710ee266e9461fdba9933ec6004318db588820 by Victor Stinner in branch 'master': bpo-40993: Don't run Travis CI coverage on PRs (GH-20916) https://github.com/python/cpython/commit/fc710ee266e9461fdba9933ec6004318db588820 --

[issue40993] Don't run Python and C coverage jobs of Travis CI on pull requests

STINNER Victor added the comment: Documentation about skipping jobs on pull requests: https://docs.travis-ci.com/user/pull-requests/#how-pull-requests-are-built I don't think that the following method works for the issue: "To only build on push events not on pull requests, disable Build on

[issue40993] Don't run Python and C coverage jobs of Travis CI on pull requests

STINNER Victor added the comment: See also bpo-40237: "Test code coverage (C) job of Travis CI fails on test_distutils which creates _configtest.gcno file". -- ___ Python tracker

[issue40993] Don't run Python and C coverage jobs of Travis CI on pull requests

STINNER Victor added the comment: See also "Travis CI doesn't report its status or doesn't run on Python pull requests": https://github.com/python/core-workflow/issues/371 -- ___ Python tracker

[issue40993] Don't run Python and C coverage jobs of Travis CI on pull requests

Change by STINNER Victor : -- keywords: +patch pull_requests: +20095 stage: -> patch review pull_request: https://github.com/python/cpython/pull/20916 ___ Python tracker ___

[issue40993] Don't run Python and C coverage jobs of Travis CI on pull requests

STINNER Victor added the comment: Concrete issue: on my PR 20915, Travis CI mandatory jobs completed successfully but I wasn't able to merge the PR since GitHub says "travis-ci/pr Pending — The Travis CI build is in progress". I cancelled the last running coverage job... but I was still

[issue40993] Don't run Python and C coverage jobs of Travis CI on pull requests

New submission from STINNER Victor : Currently, Travis CI runs C coverage and Python coverage jobs on all pull requests. This is a waste of resources: we should only run these jobs on branches like master. Attached PR skips these jobs on pull requests. Not only it's a waste of resources

Re: py2c - an open source Python to C/C++ is looking for developers

On Monday, July 30, 2012 at 6:27:04 AM UTC-7, manian...@gmail.com wrote: > I created py2c ( http://code.google.com/p/py2c )- an open source Python to > C/C++ translator! > py2c is looking for developers! > To join create a posting in the py2c-discuss Google Group or email me! > Tha

[issue39495] xml.etree.ElementTree.TreeBuilder.start differs between pure Python and C implementations

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

[issue39495] xml.etree.ElementTree.TreeBuilder.start differs between pure Python and C implementations

Serhiy Storchaka added the comment: New changeset 4edc95cf0a2960431621eee9bc194f6225f1690b by Shantanu in branch 'master': bpo-39495: Remove default value from C impl of TreeBuilder.start (GH-18275) https://github.com/python/cpython/commit/4edc95cf0a2960431621eee9bc194f6225f1690b

[issue39722] decimal differs between pure Python and C implementations

Raymond Hettinger added the comment: Thanks for double checking. -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker ___

[issue39722] decimal differs between pure Python and C implementations

Shantanu added the comment: Sounds good, thought I'd check! :-) Definitely looks annoying to remove from the Python version too. -- ___ Python tracker ___

[issue39722] decimal differs between pure Python and C implementations

Raymond Hettinger added the comment: I wouldn't worry about this. The context argument for the dunder methods isn't part of the public API. It is just an internal implementation detail that was necessary for the Python implementation but would make no sense at all for the C implementation

[issue39722] decimal differs between pure Python and C implementations

Change by Karthikeyan Singaravelan : -- nosy: +facundobatista, mark.dickinson, rhettinger, skrah ___ Python tracker ___ ___

[issue39722] decimal differs between pure Python and C implementations

mal as PyDecimal >>> PyDecimal(1).__abs__(None) Decimal('1') >>> CDecimal(1).__abs__(None) Traceback (most recent call last): File "", line 1, in TypeError: expected 0 arguments, got 1 ``` -- components: Library (Lib) messages: 362443 nosy: hauntsaninja priority:

[issue39495] xml.etree.ElementTree.TreeBuilder.start differs between pure Python and C implementations

Change by Shantanu : -- keywords: +patch pull_requests: +17650 stage: -> patch review pull_request: https://github.com/python/cpython/pull/18275 ___ Python tracker ___

[issue39495] xml.etree.ElementTree.TreeBuilder.start differs between pure Python and C implementations

Serhiy Storchaka added the comment: According to the documentation the attrs parameter does not have default value. I think that the C implementation should be changed. https://docs.python.org/3/library/xml.etree.elementtree.html#xml.etree.ElementTree.TreeBuilder.start --

[issue39495] xml.etree.ElementTree.TreeBuilder.start differs between pure Python and C implementations

Shantanu added the comment: Based on https://github.com/python/cpython/blob/master/Modules/_elementtree.c#L2700 and the behaviour at runtime, something like the following patch could work: ``` diff --git a/Lib/xml/etree/ElementTree.py b/Lib/xml/etree/ElementTree.py index

[issue39495] xml.etree.ElementTree.TreeBuilder.start differs between pure Python and C implementations

Change by Karthikeyan Singaravelan : -- nosy: +eli.bendersky, scoder, serhiy.storchaka ___ Python tracker ___ ___ Python-bugs-list

[issue39495] xml.etree.ElementTree.TreeBuilder.start differs between pure Python and C implementations

ion. ``` -- components: Library (Lib) messages: 361002 nosy: hauntsaninja priority: normal severity: normal status: open title: xml.etree.ElementTree.TreeBuilder.start differs between pure Python and C implementations ___ Python tracker <https://bugs.pyth

[issue27530] Non-Critical Compiler WARNING: Python Embedding C++11 does not allow non-constant string literals

STINNER Victor added the comment: This issues has been fixed in Python 3: the second parameter of PyObject_CallMethod() is now a "const char*". Please upgrade to Python 3. -- nosy: +vstinner resolution: -> fixed stage: -> resolved status: open -> closed

[issue28202] Python 3.5.1 C API, the global variable is not destroyed when delete the module

STINNER Victor added the comment: > The problem is resolved if call PyGC_Collect() after PyDict_DelItemString(). > Is it expected to call PyGC_Collect() here? Yeah sadly, to handle such reference cycles, you have to trigger an explicit garbage collection. It doesn't sound like a bug to me.

[issue32424] Synchronize copy methods between Python and C implementations of xml.etree.ElementTree.Element

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

[issue32424] Synchronize copy methods between Python and C implementations of xml.etree.ElementTree.Element

Stefan Behnel added the comment: New changeset 7d952ded6813c896ea3f4234bb8db5247dcb5484 by Stefan Behnel (Gordon P. Hemsley) in branch 'master': bpo-32424: Deprecate xml.etree.ElementTree.Element.copy() in favor of copy.copy() (GH-12995)

[issue32424] Synchronize copy methods between Python and C implementations of xml.etree.ElementTree.Element

Stefan Behnel added the comment: Let's just deprecate it directly (in Py3.9, I guess), given that it was never documented. -- ___ Python tracker ___

Re: Embedding Python in C

tanding. Smalltlak VW 8.3 does not support Python. > >>> I can only call Pyhton code through C/Python API. > >> > >> Ok, but that doesn't mean you need to write code that uses the C-API of > >> Python. All you need to do is: > >> > >> 1) Start

Re: Embedding Python in C

Jesse Ibarra schrieb am 22.07.19 um 18:12: > On Saturday, July 20, 2019 at 1:11:51 PM UTC-6, Stefan Behnel wrote: >> Jesse Ibarra schrieb am 20.07.19 um 04:12: >>> Sorry, I am not understanding. Smalltlak VW 8.3 does not support Python. >>> I can only call Pyhto

Re: Embedding Python in C

On Saturday, July 20, 2019 at 1:11:51 PM UTC-6, Stefan Behnel wrote: > Jesse Ibarra schrieb am 20.07.19 um 04:12: > > Sorry, I am not understanding. Smalltlak VW 8.3 does not support Python. > > I can only call Pyhton code through C/Python API. > > Ok, but that doesn't mean y

Re: Embedding Python in C

Jesse Ibarra schrieb am 20.07.19 um 04:12: > Sorry, I am not understanding. Smalltlak VW 8.3 does not support Python. > I can only call Pyhton code through C/Python API. Ok, but that doesn't mean you need to write code that uses the C-API of Python. All you need to do is: 1) Start up a C

Re: Embedding Python in C

Jesse Ibarra writes: > ... > Now ,I need to bring in shared libraries using C/Python API using Smalltalk. > It seems like I can't directly bring in C shared libraries (.so files). > PROBLEM. With Python, you typically do not load ("bring in") shared libraries explicitl

Re: Embedding Python in C

Sorry, I am not understanding. Smalltlak VW 8.3 does not support Python. I can only call Pyhton code through C/Python API. -- https://mail.python.org/mailman/listinfo/python-list

Re: Embedding Python in C

Jesse Ibarra schrieb am 17.07.19 um 20:39: > My options seem rather limited, I need to make a Pipeline from > (Smalltalk -> C -> Python) then go back (Smalltalk <- C <- Python). > Since Smalltalk does not support Python directly I have to settle with > the C/Python API &g

Re: Embedding Python in C

Am 19.07.19 um 16:26 schrieb Jesse Ibarra: On Friday, July 19, 2019 at 8:17:43 AM UTC-6, Chris Angelico wrote: On Sat, Jul 20, 2019 at 12:16 AM Jesse Ibarra wrote: On Thursday, July 18, 2019 at 2:01:39 PM UTC-6, Chris Angelico wrote: On Fri, Jul 19, 2019 at 5:51 AM Christian Gollwitzer

Re: Embedding Python in C

On Friday, July 19, 2019 at 8:17:43 AM UTC-6, Chris Angelico wrote: > On Sat, Jul 20, 2019 at 12:16 AM Jesse Ibarra > wrote: > > > > On Thursday, July 18, 2019 at 2:01:39 PM UTC-6, Chris Angelico wrote: > > > On Fri, Jul 19, 2019 at 5:51 AM Christian Gollwitzer > > > wrote: > > > > Once you can

Re: Embedding Python in C

> > >> a) to call Python functions from Smalltalk > >> b) call Smalltalk functions from Python > >> c) pass callbacks around, e.g. use a Smalltalk function within a Python > >> list comprehension, and if so, which way > >> d) integrate the class sys

Re: Embedding Python in C

On Sat, Jul 20, 2019 at 12:16 AM Jesse Ibarra wrote: > > On Thursday, July 18, 2019 at 2:01:39 PM UTC-6, Chris Angelico wrote: > > On Fri, Jul 19, 2019 at 5:51 AM Christian Gollwitzer > > wrote: > > > Once you can do this, you can proceed to call a Python function, which > > > in C means that

Re: Embedding Python in C

On Thursday, July 18, 2019 at 2:01:39 PM UTC-6, Chris Angelico wrote: > On Fri, Jul 19, 2019 at 5:51 AM Christian Gollwitzer wrote: > > Once you can do this, you can proceed to call a Python function, which > > in C means that you invoke the function PyObject_CallObject(). A basic > > example is

Re: Embedding Python in C

On Fri, Jul 19, 2019 at 5:51 AM Christian Gollwitzer wrote: > Once you can do this, you can proceed to call a Python function, which > in C means that you invoke the function PyObject_CallObject(). A basic > example is shown here: > >

Re: Embedding Python in C

Am 18.07.19 um 16:18 schrieb Jesse Ibarra: On Wednesday, July 17, 2019 at 2:20:51 PM UTC-6, Christian Gollwitzer wrote: What level of integration do you want to achieve? Do you want a) to call Python functions from Smalltalk b) call Smalltalk functions from Python c) pass callbacks around, e.g

Re: Embedding Python in C

On Wednesday, July 17, 2019 at 2:20:51 PM UTC-6, Christian Gollwitzer wrote: > Am 17.07.19 um 20:39 schrieb Jesse Ibarra: > > My options seem rather limited, I need to make a Pipeline from (Smalltalk > > -> C -> Python) then go back (Smalltalk <- C <- Python)

Re: Embedding Python in C

code: >> https://sourceforge.net/p/cxx/code/HEAD/tree/trunk/CXX/Demo/Python3/simple.cxx >> >> <https://sourceforge.net/p/cxx/code/HEAD/tree/trunk/CXX/Demo/Python3/simple.cxx> >> >> Barry >> PyCXX maintainer >> >>> >>> P

Re: Embedding Python in C

Jesse Ibarra writes: > ... > My options seem rather limited, I need to make a Pipeline from (Smalltalk -> > C -> Python) then go back (Smalltalk <- C <- Python). Since Smalltalk does > not support Python directly I have to settle with the C/Python API > (https://do

Re: Embedding Python in C

Am 17.07.19 um 20:39 schrieb Jesse Ibarra: My options seem rather limited, I need to make a Pipeline from (Smalltalk -> C -> Python) then go back (Smalltalk <- C <- Python). Since Smalltalk does not support Python directly I have to settle with the C/Python API (https://docs.py

Re: Embedding Python in C

> > > Barry > PyCXX maintainer > > > > > Please advise. > > > > Thank you. > > -- > > https://mail.python.org/mailman/listinfo/python-list > > My options seem rather limited, I need to make a Pipeline from (Smalltalk -> C

Re: Embedding Python in C

> On 17 Jul 2019, at 16:57, jesse.ibarra.1...@gmail.com wrote: > > I am using Python3.6: > > [jibarra@redsky ~]$ python3.6 > Python 3.6.8 (default, Apr 25 2019, 21:02:35) > [GCC 4.8.5 20150623 (Red Hat 4.8.5-36)] on linux > Type "help", "copyright", "credits" or "license" for more

Embedding Python in C

I am using Python3.6: [jibarra@redsky ~]$ python3.6 Python 3.6.8 (default, Apr 25 2019, 21:02:35) [GCC 4.8.5 20150623 (Red Hat 4.8.5-36)] on linux Type "help", "copyright", "credits" or "license" for more information. I am

[issue32424] Synchronize copy methods between Python and C implementations of xml.etree.ElementTree.Element

Gordon P. Hemsley added the comment: It seems the final open question on this is whether the mismatch between the Python and C implementations is enough to bypass PendingDeprecationWarning for copy() in favor of jumping straight to DeprecationWarning

[issue36329] use the right python "make -C Doc/ serve"

Berker Peksag added the comment: Yeah, we can add htmlview to devguide. I’ve even added it to Django after I discovered it in CPython :) -- --Berker -- ___ Python tracker ___

[issue36329] use the right python "make -C Doc/ serve"

Stéphane Wirtel added the comment: >Personally, I'd prefer removing the 'serve' target completely. make -C >Doc htmlview should already cover most of its use cases. There is no >deprecation period needed and there is already a replacement (and IMO >better) for it. Hi Berker, When I have read

[issue36329] use the right python "make -C Doc/ serve"

Berker Peksag added the comment: Personally, I'd prefer removing the 'serve' target completely. make -C Doc htmlview should already cover most of its use cases. There is no deprecation period needed and there is already a replacement (and IMO better) for it. -- nosy: +berker.peksag

[issue32424] Synchronize copy methods between Python and C implementations of xml.etree.ElementTree.Element

Change by Gordon P. Hemsley : -- pull_requests: +12918 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue32424] Synchronize copy methods between Python and C implementations of xml.etree.ElementTree.Element

Stefan Behnel added the comment: New changeset 50fed0b64faa305338ef5607b570fe209de6 by Stefan Behnel (Gordon P. Hemsley) in branch 'master': bpo-32424: Improve test coverage for xml.etree.ElementTree (GH-12891)

[issue32424] Synchronize copy methods between Python and C implementations of xml.etree.ElementTree.Element

Change by Gordon P. Hemsley : -- pull_requests: +12822 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue32424] Synchronize copy methods between Python and C implementations of xml.etree.ElementTree.Element

Serhiy Storchaka added the comment: Concur with Stefan. Adding the method deprecated from the born looks silly. We should either deprecate the copy() method in the Python implementation, or add an undeprecated method in the C implementation. The latter should be considered as a new feature.

[issue32424] Synchronize copy methods between Python and C implementations of xml.etree.ElementTree.Element

Stefan Behnel added the comment: We should not add anything to the implementation that we consider legacy elsewhere. Py3 has "always" used the C accelerator module instead of the Python implementation, which suggests that its interface is probably the righter one. So: make sure that the

[issue32424] Synchronize copy methods between Python and C implementations of xml.etree.ElementTree.Element

Gordon P. Hemsley added the comment: Opened issue36685 for discussion of the attrib copy issue. -- ___ Python tracker ___ ___

[issue32424] Synchronize copy methods between Python and C implementations of xml.etree.ElementTree.Element

Gordon P. Hemsley added the comment: Taking a step back, I want to make sure I understand the action items for resolving this: * Add copy() as an alias to __copy__() in the C implementation to match the Python implementation. * Deprecate copy() in favor of copy.copy() in both the Python

[issue32424] Synchronize copy methods between Python and C implementations of xml.etree.ElementTree.Element

Serhiy Storchaka added the comment: > As it stands, calling Element.__deepcopy__() will succeed with the C > implementation and fail with the Python implementation. You should not call it directly. Use copy.deepcopy(). > What is > different about the C implementation that requires the

[issue36329] use the right python "make -C Doc/ serve"

Julien Palard added the comment: New changeset 09a9f1799c8c58f573c50cb2d526422436b8658b by Julien Palard (Stéphane Wirtel) in branch 'master': bpo-36329: Declare the version of Python to use for Tools/scripts/serve.py (#12385)

[issue36329] use the right python "make -C Doc/ serve"

Change by Stéphane Wirtel : -- keywords: +patch pull_requests: +12342 stage: -> patch review ___ Python tracker ___ ___

[issue36329] use the right python "make -C Doc/ serve"

python3 binary from the system or from the virtualenv (pyenv. etc...) -- messages: 338135 nosy: matrixise priority: normal severity: normal status: open title: use the right python "make -C Doc/ serve" versions: Python 3.8 ___ Python track

[issue36329] use the right python "make -C Doc/ serve"

Change by Stéphane Wirtel : -- assignee: -> docs@python components: +Documentation nosy: +docs@python ___ Python tracker ___ ___

[issue22781] ctypes: Differing results between Python and C.

Martin Panter added the comment: Eryk Sun’s explanation makes this sound like a duplicate of Issue 15453, which shows GCC on Linux packing structures into a single byte, and ctypes using the size of the expanded integer type. -- nosy: +martin.panter resolution:

Re: Help: 64bit python call c and got OSError: exception: access violation writing 0xFFFFFFFF99222A60

Figured it out, Thanks On Wed, Jan 24, 2018 at 4:25 PM, Jason Qian wrote: > Again, thanks for the help. Everything is working fine after the changes. > > Here is one more new issue needs some help. > > On c side, > >The createService function can pass a callback handler

Re: Python call c pass a callback function on Linux

HI Dennis, Thanks for the help, After changing WINFUNCTYPE to CFUNCTYPE, the call back function works on the Linux :) Thanks again, Jason On Wed, Jan 24, 2018 at 6:15 PM, Dennis Lee Bieber wrote: > On Wed, 24 Jan 2018 17:16:22 -0500, Jason Qian via

Re: Python call c pass a callback function on Linux

On Thu, Jan 25, 2018 at 9:16 AM, Jason Qian via Python-list wrote: > Hi, > > I have following code that works fine on windows. > > InvocationCB=WINFUNCTYPE(None, c_char_p, c_int) > submit = lib.submit > submit.argtypes = [ctypes.c_void_p, c_void_p,InvocationCB] >

Python call c pass a callback function on Linux

Hi, I have following code that works fine on windows. InvocationCB=WINFUNCTYPE(None, c_char_p, c_int) submit = lib.submit submit.argtypes = [ctypes.c_void_p, c_void_p,InvocationCB] submit.restype = ctypes.c_int def handleResponse(message, code): print('--- handleResponse ---')

Re: Help: 64bit python call c and got OSError: exception: access violation writing 0xFFFFFFFF99222A60

Again, thanks for the help. Everything is working fine after the changes. Here is one more new issue needs some help. On c side, The createService function can pass a callback handler as second parameter. Without callback handler, it works fine. But if we add the callback handler, the

Re: python to C code generator

On Tue, 23 Jan 2018 17:43:18 +, bartc wrote: > It wouldn't be a satisfactory way of writing C programs. So, although > I'm not that big a fan of C syntax, it might be better to write C as C, > and Python as Python, to avoid confusion.) This. The fundamental reality is that `a +

Re: python to C code generator

could target C, but not Python to C. It would be feasible to write C code in a syntax that looks rather like Python, but it won't be real Python, and you can't run it as Python. It wouldn't be a satisfactory way of writing C programs. So, although I'm not that big a fan of C syntax, it might be

Re: python to C code generator

apanese into Russian". No, it doesn't; the complexity is inherent in the problem. You cannot translate Python code into C code without either (a) reimplementing all of Python's semantics, as Cython does; or (b) drastically changing the semantics, such that even the very simplest of code might

Re: python to C code generator

bhattacharya wrote: Hi, Is there any python framework or any tool as  which can generate C code from python code as it is . Thanks, Kushal hi, I have found nuitka as asuitable candidate but it seems that nuitka doesnt generate a simple C code which could be included as a C file in another

Re: python to C code generator

On Wednesday, January 17, 2018 at 4:34:23 PM UTC+5:30, kushal bhattacharya wrote: > Hi, > Is there any python framework or any tool as which can generate C code from > python code as it is . > > Thanks, > Kushal ok so which python tool would be the best one whi

Re: python to C code generator

>> bhattacharya wrote: >>>> >>>>> Hi, >>>>> Is there any python framework or any tool as which can generate C >>>>> code from python code as it is . >>>>> >>>>> Thanks, >>>>>

Re: python to C code generator

>>>> Hi, >>>>> Is there any python framework or any tool as which can generate C >>>>> code from python code as it is . >>>>> >>>>> Thanks, >>>>> Kushal >>>>> >>>> yes i have but it generat

Re: python to C code generator

as which can generate C code from python code as it is . Thanks, Kushal yes i have but it generates a complex C code with python dependencies.I want to call the generated function from another C code but i Cant figure out how to do that Because the translation isn't simply defined. I've just

Re: python to C code generator

ool as which can generate C code > >> from python code as it is . > >> > >> Thanks, > >> Kushal > > > > yes i have but it generates a complex C code with python dependencies.I > > want to call the generated function from another C code but

Re: python to C code generator

On 23/01/2018 13:23, kushal bhattacharya wrote: On Wednesday, January 17, 2018 at 4:34:23 PM UTC+5:30, kushal bhattacharya wrote: Hi, Is there any python framework or any tool as which can generate C code from python code as it is . Thanks, Kushal yes i have but it generates a complex C

Re: python to C code generator

On Wednesday, January 17, 2018 at 4:34:23 PM UTC+5:30, kushal bhattacharya wrote: > Hi, > Is there any python framework or any tool as which can generate C code from > python code as it is . > > Thanks, > Kushal yes i have but it generates a complex C code with python d

Re: python to C code generator

What about Cython? On 01/23/2018 01:25 PM, kushal bhattacharya wrote: On Wednesday, January 17, 2018 at 4:34:23 PM UTC+5:30, kushal bhattacharya wrote: Hi, Is there any python framework or any tool as which can generate C code from python code as it is . Thanks, Kushal hi, I have found

Re: python to C code generator

On Wednesday, January 17, 2018 at 4:34:23 PM UTC+5:30, kushal bhattacharya wrote: > Hi, > Is there any python framework or any tool as which can generate C code from > python code as it is . > > Thanks, > Kushal hi, I have found nuitka as asuitable candidate but it seems

Re: Help: 64bit python call c and got OSError: exception: access violation writing 0xFFFFFFFF99222A60

Thanks for the help, Jason On Mon, Jan 22, 2018 at 5:41 PM, eryk sun wrote: > On Mon, Jan 22, 2018 at 9:00 PM, Jason Qian via Python-list > wrote: > > > > I am using ctypes on Windows to interface with a dll and it works fine > > on Linux and

Re: Help: 64bit python call c and got OSError: exception: access violation writing 0xFFFFFFFF99222A60

Thanks you very much, fixed the problem :) On Mon, Jan 22, 2018 at 4:28 PM, Random832 wrote: > On Mon, Jan 22, 2018, at 16:00, Jason Qian via Python-list wrote: > > Hello! > > > > I am using ctypes on Windows to interface with a dll and it works fine > > on Linux and

Re: Help: 64bit python call c and got OSError: exception: access violation writing 0xFFFFFFFF99222A60

On Mon, Jan 22, 2018 at 9:00 PM, Jason Qian via Python-list wrote: > > I am using ctypes on Windows to interface with a dll and it works fine > on Linux and windows 32-bit python. But, when using 64-bit python, we got > error "exception: access violation writing

Re: Help: 64bit python call c and got OSError: exception: access violation writing 0xFFFFFFFF99222A60

On Mon, Jan 22, 2018, at 16:00, Jason Qian via Python-list wrote: > Hello! > > I am using ctypes on Windows to interface with a dll and it works fine > on Linux and windows 32-bit python. But, when using 64-bit python, we got > error "exception: access violation writing 0x99222A60".

Help: 64bit python call c and got OSError: exception: access violation writing 0xFFFFFFFF99222A60

Hello! I am using ctypes on Windows to interface with a dll and it works fine on Linux and windows 32-bit python. But, when using 64-bit python, we got error "exception: access violation writing 0x99222A60". Checking our server, it seems work without any problem. but the python

[issue32424] Synchronize copy methods between Python and C implementations of xml.etree.ElementTree.Element

Gordon P. Hemsley <gphems...@gphemsley.org> added the comment: >> As discussed above, starting with msg309074, __deepcopy__() is being added >> to the Python implementation because it already exists in the C >> implementation. > > Python implementation sho

Re: python to C code generator

On 17/01/2018 11:04, kushal bhattacharya wrote: Hi, Is there any python framework or any tool as which can generate C code from python code as it is . What C code would you expect to see from this line of Python: a = b + c ? -- https://mail.python.org/mailman/listinfo/python-list

  1   2   3   4   5   6   7   8   9   10   >