Git Product home page Git Product logo

ouroboros's Introduction

https://beeware.org/project/projects/libraries/ouroboros/ouroboros.png

Ouroboros

py-version pypi-version pypi-status license build-status discord

A standalone, pure Python implementation of the Python Standard Library. This library targets Python versions 3.3 and above.

Documentation

Documentation for Ouroboros can be found on Read The Docs.

Community

Ouroboros is part of the BeeWare suite. You can talk to the community through:

We foster a welcoming and respectful community as described in our BeeWare Community Code of Conduct.

Contributing

If you experience problems with Ouroboros, log them on GitHub. If you want to contribute code, please fork the code and submit a pull request.

We also have detailed instructions on how to setup a development environment and run tests.

ouroboros's People

Contributors

amjith avatar aphkyle avatar degustaf avatar freakboy3742 avatar glasnt avatar idan avatar illandan avatar jacebrowning avatar mmchugh avatar therealphildini avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

ouroboros's Issues

Describe how to use ouroboros library on different python implementation

Several projects would potentially benefit from this effort:

  • micropython
  • pypy
  • rustpython
  • ironpython
  • brython
  • jython
  • grumpy
  • cpython

To be of benefit to those projects, it should be clear how the files are organized.

Some suggestions:

  • Describe in the documentation page how to use the standard library on top of a custom python implementation.
  • Split the source directory into several source directories. For example entirely-python with the python only modules. Another folder half-python with modules consisting of a python part and a low level-underscore-prefixed part. Maybe it is an idea to structure the standard library such that language implementors can copy paste the pieces they want, and implement other parts themselves.

math module

It looks like there is no pure Python implementation of the math module -- even PyPy calls out to C for this.

This is a big task, and I've already started going down this rabbit hole, by basically translating the BSD libc math library sources into Python. It is tedious, and will be slower than a native implementation, but should be self-contained.

Ouroboros should be able to run the Python test suite

This ticket is really more of an "epic", to borrow an agile term.

We should get Ouroboros to the point where the stdlib parts of the cpython test suite can run against Ouroboros. This might mean borrowing stdlib implementations from other python implementations.

Updating containers on private repositories always use latest tag

I have a couple of containers being maintained on private repository (2 instances of the same application, one for dev, one for production) however, i just logged into the host machine to find both the containers are running on the latest tag where as they should both me on master and the branch that i am currently developing on. These images are stored on a GitLab Registry.

Is this a bug or by design?

Wrong documentation link?

If I follow the link that README.rst gives for the documentation it says

Ouroboros is a simple wrapper for the eventstore management APIs, designed for managing permissions on streams. It is not a fully-featured eventstore client.

which sounds like something very different to the "A standalone, pure Python implementation of the Python Standard Library." that README.rst describes.

Project status?

Is this project alive? The fact that the last commit was more than a year ago doesn't look very good...

[GSoC] Testing Framework: Compliance Suite and Tool for Disabling Problematic Tests

Table of Content

  1. Intro: 1.1 Intro, 1.2 Goals, 1.3 Benefits
  2. Schedule and Process
  3. Risk Analysis

1. Intro:

For my GSoC 2018 project I would like to contribute to Ouroboros by resolving the issues it's been having with Pythons test suite. Ouroboros is currently unable to run CPython’s test suite and therefore is allowing many unknown issues to arise. A number of problems also currently occur when running tests on certain operating systems (e.g IOS and Android).

1.2 Goals:

  • The ability to test the compliance of the Ouroboros library.

  • Full platform support for IOS

  • A list of features that must be implemented in order for the Ouroboros library to be compliant with a standard Python installation.

  • A list of tests that cause errors to arise on certain platforms and a tool to disable the tests that are flagged for the platform on which it is running.

  • Port some pure Python implementations from other repositories

  • Integrate updated library into batavia

1.3 Benefits

Testing support across platforms will help the PyBee project’s goal of a unified codebase. VOC and Bratavia users have been reporting issues regarding this problem so other PyBee projects will benefit from this fix. Gathering a list of features that must be implemented in order to make Ouroboros feature complete would give contributors a solid roadmap and encourage developers to undertake some of the smaller tasks.

2. Schedule and Process

Week 1

I will designate the first week to doing a preliminary analysis. During this week I will compile a list of reported errors related to the ouroboros, run small tests using the library over IOS and Batavia, and get comfortable testing across a variety of emulated platforms.

Week 1: Setup development environments on every platform.

Goals

  • Becoming comfortable with variety of testing tools and environments.
  • Ensuring I have the appropriate environment setup to maximize the efficiency of the project.

Week 2 - 4

Currently, Ouroboros is lacking a complete implementation of CPython’s test package.

Over weeks 2,3 and 4 I will begin extensive analysis of which Ouroboros features will need to be implemented so we can get the library to a point where it can run every one of these tests. This task may be a long process given the size of Python's library. I will import the full CPython test suite and run it to make a comprehensive list of errors.

