Typed Python execution mode
It would be nice to have "Typed Python" mode that will look like this: ```bash #!/usr/bin/env bash set -e python -m mypy $1 python $1 ``` https://gist.github.com/redradist/dd7253a55081a4dc13fdf3f1549f43b5 It could be achieved by adding special flag like `-t` (typed)
Also if such mode would exsist, it would be nice to have special keywords for such mode like `protocol` Instead of writing: ```python class MathType(Protocol): def reduce(self, *args) -> int: ... ``` it woulb be nicer to have special syntax: ```python-mypy protocol MathType: def reduce(self, *args) -> int: ... def sum(self, *args) -> int: ... ``` It will make code more readable as for me
On Sun, Dec 06, 2020 at 10:22:53AM -0000, redradist@gmail.com wrote:
What does that mean? Why is it a bash script?
It could be achieved by adding special flag like `-t` (typed)
What does "typed" mode do? Why would it be "nice"? If all you want is to run mypy, you can run mypy. Or any alternative type-checker, such as Pytype, Pyright, Pyre or Jedi: https://google.github.io/pytype/ https://github.com/Microsoft/pyright https://pyre-check.org/ https://pypi.org/project/jedi (Jedi does a lot more than just type checking.) -- Steve
Steven D'Aprano wrote:
It is only example how I use what I call "Typed Python" The same can happens under-hood, python in this "typed" mode can first run type-checker and then if there are no errors run script itself
It would be good to have direct support from python to run script in typed mode or not ... Python can support other type checker with some option `--type-checker=<path> or <name>` of module that will type-check
On Sun, Dec 06, 2020 at 11:25:32AM -0000, redradist@gmail.com wrote:
You already have direct support from python to run a type checker: python3 -m <some checker> script.py Your bash script is an excellent example of the Unix philosophy of chaining together tools to do what you want. Just alias "python" to your bash script. Or use an IDE or editor that supports it as a plugin. All the type-checkers that I listed are big, complex, specialised projects, with their own schedules for new development. Bringing them into the CPython code base would basically kill them. It would dump a huge amount of work on the CPython developers, increase the size of the Python standard installation for everybody whether they want to use a type-checker or not, and for no real benefit. If type-checking was small and easily maintained, like the -b and -W options, then it could be integrated with the interpreter. But it isn't. Keeping them as separate projects is the right strategy. -- Steve
I do not want to make type-checker a part of CPython, I just what options that will allow to run python with first some type-checker ... For example, you would be able to set default python module for type-checking and if there is not module set for type checking, verify if `mypy` installed and if installed run it first ... The issue with separate running type-checker first and then script is that it is separate commands and failing run script is console dependent: in bash `set -e` and etc. in other consoles Better to have terminal agnostic option that will allow to do the same thing ... Also I think that maybe it would be also good to have `*.ty` (Typed pYthon) that would mean if python understand extension `ty` then it will run default type checker if it is available and then script ... Anyway as you can see there is obvious reason to add CPython flag and it is not enforce to CPython somehow to integrate type checker in its source code ...
December 10, 2020 4:18 PM, redradist@gmail.com wrote:
This is quite easy to do without changing python. You could even do it with Python itself, like this: #!/usr/bin/python import os import sys if __name__ == '__main__': if(run_type_checker()): os.system("python3 " + sys.argv[1])
On Thu, Dec 10, 2020 at 09:18:32PM -0000, redradist@gmail.com wrote:
I do not want to make type-checker a part of CPython, I just what options that will allow to run python with first some type-checker ...
Okay. So we have a standard interpreter option to run a type-checker. Then tomorrow someone says that we need a standard interpreter option to run black, or another code reformatting tool. Then the day after, someone else says Python needs a standard option to run a linter like Jedi or PyFlakes over the code. Then the day after, someone else wants an option to run a test framework before running your code. Run the tests, and if they pass, run the code. And the next day after that, another person insists that there should be a standard interpreter option to run a code-coverage utility. And the following day, someone insists that Python needs an option to run a fuzz-tester. And then someone demands a standard option to run code refactoring tools. And somebody wants a special option to run a utility to vacuum their database before running their code. And then... Where does it end? Does the Python interpreter need to have a thousand special options to check for the existence of a thousand different tools and run them? You are probably thinking, "But this is silly! None of those things are so important that Python needs to support them with a standard runtime option. Just write a script!" And I totally agree. The only difference is you think that we need to make a special exception for type-checking. Why should the interpreter make *type checking* a special option and not all of the others? -- Steve
Yes, it is not bad, it is open-close principle from SOLID for good design system ... You provide template (standard way to do something) for community and if package can work through this interface that is required all goes good ... In such way community would have the standard way to do something instead of lots of different way that even not compatible with each other Also this design is exactly according Zen Python: "There should be one-- and preferably only one --obvious way to do it."
No, it is not good design choose, because then all type-checker will have different optional and it will be a mess ... It should be done in one place like python
On Thu, Dec 10, 2020 at 17:12 <redradist@gmail.com> wrote:
I think the nature of open source is that all the tools have different options and it is a mess. I don't think this is an unequivocal bad thing. No doubt, it is a joy when a different things are consistent, but it's also true that standards slow progress. I don't think python type checking in various tools is ready to have its progress slowed by standardization quite yet.
Good design should follow open-close principle from SOLID ... You provide template (standard way to do something) for community and if package can work through this interface that is required all goes good ... In such way community would have the standard way to do something instead of lots of different way that even not compatible with each other Also this design is exactly according Zen Python: "There should be one-- and preferably only one --obvious way to do it."
Also if such mode would exsist, it would be nice to have special keywords for such mode like `protocol` Instead of writing: ```python class MathType(Protocol): def reduce(self, *args) -> int: ... ``` it woulb be nicer to have special syntax: ```python-mypy protocol MathType: def reduce(self, *args) -> int: ... def sum(self, *args) -> int: ... ``` It will make code more readable as for me
On Sun, Dec 06, 2020 at 10:22:53AM -0000, redradist@gmail.com wrote:
What does that mean? Why is it a bash script?
It could be achieved by adding special flag like `-t` (typed)
What does "typed" mode do? Why would it be "nice"? If all you want is to run mypy, you can run mypy. Or any alternative type-checker, such as Pytype, Pyright, Pyre or Jedi: https://google.github.io/pytype/ https://github.com/Microsoft/pyright https://pyre-check.org/ https://pypi.org/project/jedi (Jedi does a lot more than just type checking.) -- Steve
Steven D'Aprano wrote:
It is only example how I use what I call "Typed Python" The same can happens under-hood, python in this "typed" mode can first run type-checker and then if there are no errors run script itself
It would be good to have direct support from python to run script in typed mode or not ... Python can support other type checker with some option `--type-checker=<path> or <name>` of module that will type-check
On Sun, Dec 06, 2020 at 11:25:32AM -0000, redradist@gmail.com wrote:
You already have direct support from python to run a type checker: python3 -m <some checker> script.py Your bash script is an excellent example of the Unix philosophy of chaining together tools to do what you want. Just alias "python" to your bash script. Or use an IDE or editor that supports it as a plugin. All the type-checkers that I listed are big, complex, specialised projects, with their own schedules for new development. Bringing them into the CPython code base would basically kill them. It would dump a huge amount of work on the CPython developers, increase the size of the Python standard installation for everybody whether they want to use a type-checker or not, and for no real benefit. If type-checking was small and easily maintained, like the -b and -W options, then it could be integrated with the interpreter. But it isn't. Keeping them as separate projects is the right strategy. -- Steve
I do not want to make type-checker a part of CPython, I just what options that will allow to run python with first some type-checker ... For example, you would be able to set default python module for type-checking and if there is not module set for type checking, verify if `mypy` installed and if installed run it first ... The issue with separate running type-checker first and then script is that it is separate commands and failing run script is console dependent: in bash `set -e` and etc. in other consoles Better to have terminal agnostic option that will allow to do the same thing ... Also I think that maybe it would be also good to have `*.ty` (Typed pYthon) that would mean if python understand extension `ty` then it will run default type checker if it is available and then script ... Anyway as you can see there is obvious reason to add CPython flag and it is not enforce to CPython somehow to integrate type checker in its source code ...
December 10, 2020 4:18 PM, redradist@gmail.com wrote:
This is quite easy to do without changing python. You could even do it with Python itself, like this: #!/usr/bin/python import os import sys if __name__ == '__main__': if(run_type_checker()): os.system("python3 " + sys.argv[1])
On Thu, Dec 10, 2020 at 09:18:32PM -0000, redradist@gmail.com wrote:
I do not want to make type-checker a part of CPython, I just what options that will allow to run python with first some type-checker ...
Okay. So we have a standard interpreter option to run a type-checker. Then tomorrow someone says that we need a standard interpreter option to run black, or another code reformatting tool. Then the day after, someone else says Python needs a standard option to run a linter like Jedi or PyFlakes over the code. Then the day after, someone else wants an option to run a test framework before running your code. Run the tests, and if they pass, run the code. And the next day after that, another person insists that there should be a standard interpreter option to run a code-coverage utility. And the following day, someone insists that Python needs an option to run a fuzz-tester. And then someone demands a standard option to run code refactoring tools. And somebody wants a special option to run a utility to vacuum their database before running their code. And then... Where does it end? Does the Python interpreter need to have a thousand special options to check for the existence of a thousand different tools and run them? You are probably thinking, "But this is silly! None of those things are so important that Python needs to support them with a standard runtime option. Just write a script!" And I totally agree. The only difference is you think that we need to make a special exception for type-checking. Why should the interpreter make *type checking* a special option and not all of the others? -- Steve
Yes, it is not bad, it is open-close principle from SOLID for good design system ... You provide template (standard way to do something) for community and if package can work through this interface that is required all goes good ... In such way community would have the standard way to do something instead of lots of different way that even not compatible with each other Also this design is exactly according Zen Python: "There should be one-- and preferably only one --obvious way to do it."
No, it is not good design choose, because then all type-checker will have different optional and it will be a mess ... It should be done in one place like python
On Thu, Dec 10, 2020 at 17:12 <redradist@gmail.com> wrote:
I think the nature of open source is that all the tools have different options and it is a mess. I don't think this is an unequivocal bad thing. No doubt, it is a joy when a different things are consistent, but it's also true that standards slow progress. I don't think python type checking in various tools is ready to have its progress slowed by standardization quite yet.
Good design should follow open-close principle from SOLID ... You provide template (standard way to do something) for community and if package can work through this interface that is required all goes good ... In such way community would have the standard way to do something instead of lots of different way that even not compatible with each other Also this design is exactly according Zen Python: "There should be one-- and preferably only one --obvious way to do it."
participants (6)
-
edwin＠211mainstreet.net -
Ethan Furman -
Michael Smith -
redradist＠gmail.com -
Steven D'Aprano -
Todd