Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wrapping for Python 3 #34

Open
mristin opened this issue Nov 21, 2018 · 6 comments
Open

Wrapping for Python 3 #34

mristin opened this issue Nov 21, 2018 · 6 comments

Comments

@mristin
Copy link
Collaborator

mristin commented Nov 21, 2018

Hi,
First of all, thanks for the great work!

Have you considered making a Python wrapper around the library? If not, would you mind if I paraphrase (and reference) your code and package it in a separate python module? The dependency on threading would need to be removed as well as C++11, I suppose.

@mavam
Copy link
Owner

mavam commented Nov 21, 2018

Have you considered making a Python wrapper around the library?

That's certainly an option. However, I wonder whether there are not any other Python packages out there that already cover the functionality of libbf.

If not, would you mind if I paraphrase (and reference) your code and package it in a separate python module?

Not at all, I appreciate any contributions! I'm happy to provide feedback, reviews, and discuss design. I just happen to lack the cycles right now to do the heavy lifting myself.

The dependency on threading would need to be removed as well as C++11, I suppose.

Yeah, that's just a legacy artifact. It could technically be dropped already.

@mristin
Copy link
Collaborator Author

mristin commented Nov 22, 2018

Have you considered making a Python wrapper around the library?

That's certainly an option. However, I wonder whether there are not any other Python packages out there that already cover the functionality of libbf.

Believe it or not, all the current libraries are implemented in pure Python and hence very slow.

The dependency on threading would need to be removed as well as C++11, I suppose.
Yeah, that's just a legacy artifact. It could technically be dropped already.

I'm making a pull request.

@mristin
Copy link
Collaborator Author

mristin commented Nov 22, 2018

It seems that the test code requires Threads (see file test/unit_test_impl.hpp; I closed the pull request #36).

Is there any chance to use a testing framework that does not require Threads?

Otherwise, we'll just stick to conan'izing the package and use it in our C++ code base (see issue #35).

@mavam
Copy link
Owner

mavam commented Nov 29, 2018

Believe it or not, all the current libraries are implemented in pure Python and hence very slow.

Oh, wow. That's surprising.

Is there any chance to use a testing framework that does not require Threads?

I would also prefer a simple solution that doesn't require Threads. I've written a small unit test framework for CAF. With minor modifications, it's probably a reasonable drop-in replacement.

@mavam
Copy link
Owner

mavam commented Nov 29, 2018

If you're using the library in production and considering contributing, I'd be more than happy to discuss with you a few ideas on how to improve the code. Feel free to drop me a mail.

@mristin
Copy link
Collaborator Author

mristin commented Dec 4, 2018

Hi @mavam ,
Let's keep the discussion first public -- if the correspondence grows larger and branched, we can move to private email.

I would also prefer a simple solution that doesn't require Threads. I've written a small unit test framework for CAF. With minor modifications, it's probably a reasonable drop-in replacement.

Is there a reason not to use something more common/standard like https://github.com/catchorg/Catch2? (Let me make a separate issue about removing Threads since this is now not only related to Python bindings.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants