[MRG] "Overload" cython consume methods with type introspection#1787
Conversation
|
On my laptop, 59 tests are failing, many of which are complaining about the |
|
Looks like you need to bring in the changes to |
|
Ah wait, my bad -- it's because there isn't any logic to accept |
| if type(parser_or_filename) is FastxParser: | ||
| _parser = (<FastxParser>parser_or_filename)._this | ||
| elif type(parser_or_filename) is ReadParser: | ||
| _parser = # Unholy incantation |
There was a problem hiding this comment.
I tried several things but I can't figure out the right incantation to go here. If you have a few minutes tomorrow to pair program this tomorrow @camillescott that would be wonderful. Unless it's a trivial fix, in which case a comment here should be fine.
There was a problem hiding this comment.
_parser = (<CPyReadParser_Object>parser_or_filename).parser ought to do it, along with a from khmer._oxli.parsing cimport CPyReadParser_Object up top
There was a problem hiding this comment.
Thanks!
Now clang is choking on the Cythonized C++ code. It looks like cython is using C++17 features. 😒
...
...
...
khmer/_oxli/graphs.cpp:16623:9: warning: use of the 'fallthrough' attribute is a C++1z extension [-Wc++1z-extensions]
CYTHON_FALLTHROUGH;
^
khmer/_oxli/graphs.cpp:481:36: note: expanded from macro 'CYTHON_FALLTHROUGH'
#define CYTHON_FALLTHROUGH [[fallthrough]]
^
khmer/_oxli/graphs.cpp:16636:9: warning: use of the 'fallthrough' attribute is a C++1z extension [-Wc++1z-extensions]
CYTHON_FALLTHROUGH;
^
khmer/_oxli/graphs.cpp:481:36: note: expanded from macro 'CYTHON_FALLTHROUGH'
#define CYTHON_FALLTHROUGH [[fallthrough]]
^
168 warnings and 2 errors generated.
error: command 'clang' failed with exit status 1
make: *** [test] Error 1
There was a problem hiding this comment.
Never mind, I didn't see the trees for the forest. These warnings swamped the real issues.
...
...
...
khmer/_oxli/graphs.cpp:5723:43: error: member reference type 'PyObject *' (aka '_object *') is a pointer; did you mean to use '->'?
__pyx_t_5 = __pyx_v_parser_or_filename.parser;
~~~~~~~~~~~~~~~~~~~~~~~~~~^
->
khmer/_oxli/graphs.cpp:5723:44: error: no member named 'parser' in '_object'
__pyx_t_5 = __pyx_v_parser_or_filename.parser;
~~~~~~~~~~~~~~~~~~~~~~~~~~ ^
...
...
...
This was my experience last night. I couldn't figure out how to handle objects vs pointers etc.
There was a problem hiding this comment.
Just needed to add a * to _parser = (<CPyReadParser_Object>parser_or_filename).parser to make it _parser = (<CPyReadParser_Object*>parser_or_filename).parser. w00t!
| deref(self._hg_this).\ | ||
| consume_seqfile_and_tag_readparser[CpFastxReader](_parser, | ||
| total_reads, | ||
| n_consumed) |
There was a problem hiding this comment.
Quick pair programming session with @camillescott revealed I had failed to move these changes over from feature/cython_cleanup along with the others. This explained the latest set of failing tests.
|
This PR is ready for review and merge! @ctb @luizirber @betatim |
Codecov Report
@@ Coverage Diff @@
## master #1787 +/- ##
======================================
Coverage 0.05% 0.05%
======================================
Files 78 78
Lines 9757 9757
Branches 2457 2457
======================================
Hits 5 5
Misses 9752 9752
Continue to review full report at Codecov.
|
camillescott
left a comment
There was a problem hiding this comment.
I'm surprised that the with_reads_parser variants didn't get called more in the scripts... is sandbox covered? Will wait to merge until tomorrow.
| _parser = (<FastxParser>parser_or_filename)._this | ||
| elif isinstance(parser_or_filename, ReadParser): | ||
| _parser = (<CPyReadParser_Object*>parser_or_filename).parser | ||
| else: |
There was a problem hiding this comment.
I was thinking -- there's a function in utils called is_str, which just checks for, well, strness. It might be better to do another elif with that here, and then raise a TypeError on the else. Otherwise, any TypeError is going to be raised by _bstring, which will be confusing to the user.
Even though the hashtable "consume_seqfile" methods are overloaded at the C++ level, for the most part only the variants that allow filename input have been exposed to the Python layer. This PR uses type introspection to dynamically determine whether the input is a parser object or a string to be interpreted as a filename, and expose both functionalities to Python.
Kudos to @camillescott for demonstrating this approach in #1774. I'm splitting this out into a separate PR to simplify code review and to expedite progress.
make testDid it pass the tests?make clean diff-coverIf it introduces new functionality inscripts/is it tested?make format diff_pylint_report cppcheck doc pydocstyleIs it wellformatted?
additions are allowed without a major version increment. Changing file
formats also requires a major version number increment.
documented in
CHANGELOG.md? See keepachangelogfor more details.
changes were made?
tested for streaming IO?)