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

Use PyO3 functionality to remove Python files #302

Merged
merged 52 commits into from
Aug 15, 2024
Merged

Conversation

Radonirinaunimi
Copy link
Member

@Radonirinaunimi Radonirinaunimi commented Aug 6, 2024

Towards addressing #200.

TODO:

@Radonirinaunimi Radonirinaunimi added enhancement New feature or request python python extention labels Aug 6, 2024
@Radonirinaunimi Radonirinaunimi marked this pull request as draft August 6, 2024 07:19
@felixhekhorn felixhekhorn mentioned this pull request Aug 6, 2024
@cschwan
Copy link
Contributor

cschwan commented Aug 7, 2024

Thank you for taking care of this, @Radonirinaunimi! Whenever you need help, let me know!

@felixhekhorn
Copy link
Contributor

Thank you for taking care of this, @Radonirinaunimi! Whenever you need help, let me know!

same here!

@Radonirinaunimi Radonirinaunimi marked this pull request as ready for review August 7, 2024 15:19
@Radonirinaunimi
Copy link
Member Author

Radonirinaunimi commented Aug 7, 2024

Although:

  • renaming instances of *lumi* into *channel* to be consistent with main crate (in crates, functions, variables, etc.) done through Update Python docs #301
  • fixing and/or adding some documentations done through Update Python docs #301
  • doing more tests to make sure that all the corner cases did not break without us knowing
  • improving handling of exceptions and errors currently not strictly required as (all) python PyErr have From conversion to match rust Err.

are still to be done, this is mostly ready (in that it passes all the tests) so I think you can already have a look.

There are only a few things that are not exactly the same as before (and that we may or may not want to address):

  • the methods .create() and .from_grid() are no longer available, instead objects are instantiated from the class
  • .into() needs to be manually called on subgrids in order to convert into SubgridEnum

PS: I could not force-push so please ignore the commit history 😇

pineappl_py/src/bin.rs Show resolved Hide resolved
pineappl_py/src/grid.rs Outdated Show resolved Hide resolved
pineappl_py/src/grid.rs Show resolved Hide resolved
pineappl_py/src/grid.rs Outdated Show resolved Hide resolved
@cschwan
Copy link
Contributor

cschwan commented Aug 8, 2024

There are only a few things that are not exactly the same as before (and that we may or may not want to address):

* the methods `.create()` and `.from_grid()` are no longer available, instead objects are instantiated from the class

* `.into()` needs to be manually called on subgrids in order to convert into `SubgridEnum`

That's perfectly fine, and quite happy that we can get away with so few changes actually.

PS: I could not force-push so please ignore the commit history 😇

I've disabled force-push for the time being since I'm not convinced about it being a good idea.

@felixhekhorn
Copy link
Contributor

  • the methods .create() and .from_grid() are no longer available, instead objects are instantiated from the class

I think this is acceptable - but makes this a breaking change.

  • .into() needs to be manually called on subgrids in order to convert into SubgridEnum

this is quite "rusty" and not "pythonic", if we can't find a way around we can keep it to honour our underlying language - but if possible I'd like to avoid. Can we do something with the Into trait? i.e. implement that for the subgrids (i.e. move the function to an impl block) and then take the trait as argument of PyGrid::set_subgrid? (No idea if PyO3 will like it)

@Radonirinaunimi
Copy link
Member Author

this is quite "rusty" and not "pythonic", if we can't find a way around we can keep it to honour our underlying language - but if possible I'd like to avoid. Can we do something with the Into trait? i.e. implement that for the subgrids (i.e. move the function to an impl block) and then take the trait as argument of PyGrid::set_subgrid? (No idea if PyO3 will like it)

I've had a look at this a bit and not only it could become really complicated but also messy. What would be the reasons we should avoid the current approach (apart from breaking changes)? It is basically a difference between doing:

set_subgrid(order, bin, lumi, subgrid.into())

vs before when it was re-wrapped inside:

def set_subgrid(self, order, bin_, lumi, subgrid):
"""Set the subgrid at the given position.
Convenience wrapper for :meth:`pineappl.pineappl.PyGrid.set_subgrid()`.
Parameters
----------
order : int
index of order
bin_ : int
index of bin
lumi : int
index of luminosity
subgrid : ImportOnlySubgridV1
subgrid content
"""
self.raw.set_subgrid(order, bin_, lumi, subgrid.into())

