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

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 special to require to call PyRuntime_Init(). > > Currently, you cannot call PyMem_SetAllocators() before PyRuntime_Init(). At

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

Given that we're also allowing customization of __dir__ I wouldn't want to link this to __dir__. But maybe you meant to say that vars() is the public interface for __dict__. Even if it were, in the case of specifying this particular customization for this PEP, I strongly prefer to write it in

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

On Sun, Nov 19, 2017 at 05:34:35PM -0800, Guido van Rossum wrote: > On Sun, Nov 19, 2017 at 4:57 PM, Steven D'Aprano > wrote: > > A minor point: this should(?) be written in terms of the public > > interface for accessing namespaces, namely: > > > > getter =

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

On Sun, Nov 19, 2017 at 4:57 PM, Steven D'Aprano wrote: > On Sun, Nov 19, 2017 at 08:24:00PM +, Mark Shannon wrote: > > Just one comment. Could the new behaviour of attribute lookup on a > > module be spelled out more explicitly please? > > > > > > I'm guessing it is now

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

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. Also the word "now" is confusing (does it mean "currently, before the PEP" or "once this PEP is accepted"?)

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

On Sun, Nov 19, 2017 at 08:24:00PM +, Mark Shannon wrote: > Hi, > > Just one comment. Could the new behaviour of attribute lookup on a > module be spelled out more explicitly please? > > > I'm guessing it is now something like: > > `module.__getattribute__` is now equivalent to: > > def

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

On Mon, Nov 13, 2017 at 11:59 PM, Brett Cannon wrote: ​[..]​ > On Sun, Nov 12, 2017, 10:22 Koos Zevenhoven, wrote: > ​​ > >> >> There's two thing I don't understand here: >> >> * What does it mean to preserve the string verbatim? No matter how I read >> it,

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

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 draft implementation. > The implementation could implement

[Python-Dev] __future__ imports and breaking code (was: PEP 563: Postponed Evaluation of Annotations)

Previously, I expressed some concerns about PEP 563 regarding what should happen when a string is used as an annotation. Since my point here is more general, I'm starting yet another thread. For a lot of existing type-annotated code, adding "from __tuture__ import annotations" [1] *doesn't break

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

On 19/11/17 20:41, Serhiy Storchaka wrote: 19.11.17 22:24, Mark Shannon пише: Just one comment. Could the new behaviour of attribute lookup on a module be spelled out more explicitly please? I'm guessing it is now something like: `module.__getattribute__` is now equivalent to: def

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

19.11.17 22:24, Mark Shannon пише: Just one comment. Could the new behaviour of attribute lookup on a module be spelled out more explicitly please? I'm guessing it is now something like: `module.__getattribute__` is now equivalent to: def __getattribute__(mod, name):     try:    

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

Hi, Just one comment. Could the new behaviour of attribute lookup on a module be spelled out more explicitly please? I'm guessing it is now something like: `module.__getattribute__` is now equivalent to: def __getattribute__(mod, name): try: return object.__getattribute__(mod,

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

Hi, I am very concerned by this PEP. 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 draft implementation. The implementation could implement `type.__getitem__` instead of

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

Hi, Overall I am strongly in favour of this PEP. It pretty much cures all the ongoing pain of using PEP 3017 annotations for type hints. There is one thing I don't like however, and that is treating strings as if the quotes weren't there. While this seems like a superficial simplification to

Re: [Python-Dev] PEP 565: Show DeprecationWarning in __main__

On Sun, Nov 19, 2017 at 2:26 AM, Serhiy Storchaka wrote: > It seems to me that most of issues with FutureWarning on GitHub [1] are > related to NumPy and pandas which use FutureWarning for its original nominal > purpose, for warning about using programming interfaces that

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

19.11.17 12:59, Antoine Pitrou пише: On Sun, 19 Nov 2017 00:18:28 +0100 Victor Stinner wrote: Le 18 nov. 2017 10:44, "Serhiy Storchaka" a écrit : The simplest way to do this: #define PyTuple_GET_ITEM PyTuple_GetItem This will not add new names

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

On Sun, 19 Nov 2017 00:18:28 +0100 Victor Stinner wrote: > Le 18 nov. 2017 10:44, "Serhiy Storchaka" a écrit : > > The simplest way to do this: > > #define PyTuple_GET_ITEM PyTuple_GetItem > > This will not add new names to ABI. Such defines can

Re: [Python-Dev] PEP 565: Show DeprecationWarning in __main__

13.11.17 01:34, Nick Coghlan пише: On 13 November 2017 at 03:10, Serhiy Storchaka wrote: 12.11.17 11:24, Nick Coghlan пише: The PEP also proposes repurposing the existing FutureWarning category to explicitly mean "backwards compatibility warnings that should be shown to

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

Maybe we can find a compromise: revert the change on memory allocators. They are too special to require to call PyRuntime_Init(). Currently, you cannot call PyMem_SetAllocators() before PyRuntime_Init(). Victor Le 19 nov. 2017 08:55, "Serhiy Storchaka" a écrit : >