On 2017-03-01 18:27, Nils Bruin wrote:
you might want to look for precedents of implementations that use that naming conventions for protocols that are only supported by add-on libraries
NumPy is an example: it specifies a special method .__array__(). So at least we would be in good company with .__pari__().
In fact, using something other than "_pari_" could be advantageous: you can tweak the API of pyri until you hit 1.0
I don't need to change any API. I want to split of src/sage/libs/cypari2 as a separate package called CyPari2, without changing any API.
It does seem to me that your desire to choose a different name
I don't have a particular desire to *change* the name. I want to decide on the best name to use. And I don't want to keep the name just because that is the status-quo.
And of course, I will think of backwards-compatibility. -- 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+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
