On Fri, Feb 14, 2020 at 7:05 AM Dima Pasechnik wrote:
>
>
> On Fri, 14 Feb 2020, 04:45 varenyam bakshi, wrote:
>
>> I followed all the procedure written in the sage installation guide.
>> Should i install gtk also
>>
>
> yes it look like this.
>
> We should fix our docs to mention gtk.
>
erm, t
An official bikeshed thread!
We have a number of grouped factory methods to construct familiar
objects. Some of them use CamelCase for their method names:
sage: graphs.
sage: manifolds.
sage: valuations.
Some use underscores for their method names:
sage: polytopes.
Some can't make up t
To my mind, it does not hurt to have these `factory.X` as CamelCase
or snake_case. The reason is that the factory should be thought
of as a Python module (which contains both objects and functions). I
agree that it would be nice to uniformize that a bit (and update the
developer guide once we have
Dear Sage developers,
This is a reminder for the Jupyter session at the International
Congress for Mathematical Software (Braunchweig, Germany, July 13-16).
If you would like to give a short talk there to present cool use cases
and demonstrations in research and education, or maybe feedbac
Dear all,
This used to work
sage: "{:5}".format(pi)
---
TypeError Traceback (most recent call last)
in ()
> 1 "{:5}".format(pi)
TypeError: unsupported format string passed to
sage.symbo
On Friday, February 14, 2020 at 11:01:05 PM UTC+9, Michael Orlitzky wrote:
>
> Should it apply to *methods* that also act like constructors, even
> though visually, something like cones.Foo() doesn't look like a
> constructor (it looks like a method)?
I would think
cones
On 2/14/20 4:53 PM, Kwankyu Lee wrote:
>
> +1 to cones.trivial()
>
> reason: there is no Trivial class or factory.
>
I guess this comes down to how strict your definition of a factory
method is. Traditionally, the factory pattern meant that you would ask
for an object with certain properties a
