diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 8d7e2bb80..e97d72408 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -2,13 +2,13 @@ The steps to contribute a change are: -1. Fork the IronPython3 repository. For more information see [Getting the Sources](docs/getting-the-sources.md). -2. Build the repository. For more information see [Building](docs/building.md). -1. Make your changes on your machine, ensure ```make.ps1 test-all``` runs successfully, and commit your changes. For more information see [Modifying the Sources](docs/modifying-the-sources.md). -1. Push the commits to your fork. This way your name will be the author of the commit in the main IronPython3 tree (once the commits are pulled into the main tree). -1. Create a pull request on Github, this will initiate a code review and CLA signing request -1. The IronPython team will review, and possibly request changes, to your PR -1. Once all comments/questions/concerns have been addressed, your PR will be merged. +1. Fork the IronPython3 repository. For more information see [Getting the Sources](https://github.com/IronLanguages/ironpython3/wiki/Getting-the-sources). +2. Build the repository. For more information see [Building](https://github.com/IronLanguages/ironpython3/wiki/Building). +3. Make your changes on your machine, ensure ```make.ps1 test-all``` runs successfully, and commit your changes. For more information see [Modifying the Sources](https://github.com/IronLanguages/ironpython3/wiki/Modifying-the-sources). +4. Push the commits to your fork. This way your name will be the author of the commit in the main IronPython3 tree (once the commits are pulled into the main tree). +5. Create a pull request on Github, this will initiate a code review and CLA signing request +6. The IronPython team will review, and possibly request changes, to your PR +7. Once all comments/questions/concerns have been addressed, your PR will be merged. Also, [Collaborative Github Workflow](http://www.eqqon.com/index.php/Collaborative_Github_Workflow) has a very good description of the workflow and tips and tricks when contributing to a project hosted on GitHub. diff --git a/README.md b/README.md index 292b07a44..01e8c89da 100644 --- a/README.md +++ b/README.md @@ -51,10 +51,12 @@ System.Console.WriteLine(greetings("world")); This example assumes that `IronPython` has been added to the C# project as a NuGet package. ## 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](https://dotnetfoundation.org/code-of-conduct). ## State of the Project + The current target is Python 3.4, although features and behaviors from later versions may be included. See the following lists for features from each version of CPython that have been implemented: @@ -68,22 +70,29 @@ See the following lists for features from each version of CPython that have been - [What's New In Python 3.6](WhatsNewInPython36.md) ## Contributing + For details on contributing see the [Contributing](CONTRIBUTING.md) article. ## Upgrading from IronPython 2 -For details on upgrading from IronPython 2 to 3 see the [Upgrading from IronPython 2 to 3](docs/upgrading-from-ipy2.md) article. + +For details on upgrading from IronPython 2 to 3 see the [Upgrading from IronPython 2 to 3](https://github.com/IronLanguages/ironpython3/wiki/Upgrading-from-IronPython2) article. ## Differences with CPython -While compatibility with CPython is one of our main goals with IronPython 3, there are still some differences that may cause issues. See [Differences from CPython](docs/differences-from-c-python.md) for details. + +While compatibility with CPython is one of our main goals with IronPython 3, there are still some differences that may cause issues. See [Differences from CPython](https://github.com/IronLanguages/ironpython3/wiki/Differences-from-CPython) for details. ## Package compatibility -See the [Package compatibility](docs/package-compatibility.md) document for information on compatibility with popular packages. + +See the [Package compatibility](https://github.com/IronLanguages/ironpython3/wiki/Package-compatibility) document for information on compatibility with popular packages. ## Installation -Binaries of IronPython 3 can be downloaded from the [release page](https://github.com/IronLanguages/ironpython3/releases/latest), available in various formats: `.msi`, `.zip`, `.deb`, `.pkg`. The IronPython package is also available on [NuGet](https://www.nuget.org/packages/IronPython/3.4.0). See the [installation document](docs/installing.md) for detailed instructions on how to install a standalone IronPython interpreter on various operating systems and .NET frameworks. + +Binaries of IronPython 3 can be downloaded from the [release page](https://github.com/IronLanguages/ironpython3/releases/latest), available in various formats: `.msi`, `.zip`, `.deb`, `.pkg`. The IronPython package is also available on [NuGet](https://www.nuget.org/packages/IronPython/3.4.0). See the [installation document](https://github.com/IronLanguages/ironpython3/wiki/Installing) for detailed instructions on how to install a standalone IronPython interpreter on various operating systems and .NET frameworks. ## Build -See the [building document](docs/building.md). Since the main development is on Windows, bugs on other platforms may inadvertently be introduced - please report them! + +See the [building document](https://github.com/IronLanguages/ironpython3/wiki/Building). Since the main development is on Windows, bugs on other platforms may inadvertently be introduced - please report them! ## Supported Platforms + IronPython 3 targets .NET Framework 4.6.2, .NET Standard 2.0, .NET 6.0 and .NET 8.0. The support for .NET and .NET Core follow the lifecycle defined on [.NET and .NET Core Support Policy](https://dotnet.microsoft.com/platform/support/policy/dotnet-core). diff --git a/docs/building.md b/docs/building.md index 4e04fbd1b..371c101d8 100644 --- a/docs/building.md +++ b/docs/building.md @@ -1,50 +1 @@ -# Building IronPython3 - -To build IronPython3 you will need the [.NET SDK (minimum v6.0.100)](https://dotnet.microsoft.com/download/visual-studio-sdks). - -See [Getting the Sources](getting-the-sources.md) for information on getting the source for IronPython3. - -## Building from Visual Studio - -Visual Studio 2022 v17.0 or above is required to build IronPython3. - - * Open the `IronPython.sln` solution file - * Select the configuration options (Release, Debug, etc.) - * Press Ctrl+Shift+B or F6 to build the solution - -## Building from the command line - -IronPython3 uses PowerShell to run the build and testing from the command line. You can either use a PowerShell directly, or prefix the commands below with `powershell` on Windows, or `pwsh` on Linux/macOS. - -On Linux/macOS you will need to install [PowerShell](https://github.com/PowerShell/PowerShell/releases) - -Change the working directory to the path where you cloned the sources and run `./make.ps1` - -By default, with no options, `make.ps1` will build the `Release` mode binaries. If you would like to build `Debug` binaries, you can run `./make.ps1 debug` - -Other options available for `make.ps1` are - -``` --configuration (debug/release) The configuration to build for --platform (x86/x64) The platform to use in running tests --runIgnored Run tests that are marked as ignored in the .ini manifests --frameworks A comma separated list of frameworks to run tests for - (use nomenclature as is used in msbuild files for TargetFrameworks) -``` - -There are also other targets available for use with packaging and testing, most come in debug and release (default) versions, such as `package-debug` and `package` - -``` -package Creates packages supported by the current platform -stage Stages files ready for packaging -test-* Runs tests from `all` categories, `ironpython` specific tests, - `cpython` tests from the CPython stdlib test suite -``` - -If the build is successful the binaries are stored in `ironpython3/bin/{Configuration}/{TargetFramework}`. - -## Running - -The standard library is not copied over to the `bin` folder during the build process, it lives in `src/core/IronPython.StdLib/lib`. -- When running the `Release` configuration executable, you should set the environment variable `IRONPYTHONPATH` to this folder. -- When running the `Debug` configuration executable, this folder is automatically added to `sys.path`. +This document has been moved to the IronPython wiki: [Building](https://github.com/IronLanguages/ironpython3/wiki/Building) diff --git a/docs/differences-from-c-python.md b/docs/differences-from-c-python.md index 07e4fdbb0..b75f779ec 100644 --- a/docs/differences-from-c-python.md +++ b/docs/differences-from-c-python.md @@ -1,269 +1 @@ -This page documents various differences between IronPython and CPython. Since IronPython is under active development, any of the differences described here may change or disappear in the future: - -- [Environment Variables](#environment-variables) -- [COM Interaction](#com-interaction) -- [Strings](#strings) -- [Interaction with the Operating System](#interaction-with-the-operating-system) -- [Codecs](#codecs) -- [Source File Encoding](#source-file-encoding) -- [Recursion](#recursion) - -# Environment Variables - -* `IRONPYTHONSTARTUP` is used instead of `PYTHONSTARTUP` - -* `IRONPYTHONPATH` is used instead of `PYTHONPATH` - -# COM Interaction - -* Interaction with COM objects is handled by the CLR rather than a python library binding to the native COM dlls. - -# Strings - -* `str` objects are represented in UTF-16 (like all .NET strings) rather than UTF-32 used by CPython. - -This has a few visible consequences if characters ouside of the Basic Multilingual Plane (BMP) are used (that is, characters with Unicode code points above `U+FFFF`). A few examples below illustrate the differences. - -Let's take a Unicode character U+1F70B, '🜋'. In CPython, it is represented by a single character: - -_CPython_ -``` ->>> len('\U0001f70b') -1 ->>> str('\U0001f70b') -'🜋' -``` - -In IronPython, it is represented by a pair of surrogate characters U+D83D and U+DF0B: - -_IronPython_ -``` ->>> len('\U0001f70b') -2 ->>> str('\U0001f70b') -'\ud83d\udf0b' -``` - -In **both** cases, however, the string containing such character is printed out correctly, since `print` will transcode the string from its internal representation to whichever encoding is used by the console or file (usually UTF-8): - -_CPython_ and _IronPython_ -``` -print('\U0001f70b') -'🜋' -``` - -Any surrogate pair in IronPython strings represents one logical character. CPython, however, sees a surrogate pair as two invalid characters. - -_IronPython_ -``` ->>> '\ud83d\udf0b' -'\ud83d\udf0b' ->>> print('\ud83d\udf0b') -🜋 ->>> '\ud83d\udf0b'.encode('utf-8') -b'\xf0\x9f\x9c\x8b' ->>> '\U0001f70b'.encode('utf-8') -b'\xf0\x9f\x9c\x8b' -``` - -_CPython_ -``` ->>> '\ud83d\udf0b' -'\ud83d\udf0b' ->>> print('\ud83d\udf0b') -Traceback (most recent call last): - File "", line 1, in -UnicodeEncodeError: 'utf-8' codec can't encode characters in position 0-1: surrogates not allowed -'\ud83d\udf0b'.encode('utf-8') -Traceback (most recent call last): - File "", line 1, in -UnicodeEncodeError: 'utf-8' codec can't encode characters in position 0-1: surrogates not allowed -``` - -CPython requires use of `'surrogatepass'` error handler to let those pairs through. Note however, that they are still being treated as two separate characters. IronPython encodes the pair as if it were one character. - -_CPython_ -``` ->>> '\ud83d\udf0b'.encode('utf-8','surrogatepass') -b'\xed\xa0\xbd\xed\xbc\x8b' ->>> '\U0001f70b'.encode('utf-8') -b'\xf0\x9f\x9c\x8b' -``` - -The `'surrogatepass'` error handler is still needed in IronPython to handle surrogate characters that do not form a valid surrogate pair: - -_IronPython_ -``` -print('\ud83d\udf0b') -🜋 ->>> print('\ud83d\udf0b'[::-1]) -Traceback (most recent call last): - File "", line 1, in -UnicodeEncodeError: 'cp65001' codec can't encode character '\udf0b' in position 0: Unable to translate Unicode character \\uDF0B at index 0 to specified code page. ->>> print('\ud83d\udf0b'[::-1].encode('utf-8','surrogatepass')) -b'\xed\xbc\x8b\xed\xa0\xbd' -``` - -_CPython_ -``` ->>> print('\ud83d\udf0b') -Traceback (most recent call last): - File "", line 1, in -UnicodeEncodeError: 'utf-8' codec can't encode characters in position 0-1: surrogates not allowed ->>> print('\ud83d\udf0b'[::-1]) -Traceback (most recent call last): - File "", line 1, in -UnicodeEncodeError: 'utf-8' codec can't encode characters in position 0-1: surrogates not allowed ->>> print('\ud83d\udf0b'[::-1].encode('utf-8','surrogatepass')) -b'\xed\xbc\x8b\xed\xa0\xbd' -``` - -# Interaction with the Operating System - -* Environment variables are decoded using the `'replace'` error handler, rather than the `'surrogateescape'` error handler used by CPython. - -This is how .NET libraries handle encoding errors in the system. The difference is only visible on Posix systems that have environment variables defined using a different encoding than the encoding used by the system (Windows environment variables are always in UTF-16, so no conversion takes place when accessed as Python `str` objects). - -Assume that a Linux system is configured to use UTF-8. Under bash: - -``` -$ python -c 'f=open("test.sh","w",encoding="latin-1");print("NAME=\"André\"",file=f)' -$ source test.sh -$ export NAME -``` - -This creates an environment variable that is encoded using Latin-1 encoding, rather than the system encoding. CPython will escape the invalid byte 0xe9 (letter 'é' in Latin-1) in a lone surrogate 0xdce9, which is still an invalid Unicode character. - -_CPython_ -``` ->>> import os ->>> os.environ["NAME"] -'Andr\udce9' ->>> print(os.environ["NAME"]) -Traceback (most recent call last): - File "", line 1, in -UnicodeEncodeError: 'utf-8' codec can't encode character '\udce9' in position 4: surrogates not allowed -``` - -IronPython will replace the invalid byte with U+FFFD, the Unicode replacement character, which is a valid and printable character. - -_IronPython_ -``` ->>> import os ->>> os.environ["NAME"] -'Andr�' ->>> print(os.environ["NAME"]) -Andr� ->>> hex(ord(os.environ["NAME"][-1])) -'0xfffd' -``` - -The CPython representation is not printable, but can be safely encoded back to the original form using `'surrogateescape'` (default when dealing with the OS environment): - -_CPython_ -``` ->>> os.environ["PATH"] = os.environ["PATH"] + ":/home/" + os.environ["NAME"] + "/bin" ->>> import posix ->>> posix.environ[b"PATH"] -b'/bin:/usr/bin:/usr/local/bin:/home/Andr\xe9/bin' ->>> os.environ["NAME"].encode("utf-8","surrogateescape") -b'Andr\xe9' -``` - -The IronPython representation is printable, but the original byte value is lost: - -_IronPython_ -``` ->>> os.environ["NAME"].encode("utf-8","surrogateescape") -b'Andr\xef\xbf\xbd' -``` - -# Codecs - -* Some single-byte codecs may have unused positions in their codepage. There are differences between how CPython and IronPython (and .NET) handle such cases. - -A simple example is encoding Windows-1252. According to the information on Microsoft's and the Unicode Consortium's websites, positions 81, 8D, 8F, 90, and 9D are unused; however, the Windows API `MultiByteToWideChar` maps these to the corresponding C1 control codes. The Unicode "best fit" mapping [documents this behavior](https://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WindowsBestFit/bestfit1252.txt). CPython will treat those bytes as invalid, while IronPython will map them to the "best fit" Unicode character: - -_CPython_ -``` ->>> b'\x81'.decode('windows-1252') -Traceback (most recent call last): - File "", line 1, in - File "/opt/anaconda3/envs/py34/lib/python3.4/encodings/cp1252.py", line 15, in decode - return codecs.charmap_decode(input,errors,decoding_table) -UnicodeDecodeError: 'charmap' codec can't decode byte 0x81 in position 0: character maps to ->>> b'\x81'.decode('windows-1252','surrogateescape') -'\udc81' -``` - -_IronPython_ -``` ->>> b'\x81'.decode('windows-1252') -'\x81' ->>> b'\x81'.decode('windows-1252','surrogateescape') -'\x81' -``` - -The same difference in behavior can be observed during encoding: - -_CPython_ -``` ->>> '\x81'.encode('windows-1252') -Traceback (most recent call last): - File "", line 1, in - File "/opt/anaconda3/envs/py34/lib/python3.4/encodings/cp1252.py", line 12, in encode - return codecs.charmap_encode(input,errors,encoding_table) -UnicodeEncodeError: 'charmap' codec can't encode character '\x81' in position 0: character maps to -``` - -_IronPython_ -``` ->>> '\x81'.encode('windows-1252') -b'\x81' -``` - -* When using the UTF-7 encoding, IronPython (and .NET) always terminates the modified Base64 encoded blocks with a '-' while CPython omits the '-' if allowed. - -The UTF-7 standard allows encoders for some freedom of implementation. One optionality allowed in UTF-7 is how to end a sequence encoded in the modified Base64 code. In principle, `+` marks the start of the sequence, and `-` is the terminator. However, it is allowed to omit the terminating `-` if the next character unambiguously does not belong to the encoded Base64 block. CPython chooses to drop the terminating `-` in such cases, while IronPython will always terminate Base64-encoded blocks with a `-`: - -_CPython_ -``` ->>> 'abc:~~:zyz'.encode('utf-7') -b'abc:+AH4Afg:zyz' -``` - -_IronPython_ -``` ->>> 'abc:~~:zyz'.encode('utf-7') -b'abc:+AH4Afg-:zyz' -``` - -Note that both forms are fully interchangeable; IronPython will correctly decode what CPython encoded and vice versa. - -# Source File Encoding - -* Widechar Unicode encodings are supported as source file encoding, in addition to standard Python encodings. - -The default source file encoding is UTF-8. This also applies to bytestrings used within the program (processed by `compile`, `eval`, or `exec`). The source file encoding can be explicitly specified, and possibly changed, in one of the two ways: - - 1. By declaring the encoding in a Python comment in one of the first two lines — in accordance with [PEP-263](https://www.python.org/dev/peps/pep-0263/). - 2. By a byte-order-mark (BOM) — only for Unicode encodings. - -CPython recognizes only UTF-8 BOM. IronPython recognizes BOM in UTF-8, UTF-16LE, UTF-16BE, UTF-32LE, and UTF-32BE. - -If both BOM and PEP-263 methods are used simultaneously in the same file, they should be specifying the same encoding. If the PEP-263 encoding does not match the BOM, then: - - * In case of UTF-8 BOM, an error will be reported (by both CPython and IronPython). - * In case of other BOMs, the encoding specified in the PEP-263 comment is silently ignored. - -# Recursion - -By default, instead of raising a `RecursionError` when the maximum recursion depth is reached, IronPython will terminate with a `StackOverflowException`. You can enable the recursion limit in IronPython in a number of ways: - - 1. From the command line: `ipy -X MaxRecursion=100`. - 2. In hosted scenarios: `Python.CreateEngine(new Dictionary() { { "RecursionLimit", 100 } });`. - 3. From Python: `sys.setrecursionlimit(100)`. - -*There is a significant performance cost when the recursion limit is enabled*. - -Note that IronPython 3.4 adopts the CPython 3.5 behavior and throws a `RecursionError` instead of a `RuntimeError`. +This document has been moved to the IronPython wiki: [Differences from CPython](https://github.com/IronLanguages/ironpython3/wiki/Differences-from-CPython) diff --git a/docs/getting-the-sources.md b/docs/getting-the-sources.md index b5bd5e4a9..e971d0dff 100644 --- a/docs/getting-the-sources.md +++ b/docs/getting-the-sources.md @@ -1,62 +1 @@ -The main IronPython3 git repository is at [http://github.com/IronLanguages/ironpython3](http://github.com/IronLanguages/ironpython3). - -## Downloading the sources - -You can [download a zipped copy](http://github.com/IronLanguages/ironpython3/zipball/main) of the latest IronPython3 sources as well. - -### Installing GIT - -The following links include resources for installing and using GIT: - * [GitHub guides](http://help.github.com/) - * [GIT documentation](http://www.kernel.org/pub/software/scm/git/docs/git.html) - If you have never used GIT, reading the [tutorial](http://www.kernel.org/pub/software/scm/git/docs/gittutorial.html) first will be a big help to finding your way around. - * [Cheat sheet](http://cheat.errtheblog.com/s/git) - Quick reference for commonly used commands - * [Collaborative Github Workflow](http://www.eqqon.com/index.php/Collaborative_Github_Workflow) - very good description of the workflow and tips and tricks when contributing to a project hosted on GitHub. - * [Jimmy's Cheatsheet](http://tinyurl.com/jimmygitcheat) - -### Creating a local GIT repository - -You will first need to fork the IronPython3 project. [Creating a fork](https://help.github.com/fork-a-repo/) is recommended as it will allow you to contribute patches back easily. Click the "Fork" button on [https://github.com/IronLanguages/ironpython3/](https://github.com/IronLanguages/ironpython3/). This should create your personal fork, with a web URL like http://github.com/janedoe/ironpython3 (where janedoe is your github username). - -You can now use the git command-line client with many Linux distributions, Mac OS, Cygwin, and Windows (msysgit) to get the sources onto your local computer using the following commands: - -``` -git config --global branch.autosetupmerge true -git config --global user.name "Jane Doe" -git config --global user.email janedoe@example.com - -git clone git@github.com:janedoe/ironpython3.git -cd ironpython3 -git remote add ironpython3 git://github.com/IronLanguages/ironpython3.git -git pull ironpython3 main -``` - -At a later date, to get the latest updates from the IronPython3 project, run the following command in the ironpython3 directory created above: - -``` -git pull ironpython3 main -``` - -If there is a merge conflict, edit the unmerged files to remove the conflict markers, and then run the following command: - -``` -git commit -a -``` - -To push your changes back to your fork and make them public, use `git push`. - -### Working without a fork - -You can skip creating a fork if you only want to browse the sources. In that case, you can clone the project directly as such: -``` -git clone git://github.com/IronLanguages/ironpython3.git -git pull -``` - -### Initialize submodules - -The DLR (Dynamic Language Runtime) is a submodule of the ironpython3 repository, you need to initialize after cloning the repository. -``` -git submodule update --init -``` - -For more information there is an excellent tutorial on [getting started with git](http://kylecordes.com/2008/04/30/git-windows-go/) +This document has been moved to the IronPython wiki: [Getting the sources](https://github.com/IronLanguages/ironpython3/wiki/Getting-the-sources) diff --git a/docs/installing.md b/docs/installing.md index 7b978bc11..07125d136 100644 --- a/docs/installing.md +++ b/docs/installing.md @@ -1,179 +1 @@ -# Installing IronPython Released Binaries - -IronPython can be used as a standalone interpreter, or embedded within another .NET application. For embedding, the recommended approach is to install IronPython within the target project using NuGet. This document describes various ways of installing the standalone interpreter on the target system. Once installed, IronPython is invocable from the command line as `ipy`. Use `ipy -h` for a list of available commadline options. Use `ipy -VV` to produce version information for reporting issues. - -## IronPython on .NET (Core) - -Since .NET is a cross-platform framework, the instructions in this section apply to all supported operating systems (Windows, Linux, macOS), unless explicitly indicated. - -### .NET SDK - -If the target system already has a full .NET SDK installed, the most straightforward method to install a standalone IronPython interpreter is by using [`dotnet tool`](https://learn.microsoft.com/en-us/dotnet/core/tools/global-tools). - -#### _Global Tool_ - -"Global" .NET tool means one installation for the current user. It is not available to other users in the system. Install IronPython with: - -``` -dotnet tool install --global ironpython.console -``` - -The switch `--global` can be abbreviated to `-g`. The `ipy` program will be installed in `~/.dotnet/tools`, together with the Python Standard Library for IronPython. The directory `~/.dotnet/tools` should be added to the search path for the user (AKA `PATH` environment variable), if not yet done. - -Note that any additional Python packages installed using `ipy -m pip` from this location will be installed inside that directory, hence being "global" for the user. - -#### _Project Tool_ - -IronPython can be installed as a tool local to an existing .NET project. Navigate to the root directory of the .NET project and make sure that the tool manifest file is already present(`./.config/dotnet-tools.json`). If not, create a new empty tool manifest with: - -``` -dotnet new tool-manifest -``` - -There is one tools manifest for all .NET tools configured for a given project, tracking all .NET tools used within the project. Consider adding `dotnet-tools.json` to the source control management system (like _git_). - -Install IronPython and Python Standard Library with: - -``` -dotnet tool install ironpython.console -``` - -and invoke it with `dotnet ipy` from within any folder within the project. - -**NOTE**: Any additional packages installed with `dotnet ipy -m pip` are **NOT** local to the project, but installed in a location shared by all .NET project using `ipy ` as a local tool (`~/.nuget/packages/ironpython.console`). - -If the project is cloned onto another system and the tools manifest is already present and contains the reference to `ironpython.console`, all that is needed to install `ipy` locally is: - -``` -dotnet tool restore -``` - -#### _Virtual Environment_ - -The third way of installing IronPython as a .NET tool is to specify the installation directory explicitly: - -``` -dotnet tool install ironpython.console --tool-path /path/to/install/directory -``` - -This installs IronPython, together with the matching Python Standard Library, in a way that is independent from any other IronPython installations on the system, effectively creating an equivalent of a Python virtual environment. The target directory is created and will contain executable `ipy` (`ipy.exe` on Windows). When installed by the admin in a location accessible by all users (e.g. "C:\IronPython", or "/usr/local/bin"), it can serve as a "system-wide" installation. - -Any additional packages installed with `/path/to/install/directory/ipy -m pip` are only visible for this particular installation. - -### .NET Runtime - -If the target system does not have .NET SDK installed, but does have a .NET Runtime installed (i.e `dotnet --version` works), a way to install IronPython is to use the zip file published on the project's [release page](https://github.com/IronLanguages/ironpython3/releases/latest). - -Installations from the zip file are self-contained, so in a sense work like a Python virtual environment. For PowerShell users, the zip archive also contains script `Enter-IronPythonEnvironment.ps1` that works similarly to Anaconda's `Enter-CondaEnvironment.ps1` or CPython's `activate.ps1`. Use `help` on this file for detailed usage information. - -#### _Manual_ - -Download and unzip `IronPython.3.X.Y.zip` (`X` and `Y` being the minor and patch version numbers). The unzipped directory contains several .NET Runtime version-specific subdirectories and a subdirectory `lib`. Pick a subdirectory that matches the .NET Runtime version installed on your system (or lower), and **move** subdirectory `lib` into that directory. IronPython can then be launched with - -``` -dotnet /path/to/unzipped/netXXX/ipy.dll -``` - -#### _Scripted_ - -The zip file contains a helper PowerShell script to install IronPython properly in a designated location and creates a launcher script. In this way one zip file can "seed" multiple virtual environments, each starting "blank" that is, with only the Python Standard Library present. - -``` -/path/to/unzipped/scripts/Install-IronPython.ps1 -Path ~/ipyenv -ZipFile ~/Downloads/IronPython.3.X.Y.zip -``` - -Use Powershell's `help` command on the script for information about available options and switches. - -The script is also available online, so it can be downloaded and invoked without unzipping the archive first. - -``` -PS> Invoke-WebRequest https://raw.githubusercontent.com/IronLanguages/ironpython3/main/eng/scripts/Install-IronPython.ps1 -OutFile ./Install-IronPython.ps1 -PS> ./Install-IronPython ~/ipyenv ~/Downloads/IronPython.3.X.Y.zip -PS> ~/ipyenv/Enter-IronPythonEnvironment -«ipyenv» PS> ipy -IronPython 3.4.0 (3.4.0.1000) -[.NETCoreApp,Version=v6.0 on .NET 6.0.12 (64-bit)] on win32 -Type "help", "copyright", "credits" or "license" for more information. ->>> -``` - -## IronPython on .NET Framework/Mono - -### Windows - -IronPython for .NET Framework requires .NET Framework version 4.6.2 or higher, which comes preinstalled on modern versions of Windows. To install IronPython, download the `.msi` file from the project's [release page](https://github.com/IronLanguages/ironpython3/releases/latest) and execute it. The installation of `.msi` registers IronPython in the System Registry in compliance with [PEP 514](https://peps.python.org/pep-0514/) so that other tools may detect and use it. - -Alternatively, use _Chocolatey_ package manager: - -``` -choco install ironpython -``` - -### Linux (Debian-like) - -On Linux, Mono provides the necessary .NET Framework. First install Mono following installation instructions from the [Mono Project page](https://www.mono-project.com/download/stable/#download-lin). After installation, verify that command `mono` is available at the shell prompt, with, e.g. `mono --version`. - -Then download the `.deb` package from the project's [release page](https://github.com/IronLanguages/ironpython3/releases/latest). - -Finally install the package using `dpkg`, e.g.: - -``` -dpkg -i ~/Downloads/ironpython_3.X.Y.deb -``` - -### macOS - -On macOS (AKA OSX, Darwin), Mono provides the necessary .NET Framework. First install Mono following installation instructions from the [Mono Project page](https://www.mono-project.com/download/stable/#download-mac). After installation, verify that command `mono` is available at the shell prompt, with, e.g. `mono --version`. - -Then download the `.pkg` installer from the project's [release page](https://github.com/IronLanguages/ironpython3/releases/latest) and execute it. The IronPython installation is placed in `/Library/Frameworks/IronPython.framework/Versions/3.X.Y` (`X` and `Y` being the minor and patch version numbers). It can be run with: - -``` -mono /Library/Frameworks/IronPython.framework/Versions/3.X.Y/bin/ipy.exe -``` - -Note that Mono comes with its own (old, obsolete, and unsupported) version of IronPython and a launcher script `ipy` in Mono's commands directory (`/Library/Frameworks/Mono.framework/Versions/Current/Commands/ipy`). Since Mono's command directory is by default added to the command search path, simply running `ipy` from the command line will most likely pick up the Mono version. This version reports version number 3.0.0.0 and is backed by Python StdLib 2.7. To verify if this is the case, run: - -```shell -$ which ipy -/Library/Frameworks/Mono.framework/Versions/Current/Commands/ipy -$ ipy -V -IronPython 3.0 3.0.0.0 on 6.12.0.188 (2020-02/ca8abcb6bc4 Thu Oct 13 14:26:22 EDT 2022) -``` - -It is recommended to create one's own launcher script launching the newer IronPython version and to put it before Mono's `ipy` on the search path. - -# Installing Non-Released Versions - -After a release, the development of IronPython continues so it is possible that a bug or a feature that is important to you was handled after the latest release. As each commit to the main project branch creates precompiled artifacts, it is still possible to install the relevant (or latest development) version of IronPython without the need to compile the whole project from scratch. - -Go to the project's [_Actions_ page](https://github.com/IronLanguages/ironpython3/actions) and find the commit you are interested in. Or simply find the topmost commit to `main` that has all tests passing. The _Status_ and _Branch_ filters in the top bar are helpful to narrow the list down. Then click on the commit hyperlink to access the CI run summary. At the bottom of that page there is artifact `packages`, which contains all binary artifacts the project produces. Download it and unzip. Choose the right package for your needs and follow instructions above for the officially released artifacts. For convenience, here is a table with usable packages: - -| Artifact | Framework | Operating System | -| -------------------- | ------------------------------ | ----------------------------------- | -| IronPython.3.X.Y.zip | all supported | all supported | -| IronPython-3.X.Y.msi | .NET Framework 4.6.2 or higher | Windows | -| ironpython_3.X.Y.deb | Mono 6.12 or higher | Linux (Debian, Ubuntu, and similar) | -| IronPython-3.X.Y.pkg | Mono 6.12 or higher | macOS | - - -# Installing from Sources - -To build and install IronPython from sources, first follow instructions in [_Getting the Sources_](https://github.com/IronLanguages/ironpython3/blob/main/docs/getting-the-sources.md) and [_Building IronPython3_](https://github.com/IronLanguages/ironpython3/blob/main/docs/building.md). - -When the command `./make.ps1 debug` completes successfully, runnable and usable `ipy` executables are available in subdirectories of `./bin/Debug`. To run executables from the release configuration (produced by a successful run of `./make.ps1`), first set environment variable `IRONPYTHONPATH`. - -If those executables test out successfully, the binaries can be installed outside the project directory, or on another system. Create the installation artifacts with: - -``` -./make.ps1 package -``` - -The artifacts are placed in directory `./Package/Release/Packages/IronPython-3.X.Y`. Pick a package suitable for your installation target and follow instructions above for the officially released packages. - -Note: as a convenience, if you run `Install-IronPython.ps1` directly from directory `./eng/scripts` to install IronPython from the zip file, there is no need to pass the location to the zip file; the script finds it automatically using the relative path. - -Installation example: - -``` -./eng/scripts/Install-IronPython.ps1 /path/to/install/directory -framework net462 -``` +This document has been moved to the IronPython wiki: [Installing](https://github.com/IronLanguages/ironpython3/wiki/Installing) diff --git a/docs/modifying-the-sources.md b/docs/modifying-the-sources.md index 895587d2a..d4fdb68f7 100644 --- a/docs/modifying-the-sources.md +++ b/docs/modifying-the-sources.md @@ -1,26 +1 @@ -# TDD - -Bug fixes should be accompanied by a test that shows that the bug has been fixed. If the bug fix is fixing something that is covered by a test in the C Python test suite (`src/core/IronPython.StdLib/lib/test`) and that test is not currently enabled, try enabling the test in `tests\IronPython.Tests\Cases\*.ini` depending on the type of test it is. - -Most PR's will not be accepted if there is not a test included. - -# Coding conventions - - * We have a .editorconfig file with the coding conventions used in the project. Please use an editor that honors these settings. - - * Use [.NET Framework conventions for all identifiers](https://docs.microsoft.com/en-us/dotnet/standard/design-guidelines/naming-guidelines). - * There is no specific guideline for naming private fields in this document; we prefix field names with underscores (e.g. private string _fooBar;) so that use of the fields is easily distinguishable as a field access as opposed to a local variable access. - * If you're not sure about some convention, try to find out in the rest of the IronPython code or ask in the list. - * Use `/*!*/` for method parameters and instance fields that should never be null. [Spec# annotations](http://research.microsoft.com/specsharp). - * Do not use public fields (Base::algorithm, buffer). Use properties if it is necessary to expose the field or private/internal visibility otherwise. - * Use `readonly` if the field is not mutated after the object is constructed. - * Auto properties are to be used when possible instead of private fields with wrapping properties. - * String interpolation should use used instead of calls to `String.Format` - -# Validating the changes - -The following commands will build and run all the tests that are required to pass. If you get any failures, do report them to the mailing-list to see if they are expected or not. This command can usually run without any failures. - -``` -./make.ps1 test-all -``` \ No newline at end of file +This document has been moved to the IronPython wiki: [Modifying the sources](https://github.com/IronLanguages/ironpython3/wiki/Modifying-the-sources) diff --git a/docs/package-compatibility.md b/docs/package-compatibility.md index 0ed38bc10..e8e761c0c 100644 --- a/docs/package-compatibility.md +++ b/docs/package-compatibility.md @@ -1,54 +1 @@ -# Package compatibility - -Note that IronPython does not currently support packages which are C extension modules. - -## numpy - -:warning: Not supported - C extension module. - -## pandas - -:warning: Not supported - requires `numpy`. - -## pytest (4.6.11) - -To install: -``` -ipy -m pip install pytest==4.6.11 typing==3.10.0.0 -``` - -The package fails with (probably the same issue as https://github.com/IronLanguages/ironpython3/issues/1212): -``` -SystemError: Cannot access a closed file. -``` - -Edit `_pytest/capture.py` and replace: -```py -with f: - tmpfile = safe_text_dupfile(f, mode="wb+") -``` -with: -```py -tmpfile = EncodedFile(f, getattr(f, "encoding", "utf-8")) -``` - -## requests (2.21.0) - -To install: -``` -ipy -m pip install requests==2.21.0 -``` - -## sympy (1.4) - -To install: -``` -ipy -m pip install sympy==1.4 -``` - -The above will also automatically install `mpmath` 1.2.1 if not yet installed. - -`sympy` comes with an interactive console, which can be started with: -``` -ipy -m isympy -``` +This document has been moved to the IronPython wiki: [Package compatibility](https://github.com/IronLanguages/ironpython3/wiki/Package-compatibility) diff --git a/docs/upgrading-from-ipy2.md b/docs/upgrading-from-ipy2.md index 4f59586da..68fabc25b 100644 --- a/docs/upgrading-from-ipy2.md +++ b/docs/upgrading-from-ipy2.md @@ -1,257 +1 @@ -# Upgrading from IronPython 2 to 3 - -IronPython 3.4 uses Python 3.4 syntax and standard libraries and so your Python code will need to be updated accordingly. There are numerous tools and guides available on the web to help porting from Python 2 to 3. - -## Binary compatibility - -The IronPython 3 binaries are not compatible with the IronPython 2 binaries. Modules compiled with `clr.CompileModules` using IronPython 2 are not compatible and will need to be recompiled using IronPython 3. - -## Checking for IronPython - -In an effort to improve compatibility, `sys.platform` no longer returns `cli`. If you wish to check if you're running on IronPython the recommended pattern is to check that `sys.implementation.name` is equal to `ironpython`: - -```Python -if sys.implementation.name == "ironpython": - print("IronPython!") -``` - -## `None` is a keyword - -`None` is a keyword in Python 3 and trying to access a member called `None` will raise a `SyntaxError`. Since this name is frequently used in .NET code (e.g. in enums), code trying to use it is going to throw. You can use alternate syntax in order to access the .NET member, for example `getattr(x, "None")` or an accessor for enums `MyEnum["None"]`. - -```python -# IronPython 2 -System.StringSplitOptions.None -``` - -```python -# IronPython 3 -System.StringSplitOptions["None"] -``` - -Similarly, `True` and `False` are also keywords in Python 3. - -## Redirecting output - -With IronPython 2, standard output was written to the runtime's `SharedIO.OutputWriter` (which was `Console.Out` by default). This is no longer the case with IronPython 3 where the standard output is a binary stream. The output is now written to runtime's `SharedIO.OutputStream`. Similarly, standard input and error are now using `SharedIO.InputStream` and `SharedIO.ErrorStream` respectively. - -Because of this, using a `TextWriter` to capture output will no longer work. As a workaround, in order to use a `TextWriter` as the main method of redirection, one could wrap the writer inside a stream (for example, see [`TextStream`][TextStream]). - -```c# -// IronPython 2 -var engine = Python.CreateEngine(); -var textWriter = new MyTextWriter(); -// no longer works in IronPython 3! -engine.Runtime.IO.RedirectToConsole(); -Console.SetOut(textWriter); -``` - -```c# -// IronPython 3 -var engine = Python.CreateEngine(); -var textWriter = new MyTextWriter(); -engine.Runtime.IO.SetOutput(new TextStream(textWriter), textWriter); -``` - -Another way of achieving the redirection behavior similar to IronPython 2 is to set engine option `ConsoleSupportLevel` to `SupportLevel.Basic`. IronPython 3 still uses binary streams for standard input and output but **all three** standard streams are set to use `TextStream`, forwarding to the corresponding writers/reader. - -```c# -// IronPython 3 -var engine = Python.CreateEngine(new Dictionary { - { "ConsoleSupportLevel", Microsoft.Scripting.Runtime.SharedIO.SupportLevel.Basic }, -}); -var textWriter = new MyTextWriter(); -// works again! -engine.Runtime.IO.RedirectToConsole(); -Console.SetOut(textWriter); -``` - -This method is particularly useful when embedding the IronPython 3 engine in a host that sets console's writers/reader before the engine is created and the host's code is not accessible to the user (for instance, scripting in [LINQPad]). - -```c# -// IronPython 3 in LINQPad -var engine = Python.CreateEngine(new Dictionary { - { "ConsoleSupportLevel", Microsoft.Scripting.Runtime.SharedIO.SupportLevel.Basic }, -}); -engine.Execute("print('abc')"); // shows output in the "Results" pane -dynamic ans = engine.Execute("input()"); // pauses the script and asks for input at the bottom of the "Results" pane; terminate your input with Ctrl+Z, Enter -``` - -[TextStream]: https://github.com/IronLanguages/dlr/blob/main/Src/Microsoft.Scripting/Utils/TextStream.cs -[LINQPad]: https://www.linqpad.net/ - -## `int` Type - -One of the major backward incompatible changes in Python 3 is [PEP 237 – Unifying Long Integers and Integers][PEP 0237]: Essentially, `long` renamed to `int`. That is, there is only one built-in integral type, named `int`; but it behaves mostly like the old `long` type. From the pure Python perspective this means that `int` should be used wherever previously `long` was used. More consideration has to be applied in interop cases with .NET. - -The Python `int` type in IronPython 3 is implemented as `System.Numerics.BigInteger` (and not as `System.Int32` as it was in IronPython 2). It can contain in theory an arbitrarily large integer (only limited by the 2 GByte memory boundary). - -```pycon ->>> import clr ->>> clr.AddReference("System.Numerics") ->>> import System ->>> int is System.Numerics.BigInteger -True ->>> int is System.Int32 -False ->>> clr.GetClrType(int).Name -'BigInteger' -``` - -This means that in interop cases, when the `int` type is used (think generics), it will mean `BigInteger` and not `Int32` (which was the case in IronPython 2). To retain IronPython 2 semantics, replace `int` with `System.Int32`. - -Example: - -```python -# IronPython 2 -System.Collections.Generic.List[int] -``` - -```python -# IronPython 3 -System.Collections.Generic.List[System.Int32] -``` - -Overview of `int` type equivalency: - -| IronPython 2 | IronPython 3 | .NET | -| ------------ | ------------ | ---------------------------- | -| `long` | `int` | `System.Numerics.BigInteger` | -| `int` | N/A | `System.Int32` | - -### Instances of `int` - -As for instances of `int`, mostly for performance reasons, IronPython may use instances of `System.Int32` to hold smaller integers, while `BigInteger` instances are used for large integers. This is done transparently from the Python side, but again the distinction may become relevant for interop cases. Examples: - -```python -i = 1 # instance of Int32 -j = 1 << 31 # instance of BigInteger -k = j - 1 # still BigInteger, as one of the arguments makes the result type BigInteger -``` - -This means that the type of `Int32` objects is always reported as `int` (which is the same as `BigInteger`). If it is important to check what is the actual type of a given integer object, test if the object is an instance of `System.Int32`. (An alternative way is a test for the presence of `MaxValue` or `MinValue`. For those properties to be visible, `System` has to be imported first.) - -```pycon ->>> import System ->>> type(i) - ->>> isinstance(i, System.Int32) -True ->>> type(j) - ->>> isinstance(j, System.Int32) -False ->>> hex(i.MaxValue) -'0x7fffffff' -``` - -The creation of either `Int32` or `BigInteger` instances happens automatically by the `int` constructor. If for interop purposes it is important to create a `BigInteger` (despite the value fitting in 32 bits), use method `ToBigInteger`. It converts `Int32` values to `BigInteger` and leaves `BigInteger` values unaffected. - -```pycon ->>> bi = i.ToBigInteger() ->>> isinstance(j, System.Int32) -False -``` - -In the opposite direction, if it is essential to create `Int32` objects, either use constructors for `int` or `Int32`. In the current implementation, the former converts an integer to `Int32` if the value fits in 32 bits, otherwise it leaves it as `BigInteger`. The latter throws an exception if the conversion is not possible. Although the behavior of the constructor `int` may or may not change in the future, it is always guaranteed to convert the value to the "canonical form" adopted for that version of IronPython. - -```pycon ->>> # k is a BigInteger that fits in 32 bits ->>> isinstance(k, System.Int32) -False ->>> hex(k) -'0x7fffffff' ->>> ki = int(k) # converts k to Int32 ->>> isinstance(ki, System.Int32) -True ->>> ki = System.Int32(k) # also converts k to Int32 ->>> isinstance(ki, System.Int32) -True ->>> # j is a BigInteger that does not fit in 32 bits ->>> isinstance(j, System.Int32) -False ->>> hex(j) -'0x80000000' ->>> j = int(j) # no type change, j stays BigInteger ->>> isinstance(j, System.Int32) -False ->>> j = System.Int32(j) # conversion fails -Traceback (most recent call last): - File "", line 1, in -OverflowError: Arithmetic operation resulted in an overflow. -``` - -Such explicit conversions are in most cases unnecessary since the runtime recognizes `int`/`Int32` equivalence of instances and performs necessary conversions automatically. - -```pycon ->>> import System ->>> int_list = System.Collections.Generic.List[int]() ->>> int_list.Add(1) # Int32 instance converted to BigInteger ->>> int32_list = System.Collections.Generic.List[System.Int32]() ->>> int32_list.Add((1).ToBigInteger()) # BigInteger instance converted to Int32 ->>> int_list[0] == int32_list[0] -True -``` - -### Pickling and unpickling of `int` - -When an `int` object is serialized using `pickle.dump(x, myfile)` and subsequently unpickled with `x = pickle.load(myfile)` (or `pickle.loads(pickle.dumps(x))`, this has the same effect as reconstructing the object using the `int` constructor, i.e. `x = int(x)`. In other words, if the `x` instance was `BigInteger` but the value fits in `Int32`, it will be reconstructed as `Int32`. - -### BigIntegerV2 API - -In IronPython 2, `long` type carries an obsolete `BigIntegerV2` API, accessible after importing `System`. In IronPython 3 this API is not available directly on `int` instances (regardless of whether the instance is `Int32` or `BigInteger`), but is still accessible in some form through `Microsoft.Scripting.Utils.MathUtils` in `Microsoft.Dynamic.dll`. - -```pycon ->>> # IronPython 2 ->>> i = 1 # instance of Int32 (int) ->>> j = 1 << 64 # instance of BigInteger (long) ->>> import System ->>> j.GetWords() -Array[UInt32]((0, 0, 1)) ->>> i.GetWords() -Traceback (most recent call last): - File "", line 1, in -AttributeError: 'int' object has no attribute 'GetWords' ->>> long.GetWords(i) -Array[UInt32]((1)) -``` - -```pycon ->>> # IronPython 3 ->>> i = 1 # instance of Int32 (int) ->>> j = 1 << 64 # instance of BigInteger (int) ->>> import clr ->>> clr.AddReference("Microsoft.Dynamic") ->>> import Microsoft.Scripting.Utils.MathUtils ->>> clr.ImportExtensions(Microsoft.Scripting.Utils.MathUtils) ->>> j.GetWords() -Array[UInt32]((0, 0, 1)) ->>> i.GetWords() -Traceback (most recent call last): - File "", line 1, in -AttributeError: 'int' object has no attribute 'GetWords' ->>> Microsoft.Scripting.Utils.MathUtils.GetWords(i) -Array[UInt32]((1)) -``` - -Another set of Python-hidden methods on `long` in IronPython 2 that are not available on `int` in IronPython 3 are conversion methods with names like `ToXxx`. The recommended way to perform type conversions like those is to use type constructors. The exception is the conversion to `BigInteger` itself, for the reasons explained above. - -```python -# IronPython 2 -j = long(1) -i64 = j.ToInt64() -``` - -```python -# IronPython 3 -import System -j = (1).ToBigInteger() -i64 = System.Int64(j) -``` - -### `range` - -IronPython's `range` is a generator that produces a sequence of `int` values. The values are instances of `Int32` or `BigInteger`, depending on the actual integer value they represent. When `range` is used in a LINQ context, it exposes interface `IEnumerable` and all values generated are of type `Int32`. This limits the possible value to the range `Int32.MinValue` to `Int32.MaxValue`. - -[PEP 0237]: https://python.org/dev/peps/pep-0237 - +This document has been moved to the IronPython wiki: [Upgrading from IronPython2](https://github.com/IronLanguages/ironpython3/wiki/Upgrading-from-IronPython2) diff --git a/eng/package/choco/README.md b/eng/package/choco/README.md index a7d3adba0..15d938c18 100644 --- a/eng/package/choco/README.md +++ b/eng/package/choco/README.md @@ -9,7 +9,9 @@ The current target is Python 3.4, although features and behaviors from later ver ## Differences with CPython -While compatibility with CPython is one of our main goals with IronPython 3, there are still some differences that may cause issues. See [Differences from CPython](https://github.com/IronLanguages/ironpython3/blob/main/docs/differences-from-c-python.md) for details. + +While compatibility with CPython is one of our main goals with IronPython 3, there are still some differences that may cause issues. See [Differences from CPython](https://github.com/IronLanguages/ironpython3/wiki/Differences-from-CPython) for details. ## Package compatibility -See the [Package compatibility](https://github.com/IronLanguages/ironpython3/blob/main/docs/package-compatibility.md) document for information on compatibility with popular Python packages. + +See the [Package compatibility](https://github.com/IronLanguages/ironpython3/wiki/Package-compatibility) document for information on compatibility with popular Python packages. diff --git a/eng/package/dotnettool/README.md b/eng/package/dotnettool/README.md index 690f64324..394eff5f6 100644 --- a/eng/package/dotnettool/README.md +++ b/eng/package/dotnettool/README.md @@ -9,8 +9,8 @@ The current target is Python 3.4, although features and behaviors from later ver ## Differences with CPython -While compatibility with CPython is one of our main goals with IronPython 3, there are still some differences that may cause issues. See [Differences from CPython](https://github.com/IronLanguages/ironpython3/blob/main/docs/differences-from-c-python.md) for details. +While compatibility with CPython is one of our main goals with IronPython 3, there are still some differences that may cause issues. See [Differences from CPython](https://github.com/IronLanguages/ironpython3/wiki/Differences-from-CPython) for details. ## Package compatibility -See the [Package compatibility](https://github.com/IronLanguages/ironpython3/blob/main/docs/package-compatibility.md) document for information on compatibility with popular Python packages. +See the [Package compatibility](https://github.com/IronLanguages/ironpython3/wiki/Package-compatibility) document for information on compatibility with popular Python packages. diff --git a/eng/package/nuget/README.md b/eng/package/nuget/README.md index afcc1f187..dc08f8380 100644 --- a/eng/package/nuget/README.md +++ b/eng/package/nuget/README.md @@ -22,8 +22,8 @@ System.Console.WriteLine(greetings("world")); ## Differences with CPython -While compatibility with CPython is one of our main goals with IronPython 3, there are still some differences that may cause issues. See [Differences from CPython](https://github.com/IronLanguages/ironpython3/blob/main/docs/differences-from-c-python.md) for details. +While compatibility with CPython is one of our main goals with IronPython 3, there are still some differences that may cause issues. See [Differences from CPython](https://github.com/IronLanguages/ironpython3/wiki/Differences-from-CPython) for details. ## Package compatibility -See the [Package compatibility](https://github.com/IronLanguages/ironpython3/blob/main/docs/package-compatibility.md) document for information on compatibility with popular Python packages. Note that to run most packages, IronPython Standard Library must be present. +See the [Package compatibility](https://github.com/IronLanguages/ironpython3/wiki/Package-compatibility) document for information on compatibility with popular Python packages. Note that to run most packages, IronPython Standard Library must be present. diff --git a/eng/package/zip/README.md b/eng/package/zip/README.md index e245c0305..6641eab3e 100644 --- a/eng/package/zip/README.md +++ b/eng/package/zip/README.md @@ -50,8 +50,8 @@ System.Console.WriteLine(greetings("world")); ## Differences with CPython -While compatibility with CPython is one of our main goals with IronPython 3, there are still some differences that may cause issues. See [Differences from CPython](https://github.com/IronLanguages/ironpython3/blob/main/docs/differences-from-c-python.md) for details. +While compatibility with CPython is one of our main goals with IronPython 3, there are still some differences that may cause issues. See [Differences from CPython](https://github.com/IronLanguages/ironpython3/wiki/Differences-from-CPython) for details. ## Package compatibility -See the [Package compatibility](https://github.com/IronLanguages/ironpython3/blob/main/docs/package-compatibility.md) document for information on compatibility with popular packages. Note that to run most packages, IronPython Standard Library must be present. +See the [Package compatibility](https://github.com/IronLanguages/ironpython3/wiki/Package-compatibility) document for information on compatibility with popular packages. Note that to run most packages, IronPython Standard Library must be present.