Week 2: Import Cpython test package. Import run_tests.py. I will need disable some of the regression tests that call non primitive CPython elements and other functions that are not supported. I will create a function to quickly re-enable these tests once a contribution has been made. This may take up to a week.
I have created a list of regression tests that are yet to be integrated into the Ouroboros test package: https://docs.google.com/document/d/1BBSfDbnIHp0eGL1FSz5GL4p7UBSocQTidN4EDZMDaiU/edit?usp=sharing
Week 3+4: I will clearly document every external dependency the library currently has. Hopefully through this, it will give a baseline to reference for any future users of the library. This may take up to two weeks.
With the independent elements, I will test their coverage within the CPython library and use that information to create list of needed implementations in order of priority.

Goals

  • Import cpython/Lib/test/ in its entirety.
  • Import cpython/Tools/scripts/run_tests.py
  • Modify CPython’s test suite to get it running with Ouroboros in its current state.

Week 5-8

From week 5 to 8, I will create modify run_tests.py so that it can read a list of known platform specific errors that are specified in a config file. I will add in a line that identifies the operating system and then modify the script to skip the tests specific to that platform.

Once this tool is created I will continue to expand the list of known errors by executing trial and error tests.

Week 5: Create mechanism for disabling tests. Add known failures to config file. Research any reported errors from PyBee and outside projects that outline errors related to the platform on which it is running. Document failures.
Week 6+7: Run trial and error tests on IOS i.e Run test suite and compile list of android specific failures. Use most recent version of Android. Once list is completed, perform repeat these tests on earlier versions.
Week 8: Repeat this process on Android.

Goals

  • Modify run_tests.py to get it working with Ouroboros.
  • Expand list of known platform specific errors on IOS and Android

Week 9-12

By this stage I will have a list of needed CPython implementations and will be able to mark the priority of each needed implementation. For week 7 I will audit PyPy for pure python implementations and look for any other projects from which I can import code without encountering license issues. I wrote a python tool for checking matching filenames in github repositories so this may come in useful for this stage of the project. For the final week I will integrate the updated Ouroboros library into Batavia. This will require enabling some of the regression tests that were previously disabled and running run_tests.py in order to check the library's compliance with a normal installation of CPython.

Reference: https://bitbucket.org/pypy/pypy/src/f65cb735be28/lib_pypy/?at=default

Week 9+10: Analyse other repositories (e.g PyPy) to create list of valuable files they have that we could port over to Ouroboros. Import these files over and ensure they are fully functional within Ouroboros.
Week 11: Enabling the tests from test that were previously disabled due to their absence in this project and re-testing on other platforms.
Week 12: Integrate updated library into Batavia.

Goals

  • Expand the Ouroboros library by importing code from outside sources.
  • Enable Batavia support for updated library

3. Risk Analysis

---Note---
Having not yet completed my module in Software Testing at university, I am aware that there may be some risks that I may not yet be aware of. However, I will have completed this module by the time GSoC starts and I also intend on independently studying this area thoroughly to prepare for this project. Given that I will be committing 45-50+ hours a week to this I am quite confident that I will have a good chance of overcoming any problems that I run into.
----------

  • Importing the CPython test suite is sure to cause a huge number of errors. A preliminary analysis will give me of good idea of where to start when undertaking this task.

  • Depending on the number of OS specific errors that arise, the test disabling tool could prove to be a relatively slow program. It may take time to optimize this feature.

  • Changes to the CPython code could result in side effects that take time to correct. When it comes to this stage, a test driven development will be important to maintain efficiency.

  • Finding failures through trial and error is quite a general task. It will be important to set requirements for myself at this stage to keep on schedule.

  • Importing from outside libraries may cause unforeseen errors. It will be important to review the documentation on the repositories from which I am taking, check licenses, and look at any related issues that have been reported.

Typo in LICENSE

  1. By copying, installing or otherwise using Python, Licensee

might be an extra e of the end there?

Threading/Forking Servers

Its better if ouroboros has

  • ThreadingHTTPServer
  • ForkingHTTPServer
  • ThreadingWSGIServer
  • ForkingWSGIServer

Threading servers handles each request on thread.
Forking servers handles each request on new process.
They are useful. But not provided by stdlib.
Many external server frameworks are providing them.

I can add these servers with few lines.
Can i make a pr

Fix readmes

^^
as the title says,
because the community moved from gitter to discord, the readme should change as well.

Mine MicroPython lib for potential treasure

The idea here was to mine the library for MicroPython to see if there were libraries that are done in cpython typically, but may have been redone in Python itself for this distribution. Observations are broken in two groups:

  1. Files that appear in MicroPython and not Ouroboros
  2. Files that are common between the two
    -- The bottom line is for the majority of overlap the Ouroboros libraries are arguably most complete. For anything that exists in MicroPython only there is some overlap (due to 'u' micro versions.)

