Re: [Python-Dev] Python initialization and embedded Python

On 21 November 2017 at 01:31, Eric Snow wrote: > On Nov 18, 2017 19:20, "Nick Coghlan" wrote: > > > OK, in that case I think the answer to Victor's question is: > > 1. Breaking calling Py_DecodeLocale() before calling Py_Initialize() > is a compatibility break with the API implied by our own usag

Re: [Python-Dev] Comments on PEP 560 (Core support for typing module and generic types)

Mark, with that comment now added to the PEP, are you satisfied? https://github.com/python/peps/pull/479 On Mon, Nov 20, 2017 at 12:32 PM, Ivan Levkivskyi wrote: > On 20 November 2017 at 10:22, Mark Shannon wrote: > >> On 19/11/17 22:36, Ivan Levkivskyi wrote: >> >>> Except that there is no suc

Re: [Python-Dev] Python initialization and embedded Python

2017-11-20 22:35 GMT+01:00 Eric Snow : > I'm okay with that if we can't find another way. However, shouldn't > we be able to statically initialize the raw allocator in _PyRuntime, > much as we were doing before in obmalloc.c? I have a rough PR up: > > https://github.com/python/cpython/pull/44

Re: [Python-Dev] Python initialization and embedded Python

On Mon, Nov 20, 2017 at 8:43 AM, Victor Stinner wrote: > 2017-11-20 16:31 GMT+01:00 Eric Snow : >> That Py_DecodeLocale() can use PyMem_RawMalloc() pre-init is an >> implementation detail. > > Py_DecodeLocale() uses PyMem_RawMalloc(), and so its result must be > freed by PyMem_RawFree(). It's par

Re: [Python-Dev] Comments on PEP 560 (Core support for typing module and generic types)

On 20 November 2017 at 10:22, Mark Shannon wrote: > On 19/11/17 22:36, Ivan Levkivskyi wrote: > >> Except that there is no such thing as object._getitem__. Probably you >> mean PyObject_GetItem (which is just what is done by BINARY_SUBSCR opcode). >> > In fact, I initially implemented type.__geti

Re: [Python-Dev] Comment on PEP 562 (Module __getattr__ and __dir__)

On 20 November 2017 at 20:51, Guido van Rossum wrote: > Yeah, I don't think there's an action item here except *maybe* changes to > the wording of the PEP. Ivan? > Yes, I will make a small PR with a more detailed description of how __getattr__ works. -- Ivan

Re: [Python-Dev] Comment on PEP 562 (Module __getattr__ and __dir__)

Yeah, I don't think there's an action item here except *maybe* changes to the wording of the PEP. Ivan? On Mon, Nov 20, 2017 at 12:33 AM, Serhiy Storchaka wrote: > 20.11.17 03:02, Guido van Rossum пише: > >> Serhiy's definition sounds recursive (defining __getattr__ to define the >> behavior of

Re: [Python-Dev] Comments on PEP 563 (Postponed Evaluation of Annotations)

OK, this is fine. It won't affect mypy (which will continue to treat string literals the same as before) but it will require an update to typing.py -- hope you are working on that with Ivan. On Mon, Nov 20, 2017 at 9:58 AM, Lukasz Langa wrote: > I agree with you. The special handling of outermos

Re: [Python-Dev] Comments on PEP 563 (Postponed Evaluation of Annotations)

On Mon, Nov 20, 2017 at 7:58 PM, Lukasz Langa wrote: > I agree with you. The special handling of outermost strings vs. strings > embedded inside annotations bugged me a lot. Now you convinced me that this > functionality should be moved to `get_type_hints()` and the __future__ > import shouldn't

Re: [Python-Dev] Show DeprecationWarning in debug mode?

Oh, that was quick. Thanks! I counted Serhiy, Barry, Nick, you and me in favor of the change, and nobody against the code. So well, it's ok to merge it :-) Victor 2017-11-20 18:49 GMT+01:00 Lukasz Langa : > Merged. Thanks! ✨ 🍰 ✨ > > - Ł > >> On Nov 20, 2017, at 7:01 AM, Victor Stinner wrote: >>

