On Tue, Mar 14, 2017 at 9:44 PM, William Stein <wst...@gmail.com> wrote: > On Tue, Mar 14, 2017 at 12:38 PM, Luca De Feo > <de...@lix.polytechnique.fr> wrote: >> 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 ! > > I'm in favor of (1) and against (4). I would have named it __pari__ > in the first place if I thought that was better...
I don't have a strong feeling about it, but +0.5. I don't see anything wrong with _pari_, and keeping with a _<name>_ (call it "sunder" instead of "dunder") convention if it's already in use is the least work. >> On Thu, Mar 2, 2017 at 5:49 PM, Jeroen Demeyer <jdeme...@cage.ugent.be> >> 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 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. >>> >> >> -- >> 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. > > > > -- > William (http://wstein.org) > > -- > 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. -- 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.