One suggestion I had for the next Python release is to add type-implication support. Many developers have learned Python, but do not want to use it since it is slow. An awesome way to fix this is to have optional type-implications. For example, if you know for sure that variable x is an int, you can make Python just a bit smaller by somehow specifying to the interpreter that the variable is an integer. Something like 'x::int = 5'. By having optional type implications, you can still do everything you do with normal Python, except you can speed it up a little bit by telling the Interpreter that this variable is starting off with this datatype.
Do you mean the type annotations that Python has had for about ten years?
And the typing library that uses them to specify type hints to compilers and other tooling? https://docs.python.org/3/library/typing.html
On Wed, Aug 26, 2020 at 11:07 AM krishnans2006@gmail.com wrote:
One suggestion I had for the next Python release is to add type-implication support. Many developers have learned Python, but do not want to use it since it is slow. An awesome way to fix this is to have optional type-implications. For example, if you know for sure that variable x is an int, you can make Python just a bit smaller by somehow specifying to the interpreter that the variable is an integer. Something like 'x::int = 5'. By having optional type implications, you can still do everything you do with normal Python, except you can speed it up a little bit by telling the Interpreter that this variable is starting off with this datatype. _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/ZGTZNK... Code of Conduct: http://python.org/psf/codeofconduct/
On 26 Aug 2020, at 17:02, krishnans2006@gmail.com wrote:
One suggestion I had for the next Python release is to add type-implication support. Many developers have learned Python, but do not want to use it since it is slow. An awesome way to fix this is to have optional type-implications. For example, if you know for sure that variable x is an int, you can make Python just a bit smaller by somehow specifying to the interpreter that the variable is an integer. Something like 'x::int = 5'. By having optional type implications, you can still do everything you do with normal Python, except you can speed it up a little bit by telling the Interpreter that this variable is starting off with this datatype.
Python as type annotations, but those are primarily used for type checking using tools such as mypy and are not used by the interpreter itself.
PyPy is an implementation of Python that includes an advanced JIT compiler, and their FAQ mentions that having type annotations won’t help for performance, even if they’d look at them. See: https://doc.pypy.org/en/latest/faq.html#would-type-annotations-help-pypy-s-p... https://doc.pypy.org/en/latest/faq.html#would-type-annotations-help-pypy-s-performance.
Ronald
—
Twitter / micro.blog: @ronaldoussoren Blog: https://blog.ronaldoussoren.net/
On Wed, Aug 26, 2020 at 8:41 AM Ronald Oussoren via Python-ideas < python-ideas@python.org> wrote:
On 26 Aug 2020, at 17:02, krishnans2006@gmail.com wrote:
One suggestion I had for the next Python release is to add type-implication support. Many developers have learned Python, but do not want to use it since it is slow. An awesome way to fix this is to have optional type-implications. For example, if you know for sure that variable x is an int, you can make Python just a bit smaller by somehow specifying to the interpreter that the variable is an integer. Something like 'x::int = 5'. By having optional type implications, you can still do everything you do with normal Python, except you can speed it up a little bit by telling the Interpreter that this variable is starting off with this datatype.
Python as type annotations, but those are primarily used for type checking using tools such as mypy and are not used by the interpreter itself.
Mypy includes an experimental compiler from typed Python to C that actually does what the OP is looking for.
https://github.com/python/mypy/tree/master/mypyc
On Wed, Aug 26, 2020 at 9:02 AM Guido van Rossum
Mypy includes an experimental compiler from typed Python to C that actually does what the OP is looking for.
There is also Cython, which is almost exactly what the OP is looking for.
(I’m curious about how mypyc is different than Cython (other than syntax) and I’ve lost track, but I thought Cython was looking into using standard type hint notation.
But there’s a trick: type hints can be (and often are) duck typed. That is, they might specify a Sequence of Numbers, which doesn’t provide enough information to compile down to fully performant code.
In fact, when type hinting was standardized, it was explicitly said that that was not the goal.
-CHB
-- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-leave@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/3FS5C3...
Code of Conduct: http://python.org/psf/codeofconduct/
--
Christopher Barker, PhD
Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython
On Wed, Aug 26, 2020 at 11:20 AM Christopher Barker pythonchb@gmail.com wrote:
On Wed, Aug 26, 2020 at 9:02 AM Guido van Rossum
Mypy includes an experimental compiler from typed Python to C that actually does what the OP is looking for.
There is also Cython, which is almost exactly what the OP is looking for.
And certainly more mature.
(I’m curious about how mypyc is different than Cython (other than syntax)
and I’ve lost track, but I thought Cython was looking into using standard type hint notation.
IIUC Cython (even if they were to adopt annotations) is not meant to be a strict subset of Python -- almost no Cython module is valid Python. OTOH mypyc has this as a goal -- you write annotated Python, and you test it using the Python interpreter, and then when you need more speed, mypyc can translate it to run faster. But you can still execute the mypyc input with the regular interpreter, and it will have the same semantics. (There are situations where mypyc doesn't handle certain dynamic constructs, but there are no cases where code can only be run by mypyc.)
But there’s a trick: type hints can be (and often are) duck typed. That is, they might specify a Sequence of Numbers, which doesn’t provide enough information to compile down to fully performant code.
In fact, when type hinting was standardized, it was explicitly said that that was not the goal.
Right. And mypyc is experimental. But type hints *are* useful for compilers (see also TorchScript).
On Wed, Aug 26, 2020 at 11:57 AM Guido van Rossum guido@python.org wrote:
IIUC Cython (even if they were to adopt annotations) is not meant to be a strict subset of Python -- almost no Cython module is valid Python.
correct. rather, it is a strict superset -- any valid Python should be compilable with Cython. But Cython type annotations are not valid Python.
However, Cython has a "pure python" mode that IS valid Python:
https://cython.readthedocs.io/en/latest/src/tutorial/pure.html
It used to rely almost entirely on decorators and special function (e.g. cython.declare()) to add the Cython annotations -- these could simply do nothing when run through the Python interpreter. But apparently it now is using Type Hints as well.
Or you can put the annotations in a separate file.
But it does not support full Cython functionality. But if what you want is faster Python, it may well get you there.
I hope the mypyc folks are at least keeping an eye on it -- the projects seem to have overlapping goals.
In fact, when type hinting was standardized, it was explicitly said that
that was not the goal.
Right. And mypyc is experimental. But type hints *are* useful for compilers (see also TorchScript).
Indeed. I suppose it's not the syntax that's the issue, but what types you use. If you use, e.g. Sequence, won't get much gain, but if you use a specific type, like List, then it can compile down to more efficient code.
-CHB
-
Calvin Spealman -
Christopher Barker -
Guido van Rossum -
krishnans2006＠gmail.com -
Ronald Oussoren