[Python-Dev] PEP 580 (C call protocol) minor update

I made some minor updates to PEP 580 (PEP editors: please merge https://github.com/python/peps/pull/741) and its reference implementation: - Added a new introductory section explaining the basic idea. - The C protocol no longer deals with __name__; a __name__ attribute is required but the prot

[Python-Dev] Question about PEP 484

*Hi Folks,Cc: Rebecca, pytypeThis is Adam Cataldo; I’m the engineering manager for the Python team at Google. Rebecca Chen, our lead pytype contributor, and I are interested in helping finalize PEP 484 if possible. To that end, we wanted to find out what technical

Re: [Python-Dev] Question about PEP 484

On Mon, 16 Jul 2018 at 10:32 Adam Cataldo via Python-Dev < python-dev@python.org> wrote: > > > > > > *Hi Folks,Cc: Rebecca, pytypeThis is Adam Cataldo; I’m the engineering > manager for the Python team at Google. Rebecca Chen, our lead pytype > contributor, and I

Re: [Python-Dev] Question about PEP 484

Hi, my name is Teddy Sudol. I work with Adam and Rebecca on pytype. The explanation of stub files is unclear. The section you linked starts with, "Stub files are files containing type hints that are only for use by the type checker, not at runtime." According to https://www.python.org/dev/peps/pep

Re: [Python-Dev] Question about PEP 484

Thanks Brett and Teddy, Just so it doesn't get lost in the shuffle as folks dive into details, I'll re-ask my earlier question about stub files. Assuming there is consensus that there is ambiguity to resolve in the current definition, is updating the section on stub files the preferred option? The

[Python-Dev] Specification of C function profiling?

Hello, it seems to me that there is no clear specification for the sys.setprofile() event c_call: the docs say "A C function is about to be called" but it's not clear what that means exactly, in particular when that C function is an unbound method like list.append. I also noticed that Lib/te

Re: [Python-Dev] Question about PEP 484

As one of the authors of PEP 484, *I* never thought there was an ambiguity here. The intention was for stub files to conform to the same grammar as regular .py files, but with a different interpretation. > "Have the same syntax as regular Python modules" and "are files containing type hints" are a

Re: [Python-Dev] Question about PEP 484

2018-07-16 10:21 GMT-07:00 Adam Cataldo via Python-Dev < python-dev@python.org>: > > > > > > *Hi Folks,Cc: Rebecca, pytypeThis is Adam Cataldo; I’m the engineering > manager for the Python team at Google. Rebecca Chen, our lead pytype > contributor, and I are int

Re: [Python-Dev] Question about PEP 484

On Mon, Jul 16, 2018 at 1:44 PM Guido van Rossum wrote: > As one of the authors of PEP 484, *I* never thought there was an ambiguity > here. The intention was for stub files to conform to the same grammar as > regular .py files, but with a different interpretation. > > > "Have the same syntax as

Re: [Python-Dev] Question about PEP 484

On Mon, Jul 16, 2018 at 2:56 PM, Gregory P. Smith wrote: > > On Mon, Jul 16, 2018 at 1:44 PM Guido van Rossum wrote: > >> As one of the authors of PEP 484, *I* never thought there was an >> ambiguity here. The intention was for stub files to conform to the same >> grammar as regular .py files, b

Re: [Python-Dev] Question about PEP 484

Hi Guido and all, Let me try to clarify our (pytype team's) intentions a bit. Our overall goal is to see PEP 484 finalized, in the interest of having a definitive type-checking reference to point to and work off of. We're willing and eager to help with this, if we get some guidance on what the aut

Re: [Python-Dev] Question about PEP 484

Thanks, Rebecca! So the status of PEP 484 is that we don't want to add new features to it -- those require their own PEP. But we do accept PRs for clarifications, assuming the clarifications are about issues where the intention is clear but the text is not (usually because we thought there was only

[Python-Dev] Const access to CPython objects outside of GIL?

Hi all, one of our Python projects calls for pretty heavy, low-level optimizations. We went down the rabbit hole and determined that having access to PyList_GET_ITEM(list), PyInt_AS_LONG(int) and PyDict_GetItem(dict, unicode) on Python objects **outside of GIL** might be a good-enough solution. T

Re: [Python-Dev] Const access to CPython objects outside of GIL?

[Radim Řehůřek ] > one of our Python projects calls for pretty heavy, low-level optimizations. > We went down the rabbit hole and determined that having access to > PyList_GET_ITEM(list), PyInt_AS_LONG(int) and PyDict_GetItem(dict, unicode) > on Python objects **outside of GIL** might be a good-