Files that appear in micropython, but do not appear in Ouroboros currently.
binascii/binascii.py #imports from ubinascii
bisect/bisect.py #defines:
insort_right
insort
bisect_right
bisect
insort_left
bisect_left
collections.defaultdict/collections/defaultdict.py #standalone defines defaultdict
collections.dequeu/collections/deque.py #standalone defines deque
cpython-uayncio/uasyncio.py #imports from asyncio
errno/errno.py #defines a number of statics
fnctl/fnctl.py #loads ffilib ffilib.libc()
fflib/fflib.py #loads libc
hashlib/hashlib/_sha224.py #imports from _sha256
hashlib/hashlib/_sha256.py #standalone
hashlib/hashlib/_sha384.py #imports from _sha512
hashlib/hashlib/_sha512.py #standalone
machine/machine/init.py #imports from umachine
machine/machine/pin.py #imports umachine
machine/machine/timer.py #uses ffilib ffilib.open("librt")
pkg_resources/pkg_resources.py #imports from uio
pwd/pwd.py #uses ffilib ffilib.libc()
pyb/pyb.py #defines a single simple class
pystone/pystone.py #mostly standalone
pystone_lowmem/pystone_lowmem.py #mostly standalone
re-pcre/re.py #uses ffilib ffilib.open("libpcre")
sdist_upip.py #defines alternate pip
select/select.py #uses ffilib ffilib.libc()
signal/signal.py #uses ffilib ffilib.libc() not much here
sqlite3/sqlite3.py #uses ffilib ffilib.open("libsqlite3")
time/time.py #uses ffilib ffilib.libc()
uaiohttpclient/uaiohttpclient.py #imports from uasyncio
uasyncio/uasyncio/init.py #skipped
uasyncio.core/uasyncio/core.py #skipped
uasyncio.queues/uasyncio/queues.py #skipped
uasyncio.synchro/uasyncio/synchro.py #skipped
uasyncio.udp/uasyncio/udp.py #skipped
uasyncio.websocket.server/uasyncio/websocket/server.py #skipped
ucontextlib/tests.py #skipped
ucontextlib/ucontextlib.py #skipped
ucurses/ucurses/init.py #skipped
udnspkt/udnspkt.py #imports uio defines a few methods
umqtt.robust/umqtt/robust.py #defines a few simple functions
umqtt.simple/umqtt/simple.py #imports from usocket ustruct and ubinascii
unicodedata/unicodedata.py #ignore this. Two one line methods
upip/upip.py #makes an alternate pip
upip/upip_utarfile.py #mostly standalone
upysh/upysh.py #defines a new method that essentially wraps os
urllib.urequests/urequests.py #imports from usocket. Defines a simple urlopen
utarfile/utarfile.py #mostly standalone defines a Tar class
uu/uu.py #standalone
xmltok/xmltok.py #standalone

The idea here from now on is the files from the Ouroboros code are on the left. If an exact file name match was found in MicroPython then it is the next file (in a list). The comments about the files follow. A blank line repeats the whole process. The bottom line is in all cases where there is a current implementation of foo in Ouroboros it is probably better to keep the existing implementation.

./future.py ['./future/future.py']
These files are massively different with the Ouroboros file being much more complete.
The micropython file defines 7 booleans:
nested_scopes = True
generators = True
division = True
absolute_import = True
with_statement = True
print_function = True
unicode_literals = True
The Ouroboros defines the same names. There are many other constants defined. There is also a class names _Feature defined.

./init.py ['./collections/collections/init.py', './concurrent.futures/concurrent/futures/init.py', './hashlib/hashlib/init.py', './html/html/init.py', './json/json/init.py', './machine/machine/init.py', './os/os/init.py', './uasyncio/uasyncio/init.py', './ucurses/ucurses/init.py']
No file to match on the micropython side

./_markupbase.py ['./_markupbase/_markupbase.py']
These two files are the same

./abc.py ['./abc/abc.py']
--These files are massively different with the Ouroboros file being much more complete. The micropython file is basically a stub.
--The micropython defines a function called abstractmethod which returns the input to abstractmethod.
--The Ouroboros functions:
abstractmethod
get_cache_token
--The Ouroboros classes:
abstractclassmethod
abstractstaticmethod
abstractproperty
ABCMeta
ABC

./argparse.py ['./argparse/argparse.py']
--There are a lot of differences between these two files. A lot less is imported on the micropython side. The docstring on the micro python side:
Minimal and functional version of CPython's argparse module
--Micropython high level definitions:
class _ArgError(BaseException):
class _Arg:
def _dest_from_optnames(opt_names):
class ArgumentParser:

--Ouroboros high level definitions:
class _AttributeHolder(object):
def _ensure_value(namespace, name, value):
class HelpFormatter(object):
class RawDescriptionHelpFormatter(HelpFormatter):
class RawTextHelpFormatter(RawDescriptionHelpFormatter):
class ArgumentDefaultsHelpFormatter(HelpFormatter):
class MetavarTypeHelpFormatter(HelpFormatter):
def _get_action_name(argument):
class ArgumentError(Exception):
class ArgumentTypeError(Exception):
class Action(_AttributeHolder):
class _StoreAction(Action):
class _StoreConstAction(Action):
class _StoreTrueAction(_StoreConstAction):
class _StoreFalseAction(_StoreConstAction):
class _AppendAction(Action):
class _AppendConstAction(Action):
class _CountAction(Action):
class _HelpAction(Action):
class _VersionAction(Action):
class _SubParsersAction(Action):
class FileType(object):
class Namespace(_AttributeHolder):
class _ActionsContainer(object):
class _ArgumentGroup(_ActionsContainer):
class _MutuallyExclusiveGroup(_ArgumentGroup):
class ArgumentParser(_AttributeHolder, _ActionsContainer):

