I don't see the benefits of changing as sufficient to outweigh the costs of an incompatible change, so I would vote for (1). Among the other options, (4) seems the most reasonable. David
On Tue, Feb 28, 2017 at 8:57 PM, Travis Scrimshaw <tsc...@ucdavis.edu> wrote: > > > On Tuesday, February 28, 2017 at 4:41:40 PM UTC-6, John H Palmieri wrote: >> >> >> >> On Tuesday, February 28, 2017 at 1:16:53 PM UTC-8, Jeroen Demeyer wrote: >>> >>> On 2017-02-28 20:46, Johan S. H. Rosenkilde wrote: >>> > In that case, it >>> > could be seen as an implementation detail that objects have the _pari >>> > method, and private would be apt. >>> >>> Yes, it's an "implementation detail" but it's not "private". >>> >>> I would say it's a public implementation detail: something that users >>> shouldn't need to know but something that package developers should know >>> and can rely on. A private name like "_pari" would imply that we can >>> remove/change it at will, which is not applicable in this case. >>> >>> I think this is exactly like Python's special methods such as __init__: >>> as a user, you would normally not call these but they are very important >>> when developing a class. >>> >> >> What about _latex_? Would you plan to change that, too? Sage objects and >> elements have lots of single-underscore methods, like _repr_, _mul_, etc. >> The use of _pari_ could be seen as in line with all of these, so I'm not >> sure why that choice has been rejected so quickly. >> >> > What I am seeing this as is a special conversion of the underlying type > that is essentially a system operation like __int__. So it makes a lot of > sense to me to have __pari__ as this is not a Sage special function. We > shouldn't touch _repr_, _mul_, etc. as these are Sage special functions > that are redirected to from the standard Python hooks, but we would > otherwise use __repr__, __mul__, etc. Thus, we arrive at Sage special > functions _latex_, _ascii_art_, etc., but I see that as using that > convention for functions that are specific to Sage. Thus, I would say (4), > but I could live with (1). > > Best, > Travis > > -- > 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.
