[Python-ideas] Re: Type Implications in Python 4 (or 3.9)

[Christopher Barker]

On Wed, Aug 26, 2020 at 11:57 AM Guido van Rossum  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

-- 
Christopher Barker, PhD

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@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/FQY2QL4YNE6RVKFWA3QAHRRK7VZMJ3F2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Type Implications in Python 4 (or 3.9)

[Guido van Rossum]

On Wed, Aug 26, 2020 at 11:20 AM Christopher Barker 
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.
>>
>> https://github.com/python/mypy/tree/master/mypyc
>>
>
> 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).

-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@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/VN2COA6SFVEQ7BHVNZ5ENBSJAEQ5IGKI/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Type Implications in Python 4 (or 3.9)

[Christopher Barker]

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.
>
> https://github.com/python/mypy/tree/master/mypyc
>

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?)*
> 
>
>
> ___
>
> Python-ideas mailing list -- python-ideas@python.org
>
> To unsubscribe send an email to python-ideas-le...@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/3FS5C32FVB6YNN5TL5WTZETSCGLEHDTI/
>
> 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
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@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/2VQYOMAK5U6VBXTQHJA7KGATPPCCUX76/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Type Implications in Python 4 (or 3.9)

[Guido van Rossum]

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, krishnans2...@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

-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@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/3FS5C32FVB6YNN5TL5WTZETSCGLEHDTI/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Type Implications in Python 4 (or 3.9)

[Ronald Oussoren via Python-ideas]

> On 26 Aug 2020, at 17:02, krishnans2...@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-performance
 
.

Ronald

—

Twitter / micro.blog: @ronaldoussoren
Blog: https://blog.ronaldoussoren.net/

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@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/3G24YXW5HQ7YTCSGNEBZFE7FNID34EKV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Type Implications in Python 4 (or 3.9)

[Calvin Spealman]

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  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-le...@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/ZGTZNKOSTNTEA3NLJWERIGC3IHG7WU5B/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
>

-- 

CALVIN SPEALMAN

SENIOR QUALITY ENGINEER

cspea...@redhat.com  M: +1.336.210.5107
[image: https://red.ht/sig] 
TRIED. TESTED. TRUSTED. 
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@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/V63JTFW5RLUDJ7DAAD5B7R7MV7KECIQO/
Code of Conduct: http://python.org/psf/codeofconduct/