./asyncio ['./asyncio']

./asyncio/init.py ['./uasyncio/uasyncio/init.py']
--These files are different. The Ouroboros file only imports a lot of other modules. The micropython file does much fewer imports and defines the following classes:
PollEventLoop
StreamReader
StreamWriter
--The micropython file also defines the following functions:
open_connection
start_server

./asyncio/queues.py ['./uasyncio.queues/uasyncio/queues.py']
There are differences in the two files, with the Ouroboros file being more robust in certain methods. It looks like they try to employ the same basic abilities.

./base64.py ['./base64/base64.py']
--These files look similar and define the same methods. The micropython impementation is not quite as complete though. For example in the urlsafe_b64encode and urlsafe_b64decode it raises a NotImplementedError()
--Ascii85 encoding/decoding is not present on the micropython file.

./binhex.py ['./binhex/binhex.py']
--The file exists in the micropython side, but the file is completely empty. The comment on github said they implemented a dummy file.

./bisect.py ['./bisect/bisect.py']
The two files are the same.

./calendar.py ['./calendar/calendar.py']
The file exists in micropython, but is completely empty.

./cgi.py ['./cgi/cgi.py']
These two files are largely the same. It looks like the micorpython side simply has a bit less error checking.

./cmd.py ['./cmd/cmd.py']
--These two files are largely the same. The micropython side purposely removes some functionality and that is documented:
This is a copy of python's Cmd, but leaves out features that aren't relevant
or can't currently be implemented for MicroPython.

One of the notable deviations is that since MicroPython strips doc strings,
this means that that help by doc string feature doesn't work.

./code.py ['./code/code.py']
This file is an empty stub on the micropython side.

./codecs.py ['./codecs/codecs.py']
This file is an empty stub on the micropython side.

./codeop.py ['./codeop/codeop.py']
This file is an empty stub on the micropython side.

./collections/init.py ['./collections/collections/init.py']
--There are major changes here with the micropython file deliberately being incomplete. From the comments:

Should be reimplemented for MicroPython

Reason:

CPython implementation brings in metaclasses and other bloat.

This is going to be just import-all for other modules in a namespace package

./concurrent ['./concurrent.futures/concurrent']

./concurrent/init.py ['./concurrent.futures/concurrent/futures/init.py']
The micropython file is empty and the Ouroboros one is a single comment.

./concurrent/futures ['./concurrent.futures/concurrent/futures']

./concurrent/futures/init.py ['./concurrent.futures/concurrent/futures/init.py']
The micropython file is empty and the Ouroboros file simply does a few imports.

./contextlib.py ['./contextlib/contextlib.py']
The layout of the two files is largely the same. The Ouroboros file is more complete. Ouroboros also implements redirect_stdout which does not exist in micropython.

./copy.py ['./copy/copy.py']
--The micropython implementation is intentionally less complete. micropython removes support for bytes and frozenset for example.

./csv.py ['./csv/csv.py']
--This file is an empty stub on the micropython side.

./curses/init.py ['./ucurses/ucurses/init.py']
--Micropython has an implementation for curses and ucurses. There is no init.py for curses however in the micropython side. Ouroboros does not include ucurses at all.

./curses/ascii.py ['./curses.ascii/curses/ascii.py']
These files are the same

./datetime.py ['./datetime/datetime.py']
These two files are largely the same. The Ouroboros implementation looks to be a bit more complete. For example _divide_and_round does not exist in micropython.

./dbm ['./dbm']
DBM is a dummy implementation in micropython.

./decimal.py ['./decimal/decimal.py']
This is a blank dummy stub in micropython

./difflib.py ['./difflib/difflib.py']
This is a blank dummy stub in micropython

./email ['./email.charset/email', './email.encoders/email', './email.errors/email', './email.feedparser/email', './email.header/email', './email.internal/email', './email.message/email', './email.parser/email', './email.utils/email']
The whole implementation for email in general seems to be stripped down in micropython.

./email/_encoded_words.py ['./email.internal/email/_encoded_words.py']
The two files are the same except for a single character in a comment.

./email/_parseaddr.py ['./email.internal/email/_parseaddr.py']
The two files are the same

./email/_policybase.py ['./email.internal/email/_policybase.py']
The two files are essentially the same. There are two differences:

  1. for _extend_docstrings micropython returns immediately:
    def _extend_docstrings(cls):
    return cls

  2. For the class Policy it no longer defines a metaclass:
    class Policy(_PolicyBase):#, metaclass=abc.ABCMeta):

./email/base64mime.py ['./email.encoders/email/base64mime.py']
The two files are the same

