You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
Currently the read_dimacs_file method exposed through the python api requires a file path and works by opening the file. This puts an unnecessary constraint when using the api to write out a file to disk especially if the string is constructed in python this just seems unecessary.
we can expose this via the python interface as a file like object (not sure how that connects with pybind11 but there should be a way). Ideally the interface would take either a file like object like a file, BytesIO,or a raw string we can pass to this.
Describe alternatives you've considered
The other alternative is just in pure python, basically adds a method that takes a stream or string and dumps it to a temp file and then we pass the temp file path to the existing read_dimacs, but doing it this way would just be shifting the current workaround from external to tweedledum to internal.
Additional context
The text was updated successfully, but these errors were encountered:
Binding to istream seems to be complicated. I think that for the purposes of
unit testing it should be enough to accept a string which contains the whole
DIMACS. (I expect that the most common usage would actually be for passing
the a file.)
I will work on this later, unless anyone else want to give it a try as a firs contribution
to tweedledum.
+1 to support istream. It would be much easier in a demo to define the content of the file in a your jupyter notebook and then using it directly as StringIO.
Is your feature request related to a problem? Please describe.
Currently the
read_dimacs_file
method exposed through the python api requires a file path and works by opening the file. This puts an unnecessary constraint when using the api to write out a file to disk especially if the string is constructed in python this just seems unecessary.Describe the solution you'd like
The dimacs parser being used supports passing in a dimacs file as an
std::istream
: https://lorina.readthedocs.io/en/latest/dimacs.html#_CPPv4N6lorina11read_dimacsERNSt7istreamERK13dimacs_readerP17diagnostic_enginewe can expose this via the python interface as a file like object (not sure how that connects with pybind11 but there should be a way). Ideally the interface would take either a file like object like a
file
,BytesIO,
or a raw string we can pass to this.Describe alternatives you've considered
The other alternative is just in pure python, basically adds a method that takes a stream or string and dumps it to a temp file and then we pass the temp file path to the existing
read_dimacs
, but doing it this way would just be shifting the current workaround from external to tweedledum to internal.Additional context
The text was updated successfully, but these errors were encountered: