The Stackless Python programming language

Overview

This is Python version 3.7.0 alpha 4+

CPython build status on Travis CI CPython build status on Appveyor CPython code coverage on Codecov

Copyright (c) 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017, 2018 Python Software Foundation. All rights reserved.

See the end of this file for further copyright and license information.

General Information

Contributing to CPython

For more complete instructions on contributing to CPython development, see the Developer Guide.

Using Python

Installable Python kits, and information about using Python, are available at python.org.

Build Instructions

On Unix, Linux, BSD, macOS, and Cygwin:

./configure
make
make test
sudo make install

This will install Python as python3.

You can pass many options to the configure script; run ./configure --help to find out more. On macOS and Cygwin, the executable is called python.exe; elsewhere it's just python.

On macOS, if you have configured Python with --enable-framework, you should use make frameworkinstall to do the installation. Note that this installs the Python executable in a place that is not normally on your PATH, you may want to set up a symlink in /usr/local/bin.

On Windows, see PCbuild/readme.txt.

If you wish, you can create a subdirectory and invoke configure from there. For example:

mkdir debug
cd debug
../configure --with-pydebug
make
make test

(This will fail if you also built at the top-level directory. You should do a make clean at the toplevel first.)

To get an optimized build of Python, configure --enable-optimizations before you run make. This sets the default make targets up to enable Profile Guided Optimization (PGO) and may be used to auto-enable Link Time Optimization (LTO) on some platforms. For more details, see the sections below.

Profile Guided Optimization

PGO takes advantage of recent versions of the GCC or Clang compilers. If ran, make profile-opt will do several steps.

First, the entire Python directory is cleaned of temporary files that may have resulted in a previous compilation.

Then, an instrumented version of the interpreter is built, using suitable compiler flags for each flavour. Note that this is just an intermediary step and the binary resulted after this step is not good for real life workloads, as it has profiling instructions embedded inside.

After this instrumented version of the interpreter is built, the Makefile will automatically run a training workload. This is necessary in order to profile the interpreter execution. Note also that any output, both stdout and stderr, that may appear at this step is suppressed.

Finally, the last step is to rebuild the interpreter, using the information collected in the previous one. The end result will be a Python binary that is optimized and suitable for distribution or production installation.

Link Time Optimization

Enabled via configure's --with-lto flag. LTO takes advantage of the ability of recent compiler toolchains to optimize across the otherwise arbitrary .o file boundary when building final executables or shared libraries for additional performance gains.

What's New

We have a comprehensive overview of the changes in the What's New in Python 3.7 document. For a more detailed change log, read Misc/NEWS, but a full accounting of changes can only be gleaned from the commit history.

If you want to install multiple versions of Python see the section below entitled "Installing multiple versions".

Documentation

Documentation for Python 3.7 is online, updated daily.

It can also be downloaded in many formats for faster access. The documentation is downloadable in HTML, PDF, and reStructuredText formats; the latter version is primarily for documentation authors, translators, and people with special formatting requirements.

For information about building Python's documentation, refer to Doc/README.rst.

Converting From Python 2.x to 3.x

Significant backward incompatible changes were made for the release of Python 3.0, which may cause programs written for Python 2 to fail when run with Python 3. For more information about porting your code from Python 2 to Python 3, see the Porting HOWTO.

Testing

To test the interpreter, type make test in the top-level directory. The test set produces some output. You can generally ignore the messages about skipped tests due to optional features which can't be imported. If a message is printed about a failed test or a traceback or core dump is produced, something is wrong.

By default, tests are prevented from overusing resources like disk space and memory. To enable these tests, run make testall.

If any tests fail, you can re-run the failing test(s) in verbose mode:

make test TESTOPTS="-v test_that_failed"

If the failure persists and appears to be a problem with Python rather than your environment, you can file a bug report and include relevant output from that command to show the issue.

Installing multiple versions

On Unix and Mac systems if you intend to install multiple versions of Python using the same installation prefix (--prefix argument to the configure script) you must take care that your primary python executable is not overwritten by the installation of a different version. All files and directories installed using make altinstall contain the major and minor version and can thus live side-by-side. make install also creates ${prefix}/bin/python3 which refers to ${prefix}/bin/pythonX.Y. If you intend to install multiple versions using the same prefix you must decide which version (if any) is your "primary" version. Install that version using make install. Install all other versions using make altinstall.

For example, if you want to install Python 2.7, 3.6, and 3.7 with 3.7 being the primary version, you would execute make install in your 3.7 build directory and make altinstall in the others.

Issue Tracker and Mailing List

Bug reports are welcome! You can use the issue tracker to report bugs, and/or submit pull requests on GitHub.

You can also follow development discussion on the python-dev mailing list.

Proposals for enhancement

If you have a proposal to change Python, you may want to send an email to the comp.lang.python or python-ideas mailing lists for initial feedback. A Python Enhancement Proposal (PEP) may be submitted if your idea gains ground. All current PEPs, as well as guidelines for submitting a new PEP, are listed at python.org/dev/peps/.

Release Schedule

See PEP 537 for Python 3.7 release details.

Copyright and License Information

Copyright (c) 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017, 2018 Python Software Foundation. All rights reserved.

Copyright (c) 2000 BeOpen.com. All rights reserved.

Copyright (c) 1995-2001 Corporation for National Research Initiatives. All rights reserved.

Copyright (c) 1991-1995 Stichting Mathematisch Centrum. All rights reserved.

See the file "LICENSE" for information on the history of this software, terms & conditions for usage, and a DISCLAIMER OF ALL WARRANTIES.

This Python distribution contains no GNU General Public License (GPL) code, so it may be used in proprietary projects. There are interfaces to some GNU code but these are entirely optional.

All trademarks referenced herein are property of their respective holders.

