-
Notifications
You must be signed in to change notification settings - Fork 4.4k
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
drop type specs in RecoTracker/{DeDx,FinalTrackSelectors} #30556
Conversation
The code-checks are being triggered in jenkins. |
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-30556/16792
|
A new Pull Request was created by @jeongeun (JeongEun Lee) for master. It involves the following packages: RecoTracker/DeDx @perrotta, @cmsbuild, @slava77 can you please review it and eventually sign? Thanks. cms-bot commands are listed here |
please test |
The tests are being triggered in jenkins.
|
+1 |
Comparison job queued. |
Comparison is ready Comparison Summary:
|
+1
|
This pull request is fully signed and it will be integrated in one of the next master IBs (tests are also fine). This pull request will now be reviewed by the release team before it's merged. @silviodonato, @dpiparo (and backports should be raised in the release meeting by the corresponding L2) |
+1 |
setsToMerge = cms.VPSet( cms.PSet( tLists=cms.vint32(1), pQual=cms.bool(True) ) | ||
), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
setsToMerge = cms.VPSet( cms.PSet( tLists=cms.vint32(1), pQual=cms.bool(True) ) | |
), | |
setsToMerge = [ cms.PSet( tLists=cms.vint32(1), pQual=cms.bool(True) ) | |
], |
this still works.
I'd think that a nameless tuple like could still work for PSet, like [ ( tLists=cms.vint32(1), pQual=cms.bool(True) ]
, but this is apparently not supported.
@makortel do you think it would be practical to add?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think ( tLists=cms.vint32(1), pQual=cms.bool(True) )
would be legal syntax
>>> (foo=2)
File "<stdin>", line 1
(foo=2)
^
SyntaxError: invalid syntax
So using a keyword argument would require dict(foo=2)
, which is already used for modifying an existing PSet.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
dict does not really apply here because full contents of setsToMerge
are replaced (we are not modifying just one of the elements of this array.
Just to reiterate, my question was, if we have support for VInputTag to be initialized from [ "a", b", ("c", "d") ]
, can we also get a VPSet to be initialized without listing the element type?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
With VInputTag
a compact (maybe event too compact) is possible because the meaning of each element of the sequence of strings is known by its position in the sequence. In PSet
the element keys are the parameter names, so dict
would be a natural "shortcut". But we already use dict
for something else, and I'd think anything along ("tlists", cms.vint32(1), "pQual", cms.bool(True))
would be (much) less clear than just using the cms.PSet
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sorry, I meant
instead of
cms.VPSet( cms.PSet( tLists=cms.vint32(1), pQual=cms.bool(True) ) )
to be able to say
[ ( tLists=cms.vint32(1), pQual=cms.bool(True) ) ]
this is not serving the full goal of "drop type specs", but it would at least allow to insert elements to a container of a known type (vector of cms.PSet) without need to explicitly specify the type of the element (cms.PSet)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
how about [ { 'tLists' : cms.vint32(1), 'pQual' : cms.bool(True) } ]
?
it would be a valid syntax, but it comes out with raise TypeError("wrong type being extended to container "+self._labelIfAny())
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The { 'tLists' : cms.vint32(1), 'pQual' : cms.bool(True) }
is a dictionary equivalent to dict(tLists = cms.vint32(1), pQual = cms.bool(True))
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, syntactically , this dict(
may be more transparent.
I guess from the above the point is that dict
doesn't do the right thing here (yet?).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, syntactically , this
dict(
may be more transparent.
I guess from the above the point is thatdict
doesn't do the right thing here (yet?).
OTOH, the difference to type cms.PSet
vs dict(
is rather minor; IIRC this is also the only vector type that needs this. So, we may just live with it for now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, syntactically , this
dict(
may be more transparent.
I guess from the above the point is thatdict
doesn't do the right thing here (yet?).
We already use dict()
to modify an existing PSet. I think using it to denote new PSet in one context would be confusing.
PR description: Update the safer syntax for existing parameter
Instead of modifying parameters with full type specs, which can be interpreted as an insertion of a new parameter, it is a safer way to protect from parameter name mistakes and will also help in possible parameter migrations.
(The references were PR#29979, PR#30147, PR#30270 , PR#30271, PR#30353)
In this PR, 9 files updated.
PR validation:
Event Content comparison check was also done and there is no change with these updates.
Tested in CMSSW_11_2_X, the basic test all passed in the CMSSW PR instructions.