[Python-Dev] Is anyone aware of any existing tests for ternary_op in abstract.c?
[Note: I don't think this is a high priority issue, as it only relates to doing mixed-type modular exponentiation, and that seems like an inherently bad idea anyway. But I'm also curious if anyone is able to explain the current behaviour, as I haven't come up with a better explanation than "It doesn't actually work, but nobody needs it enough to complain about it not working"] While writing up bpo-39302 [1], I tried experimenting at the REPL to see if I could get __pow__ to ever exercise the code paths where 3-argument pow() is handled by the exponent or the modulus (as described in the source code and PEP 208), rather than the usual case where it is handled by the base. I failed - the only time I could get my custom __pow__ implementation to run was when it was the base, never when it was the modulus or exponent. This means that, as far as I'm able to tell, ternary_op in abstract.c isn't actually working as intended, or at least, it doesn't work in combination with the way the `nb_power` slot wrapper is implemented in typeobject.c. That slot wrapper only ever calls the Python level function provided by the first operand, even though ternary_op calls 3 different slot implementations, they all ultimately get resolved as attempts to call the same python level function (the `__pow__` implementation on the base). I couldn't find any test cases that exercise this functionality, so even though PEP 208 describes the expected semantics, it isn't clear whether or not the implementation has ever achieved them. This is the session where I tried to see if I could get it to work the way I expected it to work based on the comments in ternary_op: [py3.7]> class _PowArgsMixin: ... def __pow__(*args): ... return tuple(map(type, args)) ... [py3.7]> class NoPow: ... pass ... [py3.7]> class NotImplementedPow: ... def __pow__(*args): ... return NotImplemented ... [py3.7]> class UnrelatedPow(_PowArgsMixin): ... pass ... [py3.7]> class ChildOfNoPow(_PowArgsMixin, NoPow): ... pass ... [py3.7]> class ChildOfNotImplementedPow(_PowArgsMixin, NotImplementedPow): ... pass ... [py3.7]> no_pow = NoPow() [py3.7]> ni_pow = NotImplementedPow() [py3.7]> has_pow = UnrelatedPow() [py3.7]> child_no = ChildOfNoPow() [py3.7]> child_ni = ChildOfNotImplementedPow() [py3.7]> # They all give the expected result as the base ... pow(has_pow, no_pow, no_pow) (, , ) [py3.7]> pow(has_pow, ni_pow, ni_pow) (, , ) [py3.7]> pow(child_no, no_pow, no_pow) (, , ) [py3.7]> pow(child_ni, ni_pow, ni_pow) (, , ) [py3.7]> # But none of them work when given as the exponent ... pow(no_pow, has_pow, no_pow) Traceback (most recent call last): File "", line 2, in TypeError: unsupported operand type(s) for pow(): 'NoPow', 'UnrelatedPow', 'NoPow' [py3.7]> pow(ni_pow, has_pow, ni_pow) Traceback (most recent call last): File "", line 1, in TypeError: unsupported operand type(s) for pow(): 'NotImplementedPow', 'UnrelatedPow', 'NotImplementedPow' [py3.7]> pow(no_pow, child_no, no_pow) Traceback (most recent call last): File "", line 1, in TypeError: unsupported operand type(s) for pow(): 'NoPow', 'ChildOfNoPow', 'NoPow' [py3.7]> pow(ni_pow, child_ni, ni_pow) Traceback (most recent call last): File "", line 1, in TypeError: unsupported operand type(s) for pow(): 'NotImplementedPow', 'ChildOfNotImplementedPow', 'NotImplementedPow' [py3.7]> # And none of them work when given as the modulus either ... pow(no_pow, no_pow, has_pow) Traceback (most recent call last): File "", line 2, in TypeError: unsupported operand type(s) for pow(): 'NoPow', 'NoPow', 'UnrelatedPow' [py3.7]> pow(ni_pow, ni_pow, has_pow) Traceback (most recent call last): File "", line 1, in TypeError: unsupported operand type(s) for pow(): 'NotImplementedPow', 'NotImplementedPow', 'UnrelatedPow' [py3.7]> pow(no_pow, no_pow, child_no) Traceback (most recent call last): File "", line 1, in TypeError: unsupported operand type(s) for pow(): 'NoPow', 'NoPow', 'ChildOfNoPow' [py3.7]> pow(ni_pow, ni_pow, child_ni) Traceback (most recent call last): File "", line 1, in TypeError: unsupported operand type(s) for pow(): 'NotImplementedPow', 'NotImplementedPow', 'ChildOfNotImplementedPow' [1] https://bugs.python.org/issue39302 -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/DT4AJNAYHNAD6UL2SPFVAVXKMD666LS3/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Requesting PR review on locale module
I've verified this fix and changed the status to "commit review." I trust that was the correct action. Kind regards, Steve Holden On Thu, Jan 9, 2020 at 9:57 PM Cédric Krier via Python-Dev < python-dev@python.org> wrote: > Hi, > > Any chance to get this PR reviewed? It is blocking the resolution of > https://bugs.tryton.org/issue8574 > > Thanks > > On 2019-11-18 06:36, Stéphane Wirtel wrote: > > Hi Cedric, > > > > It’s my fault, I am going to check your PR for this week. I am really > sorry because I am busy with the preparation of my black belt in Karate and > I have a training every day. > > > > Have a nice day, > > > > Stéphane > > > > > Le 17 nov. 2019 à 14:06, Tal Einat a écrit : > > > > > > > > > Hi Cédric, > > > > > > Thanks for writing and sorry that you've experienced such a delay. > Such occurrences are unfortunately rather common right now, though we're > working on improving the situation. > > > > > > Stéphane Wirtel self-assigned that PR to himself a couple of months > ago, but indeed hasn't followed it up after his requested changes were > apparently addressed, despite a couple of "pings". > > > > > > The experts index[1] lists Marc-Andre Lemburg as the expert for the > locale module, so perhaps he'd be interested in taking a look. > > > > > > I've CC-ed both Stéphane and Marc-Andre. > > > > > > [1] https://devguide.python.org/experts/ > > > > > >> On Sun, Nov 17, 2019 at 2:06 PM Cédric Krier via Python-Dev < > python-dev@python.org> wrote: > > >> Hi, > > >> > > >> Few months ago, I submitted a PR [1] for the bpo [2] about > locale.format > > >> casting Decimal into float. Has someone some times to finish the > review? > > >> This change is blocking a bugfix on Tryton [3]. > > >> > > >> > > >> [1] https://github.com/python/cpython/pull/15275 > > >> [2] https://bugs.python.org/issue34311 > > >> [3] https://bugs.tryton.org/issue8574 > > >> > > >> > > >> Thanks, > > >> -- > > >> Cédric Krier - B2CK SPRL > > >> Email/Jabber: cedric.kr...@b2ck.com > > >> Tel: +32 472 54 46 59 > > >> Website: http://www.b2ck.com/ > > >> ___ > > >> Python-Dev mailing list -- python-dev@python.org > > >> To unsubscribe send an email to python-dev-le...@python.org > > >> https://mail.python.org/mailman3/lists/python-dev.python.org/ > > >> Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/UOGIZADIK3EOLGPDDA2C525R63DULSDG/ > > >> Code of Conduct: http://python.org/psf/codeofconduct/ > > -- > Cédric Krier - B2CK SPRL > Email/Jabber: cedric.kr...@b2ck.com > Tel: +32 472 54 46 59 > Website: https://www.b2ck.com/ > ___ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/RFY3DCK47ALK6X6AYCZ3ET5O6P6US3NA/ > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/IL2BNPSAAWVEVOUP553X3P2BSYNNS7RF/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Object deallocation during the finalization of Python program
Hi Pau, Also, the Cython documentation warns against doing this kind of things (here, accessing the Python object stored in ``foo``). From https://cython.readthedocs.io/en/latest/src/userguide/special_methods.html: You need to be careful what you do in a __dealloc__() method. By the time your __dealloc__() method is called, the object may already have been partially destroyed and may not be in a valid state as far as Python is concerned, so you should avoid invoking any Python operations which might touch the object. In particular, don’t call any other methods of the object or do anything which might cause the object to be resurrected. It’s best if you stick to just deallocating C data. Armin ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/JFMEQM6XPB6OLFNFMO4Q4PFM63XXXJDR/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Object deallocation during the finalization of Python program
HI, Thanks for the comments, really interesting use case this one [1], I've just read it in diagonal but seems that is similar to the bug that finally I've found in our program. Basically GC was clearing all of the attributes before the deallocation for unbreaking an indirect reference cycle which resulted later in access to an invalid address during the deallocation, this is something that is already advised in the CYthon documentation. [1] https://bugs.python.org/issue38006 On Sat, Jan 11, 2020 at 1:36 PM Armin Rigo wrote: > > Hi Pau, > > Also, the Cython documentation warns against doing this kind of things > (here, accessing the Python object stored in ``foo``). From > https://cython.readthedocs.io/en/latest/src/userguide/special_methods.html: > > You need to be careful what you do in a __dealloc__() method. > By the time your __dealloc__() method is called, the object > may already have been partially destroyed and may not be > in a valid state as far as Python is concerned, so you should > avoid invoking any Python operations which might touch the > object. In particular, don’t call any other methods of the object > or do anything which might cause the object to be resurrected. > It’s best if you stick to just deallocating C data. > > > Armin -- --pau ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/7FUOIKLO27U67VPPI2HLM3GLWXQ64ESF/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Should we pass tstate in the VECTORCALL calling convention before making it public?
On Thu, 9 Jan 2020 15:12:41 +0100
Victor Stinner wrote:
>
> Getting the interpreter from a Python thread state is trivial: interp
> = tstate->interp.
>
> The problem is how to get the current Python thread state.
> *Currently*, it's an atomic variable. But tomorrow with multiple
> interpreters running in parallel, I expect that it's going to me more
> expensive like first having the current the interpreter running the
> current native thread, and then get the Python thread state of this
> interpreter. Or something like that. We may get more and more
> indirections...
It can still be simple. Store the current interpreter in a
thread-local variable (there can be only one interpreter running at a
given time in a given OS thread, even if it's not always the same
interpreter). Then have the interpreter struct contain a pointer to the
current running thread *in that interpreter*.
So you have one thread-local access to the current interpreter and then
a normal struct member access to the current thread state.
For example:
struct _ts;
struct _is {
struct _ts* current_thread;
};
_Thread_local struct _is *current_interp;
inline struct _is *_PyInterpreterState_GET() {
return current_interp;
}
inline struct _ts *_PyThreadState_GET() {
return current_interp->current_thread;
}
Regards
Antoine.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/GNJTJQ3WPZLB3VY2EJ62443GTL3L2CFI/
Code of Conduct: http://python.org/psf/codeofconduct/