Comments
  • Stackless 2.7.* app crash

    Stackless 2.7.* app crash

    Here is the setup.

    Windows 7 x64 sp1 Stackless Python 2.7.* x32 Cython 0.28.3

    I am compiling python-openzwave which uses Cython. I get this error when compiling on stackless 2.7.* and not on standard python 2.7.*.

    I get a Python app crash as soon as it starts cythonizing.

    Here is the data from the app crash window

    Problem Event Name:	APPCRASH
    Application Name:	python.exe
    Application Version:	0.0.0.0
    Application Timestamp:	59ccecdf
    Fault Module Name:	python27.dll
    Fault Module Version:	2.7.14150.1013
    Fault Module Timestamp:	59ccecce
    Exception Code:	c0000005
    Exception Offset:	00069c2a
    OS Version:	6.1.7601.2.1.0.256.1
    Locale ID:	1033
    Additional Information 1:	0a9e
    Additional Information 2:	0a9e372d3b4ad19135b953a78882e789
    Additional Information 3:	0a9e
    Additional Information 4:	0a9e372d3b4ad19135b953a78882e789
    

    The project I am working on has been around since 1996 and Stackless Python was used and is not something that can be removed easily I am also not able to upgrade the python version to 3+ any time soon. I have brought up this error to the author(s) of Cython. they were kind enough to add Stackless to their test build on travis. they found that 2.7 fails completely and 3.5 (i believe) builds successfully. they are not compiling the same code as me so that is now removed from the equation. they are building on linux. so the OS has now been removed. If I take the dll (pyd) that is built on standard 2.7 and bring it over to stackless 2.7 I get the exact same app crash on import. This leads me to believe the problem is not with Cython but instead it is with Stackless Python.

    I searched the internet to see if anyone has had an issue with the 2 working together and I could not find any issues. I couldn't find anything on someone running the 2 together either. Pretty much a dead end.

    The issue reported to Cython can be viewed here:

    https://github.com/cython/cython/issues/2476

    Any help is appreciated. Thanks again. Kevin

    bug stackless python 2.7-slp 
    opened by kdschlosser 29
  • implement switching using the Stackman submodule

    implement switching using the Stackman submodule

    The Stackman project (http://github.com/kristjanvalur/stackman) aims to provide simple stack switching code for modern platforms. The aim is to have application-agnostic code that performs the basic functionality of saving machine registers and switching stack pointer, leaving the custom code of saving/restoring stack and choosing stack pointer to a user callback.

    The resulting switching code is very succinct and easy to verfy.

    This pull requests adds Stackman based switching for the supported platforms, which is GCC on intel (x86 and x86_64) and ARM 32 hard float and aarch64.

    enhancement stackless python main-slp 
    opened by kristjanvalur 26
  • mercurial / git / github

    mercurial / git / github

    Originally reported by: Kristján Valur Jónsson (Bitbucket: krisvale, GitHub: kristjanvalur)


    Now that python has moved to github, how do we merge stuff

    (couldn't figure out how to start a simple chat, without opening an issue)


    • Bitbucket: https://bitbucket.org/stackless-dev/stackless/issue/118
    major task 
    opened by ghost 21
  • slp_get_frame(PyTaskletObject *task) broken?

    slp_get_frame(PyTaskletObject *task) broken?

    Originally reported by: Anselm Kruis (Bitbucket: akruis, GitHub: akruis)


    Either my understanding of Python threading is poor or slp_get_frame() is buggy. This is the current implementation.

    #!python
    PyFrameObject *
    slp_get_frame(PyTaskletObject *task)
    {
        PyThreadState *ts = PyThreadState_GET();
    
        return ts->st.current == task ? ts->frame : task->f.frame;
    }
    

    It uses the current thread state, not the thread state of the given tasklet. task->cstate->tstate. If this is a bug, it affects tasklet.alive and other properties.


    • Bitbucket: https://bitbucket.org/stackless-dev/stackless/issue/44
    bug major stackless python 2.7-slp 
    opened by ghost 21
  • new method tasklet.bind_thread()

    new method tasklet.bind_thread()

    Originally reported by: RMTEW FULL NAME (Bitbucket: rmtew, GitHub: rmtew)


    (originally reported in Trac by @akruis on 2013-11-28 10:46:33)

    Thanks to Kristján Stackless Python got a new method: tasklet.bind_thread(). I won't discuss the motivation and the implementation details of this method here. It's all in this thread of the Stackless mailing list: http://www.stackless.com/pipermail/stackless/2013-November/005869.html

    The purpose of this ticket is to add all the missing details we need for the next release (2.7.6) of Stackless.

    • document the method in Doc/library/stackless/tasklets.rst
    • update the documentation in Doc/library/stackless/threads.rst to clearly describe the relation between a tasklet and a thread:
      • A tasklet always has an associated thread. This thread is identified by the property thread_id
      • The thread_id of a tasklet changes only if the method bind_thread() is called or if the associated thread terminates. In the later case the new thread is ... \ @Kristján here I need your input: I noticed, that the thread id changes to the main thread, but what happens if the main thread terminates while other threads are still active?
    • update Stackless/changelog.txt

    I'll take care about these points myself, but I need help from Kristján to add the missing information.


    • Bitbucket: https://bitbucket.org/stackless-dev/stackless/issue/26
    enhancement major stackless python 2.7-slp 
    opened by ghost 20
  • New tasklet attributes tasklet.trace_function and tasklet.profile_function

    New tasklet attributes tasklet.trace_function and tasklet.profile_function

    Originally reported by: Anselm Kruis (Bitbucket: akruis, GitHub: akruis)


    I added two attributes to class tasklet: tasklet.trace_function and tasklet.profile_function. These attributes are the tasklet counterparts of the standard functions sys.gettrace(), sys.settrace(), sys.getprofile() and sys.setprofile(). With these attributes it is now possible to control tracing completely using the schedule callback. An example is given in the documentation and in Stackless/demo/tracing.py.

    The implementation also changes slp_schedule_task_prepared / slp_restore_tracing to modify tracing related members of PyThreadState only with official API functions. This prevents a ref-counting problem and prevents incorrect values of the global flag _Py_TracingPossible in ceval.c


    • Bitbucket: https://bitbucket.org/stackless-dev/stackless/issue/43
    enhancement major stackless python 2.7-slp 
    opened by ghost 19
  • channel.close() less useful than thought

    channel.close() less useful than thought

    Originally reported by: Kristján Valur Jónsson (Bitbucket: krisvale, GitHub: kristjanvalur)


    Writing a unittest for sending a sequence through a channel, I tried the obvious, but failed:

    #!python
        def testSequence(self):
            def sender():
                self.c.send_sequence(xrange(10))
                self.c.close()
            data = []
            def receiver():
                for i in self.c:
                    data.append(i)
    
            stackless.tasklet(sender)()
            stackless.tasklet(receiver)()
            stackless.run()
            self.assertEqual(data, range(10))
            self.assertTrue(self.c.closed)
    
    
    

    This doesn't work, however. The receiver is stuck on a iter.next call at the end. This is because when the sender calls close, the channel balance is already -1. So it is set into 'closing' state, but that is it. In order to do this properly, the functions needed to be tweaked like this:

    #!python
            def sender():
                self.c.send_sequence(xrange(10))
                self.c.close()
                # this needs to change, close does not wake up a receiver, we must pump it
                while self.c.closing and not self.c.closed:
                    self.c.send(None)
    
            def receiver():
                for i in self.c:
                    data.append(i)
                #remove the extra "pump" nones at the end....
                while data[-1] is None:
                    data.pop(-1)
                data.append(10)
    
    

    I wonder if this system is how we want to do it? Wouldn't it be nicer if close() were immediate? It would wake up any blocked tasklets right away? We would get rid of the 'closing' attribute, or make it synonomous with 'closed'.

    As it is, I don't really se a use case for the sequence protocol if it needs to be shored up in boilerplate anyway.

    Is there a use case for the current closing/closed state transfer?


    • Bitbucket: https://bitbucket.org/stackless-dev/stackless/issue/53
    enhancement minor 
    opened by ghost 17
  • wrong stackless.current in schedule callback

    wrong stackless.current in schedule callback

    Originally reported by: Anselm Kruis (Bitbucket: akruis, GitHub: akruis)


    stackless.run() switches from the main tasklet to another tasklet T. If a schedule callback is invoked for this switch, the stackless.current is T. This is incorrect. Inspection of the code in slp_schedule_task_prepared() reveals, that Stackless calls the schedule callback before the switch.

    I added a test case and I also have a preliminary fix.


    • Bitbucket: https://bitbucket.org/stackless-dev/stackless/issue/42
    bug major stackless python 2.7-slp 
    opened by ghost 16
  • Do not kill deletable tasklets in PyThreadState_Clear

    Do not kill deletable tasklets in PyThreadState_Clear

    Originally reported by: RMTEW FULL NAME (Bitbucket: rmtew, GitHub: rmtew)


    (originally reported in Trac by @akruis on 2013-06-03 11:49:35)

    Problem

    If you run a tasklet only partially (the tasklet calls stackless.schedule_remove() ) and then pickle the tasklet for later execution, you do not want Python to kill the tasklet during PyThreadState_Clear.

    The following test code demonstrates the problem:

    import stackless
    import threading
    
    finally_run_count=0
    
    def task():
        global finally_run_count
        try:
            stackless.schedule_remove(None)
        finally:
            finally_run_count += 1
    
    def run():
        global tasklet
        t = stackless.tasklet(task)
        t()
        stackless.run()
        
        # if you comment the next line,
        # then t will be garbage collected 
        # at the end of this function. 
        tasklet = t
    
    thread = threading.Thread(target=run)
    thread.start()
    thread.join()
    tasklet = None
    
    print "finally_run_count: %d" % (finally_run_count,)
    

    This script emits "finally_run_count: 1". If you comment the line tasklet = t Python deletes the tasklet t during the execution of the thread. As a consequence the finally clause of function task won't be called and the script would print "finally_run_count: 0". Otherwise, the tasklet still exists when Python clears the thread state. In this case PyThreadState_Clear calls slp_kill_tasks_with_stacks which kills the tasklet.

    Unfortunately it is not always easily possible to delete the tasklet in time. For instance an object that is part of a not yet collected reference cycle can reference the tasklet and delay its destruction. (This happened in our application flowGuide. Depending on the execution of the garbage collector a tasklet was killed or simply deleted.)

    I propose to change the C-function slp_kill_tasks_with_stacks() to not kill a tasklet, if both conditions are met:

    • The tasklet can be deleted (C-function tasklet_has_c_stack() returns 0.
    • The tasklet is not scheduled (one of stackless.schedule_remove() or tasklet.remove() has been called).

    Does this change make sense? Are there any pitfalls?


    • Bitbucket: https://bitbucket.org/stackless-dev/stackless/issue/24
    bug major stackless python 2.7-slp 
    opened by ghost 15
  • Adhere to the PSF Trademark Usage Policy

    Adhere to the PSF Trademark Usage Policy

    Originally reported by: Anselm Kruis (Bitbucket: akruis, GitHub: akruis)


    It is a legal requirement to adhere to the PSF Trademark Usage Policy. Currently that is most certailly not the case.

    I would like to update our Stackless specific documentation (rst-files, doc-strings and source code comments) to meet the conditions set by the PSF for usage of the word "python".

    Plan:

    1. Summarise the rules for using the word "python" in Stackless.

    2. Update stackless specific *.rst files

    3. Update stackless specific doc strings

    4. Update other stackless specific documentation including sourcee code comments

    PythonTrademarkUsage.odt.zip


    • Bitbucket: https://bitbucket.org/stackless-dev/stackless/issue/34
    major task stackless python 2.7-slp 
    opened by ghost 14
  • hard switching using Stackman

    hard switching using Stackman

    The idea to share the stack switching code between different projects is not new, see issue #10. Last year Kristján Valur Jónsson made another attempt: pull request #230:

    The Stackman project (http://github.com/kristjanvalur/stackman) aims to provide simple stack switching code for modern platforms. The aim is to have application-agnostic code that performs the basic functionality of saving machine registers and switching stack pointer, leaving the custom code of saving/restoring stack and choosing stack pointer to a user callback.

    The resulting switching code is very succinct and easy to verify.

    I open this issue to discuss those aspects, that are unrelated to a particular implementation.

    What

    Make it possible to use Stackman to implement stack-switching instead of the current Stackless code.

    Why - Benefits and Drawbacks

    argument \ stakeholder | Stackless maintainer | Python developer | end user ------------------------------ | ---------------------------- | ------------------------ | ----------- Stackman is simpler to maintain. | + | | Supporting a new platform / architecture / compiler does not require changes to Stackless, only to Stackman | | + | | Stackless own hard switching code works well, Stackman adds complexity to the overall project | - | | | Performance is better / worse | | | +/- |

    Are there any arguments, why the performance of Stackman is better/worse than legacy Stackless stack switching?

    When

    Now. Stackless 3.7 is near its eol and Stackless 3.8 hasn't been released. Stackman seems to be sufficiently mature.

    How

    Pull request #230 proves that Stackman can be used, but there are many more ways to do it.

    Options

    1. Install Stackman as an external project. Add a make install option to Stackman. In Stackless add an option --with-stackman to configure.
    2. Like option 1, but automatically detect Stackman and use an option to disable Stackman (--without-stackman).
    3. Add Stackman as a git submodule to Stackless. That's what pull request #230 does.
    4. Add a full copy of Stackman source (archive) to a sub-directory in the Stackless source code.
    5. Add a partial copy of Stackman to the Stackless source code and automatically use it.

    There might be more options.

    Requirements

    Some requirements. There might be more.

    1. Using Stackman is a compile time option. It is still possible to use the legacy Stackless hard switching code.
    2. No user visible changes in API, stability, usage, if Stackless uses Stackman.
    3. Do not break a working build process, if building from a Stackless source archive. E.g. ./configure && make && make test && make install still works. Especially important for the Windows build process. As a consequence, Stackless should adhere to the Include-directory layout from C-Python.
    4. If Stackman is not bundled with Stackless source (options 1 and 2), there should be a mechanism to detect, if the found/specified version of Stackman is compatible with Stackless.
    5. No legal risk. Stackless currently is a leisure time project. (Currently I don't expect any problems here, it is just for completeness.)

    Discussion

    Just some preliminary thoughts

    We can divide the possible options into two goups:

    • option 1,2: Stackman is only available, if separately installed
    • option 3...5: Stackman is always available

    Currently Stackless is mostly used on Windows amd64 and Linux amd64 (32bit versions are fading away). On these platforms the existing hard switching code and building Stackless just works. Unless Stackman improves the performance, using Stackman or legacy Stackless stack-switching makes no difference. If there was a performance gain, we would prefer option 3...5.

    Advantages of option 1 and 2:

    • Implementation of option 1 or 2 is probably simpler than option 3 or 4. Adding a complete copy of the Stackman source causes its header files to live outside of ./Include. Therefore we would need to modify the installation process (make install and Windows Tools/msi) or the build process.
    • Selecting the right library is a concern of the Stackman installation.
    • Stackless source does not contain any precompiled binary.

    Option 5 would be fairly similar to the legacy solution. Upgrading to a newer Stackman version become complicated.

    enhancement major stackless python main-slp 
    opened by akruis 13
  • Use 'B' instead of 'b' to parse/build char value.

    Use 'B' instead of 'b' to parse/build char value.

    Issue:

    • pickle.load raises OverflowError if loaded content includes PyFrameObject, whose f_executing is set to SLP_FRAME_EXECUTING_INVALID, i.e. -1.

    Solution:

    • Use 'B' instead of 'b' to parse/build char value when frame object is pickled.

    How to reproduce this issue:

    • The following code causes OverflowError unexpectedly.
       import pickle
       import stackless
       import sys
      
      
       try:
           raise RuntimeError()
       except:
           traceback_object = sys.exc_info()[2]
       a = pickle.dumps(traceback_object)
       b = pickle.loads(a)
       c = pickle.dumps(b)
       d = pickle.loads(c)
       # => This raises "OverflowError: unsigned byte integer is less than minimum".
      

    Details:

    • f_executing in PyFrameObject is declared as char, which might be signed depending on implementation.
      Therefore, 'B' should be specified when Py_BuildValue and PyArg_ParseTuple is called.
    • If 'b' is specified instead of 'B' and f_executing is set to SLP_FRAME_EXECUTING_INVALID, PyArg_ParseTuple in frame_setstate in Stackless\pickling\prickelpit.c raises OverflowError.
      This is raised in convertsimple in Python\getargs.c because SLP_FRAME_EXECUTING_INVALID is less than 0.
    opened by masamitsu-murase 0
  • PEP-578 Audit Hooks for Stackless

    PEP-578 Audit Hooks for Stackless

    C-Python 3.8 adds various Audit Hooks, see. Various Stackless APIs could be used to bypaas those hooks. Therefore Stckless sould add appropriate calls of PySys_Audit() to relevant C-functions (mostly __reduce__() and __setstate__(), tasklet.frame, tasklet.cstate, cstack.\_\_str\_\_, cstack.startaddr, cframe.*, ).

    C-Python Hooks to be considered

    • code.__new__
    • sys._current_frames
    • sys._getframe
    • sys.set_asyncgen_hooks_finalizer
    • sys.set_asyncgen_hooks_firstiter

    Stackless already creates the events sys.setprofile and sys.settrace

    enhancement task stackless python main-slp 3.8-slp 
    opened by akruis 4
  • Upstream fix for bpo-39606 breaks Stackless test case test_pickle.TestAsyncGenAThrowPickling

    Upstream fix for bpo-39606 breaks Stackless test case test_pickle.TestAsyncGenAThrowPickling

    Commit 925dc7fb1d0 (branch main) / 8dbdf5f275 (branch 3.8) breaks test_pickle.TestAsyncGenAThrowPickling. The test fails with AssertionError: Tuples differ: ((ZeroDivisionError('bla bla'),), 2, True) != ((ZeroDivisionError('bla bla'),), 1, True). The difference is the direct effect of the upstream change.

    The fix is trivial.

    For now I can apply the fix to branch 3.8-slp. To apply it to branch main-slp, upstream commit 925dc7fb1d0 needs to be merged first.

    bug stackless python trivial main-slp 3.8-slp 
    opened by akruis 1
  • Replace Stackless hard switching with libteatet

    Replace Stackless hard switching with libteatet

    This is the historical patch for issue #10 from Kristján Valur Jónsson.

    I converted this patch from a backup of the original mercurial repository available from https://bitbucket-archive.softwareheritage.org/projects/kr/krisvale/stackless-tealet.html.

    enhancement stackless python 2.7-slp 
    opened by akruis 1
Owner
Stackless Python
Development of Stackless Python
Stackless Python
A faster and highly-compatible implementation of the Python programming language. The code here is out of date, please follow our blog

Pyston is a faster and highly-compatible implementation of the Python programming language. Version 2 is currently closed source, but you can find the

null 4.9k Dec 21, 2022
A faster and highly-compatible implementation of the Python programming language.

Pyston Pyston is a fork of CPython 3.8.8 with additional optimizations for performance. It is targeted at large real-world applications such as web se

null 2.3k Jan 9, 2023
Python for .NET is a package that gives Python programmers nearly seamless integration with the .NET Common Language Runtime (CLR) and provides a powerful application scripting tool for .NET developers.

pythonnet - Python.NET Python.NET is a package that gives Python programmers nearly seamless integration with the .NET Common Language Runtime (CLR) a

null 3.5k Jan 6, 2023
DO NOT USE. Implementation of Python 3.x for .NET Framework that is built on top of the Dynamic Language Runtime.

IronPython 3 IronPython3 is NOT ready for use yet. There is still much that needs to be done to support Python 3.x. We are working on it, albeit slowl

IronLanguages 2k Dec 30, 2022
x2 - a miniminalistic, open-source language created by iiPython

x2 is a miniminalistic, open-source language created by iiPython, inspired by x86 assembly and batch. It is a high-level programming language with low-level, easy-to-remember syntaxes, similar to x86 assembly.

Benjamin 3 Jul 29, 2022
An implementation of Python in Common Lisp

CLPython - an implementation of Python in Common Lisp CLPython is an open-source implementation of Python written in Common Lisp. With CLPython you ca

Willem Broekema 339 Jan 4, 2023
Grumpy is a Python to Go source code transcompiler and runtime.

Grumpy: Go running Python Overview Grumpy is a Python to Go source code transcompiler and runtime that is intended to be a near drop-in replacement fo

Google 10.6k Dec 24, 2022
MicroPython - a lean and efficient Python implementation for microcontrollers and constrained systems

The MicroPython project This is the MicroPython project, which aims to put an implementation of Python 3.x on microcontrollers and small embedded syst

MicroPython 15.7k Dec 31, 2022
x86-64 assembler embedded in Python

Portable Efficient Assembly Code-generator in Higher-level Python (PeachPy) PeachPy is a Python framework for writing high-performance assembly kernel

Marat Dukhan 1.7k Jan 3, 2023
Pyjion - A JIT for Python based upon CoreCLR

Pyjion Designing a JIT API for CPython A note on development Development has moved to https://github.com/tonybaloney/Pyjion FAQ What are the goals of

Microsoft 1.6k Dec 30, 2022
A mini implementation of python library.

minipy author = RQDYSGN date = 2021.10.11 version = 0.2 1. 简介 基于python3.7环境,通过py原生库和leetcode上的一些习题构建的超小型py lib。 2. 环境 Python 3.7 2. 结构 ${project_name}

RQDYGSN 2 Oct 26, 2021
Rust syntax and lexical analyzer implemented in Python.

Rust Scanner Rust syntax and lexical analyzer implemented in Python. This project was made for the Programming Languages class at ESPOL (SOFG1009). Me

Joangie Marquez 0 Jul 3, 2022
Core Python libraries ported to MicroPython

This is a repository of libraries designed to be useful for writing MicroPython applications.

MicroPython 1.8k Jan 7, 2023
A programming language built on top of Python to easily allow Swahili speakers to get started with programming without ever knowing English

pyswahili A programming language built over Python to easily allow swahili speakers to get started with programming without ever knowing english pyswa

Jordan Kalebu 72 Dec 15, 2022
Advent of Code is an Advent calendar of small programming puzzles for a variety of skill sets and skill levels that can be solved in any programming language you like.

Advent Of Code 2021 - Python English Advent of Code is an Advent calendar of small programming puzzles for a variety of skill sets and skill levels th

Coral Izquierdo Muñiz 2 Jan 9, 2022
Rick Astley Language is a rick roll oriented, dynamic, strong, esoteric programming language.

Rick Roll Language / Rick Astley Language A rick roll oriented, dynamic, strong, esoteric programming language. Prolegomenon The reasons that I made t

Rick Roll Programming Language 658 Jan 9, 2023
PyGo custom language, New but similar language programming

New but similar language programming. Now we are capable to program in a very similar language to Python but at the same time get the efficiency of Go.

Fernando Perez 4 Nov 19, 2022
NL. The natural language programming language.

NL A Natural-Language programming language. Built using Codex. A few examples are inside the nl_projects directory. How it works Write any code in pur

null 2 Jan 17, 2022
pygame is a Free and Open Source python programming language library for making multimedia applications like games built on top of the excellent SDL library. C, Python, Native, OpenGL.

pygame is a Free and Open Source python programming language library for making multimedia applications like games built on top of the excellent SDL library. C, Python, Native, OpenGL.

pygame 5.6k Jan 1, 2023