Hello, Discussion on this matter seems to have stalled, with no clear consensus. There is an open ticket (#22470, only affecting _pari_) that we would like to close by the end of SD85.
Let me summarize the discussion. From what I've read, the only two options that seem to have gained some consensus are : (1) keep _pari_ (4) rename to __pari__, keep _pari_ with a deprecation for backwards compatibility Disregarding arguments that have been refuted, here's those in favour of (4): - It is consistent with standard Python conversions (__string__, etc.); - It has a precedent in Numpy (__array__). and heres those against (4): - It's bikeshedding, let's not waste developers' time with it (deprecations *do* have a cost); - It may clash with future Python special methods; - It has a precedent in IPython (_repr_latex_, etc.) No one seems to feel strongly for one of the other, but if I may try to count votes: - in favour of (4): Jeroen, Travis, me - against (4): Simon, Marc, David The 50/50 split seems to call for maintaining the status-quo, right? In this case we may close 22470 as wontfix by, say, the end of the week. So, if you care about (4), please speak out ! Thanks, Luca On Thu, Mar 2, 2017 at 5:49 PM, Jeroen Demeyer <[email protected]> wrote: > On 2017-03-02 14:19, Marc Mezzarobba wrote: >> >> Jeroen Demeyer wrote: >>> >>> (4) __pari__(): consistent with Python (__int__, __str__) and NumPy >>> (__array__). However, creating such names possibly goes against the >>> Python documentation [2]. >> >> >> Why "possibly"? The way I understand [2] is that __names__ are reserved >> for use by the Python interpreter and standard library, period. > > > As I have said before, NumPy have invented __array__ too. And I don't think > that the Python Naming Police came to hunt them down. > > What bothers me about [1] and [2] is that they do not say which names should > be used for custom special methods. > > [1] https://www.python.org/dev/peps/pep-0008/#descriptive-naming-styles > [2] > https://docs.python.org/3/reference/lexical_analysis.html#reserved-classes-of-identifiers > >> But if you want to do the same with all conversion >> methods, there could well be a conflict with some future standard python >> module. > > > *Any* name has the potential to clash with Python or with other packages. > And I don't think that __pari__ is much more likely to clash than any other > of the proposed names. > > > -- > 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 [email protected]. > To post to this group, send email to [email protected]. > Visit this group at https://groups.google.com/group/sage-devel. > For more options, visit https://groups.google.com/d/optout. > -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
