Deprecate numba.pycc

Capturing the outcome of the discussion on deprecating numba.pycc from the public Numba meeting on 2022-10-04 (meeting notes are in the wiki, but copying the relevant bits here):

PYCC has multiple longstanding issues and upcoming problems with setuptools; it also has very limited feature
Target to deprecate in 0.57 release
No one in the meeting objected

Essentially, numba.pycc (and everything associated with it) will be deprecated in version 0.57. Further subsequent searches for active use of numba.pycc did not have a large number of hits.

If this will impact a project you maintain or use please do comment on this issue. Many thanks!

I regularly use pycc as a helper to get profiling information about numba. If I use dynamic jit compiled code I can not see good benchmark information in perf or similar tools (see #5028), but by compiling a function of interest using pycc and then loading the generated shared library I can get decent profiling info (although debugging symbols are missing, which means I have to practice reading assembly :-) ).
I don't think this is necessarily a good reason not to deprecate it anyway, but I'll miss it if it is gone...

@aseyboldt

@aseyboldt that's an interesting and unexpected use of pycc, thanks for sharing it! This task is just to deprecate pycc so as to make it clear to users that it is eventially going to be removed. I hope by the time it is actually removed, Numba will have migrated to using LLVM's ORCJIT which has perf support (Numba currently uses MCJIT which does not).

I maintain a scientific software package (currently closed source) which uses the numba AOT compile in pycc so I guess this deprecation will affect us at some point. I understand the reason for the deprecation given the deprecation of distutils and etc.

But anyway we began using JIT with numba but found that the compile time to be quite long for some of our functions. We also tried the caching functionality but we found this to be quite problematic when running a lot of jobs simultaneously on a HPC with fresh repo so cache files hadn't been generated yet. Numba AOT seemed to be the best thing to do.

We had some ideas about what we should do such as moving to cython (this would be quite time-consuming) or perhaps we'd just fix our conda envs to a specific version of numba.

But anyway was wondering if you have any suggestions for people who do use pycc a lot in their code.

@ChiCheng45

@ChiCheng45 thanks for the input and for describing your use case.

It's anticipated that Numba will issue a NumbaPendingDeprecationWarning so as to start warning users that pycc will be deprecated at some point in the future. At the point pycc is fully deprecated, use of it will produce a NumbaDeprecationWarning. Further, at the point of deprecation, a deprecation schedule will be released explaining when it will be removed and documentation will available that includes instructions about how to migrate to a provided/suitable replacement. Essentially, rest assured that it won't just be removed, plenty of notice will be given, and a replacement will be provided when it is removed!

The fundamental purpose of starting the deprecation process for pycc is to warn people against writing new code that uses it and to make existing users aware that at some point a change will potentially be needed.

Hope this helps?

Will we have any substitutions for pycc? AOT functionality is quite essential if we want to use numba in production.

@auderson

Will we have any substitutions for pycc? AOT functionality is quite essential if we want to use numba in production.

@auderson yes, as noted in #8509 (comment), a replacement for this functionality will be provided when it is finally removed.

Add pending-deprecation warnings for ``numba.pycc``

PR #8795 issues pending-deprecation warnings.

This feature is also useful in cloud computing that don't allow the use of Numba JIT, but you can make a small pre-compiled library of your JIT functions. But I find it difficult to use. Consider the following example:

from numba.pycc import CC

cc = CC('test_cc1')

@cc.export('f', 'f8(f8)')
def f(x):
    return x + 123.4

@cc.export('g', 'f8(f8)')
def g(y):
    return y - 456.7

@cc.export('h', 'f8(f8, f8)')
def h(x, y):
    return f(x) * g(y)

if __name__ == "__main__":
    cc.compile()

When running python test_cc_src1.py it gives the following error:

(...)
numba.core.errors.TypingError: Failed in nopython mode pipeline (step: nopython frontend)
Untyped global name 'f': Cannot determine Numba type of <class 'function'>

File "test_cc_src1.py", line 15:
def h(x, y):
    return f(x) * g(y)
    ^

If I split this into two files so that f and g go into test_cc_src1.py and h goes into test_cc_src2.py, and then try and compile them in turn, I still get a similar error for the second file. I couldn't figure out how to make this work. Is there a solution?

Perhaps this is something you could improve in a new version of this system.

Thanks!

@Hvass-Labs

@Hvass-Labs try decorating e.g. the function f with @njit as well as @cc.export(...) the CC compiler should then be able to "see" the function f.

Is there a place we can follow development of the replacement AOT approach?

We use pycc internally (essentially an HPC use case) to avoid the first-call overhead. In our case I don't think we have any other constraints, so hm, maybe we can work with the existing support for caching the JIT output. Do you happen to know if anyone has an example / approach for doing explicit caching during the build, like a plugin for setuptools or poetry or something?

We can deal with the cache being CPU-specific - we'd likely want to set NUMBA_CPU_NAME to our baseline CPU anyway for reproducibility, but we can definitely just loop over all the CPUs in our environment.

Is there a place we can follow development of the replacement AOT approach?

A replacement for #8971 for 2024 will be posted soon and pinned to the top of the issue tracker, it will outline such development.

We use pycc internally (essentially an HPC use case) to avoid the first-call overhead. In our case I don't think we have any other constraints, so hm, maybe we can work with the existing support for caching the JIT output. Do you happen to know if anyone has an example / approach for doing explicit caching during the build, like a plugin for setuptools or poetry or something?

I don't know of any such project I'm afraid, it might be worth asking on Numba's discourse forum about approaches others are taking with regards to reusing caches? I'm not sure how reliable such an approach would be in practice.

We can deal with the cache being CPU-specific - we'd likely want to set NUMBA_CPU_NAME to our baseline CPU anyway for reproducibility, but we can definitely just loop over all the CPUs in our environment.

It's also worth nothing that pycc is deprecated pending removal, but full deprecation and removal is on the condition that a replacement is available, so it's fine to carry on using it.

@stuartarchibald

@stuartarchibald
I hope you're doing well. I'm reaching out to inquire about the latest developments regarding Ahead-Of-Time (AOT) compilation within Numba. As pycc has been deprecated, I am particularly interested in understanding the current alternatives or advancements that have been made in AOT compilation.

Could you please direct me to where I can find the most recent updates or discussions on this topic? Whether it's a specific GitHub issue, PR, or a discussion thread, any guidance would be greatly appreciated.

@stuartarchibald

Hi @stuartarchibald, I have the same question as @Ye980226, any news on this?

AOT work is taking place. Various components are being built:

numba-rvdsg (see project in the numba org), this is for restructuring Python bytecode and source into a form that is easier to compile. This is the most "front-end" part of the new technology.
PIXIE (see project in the numba org), this is for producing libraries, which can be shipped ahead-of-time, that embed representations of the code that can consumed by JIT compilers. This is the "back-end" part of the new technology.
The "middle-end" part of the new technology is currently under R&D.

If you are interested Numba development, perhaps the Numba Activity Newsletter would be of interest to you? They are posted monthly on the Numba discourse forum.

Hi! Is there any timeline on the development of the alternatives to pycc? I'm assessing the viability of Numba for our use-case (image processing) compared to other approaches like rewriting to C++, Cython etc. Our use-case would benefit from AOT greatly.

I am using pycc to run pre-compiled numba code from C to eliminate the python overhead and Numba's compile-time memory leaks 6707 from runtime.

Navigation Menu

Repository navigation

Deprecate `numba.pycc` #8509

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Deprecate numba.pycc #8509

Description

Activity

aseyboldt commented on Oct 22, 2022

stuartarchibald commented on Oct 24, 2022

ChiCheng45 commented on Nov 17, 2022

stuartarchibald commented on Dec 6, 2022

auderson commented on Feb 1, 2023

stuartarchibald commented on Feb 6, 2023

stuartarchibald commented on Mar 6, 2023

Hvass-Labs commented on Sep 2, 2023

stuartarchibald commented on Sep 12, 2023

geofft commented on Jan 21, 2024

stuartarchibald commented on Jan 26, 2024

Ye980226 commented on Jul 20, 2024

fulcus commented on Sep 15, 2024

stuartarchibald commented on Sep 27, 2024

vavanade commented on Jan 31, 2025

ca5446001-tech commented on Mar 17, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Deprecate `numba.pycc` #8509