./email/charset.py ['./email.charset/email/charset.py']
These two files are nearly identical. There is a comment on the micropython side noting something that should be done later:
# Note that this clause doesn't handle the case of a _payload that
# is already bytes. It never did, and the semantics of _payload
# being bytes has never been nailed down, so fixing that is a
# longer term TODO.

./email/encoders.py ['./email.encoders/email/encoders.py']
These two files are largely the same, but there is more error checking on the micropython side.

./email/errors.py ['./email.errors/email/errors.py']
These two files are the same except the definition of one class. It does not extend the TypeError class:
class MultipartConversionError(MessageError):#, TypeError):
"""Conversion to a multipart is prohibited."""

./email/feedparser.py ['./email.feedparser/email/feedparser.py']
There are minor differences in the files between the two. It looks like there are a couple more checks on the micropython side.

./email/header.py ['./email.header/email/header.py']
These two files are essentially the same. Micropython imports sys twice later in the code for some unknown reason.

./email/iterators.py ['./email.message/email/iterators.py']
These two files are essentially identical.

./email/message.py ['./email.message/email/message.py']
There are differences between the two files here, but they have largely the exact same structure. It appears the Ouroboros side looks to do more error checking.

./email/mime/message.py ['./email.message/email/message.py']
--There are massive changes between the two files here. Based on the copyright string the micropython implementation is a year newer and is more complete.

./email/parser.py ['./email.parser/email/parser.py']
--These two files are largely the same with a couple of minor differences. The Ouroboros file has a little more error checking.

./email/quoprimime.py ['./email.encoders/email/quoprimime.py']
--These two files have the same layout and try to provide the same functionality. It looks like the Ouroboros file does more error checking.

./email/utils.py ['./email.utils/email/utils.py']
--These two files have the same layout and try to provide the same functionality. The Ouroboros file has a bit more error checking

./fnmatch.py ['./fnmatch/fnmatch.py']
--These two files have the same layout and try to provide the same functionality. The Ouroboros file has a bit more error checking

./formatter.py ['./formatter/formatter.py']
This file is an empty stub in micropython

./fractions.py ['./fractions/fractions.py']
This file is an empty stub in micropython

./ftplib.py ['./ftplib/ftplib.py']
This file is an empty stub in micropython

./functools.py ['./functools/functools.py']
The micropython implementation is largely a dummy implementation.

./getopt.py ['./getopt/getopt.py']
--The files are the same with the exception of a one character change in the comments.

./getpass.py ['./getpass/getpass.py']
--This file is an empty stub in micropython

./gettext.py ['./gettext/gettext.py']
--These files are majorly different. The micropython implementation is essentially a stub.

./glob.py ['./glob/glob.py']
--The two files have the same layout and implementation. Mostly minor differences, but doesn't appear to be functional. Ouroboros implementation also had an escape method.

./gzip.py ['./gzip/gzip.py']
There are major differences here and the Ouroborus implementation is much more complete.

./heapq.py ['./heapq/heapq.py']
The layout and functionality here is mostly the same. The largest differences is a bunch of imports are only done if certain functions are run instead of all the time.

./hmac.py ['./hmac/hmac.py']
There are minor differences between the files, but they look to be functionally equivalent.

./html ['./html', './html/html', './html.entities/html', './html.parser/html']

./html/init.py ['./html/html/init.py']
The same functions are defined in both files, but the Ouroboros file looks to be more complete.

./html/entities.py ['./html.entities/html/entities.py']
--These two files are functionally the same. Minor spelling differences in the comments.

./html/parser.py ['./html.parser/html/parser.py']
--These two files define the same functionality. The unescape function is purposely removed in the Ouroboros copy. There are extra checks throughout the file in the Ouroboros copy.

./http ['./http.client/http']

./http/client.py ['./http.client/http/client.py']
--The two files try to implement all of the same endpoints. The Ouroboros file looks to have more error checking throughout.

./imaplib.py ['./imaplib/imaplib.py']
--The micropython file is an empty dummy file.

./imp.py ['./imp/imp.py']
--The micropython file is an empty dummy file.

./importlib ['./importlib']

./inspect.py ['./inspect/inspect.py']
--The micropython copy is incomplete in comparison. Certain functions are deliberately not implemented.

./io.py ['./io/io.py']
--The Ouroboros file is much more complete and defines many things not in micropython.

./ipaddress.py ['./ipaddress/ipaddress.py']
--This file is an empty stub in micropython

./itertools.py ['./itertools/itertools.py']
--There are a number of differences in the two files. For the same method in some instances they are implemented in two different ways. The Ouroboros file is more complete. For example it includes a method for zip_longest while micropython does not.

./json ['./json', './json/json']

./json/init.py ['./json/json/init.py']
--There are a few changes between the files. Some of the defaults into a function are the opposite between the two files. The same endpoints are defined, but it seems that micropython forcefully tries to make more compact json representations.

./json/decoder.py ['./json/json/decoder.py']
--There are some differences here such as micropython does not implement _decode_uXXXX. Instead that same functionality is defined inline in a different method. Overall it looks like they provide the same functionality.

