Python's STDOUT isn't flushed

[ikegami]

As reported on StackOverflow, Python's STDOUT isn't flushed

use feature qw( say );

use Inline Python => <<'END_OF_PYTHON_CODE';

def test_print() -> int:
    print("In the python test print")
    return 32

END_OF_PYTHON_CODE

say "Got back ", test_print();

Output:

$ perl a.pl
In the python test print
Got back 32

$ perl a.pl | cat
Got back 32

Who knows what other destruction doesn't occur.

[ikegami]

One can work around this issue by adding the following to one's program:

END { Inline::Python::py_finalize(); }

[matthewpersico]

That doesn't quite solve the output issue. See here; we get all the output, but it is scrambled.

[ikegami]

That doesn't quite solve the output issue. See here; we get all the output, but it is scrambled.

That's expected, completely normal, and not a bug in the module.

[matthewpersico]

That's expected, completely normal, and not a bug in the module.

Then it might warrant a comment in the docs. Would you take a PR for such?

[ikegami]

That's expected, completely normal, and not a bug in the module.

Then it might warrant a comment in the docs. Would you take a PR for such?

Whenever you have two things trying to use one resource (e.g. a terminal), coordination (e.g. synchronization) is required, or at least needs to be considered.

[matthewpersico]

Whenever you have two things trying to use one resource (e.g. a terminal), coordination (e.g. synchronization) is required, or at least needs to be considered.

Yes, I see now. Here, we have two interpreters running, each with its own process space. Would this be an issue if we were inlining a compiled language? I would think not because then the inline'd code is just a library being executed in the Perl process space.

The distinction is important to me in terms of how I want to propose a documentation PR - I propose it would go in the Inline docs themselves under a heading like "Considering Non-Compiled Inline Modules"

[niner]

On Mittwoch, 18. August 2021 19:00:13 CEST Matthew O. Persico wrote: Yes, I see now. Here, we have two interpreters running, each with its own process space. Would this be an issue if we were inlining a compiled language? I would think not because then the inline'd code is just a library being executed in the Perl process space.

That's not correct. The Python interpreter is running the very same process as Perl does. In fact the Python interpreter really is just a library written in C. The same is actually true for Perl itself. You'll run into the same issue with any library that is written like it's fully in charge of a ressource like STDOUT.

[ikegami]

"running, each with its own process space", You mean address space? There isn't two. There's only process and thus only one address space. "Would this be an issue if we were inlining a compiled language?" But you are loading a library written in a compiled language. (Not sure in which language `python` is written. C?)

…

On Wed., Aug. 18, 2021, 2:00 p.m. Matthew O. Persico, < ***@***.***> wrote: Whenever you have two things trying to use one resource (e.g. a terminal), coordination (e.g. synchronization) is required, or at least needs to be considered. Yes, I see now. Here, we have two interpreters running, each with its own process space. Would this be an issue if we were inlining a compiled language? I would think not because then the inline'd code is just a library being executed in the Perl process space. The distinction is important to me in terms of how I want to propose a documentation PR - I propose it would go in the Inline docs themselves under a heading like "Considering Non-Compiled Inline Modules" — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#32 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFK2ZPAECCWGLA6GPYIHB3T5PRJ3ANCNFSM5BR4QU5A> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email> .