DO NOT USE. Implementation of Python 3.x for .NET Framework that is built on top of the Dynamic Language Runtime.

Overview

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 slowly. We welcome all those who would like to help!

Official Website

IronPython is an open-source implementation of the Python programming language which is tightly integrated with the .NET Framework. IronPython can use the .NET Framework and Python libraries, and other .NET languages can use Python code just as easily.

What? Where?
Windows/Linux/macOS Builds Build status Github build status
Downloads No releases
Help Gitter chat StackExchange

Comparison of IronPython vs. C# for 'Hello World'

C#:

using System;
class Hello
{
    static void Main() 
    {
        Console.WriteLine("Hello World");
    }
}

IronPython:

print("Hello World")

IronPython 3 targets Python 3, including the re-organized standard library, Unicode strings, and all of the other new features.

Code of Conduct

This project has adopted the code of conduct defined by the Contributor Covenant to clarify expected behavior in our community. For more information see the .NET Foundation Code of Conduct.

Installation

Builds of IronPython 3 are not yet provided.

Build

See the building document

Since the main development is on Windows, Mono bugs may inadvertantly be introduced

  • please report them!

Supported Platforms

IronPython 3 targets .NET Framework 4.6, .NET Core 2.1/3.1 and .NET 5.0. The support for .NET Core and .NET 5 will follow the lifecycle defined on .NET Core and .NET 5 Support Policy.

