Re: exec() an locals() puzzle

e It is a mystery, which may be why the documentation for globals() and locals() is 2-line long. Le mer. 20 juill. 2022, à 19 h 31, Martin Di Paola < martinp.dipa...@gmail.com> a écrit : > I did a few tests > > # test 1 > def f(): > i = 1 > print(locals()) > exec(

Re: exec() an locals() puzzle

I did a few tests # test 1 def f(): i = 1 print(locals()) exec('y = i; print(y); print(locals())') print(locals()) a = eval('y') print(locals()) u = a print(u) f() {'i': 1} 1 {'i': 1, 'y': 1} {'i': 1,

Re: exec() an locals() puzzle

On 7/20/22, george trojan wrote: > > 1. This works as I expect it to work: > > def f(): > i = 1 > print(locals()) > exec('y = i; print(y); print(locals())') > print(locals()) > exec('y *= 2') > print('ok:', eval

exec() an locals() puzzle

I wish I could understand the following behaviour: 1. This works as I expect it to work: def f(): i = 1 print(locals()) exec('y = i; print(y); print(locals())') print(locals()) exec('y *= 2') print('ok:', eval('y')) f() {'i&#

Re: Explaining exec(globals, separate_locals)

Terry Reedy wrote at 2021-9-20 12:46 -0400: >The second paragraph of the current exec entry >https://docs.python.org/3.11/library/functions.html#exec >ends with a sentence I wrote. > >"If exec gets two separate objects as globals and locals, the code will >be executed as i

Re: Explaining exec(globals, separate_locals)

On 9/20/21, Terry Reedy wrote: > > "If exec gets two separate objects as globals and locals, the code will > be executed as if it were embedded in a class definition." Note that, unlike exec(), the body of a class definition can modify closure variables in nonlocal function

Explaining exec(globals, separate_locals)

The second paragraph of the current exec entry https://docs.python.org/3.11/library/functions.html#exec ends with a sentence I wrote. "If exec gets two separate objects as globals and locals, the code will be executed as if it were embedded in a class definition." Would the followin

Re: exec and globals and locals ...

Peter Otten於 2019年9月20日星期五 UTC+8下午3時31分48秒寫道： > jf...@ms4.hinet.net wrote: > > >>>> x = 3 > >>>> def foo(): > > ... exec("print(globals(), locals()); x = x + 1; print(globals(), > > locals())") ... > >>>> fo

Re: exec and globals and locals ...

jf...@ms4.hinet.net wrote: >>>> x = 3 >>>> def foo(): > ... exec("print(globals(), locals()); x = x + 1; print(globals(), > locals())") ... >>>> foo() > {'foo': , '__package__': None, '__builtins__':

Re: exec and globals and locals ...

>>> x = 3 >>> def foo(): ... exec("print(globals(), locals()); x = x + 1; print(globals(), locals())") ... >>> foo() {'foo': , '__package__': None, '__builtins__': , '__loader__': , '__doc__': No

Re: exec and globals and locals ...

Am Donnerstag, 19. September 2019 20:24:49 UTC+2 schrieb Peter Otten: > Eko palypse wrote: > > > Am Donnerstag, 19. September 2019 18:31:43 UTC+2 schrieb Peter Otten: > >> Eko palypse wrote: > >> > >> > No, I have to correct myself > >> > &g

Re: exec and globals and locals ...

Eko palypse wrote: > Am Donnerstag, 19. September 2019 18:31:43 UTC+2 schrieb Peter Otten: >> Eko palypse wrote: >> >> > No, I have to correct myself >> > >> > x = 5 >> > def f1(): >> > exec("x = x + 1; print('f1 in:

Re: exec and globals and locals ...

Am Donnerstag, 19. September 2019 18:31:43 UTC+2 schrieb Peter Otten: > Eko palypse wrote: > > > No, I have to correct myself > > > > x = 5 > > def f1(): > > exec("x = x + 1; print('f1 in:', x)") > > return x > >

Re: exec and globals and locals ...

First thank you for all the answers, very much appreciated. I assume the root cause might be explained by the zen of python as well. If the implementation is hard to explain, it's a bad idea. Maybe I need to rethink my implementation :-) Eren -- https://mail.python.org/mailman/listinfo/python-l

Re: exec and globals and locals ...

Eko palypse wrote: > No, I have to correct myself > > x = 5 > def f1(): > exec("x = x + 1; print('f1 in:', x)") > return x > print('f1 out', f1()) > > results in the same, for me confusing, results. > > f1 in: 6 > f1 out

Re: exec and globals and locals ...

No, I have to correct myself x = 5 def f1(): exec("x = x + 1; print('f1 in:', x)") return x print('f1 out', f1()) results in the same, for me confusing, results. f1 in: 6 f1 out 5 Eren -- https://mail.python.org/mailman/listinfo/python-list

Re: exec and globals and locals ...

Eko palypse wrote: > Thank you, I'm currently investigating importlib and read that > __builtins__ might be another alternative. > My ultimate goal would be to have objects available without the need to > import them, regardless whether used in a script directly or used in an > imported module. I

Re: exec and globals and locals ...

Richard Damon wrote: > On 9/19/19 6:16 AM, Eko palypse wrote: >>> In all cases, if the optional parts are omitted, the code is executed in >>> the current scope. ... >>> >>> >>> You can see from it that "globals" is optional. >>>

Re: exec and globals and locals ...

I’m not the OP, but I want to thank you for that clarification. I had previously not understood the ramifications of the following in section “7. Simple statements” in “The Python Language Reference”: “An augmented assignment expression like x += 1 can be rewritten as x = x + 1 to achieve a si

Re: exec and globals and locals ...

gt;>>> >>>> >>>> You can see from it that "globals" is optional. >>>> And that, if "globals" is missing, then >>>> "exec" is executed in the current scope ("f1" in your case). >>> Thank you for y

Re: exec and globals and locals ...

; namespaces takes place. > > > > Thank you too for your answer. Ok, that means that in every case when exec > > imports something it has its own global namespace, right? > > Is there a way to manipulate this namespace before any code from that > > module gets executed? &

Re: exec and globals and locals ...

Eko palypse wrote: >> Then it should be clear that the name 'test01' is put into globals(), if >> load_module() doesn't throw an exception. No sharing or nesting of >> namespaces takes place. > > Thank you too for your answer. Ok, that means that in ever

Re: exec and globals and locals ...

rom it that "globals" is optional. > >> And that, if "globals" is missing, then > >> "exec" is executed in the current scope ("f1" in your case). > > Thank you for your answer, and that is exactly what confuses me? > > Where does

Re: exec and globals and locals ...

On 9/19/19 6:16 AM, Eko palypse wrote: >> In all cases, if the optional parts are omitted, the code is executed in the >> current scope. ... >> >> >> You can see from it that "globals" is optional. >> And that, if "globals" is missing, then

Re: exec and globals and locals ...

> Then it should be clear that the name 'test01' is put into globals(), if > load_module() doesn't throw an exception. No sharing or nesting of > namespaces takes place. Thank you too for your answer. Ok, that means that in every case when exec imports something it has

Re: exec and globals and locals ...

> In all cases, if the optional parts are omitted, the code is executed in the > current scope. ... > > > You can see from it that "globals" is optional. > And that, if "globals" is missing, then > "exec" is executed in the current scope ("

Re: exec and globals and locals ...

Eko palypse wrote: > exec('import test01', globals()) > print('f3 out', x) > > # result exception, expected but because f1 didn't throw an exception > # I'm confused. module test01 has only this two lines > x += 1 > print('f3 in:', x)

Re: exec and globals and locals ...

Eko palypse writes: > Why does f1 work? I've expected an exception as no global dict has been > provided > ... >def f1(...): > exec("...") >... The documentation ("https://docs.python.org/3/library/functions.html#exec";) tells you: exec(object[, g

exec and globals and locals ...

Why does f1 work? I've expected an exception as no global dict has been provided, and why does throw f3 an exception if it does, more or less, the same as f1? x += 5 def f1(): exec("x += 1; print('f1 in:', x)") return x print('f1 out', f1()) # resu

Re: Using exec with embedded python interpreter 3.7

@MRAB, I'm building a notepad++ plugin which can execute the written code and if one writes help(os) it gets executed via exec(editor.getText()) and output redirected to the plugin console window. Sorry to you as well as I have also replied to you directly. Thank you -- https://mail.pytho

Re: Using exec with embedded python interpreter 3.7

Just saw, that I replied to you directly instead to python list, sorry. That did it, changed encoding from function to property and now I'm able to call help(object) Thank you. -- https://mail.python.org/mailman/listinfo/python-list

Re: Using exec with embedded python interpreter 3.7

hon interpreter by using cffi to build the dll. So far so good. One obstacle I've found is that I'm not able to use exec(help(object)) in order to get the wanted info from the object. The error I get is: Traceback (most recent call last): File "", line 131, in run_code

Re: Using exec with embedded python interpreter 3.7

bedded python interpreter > by using cffi to build the dll. So far so good. One obstacle I've found is > that I'm not able to use exec(help(object)) in order to get the wanted > info from the object. > > The error I get is: > > Traceback (most recent call last): >

Using exec with embedded python interpreter 3.7

dll. So far so good. One obstacle I've found is that I'm not able to use exec(help(object)) in order to get the wanted info from the object. The error I get is: Traceback (most recent call last): File "", line 131, in run_code File "", line 1, in File &q

Using exec with embedded python interpreter 3.7

Hello, I'm creating a notepad++ plugin which hosts an embedded python interpreter by using cffi to build the dll. So far so good. One obstacle I've found is that I'm not able to use exec(help(object)) in order to get the wanted info from the object. The error I get is: Traceba

Re: exec and traceback

On 1/22/18 3:22 AM, ken...@gameofy.com wrote: I'm using exec() to run a (multi-line) string of python code. If an exception occurs, I get a traceback containing a stack frame for the string. I've labeled the code object with a "file name" so I can identify it easily,

Re: exec and traceback

ken...@gameofy.com writes: > I'm using exec() to run a (multi-line) string of python code. If an > exception occurs, I get a traceback containing a stack frame for the > string. I've labeled the code object with a "file name" so I can > identify it easily, and

Re: exec and traceback

On 1/22/18 3:22 AM, ken...@gameofy.com wrote: (BTW, I've written a simple secure eval()) You have accurately guessed our interest!  Would you mind starting a new thread to show us your simple secure eval? --Ned. -- https://mail.python.org/mailman/listinfo/python-list

Re: exec and traceback

On Mon, Jan 22, 2018 at 7:22 PM, wrote: > > > I'm using exec() to run a (multi-line) string of python code. If an > exception occurs, I get a traceback containing a stack frame for the string. > I've labeled the code object with a "file name" so I can identi

exec and traceback

I'm using exec() to run a (multi-line) string of python code. If an exception occurs, I get a traceback containing a stack frame for the string. I've labeled the code object with a "file name" so I can identify it easily, and when I debug, I find that I can interact w

Re: How to exec a string which has an embedded '\n'? (Posting On Python-List Prohibited)

Lawrence D’Oliveiro於 2018年1月1日星期一 UTC+8上午7時56分02秒寫道： > On Sunday, December 31, 2017 at 11:04:19 PM UTC+13, jf...@ms4.hinet.net wrote: > > > > This answer makes me think about '\' more thoughtful:-) > > Python generating HTML containing JavaScript which generates HTML: > > out.write \ >

Re: How to exec a string which has an embedded '\n'?

Random832於 2017年12月31日星期日 UTC+8下午1時25分50秒寫道： > On Sat, Dec 30, 2017, at 23:57, jf...@ms4.hinet.net wrote: > > I have a multiline string, something like '''...\nf.write('\n')\n...''' > > when pass to exec(), I got > > SyntaxError: EO

Re: How to exec a string which has an embedded '\n'?

On Sat, Dec 30, 2017, at 23:57, jf...@ms4.hinet.net wrote: > I have a multiline string, something like '''...\nf.write('\n')\n...''' > when pass to exec(), I got > SyntaxError: EOL while scanning string literal > > How to get rid of

How to exec a string which has an embedded '\n'?

I have a multiline string, something like '''...\nf.write('\n')\n...''' when pass to exec(), I got SyntaxError: EOL while scanning string literal How to get rid of it? Best Regards, Jach Fong -- https://mail.python.org/mailman/listinfo/python-list

Re: `exec`-based routine crashes app upon migration from 3.4.3 to python 3.5.2.

On Tue, Aug 2, 2016 at 1:45 AM, Lawrence D’Oliveiro wrote: > On Friday, July 29, 2016 at 6:25:51 AM UTC+12, Enjoys Math wrote: > >> exec('obj = ' + objType + '(self)', None, _locals) >> obj = _locals['obj'] > >

Re: `exec`-based routine crashes app upon migration from 3.4.3 to python 3.5.2.

On Friday, July 29, 2016 at 6:25:51 AM UTC+12, Enjoys Math wrote: > exec('obj = ' + objType + '(self)', None, _locals) > obj = _locals['obj'] Why? Why not just obj = objType(self) ? -- https://mail.python.org/mailman/listinfo/python-list

Re: `exec`-based routine crashes app upon migration from 3.4.3 to python 3.5.2.

if listJ != None: >> for objJ in listJ: >> _locals = locals() >> exec('obj = ' + objType + '(self)', None, _locals) >> obj = _locals['obj'] >> obj.loadJson(objJ) &

Re: `exec`-based routine crashes app upon migration from 3.4.3 to python 3.5.2.

On Thu, Jul 28, 2016, at 11:47, Enjoys Math wrote: > So what's the proper way to get the return value of an exec call when > there is one? Exec calls do not have return values. If you need to pass an object out of the exec call to the surrounding context, you can wrap it in an ex

Re: `exec`-based routine crashes app upon migration from 3.4.3 to python 3.5.2.

_locals = locals() > exec('obj = ' + objType + '(self)', None, _locals) > obj = _locals['obj'] > obj.loadJson(objJ) > self.addLSobjOfType(objType, obj) > > when breakpoints are set on `obj=_loc

`exec`-based routine crashes app upon migration from 3.4.3 to python 3.5.2.

I've manually set breakpoints and traced this app crash back to this function: def loadLSobjsOfType(self, objType, listJ): if listJ != None: for objJ in listJ: _locals = locals() exec('obj = ' + objType + '(s

Re: Conversion: execfile --> exec

On Mon, Jun 13, 2016 at 1:51 PM Rustom Mody wrote: > looks (to me) like an intent to import the package chaco with no locals > and globals -- Just guessing of course > And without creating a module object. I suppose that means it doesn't get cached in sys.modules either. Not sure if that's a fea

Re: Conversion: execfile --> exec

ved in python 3.x. > > > > So my problem is how to convert the above to a 3.x based command? > > > > > > > > thanks very much > > > > > > > Open the file and pass it to exec: > > > > > > info = {} > > > with open(

Re: Conversion: execfile --> exec

> > execfile(join('chaco', '__init__.py'), info) > > > -- > > > > > > But execfile has been removed in python 3.x. > > > So my problem is how to convert the above to a 3.x based command? > > > &

Re: Conversion: execfile --> exec

; -- > > > > But execfile has been removed in python 3.x. > > So my problem is how to convert the above to a 3.x based command? > > > > thanks very much > > > Open the file and pass it to exec: > > info = {} > with open(joi

Re: Conversion: execfile --> exec

above to a 3.x based command? thanks very much Open the file and pass it to exec: info = {} with open(join('chaco', '__init__.py')) as file: exec(file.read(), info) -- https://mail.python.org/mailman/listinfo/python-list

Conversion: execfile --> exec

The python 2.x command is as following: --- info = {} execfile(join('chaco', '__init__.py'), info) -- But execfile has been removed in python 3.x. So my problem is how to convert the above to a 3.x based command? thanks very much -- https://mai

Re: exec inside functions in Python 3

On Tue, Mar 22, 2016 at 11:57 PM, Steven D'Aprano wrote: > Anyone have any idea what is going on here? > > > def test(): > spam = 1 > exec("spam = 2; print('inside exec: %d' % spam)") > print('outside exec: %d' % spam) > &

exec inside functions in Python 3

Anyone have any idea what is going on here? def test(): spam = 1 exec("spam = 2; print('inside exec: %d' % spam)") print('outside exec: %d' % spam) In Python 2.7: py> test() inside exec: 2 outside exec: 2 In Python 3.4: outside exec: 1 py> t

Re: exec "x = 3; print x" in a - How does it work?

On Wed, Mar 9, 2016 at 5:25 PM, Veek. M wrote: > ah, okay - i'm familiar with the py3 syntax where you do: > eval('whatever stmt', globals={}, locals={}) > I suppose this: exec " " in NS; syntax is strictly py2? > > Many thanks :) Yeah, that's

Re: exec "x = 3; print x" in a - How does it work?

Steven D'Aprano wrote: > On Wednesday 09 March 2016 16:27, Veek. M wrote: > >> What is the return value of `exec`? Would that object be then used to >> iterate the sequence in 'a'? I'm reading this: >> https://www.python.org/download/releases/2.2.3/de

Re: exec "x = 3; print x" in a - How does it work?

Ben Finney wrote: > "Veek. M" writes: > >> What is the return value of `exec`? > > You can refer to the documentation for questions like that. > https://docs.python.org/3/library/functions.html#exec> > >> Would that object be then used to iterate th

Re: exec "x = 3; print x" in a - How does it work?

On Wednesday 09 March 2016 16:27, Veek. M wrote: > What is the return value of `exec`? Would that object be then used to > iterate the sequence in 'a'? I'm reading this: > https://www.python.org/download/releases/2.2.3/descrintro/ exec is a statement, not a function, so

Re: exec "x = 3; print x" in a - How does it work?

"Veek. M" writes: > What is the return value of `exec`? You can refer to the documentation for questions like that. https://docs.python.org/3/library/functions.html#exec> > Would that object be then used to iterate the sequence in 'a'? The ‘for’ or ‘while’ stateme

exec "x = 3; print x" in a - How does it work?

What is the return value of `exec`? Would that object be then used to iterate the sequence in 'a'? I'm reading this: https://www.python.org/download/releases/2.2.3/descrintro/ -- https://mail.python.org/mailman/listinfo/python-list

Re: fork/exec & close file descriptors

The subprocess module uses upper bound MAXFD which is defined as try: MAXFD = os.sysconf("SC_OPEN_MAX") except: MAXFD = 256 /Jean -- https://mail.python.org/mailman/listinfo/python-list

Re: fork/exec & close file descriptors

On Thu, Jun 4, 2015 at 6:07 AM, wrote: > On Wed, Jun 3, 2015, at 09:32, Chris Angelico wrote: >> Write an editor that opens a file and holds it open until the user's >> done with it. Have something that lets you shell out for whatever >> reason. Then trigger the shell-out, and instantly SIGSTOP t

Re: fork/exec & close file descriptors

random...@fastmail.us: > On Wed, Jun 3, 2015, at 10:43, Marko Rauhamaa wrote: >> However, the child process needs to be prepared for os.close() to >> block indefinitely because of an NFS problem or because SO_LINGER has >> been specified by the parent, for example. Sett

Re: fork/exec & close file descriptors

On Wed, Jun 3, 2015, at 10:43, Marko Rauhamaa wrote: > However, the child process needs to be prepared for os.close() to block > indefinitely because of an NFS problem or because SO_LINGER has been > specified by the parent, for example. Setting the close-on-exec flag > doesn't he

Re: fork/exec & close file descriptors

On Wed, Jun 3, 2015, at 09:32, Chris Angelico wrote: > Write an editor that opens a file and holds it open until the user's > done with it. Have something that lets you shell out for whatever > reason. Then trigger the shell-out, and instantly SIGSTOP the child > process, before it does its work -

Re: fork/exec & close file descriptors

alister : > I meant the program that is supplying your app with file handles > willy- nilly without caring what happens to them You seem to be advocating a strategy whereby the application keeps close track of all file descriptors and closes them individually as needed. Thing is, processes can b

Re: fork/exec & close file descriptors

However, the child process needs to be prepared for os.close() to block indefinitely because of an NFS problem or because SO_LINGER has been specified by the parent, for example. Setting the close-on-exec flag doesn't help there. Marko -- https://mail.python.org/mailman/listinfo/python-list

Re: fork/exec & close file descriptors

Marko Rauhamaa : > random...@fastmail.us: > >> Why does the child process need to report the error at all? The parent >> process will find out naturally when *it* tries to close the same file >> descriptor. > > That's not how it goes. > > File descriptors are reference counted in the Linux kernel.

Re: fork/exec & close file descriptors

On Wed, Jun 3, 2015 at 11:21 PM, wrote: > On Wed, Jun 3, 2015, at 09:08, Marko Rauhamaa wrote: >> random...@fastmail.us: >> >> > Why does the child process need to report the error at all? The parent >> > process will find out naturally when *it* tries to close the same file >> > descriptor. >> >

Re: fork/exec & close file descriptors

On Wed, Jun 3, 2015, at 09:08, Marko Rauhamaa wrote: > random...@fastmail.us: > > > Why does the child process need to report the error at all? The parent > > process will find out naturally when *it* tries to close the same file > > descriptor. > > That's not how it goes. > > File descriptors a

Re: fork/exec & close file descriptors

aning, simply because ranges have no >> meaning for file descriptors (they're not ordered in any way). What if >> some library uses its own descriptors that happen to lie in your >> "range"? Etc. > > The context in which this is useful is that you've just forke

Re: fork/exec & close file descriptors

random...@fastmail.us: > Why does the child process need to report the error at all? The parent > process will find out naturally when *it* tries to close the same file > descriptor. That's not how it goes. File descriptors are reference counted in the Linux kernel. Closes are no-ops except for

Re: fork/exec & close file descriptors

On Wed, 03 Jun 2015 15:27:19 +0300, Marko Rauhamaa wrote: > alister : > >> from the scenario Marco is reporting I get the impression that he is >> having to interact with a system that is fundamentally flawed from the >> ground up. > > Well, yes. It's called linux, but it's not all bad. I just t

Re: fork/exec & close file descriptors

On Wed, Jun 3, 2015, at 08:25, Marko Rauhamaa wrote: > Steven D'Aprano : > > > How does the child process know what action didn't complete? What > > error message are you going to display to the user? > > You definitely must not use sys.stderr from the child process nor are > you allowed to exit

Re: fork/exec & close file descriptors

alister : > from the scenario Marco is reporting I get the impression that he is > having to interact with a system that is fundamentally flawed from the > ground up. Well, yes. It's called linux, but it's not all bad. I just think that man page was being sanctimonious. Marko -- https://mail.p

Re: fork/exec & close file descriptors

Steven D'Aprano : > How does the child process know what action didn't complete? What > error message are you going to display to the user? > > "Error when closing file descriptor 123456" > > What action do you think the user can take on seeing this error > message? Besides, even if you wanted to

Re: fork/exec & close file descriptors

ing for file descriptors (they're not ordered in any way). What if > some library uses its own descriptors that happen to lie in your > "range"? Etc. The context in which this is useful is that you've just forked, and you're about to exec. "Some library" isn't

Re: fork/exec & close file descriptors

On Wed, 03 Jun 2015 22:07:47 +1000, Steven D'Aprano wrote: > On Wed, 3 Jun 2015 07:38 pm, alister wrote: > >> On Wed, 03 Jun 2015 10:41:44 +0300, Marko Rauhamaa wrote: > [...] >>> Here's the deal: the child process is saddled with file descriptors it >>> never wanted in the first place. It can't

Re: fork/exec & close file descriptors

On Wed, 3 Jun 2015 07:38 pm, alister wrote: > On Wed, 03 Jun 2015 10:41:44 +0300, Marko Rauhamaa wrote: [...] >> Here's the deal: the child process is saddled with file descriptors it >> never wanted in the first place. It can't decline them. Now you're >> saying it can't even dispose of them. >>

Re: fork/exec & close file descriptors

On Wed, 03 Jun 2015 10:41:44 +0300, Marko Rauhamaa wrote: > Alain Ketterlin : > >> Marko Rauhamaa writes: >>> Maybe close() will fail for ever. >> >> Your program has to deal with this, something is going wrong, it can't >> just close and go on. > > Here's the deal: the child process is saddled

Re: fork/exec & close file descriptors

Alain Ketterlin : > Marko Rauhamaa writes: >> Maybe close() will fail for ever. > > Your program has to deal with this, something is going wrong, it can't > just close and go on. Here's the deal: the child process is saddled with file descriptors it never wanted in the first place. It can't decl

Re: fork/exec & close file descriptors

Marko Rauhamaa writes: > Alain Ketterlin : > >> Marko Rauhamaa writes: >>> First, if close() fails, what's a poor program to do? >> >> Warn the user? Not assume everything went well? It all depends on the >> application, and what the file descriptor represents. > > The problem here is in the sys

Re: fork/exec & close file descriptors

Chris Angelico writes: > On Wed, Jun 3, 2015 at 7:06 AM, Alain Ketterlin > wrote: >> I've no idea what the OP's program was doing, so I'm not going to split >> hairs. I can't imagine why one would like to mass-close an arbitrary set >> of file descriptors, and I think APIs like os.closerange() a

Re: fork/exec & close file descriptors

Folks, I'm not interested in rehashing this. I don't know what all the open file descriptors are. Some/many/most will have been opened by underlying C++ libraries and will not have been opened by code at the Python level. I do think the addition of an os.fsync() attempt on each file descriptor befo

Re: fork/exec & close file descriptors

On Wed, Jun 3, 2015 at 7:06 AM, Alain Ketterlin wrote: > I've no idea what the OP's program was doing, so I'm not going to split > hairs. I can't imagine why one would like to mass-close an arbitrary set > of file descriptors, and I think APIs like os.closerange() are toxic and > an appeal to slop

Re: fork/exec & close file descriptors

of open files in the system may grow over all limits or simply waste kernel resources. Close-on-exec is nice, maybe. However, you don't have control over all file descriptors. Loggers, high-level library calls and others open files without the application programmer knowing or having direct

Re: fork/exec & close file descriptors

;t followed the thread, but if your problem is to make sure >> fds are closed on exec, you may be better off using the... >> close-on-exec flag. Or simply do the bookkeeping.) > > The quoted man page passage is a bit untenable. > > First, if close() fails, what's a po

Re: fork/exec & close file descriptors

reported at the > | final close(). Not checking the return value when closing the file > | may lead to silent loss of data. This can especially be observed > | with NFS and with disk quota. > | > > (I haven't followed the thread, but if your problem is to make sure > fds are cl

Re: fork/exec & close file descriptors

On 2015-06-02, Marko Rauhamaa wrote: > Skip Montanaro : > >> On Tue, Jun 2, 2015 at 10:28 AM, Marko Rauhamaa wrote: >>> >>> The only problem is that you don't know how high you need to go in >>> general. >> >> Sure, but I didn't know anyway, so no matter what upper bound I choose >> (or what func

Re: fork/exec & close file descriptors

Skip Montanaro : > On Tue, Jun 2, 2015 at 10:28 AM, Marko Rauhamaa wrote: >> >> The only problem is that you don't know how high you need to go in >> general. > > Sure, but I didn't know anyway, so no matter what upper bound I choose > (or what function I choose/implement), it's just going to be

Re: fork/exec & close file descriptors

Skip Montanaro writes: > Reviving (and concluding) a thread I started a couple weeks ago, I asked: > >> The basic fork/exec dance is not a problem, but how do I discover >> all the open file descriptors in the new child process to make sure >> they get closed? Do I simpl

Re: fork/exec & close file descriptors

On Tue, Jun 2, 2015 at 10:28 AM, Marko Rauhamaa wrote: > > The only problem is that you don't know how high you need to go in > general. Sure, but I didn't know anyway, so no matter what upper bound I choose (or what function I choose/implement), it's just going to be a guess. os.closerange just

Re: fork/exec & close file descriptors

Skip Montanaro : > os.closerange(fd_low, fd_high) > Close all file descriptors from fd_low (inclusive) to fd_high > (exclusive), ignoring errors. > > Guido's time machine strikes again... The only problem is that you don't know how high you need to go in general. Marko -- https://m

Re: fork/exec & close file descriptors

Reviving (and concluding) a thread I started a couple weeks ago, I asked: > The basic fork/exec dance is not a problem, but how do I discover > all the open file descriptors in the new child process to make sure > they get closed? Do I simply start at fd 3 and call os.close() on > e

Re: fork/exec & close file descriptors

On Tue, May 19, 2015 at 7:10 PM, Gregory Ewing wrote: >> On Tue, May 19, 2015 at 8:54 AM, Chris Angelico > > wrote: >> >> On Linux (and possibly some other Unixes), /proc/self/fd may be of >> use. > > > On MacOSX, /dev/fd seems to be the equivalent of this. Not a

Re: fork/exec & close file descriptors

On Tue, May 19, 2015 at 8:54 AM, Chris Angelico > wrote: On Linux (and possibly some other Unixes), /proc/self/fd may be of use. On MacOSX, /dev/fd seems to be the equivalent of this. -- Greg -- https://mail.python.org/mailman/listinfo/python-list

  1   2   3   4   5   6   7   8   >