On Saturday, April 20, 2019 at 8:41:34 PM UTC+2, vdelecroix wrote:
>
> Shouldn't we implement that only as a IPython hook as well then?
>
The displayhook override is really just a hack since the plain python
output can't be changed, whereas Sage can generate nice output by default.
So IMHO no,
See https://trac.sagemath.org/ticket/27710 for a python3 fix to
combinat/tutorial.py
On Sunday, 21 April 2019 09:26:11 UTC+10, Andrew wrote:
>
> Fixing this problem properly as Martin or Volker suggests is probably the
> best option but `# random print order` is a good option too, which I was
On Saturday, April 20, 2019 at 4:26:11 PM UTC-7, Andrew wrote:
>
> Fixing this problem properly as Martin or Volker suggests is probably the
> best option but `# random print order` is a good option too, which I was
> not aware of -- or is this really `# random` with additional explanation?
>
I
Fixing this problem properly as Martin or Volker suggests is probably the
best option but `# random print order` is a good option too, which I was
not aware of -- or is this really `# random` with additional explanation?
Is there a complete list of the doc-test modifiers anywhere? I just looked
Le 20/04/2019 à 09:43, Volker Braun a écrit :
On Saturday, April 20, 2019 at 1:10:28 AM UTC+2, Andrew wrote:
Set(['a', 'b', 'c'])
gives different output with each sage session, at least when `sage` is
compiled with python3.
Ideally Set._repr_ would try to sort the set members (falling back
On Saturday, April 20, 2019 at 1:10:28 AM UTC+2, Andrew wrote:
>
> Set(['a', 'b', 'c'])
> gives different output with each sage session, at least when `sage` is
> compiled with python3.
>
Ideally Set._repr_ would try to sort the set members (falling back to
alphabetical order if the elements
Sorry: "Should we do this?" should be "Should I do this?"
Martin
Am Samstag, 20. April 2019 06:31:20 UTC+2 schrieb Martin R:
>
> In my opinion, `Set` should not be used in library code. It is slow,
> unnecessary, and can hide subtle bugs when the underlying object is not
> hashable.
In my opinion, `Set` should not be used in library code. It is slow,
unnecessary, and can hide subtle bugs when the underlying object is not
hashable. (https://trac.sagemath.org/ticket/23324)
For the concrete issue at hand, the use of `Set` could be easily removed in
all methods except
On Friday, April 19, 2019 at 5:25:13 PM UTC-7, John H Palmieri wrote:
>
> What does
>
> sage: C
> Set partitions of {'a', 'c', 'b'}
>
>
> reveal? Is it helpful, or can it be omitted?
>
> Adding to that: perhaps it reveals something for the documentation reader.
But in that case the output doesn't
What does
sage: C
Set partitions of {'a', 'c', 'b'}
reveal? Is it helpful, or can it be omitted? Maybe it's good enough to do
sage: C = SetPartitions(["a", "b", "c"])
sage: C.cardinality()
5
sage: sorted(C)
[{{'a'}, {'b'}, {'c'}},
{{'a'}, {'b', 'c'}},
{{'a', 'b'}, {'c'}},
{{'a', 'b', 'c'}},
What the accepted best practice for fixing the failing python3 doc-tests?
For example, in `combinat/tutorial.py` I can fix one of the failing
doc-tests with:
sage: C = SetPartitions(["a", "b", "c"])
sage: C #py2
Set partitions of {'a', 'c', 'b'}
sage: C #py3
Set partitions
11 matches
Mail list logo
