On Sunday, October 10, 2021 at 12:30:23 PM UTC-7 Matthias Koeppe wrote:
> On Sunday, September 26, 2021 at 10:44:14 AM UTC-7 Matthias Koeppe wrote:
>
>>
>> *2. Do not import CLASS just to run an isinstance(..., CLASS); likewise,
>> remove uses of is_CLASS functions*
>>
>> Instead, create abstract
On Sunday, September 26, 2021 at 10:44:14 AM UTC-7 Matthias Koeppe wrote:
>
> *2. Do not import CLASS just to run an isinstance(..., CLASS); likewise,
> remove uses of is_CLASS functions*
>
> Instead, create abstract base classes that can be imported without pulling
> in the actual implementatio
On Sunday, September 26, 2021 at 10:44:14 AM UTC-7 Matthias Koeppe wrote:
> *1. Replace use of "from sage.PAC.KAGE.all import ..." by more specific
> imports*
>
> This pattern in our Sage library code blocks modularization.
>
In https://trac.sagemath.org/ticket/32586 I would need help from expe
On Sunday, September 26, 2021 at 9:28:18 PM UTC-7 wst...@gmail.com wrote:
> With use of __init__.py the above would be "from sage.PAC.KAGE import
> ...".
>
Side remark: Native namespace packages (PEP 420) do not have __init__.py;
and this is the technical mechanism that the modularization plan
On Sunday, September 26, 2021 at 9:28:18 PM UTC-7 wst...@gmail.com wrote:
> The modularization of the Sage library could have lofty longterm
> goals, but start with one single package that is included
> in Sage, but is also a separate Python package and is even published
> to pypi and other pla
On Sunday, September 26, 2021 at 9:28:18 PM UTC-7 wst...@gmail.com wrote:
> On Sun, Sep 26, 2021 at 1:10 PM Nils Bruin wrote:
> > On Sunday, 26 September 2021 at 10:44:14 UTC-7 Matthias Koeppe wrote:
> >
> >> 3. Break up Cython modules that depend on several C/C++ libraries
> simultaneously
On Sun, Sep 26, 2021 at 1:10 PM Nils Bruin wrote:
>
> On Sunday, 26 September 2021 at 10:44:14 UTC-7 Matthias Koeppe wrote:
>>
>> 1. Replace use of "from sage.PAC.KAGE.all import ..." by more specific
>> imports
>
>
> I'm not sure whether I'm a fan of the "all" packages (for one thing, they
> ma
On Sunday, September 26, 2021 at 1:53:38 PM UTC-7 Nils Bruin wrote:
> On Sunday, 26 September 2021 at 13:32:28 UTC-7 Matthias Koeppe wrote:
>
>>
>> This does not describe our current practice or policy. All public names
>> in all Python modules are part of the API; when we move anything around, w
On Sunday, September 26, 2021 at 1:10:21 PM UTC-7 Nils Bruin wrote:
> On Sunday, 26 September 2021 at 10:44:14 UTC-7 Matthias Koeppe wrote:
>
>>
>> *3. Break up Cython modules that depend on several C/C++ libraries
>> simultaneously*
>>
>> An example is sage.matrix.misc, which depends on both fli
On Sunday, 26 September 2021 at 13:32:28 UTC-7 Matthias Koeppe wrote:
>
> This does not describe our current practice or policy. All public names in
> all Python modules are part of the API; when we move anything around, we
> use deprecation via lazy_import etc.
>
> I think deprecation only gets
On Sunday, September 26, 2021 at 1:10:21 PM UTC-7 Nils Bruin wrote:
> On Sunday, 26 September 2021 at 10:44:14 UTC-7 Matthias Koeppe wrote:
>
>> *1. Replace use of "from sage.PAC.KAGE.all import ..." by more specific
>> imports*
>>
>
> I'm not sure whether I'm a fan of the "all" packages (for one
On Sunday, September 26, 2021 at 1:10:21 PM UTC-7 Nils Bruin wrote:
> On Sunday, 26 September 2021 at 10:44:14 UTC-7 Matthias Koeppe wrote:
>
>> *2. Do not import CLASS just to run an isinstance(..., CLASS); likewise,
>> remove uses of is_CLASS functions*
>>
>
>> Instead, create abstract base cla
On Sunday, 26 September 2021 at 10:44:14 UTC-7 Matthias Koeppe wrote:
> *1. Replace use of "from sage.PAC.KAGE.all import ..." by more specific
> imports*
>
I'm not sure whether I'm a fan of the "all" packages (for one thing, they
make proper use of "lazy_import" a lot harder, but importing laz
13 matches
Mail list logo
