Hi,

On Tue, Feb 28, 2017 at 04:41:39PM +0000, John Cremona wrote:
> On 28 February 2017 at 16:26, Jeroen Demeyer <[email protected]> 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 [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.

-- 
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.

Reply via email to