# Public Numba Dev Meeting, Tuesday October 13 2020

**URL:** <https://numba.discourse.group/t/public-numba-dev-meeting-tuesday-october-13-2020/253>\
**Category:** Announcements\
**Created:** [October 9, 2020, 3:22pm UTC](https://numba.discourse.group/t/public-numba-dev-meeting-tuesday-october-13-2020/253 "2020-10-09T15:22:03Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![sklam](https://yyz2.discourse-cdn.com/free1/user_avatar/numba.discourse.group/sklam/32/9_2.png) [@sklam](https://numba.discourse.group/u/sklam)\
**Post date:** [October 9, 2020, 3:22pm UTC](https://numba.discourse.group/t/public-numba-dev-meeting-tuesday-october-13-2020/253/1 "2020-10-09T15:22:03Z")

</div>

Hi all,

The upcoming Public Numba Dev meeting is on Oct 13th at 10:30 US central time. You can find instructions on how to join in the event details on this [google calender](https://calendar.google.com/calendar/embed?src=5rqnddm4gjrdfjm31fsv182epk%40group.calendar.google.com). (Tips: adding it to your own calendar will convert the time to your timezone.)

Here’s are some topics that we can have:

1. Type annotations discussions
2. Numba devs demoing new diagnostic tool; i.e. enhanced inspect\_cfg ([https://github.com/numba/numba/pull/6295](https://github.com/numba/numba/pull/6295))
3. \< your suggestions \>

Feel free to discuss which topic(s) to talk about, or indeed suggest new ones in the thread, topic selection will be based on popularity.

Hope to see you there!

---

<div class="post-metadata">

**Author:** ![sklam](https://yyz2.discourse-cdn.com/free1/user_avatar/numba.discourse.group/sklam/32/9_2.png) [@sklam](https://numba.discourse.group/u/sklam)\
**Post date:** [October 9, 2020, 5:11pm UTC](https://numba.discourse.group/t/public-numba-dev-meeting-tuesday-october-13-2020/253/2 "2020-10-09T17:11:49Z")

</div>

Adding context to the “Type Annotation discussion”, the Numba devs continue to have some concerns about the idea of adding type annotations everywhere, and we are probably not as familiar with type annotations as some of our community members. So, I am inviting community members to help answer our questions and concerns about type annotations; especially:

- Type annotations can affect readability… long lines because of complex types.
- How to annotate NumPy arrays? Related to discussion in [https://github.com/numba/numba/pull/5609#pullrequestreview-492006847](https://github.com/numba/numba/pull/5609#pullrequestreview-492006847).
- Can we redirect the effort to annotate llvmlite first? Static type checks may have more immediate benefits in llvmlite.

---

<div class="post-metadata">

**Author:** ![EPronovost](https://yyz2.discourse-cdn.com/free1/user_avatar/numba.discourse.group/epronovost/32/63_2.png) [@EPronovost](https://numba.discourse.group/u/EPronovost)\
**Post date:** [October 10, 2020, 4:45am UTC](https://numba.discourse.group/t/public-numba-dev-meeting-tuesday-october-13-2020/253/3 "2020-10-10T04:45:45Z")

</div>

Regarding readability, I at least personally find that [black](https://black.readthedocs.io/en/stable/) behaves much better than flake8 for formatting with type annotations. I think the [black source code](https://github.com/psf/black/blob/master/src/black_primer/lib.py) is a good example. For an example from numba, these two function definitions pass flake8

```auto
class DictType(IterableType, InitialValue):
    def __init__ (self, keyty: NumbaTypeInst, valty: NumbaTypeInst,
                 initial_value: pt.Optional[pt.Dict[pt.Any, pt.Any]] = None):

```

and

```auto
class DictType(IterableType, InitialValue):
    def __init__ (
        self, keyty: NumbaTypeInst, valty: NumbaTypeInst,
            initial_value: pt.Optional[pt.Dict[pt.Any, pt.Any]] = None):

```

where as black would format it as

```auto
class DictType(IterableType, InitialValue):
    def __init__ (
        self,
        keyty: NumbaTypeInst,
        valty: NumbaTypeInst,
        initial_value: pt.Optional[pt.Dict[pt.Any, pt.Any]] = None,
    ):

```

Readability is in the eye of the beholder, but from my perspective code like [this](https://github.com/numba/numba/blob/master/numba/core/typing/context.py#L578-L588) is fairly unreadable. Besides the easy formatting things (e.g. multiple arguments per row in a multi-row definition), I have no idea what the arguments should be. If that definition looked more like the black + type annotations example above, it would be a lot clearer to me what’s going on.

---

<div class="post-metadata">

**Author:** ![luk-f-a](https://yyz2.discourse-cdn.com/free1/user_avatar/numba.discourse.group/luk-f-a/32/56_2.png) [@luk-f-a](https://numba.discourse.group/u/luk-f-a)\
**Post date:** [October 12, 2020, 9:25am UTC](https://numba.discourse.group/t/public-numba-dev-meeting-tuesday-october-13-2020/253/4 "2020-10-12T09:25:54Z")

</div>

I am not a huge fan of Black for every line, but I also use the one-arg-per-line style when I have complex annotations that don’t fit in one line. I would definitely choose

```python
class DictType(IterableType, InitialValue):
    def __init__ (
        self,
        keyty: NumbaTypeInst,
        valty: NumbaTypeInst,
        initial_value: pt.Optional[pt.Dict[pt.Any, pt.Any]] = None,
    ):

```

over the other alternatives.

Another way to improve readability is to use more type aliases, like `MaybeDict = pt.Optional[pt.Dict[pt.Any, pt.Any]]`, when the same type is being used in many places. IDEs will allow you to jump to the definition in one click, so it’s not a big deal.

Regarding numpy arrays, it’s think it’s an open topic for mypy and numpy themselves, so I see no option but to wait for them.

Regarding directing the effort towards llvmlite, I wonder if the effort can be re-directed. I don’t think I would be able to type llvmlite, so my efforts are limited to Numba. But it’s true that core devs effort in reviewing PRs could be re-directed, and therefore subject to choosing what has higher priority.

I would like to point out an important aspect of annotations, that goes beyond the static checking, namely the formalization of internal APIs. Look at this code

> <https://github.com/numba/numba/blob/95fa2bef8ea2ca08e32bb8846e59fda5e060f1c8/numba/core/boxing.py#L46>

There’s no indication of what `typ, val, c` are. Furthermore `unbox_integer(typ, obj, c)` might be readable for someone familiar with numba internals, but it’s absolutely unreadable for anyone else. Even if you are familiar, you get no help from autocompletion unless you annotate. There are many such internal APIs where certain signatures are expected, but no information of what will be passed to each argument.

Just my two cents.

---

<div class="post-metadata">

**Author:** ![luk-f-a](https://yyz2.discourse-cdn.com/free1/user_avatar/numba.discourse.group/luk-f-a/32/56_2.png) [@luk-f-a](https://numba.discourse.group/u/luk-f-a)\
**Post date:** [October 12, 2020, 9:27am UTC](https://numba.discourse.group/t/public-numba-dev-meeting-tuesday-october-13-2020/253/5 "2020-10-12T09:27:00Z")

</div>

On the topic of suggestions, I am wondering if the core devs are considering new extension APIs to allow new behaviour without modifying Numba itself.

---

<div class="post-metadata">

**Author:** ![sklam](https://yyz2.discourse-cdn.com/free1/user_avatar/numba.discourse.group/sklam/32/9_2.png) [@sklam](https://numba.discourse.group/u/sklam)\
**Post date:** [October 12, 2020, 8:03pm UTC](https://numba.discourse.group/t/public-numba-dev-meeting-tuesday-october-13-2020/253/6 "2020-10-12T20:03:29Z")

</div>

> [@luk-f-a](#):
>
> On the topic of suggestions, I am wondering if the core devs are considering new extension APIs to allow new behaviour without modifying Numba itsel

Yes, the “numba-extras” for additive extensions. However, that will not allow changes to existing types or behavior.