The most widely used Python to C compiler

Overview

Welcome to Cython!

Cython is a language that makes writing C extensions for Python as easy as Python itself. Cython is based on Pyrex, but supports more cutting edge functionality and optimizations.

The Cython language is very close to the Python language, but Cython additionally supports calling C functions and declaring C types on variables and class attributes. This allows the compiler to generate very efficient C code from Cython code.

This makes Cython the ideal language for wrapping external C libraries, and for fast C modules that speed up the execution of Python code.

You can support the Cython project via Github Sponsors or Tidelift.

Installation:

If you already have a C compiler, just run following command:

pip install Cython

otherwise, see the installation page.

License:

The original Pyrex program was licensed "free of restrictions" (see below). Cython itself is licensed under the permissive Apache License.

See LICENSE.txt.

Contributing:

Want to contribute to the Cython project? Here is some help to get you started.

We are currently building the next great Cython edition: Cython 3.0. You can help us make the life of Python 3.x users easier.

Get the full source history:

Note that Cython used to ship the full version control repository in its source distribution, but no longer does so due to space constraints. To get the full source history from a downloaded source archive, make sure you have git installed, then step into the base directory of the Cython source distribution and type:

make repo

The following is from Pyrex:

This is a development version of Pyrex, a language for writing Python extension modules.

For more info, take a look at:

  • Doc/About.html for a description of the language
  • INSTALL.txt for installation instructions
  • USAGE.txt for usage instructions
  • Demos for usage examples

Comments, suggestions, bug reports, etc. are most welcome!

Copyright stuff: Pyrex is free of restrictions. You may use, redistribute, modify and distribute modified versions.

The latest version of Pyrex can be found here.

