MAINT: refactor datetime.c_metadata creation #12437
Conversation
bc0ca1b to
0aec1d1
Compare
|
Would be good to finish this up - just needs a decision about the |
0aec1d1 to
743fca8
Compare
| } | ||
|
|
||
| /* | ||
| * Initializes the c_metadata field |
There was a problem hiding this comment.
This comment is no longer accurate, since it does not initialize any static objects, nor does it touch the c_metadata field.
| * Initializes the c_metadata field | ||
| */ | ||
| static NpyAuxData* | ||
| _get_builtin_datetime_metadata(void) |
There was a problem hiding this comment.
Optional: could change the signature to _create_datetime_metadata(base, num), and move the actual defaults to the call site
743fca8 to
f4fd8bd
Compare
|
Out of date comment again on line 4209, otherwise looks good |
f4fd8bd to
2552e57
Compare
|
Coverage report is nonsensical - the coverage markers don't match up with source lines in a way that makes sense. Any ideas, @tylerjereddy? |
|
@eric-wieser I think I see what you mean -- some of the markers are on terminating braces while conditional statements and blocks of code seem to get ignored for some reason. On the other hand, what can we reasonably expect codecov to do with a source file in a custom template language that looks a bit like C, but that it doesn't really know anything about? Ideally we'd be able to just track the generated .c files and ignore the .src files? I'm guessing that tracking generated (but not under source control) .c files is maybe not straightforward w/ codecov, but I could be wrong. Maybe ignoring the .src files is appropriate to reduce reviewer confusion / burden for the time being, with an issue open to make this better someday. I've not had much success with fine-tuning codecov settings--we know it isn't super well-behaved (Ralf will tell you this & it is completely hosed for SciPy now) but not many better options unless we i.e., run cov ourselves and have a script parse it & keep the html in artifact like we started doing for CircleCI docs. There are definitely some very nice coverage-analysis / html display tools out there, including Python libraries we could just pip install during CI. That would allow us to have really fine-grained control over things. I probably have a little too much fun working on devops stuff though, and the usual caveats about reinventing the wheel might apply I guess, but in this case the wheel is pretty bad to start with. |
What surprises me is that it seems to be so close to behaving correctly - on the order of 5-10 lines out of place. I think our generated code has some magic markers in it to tell gcc what the source line numbers are. Perhaps there's an off-by-one error in those? |
Refactor the creation of
datetime64.c_metadata. Spun off of PR #12430. Part of making dtype into aPyTypeObject