Re: [sage-devel] Names of special methods like _pari_
On 2017-02-28 17:26, Jeroen Demeyer wrote: > (4) __pari__(): consistent with Python (__int__, __str__) and NumPy > (__array__). However, creating such names possibly goes against the > Python documentation [2]. If we change it, then +1 for option (4). Daniel -- 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.
Re: [sage-devel] Names of special methods like _pari_
On 2017-03-01 03:43, David Roe wrote: I don't see the benefits of changing as sufficient to outweigh the costs of an incompatible change We could always keep supporting _pari_ with deprecation, so the cost of changing is zero. -- 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.
Re: [sage-devel] Names of special methods like _pari_
What about _latex_? Would you plan to change that, too? Sage objects and elements have lots of single-underscore methods, like _repr_, _mul_, etc. Well, I would put _latex_ in the same basket as _pari_. But _repr_ and _mul_ are different: they deal with the implementation of SageObject/Element so this is *not* about those methods. I'm not convinced, because you'll potentially break code people have written that is not included in the Sage library. For that reason, I'm -1 to changing _pari_ in a backwards incompatible way. We could always keep supporting _pari_ with deprecation, so that's not really an issue. -- 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.
Re: [sage-devel] Names of special methods like _pari_
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 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.
Re: [sage-devel] Names of special methods like _pari_
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.
Re: [sage-devel] Names of special methods like _pari_
On Tue, Feb 28, 2017 at 2:41 PM, 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. The subject of this thread is "Names of special methods like _pari_", so I suspect Jeroen wants to change *everything*. Jeroen says: > It's just a simple search-and-replace-all, so essentially no work. I'm not convinced, because you'll potentially break code people have written that is not included in the Sage library. For that reason, I'm -1 to changing _pari_ in a backwards incompatible way. -- William > > -- > John > > -- > 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.
Re: [sage-devel] Names of special methods like _pari_
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. -- John -- 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.
Re: [sage-devel] Names of special methods like _pari_
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. -- 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.
Re: [sage-devel] Names of special methods like _pari_
> > (2) _pari(): meant for private methods. This doesn't seem correct to me, > because we want this method to be part of the public API. But as Thierry says, perhaps not so public that we want it to figure in tab-completion on all objects everywhere. Isn't this exactly because most users would use this "convert to PARI" method through other, more publicly visible services? In that case, it could be seen as an implementation detail that objects have the _pari method, and private would be apt. I think I vote for this, though my only objection to (4) is that it possibly goes against the Python doc. Best, Johan -- 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.
Re: [sage-devel] Names of special methods like _pari_
Hi, On Tue, Feb 28, 2017 at 04:41:39PM +, John Cremona wrote: > On 28 February 2017 at 16:26, Jeroen Demeyer wrote: > > This is a continuation of discussion from > > https://trac.sagemath.org/ticket/22470 > > > > I will only talk about _pari_ below but this is just an example. We also > > have _gap_ and others. > > > > Sage supports the special method _pari_() to convert arbitrary objects to > > PARI. Now I would like to ask the question whether _pari_() is really the > > best name. Especially if we want Sage to fit better in a larger Python > > ecosystem, it makes sense to think about this. > > > > > > We essentially have 5 options: > > Must the name be just 'pari' with some number of underscores? As this > is an explicit conversion, something like (6) to_pari() would seem OK > to me. I am -1 for (5) and (6) since it will pollute autocompletion on every Sage object. Ciao, Thierry > > > > > (1) _pari_(): the status-quo. This seems to be very Sage-specific, I don't > > know if this naming convention is used anywhere else. > > > > (2) _pari(): meant for private methods. This doesn't seem correct to me, > > because we want this method to be part of the public API. > > > > (3) __pari(): even more private with mangling, so even less suitable. > > > > (4) __pari__(): consistent with Python (__int__, __str__) and NumPy > > (__array__). However, creating such names possibly goes against the Python > > documentation [2]. > > > > (5) pari(): very simple but it doesn't make it clear that it has a special > > meaning. Higher chance of false positives with people using a pari() method > > for something else. > > > > > > My personal choice would be (4). Since this seems to be a controversial > > topic, I decided to write this sage-devel post. > > > > > > There is some discussion about naming in these two references: > > [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 neither seems to answer what is the right thing to do for our use case. > > > > > > Jeroen. > > > > -- > > 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. -- 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.
Re: [sage-devel] Names of special methods like _pari_
On 28 February 2017 at 16:26, Jeroen Demeyer wrote: > This is a continuation of discussion from > https://trac.sagemath.org/ticket/22470 > > I will only talk about _pari_ below but this is just an example. We also > have _gap_ and others. > > Sage supports the special method _pari_() to convert arbitrary objects to > PARI. Now I would like to ask the question whether _pari_() is really the > best name. Especially if we want Sage to fit better in a larger Python > ecosystem, it makes sense to think about this. > > > We essentially have 5 options: Must the name be just 'pari' with some number of underscores? As this is an explicit conversion, something like (6) to_pari() would seem OK to me. > > (1) _pari_(): the status-quo. This seems to be very Sage-specific, I don't > know if this naming convention is used anywhere else. > > (2) _pari(): meant for private methods. This doesn't seem correct to me, > because we want this method to be part of the public API. > > (3) __pari(): even more private with mangling, so even less suitable. > > (4) __pari__(): consistent with Python (__int__, __str__) and NumPy > (__array__). However, creating such names possibly goes against the Python > documentation [2]. > > (5) pari(): very simple but it doesn't make it clear that it has a special > meaning. Higher chance of false positives with people using a pari() method > for something else. > > > My personal choice would be (4). Since this seems to be a controversial > topic, I decided to write this sage-devel post. > > > There is some discussion about naming in these two references: > [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 neither seems to answer what is the right thing to do for our use case. > > > Jeroen. > > -- > 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.
[sage-devel] Names of special methods like _pari_
This is a continuation of discussion from https://trac.sagemath.org/ticket/22470 I will only talk about _pari_ below but this is just an example. We also have _gap_ and others. Sage supports the special method _pari_() to convert arbitrary objects to PARI. Now I would like to ask the question whether _pari_() is really the best name. Especially if we want Sage to fit better in a larger Python ecosystem, it makes sense to think about this. We essentially have 5 options: (1) _pari_(): the status-quo. This seems to be very Sage-specific, I don't know if this naming convention is used anywhere else. (2) _pari(): meant for private methods. This doesn't seem correct to me, because we want this method to be part of the public API. (3) __pari(): even more private with mangling, so even less suitable. (4) __pari__(): consistent with Python (__int__, __str__) and NumPy (__array__). However, creating such names possibly goes against the Python documentation [2]. (5) pari(): very simple but it doesn't make it clear that it has a special meaning. Higher chance of false positives with people using a pari() method for something else. My personal choice would be (4). Since this seems to be a controversial topic, I decided to write this sage-devel post. There is some discussion about naming in these two references: [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 neither seems to answer what is the right thing to do for our use case. Jeroen. -- 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.
