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 : > 19.11.17 04:17, Nick Coghlan пише: > >> 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, and ensure at >> least one release's worth of DeprecationWarning before requiring >> either the use of an alternative API (where the caller controls the >> memory management), or else a new lower level pre-initialization API >> (i.e. making `PyRuntime_Initialize` a public API) >> > > There is a way to to control the memory manager. The caller should just > define their own PyMem_RawMalloc(), PyMem_RawFree(), etc. It seems to me > that the reasons of introducing these functions were: > > 1. Get around the implementation detail when malloc(0) could return NULL. > PyMem_RawMalloc() always should return an unique address (unless error). > > 2. Allow the caller to control the memory management by providing their > own implementations. > > Let use existing possibilities and not expand the API. I don't think the > deprecation and breaking compatibility are needed here. > > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/victor. > stinner%40gmail.com > ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 users of Python applications" since: - we don't tend to use FutureWarning for its original nominal purpose (changes that will continue to run but will do something different) FutureWarning currently is used for its original nominal purpose in the re and ElementTree modules. If the future warnings relate to regex and XML parsing, they'd still fall under the "for display to users" category, since those modules can't tell if the input data was application provided or part of an end user interface like a configuration file. In the case of regular expressions or XPath the warnings could fall under the "for display to users" category, though in most cases they are emitted for hardcoded expressions. It is easy to fix these expressions, making them working ambiguously in past and future versions, and the author should do this. But FutureWarning is also raised in the __bool__ method which will change its meaning in future (the similar change was made for the midnight time object). 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 behavior in future. This doesn't have any relation to end users unless the end user is an author of the written code. [1] https://github.com/search?q=FutureWarning&type=Issues ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 be added in a separate > header file included for compatibility. > > > It is exactly what I am proposing :-) But those do not have the same semantics. PyTuple_GetItem() checks its arguments and raises an error if you pass it something else than a tuple, or if the index is out of bounds. PyTuple_GET_ITEM(), however, will crash if you do so. Regards Antoine. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 to ABI. Such defines can be added in a separate header file included for compatibility. It is exactly what I am proposing :-) But those do not have the same semantics. PyTuple_GetItem() checks its arguments and raises an error if you pass it something else than a tuple, or if the index is out of bounds. PyTuple_GET_ITEM(), however, will crash if you do so. There are no guaranties that PyTuple_GET_ITEM() will crash. In all cases when PyTuple_GET_ITEM() is used for getting the reference to a tuple's item it can be replaced with PyTuple_GetItem(). 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); ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 will change the > behavior in future. This doesn't have any relation to end users unless the > end user is an author of the written code. > > [1] https://github.com/search?q=FutureWarning&type=Issues Eh, numpy does use FutureWarning for changes where the same code will transition from doing one thing to doing something else without passing through a state where it raises an error. But that decision was based on FutureWarning being shown to users by default, not because it matches the nominal purpose :-). IIRC I proposed this policy for NumPy in the first place, and I still don't even know if it matches the original intent because the docs are so vague. "Will change behavior in the future" describes every case where you might consider using FutureWarning *or* DeprecationWarning, right? We have been using DeprecationWarning for changes where code will transition from working -> raising an error, and that *is* based on the Official Recommendation to hide those by default whenever possible. We've been doing this for a few years now, and I'd say our experience so far has been... poor. I'm trying to figure out how to say this politely. Basically it doesn't work at all. What happens in practice is that we issue a DeprecationWarning for a year, mostly no-one notices, then we make the change in a 1.x.0 release, everyone's code breaks, we roll it back in 1.x.1, and then possibly repeat several times in 1.(x+1).0 and 1.(x+2).0 until enough people have updated their code that the screams die down. I'm pretty sure we'll be changing our policy at some point, possibly to always use FutureWarning for everything. -n -- Nathaniel J. Smith -- https://vorpus.org ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[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 make transition easier, it introduces inconsistency and will ultimately make both implementing and using type hints harder. Having the treatment of strings depend on their depth in the AST seems confusing and unnecessary: "List[int]" becomes 'List[int]' # quotes removed but List["int"] becomes 'List["int"]' # quoted retained Also, T = "My unparseable annotation" def f()->T: pass would remain legal, but def f()->"My unparseable annotation" would become illegal. The change in behaviour between the above two code snippets is already confusing enough without making one of them a SyntaxError. Using annotations for purposes other than type hinting is legal and has been for quite a while. Also, PEP 484 type-hints are not the only type system in the Python ecosystem. Cython has a long history of using static type hints. For tools other than MyPy, the inconsistent quoting is onerous and will require double-quoting to prevent a parse error. For example def foo()->"unsigned int": ... will become illegal and require the cumbersome def foo()->'"unsigned int"': ... Cheers, Mark. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[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 changing `object.__getitem__`, but that is still a major change to the language. In fact, the addition of `__mro_entries__` makes `__class_getitem__` unnecessary. The addition of `__mro_entries__` allows instances of classes that do not subclass `type` to act as classes in some circumstances. That means that any class can implement `__getitem__` to provide a generic type. For example, here is a minimal working implementation of `List`: class Generic: def __init__(self, concrete): self.concrete = concrete def __getitem__(self, index): return self.concrete def __mro_entries__(self): return self.concrete List = Generic(list) class MyList(List): pass # Works perfectly class MyIntList(List[int]): pass # Also works. The name `__mro_entries__` suggests that this method is solely related method resolution order, but it is really about providing an instance of `type` where one is expected. This is analogous to `__int__`, `__float__` and `__index__` which provide an int, float and int respectively. This rather suggests (to me at least) the name `__type__` instead of `__mro_entries__` Also, why return a tuple of classes, not just a single class? The PEP should include the justification for this decision. Should `isinstance` and `issubclass` call `__mro_entries__` before raising an error if the second argument is not a class? In other words, if `List` implements `__mro_entries__` to return `list` then should `issubclass(x, List)` act like `issubclass(x, list)`? (IMO, it shouldn't) The reasoning behind this decision should be made explicit in the PEP. Cheers, Mark. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[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, name)
except AttributeError:
try:
getter = mod.__dict__["__getattr__"]
except KeyError:
raise AttributeError(f"module has no attribute '{name}'")
return getter(name)
Cheers,
Mark.
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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:
return object.__getattribute__(mod, name)
except AttributeError:
try:
getter = mod.__dict__["__getattr__"]
except KeyError:
raise AttributeError(f"module has no attribute '{name}'")
return getter(name)
I think it is better to describe in the terms of __getattr__.
def ModuleType.__getattr__(mod, name):
try:
getter = mod.__dict__["__getattr__"]
except KeyError:
raise AttributeError(f"module has no attribute '{name}'")
return getter(name)
The implementation of ModuleType.__getattribute__ will be not changed
(it is inherited from the object type).
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 __getattribute__(mod, name):
try:
return object.__getattribute__(mod, name)
except AttributeError:
try:
getter = mod.__dict__["__getattr__"]
except KeyError:
raise AttributeError(f"module has no attribute '{name}'")
return getter(name)
I think it is better to describe in the terms of __getattr__.
def ModuleType.__getattr__(mod, name):
try:
getter = mod.__dict__["__getattr__"]
except KeyError:
raise AttributeError(f"module has no attribute '{name}'")
return getter(name)
The implementation of ModuleType.__getattribute__ will be not changed
(it is inherited from the object type).
Not quite, ModuleType overrides object.__getattribute__ in order to
provide a better error message. So with your suggestion, the change
would be to *not* override object.__getattribute__ and provide the above
ModuleType.__getattr__
Cheers,
Mark.
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[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 anything*. But that doesn't seem right. The whole point of __future__ imports is to break things. Maybe the __future__ import will not give a 100% equivalent functionality to what will be in Python 4 by default, but anyway, it's Python 4 that should break as little as possible. This leaves the breaking business to the future import, if necessary. If someone cares enough to add the future import that avoids needing string annotations for forward references, it shouldn't be such a big deal to get a warning if there's a string annotation left. But the person upgrading to Python 4 (or whatever they might be upgrading) will have a lot less motivation to figure out what went wrong. Then again, code that works in both Python 3 and 4 could still have the future import. But that would defeat the purpose of Python 4 as a clean and high-performance dynamic language. —Koos [1] As defined in the PEP 563 draft: https://mail.python.org/pipermail/python-dev/2017-November/150062.html -- + Koos Zevenhoven + http://twitter.com/k7hoven + ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 `type.__getitem__` instead of changing > `object.__getitem__`, but that is still a major change to the language. > 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.__getitem__, but I didn't like it for various reasons. I don't think that any of the above are changes to the language. These are rather implementation details. The only unusual thing is that while dunders are searched on class, __class_getitem__ is searched on the object (class object in this case) itself. But this is clearly explained in the PEP. > In fact, the addition of `__mro_entries__` makes `__class_getitem__` > unnecessary. > But how would you implement this: class C(Generic[T]): ... C[int] # This should work The name `__mro_entries__` suggests that this method is solely related > method resolution order, but it is really about providing an instance of > `type` where one is expected. This is analogous to `__int__`, `__float__` > and `__index__` which provide an int, float and int respectively. > This rather suggests (to me at least) the name `__type__` instead of > `__mro_entries__` > This was already discussed during months, and in particular the name __type__ was not liked by ... you https://github.com/python/typing/issues/432#issuecomment-304070379 So I would propose to stop bikesheding this (also Guido seems to like the currently proposed name). > Should `isinstance` and `issubclass` call `__mro_entries__` before raising > an error if the second argument is not a class? > In other words, if `List` implements `__mro_entries__` to return `list` > then should `issubclass(x, List)` act like `issubclass(x, list)`? > (IMO, it shouldn't) The reasoning behind this decision should be made > explicit in the PEP. > I think this is orthogonal to the PEP. There are many situations where a class is expected, and IMO it is clear that all that are not mentioned in the PEP stay unchanged. -- Ivan ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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, I can't tell if it's with quotes or without. >> >> Maybe I'm missing some context. >> > > I believe the string passes through unchanged (i.e. no quotes). Think of > the PEP as simply turning all non-string annotations into string ones. > > Ok, maybe that was just wishful thinking on my part ;-). More info in the other threads, for example: https://mail.python.org/pipermail/python-dev/2017-November/150642.html https://mail.python.org/pipermail/python-dev/2017-November/150637.html -- Koos -- + Koos Zevenhoven + http://twitter.com/k7hoven + ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 __getattribute__(mod, name): > try: > return object.__getattribute__(mod, name) > except AttributeError: > try: > getter = mod.__dict__["__getattr__"] A minor point: this should(?) be written in terms of the public interface for accessing namespaces, namely: getter = vars(mod)["__getattr__"] -- Steve ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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"?)
It would be clearer to first state that Module.__getattribute__ is
currently (before the PEP) essentially defined as
class Module(object):
def __getattribute__(self, name):
try:
return object.__getattribute__(self, name)
except AttributeError:
if hasattr(self, '__dict__'):
mod_name = self.__dict__.get(name)
if isinstance(mod_name, str):
raise AttributeError("module '%s' has no attribute '%s'" %
(mod_name, name))
raise AttributeError("module has no attribute '%s'" % name)
The PEP changes the contents of the except clause to:
if hasattr(self, '__dict__'):
if '__getattr__' in self.__dict__:
getter = self.__dict__['__getattr__']
if not callable(getter):
raise TypeError("module __getattr__ must be callable")
return getter(name)
# Unchanged from here on
mod_name = self.__dict__.get(name)
if isinstance(mod_name, str):
raise AttributeError("module '%s' has no attribute '%s'" %
(mod_name, name))
raise AttributeError("module has no attribute '%s'" % name)
(However exception chaining makes the equivalency still not perfect. And we
ignore threading. But how far do we need to go when specifying "equivalent
code" to what every implementation should implement natively?)
On Sun, Nov 19, 2017 at 12:48 PM, Mark Shannon wrote:
>
>
> 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 __getattribute__(mod, name):
>>> try:
>>> return object.__getattribute__(mod, name)
>>> except AttributeError:
>>> try:
>>> getter = mod.__dict__["__getattr__"]
>>> except KeyError:
>>> raise AttributeError(f"module has no attribute '{name}'")
>>> return getter(name)
>>>
>>
>> I think it is better to describe in the terms of __getattr__.
>>
>> def ModuleType.__getattr__(mod, name):
>> try:
>> getter = mod.__dict__["__getattr__"]
>> except KeyError:
>> raise AttributeError(f"module has no attribute '{name}'")
>> return getter(name)
>>
>> The implementation of ModuleType.__getattribute__ will be not changed (it
>> is inherited from the object type).
>>
>
> Not quite, ModuleType overrides object.__getattribute__ in order to
> provide a better error message. So with your suggestion, the change would
> be to *not* override object.__getattribute__ and provide the above
> ModuleType.__getattr__
>
> Cheers,
> Mark.
>
> ___
> Python-Dev mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/guido%
> 40python.org
>
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 something like: > > > > `module.__getattribute__` is now equivalent to: > > > > def __getattribute__(mod, name): > > try: > > return object.__getattribute__(mod, name) > > except AttributeError: > > try: > > getter = mod.__dict__["__getattr__"] > > A minor point: this should(?) be written in terms of the public > interface for accessing namespaces, namely: > > getter = vars(mod)["__getattr__"] > Should it? The PEP is not proposing anything for other namespaces. What difference do you envision this way of specifying it would make? -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 = vars(mod)["__getattr__"] > > Should it? The PEP is not proposing anything for other namespaces. What > difference do you envision this way of specifying it would make? I don't know if it should -- that's why I included the question mark. But my idea is that __dict__ is the implementation and vars() is the interface to __dir__, and we should prefer using the interface rather than the implementation unless there's a good reason not to. (I'm not talking here about changing the actual name lookup code to go through vars(). I'm just talking about how we write the equivalent recipe.) Its not a big deal either way, __dict__ is already heavily used and vars() poorly known. Call it a matter of taste, if you like, but in my opinion the fewer times we directly reference dunders, the better. -- Steve ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 terms of __dict__. On Sun, Nov 19, 2017 at 6:34 PM, Steven D'Aprano wrote: > 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__"] > > > > Should it? The PEP is not proposing anything for other namespaces. What > > difference do you envision this way of specifying it would make? > > I don't know if it should -- that's why I included the question mark. > > But my idea is that __dict__ is the implementation and vars() is the > interface to __dir__, and we should prefer using the interface rather > than the implementation unless there's a good reason not to. > > (I'm not talking here about changing the actual name lookup code to go > through vars(). I'm just talking about how we write the equivalent > recipe.) > > Its not a big deal either way, __dict__ is already heavily used and > vars() poorly known. Call it a matter of taste, if you like, but in my > opinion the fewer times we directly reference dunders, the better. > > > -- > Steve > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/ > guido%40python.org > -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 least the raw allocators, anyway - that way, the developer facing documentation/comments can just say that the raw allocators can't have any prerequisites that aren't shared by regular malloc/calloc/realloc/free calls. If that's enough to get Py_DecodeLocale working again prior to _PyRuntime_Init(), then I'd suggest officially adding that to the "must work prior to Py_Initialize" list, otherwise we can re-examine it based on whatever's still broken after reverting the raw allocator changes. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
