# Development

**URL:** https://numba.discourse.group/c/numba/development/8.md?page=2

[Latest](https://numba.discourse.group/latest.md) · [Categories](https://numba.discourse.group/categories.md)

**Page:** 3

---

## [Can we remove the \`c\` argument to \`typeof\_impl\`?](https://numba.discourse.group/t/can-we-remove-the-c-argument-to-typeof-impl/118)

<div class="topic-metadata">

**Author:** [@gmarkall](https://numba.discourse.group/u/gmarkall)\
**Replies:** 4\
**Last updated:** [July 23, 2020, 12:03am UTC](https://numba.discourse.group/t/can-we-remove-the-c-argument-to-typeof-impl/118 "2020-07-23T00:03:41Z")

</div>

When registering type inference for Python values, as in the Interval Example, the function supplied must accept two parameters: @typeof\_impl.register(Interval) def typeof\_index(val, c): return interval\_type The fi…

---

## [Improve @guvectorize capabilities](https://numba.discourse.group/t/improve-guvectorize-capabilities/66)

<div class="topic-metadata">

**Author:** [@guilherme](https://numba.discourse.group/u/guilherme)\
**Replies:** 2\
**Last updated:** [July 7, 2020, 4:13pm UTC](https://numba.discourse.group/t/improve-guvectorize-capabilities/66 "2020-07-07T16:13:50Z")

</div>

Currently, @guvectorize functions works by compiling the functions ahead of time. The decorator expects the list of signatures as well as the declaration of input and output layouts: @guvectorize(\[(int64\[:\], int64, int6…

---

## [Type Hints for Numba](https://numba.discourse.group/t/type-hints-for-numba/37)

<div class="topic-metadata">

**Author:** [@EPronovost](https://numba.discourse.group/u/EPronovost)\
**Replies:** 6\
**Last updated:** [July 4, 2020, 8:01pm UTC](https://numba.discourse.group/t/type-hints-for-numba/37 "2020-07-04T20:01:56Z")

</div>

Now that we’ve deprecated Python 2 support, I’m wondering if anyone has thought about adding type hints to numba. If the infrastructure to run mypy was in place, this could be a good thing for community contributions.

---

## [Lets add standalone compilation like AssemblyScript](https://numba.discourse.group/t/lets-add-standalone-compilation-like-assemblyscript/77)

<div class="topic-metadata">

**Author:** [@redradist](https://numba.discourse.group/u/redradist)\
**Replies:** 1\
**Last updated:** [June 30, 2020, 12:46pm UTC](https://numba.discourse.group/t/lets-add-standalone-compilation-like-assemblyscript/77 "2020-06-30T12:46:48Z")

</div>

Hi all, I know Numba already have standalone compilation https://numba.pydata.org/numba-doc/dev/user/pycc.html … But for me it would be better if it would allow to compile any python program that was properly annotated…

---

## [Lets use Python type annotations](https://numba.discourse.group/t/lets-use-python-type-annotations/76)

<div class="topic-metadata">

**Author:** [@redradist](https://numba.discourse.group/u/redradist)\
**Replies:** 8\
**Last updated:** [June 29, 2020, 5:35pm UTC](https://numba.discourse.group/t/lets-use-python-type-annotations/76 "2020-06-29T17:35:57Z")

</div>

Guys, I am wondering if Numba will support native CPython type annotations ? CPython type annotations so powerful that it allow to annotate argument with whatever object: def sum(i: int, k: int): pass def sum(i: n…

---

## [Addons / Contrib repo](https://numba.discourse.group/t/addons-contrib-repo/29)

<div class="topic-metadata">

**Author:** [@luk-f-a](https://numba.discourse.group/u/luk-f-a)\
**Replies:** 6\
**Last updated:** [June 26, 2020, 6:45pm UTC](https://numba.discourse.group/t/addons-contrib-repo/29 "2020-06-26T18:45:08Z")

</div>

Hi, one current problem for core-devs seems to be the large number of PRs that they have to review. Besides basic correctness, they need to ensure that these PRs do not have unintended consequences, and that they will n…

---

## [Host Side Memory Allocation (for CUDA)](https://numba.discourse.group/t/host-side-memory-allocation-for-cuda/64)

<div class="topic-metadata">

**Author:** [@uchytilc](https://numba.discourse.group/u/uchytilc)\
**Replies:** 4\
**Last updated:** [June 26, 2020, 4:02am UTC](https://numba.discourse.group/t/host-side-memory-allocation-for-cuda/64 "2020-06-26T04:02:05Z")

</div>

I am wondering how Numba deals with host side memory allocation. I am very unfamiliar with the inner workings of Numpy and have very little experience with extending Python into C. From what I gather it looks like Numba …

---

## [LLVM upstream version vs. NVVM LLVM version](https://numba.discourse.group/t/llvm-upstream-version-vs-nvvm-llvm-version/62)

<div class="topic-metadata">

**Author:** [@gmarkall](https://numba.discourse.group/u/gmarkall)\
**Replies:** 4\
**Last updated:** [June 25, 2020, 8:06pm UTC](https://numba.discourse.group/t/llvm-upstream-version-vs-nvvm-llvm-version/62 "2020-06-25T20:06:22Z")

</div>

Numba uses llvmlite’s version of LLVM for building and optimizing IR before sending it to NVVM in the CUDA target. The current issues / concerns with this are: A patch to LLVM 9 was required to stop the IR auto-upgrade…

[Previous page](https://numba.discourse.group/c/numba/development/8.md?page=1)
