Trivial changes in pari interface from 9.3 to 9.4 break compatibility

[Nils Bruin]

I noticed that in pari.qfminim; from 9.3 to 9.4 there was a trivial change: the second parameter changed name from 'b' to 'B'. This breaks code that calls it with 'b' as a keyword. I had trouble tracing this change, but it looks like this is in some automatically generated interface.

It's generally not a good idea to break compatibility with such trivial changes. Is this indeed stemming from pari?  In that case how does pari get away with it? Do they only have positional arguments? Or do they have a different place where they save their allowed names/aliases for keywords?

If this really is a peculiarity of pari that we have to live with, we should perhaps document to not depend on keyword arguments [which, when I checked, people haven't really done for the 'b' parameter, but are doing for the 'flags' parameter].

[Justin C. Walker]

I’m not sure this is relevant to your issue, but FWIW, I tried in recent versions of Pari, and noticed two things:
- “?qfminim" documents the use of ‘b’ as the second argument, while "??qfminim" documents the use of ‘B’.
- using the forms “b=“ and “B=“ in the calls with a second argument makes no difference in the outcome (same values).

HTH

Justin

> --
> You received this message because you are subscribed to the Google Groups "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/9a9b098a-55f3-4675-968b-3caf77fa607bn%40googlegroups.com.

--
Justin C. Walker, Curmudgeon at Large
Director
Institute for the Enhancement of the Director's income
-----------
--
They said it couldn't be done, but sometimes,
it doesn't work out that way.
- Casey Stengel
--

[Nils Bruin]

On Monday, 20 September 2021 at 12:58:10 UTC-7 jus...@mac.com wrote:

I’m not sure this is relevant to your issue, but FWIW, I tried in recent versions of Pari, and noticed two things:
- “?qfminim" documents the use of ‘b’ as the second argument, while "??qfminim" documents the use of ‘B’.

Hm, I see a capital B in both the text from ?qfminim in GP and in the PS document from ??qfminim in GP.

 

- using the forms “b=“ and “B=“ in the calls with a second argument makes no difference in the outcome (same values).

I agree: it looks like GP treats keyword-arguments in a case-insensitive way. Python, on the other hand, does not. We could just force them to be lower case in the python interface all the time, to be shielded from the arbitrary (irrelevant) documented case use in GP.

 

[Vincent Delecroix]

As far as cypari2 is concerned, qfminim is auto-generated from
the data pari provides (the pari.desc file, gp help, etc).

Forcing lower case in all situations is a huge backward incompatible
change. I see many D, G, V which are commonly used as upper case
letters in math for discriminant, group and vector space.

We could add a sophisticated argument parser in cpyari2 but it is a lot
of trouble and time penalty at execution.

The only reasonable move that I see is to discuss with pari devs.

[Nils Bruin]

On Tuesday, 21 September 2021 at 15:08:44 UTC-7 vdelecroix wrote:

We could add a sophisticated argument parser in cpyari2 but it is a lot
of trouble and time penalty at execution.

The only reasonable move that I see is to discuss with pari devs.

Yes, I don't think we're willing to incur any runtime penalties. It may be worth reporting to the pari devs that they should maintain case if at all possible.