fix: limit number of particles using the eventinfo

[jhgoh]

read_lhe() tries to append to the list of particles in the event, raising error for some LHE output with optional fields. Another function read_lhe_with_attributes() is safe from this issue because it skips strings starting with '#'.
From the LHE standard, the number of particles is already given in the first line of the LHE event, which is also available in the eventinfo.nparticles, and any lines after nparticles should be treated as optional field.

Related issue: #102

[codecov]

Codecov Report

Merging #103 (df72add) into master (48f528e) will increase coverage by 4.47%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master     #103      +/-   ##
==========================================
+ Coverage   60.28%   64.76%   +4.47%     
==========================================
  Files           2        2              
  Lines         209      210       +1     
  Branches       56       56              
==========================================
+ Hits          126      136      +10     
+ Misses         73       65       -8     
+ Partials       10        9       -1     

Flag	Coverage Δ
unittests-3.10	63.33% <100.00%> (+4.48%)	⬆️
unittests-3.6	61.95% <100.00%> (+4.59%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
src/pylhe/__init__.py	71.09% <100.00%> (+5.40%)	⬆️

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

[matthewfeickert]

As @eduardo-rodrigues had pointed out in Issue #102, it would be good to cover this with tests. I understand that as this has gotten ignored for a long time that this might not be something @jhgoh has time to add now (totally understandable and reasonable given the delay), so if that's the case then once I'm through the next week or so I can come and add tests for all the PRs that are lacking them.

[eduardo-rodrigues]

Hi @matthewfeickert, I actually tested locally that this MR is all good with a file containing those lines starting with #aMCatNLO, as I found a file online for that. And since all tests present work, this MR is good to go. At this point in time a new release is really in need, and this MR is outstanding since long. I would kindly suggest that a new big release is made and more tests are added for robustness. I'm happy to add the file I'm mentioning to scikit-hep-testdata for a follow-up MR. WDYT?

[matthewfeickert]

I'm happy to add the file I'm mentioning to scikit-hep-testdata for a follow-up MR.

Yeah a PR that adds more test data to scikit-hep-testdata would be great.

[eduardo-rodrigues]

I'm happy to add the file I'm mentioning to scikit-hep-testdata for a follow-up MR.

Yeah a PR that adds more test data to scikit-hep-testdata would be great.

@matthewfeickert, I have added a test based on the file I added to scikit-hep-testdata. This is ready to be merged IMHO. Are you happy at this stage? [Test coverage is something to improve but unrelated to this MR.]

[eduardo-rodrigues]

Closes #102

[eduardo-rodrigues]

Hello @matthewfeickert, @lukasheinrich, @kratsg, I have added the requested test some time ago. Anything else or this can go in :-)?

[eduardo-rodrigues]

Done the homework @matthewfeickert. I would be happy with an approval at this stage so that I merge :-).

Closes #102.

[eduardo-rodrigues]

Morning @matthewfeickert, let's try and tick this off for the weekend. At this point is seems straightforward since I trivially dealt with your 2 remaining comments.

[eduardo-rodrigues]

Am now merging for the first time in this repo :-). I'm sure I ticked all to-dos from the review.