Re: [Numpy-discussion] Type annotations for NumPy

2017-11-26 Thread Jelle Zijlstra
2017-11-26 6:00 GMT-05:00 Kirill Balunov :

> Hi!
>
> 2017-11-26 4:31 GMT+03:00 Juan Nunez-Iglesias :
>
>>
>> On 26 Nov 2017, 12:27 PM +1100, Nathaniel Smith , wrote:
>>
>> It turns out that the PEP 484 type system is *mostly* not useful for
>> this. They're really designed for checking consistency across a large
>> code-base, not for enabling compiler speedups. For example, if you
>> annotate something as an int, that means "this object is a subclass of
>> int". This is enough to let mypy catch your mistake if you
>> accidentally pass in a float instead, but it's not enough to tell you
>> anything at all about the object's behavior -- you could make a wacky
>> int subclass that acts like a string or something.
>>
>>
> I have subscribed to many lists, although I am not an active participant
> in them. Nevertheless this topic of using the type annotation in their
> projects was discussed several times on all Cython-like channels (and it
> becomes much more acute now days). "Misconceptions" arise both for ordinary
> users and developers, but I have never seen anyone to write clearly why the
> application of type annotation in Cython (and similar projects) is
> impossible or not reasonable. Maybe someone close to the topic has the time
> and energy to sum up and write a brief summary of how to perceive them and
> why they should be viewed "orthogonal"?
>
> Maybe I'm looking too superficially at this topic. But both Mypy and
> Cython perform type checking. From the Cython point of view I do not see
> any pitfalls, type checking and type conversions are what Cython is doing
> right now during compilation (and looks at types as strictly as necessary).
> From Mypy's point of view, it's possible that it can delegate all this
> stuff, using a certain option, on a project's related type checker (which
> can be much stricter in its assumptions)
>
The main (perceived) difficulty is that the type systems are different. If
Cython has a list-typed argument, it wants exactly a list so it can use
specialized code for lists, but to mypy it means "list or a subclass of
list", which is not as easily optimized because the subclass may do things
differently from the base class. Similarly, to Cython an int means a C int,
and in Python it may mean an arbitrary-precision integer.

However, Cython managed to overcome the problem and actually added support
for type annotations recently; see
https://github.com/cython/cython/issues/1672 and
https://github.com/cython/cython/issues/1850. I haven't used the support
myself and there are probably still details to be worked out, but in
principle it should be possible to use both Cython and mypy on a codebase.

>
> With kind regards, -gdg
>
>
>
>
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
>
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion


[Numpy-discussion] PEP 688: Making the buffer protocol accessible in Python

2022-04-25 Thread Jelle Zijlstra
I just posted https://peps.python.org/pep-0688/, which proposes adding a
types.Buffer type that will make it possible to check in Python code
whether a type implements the buffer protocol.

I'm reaching out to the numpy community because numpy was an important
driver for creating the buffer protocol. I'd be happy to hear any feedback
or possible use cases for the PEP.
___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-le...@python.org
https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
Member address: arch...@mail-archive.com


[Numpy-discussion] Re: PEP 688: Making the buffer protocol accessible in Python

2022-04-26 Thread Jelle Zijlstra
El mar, 26 abr 2022 a las 4:08, bas van beek ()
escribió:

> Hi Jelle,
>
>
>
> I’ve stumbled upon buffer-related issues multiple times when typing with
> numpy, be It either with annotating functions such as `np.frombuffer` or
> when passing a numpy array to the likes of `memoryview` (resulting in a
> false positive by type checkers).
>
> All in all I’d say this buffer-type would very much be a welcome addition.
>

Thank you!

>
>
> I do have a small remark about the name though: why not `BufferType`
> instead of `Buffer`?
>
> the classes in the `types` namespace generally have the `Type` suffix, so
> the lack thereof stands out a bit here.
>
I see it as more akin to the classes in collections.abc, which don't have a
Type suffix. I don't feel strongly about this though; I may change it if
more people bring up this feedback.


>
>
> Regards, Bas
>
>
>
> *From:* Jelle Zijlstra 
> *Sent:* Monday, 25 April 2022 05:47
> *To:* Discussion of Numerical Python 
> *Subject:* [Numpy-discussion] PEP 688: Making the buffer protocol
> accessible in Python
>
>
>
> I just posted https://peps.python.org/pep-0688/, which proposes adding a
> types.Buffer type that will make it possible to check in Python code
> whether a type implements the buffer protocol.
>
>
>
> I'm reaching out to the numpy community because numpy was an important
> driver for creating the buffer protocol. I'd be happy to hear any feedback
> or possible use cases for the PEP.
>
>
>
>
> ___
> NumPy-Discussion mailing list -- numpy-discussion@python.org
> To unsubscribe send an email to numpy-discussion-le...@python.org
> https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
> Member address: jelle.zijls...@gmail.com
>
___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-le...@python.org
https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
Member address: arch...@mail-archive.com