Sage: Ticket #24261: py3: add py2 and py3 doctest flags
https://trac.sagemath.org/ticket/24261
<p>
This adds two new flags that can be placed next to doctests: <code># py2</code> and <code># py3</code>. If marked <code>py2</code> a test will <em>only</em> be run on Python 2 and so on.
</p>
<p>
Generally this should be avoided in favor of making a test work on both in some way or another, but there are some cases where it simply doesn't make sense. For example this test in <code>sage.doctest.control</code>
</p>
<pre class="wiki"> 640 sage: DD = DocTestDefaults(sagenb = True)
641 sage: DC = DocTestController(DD, [])
642 sage: DC.add_files() # py2
643 Doctesting the Sage notebook.
644 sage: DC.files[0][-6:] # py2
645 'sagenb'
</pre><p>
This doesn't work on Python 3 since we don't even install the Sage notebook on Python 3 (at least not currently).
</p>
<p>
The relevant code being tested there should also be updated to handle Python 3 better, but even so there's no practical way to make the test make sense on Python 3 until/unless sagenb is supported on Python 3. I suspect other cases like this may come up on occasion so it's useful to have.
</p>
en-usSagehttps://trac.sagemath.org/chrome/site/logo_sagemath_trac.png
https://trac.sagemath.org/ticket/24261
Trac 1.1.6embrayTue, 21 Nov 2017 14:09:47 GMTstatus changed
https://trac.sagemath.org/ticket/24261#comment:1
https://trac.sagemath.org/ticket/24261#comment:1
<ul>
<li><strong>status</strong>
changed from <em>new</em> to <em>needs_review</em>
</li>
</ul>
TicketjdemeyerTue, 21 Nov 2017 15:59:53 GMT
https://trac.sagemath.org/ticket/24261#comment:2
https://trac.sagemath.org/ticket/24261#comment:2
<p>
Why not <code># optional - python2</code> or <code># optional - python3</code>? That's reusing an existing system for optional tests.
</p>
TicketchapotonTue, 21 Nov 2017 16:02:38 GMT
https://trac.sagemath.org/ticket/24261#comment:3
https://trac.sagemath.org/ticket/24261#comment:3
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/24261#comment:2" title="Comment 2">jdemeyer</a>:
</p>
<blockquote class="citation">
<p>
Why not <code># optional - python2</code> or <code># optional - python3</code>? That's reusing an existing system for optional tests.
</p>
</blockquote>
<p>
and there are already existing instances waiting for that
</p>
TicketembrayTue, 21 Nov 2017 17:07:29 GMT
https://trac.sagemath.org/ticket/24261#comment:4
https://trac.sagemath.org/ticket/24261#comment:4
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/24261#comment:2" title="Comment 2">jdemeyer</a>:
</p>
<blockquote class="citation">
<p>
Why not <code># optional - python2</code> or <code># optional - python3</code>? That's reusing an existing system for optional tests.
</p>
</blockquote>
<p>
I considered something like that but it seems to have different semantics. Currently "optional - pkgname" implies that a package is installed/available. Here we don't care if python2/3 is available. We care about what Python version is currently running the tests.
</p>
<p>
Rather than making a special case it's simpler and clearer I think to just have specific tags for this (there's also prior precedence such as using <code># py3</code> in coverage to mark lines that should be ignored in the coverage analysis).
</p>
TickettscrimWed, 22 Nov 2017 04:44:55 GMT
https://trac.sagemath.org/ticket/24261#comment:5
https://trac.sagemath.org/ticket/24261#comment:5
<p>
I think it would be better to have <code># py2</code> and <code># py3</code> behave like the <code># 32-bit</code> and <code># 64-bit</code> and be specific for the output. I guess there is also the question of how many of our doctest inputs are going to be specific for Python2. Do any of you have an impression? I think it might be marginal at worst, in which case, we can just build into the doctests an explicit check of Python2 vs 3 as part of the doctest itself.
</p>
TicketembrayWed, 22 Nov 2017 13:11:51 GMT
https://trac.sagemath.org/ticket/24261#comment:6
https://trac.sagemath.org/ticket/24261#comment:6
<p>
I wouldn't mind changing it to apply to the output but not skip the test. That would actually be better since if the behavior on Python 3 changes in these cases (e.g. <code>sagenb</code> works, to use my previous example) then we'd want to see that reflected in the test results.
</p>
<p>
I think a stronger possibility is <em>Python 3</em> only inputs, such as doing things with annotations and other Python 3 only syntax. So maybe having these tags work on both output and input would be good?
</p>
TickettscrimWed, 22 Nov 2017 22:01:55 GMT
https://trac.sagemath.org/ticket/24261#comment:7
https://trac.sagemath.org/ticket/24261#comment:7
<p>
I would not oppose that, but I don't think we do anything like that elsewhere. So it might require some invasive changes and might cause some slight confusion (but that is debatable). I think we would be better off having a separate marker for Python3 input.
</p>
TicketembrayThu, 23 Nov 2017 09:53:17 GMT
https://trac.sagemath.org/ticket/24261#comment:8
https://trac.sagemath.org/ticket/24261#comment:8
<p>
Adding tags on output lines would not require invasive changes, but I do think it's slightly more confusing. Whereas the use of comments on input lines is consistent with Python syntax, sticking comments in output lines is a bit ad-hoc and confusing. But we also already have precedence for that in the "32-bit/64-bit" case as you pointed out.
</p>
TicketembrayFri, 01 Dec 2017 11:12:18 GMTstatus changed
https://trac.sagemath.org/ticket/24261#comment:9
https://trac.sagemath.org/ticket/24261#comment:9
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>needs_work</em>
</li>
</ul>
<p>
I just realized there's a bug in how this is implemented, where tests containing these tags are skipped regardless.
</p>
TicketembrayFri, 01 Dec 2017 11:16:29 GMT
https://trac.sagemath.org/ticket/24261#comment:10
https://trac.sagemath.org/ticket/24261#comment:10
<p>
Implementation bug aside, I've been working on fixing the sageinspect module, and that's increasingly convinced me that having a concise way to run specific test cases on either Python 2 or Python 3 only is useful, especially in that module.
</p>
TicketgitFri, 01 Dec 2017 13:57:48 GMTcommit changed
https://trac.sagemath.org/ticket/24261#comment:11
https://trac.sagemath.org/ticket/24261#comment:11
<ul>
<li><strong>commit</strong>
changed from <em>6f5fd8cfb06c4b7c7f9743e2559eca00c06f3a0f</em> to <em>e01e5531b69e5a65642651efab85cf5bb496c8ee</em>
</li>
</ul>
<p>
Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:
</p>
<table class="wiki">
<tr><td><a class="ext-link" href="https://git.sagemath.org/sage.git/commit/?id=e01e5531b69e5a65642651efab85cf5bb496c8ee"><span class="icon"></span>e01e553</a></td><td><code>Add doctest flags for running tests on Python 2 only or Python 3 only.</code>
</td></tr></table>
TicketembrayFri, 01 Dec 2017 13:58:52 GMTstatus changed
https://trac.sagemath.org/ticket/24261#comment:12
https://trac.sagemath.org/ticket/24261#comment:12
<ul>
<li><strong>status</strong>
changed from <em>needs_work</em> to <em>needs_review</em>
</li>
</ul>
<p>
Okay, this definitely works now. My fixes to the sageinspect module (and in particular its tests) rely on this pretty heavily.
</p>
TicketgitFri, 01 Dec 2017 14:08:55 GMTcommit changed
https://trac.sagemath.org/ticket/24261#comment:13
https://trac.sagemath.org/ticket/24261#comment:13
<ul>
<li><strong>commit</strong>
changed from <em>e01e5531b69e5a65642651efab85cf5bb496c8ee</em> to <em>31f2008835ab51a4a1fdbe8b14b7ef175494be01</em>
</li>
</ul>
<p>
Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:
</p>
<table class="wiki">
<tr><td><a class="ext-link" href="https://git.sagemath.org/sage.git/commit/?id=31f2008835ab51a4a1fdbe8b14b7ef175494be01"><span class="icon"></span>31f2008</a></td><td><code>Add doctest flags for running tests on Python 2 only or Python 3 only.</code>
</td></tr></table>
TicketjdemeyerMon, 04 Dec 2017 13:20:11 GMT
https://trac.sagemath.org/ticket/24261#comment:14
https://trac.sagemath.org/ticket/24261#comment:14
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/24261#comment:4" title="Comment 4">embray</a>:
</p>
<blockquote class="citation">
<p>
I considered something like that but it seems to have different semantics. Currently "optional - pkgname" implies that a package is installed/available. Here we don't care if python2/3 is available. We care about what Python version is currently running the tests.
</p>
</blockquote>
<p>
Right, I get that. Still, I think that we already have enough (if not too many) special doctest markers. And even if <code># optional</code> is typically used to check whether a package is installed, I think that the meaning of <code># optional - python2</code> is clear enough.
</p>
<p>
Moreover, there are already doctests using <code># optional - python2</code> and <code># optional - python3</code> referring to the current running version of Python.
</p>
TicketembrayMon, 04 Dec 2017 13:27:43 GMT
https://trac.sagemath.org/ticket/24261#comment:15
https://trac.sagemath.org/ticket/24261#comment:15
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/24261#comment:14" title="Comment 14">jdemeyer</a>:
</p>
<blockquote class="citation">
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/24261#comment:4" title="Comment 4">embray</a>:
</p>
<blockquote class="citation">
<p>
I considered something like that but it seems to have different semantics. Currently "optional - pkgname" implies that a package is installed/available. Here we don't care if python2/3 is available. We care about what Python version is currently running the tests.
</p>
</blockquote>
<p>
Right, I get that. Still, I think that we already have enough (if not too many) special
</p>
</blockquote>
<p>
That's pretty subjective--I think "enough" is however many you need to write reasonable tests.
</p>
<blockquote class="citation">
<p>
doctest markers. And even if <code># optional</code> is typically used to check whether a package is installed, I think that the meaning of <code># optional - python2</code> is clear enough.
</p>
</blockquote>
<p>
I don't. It's overly wordy and not quite clear at all given the double meaning.
</p>
<blockquote class="citation">
<p>
Moreover, there are already doctests using <code># optional - python2</code> and <code># optional - python3</code> referring to the current running version of Python.
</p>
</blockquote>
<p>
Except those explicitly don't work right now. I've already replaced a few examples using these markers. Here's a concrete example that might help motivate:
</p>
<pre class="wiki"> sage: import ast, sage.misc.sageinspect as sms # py3
sage: visitor = sms.SageArgSpecVisitor() # py3
sage: vis = lambda x: visitor.visit_NameConstant(ast.parse(x).body[0].value) # py3
sage: [vis(n) for n in ['True', 'False', 'None']] # py3
[True, False, None]
sage: [type(vis(n)) for n in ['True', 'False', 'None']] # py3
[<type 'bool'>, <type 'bool'>, <type 'NoneType'>]
</pre><p>
This entire sequence of test commands is Python 3 only and does not even make sense on Python 2 (it might be nice to tag a whole range at once actually rather than every single line but that's a separate issue). Putting "# optional - python3" on every one of those lines is just that much more line noise.
</p>
TicketjdemeyerThu, 07 Dec 2017 17:29:03 GMTstatus changed
https://trac.sagemath.org/ticket/24261#comment:16
https://trac.sagemath.org/ticket/24261#comment:16
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>needs_work</em>
</li>
</ul>
<p>
OK, fine. I don't really agree, but we have to move on. If you want to go forward with <code># py2</code> and <code># py3</code>, you should at least fix the existing uses of <code># optional - python2</code> and <code># optional - python3</code>. If you do that, I'm willing to set this ticket to positive review.
</p>
TicketembrayFri, 08 Dec 2017 09:11:59 GMT
https://trac.sagemath.org/ticket/24261#comment:17
https://trac.sagemath.org/ticket/24261#comment:17
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/24261#comment:16" title="Comment 16">jdemeyer</a>:
</p>
<blockquote class="citation">
<p>
OK, fine. I don't really agree, but we have to move on. If you want to go forward with <code># py2</code> and <code># py3</code>, you should at least fix the existing uses of <code># optional - python2</code> and <code># optional - python3</code>. If you do that, I'm willing to set this ticket to positive review.
</p>
</blockquote>
<p>
I'm fixing those as I come to them, but fixing all of them at once would probably only hang this up longer. Better to add the feature first and then switch to using it where it makes sense to on a case by case basis.
</p>
TicketjdemeyerFri, 08 Dec 2017 09:39:15 GMT
https://trac.sagemath.org/ticket/24261#comment:18
https://trac.sagemath.org/ticket/24261#comment:18
<p>
Come on, there are really few instances of <code># optional - python[23]</code> currently in Sage. It doesn't take much effort to fix those. And those can also double as testcase that the <code># py2</code> and <code># py3</code> markers actually work.
</p>
TicketembrayFri, 08 Dec 2017 10:45:41 GMT
https://trac.sagemath.org/ticket/24261#comment:19
https://trac.sagemath.org/ticket/24261#comment:19
<p>
Alright, I have no problem doing it (I'll have to double-check but I think I've already fixed most of those cases). It just seemed antithetical to your normal philosophy (which I generally agree with...)
</p>
TicketgitFri, 08 Dec 2017 11:03:53 GMTcommit changed
https://trac.sagemath.org/ticket/24261#comment:20
https://trac.sagemath.org/ticket/24261#comment:20
<ul>
<li><strong>commit</strong>
changed from <em>31f2008835ab51a4a1fdbe8b14b7ef175494be01</em> to <em>c09007614f985868bd2a43c0f8e282aeb8de17b7</em>
</li>
</ul>
<p>
Branch pushed to git repo; I updated commit sha1. New commits:
</p>
<table class="wiki">
<tr><td><a class="ext-link" href="https://git.sagemath.org/sage.git/commit/?id=c09007614f985868bd2a43c0f8e282aeb8de17b7"><span class="icon"></span>c090076</a></td><td><code>Fix a few more cases where '# optional - python2' wasn't really doing what was intended.</code>
</td></tr></table>
TicketembrayFri, 08 Dec 2017 11:04:25 GMTstatus changed
https://trac.sagemath.org/ticket/24261#comment:21
https://trac.sagemath.org/ticket/24261#comment:21
<ul>
<li><strong>status</strong>
changed from <em>needs_work</em> to <em>needs_review</em>
</li>
</ul>
<p>
Note: I also fixed one case of <code># optional - python2</code> in <a class="closed ticket" href="https://trac.sagemath.org/ticket/24286" title="defect: py3: minor fixes to sage.repl.load and sage.repl.attach (closed: fixed)">#24286</a>.
</p>
TicketchapotonThu, 14 Dec 2017 15:45:42 GMT
https://trac.sagemath.org/ticket/24261#comment:22
https://trac.sagemath.org/ticket/24261#comment:22
<p>
typo : "on optionl features" in src/doc/en/developer/coding_basics.rst
</p>
<p>
one failing doctest in src/sage/doctest/sources.py
</p>
TicketchapotonThu, 14 Dec 2017 15:45:50 GMTstatus changed
https://trac.sagemath.org/ticket/24261#comment:23
https://trac.sagemath.org/ticket/24261#comment:23
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>needs_work</em>
</li>
</ul>
TicketembrayFri, 15 Dec 2017 11:23:09 GMT
https://trac.sagemath.org/ticket/24261#comment:24
https://trac.sagemath.org/ticket/24261#comment:24
<p>
Can somebody explain the origin of this test?
</p>
<pre class="wiki">sage -t --long src/sage/doctest/sources.py
**********************************************************************
File "src/sage/doctest/sources.py", line 759, in sage.doctest.sources.FileDocTestSource._test_enough_doctests
Failed example:
for path, dirs, files in itertools.chain(os.walk('sage'), os.walk('doc')): # long time
path = os.path.relpath(path)
dirs.sort(); files.sort()
for F in files:
_, ext = os.path.splitext(F)
if ext in ('.py', '.pyx', '.pxd', '.pxi', '.sage', '.spyx', '.rst'):
filename = os.path.join(path, F)
FDS = FileDocTestSource(filename, DocTestDefaults(long=True,optional=True))
FDS._test_enough_doctests(verbose=False)
Expected:
There are 7 tests in sage/combinat/diagram_algebras.py that are not being run
There are 7 tests in sage/combinat/dyck_word.py that are not being run
There are 7 tests in sage/combinat/finite_state_machine.py that are not being run
There are 6 tests in sage/combinat/interval_posets.py that are not being run
There are 18 tests in sage/combinat/partition.py that are not being run
There are 15 tests in sage/combinat/permutation.py that are not being run
There are 14 tests in sage/combinat/skew_partition.py that are not being run
There are 18 tests in sage/combinat/tableau.py that are not being run
There are 8 tests in sage/combinat/crystals/tensor_product.py that are not being run
There are 11 tests in sage/combinat/rigged_configurations/rigged_configurations.py that are not being run
There are 15 tests in sage/combinat/root_system/cartan_type.py that are not being run
There are 8 tests in sage/combinat/root_system/type_A.py that are not being run
There are 8 tests in sage/combinat/root_system/type_G.py that are not being run
There are 3 unexpected tests being run in sage/doctest/parsing.py
There are 1 unexpected tests being run in sage/doctest/reporting.py
There are 15 tests in sage/manifolds/manifold.py that are not being run
There are 3 tests in sage/rings/invariant_theory.py that are not being run
Got:
There are 7 tests in sage/combinat/diagram_algebras.py that are not being run
There are 7 tests in sage/combinat/dyck_word.py that are not being run
There are 7 tests in sage/combinat/finite_state_machine.py that are not being run
There are 6 tests in sage/combinat/interval_posets.py that are not being run
There are 18 tests in sage/combinat/partition.py that are not being run
There are 15 tests in sage/combinat/permutation.py that are not being run
There are 14 tests in sage/combinat/skew_partition.py that are not being run
There are 18 tests in sage/combinat/tableau.py that are not being run
There are 8 tests in sage/combinat/crystals/tensor_product.py that are not being run
There are 11 tests in sage/combinat/rigged_configurations/rigged_configurations.py that are not being run
There are 15 tests in sage/combinat/root_system/cartan_type.py that are not being run
There are 8 tests in sage/combinat/root_system/type_A.py that are not being run
There are 8 tests in sage/combinat/root_system/type_G.py that are not being run
There are 3 unexpected tests being run in sage/doctest/parsing.py
There are 1 unexpected tests being run in sage/doctest/reporting.py
There are 15 tests in sage/manifolds/manifold.py that are not being run
There are 1 tests in sage/misc/sage_eval.py that are not being run
There are 3 tests in sage/rings/invariant_theory.py that are not being run
There are 1 tests in sage/rings/finite_rings/integer_mod.pyx that are not being run
**********************************************************************
1 item had failures:
1 of 9 in sage.doctest.sources.FileDocTestSource._test_enough_doctests
[367 tests, 1 failure, 244.00 s]
</pre><p>
It's pretty awfully annoying to have a test whose output depends on the contents of a variety of specific modules. If this is meant to be some kind of regression test (?) it's not clear, but surely it could be run without such a strong dependency on external data.
</p>
TicketembrayFri, 15 Dec 2017 11:46:40 GMT
https://trac.sagemath.org/ticket/24261#comment:25
https://trac.sagemath.org/ticket/24261#comment:25
<p>
I really don't understand what to do with this test. It's like it's testing the doctest parser by using a different, simpler doctest parser that doesn't fully work, and comparing the results from that parser to the results from the actual doctest parser. If we want to check that the actual doctest parser works then there should be (and are) unit tests for the code of the actual doctest parser. As it is this test is just testing the secondary, flakier doctest parser implemented in the test...
</p>
TicketgitFri, 15 Dec 2017 11:48:28 GMTcommit changed
https://trac.sagemath.org/ticket/24261#comment:26
https://trac.sagemath.org/ticket/24261#comment:26
<ul>
<li><strong>commit</strong>
changed from <em>c09007614f985868bd2a43c0f8e282aeb8de17b7</em> to <em>96127ebd7f23c774b4c5c6619962f8dcb8bc2ae5</em>
</li>
</ul>
<p>
Branch pushed to git repo; I updated commit sha1. New commits:
</p>
<table class="wiki">
<tr><td><a class="ext-link" href="https://git.sagemath.org/sage.git/commit/?id=96127ebd7f23c774b4c5c6619962f8dcb8bc2ae5"><span class="icon"></span>96127eb</a></td><td><code>Fix typo</code>
</td></tr></table>
TicketembrayMon, 18 Dec 2017 16:36:11 GMTstatus changed
https://trac.sagemath.org/ticket/24261#comment:27
https://trac.sagemath.org/ticket/24261#comment:27
<ul>
<li><strong>status</strong>
changed from <em>needs_work</em> to <em>needs_info</em>
</li>
</ul>
TicketjdemeyerTue, 19 Dec 2017 12:27:32 GMT
https://trac.sagemath.org/ticket/24261#comment:28
https://trac.sagemath.org/ticket/24261#comment:28
<p>
To solve your problem with <code>_test_enough_doctests</code>, you could add some extra attribute to <code>SageDocTestParser</code> to never skip any test (not even the <code># py2</code> and <code># py3</code> tests). Then you set that attribute when running <code>_test_enough_doctests</code>.
</p>
TicketembrayTue, 02 Jan 2018 15:27:04 GMT
https://trac.sagemath.org/ticket/24261#comment:29
https://trac.sagemath.org/ticket/24261#comment:29
<p>
I'd still just as soon remove that test...
</p>
TicketjdemeyerFri, 05 Jan 2018 10:18:05 GMTbranch changed
https://trac.sagemath.org/ticket/24261#comment:30
https://trac.sagemath.org/ticket/24261#comment:30
<ul>
<li><strong>branch</strong>
changed from <em>u/embray/python3/doctest-py2-only</em> to <em>u/jdemeyer/python3/doctest-py2-only</em>
</li>
</ul>
TicketjdemeyerFri, 05 Jan 2018 10:19:00 GMTstatus, commit, author changed
https://trac.sagemath.org/ticket/24261#comment:31
https://trac.sagemath.org/ticket/24261#comment:31
<ul>
<li><strong>status</strong>
changed from <em>needs_info</em> to <em>needs_review</em>
</li>
<li><strong>commit</strong>
changed from <em>96127ebd7f23c774b4c5c6619962f8dcb8bc2ae5</em> to <em>12c300aad31ee72ea569134b35a94baed7efa470</em>
</li>
<li><strong>author</strong>
changed from <em>Erik Bray</em> to <em>Erik Bray, Jeroen Demeyer</em>
</li>
</ul>
<p>
This variant re-uses the existing optional tags implementation. It passes all tests in <code>sage/doctest</code>.
</p>
<hr />
<p>
New commits:
</p>
<table class="wiki">
<tr><td><a class="ext-link" href="https://git.sagemath.org/sage.git/commit?id=39c71a222dddc426e23ac733c96c0bdb90a8d18b"><span class="icon"></span>39c71a2</a></td><td><code>Add doctest flags for running tests on Python 2 only or Python 3 only.</code>
</td></tr><tr><td><a class="ext-link" href="https://git.sagemath.org/sage.git/commit?id=1fcea7e739d5be87349d1fb11581cdfecf980af3"><span class="icon"></span>1fcea7e</a></td><td><code>Better fix for this doctest</code>
</td></tr><tr><td><a class="ext-link" href="https://git.sagemath.org/sage.git/commit?id=12c300aad31ee72ea569134b35a94baed7efa470"><span class="icon"></span>12c300a</a></td><td><code>Automatically add py2/py3 optional tag</code>
</td></tr></table>
TicketembrayFri, 05 Jan 2018 12:08:50 GMT
https://trac.sagemath.org/ticket/24261#comment:32
https://trac.sagemath.org/ticket/24261#comment:32
<p>
I don't fully understand what this is doing differently, but I'm not opposed as long as it works.
</p>
TicketjdemeyerFri, 05 Jan 2018 12:47:09 GMT
https://trac.sagemath.org/ticket/24261#comment:33
https://trac.sagemath.org/ticket/24261#comment:33
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/24261#comment:32" title="Comment 32">embray</a>:
</p>
<blockquote class="citation">
<p>
I'm not opposed
</p>
</blockquote>
<p>
Is that a subtle way to say "positive review"?
</p>
TicketchapotonSat, 06 Jan 2018 19:21:59 GMT
https://trac.sagemath.org/ticket/24261#comment:34
https://trac.sagemath.org/ticket/24261#comment:34
<p>
This seems to be ready to go, no ?
</p>
TicketchapotonMon, 08 Jan 2018 16:42:30 GMTstatus changed; reviewer set
https://trac.sagemath.org/ticket/24261#comment:35
https://trac.sagemath.org/ticket/24261#comment:35
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>positive_review</em>
</li>
<li><strong>reviewer</strong>
set to <em>Frédéric Chapoton, Erik Bray, Jeroen Demeyer</em>
</li>
</ul>
<p>
ok, let it be. Erik and Jeroen, I added your names as reviewers. Feel free to undo that.
</p>
TicketembrayTue, 09 Jan 2018 13:34:47 GMT
https://trac.sagemath.org/ticket/24261#comment:36
https://trac.sagemath.org/ticket/24261#comment:36
<p>
Yes, I understand how this is working now. +1
</p>
TicketvbraunSun, 14 Jan 2018 10:14:36 GMTstatus, branch changed; resolution set
https://trac.sagemath.org/ticket/24261#comment:37
https://trac.sagemath.org/ticket/24261#comment:37
<ul>
<li><strong>status</strong>
changed from <em>positive_review</em> to <em>closed</em>
</li>
<li><strong>resolution</strong>
set to <em>fixed</em>
</li>
<li><strong>branch</strong>
changed from <em>u/jdemeyer/python3/doctest-py2-only</em> to <em>12c300aad31ee72ea569134b35a94baed7efa470</em>
</li>
</ul>
TicketchapotonFri, 19 Jan 2018 15:16:25 GMTcommit deleted
https://trac.sagemath.org/ticket/24261#comment:38
https://trac.sagemath.org/ticket/24261#comment:38
<ul>
<li><strong>commit</strong>
<em>12c300aad31ee72ea569134b35a94baed7efa470</em> deleted
</li>
</ul>
<p>
follow-up in <a class="closed ticket" href="https://trac.sagemath.org/ticket/24570" title="enhancement: py3: using the new tags py3 and py2 in some rst files (closed: fixed)">#24570</a>
</p>
Ticket