./json/encoder.py ['./json/json/encoder.py']
--There are a number of differences between the two files. It looks like most of the differences though are more complete error checking in the Ouroboros definition.

./json/scanner.py ['./json/json/scanner.py']
--These two files are the same with two minor changes when an exception is raised.

./json/tool.py ['./json/json/tool.py']
--These files are the same except in one instance micropython includes an extra parameter by default to json.dump.

./keyword.py ['./keyword/keyword.py']
--There are changes between the two files in several places, but it looks like they mostly try to achieve the same functionality.

./linecache.py ['./linecache/linecache.py']
--The micropython implementation is a single line definition for the cache. Ouroboros is more complete.

./locale.py ['./locale/locale.py']
--The Ouroboros file tries to determine the locale. Micropython on the other hand says screw it everything is UTF-8

./logging ['./logging']

./mailbox.py ['./mailbox/mailbox.py']
-- This is an empty stub file in micropython

./mailcap.py ['./mailcap/mailcap.py']
-- This is an empty stub file in micropython

./mimetypes.py ['./mimetypes/mimetypes.py']
-- This is an empty stub file in micropython

./multiprocessing ['./multiprocessing']

./nntplib.py ['./nntplib/nntplib.py']
-- This is an empty stub file in micropython

./numbers.py ['./numbers/numbers.py']
-- This is an empty stub file in micropython

./operator.py ['./operator/operator.py']
--The Ouroboros file is much more complete here and defines a number of methods not present in micropython

./optparse.py ['./optparse/optparse.py']
-- This is an empty stub file in micropython

./pathlib.py ['./pathlib/pathlib.py']
-- This is an empty stub file in micropython

./pdb.py ['./pdb/pdb.py']
-- This is an empty stub file in micropython

./pickle.py ['./pickle/pickle.py']
--Micropython implements a fake pickle which looks trivial and has no error checking.

./pickletools.py ['./pickletools/pickletools.py']
-- This is an empty stub file in micropython

./pkgutil.py ['./pkgutil/pkgutil.py']
--The package file very short and has no error checking. The Ouroboros is much more complete.

./platform.py ['./platform/platform.py']
-- This is an empty stub file in micropython

./poplib.py ['./poplib/poplib.py']
-- This is an empty stub file in micropython

./posixpath.py ['./posixpath/posixpath.py']
-- This is an empty stub file in micropython

./pprint.py ['./pprint/pprint.py']
--In micropython this is a stub that simply returns the repr for an object instead of actually doing pprint.

./profile.py ['./profile/profile.py']
-- This is an empty stub file in micropython

./pty.py ['./pty/pty.py']
-- This is an empty stub file in micropython

./queue.py ['./queue/queue.py']
-- This is an empty stub file in micropython

./quopri.py ['./quopri/quopri.py']
--These files are nearly identical. All of the endpoints are the same. There are wording changes in two comments. There is also a change in an exception clause.

./random.py ['./random/random.py']
--The micropython implementation defines a few methods, but they are trivial implementations. The Ouroboros file is much more complete.

./re.py ['./re-pcre/re.py']
--There are major major changes between the two files in this case. In the micropython case an external file is loaded which I do not seem to have a copy of. Therefore it is hard to compare the two fully.

./reprlib.py ['./reprlib/reprlib.py']
-- This is an empty stub file in micropython. I assume this is due to the external file that is read in when re.py is used.

./runpy.py ['./runpy/runpy.py']
-- This is an empty stub file in micropython

./sched.py ['./sched/sched.py']
-- This is an empty stub file in micropython

./selectors.py ['./selectors/selectors.py']
-- This is an empty stub file in micropython

./shelve.py ['./shelve/shelve.py']
-- This is an empty stub file in micropython

./shlex.py ['./shlex/shlex.py']
-- This is an empty stub file in micropython

./shutil.py ['./shutil/shutil.py']
--There are major differences here. There is a comment in the micropython file:

Reimplement, because CPython3.3 impl is rather bloated

Currently only 2 methods are implemented in micropython. Those are rmtree and copyfileobj

./smtplib.py ['./smtplib/smtplib.py']
-- This is an empty stub file in micropython

./socket.py ['./socket/socket.py']
--There are major differences in implementation here. The micropython version looks to be bare bones with no error checking.

./socketserver.py ['./socketserver/socketserver.py']
-- This is an empty stub file in micropython

./sqlite3 ['./sqlite3']

./ssl.py ['./ssl/ssl.py']
--There are major differences in implementation here. The micropython version looks to be bare bones with no error checking.

./stat.py ['./stat/stat.py']
--These two files are nearly identical. The exception is the following at the bottom of the Ouroboros file:

If available, use C implementation

try:
from _stat import *
except ImportError:
pass

./statistics.py ['./statistics/statistics.py']
-- This is an empty stub file in micropython

./string.py ['./string/string.py']
--There are major differences in implementation here. The micropython version looks to be bare bones with no error checking.

./stringprep.py ['./stringprep/stringprep.py']
-- This is an empty stub file in micropython

