[Python-Dev] Developing a Python JIT and have troubld

[Yuheng Zou]

I am building a Python JIT, so I want to change the interp->eval_frame to
my own function.

I built a C++ library which contains EvalFrame function, and then use dlopen
 and dlsym to use it. It looks like this:

extern "C" PyObject *EvalFrame(PyFrameObject *f, int throwflag) {
return _PyEval_EvalFrameDefault(f, throwflag);}

I added following code to Python/pylifecycle.c at function _Py_InitializeEx_
Private(Python version is 3.6.1):

void *pyjit = NULL;
pyjit = dlopen("../cmake-build-debug/libPubbon.dylib", 0);if (pyjit != NULL) {
interp->eval_frame = (_PyFrameEvalFunction)dlsym(pyjit, "EvalFrame");
//interp->eval_frame = _PyEval_EvalFrameDefault;}

Then something strange happened. I used LLDB to trace the variables. When
it ran at EvalFrame, the address of f pointer didn't change, but f->f_lineno
 changed.

Why the address of the pointer didn't change, but the context change?

I am working on Mac OS X and Python 3.6.1. I want to know how to replace
_PyEval_EvalFrameDefault in interp->eval_frame with my own function.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] why _PyGen_Finalize(gen) propagates close() to _PyGen_yf() ?

[Nathaniel Smith]

On Thu, Mar 30, 2017 at 11:05 AM, Oleg Nesterov  wrote:
> On 03/28, Eric Snow wrote:
>>
>> On Mon, Mar 20, 2017 at 11:30 AM, Oleg Nesterov  wrote:
>> > Hello,
>> >
>> > Let me first clarify, I do not claim this is a bug, I am trying to learn
>> > python and now I trying to understand yield-from.
>>
>> Given that you haven't gotten a response here,
>
> and this looks a bit strange. My question is simple, the implementation looks
> clear and straightforward, I am a bit surprised none of cpython devs bothered
> to reply.
>
>> you may want to take
>> this over to the core-mentors...@python.org list.
>
> Well, I'm afraid to contact this closed and not-for-mortals list, not sure
> this very basic question should go there ;) perhaps you are already a member,
> feel free to forward.

core-mentorship is intended as a friendly place for folks who are
starting to study CPython internals. I'm not sure where you got the
impression that it's not-for-mortals but I suspect the people running
it would like to know so they can fix it :-).

In any case the short answer to your original question is that PEP 342
says that generator finalization calls the generator's close() method,
which throws a GeneratorExit into the generator, and PEP 380 says that
as a special case, when a GeneratorExit is thrown into a yield from,
then this is propagated by calling .close() on the yielded-from
iterator (if such a method exists) and then re-raised in the original
generator.

-n

-- 
Nathaniel J. Smith -- https://vorpus.org
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] why _PyGen_Finalize(gen) propagates close() to _PyGen_yf() ?

[Oleg Nesterov]

On 03/28, Eric Snow wrote:
>
> On Mon, Mar 20, 2017 at 11:30 AM, Oleg Nesterov  wrote:
> > Hello,
> >
> > Let me first clarify, I do not claim this is a bug, I am trying to learn
> > python and now I trying to understand yield-from.
>
> Given that you haven't gotten a response here,

and this looks a bit strange. My question is simple, the implementation looks
clear and straightforward, I am a bit surprised none of cpython devs bothered
to reply.

> you may want to take
> this over to the core-mentors...@python.org list.

Well, I'm afraid to contact this closed and not-for-mortals list, not sure
this very basic question should go there ;) perhaps you are already a member,
feel free to forward.

I downloaded micropython and it doesn't propagate .close() in this case. but
it seem to differ very much from cpython, not sure this matters at all.

Thanks,

Oleg.

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] What version is an extension module binary compatible with

[Petr Viktorin]

On 03/30/2017 06:31 AM, Nick Coghlan wrote:

On 29 March 2017 at 02:18, Paul Moore  wrote:

On 28 March 2017 at 12:24, Miro Hrončok  wrote:

I'd like some clarification on what ABI compatibility we can expect.
 * Should the ABI be stable across patch releases (so calling
PySlice_AdjustIndices from an existing macro would be a bug)?
 * Should the ABI be forward-compatible within a minor release (so modules
built for 3.6.0 should be usable with 3.6.1, but not vice versa)?
 * Or should we expect the ABI to change even across patch releases?


Given that binary wheels are built against a specific minor version
(3.6, 3.5, ...) I would expect the ABI to be consistent over a minor
release. That would fit with my expectations of the compatibility
guarantees on patch releases.

So I from what you describe, I'd consider this as a bug. Certainly, if
someone built a C extension as a wheel using Python 3.6.1, it would be
tagged as compatible with cp36, and pip would happily use it when
installing to a Python 3.6.0 system, where it would fail.


Right, this is the main problem - while "build against the X.Y.0
headers" is useful advice, it's not something we've ever explicitly
stated, and it's not something we can reasonably expect all providers
of pre-built binary modules to do.


Also, while building against 3.6.0 headers will ensure compatibility, it 
will also restore the original bug that PySlice_AdjustIndices fixes.
Expecting extension authors to build against x.y.0 would lock them out 
of such bug fixes in later releases.



Instead, it makes sense to explicitly strengthen the ABI guarantees
within CPython maintenance releases, and add some automated testing to
avoid accidental changes and oversights (similar to the pending test
to ensure magic number stability for cached bytecode files)

Cheers,
Nick.



___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com