Ensuring PALP fails consistently without returning misleading data

[rashadalsharpini]

Description

it addresses issue #41400
where PALP fails and in the first call for n_points it fails (good)
second time it returns the number of vertices (wrong)

Changes

• delayed the assignment of self._points
• added try catch, to make behavior more consistent

tests

• passed all related tests
• recreated the test from addressed issue and it worked

[rashadalsharpini]

@fchapoton so what do you think does this fix it?

[orlitzky]

The design of this method is a little weird so I may be overlooking some complication, but I think it would be much simpler if we did the cache check at the beginning of the method, for example:

if self._points is not None:
    return self._points(*args, **kwds)

# rest of the function
M = self.lattice()
nv = self.n_vertices()
points = self._vertices
...
if len(points) > nv:
    points = PointCollection(points, M)
self._points = points
return self._points(*args, **kwds)

From what I understand PALP already raises an exception when it fails. So long as the premature self._points = self._vertices assignment is not made at the beginning of the function, we will not get the wrong answer on the second call.

[rashadalsharpini]

your approach is valid but i kind went this way to only cache on success so i completely avoid any garbage value that might happen, so if everything goes smoothly then i cache otherwise it's just empty

[orlitzky]

Sure, that is the goal. In my example, self._points only appears two places:

1. In the first two lines of the method; if a value is cached, we immediately return and exit.
2. In the last two lines of the function; to cache the value that we have just (successfully) computed.

When the class is initiated, self._points is None, so the only way for it to become not None is for the method to succeed. There are of course many ways to do it, but in my example the "is the value cached?" cases are handled immediately, whereas in the original code they span the entire length of the method -- at the very end you have to remember that you are exiting an "if" statement that started ~30 lines ago.

Putting that aside for the moment, why catch and re-raise the exception?

[rashadalsharpini]

I simplified the code structure

• lost the if not which as you mentioned you can easily forget it's existence
• Moved cache check to the beginning
• Removed redundant exception
  i think this does it
  @orlitzky @fchapoton so what do you think?

[orlitzky]

It looks like an extra space snuck in here between self. and poly_x.

[orlitzky]

here too

[orlitzky]

here too

[orlitzky]

Aside from three little typos it LGTM. Can you please add a doctest for the issue in #41400?

[rashadalsharpini]

i fixed typo i just got used smashing the space button :)
and i added the doctest for the issue @orlitzky

[dimpase]

@roed314 @saraedum - please trigger CI

[github-actions]

Documentation preview for this PR (built with commit c0906c3; changes) is ready! 🎉
This preview will update shortly after each push to this PR.