From 1f817013c9f2779d52c6b476a2a2da47357ce92e Mon Sep 17 00:00:00 2001 From: Sangyub Lee Date: Fri, 25 Aug 2023 15:43:58 -0500 Subject: [PATCH 01/17] SymPEP for static typing --- .gitignore | 1 + SymPEP-XXXX.md | 75 ++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 76 insertions(+) create mode 100644 .gitignore create mode 100644 SymPEP-XXXX.md diff --git a/.gitignore b/.gitignore new file mode 100644 index 0000000..600d2d3 --- /dev/null +++ b/.gitignore @@ -0,0 +1 @@ +.vscode \ No newline at end of file diff --git a/SymPEP-XXXX.md b/SymPEP-XXXX.md new file mode 100644 index 0000000..d5e91b5 --- /dev/null +++ b/SymPEP-XXXX.md @@ -0,0 +1,75 @@ +# SymPEP X — Adopting Static Typing in SymPy + +**Author:** Sangyub Lee + +**Status:** Draft + +**Type:** Standards Track + +**Created:** 2023-08-25 + +**Resolution:** [Link to Discussion] + +## Abstract + +This SymPEP proposes the adoption of static typing in the SymPy codebase. Static typing can enhance the development experience, improve code quality, and facilitate better collaboration among contributors. + +## Motivation and Scope + +The current SymPy codebase is predominantly dynamically typed, which can lead to runtime errors and make it harder to understand the codebase. The adoption of static typing will provide better tooling support, catch type-related errors at compile-time, and improve the overall robustness of the library. This SymPEP aims to define the scope and guidelines for introducing static typing to SymPy. + +## Usage and Impact + +With static typing, users of SymPy will benefit from improved code suggestions, better error messages, and increased confidence in the correctness of their code. For instance, when working with symbolic expressions, the static type system can help catch potential issues in function calls, attribute accesses, and type mismatches. This will lead to a more intuitive and reliable programming experience for SymPy users. + +```python +from typing import List +from sympy import Expr, Symbol + +def differentiate(expr: Expr, var: Symbol) -> Expr: + """ + Differentiate a SymPy expression with respect to a variable. + """ + return expr.diff(var) + +def simplify_expressions(expressions: List[Expr]) -> List[Expr]: + """ + Simplify a list of SymPy expressions. + """ + return [expr.simplify() for expr in expressions] + +``` + +## Backwards Compatibility + +Introducing static typing to SymPy may break backwards compatibility for code that relies on dynamically typed behavior. Users who heavily depend on runtime type inference might need to update their code to match the new type annotations. + +## Detailed Description + +This SymPEP proposes the gradual introduction of static type annotations using tools like Python's `typing` module and third-party type checkers such as `mypy` or `pyright`. The process will involve identifying critical modules, functions, and classes to begin the static typing integration. We will define guidelines for annotating function signatures, class attributes, and return types. The goal is to maintain compatibility with existing dynamically typed code while allowing for a smooth transition. + +## Implementation + +1. Identify key modules for static typing. +2. Start by adding type annotations to function signatures and class attributes. +3. Use `mypy` or `pyright` to perform static type checking and address any issues. +4. Gradually propagate static typing to dependent modules and functions. +5. Update documentation to reflect the new static typing conventions. + +The implementation progress will be tracked through pull requests linked in this section. + +## Alternatives + +An alternative approach would be to maintain the status quo of dynamic typing. However, this could lead to ongoing challenges in maintaining code quality and preventing runtime errors, especially as the SymPy codebase continues to evolve. + +## Discussion + +- [Link to Mailing List Discussion] + +## References + +- [Python Typing Documentation](https://docs.python.org/3/library/typing.html) + +## Copyright + +This document has been placed in the public domain. From 54932ad95a645e725c9005689844c0c007c25e08 Mon Sep 17 00:00:00 2001 From: Sangyub Lee Date: Fri, 25 Aug 2023 15:47:50 -0500 Subject: [PATCH 02/17] Add final procedure of using strict mode --- SymPEP-XXXX.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/SymPEP-XXXX.md b/SymPEP-XXXX.md index d5e91b5..55249ca 100644 --- a/SymPEP-XXXX.md +++ b/SymPEP-XXXX.md @@ -55,8 +55,7 @@ This SymPEP proposes the gradual introduction of static type annotations using t 3. Use `mypy` or `pyright` to perform static type checking and address any issues. 4. Gradually propagate static typing to dependent modules and functions. 5. Update documentation to reflect the new static typing conventions. - -The implementation progress will be tracked through pull requests linked in this section. +6. Use `mypy` or `pyright` with strict mode. ## Alternatives From 8decf0e2e29d35a8cc9c11eea77d1d969cb32ffe Mon Sep 17 00:00:00 2001 From: Sangyub Lee Date: Fri, 25 Aug 2023 15:51:03 -0500 Subject: [PATCH 03/17] Fix trailing whitespace --- .gitignore | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.gitignore b/.gitignore index 600d2d3..722d5e7 100644 --- a/.gitignore +++ b/.gitignore @@ -1 +1 @@ -.vscode \ No newline at end of file +.vscode From 9e5474dc2d3062e021080a1dbd3b289d824f2b41 Mon Sep 17 00:00:00 2001 From: Sangyub Lee Date: Fri, 25 Aug 2023 16:58:11 -0500 Subject: [PATCH 04/17] Add examples of dynamic typing --- SymPEP-XXXX.md | 44 ++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 44 insertions(+) diff --git a/SymPEP-XXXX.md b/SymPEP-XXXX.md index 55249ca..9cc5616 100644 --- a/SymPEP-XXXX.md +++ b/SymPEP-XXXX.md @@ -22,6 +22,8 @@ The current SymPy codebase is predominantly dynamically typed, which can lead to With static typing, users of SymPy will benefit from improved code suggestions, better error messages, and increased confidence in the correctness of their code. For instance, when working with symbolic expressions, the static type system can help catch potential issues in function calls, attribute accesses, and type mismatches. This will lead to a more intuitive and reliable programming experience for SymPy users. +For example, the functions can be static typed as follows: + ```python from typing import List from sympy import Expr, Symbol @@ -37,9 +39,51 @@ def simplify_expressions(expressions: List[Expr]) -> List[Expr]: Simplify a list of SymPy expressions. """ return [expr.simplify() for expr in expressions] +``` + +which is better than the dynamically typed versions: + +```python +def differentiate(expr, var): + """ + Differentiate a SymPy expression with respect to a variable. + """ + return expr.diff(var) +def simplify_expressions(expressions): + """ + Simplify a list of SymPy expressions. + """ + return [expr.simplify() for expr in expressions] ``` +which is not friendly for users because they cannot know the type of the input and output of the functions, before running the functions. + +```python +from sympy import Expr, Symbol + +def differentiate(expr, var): + """ + Differentiate a SymPy expression with respect to a variable. + """ + if isinstance(expr, Expr) and isinstance(var, Symbol): + return expr.diff(var) + else: + raise TypeError("expr must be a SymPy expression and var must be a SymPy symbol") + +def simplify_expressions(expressions): + """ + Simplify a list of SymPy expressions. + """ + if isinstance(expressions, list): + if all(isinstance(expr, Expr) for expr in expressions): + return [expr.simplify() for expr in expressions] + else: + raise TypeError("expressions must be a list of SymPy expressions") +``` + +which is more verbose and less efficient than the static typed versions, because of added runtime type checks. + ## Backwards Compatibility Introducing static typing to SymPy may break backwards compatibility for code that relies on dynamically typed behavior. Users who heavily depend on runtime type inference might need to update their code to match the new type annotations. From 882c801f6abab06000b2f48bb57ed47ad22cbc42 Mon Sep 17 00:00:00 2001 From: Sangyub Lee Date: Fri, 25 Aug 2023 17:02:00 -0500 Subject: [PATCH 05/17] Elaborate about Python code without type hints --- SymPEP-XXXX.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/SymPEP-XXXX.md b/SymPEP-XXXX.md index 9cc5616..3962c11 100644 --- a/SymPEP-XXXX.md +++ b/SymPEP-XXXX.md @@ -57,7 +57,8 @@ def simplify_expressions(expressions): return [expr.simplify() for expr in expressions] ``` -which is not friendly for users because they cannot know the type of the input and output of the functions, before running the functions. +which is not friendly for users because they can simplify expressions with a list of integers or strings. The static typed version can catch this error at compile-time. + ```python from sympy import Expr, Symbol From 15e24503d7eeacbf98b49cfd8896145e414c9a54 Mon Sep 17 00:00:00 2001 From: Sangyub Lee Date: Sat, 26 Aug 2023 05:12:57 -0500 Subject: [PATCH 06/17] Add more lines case by case in the detailed description --- SymPEP-XXXX.md | 19 ++++++++++++++++++- 1 file changed, 18 insertions(+), 1 deletion(-) diff --git a/SymPEP-XXXX.md b/SymPEP-XXXX.md index 3962c11..4ff11e7 100644 --- a/SymPEP-XXXX.md +++ b/SymPEP-XXXX.md @@ -93,6 +93,20 @@ Introducing static typing to SymPy may break backwards compatibility for code th This SymPEP proposes the gradual introduction of static type annotations using tools like Python's `typing` module and third-party type checkers such as `mypy` or `pyright`. The process will involve identifying critical modules, functions, and classes to begin the static typing integration. We will define guidelines for annotating function signatures, class attributes, and return types. The goal is to maintain compatibility with existing dynamically typed code while allowing for a smooth transition. +Authors of new classes, functions, or modules in SymPy should be encouraged to write their code with static typing, unless they encounter a situation where achieving this is difficult or not possible. In such cases, they are expected to include a comment explaining the reasons preventing static typing. + +Introducing new dynamically typed code initially can lead to the accumulation of technical debt. It's recognized that migrating existing dynamically typed code later is significantly more challenging than initially writing code with static typing. Therefore, introducing new dynamically typed code should be approached cautiously. + +It's important to note that tools like mypy and pyright are capable of inferring types, facilitating the incorporation of static typing without a steep learning curve. By adding a few annotations, code can be made cleaner and the transition to static typing across the entire codebase can be eased. + +For functions, classes, and modules internally used by SymPy that currently feature unnecessary dynamic type checks, a shift towards static typing should be promoted. This transition can help eliminate these unnecessary checks and subsequently enhance the overall performance of the SymPy codebase. + +Similarly, functions, classes, and modules within SymPy that intentionally avoided runtime type checks for performance reasons should consider embracing static typing. Static typing undoubtedly mitigates performance overhead while providing better bug detection related to type errors. + +However, in the case of core and public functions and classes, such as ``sympify``, ``simplify``, or ``lambdify``, which have historically relied on dynamic typing for an extended period, the introduction of static typing should be approached judiciously. It should be implemented for these core components only if it doesn't disrupt backward compatibility. + +It's worth noting that SymPy has devoted considerable effort over time to address type-related issues of Python objects within SymPy. This was especially relevant during periods when the Python type system was less mature or lacked type hinting capabilities. + ## Implementation 1. Identify key modules for static typing. @@ -108,11 +122,14 @@ An alternative approach would be to maintain the status quo of dynamic typing. H ## Discussion -- [Link to Mailing List Discussion] +- [Look into using type hints](https://github.com/sympy/sympy/issues/17945) ## References - [Python Typing Documentation](https://docs.python.org/3/library/typing.html) +- [PEP-484](https://peps.python.org/pep-0484/) +- [MyPy Documentation](https://mypy.readthedocs.io/en/stable/) +- [Pyright Documentation](https://microsoft.github.io/pyright/) ## Copyright From 952286db9c7f8d467a6c54ef13e53b783afb7917 Mon Sep 17 00:00:00 2001 From: Sangyub Lee Date: Sat, 26 Aug 2023 05:57:25 -0500 Subject: [PATCH 07/17] Updates --- SymPEP-XXXX.md | 18 ++++++++++-------- 1 file changed, 10 insertions(+), 8 deletions(-) diff --git a/SymPEP-XXXX.md b/SymPEP-XXXX.md index 4ff11e7..7ee0b26 100644 --- a/SymPEP-XXXX.md +++ b/SymPEP-XXXX.md @@ -91,21 +91,23 @@ Introducing static typing to SymPy may break backwards compatibility for code th ## Detailed Description -This SymPEP proposes the gradual introduction of static type annotations using tools like Python's `typing` module and third-party type checkers such as `mypy` or `pyright`. The process will involve identifying critical modules, functions, and classes to begin the static typing integration. We will define guidelines for annotating function signatures, class attributes, and return types. The goal is to maintain compatibility with existing dynamically typed code while allowing for a smooth transition. +This SymPEP proposes the gradual introduction of static type annotations using tools like Python's typing module and third-party type checkers such as ``mypy`` or ``pyright``. The process will involve identifying critical modules, functions, and classes to initiate the integration of static typing. Guidelines will be established for annotating function signatures, class attributes, and return types. The objective is to maintain compatibility with existing dynamically typed code while facilitating a seamless transition. -Authors of new classes, functions, or modules in SymPy should be encouraged to write their code with static typing, unless they encounter a situation where achieving this is difficult or not possible. In such cases, they are expected to include a comment explaining the reasons preventing static typing. +Authors of new classes, functions, or modules in SymPy should be encouraged to write their code with static typing, unless they encounter a situation where achieving this is difficult or not possible. In such cases, the authors should be prompted to provide type stubs for their code, allowing for users to benefit from static typing. -Introducing new dynamically typed code initially can lead to the accumulation of technical debt. It's recognized that migrating existing dynamically typed code later is significantly more challenging than initially writing code with static typing. Therefore, introducing new dynamically typed code should be approached cautiously. +It's important to note that tools like ``mypy`` and ``pyright`` are capable of inferring types, which simplifies the process of incorporating static typing without requiring a steep learning curve. By adding a few annotations, the code can be enhanced in terms of clarity, facilitating the transition to static typing across the entire codebase. -It's important to note that tools like mypy and pyright are capable of inferring types, facilitating the incorporation of static typing without a steep learning curve. By adding a few annotations, code can be made cleaner and the transition to static typing across the entire codebase can be eased. +Encouraging the SymPy community to collaborate on creating ``.pyi`` files to provide type stubs for all exported functions and classes in SymPy is recommended for fostering public access to type information. -For functions, classes, and modules internally used by SymPy that currently feature unnecessary dynamic type checks, a shift towards static typing should be promoted. This transition can help eliminate these unnecessary checks and subsequently enhance the overall performance of the SymPy codebase. +Although the core CPython is inherently dynamically typed, nearly all core CPython standard libraries are equipped with type annotations. Similarly, popular third-party libraries like ``numpy``, ``scipy``, or ``pandas`` provide users with type annotations. -Similarly, functions, classes, and modules within SymPy that intentionally avoided runtime type checks for performance reasons should consider embracing static typing. Static typing undoubtedly mitigates performance overhead while providing better bug detection related to type errors. +SymPy holds a pivotal role as a library used by many other libraries and stands at the forefront of the supply chain of scientific computing libraries. However, it currently lags behind technical standards by lacking comprehensive type annotations. -However, in the case of core and public functions and classes, such as ``sympify``, ``simplify``, or ``lambdify``, which have historically relied on dynamic typing for an extended period, the introduction of static typing should be approached judiciously. It should be implemented for these core components only if it doesn't disrupt backward compatibility. +The following forms of typing are permissible to be added to the sympy code base: -It's worth noting that SymPy has devoted considerable effort over time to address type-related issues of Python objects within SymPy. This was especially relevant during periods when the Python type system was less mature or lacked type hinting capabilities. +For functions, classes, and modules internally used by SymPy that currently include unnecessary dynamic type checks, advocating for a shift towards static typing is advisable. This transition can help eliminate these redundant checks and consequently enhance the overall performance of the SymPy codebase. + +Similarly, functions, classes, and modules within SymPy that intentionally avoided runtime type checks for performance reasons should consider embracing static typing. Static typing undoubtedly mitigates performance overhead while providing better bug detection capabilities related to type errors. ## Implementation From c802f813e64869b9ae313c0af60b45c4b4364a49 Mon Sep 17 00:00:00 2001 From: Sangyub Lee Date: Sat, 26 Aug 2023 05:58:34 -0500 Subject: [PATCH 08/17] Update --- SymPEP-XXXX.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/SymPEP-XXXX.md b/SymPEP-XXXX.md index 7ee0b26..5a210a2 100644 --- a/SymPEP-XXXX.md +++ b/SymPEP-XXXX.md @@ -93,7 +93,7 @@ Introducing static typing to SymPy may break backwards compatibility for code th This SymPEP proposes the gradual introduction of static type annotations using tools like Python's typing module and third-party type checkers such as ``mypy`` or ``pyright``. The process will involve identifying critical modules, functions, and classes to initiate the integration of static typing. Guidelines will be established for annotating function signatures, class attributes, and return types. The objective is to maintain compatibility with existing dynamically typed code while facilitating a seamless transition. -Authors of new classes, functions, or modules in SymPy should be encouraged to write their code with static typing, unless they encounter a situation where achieving this is difficult or not possible. In such cases, the authors should be prompted to provide type stubs for their code, allowing for users to benefit from static typing. +Authors of new classes, functions, or modules in SymPy should be encouraged to write their code with static typing, unless they encounter a situation where achieving this is difficult or not possible. Even in such cases, the authors should be prompted to provide type stubs for their code, allowing for users to benefit from static typing. It's important to note that tools like ``mypy`` and ``pyright`` are capable of inferring types, which simplifies the process of incorporating static typing without requiring a steep learning curve. By adding a few annotations, the code can be enhanced in terms of clarity, facilitating the transition to static typing across the entire codebase. From 6cf9b11493511efc7f71533248a9a174206945c3 Mon Sep 17 00:00:00 2001 From: Sangyub Lee Date: Sat, 26 Aug 2023 08:36:22 -0500 Subject: [PATCH 09/17] Address all alternatives in discussion --- SymPEP-XXXX.md | 79 ++++++++++++++++++++++++++++++++++++++++++-------- 1 file changed, 67 insertions(+), 12 deletions(-) diff --git a/SymPEP-XXXX.md b/SymPEP-XXXX.md index 5a210a2..658f5a1 100644 --- a/SymPEP-XXXX.md +++ b/SymPEP-XXXX.md @@ -93,7 +93,7 @@ Introducing static typing to SymPy may break backwards compatibility for code th This SymPEP proposes the gradual introduction of static type annotations using tools like Python's typing module and third-party type checkers such as ``mypy`` or ``pyright``. The process will involve identifying critical modules, functions, and classes to initiate the integration of static typing. Guidelines will be established for annotating function signatures, class attributes, and return types. The objective is to maintain compatibility with existing dynamically typed code while facilitating a seamless transition. -Authors of new classes, functions, or modules in SymPy should be encouraged to write their code with static typing, unless they encounter a situation where achieving this is difficult or not possible. Even in such cases, the authors should be prompted to provide type stubs for their code, allowing for users to benefit from static typing. +Authors of new classes, functions, or modules in SymPy should be encouraged to provide the ``.pyi`` for their implementations, unless they encounter a situation where achieving this is difficult or not possible. It's important to note that tools like ``mypy`` and ``pyright`` are capable of inferring types, which simplifies the process of incorporating static typing without requiring a steep learning curve. By adding a few annotations, the code can be enhanced in terms of clarity, facilitating the transition to static typing across the entire codebase. @@ -103,24 +103,79 @@ Although the core CPython is inherently dynamically typed, nearly all core CPyth SymPy holds a pivotal role as a library used by many other libraries and stands at the forefront of the supply chain of scientific computing libraries. However, it currently lags behind technical standards by lacking comprehensive type annotations. -The following forms of typing are permissible to be added to the sympy code base: +## Implementation -For functions, classes, and modules internally used by SymPy that currently include unnecessary dynamic type checks, advocating for a shift towards static typing is advisable. This transition can help eliminate these redundant checks and consequently enhance the overall performance of the SymPy codebase. +1. Identify Key Modules for Static Typing -Similarly, functions, classes, and modules within SymPy that intentionally avoided runtime type checks for performance reasons should consider embracing static typing. Static typing undoubtedly mitigates performance overhead while providing better bug detection capabilities related to type errors. + Identify the modules or components in your codebase that are essential candidates for static typing. These could include frequently used public functions, classes, and methods. -## Implementation +2. Use `.pyi` Stub Files + + Stub files (`.pyi` files) are separate files that contain type hints for external modules or libraries that isn't implemented with static typing. These files serve as references for static type checking tools like mypy or pyright and enable them to understand the types and interfaces of external code. + + Create a .pyi stub file for each SymPy modules by naming it with the same name as the module you're stubbing, and place it in the same directory as your code. For example, if you're stubbing the `prime` module, create a file named `prime.pyi`. + +3. Start by Adding Type Annotations + + Begin by adding type annotations to function signatures and class attributes. For functions, specify the argument types and return type using the `->` syntax. For classes, annotate attributes in the `__init__` method and methods within the class. + + ```python + # Original code + def add(a, b): + ... + + # Annotated with type hints + def add(a: Integer, b: Integer) -> Integer: + ... + ``` + + ```python + # Original class + class Circle: + def __init__(self, center, radius): + ... + + # Annotated with type hints + class Circle: + def __init__(self, center: Point2D, radius: Expr): + ... + ``` + +4. Gradually Propagate Static Typing + + Gradually add type annotations to dependent modules and functions. As you do this, ensure that you're not only annotating your code but also updating any function calls or method invocations to adhere to the new type annotations. + +5. Update Documentation -1. Identify key modules for static typing. -2. Start by adding type annotations to function signatures and class attributes. -3. Use `mypy` or `pyright` to perform static type checking and address any issues. -4. Gradually propagate static typing to dependent modules and functions. -5. Update documentation to reflect the new static typing conventions. -6. Use `mypy` or `pyright` with strict mode. + As you add type annotations, remember to update your code documentation to reflect the new static typing conventions. This will help other developers understand the expected types and enhance the overall clarity of your codebase. + +6. Use Strict Mode with mypy or pyright + + Both mypy and pyright offer a strict mode that enforces more comprehensive type checking. Enable strict mode in your static type checking tool to catch even subtle type-related issues. + +Remember that static typing is an iterative process. Start with the most critical parts of your codebase, or most simple and easiest parts of the codebase, and gradually expand the coverage as you become more comfortable with the process. This approach helps maintain a balance between improving code quality and avoiding overwhelming upfront changes. ## Alternatives -An alternative approach would be to maintain the status quo of dynamic typing. However, this could lead to ongoing challenges in maintaining code quality and preventing runtime errors, especially as the SymPy codebase continues to evolve. +### Keeping the status quo of static typing + +An alternative perspective is to maintain the current dynamic typing approach. However, this decision could potentially give rise to persistent challenges in upholding code quality and mitigating runtime errors, particularly as the SymPy codebase continues to evolve. + +### Conservatism and Community Implications + +To conserve about not using any type hints in the SymPy, additional concern regarding its impact on the SymPy community. By adhering strictly to dynamic typing and favoring duck typing, there's a risk of creating a division between users who prefer static typing for its benefits and those who are more inclined towards the existing syntax. This division might inadvertently isolate those who seek the advantages of static typing and potentially alienate them from the community. Consequently, this could lead to a situation where users start exploring alternative of SymPy instead of contributing to SymPy's improvement. + +### Challenges of Comprehensive Annotation + +Another approach to consider is fully annotating the entire SymPy codebase with inline type hints. While this strategy offers a comprehensive solution, it's worth noting that it presents significant technical challenges. Certain SymPy functions, like ``solve``, inherently defy easy expression through type annotations due to their complexity. Attempting to annotate these functions might introduce more confusion than clarity, making this approach less feasible in practice. + +### The Role of .pyi Stubs + +In light of the aforementioned considerations, ``.pyi`` stub files emerge as an appealing middle ground to introduce static typing to the core of SymPy. The advantage of this approach lies in its non-intrusive nature. It doesn't necessitate altering the existing codebase, and it has no impact on the documentation. This means that the project can gradually adopt static typing without undergoing immediate massive changes, striking a balance between the advantages of static typing and the project's existing dynamics. + +### Verification and Community Management + +It's important to acknowledge that while ``.pyi`` files offer a promising route, they are not without their challenges. There's a potential for these stub files to define unsound types that don't accurately reflect the implementation. This underscores the need for human reviewers to meticulously assess their correctness ensure their alignment with the project's implementation. The community's involvement in managing these ``.pyi`` files becomes crucial for maintaining the integrity of the type information and promoting accurate static type checking. ## Discussion From 24b7327d95f05db146aec91dee4f35f8c01b27cc Mon Sep 17 00:00:00 2001 From: Sangyub Lee Date: Sat, 26 Aug 2023 08:38:52 -0500 Subject: [PATCH 10/17] Remark about backward compatibility of users who don't use type checkers --- SymPEP-XXXX.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/SymPEP-XXXX.md b/SymPEP-XXXX.md index 658f5a1..fe1e124 100644 --- a/SymPEP-XXXX.md +++ b/SymPEP-XXXX.md @@ -59,7 +59,6 @@ def simplify_expressions(expressions): which is not friendly for users because they can simplify expressions with a list of integers or strings. The static typed version can catch this error at compile-time. - ```python from sympy import Expr, Symbol @@ -87,7 +86,8 @@ which is more verbose and less efficient than the static typed versions, because ## Backwards Compatibility -Introducing static typing to SymPy may break backwards compatibility for code that relies on dynamically typed behavior. Users who heavily depend on runtime type inference might need to update their code to match the new type annotations. +There are no backwards compatibility issues with this SymPEP, for users +who don't use the type checkers like ``mypy`` or ``pyright``. However, for users who use the type checkers, they need to update their code to match the new type annotations. ## Detailed Description From 8cbb2adb9e277243c31bb32494209afa09093eb1 Mon Sep 17 00:00:00 2001 From: Sangyub Lee Date: Sat, 26 Aug 2023 09:54:50 -0500 Subject: [PATCH 11/17] Add PEP-561 Reference --- SymPEP-XXXX.md | 1 + 1 file changed, 1 insertion(+) diff --git a/SymPEP-XXXX.md b/SymPEP-XXXX.md index fe1e124..b49aac8 100644 --- a/SymPEP-XXXX.md +++ b/SymPEP-XXXX.md @@ -185,6 +185,7 @@ It's important to acknowledge that while ``.pyi`` files offer a promising route, - [Python Typing Documentation](https://docs.python.org/3/library/typing.html) - [PEP-484](https://peps.python.org/pep-0484/) +- [PEP-561](https://peps.python.org/pep-0561/) - [MyPy Documentation](https://mypy.readthedocs.io/en/stable/) - [Pyright Documentation](https://microsoft.github.io/pyright/) From 9bf56ed1d3bee09cfa807f6974d24e3ff6ae32c3 Mon Sep 17 00:00:00 2001 From: Sangyub Lee Date: Sat, 26 Aug 2023 10:43:14 -0500 Subject: [PATCH 12/17] Add a section for LPython --- SymPEP-XXXX.md | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/SymPEP-XXXX.md b/SymPEP-XXXX.md index b49aac8..44abb61 100644 --- a/SymPEP-XXXX.md +++ b/SymPEP-XXXX.md @@ -177,6 +177,12 @@ In light of the aforementioned considerations, ``.pyi`` stub files emerge as an It's important to acknowledge that while ``.pyi`` files offer a promising route, they are not without their challenges. There's a potential for these stub files to define unsound types that don't accurately reflect the implementation. This underscores the need for human reviewers to meticulously assess their correctness ensure their alignment with the project's implementation. The community's involvement in managing these ``.pyi`` files becomes crucial for maintaining the integrity of the type information and promoting accurate static type checking. +### Using `S` for SymPy objects + +LPython is currently engaged in the development of a Python compiler. This compiler harnesses the benefits of statically typed functions, classes, and symbolic expressions found in SymPy. + +To enhance collaboration and foster compatibility, there's a proposal to initiate a discussion regarding the establishment of type annotations as the standardized technical interface for interacting with LPython. This approach would involve soliciting input not only from the SymPy community but also potentially from external stakeholders, including 3rd party computer algebra systems and compilers. Rather than making internal decisions and implementing changes solely within the SymPy community, this effort aims to gather broader perspectives and create a consensus-driven approach to drive the evolution of LPython and its interface standards. + ## Discussion - [Look into using type hints](https://github.com/sympy/sympy/issues/17945) From 2caed2848a00346eedb8472b4b1fd0a00616281e Mon Sep 17 00:00:00 2001 From: Sangyub Lee Date: Sat, 26 Aug 2023 11:11:19 -0500 Subject: [PATCH 13/17] Add link for discussion --- SymPEP-XXXX.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/SymPEP-XXXX.md b/SymPEP-XXXX.md index 44abb61..9722d1b 100644 --- a/SymPEP-XXXX.md +++ b/SymPEP-XXXX.md @@ -8,7 +8,7 @@ **Created:** 2023-08-25 -**Resolution:** [Link to Discussion] +**Resolution:** `https://github.com/sympy/SymPEPs/pull/4` ## Abstract From c91f4bfde46f3e4f060e3f5a177bf5cdb5022b8e Mon Sep 17 00:00:00 2001 From: Sangyub Lee Date: Sat, 26 Aug 2023 11:39:51 -0500 Subject: [PATCH 14/17] Add a discussion about allowed type annotations --- SymPEP-XXXX.md | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/SymPEP-XXXX.md b/SymPEP-XXXX.md index 9722d1b..c6717dc 100644 --- a/SymPEP-XXXX.md +++ b/SymPEP-XXXX.md @@ -177,6 +177,14 @@ In light of the aforementioned considerations, ``.pyi`` stub files emerge as an It's important to acknowledge that while ``.pyi`` files offer a promising route, they are not without their challenges. There's a potential for these stub files to define unsound types that don't accurately reflect the implementation. This underscores the need for human reviewers to meticulously assess their correctness ensure their alignment with the project's implementation. The community's involvement in managing these ``.pyi`` files becomes crucial for maintaining the integrity of the type information and promoting accurate static type checking. +### Allowed Type Annotations + +The nature and extent of permissible type annotations are open to discussion. +Our stance is that there are no constraints on allowable type annotations, +as long as they adhere to PEP guidelines and are compatible with the minimum Python version supported by SymPy. +Nevertheless, these annotations must be structured +according to ``.pyi`` files for type hinting purposes. + ### Using `S` for SymPy objects LPython is currently engaged in the development of a Python compiler. This compiler harnesses the benefits of statically typed functions, classes, and symbolic expressions found in SymPy. From 878813a7d536df5b23a672a7d0510937f70d26e9 Mon Sep 17 00:00:00 2001 From: Sangyub Lee Date: Sat, 26 Aug 2023 11:41:33 -0500 Subject: [PATCH 15/17] Change static -> duck --- SymPEP-XXXX.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/SymPEP-XXXX.md b/SymPEP-XXXX.md index c6717dc..fc2956b 100644 --- a/SymPEP-XXXX.md +++ b/SymPEP-XXXX.md @@ -157,7 +157,7 @@ Remember that static typing is an iterative process. Start with the most critica ## Alternatives -### Keeping the status quo of static typing +### Keeping the status quo of duck typing An alternative perspective is to maintain the current dynamic typing approach. However, this decision could potentially give rise to persistent challenges in upholding code quality and mitigating runtime errors, particularly as the SymPy codebase continues to evolve. From 325b5a544f7f5a871abcfb92f0142509c4a156f0 Mon Sep 17 00:00:00 2001 From: Sangyub Lee Date: Sat, 26 Aug 2023 13:45:54 -0500 Subject: [PATCH 16/17] Fix indentation of code and add section for type checkers --- SymPEP-XXXX.md | 18 ++++++++++++------ 1 file changed, 12 insertions(+), 6 deletions(-) diff --git a/SymPEP-XXXX.md b/SymPEP-XXXX.md index fc2956b..112572a 100644 --- a/SymPEP-XXXX.md +++ b/SymPEP-XXXX.md @@ -131,14 +131,14 @@ SymPy holds a pivotal role as a library used by many other libraries and stands ```python # Original class - class Circle: - def __init__(self, center, radius): - ... + class Circle: + def __init__(self, center, radius): + ... # Annotated with type hints - class Circle: - def __init__(self, center: Point2D, radius: Expr): - ... + class Circle: + def __init__(self, center: Point2D, radius: Expr): + ... ``` 4. Gradually Propagate Static Typing @@ -185,6 +185,12 @@ as long as they adhere to PEP guidelines and are compatible with the minimum Pyt Nevertheless, these annotations must be structured according to ``.pyi`` files for type hinting purposes. +### Supported Type Checkers + +The SymPy community is already using the ``mypy`` type checker for static type checking. However, there are other type checkers available, including ``pyright``, ``pytype``, and ``pyre``. The SymPy community is open to supporting other type checkers as well. And may receive requests from the community, if there are issues from other type checkers. + +However, we are not decided to add other type checkers to build integration progress. + ### Using `S` for SymPy objects LPython is currently engaged in the development of a Python compiler. This compiler harnesses the benefits of statically typed functions, classes, and symbolic expressions found in SymPy. From 39fe1279ad8e8eb8b9defca9e36ff7fd09992f43 Mon Sep 17 00:00:00 2001 From: Sangyub Lee Date: Sat, 26 Aug 2023 16:50:12 -0500 Subject: [PATCH 17/17] Add preference about static typing vs dynamic typing --- SymPEP-XXXX.md | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/SymPEP-XXXX.md b/SymPEP-XXXX.md index 112572a..c556246 100644 --- a/SymPEP-XXXX.md +++ b/SymPEP-XXXX.md @@ -191,6 +191,12 @@ The SymPy community is already using the ``mypy`` type checker for static type c However, we are not decided to add other type checkers to build integration progress. +### Preference about static typing and dynamic typing + +The SymPy community does not currently exhibit a consensus regarding a preference for either dynamic typing or static typing in the project's development and codebase. Different contributors and stakeholders within the community may hold differing viewpoints on this matter. + +However, we are trying to make our code supportive with both the static-typed and dynamic-typed ecosystem of the Python, as much as we are willing to support different Python versions, Python implementations or language extensions, if possible. + ### Using `S` for SymPy objects LPython is currently engaged in the development of a Python compiler. This compiler harnesses the benefits of statically typed functions, classes, and symbolic expressions found in SymPy.