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 least the raw allocators, anyw
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
terms
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 = vars(mod)["__getattr__"]
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 something like:
> >
>
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"?)
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 _
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, I can't tell if it's with quotes or wi
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 `type.__getitem__`
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 a
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 __getat
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:
retur
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, n
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
chang
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
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 will change the
> behavio
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 to ABI. Such defines can be added in a separate
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 be added in a separate
> header file included fo
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 users of Python applic
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 :
> 19.11.17 04:17, Nick Coghlan
19 matches
Mail list logo