Comments
  • IronPython 3 should use >= .Net 4.5.1

    IronPython 3 should use >= .Net 4.5.1

    From my point of view, it would be enough if IronPython 3.x only supports .net framework version equal-greater than 4.5.1. This may make the build and test-process more easy.

    opened by simplicbe 27
  • Factor out IPythonBuffer from IBufferProtocol

    Factor out IPythonBuffer from IBufferProtocol

    Here is my exploration around the re-implementation of the buffer protocol (#21). I will try to make incremental changes that will keep IronPython working (so all tests should be passing).

    Each step is a proposal of an idea that can be discussed and adjusted, so smaller steps are preferable, rather a large dive that goes nowhere.

    The PR is writable to the maintainers, so I welcome commits on top in a collaborative effort.

    opened by BCSharp 24
  • Version 3.4.0-beta

    Version 3.4.0-beta

    Things left to do for the release:

    • [x] Release DLR 1.3.2 and bump to nuspec
    • [x] Finish and merge https://github.com/IronLanguages/ironpython3/pull/1417 and https://github.com/IronLanguages/ironpython3/pull/1420
    • [x] Update installer?
    • [x] Document breaking changes related to https://github.com/IronLanguages/ironpython3/issues/52
    • [ ] Prepare release notes (special mentions: f-strings, venv, int/long unification, anything else?)
    • [x] Prepare website update with release info
    • [ ] Testing
    • [ ] Other stuff?

    @BCSharp Any potential PRs you'd like to squeeze in before a release? Can you think of anything else?

    opened by slozier 23
  • macOS:

    macOS: "LookupError: unknown encoding: cp0" when starting ipy

    When starting ipy on MacOS I get LookupError: unknown encoding: cp0.

    I compiled IronPython for Mac from source as I did not find any binary releases for IronPython (homebrew?)

    ➜  ironpython3 git:(35cc2274) ✗ pwsh make.ps1 -frameworks net6.0 debug
    
    ➜  ironpython3 git:(35cc2274) ✗ ./bin/Debug/net6.0/ipy
    Traceback (most recent call last):
      File "<string>", line 1567, in load_module
      File "<string>", line 596, in _load_module_shim
      File "<string>", line 1210, in load
      File "<string>", line 1190, in _load_unlocked
      File "<string>", line 1119, in _exec
      File "<string>", line 1461, in exec_module
      File "<string>", line 539, in _check_name_wrapper
      File "<string>", line 321, in _call_with_frames_removed
      File "/Users/sascha/Dev/ironpython3/bin/Debug/net6.0/../../../Src/StdLib/Lib/site.py", line 564, in <module>
      File "/Users/sascha/Dev/ironpython3/bin/Debug/net6.0/../../../Src/StdLib/Lib/site.py", line 550, in main
      File "/Users/sascha/Dev/ironpython3/bin/Debug/net6.0/../../../Src/StdLib/Lib/site.py", line 281, in addusersitepackages
      File "/Users/sascha/Dev/ironpython3/bin/Debug/net6.0/../../../Src/StdLib/Lib/site.py", line 257, in getusersitepackages
      File "/Users/sascha/Dev/ironpython3/bin/Debug/net6.0/../../../Src/StdLib/Lib/site.py", line 247, in getuserbase
      File "/Users/sascha/Dev/ironpython3/Src/StdLib/Lib/sysconfig.py", line 595, in get_config_var
      File "/Users/sascha/Dev/ironpython3/Src/StdLib/Lib/sysconfig.py", line 575, in get_config_vars
      File "/Users/sascha/Dev/ironpython3/Src/StdLib/Lib/_osx_support.py", line 393, in customize_config_vars
      File "/Users/sascha/Dev/ironpython3/Src/StdLib/Lib/_osx_support.py", line 135, in _supports_universal_builds
      File "/Users/sascha/Dev/ironpython3/Src/StdLib/Lib/_osx_support.py", line 103, in _get_system_version
    LookupError: unknown encoding: cp0IronPython 3.4.0b1 DEBUG (3.4.0.0010)
    [.NETCoreApp,Version=v6.0 on .NET 6.0.7 (64-bit)] on darwin
    Type "help", "copyright", "credits" or "license" for more information.
    

    When printing out the current encoding, utf_8 is returned:

    ➜  ironpython3 git:(35cc2274) ✗ bin/Debug/net6.0/ipy -c "import sys; print('The enncoding is='+sys.stdin.encoding)"
    Traceback (most recent call last):
      File "<string>", line 1567, in load_module
      File "<string>", line 596, in _load_module_shim
      File "<string>", line 1210, in load
      File "<string>", line 1190, in _load_unlocked
      File "<string>", line 1119, in _exec
      File "<string>", line 1461, in exec_module
      File "<string>", line 539, in _check_name_wrapper
      File "<string>", line 321, in _call_with_frames_removed
      File "/Users/sascha/Dev/ironpython3/bin/Debug/net6.0/../../../Src/StdLib/Lib/site.py", line 564, in <module>
      File "/Users/sascha/Dev/ironpython3/bin/Debug/net6.0/../../../Src/StdLib/Lib/site.py", line 550, in main
      File "/Users/sascha/Dev/ironpython3/bin/Debug/net6.0/../../../Src/StdLib/Lib/site.py", line 281, in addusersitepackages
      File "/Users/sascha/Dev/ironpython3/bin/Debug/net6.0/../../../Src/StdLib/Lib/site.py", line 257, in getusersitepackages
      File "/Users/sascha/Dev/ironpython3/bin/Debug/net6.0/../../../Src/StdLib/Lib/site.py", line 247, in getuserbase
      File "/Users/sascha/Dev/ironpython3/Src/StdLib/Lib/sysconfig.py", line 595, in get_config_var
      File "/Users/sascha/Dev/ironpython3/Src/StdLib/Lib/sysconfig.py", line 575, in get_config_vars
      File "/Users/sascha/Dev/ironpython3/Src/StdLib/Lib/_osx_support.py", line 393, in customize_config_vars
      File "/Users/sascha/Dev/ironpython3/Src/StdLib/Lib/_osx_support.py", line 135, in _supports_universal_builds
      File "/Users/sascha/Dev/ironpython3/Src/StdLib/Lib/_osx_support.py", line 103, in _get_system_version
    LookupError: unknown encoding: cp0The enncoding is=utf_8
    

    Looking into the code reveals that f = open('/System/Library/CoreServices/SystemVersion.plist') is raising the error.

    ➜  ironpython3 git:(35cc2274) ✗ cat /System/Library/CoreServices/SystemVersion.plist
    <?xml version="1.0" encoding="UTF-8"?>
    <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
    <plist version="1.0">
    <dict>
    	<key>ProductBuildVersion</key>
    	<string>19H2026</string>
    	<key>ProductCopyright</key>
    	<string>1983-2022 Apple Inc.</string>
    	<key>ProductName</key>
    	<string>Mac OS X</string>
    	<key>ProductUserVisibleVersion</key>
    	<string>10.15.7</string>
    	<key>ProductVersion</key>
    	<string>10.15.7</string>
    	<key>iOSSupportVersion</key>
    	<string>13.6</string>
    </dict>
    </plist>
    
    ➜  ironpython3 git:(35cc2274) ✗ file /System/Library/CoreServices/SystemVersion.plist
    /System/Library/CoreServices/SystemVersion.plist: XML 1.0 document text, ASCII text
    

    Reading this file with the default encoding yields to the error:

    >>> f = open('/System/Library/CoreServices/SystemVersion.plist')
    >>> print(f.readlines())
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    LookupError: unknown encoding: cp0
    >>> f = open('/System/Library/CoreServices/SystemVersion.plist', encoding='utf-8')
    >>> print(f.readlines())
    ['<?xml version="1.0" encoding="UTF-8"?>\n', '<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">\n', '<plist version="1.0">\n', '<dict>\n', '\t<key>ProductBuildVersion</key>\n', '\t<string>19H2026</string>\n', '\t<key>ProductCopyright</key>\n', '\t<string>1983-2022 Apple Inc.</string>\n', '\t<key>ProductName</key>\n', '\t<string>Mac OS X</string>\n', '\t<key>ProductUserVisibleVersion</key>\n', '\t<string>10.15.7</string>\n', '\t<key>ProductVersion</key>\n', '\t<string>10.15.7</string>\n', '\t<key>iOSSupportVersion</key>\n', '\t<string>13.6</string>\n', '</dict>\n', '</plist>\n']
    

    Setting PYTHONIOENCODING did not change the behavior:

    ➜  ironpython3 git:(35cc2274) ✗ PYTHONIOENCODING=utf_8 bin/Debug/net6.0/ipy
    Traceback (most recent call last):
      File "<string>", line 1567, in load_module
      File "<string>", line 596, in _load_module_shim
      File "<string>", line 1210, in load
      File "<string>", line 1190, in _load_unlocked
      File "<string>", line 1119, in _exec
      File "<string>", line 1461, in exec_module
      File "<string>", line 539, in _check_name_wrapper
      File "<string>", line 321, in _call_with_frames_removed
      File "/Users/sascha/Dev/ironpython3/bin/Debug/net6.0/../../../Src/StdLib/Lib/site.py", line 564, in <module>
      File "/Users/sascha/Dev/ironpython3/bin/Debug/net6.0/../../../Src/StdLib/Lib/site.py", line 550, in main
      File "/Users/sascha/Dev/ironpython3/bin/Debug/net6.0/../../../Src/StdLib/Lib/site.py", line 281, in addusersitepackages
      File "/Users/sascha/Dev/ironpython3/bin/Debug/net6.0/../../../Src/StdLib/Lib/site.py", line 257, in getusersitepackages
      File "/Users/sascha/Dev/ironpython3/bin/Debug/net6.0/../../../Src/StdLib/Lib/site.py", line 247, in getuserbase
      File "/Users/sascha/Dev/ironpython3/Src/StdLib/Lib/sysconfig.py", line 595, in get_config_var
      File "/Users/sascha/Dev/ironpython3/Src/StdLib/Lib/sysconfig.py", line 575, in get_config_vars
      File "/Users/sascha/Dev/ironpython3/Src/StdLib/Lib/_osx_support.py", line 393, in customize_config_vars
      File "/Users/sascha/Dev/ironpython3/Src/StdLib/Lib/_osx_support.py", line 135, in _supports_universal_builds
      File "/Users/sascha/Dev/ironpython3/Src/StdLib/Lib/_osx_support.py", line 103, in _get_system_version
    LookupError: unknown encoding: cp0IronPython 3.4.0b1 DEBUG (3.4.0.0010)
    [.NETCoreApp,Version=v6.0 on .NET 6.0.7 (64-bit)] on darwin
    Type "help", "copyright", "credits" or "license" for more information.
    >>>
    ➜  ironpython3 git:(35cc2274) ✗ PYTHONIOENCODING=utf-8 bin/Debug/net6.0/ipy
    Traceback (most recent call last):
      File "<string>", line 1567, in load_module
      File "<string>", line 596, in _load_module_shim
      File "<string>", line 1210, in load
      File "<string>", line 1190, in _load_unlocked
      File "<string>", line 1119, in _exec
      File "<string>", line 1461, in exec_module
      File "<string>", line 539, in _check_name_wrapper
      File "<string>", line 321, in _call_with_frames_removed
      File "/Users/sascha/Dev/ironpython3/bin/Debug/net6.0/../../../Src/StdLib/Lib/site.py", line 564, in <module>
      File "/Users/sascha/Dev/ironpython3/bin/Debug/net6.0/../../../Src/StdLib/Lib/site.py", line 550, in main
      File "/Users/sascha/Dev/ironpython3/bin/Debug/net6.0/../../../Src/StdLib/Lib/site.py", line 281, in addusersitepackages
      File "/Users/sascha/Dev/ironpython3/bin/Debug/net6.0/../../../Src/StdLib/Lib/site.py", line 257, in getusersitepackages
      File "/Users/sascha/Dev/ironpython3/bin/Debug/net6.0/../../../Src/StdLib/Lib/site.py", line 247, in getuserbase
      File "/Users/sascha/Dev/ironpython3/Src/StdLib/Lib/sysconfig.py", line 595, in get_config_var
      File "/Users/sascha/Dev/ironpython3/Src/StdLib/Lib/sysconfig.py", line 575, in get_config_vars
      File "/Users/sascha/Dev/ironpython3/Src/StdLib/Lib/_osx_support.py", line 393, in customize_config_vars
      File "/Users/sascha/Dev/ironpython3/Src/StdLib/Lib/_osx_support.py", line 135, in _supports_universal_builds
      File "/Users/sascha/Dev/ironpython3/Src/StdLib/Lib/_osx_support.py", line 103, in _get_system_version
    LookupError: unknown encoding: cp0IronPython 3.4.0b1 DEBUG (3.4.0.0010)
    [.NETCoreApp,Version=v6.0 on .NET 6.0.7 (64-bit)] on darwin
    Type "help", "copyright", "credits" or "license" for more information.
    >>>
    

    Forcefully editing _osx_support.py to open the file with utf-8 works:

    f = open('/System/Library/CoreServices/SystemVersion.plist', encoding='utf-8')
    

    Any suggested work-around or fix?

    Environment

    ➜  ~ dotnet --info
    .NET SDK (reflecting any global.json):
     Version:   6.0.302
     Commit:    c857713418
    
    Runtime Environment:
     OS Name:     Mac OS X
     OS Version:  10.15
     OS Platform: Darwin
     RID:         osx.10.15-x64
     Base Path:   /usr/local/share/dotnet/sdk/6.0.302/
    
    global.json file:
      Not found
    
    Host:
      Version:      6.0.7
      Architecture: x64
      Commit:       0ec02c8c96
    
    .NET SDKs installed:
      6.0.302 [/usr/local/share/dotnet/sdk]
    
    .NET runtimes installed:
      Microsoft.AspNetCore.App 6.0.7 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
      Microsoft.NETCore.App 6.0.7 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
    
    opened by strongly-typed 21
  • round of an integer should return an integer

    round of an integer should return an integer

    x = 111111111111111111111111111111
    assert round(x) == x
    assert round(x, 2) == x
    

    See https://github.com/IronLanguages/ironpython3/blob/master/WhatsNewInPython31.md

    Also round with no ndigits argument always returns an int:

    x = 1e16
    assert type(round(x)) == type(int(x)) # using type(int(x)) since we haven't unified int/long yet
    
    good first issue builtins 
    opened by slozier 19
  • Implements 'surrogateescape' encoding error handler

    Implements 'surrogateescape' encoding error handler

    Implements PEP 383 and Issue #2. Works with all .NET encodings: ASCII, Latin1, UTF-8, UTF-7, UTF-16, UTF-32, etc.

    The challenge is that .NET encoder and decoder fallback interfaces are only character oriented. This was also a problem in CPython, but they could extend the interface to allow fallbacks to produce output on byte level (see discussion PEP 383).

    opened by BCSharp 17
  • Round of an integer should return an integer #505

    Round of an integer should return an integer #505

    Implemented:

    • even rounding for floats and ints, floats is partially handled by an update to the DLR submodule.
    • all of the various error messages I could find are identical to those in Python 3.
    • for types that implement round, round() delegates to this special member.
    • when number is an int it returns an int when it can. when it cannot a BigInteger is returned.
    • when number is a BigInteger a BigInteger is always returned.

    The algorithm I have used for integral rounding is the one described here https://bugs.python.org/msg78141, which I believe is the algorithm that they use in CPython. There is a caveat that when ndigits is negative and cannot be converted to an int, then 0 is returned. There is no concept of signed zero for BigInteger.

    I've routed all of the two parameter integral rounding through a single BigInteger method to reduce the total number of code paths. Since there is a need to unify the int and long types and the int method can overflow I think the benefits of this outweigh any immediate performance concerns.

    I think I've tested all of the code paths, but I wouldn't say that the numerical testing is bulletproof.

    opened by hackf5 15
  •  Update exception handling to Python3 definition

    Update exception handling to Python3 definition

    After exiting an except block, no longer treat the latest exception as being "handled." Maintain the exception context when executing via a generator.

    Resolves #245.


    It's still missing some major parts, but this is a minimal change that seems to get the tests described in the issue passing.

    opened by gfmcknight 14
  • reworked original 2.x version of xrange into range

    reworked original 2.x version of xrange into range

    Fixes #50.

    changed from int to BigInteger to support ranges beyond 2^64
    added applicable test from stdlib
    added convenience methods to iptest/assert_util.py to mimic unittest
    added slice operator
    added == != < <= > >= operators
    added __contains__ method
    added count and index methods of collections.abc.Sequence
    changed start, stop and step to be attributes
    added __hash__
    added support for objects implementing __index__
    

    Outstanding: pickle testing - it depends on itertools which depends on missing language features I also made a change to Builtin (int is BigInteger) which may need to wait until a real int->long unification is done. When reviewing, go for second commit otherwise rename obfuscates changes.

    The result test out of a branch with some other temporary work around:

    rejap@WIN-CUE1I6EN9JB ~/github/ironpython3/bin/Debug
    $ ./IronPythonTestConsole.exe  IronPythonTest -noh -labels -full -test:IronPythonTest.Cases.IronPythonCases.test_range                 Runtime Environment -
        OS Version: Microsoft Windows NT 6.1.7601 Service Pack 1
      .NET Version: 4.0.30319.18444
    
    ***** IronPythonTest.DLL
    ***** IronPythonCases
    ***** IronPythonTests
    ***** test_range
    >>>   0.00s testing test_attributes_from_stdlib
    >>>   0.25s testing test_comparison_from_stdlib
    >>>   0.45s testing test_contains_from_stdlib
    >>>   0.51s testing test_count_from_stdlib
    >>>   0.58s testing test_empty_from_stdlib
    >>>   0.58s testing test_index_from_stdlib
    >>>   0.71s testing test_invalid_invocation_from_stdlib
    >>>   0.94s testing test_issue11845_from_stdlib
    >>>   1.04s testing test_odd_bug_from_stdlib
    >>>   1.05s testing test_range
    >>>   1.10s testing test_range_collections
    >>>   1.12s testing test_range_corner_cases
    >>>   1.17s testing test_range_coverage
    >>>   1.21s testing test_range_equal
    >>>   1.21s testing test_range_from_stdlib
    >>>   1.26s testing test_repr_from_stdlib
    >>>   1.26s testing test_reverse_iteration_from_stdlib
    >>>   1.29s testing test_slice_from_stdlib
    >>>   1.33s testing test_strided_limits_from_stdlib
    >>>   1.34s testing test_types_from_stdlib
    >>>   1.47s testing test_user_index_method_from_stdlib
    
    21 tests passed
    Tests run: 1, Passed: 1, Errors: 0, Failures: 0, Inconclusive: 0
      Not run: 0, Invalid: 0, Ignored: 0, Skipped: 0
    Elapsed time: 00:00:11.9180000
    
    opened by paweljasinski 13
  • Get test_memoryview passing

    Get test_memoryview passing

    ... Kind of.

    I have a couple pieces of the implementation that I think need revision, namely:

    1. When I added weakref support to memoryview, for some reason it wasn't releasing in time for the net4.5 target when run through make.ps1 tests. If I ran test_memoryview in any other circumstance the weakref seemed to release appropriately. I left it out for now, but it might be a good idea to investigate, given that we've seen something similar in #544.
    2. The change to suboffsets (empty tuple instead of None) should probably be handled on the other side of the IBufferProtocol instead of in memoryview, right?
    opened by gfmcknight 12
  • Documentation for New Contributors

    Documentation for New Contributors

    I'd like to contribute to this project. It seems like documentation is a little sparse, so it's tough to get a sense of what currently works and what doesn't, and what the current goals are.

    documentation 
    opened by brentshermana 12
  • dict subclasses which override __iter__ should be treated as mappings

    dict subclasses which override __iter__ should be treated as mappings

    Here are some examples:

    class test(dict):
        def __iter__(self):
            return super().__iter__()
        def keys(self):
            return ["A"]
        def __getitem__(self, key):
            return 1
    
    A = {"A": 1}
    B = test({"B": 2})
    
    assert dict(B) == A
    assert dict(**B) == A
    
    def fn(**kw):
        return kw
    
    assert fn(**B) == A
    
    d = {}
    d.update(B)
    assert d == A
    
    d = {}
    d.update(**B)
    assert d == A
    

    This is causing an issue with order preserving dicts and collections.OrderedDict.

    opened by slozier 0
  • Type `str` is missing `casefold` method

    Type `str` is missing `casefold` method

    Prerequisites

    • [X] Are you running the latest version?
    • [X] Are you reporting to the correct repository?
    • [X] Did you perform a cursory search?

    Description

    Type str implementation is missing casefold method. This method was added in Python 3.3

    Steps to Reproduce

    1. Run ipy.exe
    2. Type str.casefold and hit enter
    3. See exception
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    AttributeError: 'type' object has no attribute 'casefold'
    

    Expected behavior: [What you expected to happen]

    Runtime should find the method and repor <method 'casefold' of 'str' objects>

    Actual behavior: [What actually happened]

    Runtime reports AttributeError

    Versions

    You can get this information from executing ipy -VV.

    IronPython 3.4.0 (3.4.0.1000)
    [.NETFramework,Version=v4.6.2 on .NET Framework 4.8.4515.0 (64-bit)]
    

    and

    IronPython 3.4.0 (3.4.0.1000)
    [.NETCoreApp,Version=v6.0 on .NET 6.0.5 (64-bit)]
    
    What's New In Python 3.3 
    opened by eirannejad 0
  • Missing doctests on builtin methods

    Missing doctests on builtin methods

    The following builtin methods have doctests included in their __doc__ string:

    • bin
    • float.as_integer_ratio
    • float.fromhex
    • float.hex
    • hex
    • int
    • int.bit_length
    • oct
    opened by slozier 0
  • Formatting issues

    Formatting issues

    %-formatting of 999999999999998 is busted (outputs f-1) on .NET Framework (because it's rounding up to 1000000000000000 and the formatting logic fails to handle that properly).

    assert "%.15g" % 999999999999998 == "999999999999998"
    

    The "new-style" formatting is also failing, but with a ValueError:

    assert f"{999999999999998:.15g}" == "999999999999998"
    

    ValueError: Precision not allowed in integer format specifier

    opened by slozier 0
  • Unexpected output precision and/or rounding results in IronPython 3.4.0

    Unexpected output precision and/or rounding results in IronPython 3.4.0

    Description

    print - whether in conjunction with round or not - does not yield the expected output of decimal values as in 2.7

    Steps to Reproduce

    While I first observed the behavior in some breaking Unit tests while porting my .NET application to IronPython 3.4.0 using the new nupkg, a simple console example should do:

    IronPython 3.4.0 (3.4.0.1000)
    [.NETFramework,Version=v4.6.2 on .NET Framework 4.8.4515.0 (64-bit)] on win32
    Type "help", "copyright", "credits" or "license" for more information.
    >>> print(685.86)
    685.86000000000001
    >>> f = float(685.86)
    >>> print(f)
    685.86000000000001
    >>> print(round(f,2))
    685.86000000000001
    >>> print(round(f))
    686
    >>> print(round(f,1))
    685.89999999999998
    >>>
    

    Therefore, I'd think of an output rather than a numeric issue.

    Expected behavior: While I am aware that not every decimal number can be rendered in full fidelity, I would expect the same output as was the input argument; or in case of round the output being truncated to the specified number of decimal places. This was the case in IronPython 2.7.

    Actual behavior: Although the result may be correct from a numeric point of view, the numbers always seem to be output with the same number of decimal places, which is never the one provided as an argument. Especially, rounding to 1 digit should not give me 14 digits.

    Versions

    • 3.4.0 Release

    If this is indeed expected, then I am not sure how to produce a normalized output.

    opened by AlGerngro 1
Releases(v3.4.0)
Owner
IronLanguages
IronLanguages
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
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
The Python programming language

This is Python version 3.10.0 alpha 5 Copyright (c) 2001-2021 Python Software Foundation. All rights reserved. See the end of this file for further co

Python 49.7k Dec 30, 2022
The Stackless Python programming language

This is Python version 3.7.0 alpha 4+ Copyright (c) 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 20

Stackless Python 891 Jan 3, 2023
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
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
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
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
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
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
ONNX Runtime Web demo is an interactive demo portal showing real use cases running ONNX Runtime Web in VueJS.

ONNX Runtime Web demo is an interactive demo portal showing real use cases running ONNX Runtime Web in VueJS. It currently supports four examples for you to quickly experience the power of ONNX Runtime Web.

Microsoft 58 Dec 18, 2022
null 270 Dec 24, 2022
Kashgari is a production-level NLP Transfer learning framework built on top of tf.keras for text-labeling and text-classification, includes Word2Vec, BERT, and GPT2 Language Embedding.

Kashgari Overview | Performance | Installation | Documentation | Contributing ?? ?? ?? We released the 2.0.0 version with TF2 Support. ?? ?? ?? If you

Eliyar Eziz 2.3k Dec 29, 2022
Kashgari is a production-level NLP Transfer learning framework built on top of tf.keras for text-labeling and text-classification, includes Word2Vec, BERT, and GPT2 Language Embedding.

Kashgari Overview | Performance | Installation | Documentation | Contributing ?? ?? ?? We released the 2.0.0 version with TF2 Support. ?? ?? ?? If you

Eliyar Eziz 2k Feb 9, 2021
Pyrin is an application framework built on top of Flask micro-framework to make life easier for developers who want to develop an enterprise application using Flask

Pyrin A rich, fast, performant and easy to use application framework to build apps using Flask on top of it. Pyrin is an application framework built o

Mohamad Nobakht 10 Jan 25, 2022
The Medical Detection Toolkit contains 2D + 3D implementations of prevalent object detectors such as Mask R-CNN, Retina Net, Retina U-Net, as well as a training and inference framework focused on dealing with medical images.

The Medical Detection Toolkit contains 2D + 3D implementations of prevalent object detectors such as Mask R-CNN, Retina Net, Retina U-Net, as well as a training and inference framework focused on dealing with medical images.

MIC-DKFZ 1.2k Jan 4, 2023