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.

Sign up for GitHub

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

Jump to bottom

[muon] a workaround for enum to int conversion problem in pyROOT #26446

Closed
wants to merge 1 commit into from
Closed

[muon] a workaround for enum to int conversion problem in pyROOT #26446

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
6 changes: 4 additions & 2 deletions DataFormats/PatCandidates/interface/Muon.h
View file
Open in desktop
Expand Up @@ -281,8 +281,10 @@ namespace pat {
void setSoftMvaValue(float softmva){ softMvaValue_ = softmva; }

/// MC matching information
reco::MuonSimType simType() const { return simType_; }
reco::ExtendedMuonSimType simExtType() const { return simExtType_; }
/// returns reco::MuonSimType - we cast it to int to avoid issues in pyROOT
int simType() const { return simType_; }
/// reco::ExtendedMuonSimType - we cast it to int to avoid issues in pyROOT
int simExtType() const { return simExtType_; }
Copy link
Contributor

Choose a reason for hiding this comment

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

This solution degrades type safety to serve a broken external use case.

I propose to introduce/add simTypeInt and simExtTypeInt with appropriate comments that it's to be used in FWLite environment where the scoped enums are not properly recognized.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I don't think your solution will work well because the user needs to know that he has to use simTypeInt to be safe. I have personally rediscovered this problem 3 times, i.e. one tends to forget about it and use it as is. All these accessors are primarily used by endusers, i.e. there won't be many use cases where someone would really benefit from type safety. In other words the tradeoff is between a benefit that won't be used vs a real problem that affects a number of users.

// FLAVOUR:
// - for non-muons: 0
// - for primary muons: 13
Expand Down