./struct.py ['./struct/struct.py']
--I haven't gone through all of the supporting files, but micropython imports from ustruct. Ouroboros on the other hand imports from _struct

./subprocess.py ['./subprocess/subprocess.py']
-- This is an empty stub file in micropython

./tarfile.py ['./tarfile/tarfile.py']
-- This is an empty stub file in micropython

./telnetlib.py ['./telnetlib/telnetlib.py']
-- This is an empty stub file in micropython

./tempfile.py ['./tempfile/tempfile.py']
-- This is an empty stub file in micropython

./test ['./test', './test.pystone/test', './test.support/test']

./test/pystone.py ['./test.pystone/test/pystone.py']
--These two files are identical with the exception of a one character comment

./test/test_argparse.py ['./argparse/test_argparse.py']
--There are massive differences between the two files. This is probably explained by the stripped down implementation of the code it tests

./test/test_base64.py ['./base64/test_base64.py']
--There are massive differences between the two files. This is probably explained by the stripped down implementation of the code it tests

./test/test_binascii.py ['./binascii/test_binascii.py']
--There are massive differences between the two files. This is probably explained by the stripped down implementation of the code it tests

./test/test_datetime.py ['./datetime/test_datetime.py']
--There are massive differences between the two files. This is probably explained by the stripped down implementation of the code it tests

./test/test_defaultdict.py ['./collections.defaultdict/test_defaultdict.py']
--There are massive differences between the two files. This is probably explained by the stripped down implementation of the code it tests

./test/test_fnmatch.py ['./fnmatch/test_fnmatch.py']
--There are only minor changes between the two files. One example is a method that is commented out due to not being implemented.

./test/test_gettext.py ['./gettext/test_gettext.py']
--There are massive differences between the two files. This is probably explained by the stripped down implementation of the code it tests

./test/test_glob.py ['./glob/test_glob.py']
--There are minor differences between the files. This is mostly due to tests being skipped in micropython since they are not supported.

./test/test_hashlib.py ['./hashlib/test_hashlib.py']
--There are major differences in the test run between the two files.

./test/test_heapq.py ['./heapq/test_heapq.py']
--There are major differences between the files. This is mostly due to tests being skipped in micropython since they are not supported.

./test/test_hmac.py ['./hmac/test_hmac.py']
--There are major differences in the test run between the two files.

./test/test_importlib/import_/test_path.py ['./os.path/test_path.py']
--There are major differences between the files. Ouroboros has a lot more checks.

./test/test_itertools.py ['./itertools/test_itertools.py']
--There are major differences between the files. This is mostly due to tests being skipped in micropython since they are not supported.

./test/test_operator.py ['./operator/test_operator.py']
--There are major differences between the files. Ouroboros has a lot more checks.

./test/test_pep380.py ['./test/test_pep380.py']
--There are minor differences in the tests. For example one import is commented out in micropython. The other changes seem to be due to things that are not supported in micropython:

MicroPython doesn't support nested exceptions

MicroPython doesn't support assignment to .value

In MicroPython, exceptions is .close() are not ignored/printed to sys.stderr,

but propagated as usual.

@unittest.skip("MicroPython doesn't check for already active generator when resuming it")
@unittest.skip("MicroPython doesn't support inspect.stack()")

./test/test_pickle.py ['./pickle/test_pickle.py']
--There are major differences between the files. This is mostly due to tests being skipped in micropython since they are not supported.

./test/test_quopri.py ['./quopri/test_quopri.py']
--There are only minor differences between the files. Most of the checks are the same

./test/test_re.py ['./re-pcre/test_re.py']
--There are major differences between the files. This is mostly due to tests being skipped in micropython since they I believe they not supported.

./test/test_readline.py ['./uasyncio/test_readline.py']
--There are major differences between the files. Ouroboros has many more checks being done.

./test/test_strftime.py ['./time/test_strftime.py']
--There are major differences between the files. Ouroboros has many more checks being done.

./test/test_unittest.py ['./unittest/test_unittest.py']
--There are major differences between the files. In this case micropython makes many more tests which is typically not the case.

./test/test_urlparse.py ['./urllib.parse/test_urlparse.py']
--There are checks that differ on both sides of this file. Most of the checks appear to be the same, but both have some unique cases.

./test/xmltestdata/test.xml ['./xmltok/test.xml']
--There are major differences between the files. Ouroboros has many more checks being done.

./textwrap.py ['./textwrap/textwrap.py']
These two files are the except minor differences in the comments. There is one more difference which is the else block on line 434 in Ouroboros is not implemented in micropython.

./threading.py ['./threading/threading.py']
--There are major differences between the files. Ouroboros has many more checks being done.

./timeit.py ['./timeit/timeit.py']
--There are some changes between the files, but most of the tests appear to be the same. It looks like in micropython some things may not run since it may be possible to not find itertools

./trace.py ['./trace/trace.py']
--The test file in micropython is an empty stub file.

./traceback.py ['./traceback/traceback.py']
--There are major differences between the files. Ouroboros has many more checks being done.