Re: [Python-Dev] PEP 563: Postponed Evaluation of Annotations

See my response to Mark's e-mail. I agree that special-casing outermost strings is not generic enough of a solution and will be removing this special handling from the PEP and the implementation. - Ł > On Nov 19, 2017, at 2:38 PM, Koos Zevenhoven wrote: > > On Mon, Nov 13, 2017 at 11:59 PM, B

Re: [Python-Dev] Comments on PEP 563 (Postponed Evaluation of Annotations)

I agree with you. The special handling of outermost strings vs. strings embedded inside annotations bugged me a lot. Now you convinced me that this functionality should be moved to `get_type_hints()` and the __future__ import shouldn't try to special-case this one instance, while leaving others

Re: [Python-Dev] Show DeprecationWarning in debug mode?

Merged. Thanks! ✨ 🍰 ✨ - Ł > On Nov 20, 2017, at 7:01 AM, Victor Stinner wrote: > > 2017-11-18 18:13 GMT+01:00 Brett Cannon : >> +1 from me as well. > > Ok, I created https://bugs.python.org/issue32088 and > https://github.com/python/cpython/pull/4474 to implement the proposed > change. > > Vi

Re: [Python-Dev] Python initialization and embedded Python

2017-11-20 16:31 GMT+01:00 Eric Snow : > That Py_DecodeLocale() can use PyMem_RawMalloc() pre-init is an > implementation detail. Py_DecodeLocale() uses PyMem_RawMalloc(), and so its result must be freed by PyMem_RawFree(). It's part the documentation. I'm not sure that I understood correctly. D

Re: [Python-Dev] Python initialization and embedded Python

On Nov 18, 2017 19:20, "Nick Coghlan" wrote: OK, in that case I think the answer to Victor's question is: 1. Breaking calling Py_DecodeLocale() before calling Py_Initialize() is a compatibility break with the API implied by our own usage examples, and we'll need to revert the breakage for 3.7,

Re: [Python-Dev] Show DeprecationWarning in debug mode?

2017-11-18 18:13 GMT+01:00 Brett Cannon : > +1 from me as well. Ok, I created https://bugs.python.org/issue32088 and https://github.com/python/cpython/pull/4474 to implement the proposed change. Victor ___ Python-Dev mailing list Python-Dev@python.org h

Re: [Python-Dev] Python initialization and embedded Python

To not lost track of the issue, I created this issue on the bpo: https://bugs.python.org/issue32086 Victor 2017-11-20 7:54 GMT+01:00 Nick Coghlan : > On 19 November 2017 at 18:52, Victor Stinner wrote: >> Maybe we can find a compromise: revert the change on memory allocators. They >> are too spe

Re: [Python-Dev] Make the stable API-ABI usable

On 11/19/2017 12:50 PM, Serhiy Storchaka wrote: But if PyTuple_GET_ITEM() is used for getting a reference to a C array of items it can't be replaced with PyTuple_GetItem(). And actually there is no replacement for this case in the limited API. PyObject **items = &PyTuple_GET_ITEM(tuple, 0)

Re: [Python-Dev] Comments on PEP 560 (Core support for typing module and generic types)

On 19/11/17 22:36, Ivan Levkivskyi wrote: On 19 November 2017 at 21:06, Mark Shannon > wrote: By far and away the largest change in PEP 560 is the change to the behaviour of object.__getitem__. This is not mentioned in the PEP at all, but is explicit in the d

Re: [Python-Dev] Comment on PEP 562 (Module __getattr__ and __dir__)

20.11.17 03:02, Guido van Rossum пише: Serhiy's definition sounds recursive (defining __getattr__ to define the behavior of __getattr__) but Mark's suggestion makes his intention unclear since the error message is still the same. It is recursive only when the '__dict__' attribute is not define