Greg Ewing, Computer Science Dept
University of Canterbury
Christchurch, New Zealand
A citizen of NewZealandCorp, a wholly-owned subsidiary of USA Inc.
Issues
  • Large output size of compiled code

    Large output size of compiled code

    Hi All,

    I'm trying to reduce the packaged size of the scientific computing ecosystem to make it friendlier for distributed deployments using tools like docker, kubernetes, etc.. An issue for this topic generally is here: https://github.com/ContinuumIO/anaconda-issues/issues/8242

    One important issue that came up from @mingwandroid relates to Cython, see https://github.com/ContinuumIO/anaconda-issues/issues/8242#issuecomment-359524128

    It seems the shared libraries are chock full of instruction code

    PyInit_cython_special is huge; more than 1MB.

    why all of these movq instructions are not being coalesced into a memset.

    In a separate conversation he said the following:

    Now ideally you'd like your compiler to be smart enough to coalesce all those clears over the whole object into 1 memset, and then even better, put them all together so that a single memset could do it. the package size on disk is swamped by the instructions to do these clears! instead of a call to a function to memset it's a huge amount of instructions, like tens of thousands. and that takes space on the extension module text segment.

    To be honest, I don't have much expertise here, but I thought I'd raise an issue here in case this sort of problem can be resolved within Cython, or, if not, if anyone here has any additional helpful thoughts.

    Thank you all for your time.

    enhancement Code Generation Build System 
    opened by mrocklin 52
  • Verbatim C code using docstring syntax.

    Verbatim C code using docstring syntax.

    Allow including snippets of C code in a cdef extern from * block using docstring syntax:

    cdef extern from *:
        """
        static long square(long x)
        {
            return x * x;
        }
        """
        long square(long)
    

    This is an alternative to adding an external .h file containing the C code. This would be useful especially for simple things, like a one-line macro.

    I still have to write documentation, but I'll wait for feedback first.

    Edit: This is currently a syntax error and thus cannot conflict with existing code.

    enhancement 
    opened by jdemeyer 50
  • Introduce pure python mode in language basics documentation

    Introduce pure python mode in language basics documentation

    This PR is introducing pure python mode in language basics documentation. It is partial fix of https://github.com/cython/cython/issues/4187

    Documentation 
    opened by matusvalo 42
  • Switch to github actions

    Switch to github actions

    Closes #3913

    Latest run: https://github.com/davfsa/cython/actions/runs/769744264

    enhancement Testing 
    opened by davfsa 39
  • Late includes

    Late includes

    This pull request adds support for a late #include. My proposed syntax is to add a leading pipe to the filename:

    cdef extern from "|spam.h":
        ...
    

    For this cdef extern block, Cython will generate the #include statement after its own variable declarations. So it can be used if the C code in spam.h needs to refer to Cython variables.

    cysignals has a use-case which is currently "solved" by some ugly hack involving .pxi files (for which I need #483). If this pull request is accepted, cysignals would no longer need to rely on .pxi files: https://github.com/sagemath/cysignals/pull/49

    Of course, there are plenty of bikeshedding opportunities for the syntax, but I care about the feature, not the syntax. I chose the leading pipe because it is unlikely to occur in actual filenames. (Also: think of the pipe as "piping" the Cython variables into the header file).

    opened by jdemeyer 36
  • Pythonise the documentation according to #4187: Basic Tutorial (cython_tutorial.rst)

    Pythonise the documentation according to #4187: Basic Tutorial (cython_tutorial.rst)

    This is the first step in adding Pure Python code versions to all Cython documentation!

    Note, since the current tests for .py files do not add cython to namespace, some tests are expected to fail due to the convention not to use import cython in most pure python files.

    To be able to try this, you will need to install doc-requirements.txt (it has been updated).

    Lots of process details and standardization are found here: #4187

    Small preview: Small preview

    Documentation 
    opened by 0dminnimda 36
  • Added PEP 442 implementation and test case

    Added PEP 442 implementation and test case

    This should adress #3612. I added a simple test case to ensure that the __del__ methods is called when the cdef class is released.

    feature Python Semantics 
    opened by ax487 36
  • no attribute __reduce_cython__

    no attribute __reduce_cython__

    https://github.com/cython/cython/issues/1894#issuecomment-339966952.

    I'm getting an AttributeError due to a missing __reduce_cython__ attribute in an embedded environment when I build lxml with Cython 0.26 or 0.27. 0.25(.2) works fine. The issue seems to be triggered by reinitializing the environment but unfortunately I was not able to find a minimal sample that replicates it yet.

    I did a git-bisect and found https://github.com/cython/cython/commit/f8b3405e926d2ba9bc2ee24d79848235875ee12e to be the first broken commit.

    Will try to find a simple test case, but I'm not sure how soon I'll have a result.

    EDIT: This was resolved in Cython 0.28. See https://github.com/cython/cython/issues/1953#issuecomment-398128940.

    opened by cschramm 36
  • Add a Pythran backend for Numpy operation

    Add a Pythran backend for Numpy operation

    I've been working for quite some time on the usage of Pythran as a backend for the Numpy operations that Cython can generate. The associated PR on github can be found here: . This work has been sponsored by the OpenDreamKit project (https://github.com/OpenDreamKit/OpenDreamKit/).

    First of all, the Pythran project (https://github.com/serge-sans-paille/pythran) is a (subset of) Python to C++ compiler, that aims at optimizing "scientific" Python code. It also provides a full C++ implementation of a major set of the Numpy API. Some of the advantage of this implementation is that it supports expression templates and SIMD instructions (partially thanks to Boost.SIMD [1]).

    One of the limitation of the current Numpy support of Cython is that it relies on the original Numpy Python module for a lot of computations. The overall idea is to replace these calls by the Numpy implementation provided within the Pythran project.

    I'll discuss in this mail the various choices that have been made, why and some implementation details. Then we'll also show some benchmark to see the potential improvements, which is the point of all this in the end :)

    Pythran limitations

    The Pythran Numpy implementation has some limitations:

    • array "views" are not supported. That means that arrays must be stored in contiguous memory. Fortran and C-style format are supported.
    • the endianness of the integers must be the same that the one of the targeted architecture (note that Cython has the same limitation)

    That's why we did two things:

    • the usage of the Pythran backend needs to be explicitly asked by the user by providing the --np-pythran flag to the Cython compiler, or by using the "np_pythran" flag to the cythonize call (for distutils)
    • in function arguments, Numpy buffers are replaced by fused types to be able to fall back in case of unsupported buffers. More on this below.

    Implementation choices and details within Cython

    a) PythranExpr

    We defined a new type in PyrexTypes.py, which defines a Pythran buffer or expression. A Pythran expression is associated to a Pythran expression template, whose C++ type can be something like "decltype(a+b)". We thus compose every expression/function call like this, which allows us to use Pythran's expression template mechanism.

    We also choose to let the C++ compiler deduced the final type of every expression, and emit errors if something goes wrong. This choice allows not to have to rewrite in Python all the (potentially implicit) conversion rules that can apply in a C/C++ program, which could be error prone. The disadvantage is that it may generate not that trivial error messages for the end-user.

    b) Fused types for function arguments

    As Pythran has some limitations about the Numpy buffers it can support, we chose to replace Numpy buffer arguments by a fused type that can be either a Pythran buffer or the original Numpy buffer. The decision is made to use one type or another according to the limitations described above.

    This allows a fallback to the original Cython implementation in case of an unsupported buffer type.

    Tests

    A flag has been added to the runtests.py script. If provided with a path to a Pythran installation, it will run the C++ tests in "Pythran" mode. This allows to reuse the whole test suite of Cython.

    Benchmark

    The whole idea of this is to get better performances.

    Here is a simple benchmark of what this mode can achieve, using this cython code:

    def sqrt_sum(numpy.ndarray[numpy.float_t, ndim=1] a, numpy.ndarray[numpy.float_t, ndim=1] b):
        return numpy.sqrt(numpy.sqrt(a*a+b*b))
    

    On my computer (Core i7-6700HQ), this gives there results, with an array of 100000000 32-bit floats as input:

    • for the classical Cython version: 960ms
    • for the Cython version using the Pythran backend: 761ms
    • for the Cython version using the Pythran backend using SIMD instructions: 243ms

    which makes a speedup of ~3.9x using SIMD instructions.

    Documentation

    I put an example of how to use this with distutils in the documentation. It could be put elsewhere if needed, or formatted differently.

    opened by aguinet 34
  • Add create_extension() hook

    Add create_extension() hook

    As alternative to #412, add support for a hook function create_extension() allowing complete customization of creating the Extension object after Cython has processed the list of sources and # distutils declarations.

    opened by jdemeyer 34
  • [BUG] Example code has compilation error in cython tutorial - Primes with C++

    [BUG] Example code has compilation error in cython tutorial - Primes with C++

    Describe the bug

    I encountered a bug when following cython tutorial - Primes with C++

    I used the code which is presented in the tutorial, and named it to primes_vec.py. I used the setup.py (shown below) to compile it, but it failed with error.

    from setuptools import setup
    from Cython.Build import cythonize
    
    setup(
        ext_modules = cythonize(
            [
                'primes_vec.py',
            ],
            annotate=True,
        ),
    )
    
    python setup.py build_ext --inplace
    Compiling primes_vec.py because it changed.
    [1/1] Cythonizing primes_vec.py
    /home/user/anaconda3/envs/cython/lib/python3.10/site-packages/Cython/Compiler/Main.py:369: FutureWarning: Cython directive 'language_level' not set, using 2 for now (Py2). This will change in a later release! File: /path/CythonPractice/prime/primes_vec.py
      tree = Parsing.p_module(s, pxd, full_module_name)
    
    Error compiling Cython file:
    ------------------------------------------------------------
    ...
    from cython.cimports.libcpp.vector import vector
    
    def primes(nb_primes: cython.uint):
        i: cython.int
        p: vector[cython.int]
        p.reserve(nb_primes)  # allocate memory for 'nb_primes' elements.
       ^
    ------------------------------------------------------------
    
    primes_vec.py:9:4: local variable 'p' referenced before assignment
    
    Error compiling Cython file:
    ------------------------------------------------------------
    ...
        i: cython.int
        p: vector[cython.int]
        p.reserve(nb_primes)  # allocate memory for 'nb_primes' elements.
    
        n: cython.int = 2
        while p.size() < nb_primes:  # size() for vectors is similar to len()
             ^
    ------------------------------------------------------------
    
    primes_vec.py:12:10: local variable 'p' referenced before assignment
    
    Error compiling Cython file:
    ------------------------------------------------------------
    ...
        p: vector[cython.int]
        p.reserve(nb_primes)  # allocate memory for 'nb_primes' elements.
    
        n: cython.int = 2
        while p.size() < nb_primes:  # size() for vectors is similar to len()
            for i in p:
                    ^
    ------------------------------------------------------------
    
    primes_vec.py:13:17: local variable 'p' referenced before assignment
    
    Error compiling Cython file:
    ------------------------------------------------------------
    ...
        while p.size() < nb_primes:  # size() for vectors is similar to len()
            for i in p:
                if n % i == 0:
                    break
            else:
                p.push_back(n)  # push_back is similar to append()
               ^
    ------------------------------------------------------------
    
    primes_vec.py:17:12: local variable 'p' referenced before assignment
    
    Error compiling Cython file:
    ------------------------------------------------------------
    ...
                p.push_back(n)  # push_back is similar to append()
            n += 1
    
        # If possible, C values and C++ objects are automatically
        # converted to Python objects at need.
        return p  # so here, the vector will be copied into a Python list.          ^
    ------------------------------------------------------------
    
    primes_vec.py:22:11: local variable 'p' referenced before assignment
    Traceback (most recent call last):
      File "/path/CythonPractice/prime/setup.py", line 5, in <module>
        ext_modules = cythonize(
      File "/home/user/anaconda3/envs/cython/lib/python3.10/site-packages/Cython/Build/Dependencies.py", line 1103, in cythonize
        cythonize_one(*args)
      File "/home/user/anaconda3/envs/cython/lib/python3.10/site-packages/Cython/Build/Dependencies.py", line 1226, in cythonize_one
        raise CompileError(None, pyx_file)
    Cython.Compiler.Errors.CompileError: primes_vec.py
    

    Environment (please complete the following information):

    • OS: macOS
    • Python version: 3.10.0
    • Cython version 0.29.26
    opened by Co1lin 3
  • Backport gh-4563 : generate dependency files

    Backport gh-4563 : generate dependency files

    Backport of gh-4563 for 0.29.x

    opened by ev-br 1
  • Stop cfunc/ccall/class applying to inner funcs/classes

    Stop cfunc/ccall/class applying to inner funcs/classes

    Fixes https://github.com/cython/cython/issues/4092

    Inner classes isn't tested because they don't officially work at this stage (see https://github.com/cython/cython/issues/4572). It should be tested if/when they're fully supported

    opened by da-woods 1
  • [BUG] SIGABRT while running generated __Pyx_PyObject_CallOneArg

    [BUG] SIGABRT while running generated __Pyx_PyObject_CallOneArg

    I have a small piece of code which runs gevent.subprocess.run to execute netstat -nr, before which I set the environment variables. The code looks like:

    import os
    import gevent.subprocess
    
    def run():
        env = dict(os.environ)
        gevent.subprocess.run(...., env=env)
    

    Note:

    • so this run() is called pretty frequently: Once in every 5 seconds
    • It runs fine for a few hours before just aborting at the code. I ran my cythonized code with -g3 and -O0 to get better stack traces and here's how it looks like:
    #1  0x0000000801a730c4 in raise () from /lib/libc.so.7                                                                                                                  #2  0x0000000801a73039 in abort () from /lib/libc.so.7
    #3  0x0000000800b968c9 in ?? () from /usr/local/lib/libpython3.8.so.1.0                                                                                                 #4  0x0000000800b965b3 in Py_FatalError () from /usr/local/lib/libpython3.8.so.1.0
    #5  0x0000000800af44e9 in ?? () from /usr/local/lib/libpython3.8.so.1.0                                                                                                 #6  0x0000000800b01728 in _PyUnicodeWriter_PrepareInternal () from /usr/local/lib/libpython3.8.so.1.0
    #7  0x0000000800afa859 in PyUnicode_DecodeASCII () from /usr/local/lib/libpython3.8.so.1.0
    #8  0x0000000800afa56d in PyUnicode_Decode () from /usr/local/lib/libpython3.8.so.1.0
    #9  0x0000000800afa2f4 in PyUnicode_FromEncodedObject () from /usr/local/lib/libpython3.8.so.1.0
    #10 0x0000000800a887ed in ?? () from /usr/local/lib/libpython3.8.so.1.0
    #11 0x0000000800a96b84 in ?? () from /usr/local/lib/libpython3.8.so.1.0
    #12 0x0000000800b59ae4 in ?? () from /usr/local/lib/libpython3.8.so.1.0
    #13 0x0000000800b56c40 in _PyEval_EvalFrameDefault () from /usr/local/lib/libpython3.8.so.1.0
    #14 0x0000000800b5a7b0 in _PyEval_EvalCodeWithName () from /usr/local/lib/libpython3.8.so.1.0
    #15 0x0000000800a8dd9b in _PyFunction_Vectorcall () from /usr/local/lib/libpython3.8.so.1.0
    #16 0x0000000800b59ae4 in ?? () from /usr/local/lib/libpython3.8.so.1.0
    #17 0x0000000800b56c64 in _PyEval_EvalFrameDefault () from /usr/local/lib/libpython3.8.so.1.0
    #18 0x0000000800a9e224 in ?? () from /usr/local/lib/libpython3.8.so.1.0
    #19 0x0000000800b52bf5 in _PyEval_EvalFrameDefault () from /usr/local/lib/libpython3.8.so.1.0
    #20 0x0000000800a9e224 in ?? () from /usr/local/lib/libpython3.8.so.1.0
    #21 0x0000000800aaa3e3 in ?? () from /usr/local/lib/libpython3.8.so.1.0
    #22 0x0000000800a78ac8 in ?? () from /usr/local/lib/libpython3.8.so.1.0
    #23 0x0000000800abf651 in ?? () from /usr/local/lib/libpython3.8.so.1.0
    #24 0x0000000800ac443f in ?? () from /usr/local/lib/libpython3.8.so.1.0
    #25 0x0000000800ae24b1 in ?? () from /usr/local/lib/libpython3.8.so.1.0
    #26 0x000000080976d1d5 in __Pyx_PyObject_Call (func=<type at remote 0x800efa060>, Python Exception <class 'gdb.error'>: There is no member named dk_nentries.
    arg=, kw=0x0) at common/cmd.c:3645
    #27 0x000000080976e1b5 in __Pyx__PyObject_CallOneArg (func=<type at remote 0x800efa060>, Python Exception <class 'gdb.error'>: There is no member named dk_nentries.
    arg=) at common/cmd.c:3684
    #28 0x000000080976cef2 in __Pyx_PyObject_CallOneArg (func=<type at remote 0x800efa060>, Python Exception <class 'gdb.error'>: There is no member named dk_nentries.
    arg=) at common/cmd.c:3703
    #29 0x000000080976a5a3 in __pyx_pf_3cmd_run (__pyx_self=<cython_function_or_method at remote 0x8078b7930>, __pyx_v_command='netstat',
        __pyx_v_envvars=None, __pyx_v_args=('-rn',)) at common/cmd.c:1463
    #30 0x0000000809769cfd in __pyx_pw_3cmd_1run (__pyx_self=<cython_function_or_method at remote 0x8078b7930>, __pyx_args=('netstat', '-rn'),
        __pyx_kwds=0x0) at common/cmd.c:1393
    
    //.... other frames
    

    After jumping to frame 29, I see that this is the generated line at which it failed:

    (gdb) f 29
    #29 0x000000080976a5a3 in __pyx_pf_3cmd_run (__pyx_self=<cython_function_or_method at remote 0x8078b7930>, __pyx_v_command='netstat',
        __pyx_v_envvars=None, __pyx_v_args=('-rn',)) at common/cmd.c:1463
    1463      __pyx_t_1 = __Pyx_PyObject_CallOneArg(((PyObject *)(&PyDict_Type)), __pyx_t_3); if (unlikely(!__pyx_t_1)) __PYX_ERR(0, 24, __pyx_L1_error)
    (gdb) l
    1458      __Pyx_GetModuleGlobalName(__pyx_t_1, __pyx_n_s_os); if (unlikely(!__pyx_t_1)) __PYX_ERR(0, 24, __pyx_L1_error)
    1459      __Pyx_GOTREF(__pyx_t_1);
    1460      __pyx_t_3 = __Pyx_PyObject_GetAttrStr(__pyx_t_1, __pyx_n_s_environ); if (unlikely(!__pyx_t_3)) __PYX_ERR(0, 24, __pyx_L1_error)
    1461      __Pyx_GOTREF(__pyx_t_3);
    1462      __Pyx_DECREF(__pyx_t_1); __pyx_t_1 = 0;
    1463      __pyx_t_1 = __Pyx_PyObject_CallOneArg(((PyObject *)(&PyDict_Type)), __pyx_t_3); if (unlikely(!__pyx_t_1)) __PYX_ERR(0, 24, __pyx_L1_error)
    1464      __Pyx_GOTREF(__pyx_t_1);
    1465      __Pyx_DECREF(__pyx_t_3); __pyx_t_3 = 0;
    1466      __pyx_v_env = ((PyObject*)__pyx_t_1);
    1467      __pyx_t_1 = 0;
    (gdb)
    

    Which mapped to this code (as per the cmd.c file):

    /* "common/cmd.py":24
    *     # Run the subprocess
    *     env = dict(os.environ)             # <<<<<<<<<<<<<<
    */
     __Pyx_GetModuleGlobalName(__pyx_t_1, __pyx_n_s_os); if (unlikely(!__pyx_t_1)) __PYX_ERR(0, 24, __pyx_L1_error)
     __Pyx_GOTREF(__pyx_t_1);
     __pyx_t_3 = __Pyx_PyObject_GetAttrStr(__pyx_t_1, __pyx_n_s_environ); if (unlikely(!__pyx_t_3)) __PYX_ERR(0, 24, __pyx_L1_error)
     __Pyx_GOTREF(__pyx_t_3);
     __Pyx_DECREF(__pyx_t_1); __pyx_t_1 = 0;
     __pyx_t_1 = __Pyx_PyObject_CallOneArg(((PyObject *)(&PyDict_Type)), __pyx_t_3); if (unlikely(!__pyx_t_1)) __PYX_ERR(0, 24, __pyx_L1_error)
     __Pyx_GOTREF(__pyx_t_1);
     __Pyx_DECREF(__pyx_t_3); __pyx_t_3 = 0;
     __pyx_v_env = ((PyObject*)__pyx_t_1);
     __pyx_t_1 = 0;
    

    Could anyone please help out in what could be going wrong here?

    Environment:

    • OS: FreeBSD 11.4
    • Python 3.8.12
    • Cython 0.29.23
    opened by Rahul-RB 10
  • [BUG] Compiler crash on nested class

    [BUG] Compiler crash on nested class

    Describe the bug The current alpha for Cython 3 crashes on a nested class definition in a py+pxd setup.

    To Reproduce Code to reproduce the behaviour:

    $ cat _red.py
    class R:
        class watch_key_states:
            pass
    $ cat _red.pxd
    cdef class R:
        pass
    $ cython -3 --line-directives -X infer_types=True _red.py
    /home/jelle/ans/venv/lib/python3.6/site-packages/Cython/Compiler/Main.py:346: FutureWarning: Cython directive 'language_level' not set, using '3str' for now (Py3). This has changed from earlier releases! File: /home/jelle/ans/web/lib/qclient/databox/_red.pxd
      tree = Parsing.p_module(s, pxd, full_module_name)
    
    Error compiling Cython file:
    ------------------------------------------------------------
    ...
    class R:
        class watch_key_states:
       ^
    ------------------------------------------------------------
    
    _red.py:2:4: Compiler crash in ControlFlowAnalysis
    
    ModuleNode.body = StatListNode(_red.py:1:0)
    CClassDefNode.body = StatListNode(_red.py:2:4)
    
    Compiler crash traceback from this point on:
      File "/home/jelle/ans/venv/lib/python3.6/site-packages/Cython/Compiler/Visitor.py", line 180, in _visit
        return handler_method(obj)
      File "/home/jelle/ans/venv/lib/python3.6/site-packages/Cython/Compiler/FlowControl.py", line 1335, in visit_PyClassDefNode
        self.env.lookup(node.target.name))
      File "/home/jelle/ans/venv/lib/python3.6/site-packages/Cython/Compiler/FlowControl.py", line 174, in mark_assignment
        if self.block and self.is_tracked(entry):
      File "/home/jelle/ans/venv/lib/python3.6/site-packages/Cython/Compiler/FlowControl.py", line 152, in is_tracked
        if entry.is_anonymous:
    AttributeError: 'NoneType' object has no attribute 'is_anonymous'
    $ cython --version
    Cython version 3.0.0a10
    

    Expected behavior Don't crash

    Environment (please complete the following information):

    • OS: Ubuntu
    • Python version 3.6.10
    • Cython 3.0.0a10

    Additional context This works fine on 0.29.x.

    opened by JelleZijlstra 4
  • [BUG] declaring a cpdef enum also populates the module namespace

    [BUG] declaring a cpdef enum also populates the module namespace

    Describe the bug When declaring a cpdef enum, its values are also dumped into the module namespace and made accessible from Python. This isn't how normal Python enums work. I also want to avoide cluttering up the modules namespace. To Reproduce

    cpdef enum letters:
    	a,b,c,d,e,f,g,h,i,j
    

    Compile the code, load the extension module from Python and do "module.a"

    Expected behavior All enum values are stored inside the enum (for example letters.a) but not available in the module. Environment (please complete the following information): Os: Windows 10 (64-bit) Python: 3.9.5 Cython: 0.29.26

    Additional context

    opened by Keithcat1 2
  • Implement PEP 614: more general expressions for decorators

    Implement PEP 614: more general expressions for decorators

    Describe the bug When compiling this code

    @(functools).wraps(foo)
    def bar(): pass
    

    Cython fails with such output

    @(functools).wraps(foo)
    ^
    ------------------------------------------------------------
    
    ...\test.pyx:6:1: Expected an identifier
    

    I know that

    (object).__name__
    

    is supported, therefore that behavior with decorators seems weird

    Expected behavior To just interpret that as

    @functools.wraps(foo)
    

    like python does and don't show any errors :)

    Environment (please complete the following information):

    • OS: Windows
    • Python version 3.9.0
    • Cython version 3.0.0a8
    feature Python Semantics 
    opened by 0dminnimda 1
  • [ENH] Allow runtime conditional GIL releasing/acquiring?

    [ENH] Allow runtime conditional GIL releasing/acquiring?

    Is your feature request related to a problem? Please describe. A clear and concise description of what the problem is. Ex. In my code, I would like to do [...]

    Currently with nogil(condition) accepts a compile-time condition (link). But how about a runtime condition? Is it possible?

    def increment(double x, is_ok):
        # is_ok is a Python object, x is a C double
        with nogil(is_ok):
            x = x + 1
        return x
    

    Describe the solution you'd like A clear and concise description of what you want to happen, including code examples if applicable.

    As title.

    Describe alternatives you've considered A clear and concise description of any alternative solutions or features you've considered.

    N/A

    Additional context Add any other context about the feature request here.

    Not sure if that this was not allowed is because of any technical difficulty, or just because no one asked for it, thus I'm raising a discussion. Thanks!

    opened by leofang 4
  • Switch to

    Switch to "new_build_ext" broke PyYAML

    @scoder @matusvalo This change killed some nasty dynamic build_ext subclassing that PyYAML's been doing since the dawn of time (see https://github.com/yaml/pyyaml/issues/601 and https://github.com/yaml/pyyaml/blob/6.0/setup.py#L174-L238). The most immediate issue is just that the cython_sources method from old_build_ext that PyYAML's subclass was calling is no longer available- I tried a few different ways of patching it on with no success (various issues around missing instance data on either the command or the extension by the time get_source_files is called).

    A couple of questions:

    1. Would you consider a reasonably simple change to emulate the cython_sources method from old_build_ext (to keep already-released PyYAML build_ext subclasses working on 3.0.0a10+ without modification)? That's assuming I can come up with one- so far, that's not looking good...
    2. Curious what the long-term plan is for old_build_ext? I can make things work again in future PyYAML releases without rewiring all the ancient build code just by swapping in old_build_ext (eg https://github.com/yaml/pyyaml/pull/602), but not sure how long it'll be around.

    Thanks!

    (I can open an issue for this, but if the answers to the above are "no" and "not very long", not much point :wink: )

    Originally posted by @nitzmahone in https://github.com/cython/cython/issues/4498#issuecomment-1011573018

    Build System 
    opened by scoder 2
  • [ENH] Advertize cython to be a build dependency rather than shipping C/C++ generated files

    [ENH] Advertize cython to be a build dependency rather than shipping C/C++ generated files

    This issue has been discussed on the cython-users mailing list and got approved by @scoder and @robertwb

    Basically one should just discourage the distribution of Cython-generated C/C++ files to save space, bandwidth, and the planet. Making Cython a build dependency is no more a burden with the improvement of packaging of Python in the last decade.

    This change also follows some general development guidelines like:

    • Don't put under VCS any computer generated file
    • Distribute pure source code, not semi-compiled code (Debian)

    The work to be done by modifying the documentation at: https://github.com/cython/cython/blob/master/docs/src/userguide/source_files_and_compilation.rst#distributing-cython-modules

    opened by kif 1
Releases(3.0.0a10)
A small C compiler written in Python for learning purposes

A small C compiler written in Python. Generates x64 Intel-format assembly, which is then assembled and linked by nasm and ld.

Scattered Thoughts 3 Oct 22, 2021
a simple functional programming language compiler written in python

Functional Programming Language A compiler for my small functional language. Written in python with SLY lexer/parser generator library. Requirements p

Ashkan Laei 3 Nov 5, 2021
A simple BrainF**k compiler written in Python

bf-comp A simple BrainF**k compiler written in Python. What else were you looking for?

null 1 Jan 9, 2022
🎉 🎉 PyComp - Java Code compiler written in python.

?? ?? PyComp Java Code compiler written in python. This is yet another compiler meant for babcock students project which was created using pure python

Alumona Benaiah 3 Jan 6, 2022
Pulse sequence builder and compiler for q1asm

q1pulse Pulse sequence builder and compiler for q1asm. q1pulse is a simple library to compile pulse sequence to q1asm, the assembly language of Qblox

Sander de Snoo 1 Jan 10, 2022
MatroSka Mod Compiler for ts4scripts

MMC Current Version: 0.2 MatroSka Mod Compiler for .ts4script files Requirements Have Python 3.7 installed and set as default. Running from Source pip

MatroSka 1 Dec 13, 2021
This is a small compiler to demonstrate how compilers work.

This is a small compiler to demonstrate how compilers work. It compiles our own dialect to C, while being written in Python.

Md. Tonoy Akando 2 Dec 28, 2021
A C-like hardware description language (HDL) adding high level synthesis(HLS)-like automatic pipelining as a language construct/compiler feature.

██████╗ ██╗██████╗ ███████╗██╗ ██╗███╗ ██╗███████╗ ██████╗ ██╔══██╗██║██╔══██╗██╔════╝██║ ██║████╗ ██║██╔════╝██╔════╝ ██████╔╝██║██████╔╝█

Julian Kemmerer 211 Jan 6, 2022
Hotpile: High Order Turing Machine Language Compiler

Hotpile: High Order Turing Machine Language Compiler Build and Run Requirements: Python 3.6+, bison, flex, and GCC installed. Needs to be run under UN

Jiang Weihao 4 Dec 29, 2021
Compiler Final Project - Lisp Interpreter

Compiler Final Project - Lisp Interpreter

null 2 Jan 7, 2022
Originally used during Marketplace.tf's open period, this program was used to get the profit of items bought with keys and sold for dollars.

Originally used during Marketplace.tf's open period, this program was used to get the profit of items bought with keys and sold for dollars. Practically useless for me now, but can be used as an example of tkinter.

BoggoTV 1 Dec 11, 2021
Python most simple|stupid programming language (MSPL)

Most Simple|Stupid Programming language. (MSPL) Stack - Based programming language "written in Python" Features: Interpretate code (Run). Generate gra

Kirill Zhosul 0 Dec 8, 2021
CBLang is a programming language aiming to fix most of my problems with Python

CBLang A bad programming language made in Python. CBLang is a programming language aiming to fix most of my problems with Python (this means that you

Chadderbox 4 Dec 29, 2021
This program goes thru reddit, finds the most mentioned tickers and uses Vader SentimentIntensityAnalyzer to calculate the ticker compound value.

This program goes thru reddit, finds the most mentioned tickers and uses Vader SentimentIntensityAnalyzer to calculate the ticker compound value.

null 167 Dec 31, 2021
A step-by-step tutorial for how to work with some of the most basic features of Nav2 using a Jupyter Notebook in a warehouse environment to create a basic application.

This project has a step-by-step tutorial for how to work with some of the most basic features of Nav2 using a Jupyter Notebook in a warehouse environment to create a basic application.

Steve Macenski 26 Dec 31, 2021
Wrappers around the most common maya.cmds and maya.api use cases

Maya FunctionSet (maya_fn) A package that decompose core maya.cmds and maya.api features to a set of simple functions. Tests The recommended approach

Ryan Porter 8 Sep 19, 2021
The most hackable keyboard in all the land

MiRage Modular Keyboard © 2021 Zack Freedman of Voidstar Lab Licensed Creative Commons 4.0 Attribution Noncommercial Share-Alike The MiRage is a 60% o

Zack Freedman 364 Jan 10, 2022
The goal of this program was to find the most common color in my living room.

The goal of this program was to find the most common color in my living room. I found a dataset online with colors names and their corr

null 1 Nov 9, 2021
Supply Chain will be a SAAS platfom to provide e-logistic facilites with most optimal

Shipp It Welcome To Supply Chain App [ Shipp It ] In "Shipp It" we are creating a full solution[web+app] for a entire supply chain from receiving orde

SAIKAT_CLAW 1 Jan 18, 2022