@cschwan
Copy link
Contributor

cschwan commented Aug 9, 2024

set_subgrid(order, bin, lumi, subgrid.into())

Where do we use Grid::set_subgrid? This will need to changed, since soon (#299) all the subgrid types will be changed/removed.

@felixhekhorn
Copy link
Contributor

Where do we use Grid::set_subgrid? This will need to changed, since soon (#299) all the subgrid types will be changed/removed.

yadism does - since we do the interpolation ourselves

What would be the reasons we should avoid the current approach

as said above the only reason is being "rusty" and not "pythonic" - if it is too much of a hassle it is also fine ... (as Python knows no (strong) types, it also doesn't know casting so it feels a bit weird, that's it)

@Radonirinaunimi
Copy link
Member Author

as said above the only reason is being "rusty" and not "pythonic" - if it is too much of a hassle it is also fine ... (as Python knows no (strong) types, it also doesn't know casting so it feels a bit weird, that's it)

Ok, let's keep it as it is then.

I think this is basically done. The remaining todos re docs and change of macros were already addressed by #301. The only maybe we'd add is a pre-commit hooks to format the python tests (and that also runs cargo fmt)(?).

pineappl_py/README.md Outdated Show resolved Hide resolved
cschwan and others added 2 commits August 14, 2024 17:25
Co-authored-by: Alessandro Candido <candido.ale@gmail.com>
@Radonirinaunimi
Copy link
Member Author

Are we happy to merge this now? We can add pre-commit hooks to automatically run black and cargo fmt before commit in another PR.

@cschwan
Copy link
Contributor

cschwan commented Aug 15, 2024

Are we happy to merge this now?

I found some minor things, let me fix them first.

@Radonirinaunimi
Copy link
Member Author

@cschwan What was actually the reason of renaming/moving channel into boc?

@cschwan
Copy link
Contributor

cschwan commented Aug 15, 2024

@cschwan What was actually the reason of renaming/moving channel into boc?

That just reflects the same module structure in Rust. I think we should keep the two as close as possible.

@Radonirinaunimi
Copy link
Member Author

That just reflects the same module structure in Rust. I think we should keep the two as close as possible.

Yes, this I understood and I completely agree. But what was the reason to change it in the main Rust module (for my own curiosity).

@cschwan
Copy link
Contributor

cschwan commented Aug 15, 2024

But what was the reason to change it in the main Rust module (for my own curiosity).

Grid is basically, as you know, a three-dimensional array over bins, orders and channels, and I wanted to have a single module to reflect these three dimensions. It's not perfect yet, as there's still the bin module and the ordering isn't boc but obc, but I'd expect that to change in the future.

@Radonirinaunimi
Copy link
Member Author

Grid is basically, as you know, a three-dimensional array over bins, orders and channels, and I wanted to have a single module to reflect these three dimensions. It's not perfect yet, as there's still the bin module and the ordering isn't boc but obc, but I'd expect that to change in the future.

I see, thanks!

@cschwan
Copy link
Contributor

cschwan commented Aug 15, 2024

@Radonirinaunimi can you please check that commit 8ef2297 doesn't do anything unexpected? Contrary to what I wrote it isn't a bug, in the new commit it should just be more succinct. If it's OK, you can merge!

CHANGELOG.md Outdated Show resolved Hide resolved
@Radonirinaunimi
Copy link
Member Author

Radonirinaunimi commented Aug 15, 2024

@Radonirinaunimi can you please check that commit 8ef2297 doesn't do anything unexpected? Contrary to what I wrote it isn't a bug, in the new commit it should just be more succinct. If it's OK, you can merge!

I checked and this does not change anything, so we are good.

Co-authored-by: Felix Hekhorn <felixhekhorn@users.noreply.github.com>
@Radonirinaunimi Radonirinaunimi merged commit 453aff6 into master Aug 15, 2024
9 checks passed
@Radonirinaunimi Radonirinaunimi deleted the remove_pymodules branch August 15, 2024 09:22
@felixhekhorn felixhekhorn mentioned this pull request Oct 28, 2024
37 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request python python extention
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants