Thanks for these hints! I'm afraid that I still have to go with Jeroen's
solution, because I'd like to have different descriptions of the class,
only what's displayed as "Init docstring" should be kept.
It's actually strange that non-present docstrings of methods which are
overwritten are not
What did you want to know about it? I hadn’t heard of it before, but it’s just
a brew cask which means that it downloads the disk image from sagemath and
installs it. So it’s just a convenient way to install app version.
-Ivan
> On Nov 7, 2016, at 6:20 AM, Dima Pasechnik wrote:
>
> Does any
As a check of the build process, I did download a pristine copy and it
built with multiple jobs.
The copy that did not build cleanly is the one I've been updating all
summer from the GitHub master, which is certainly not pristine. I did run a
make dist-clean on it but that did not solve the pro
If nobody else than me cares about *working* on the transition to py3, this
is probably not going to happen anytime soon.
Frederic
Le lundi 7 novembre 2016 11:19:51 UTC+1, Erik Bray a écrit :
>
> On Thu, Oct 27, 2016 at 9:53 PM, Jeroen Demeyer > wrote:
> > Well, Python isn't exactly efficient
On Mon, Nov 7, 2016 at 4:04 PM, Travis Scrimshaw wrote:
>
>
> On Monday, November 7, 2016 at 7:26:57 AM UTC-6, Jeroen Demeyer wrote:
>>
>> On 2016-11-07 14:13, 'Martin R' via sage-devel wrote:
>> > I would like that these subclasses inherit the docstring of
>> > GrowthDiagram.__init__ (and a few o
On Monday, November 7, 2016 at 7:26:57 AM UTC-6, Jeroen Demeyer wrote:
>
> On 2016-11-07 14:13, 'Martin R' via sage-devel wrote:
> > I would like that these subclasses inherit the docstring of
> > GrowthDiagram.__init__ (and a few other methods), but I do not know how
> > to achieve this.
>
>
I've no idea, but searching for this tool took me to
https://github.com/caskroom/homebrew-cask/blob/master/Casks/sage.rb
looking at blame/log reveals some names …
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and
On 2016-11-07 14:13, 'Martin R' via sage-devel wrote:
I would like that these subclasses inherit the docstring of
GrowthDiagram.__init__ (and a few other methods), but I do not know how
to achieve this.
sage: class B(A):
: def __init__(self):
: pass
: __init__.__doc_
On 7 November 2016 at 14:19, Jeroen Demeyer wrote:
> On 2016-11-07 07:00, Nils Bruin wrote:
>>
>> Why not just make a subclass for the n==2, m==0 case and put the methods
>> there?
>
>
> +1
+1 this is cleaner *and* simpler (in the particular case you invoke)
--
You received this message because
Does anyone have an idea on http://macappstore.org/sage/ ?
This appears to be a homebrew-based installer of Sage on OSX...
Dima
--
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
On 2016-11-07 07:00, Nils Bruin wrote:
Why not just make a subclass for the n==2, m==0 case and put the methods
there?
+1
--
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
I have a possibly related question on documentation. At
https://trac.sagemath.org/ticket/21594 I have an class GrowthDiagram, which
is not intended for the end user. Instead, there are several subclasses
(GrowthDiagramRSK, GrowthDiagramBinWord, GrowthDiagramDomino, etc.), which,
however, all
On Wed, Oct 19, 2016 at 1:22 PM, Ximin Luo wrote:
> Jeroen Demeyer:
>> On 2016-10-18 17:52, Ximin Luo wrote:
>>> (2) In the long run, one can think about splitting out sage.rings.integers
>>> (and related things) into a small library "sage-types" or something like
>>> that. Then sagelib and fpyl
Your patches work for me (Ubuntu 16.10 64).
Thank you
Herbert
Am Samstag, 5. November 2016 18:21:13 UTC+1 schrieb Jörg-Volker:
>
> I compiled 7.4 on debian testing with the system gcc 6.2.0 using two
> additional patches for the packages flint and arb.
> Regards.
>
>>
>>
--
You received this m
On 2016-11-03 20:40, Paul Masson wrote:
OSError: [Errno 2] No such file or directory:
'/Users/Masson/Downloads/GitHub/sage/local/lib/python2.7/site-packages/backports_abc-0.4-py2.7.egg'
Error installing Cython
This looks very much like
https://trac.sagemath.org/ticket/21672
which should be fixe
On Thu, Nov 3, 2016 at 8:40 PM, Paul Masson wrote:
> The one package that stuck in my mind was Cython, and for some reason the
> error log for that one is not yet overwritten. Here's that error message:
>
> OSError: [Errno 2] No such file or directory:
> '/Users/Masson/Downloads/GitHub/sage/local/
VulK writes:
> The first question is about which is the correct way to implement methods
> that are not always defined.
I agree with Nils that subclassing is the most OOP-clean way of
achieving this. That being said, one might argue that it is a pretty
heavy-handed solution which potentially lead
On Thu, Oct 27, 2016 at 9:53 PM, Jeroen Demeyer wrote:
> Well, Python isn't exactly efficient when it comes to system calls...
Python 3 is much better. I look forward to Sage switching :)
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsub
18 matches
Mail list logo