Activity for PyCXX Python-C++ Connection
-
Barry Alan Scott committed [r464] on Code
Remove building old python 2.7, 3.3 and 3.4.
-
Fix typo
-
Py_UCS4 is not compatible with C++ std::basic_string. Use char32_t as required.
-
There is a lot more then Python 2 removal in these changes. I would like prefer to get this as a patch series with one change at at time. For the usually reasons of its easier to review and not missing issues.
-
Are #13, #14 and this ticket duplicates? Can I just work on the CXX.zip from one of them?
-
andrea created ticket #15
removing python2 support
-
removing python2 support
-
removing python2
-
Python 3.13 and Py_UNICODE
-
There are compiler options to disable reporting deprecation warning. Check your compiler docs to see what the option is and add it to your build.
-
Kohei Takahashi posted a comment on ticket #45
But until then the warning will be present unless you know a way to supress them? Yes, the warnings are always appeared and very noisy even if the program doesn't use Py_UNICODE interface. It is very helpful if adding #if switch to suppress them.
-
There is code that uses Py_UNICODE which means that the warning are expected. Once Py_UNICODE is removed from the API then I will #if use of Py_UNICODE to older python versions that support it. But until then the warning will be present unless you know a way to supress them?
-
Python 3.13 and Py_UNICODE
-
Stefano Rivera created ticket #31
Use setuptools in Demo
-
Sebastian Pipping posted a comment on ticket #44
I read how pycxx is packaged for fedora and its using setup.py - but distutils can be imported. I'm not sure why that is working like that. Why is distutil available on Fedora? distutils may be importable with 3.12 in some places but upstream https://docs.python.org/3.11/library/distutils.html are clear in "deprecated with removal planned for Python 3.12" and the official docs no longer contain a page for that package for 3.12; it's officially removed with regard to CPython upstream. I will investigate...
-
I read how pycxx is packaged for fedora and its using setup.py - but distutils can be imported. I'm not sure why that is working like that. Why is distutil available on Fedora? I will investigate and update. Note since all the setup.py does is install files there is no need to define the compiler. PyCXX is a template library with nothing to be compiled. That happens in the projects that use PyCXX.
-
Hi Barry, I believe the Gentoo package dev-python/pycxx that brought me here uses setup.py and not setup_makefile.py. After a quick look at the Makefile that command python3 setup_makefile.py linux Makefile produced, my impression is: - that it does not have an install target - that the produced files obj/simple.so obj/example.so obj/pycxx_iter.so are not essential (but you tell me) - that g++ would need to be a variable, e.g. $(CXX) - that -g should come from $(CFLAGS) and $(LDFLAGS) to respect...
-
This is a contributed script, that I do not use. Do you have a patch to it that I can use to migrate to setuptools? Or can you use setup_makefile.py? Maybe I should delete setup.py?
-
distutils not removed from setup.py?
-
Update to use msvc 2022 and fix path to tools on up to date windows 11 install.
-
Tag version 7.1.10
-
Fix for building against python 3.13a1
-
Add python 3.13
-
Fix \ used as pathsep but not escaped.
-
Undo braces change as it just swaps between "brace suggested" and "brace used on scaler" in llvm.
-
update README.html for 7.1.9
-
7.1.9 remove use of variables deprecated by python 3.12
-
Fix gcc compiler warning suggesting need for {}.
-
PyCXX Python-C++ Connection released /CXX/PyCXX V7.1.8/README.txt
-
-
Tag version 7.1.8
-
replace use of distutils with sysconfig.
-
Update build to use py.exe and not assume where python is installed.
-
Apply patch to remove deprecated <T> where it is not needed.
-
Detect the arch that the python executable supports and build for thoses arch.
-
Update build tooling to allow compiling with g++ -std=XXX options.
-
I'm updating build to allow testing against each standard. Your patch is good for c++11 to c++20 with GCC. I see some issues with c++98 and c++03 but I happy to not support that far back in time. I'll go on to test with MSVC and xcode/llvm next. I think I will not patch python 2 files are these are, I hope, at this point for legacy systems that will not need the patch and may be using very old compilers.
-
Add specific C compiler rules as sharing with C++ does not work on all compilers.
-
César Douady posted a comment on ticket #30
Hi Barry, Here it is. I actually do not use svn. I have been unable to provide a multi-file diff that is understandable by patch. There are 2 files to patch, one for Python2 the other for Python3. I have not tested the patch for Python2 but it is mostly the same as for Python3 (and it is very simple). I have attached the diffs for the individual files and a global file for both by using diff -ru. If you have a look on these files, you’ll see it is very simple. Sorry for the inconvenience. Regards,...
-
patch does not like the diff. Can you create the diff with svn diff please? Or if you doing this outside of svn then use diff -u? The diff should look like this format: $ diff -u README.txt{~,} --- README.txt~ 2022-08-07 09:54:24.133626013 +0100 +++ README.txt 2022-08-07 09:54:24.133626013 +0100 @@ -2,4 +2,6 @@ Add support for building against python 3.11 alpha 4. +Foo + This Version 7.1.6 with README updates
-
patch does not like the diff. Can you create the diff with svn diff please? Or if you doing this outside of svn then use diff -u?
-
Thanks. I'll run it pass my tests
-
Oups, I meant this should not afffect other compilers as this is the standard way to declare constructors.
-
Support gcc -std=c++20
-
PyCXX V7.1.7 release
-
-
-
Tag version 7.1.7
-
Release 7.1.7 with README changes
-
Tag version 7.1.6
-
Add a check that the version passed in matches the Version.hxx definition
-
Release 7.1.6
-
Support building against python 3.11 alpha 4
-
Fix build all to ignore the 32 bit version on none windows, not the 64 bit version.
-
Fix typos in readme.
-
Fix typos in README.txt
-
PyCXX V7.1.5 release
-
-
-
Tag version 7.1.5
-
Update for 7.1.5 release
-
Add build-all.py missed from last commit.
-
build-all is getting move complex then bash or cmd can handle - replace with a python version.
-
Add python 3.10
-
fix typo in lable
-
In Python 3.9 Unicode API are being deprecated.
-
PyCXX V7.1.4 release
-
-
-
Tag version 7.1.4
-
Update README files
-
Fix test that was failing becuse of a test error.
-
change \t to SP.
-
remove trailing whitespace on lines.
-
Support for Python 3.9 changes. PyEval_CallObjectWithKeywords is deprecated.
-
Prep for 7.1.4 release
-
Patrick Monnerat posted a comment on ticket #29
This issue can be closed as the problem has been fixed by https://sourceforge.net/p/cxx/code/421/
-
In python2 this was easy to support you just defined the __dir__ property. But that was removed in python3 and there is no direct replacement. What makes this work for python3 is using an API to create classes that I could not see how to use in PyCXX. (I don't have the API details to hand at the moment). Curiously this has been this way with PyCXX since I added python 3.9 support and your maybe the 2nd person to notice. I would love to fix this, but have not figured out how.
-
Igor Kalakin created ticket #12
Intellisense for classes
-
DeepSOIC created ticket #11
Make Object::set, release and validate virtual
-
Add support for more number methods, like matrix and the inplace versions.
-
Use IsInstance checking so that derived classes also work.
-
Accept derived class objects
-
Update how to instructions and have only one README.txt file.
-
-
PyCXX V7.1.3 releases
-
-
-
Tag version 7.1.3
-
Update release notes
-
tp_print is on its way out of python and does nothing useful anyway.
-
Prep for 7.1.3 release
-
Fix for https://sourceforge.net/p/cxx/bugs/43/ memory leak caused by wrong ref count on python3 Py::String objects.
-
Thank you for the analysis and proposed fix. I just wanted to ack your work - I hope to work on this shortly.
-
Werner Mayer created ticket #43
Memory leak in constructors of Py::String
-
Thanks for taking the time to explain why this matters. I suspect this is going to take a while for me to understand what has to be changed to make this work. You should stay with your work around in the mean time.
-
Saim Raza posted a comment on ticket #42
The following example will try to demonstrate a real world use case. I have a class MyComputations which delegates heavy computation to C++. The class saves the functions it has to call, and we execute those functions (defined in the extension module) by calling its method do_computations. I have used the simple extension module which comes as a part of pycxx source distribution to make things simple. import simple # extension module defined using pycxx class MyComputations(object): def __init__(self,...
-
I do not understand why pickling the function is required for the use case of pickling objects, which I have shown can be made to work with no changes. Until I understand why its a real world problem I do not plan to work towars a fix.
-
Tests in pickle_tests.py only test that a class defined in an extension is pickleable. However, the issue here is that any method defined as a part of simplemodule is unpickleable. Following tests should pass for this bug to be resolved: assert pickle.loads(pickle.dumps(simple.func)) is simple.func # test keyword method is pickleable assert pickle.loads(pickle.dumps(simple.old_style_class)) is simple.old_style_class # test varargs method is pickleable # Also add test for noargs method
1 >
