On Thu, May 13, 2021 at 1:34 AM 'Travis Scrimshaw' via sage-devel
<sage-devel@googlegroups.com> wrote:
>
> Own tag might be a goood way forward as the code itself can run on Python 3.7 
> by avoiding the multiprocessing. It would be purely to state that we don't 
> want to test the mp parts of the code. How do I make an optional tag? I am 
> worried that since this is not simply an optional package to test but against 
> a Python version, it would require a slightly invasive change to the 
> doctesting framework.

I always thought that it's trivial:

       sage: bar()  # optional:foo

would stop bar() being tested, unless "--optional=...,foo,..."
is given to ./sage -t

Am I wrong?

Dima



> There also is an option of testing for a more specific import from Python too.
>
> Best,
> Travis
>
> On Wednesday, May 12, 2021 at 7:10:53 AM UTC+10 Volker Braun wrote:
>>
>> Yet another possibility is to look for a backport that implements sufficient 
>> functionality for your needs for now.
>>
>> On Tuesday, May 11, 2021 at 2:40:04 AM UTC+2 Matthias Koeppe wrote:
>>>
>>> -1. Even NEP 29 (https://numpy.org/neps/nep-0029-deprecation_policy.html) 
>>> does not drop Python 3.7 support before end of the year.
>>>
>>>
>>> On Monday, May 10, 2021 at 4:12:48 PM UTC-7 Travis Scrimshaw wrote:
>>>>
>>>> On #30423, which is getting close to completion, we will be using 
>>>> multiprocessing.shared_memory, which is only available on Python 3.8+. 
>>>> However, right now we are at least allowing Python 3.7 (as per the 
>>>> patchbot). So my main proposal would be to bump the minimum required 
>>>> Python version to 3.8, which was released Oct. 14, 2019.
>>>>
>>>> On that ticket, we can make it so that the main entry point runs things in 
>>>> serial if the Python version is sufficiently small and that the doc 
>>>> builds, but the doctests for the parallel code will fail. So the first 
>>>> alternative option would be to mark certain doctests (or the file) as 
>>>> needing a large Python version.
>>>>
>>>> A second alternative is that this can be split off as a separate package 
>>>> (either an optional Sage package or pip installable). Yet, it is somewhat 
>>>> tightly coupled with the FusionRing code (and root systems) in Sage, so 
>>>> this is not so desirable. A less invasive way would be to just split the 
>>>> parallel part off, but this would take some work to do I think.
>>>>
>>>> What do people think?
>>>>
>>>> Best,
>>>> Travis
>>>>
> --
> 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 sage-devel+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/sage-devel/ae100fbf-8b77-4c9c-b92a-cde41e6d17f8n%40googlegroups.com.

-- 
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 sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/CAAWYfq1z28PNZeR%3Dn5n4cNX4crBqYcNEnV9EvThH_Oa-cSiaeA%40mail.gmail.com.

Reply via email to