./tty.py ['./tty/tty.py']
--Micropython only does a single import in the file. Ouroboros implements two other methods.

./types.py ['./types/types.py']
--The Micropython implementation is not as complete due to other missing pieces under the hood. There are things still defined though. For example:
CodeType = None # TODO: Add better sentinel which can't match anything
MappingProxyType = None # TODO: Add better sentinel which can't match anything
SimpleNamespace = None # TODO: Add better sentinel which can't match anything

./unittest ['./unittest']

./urllib ['./urllib', './urllib.parse/urllib', './urllib.urequest/urllib']

./urllib/parse.py ['./urllib.parse/urllib/parse.py']
--There are minor differences between the files, but they look to be mostly functionally equal. A lot of the differences on both sides seem to be delayed imports or definitions only when a function is run.

./uu.py ['./uu/uu.py']
--The two files are the same.

./uuid.py ['./uuid/uuid.py']
--This is an empty stub file in micropython.

./venv ['./venv']

./warnings.py ['./warnings/warnings.py']
--Micropython has a trivial single method implementation here.

./weakref.py ['./weakref/weakref.py']
--Micropython has a trivial single method implementation here.

./zipfile.py ['./zipfile/zipfile.py']
--This is an empty stub file in micropython.

Low Number of Tests

Currently, there are only two tests–both on cmath–in tests. This isn't nearly enough coverage for all of the Python standard libraries!

Currently unable to run tests

When I try to python setup.py test, I get the following:

SensitiveDependence:ouroboros phildini$ python setup.py test
running test
running egg_info
creating ouroboros.egg-info
writing ouroboros.egg-info/PKG-INFO
writing top-level names to ouroboros.egg-info/top_level.txt
writing dependency_links to ouroboros.egg-info/dependency_links.txt
writing manifest file 'ouroboros.egg-info/SOURCES.txt'
reading manifest file 'ouroboros.egg-info/SOURCES.txt'
reading manifest template 'MANIFEST.in'
warning: no files found matching 'requirements*.txt'
writing manifest file 'ouroboros.egg-info/SOURCES.txt'
running build_ext
Traceback (most recent call last):
  File "setup.py", line 38, in <module>
    test_suite='tests'
  File "/usr/local/Cellar/python/2.7.11/Frameworks/Python.framework/Versions/2.7/lib/python2.7/distutils/core.py", line 151, in setup
    dist.run_commands()
  File "/usr/local/Cellar/python/2.7.11/Frameworks/Python.framework/Versions/2.7/lib/python2.7/distutils/dist.py", line 953, in run_commands
    self.run_command(cmd)
  File "/usr/local/Cellar/python/2.7.11/Frameworks/Python.framework/Versions/2.7/lib/python2.7/distutils/dist.py", line 972, in run_command
    cmd_obj.run()
  File "/usr/local/lib/python2.7/site-packages/setuptools/command/test.py", line 157, in run
    self.with_project_on_sys_path(self.run_tests)
  File "/usr/local/lib/python2.7/site-packages/setuptools/command/test.py", line 138, in with_project_on_sys_path
    func()
  File "/usr/local/lib/python2.7/site-packages/setuptools/command/test.py", line 178, in run_tests
    testRunner=self._resolve_as_ep(self.test_runner),
  File "/usr/local/Cellar/python/2.7.11/Frameworks/Python.framework/Versions/2.7/lib/python2.7/unittest/main.py", line 94, in __init__
    self.parseArgs(argv)
  File "/usr/local/Cellar/python/2.7.11/Frameworks/Python.framework/Versions/2.7/lib/python2.7/unittest/main.py", line 149, in parseArgs
    self.createTests()
  File "/usr/local/Cellar/python/2.7.11/Frameworks/Python.framework/Versions/2.7/lib/python2.7/unittest/main.py", line 158, in createTests
    self.module)
  File "/usr/local/Cellar/python/2.7.11/Frameworks/Python.framework/Versions/2.7/lib/python2.7/unittest/loader.py", line 130, in loadTestsFromNames
    suites = [self.loadTestsFromName(name, module) for name in names]
  File "/usr/local/Cellar/python/2.7.11/Frameworks/Python.framework/Versions/2.7/lib/python2.7/unittest/loader.py", line 103, in loadTestsFromName
    return self.loadTestsFromModule(obj)
  File "/usr/local/lib/python2.7/site-packages/setuptools/command/test.py", line 36, in loadTestsFromModule
    tests.append(self.loadTestsFromName(submodule))
  File "/usr/local/Cellar/python/2.7.11/Frameworks/Python.framework/Versions/2.7/lib/python2.7/unittest/loader.py", line 100, in loadTestsFromName
    parent, obj = obj, getattr(obj, part)
AttributeError: 'module' object has no attribute 'test_cmath'

Looking in the codebase, I don't even see test_cmath referenced anywhere, so I'm not sure what's going on.

requirements_dev.txt

The requirements_dev.txt that is indicated in the instructions the set up the development environment is not included in the repository. Also the init.py containing the version number is missing, and in this case, the pip install -e . command can't work.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.