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

Embed Cython docstrings in generated files. #58

Merged

Conversation

vyasr
Copy link
Contributor

@vyasr vyasr commented Apr 7, 2022

This PR embeds signatures in Cython functions and classes so that they'll be accessible for normal Python help. While docstrings are currently present as expected, we still have to provide Cython with the appropriate directives to tell it that we want signatures.

@vyasr vyasr self-assigned this Apr 7, 2022
@vyasr vyasr added bug Something isn't working non-breaking Introduces a non-breaking change labels Apr 7, 2022
Copy link
Member

@madsbk madsbk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, thanks @vyasr

@@ -16,6 +16,10 @@ cmake_minimum_required(VERSION 3.20.1 FATAL_ERROR)

set(kvikio_version 22.06.00)

set(CYTHON_FLAGS
"--directive binding=True,embedsignature=True,always_allow_keywords=True"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are there other things we should handle this way like opting into Python 3 syntax, using C++, etc.?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • Using C++ is generally handled by Cython using file extensions, but with scikit-build CMake will take care of that so that isn't necessary.
  • We could opt into various optimizations like turning of bounds checking and wraparounds, but since we don't actually write much Cython code and it's just there for bindings I don't think it's necessary. We can always revisit if we ever start incorporating actual Cython code into performance-critical sections.
  • Opting into Python 3 syntax is definitely a possibility. I'd be open to specifying a language level here. Note that whenever we upgrade to Cython 3.0 (I think the main obstacle right now is getting try building 3.0.0 pre-releases conda-forge/cython-feedstock#75 through) the language level will automatically be set to 3, but no harm in doing it before. I don't know how big of a difference it makes given our limited Cython (Python files default to the language level of the interpreter, so those will already be 3), so let me know what you'd like me to do here.
  • We may want to add some CMake options to enable Cython profiling that would modify these flags, but that's probably something that can wait until someone has a use case?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Coming back to this comment, wondering if we should handle this as part of other needed updates to the build tooling here ( #186 )

Copy link
Contributor Author

@vyasr vyasr Mar 31, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • I'd still want to see the benefits of turning off bounds checking etc. Also in general IMO we'd be better off using Cython's decorator syntax to do this on a per-function basis rather than globally where it is more likely to unintentionally lead to bugs.
  • Same deal for the profiling flags, not much reason to add them unless someone is actually profiling Cython IMO.
  • We recently tried opting into language_level=3 and found some issues, which I suspect may be bugs in the Cython<3 implementation of it but haven't had time to confirm. We'll probably need to revisit, but at this point I would expect the language_level transition to happen as part of a broader RAPIDS switch to using Cython 3.

@madsbk
Copy link
Member

madsbk commented Apr 8, 2022

@gpucibot merge

@rapids-bot rapids-bot bot merged commit a0afdfa into rapidsai:branch-22.06 Apr 8, 2022
@vyasr vyasr deleted the fix/embed_cython_docstrings branch March 31, 2023 18:58
vuule pushed a commit to vuule/kvikio that referenced this pull request Nov 8, 2023
…n't exist (rapidsai#58)

Fixes: rapidsai/cudf#13860

This PR fixes an issue in Series.setitem where if the index is a RangeIndex, we are corrupting the series data & index object by not properly handling RangeIndex separately and not making a copy.

Co-authored-by: Bradley Dice <bdice@bradleydice.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working non-breaking Introduces a non-breaking change
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants