Re: [Python-Dev] cpython (3.3): return NULL here
Am 23.07.2013 07:08, schrieb benjamin.peterson:
> http://hg.python.org/cpython/rev/042ff9325c5e
> changeset: 84804:042ff9325c5e
> branch: 3.3
> parent: 84789:bb63f813a00f
> user:Benjamin Peterson
> date:Mon Jul 22 22:08:09 2013 -0700
> summary:
> return NULL here
>
> files:
> Python/dynload_shlib.c | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
>
> diff --git a/Python/dynload_shlib.c b/Python/dynload_shlib.c
> --- a/Python/dynload_shlib.c
> +++ b/Python/dynload_shlib.c
> @@ -91,7 +91,8 @@
> int i;
> struct stat statb;
> if (fstat(fileno(fp), &statb) == -1) {
> -return PyErr_SetFromErrno(PyExc_IOError);
> +PyErr_SetFromErrno(PyExc_IOError);
> +return NULL;
> }
PyErr_SetFromErrno() already and always returns NULL. Or do you prefer
to return NULL explicitly?
Christian
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython (3.3): return NULL here
2013/7/23 Christian Heimes :
> Am 23.07.2013 07:08, schrieb benjamin.peterson:
>> http://hg.python.org/cpython/rev/042ff9325c5e
>> changeset: 84804:042ff9325c5e
>> branch: 3.3
>> parent: 84789:bb63f813a00f
>> user:Benjamin Peterson
>> date:Mon Jul 22 22:08:09 2013 -0700
>> summary:
>> return NULL here
>>
>> files:
>> Python/dynload_shlib.c | 3 ++-
>> 1 files changed, 2 insertions(+), 1 deletions(-)
>>
>>
>> diff --git a/Python/dynload_shlib.c b/Python/dynload_shlib.c
>> --- a/Python/dynload_shlib.c
>> +++ b/Python/dynload_shlib.c
>> @@ -91,7 +91,8 @@
>> int i;
>> struct stat statb;
>> if (fstat(fileno(fp), &statb) == -1) {
>> -return PyErr_SetFromErrno(PyExc_IOError);
>> +PyErr_SetFromErrno(PyExc_IOError);
>> +return NULL;
>> }
>
> PyErr_SetFromErrno() already and always returns NULL. Or do you prefer
> to return NULL explicitly?
It might always return NULL, but the compiler sees (PyObject *)NULL
when this function returns dl_funcptr.
--
Regards,
Benjamin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] tuple index out of range
Hi, I am new to this list and to troubleshooting python. I hope someone can help me. I am getting this tuple index out of range error while running a test call to my python code. Not sure what this error really means and was hoping someone might shed some light on how to fix this. Also was wondering why much of my .py files are not getting compiled to .pyc upon first run.. is this unusual or need I not worry? Running python 2.5.2 on fedora. Thanks, Nick ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] tuple index out of range
On 23 Jul, 2013, at 12:17, Nicholas Hart wrote: > Hi, > > I am new to this list and to troubleshooting python. I hope someone can help > me. I am getting this tuple index out of range error while running a test > call to my python code. Not sure what this error really means and was hoping > someone might shed some light on how to fix this. Also was wondering why > much of my .py files are not getting compiled to .pyc upon first run.. is > this unusual or need I not worry? > > Running python 2.5.2 on fedora. Nick, This list is focussed on the development of Python, not on development with Python. The python-list list is more appropriate for asking questions like yours. Regards, Ronald > > Thanks, > Nick > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/ronaldoussoren%40mac.com ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython (3.3): return NULL here
On 23 Jul, 2013, at 17:36, Christian Heimes wrote: > Am 23.07.2013 17:10, schrieb Benjamin Peterson: >>> PyErr_SetFromErrno() already and always returns NULL. Or do you prefer >>> to return NULL explicitly? >> >> It might always return NULL, but the compiler sees (PyObject *)NULL >> when this function returns dl_funcptr. > > Oh, you are right. I must have missed the compiler warning. How about we > turn type return and type assignment warnings into fatal errors? That's probably possible with a '-Werror=' argument. But please consider issue 18211 before unconditionally adding such a flag, as that issue mentions new compiler flags also get used when compiling 3th-party extensions. I guess there needs to be (yet) another CFLAGS_xxx variable in the Makefile that gets added to $(CFLAGS) during the build of Python itself, but is ignored by distutils and sysconfig. Ronald > > Christian > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/ronaldoussoren%40mac.com ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython (3.3): return NULL here
Am 23.07.2013 17:10, schrieb Benjamin Peterson: >> PyErr_SetFromErrno() already and always returns NULL. Or do you prefer >> to return NULL explicitly? > > It might always return NULL, but the compiler sees (PyObject *)NULL > when this function returns dl_funcptr. Oh, you are right. I must have missed the compiler warning. How about we turn type return and type assignment warnings into fatal errors? Christian ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding Python scripts to PATHEXT on Windows
Am 15.07.13 10:26, schrieb Paul Moore: > Does anyone have any objections to this? I could try to write a patch, > but I know next to nothing about building MSIs, so if any of the > installer experts could help that would be fantastic. It's fine with me. I could write the patch, but will likely forget - so please remind me with every alpha that misses this. Also, contributions are welcome. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding Python scripts to PATHEXT on Windows
On 23 July 2013 17:11, "Martin v. Löwis" wrote: > Am 15.07.13 10:26, schrieb Paul Moore: > > Does anyone have any objections to this? I could try to write a patch, > > but I know next to nothing about building MSIs, so if any of the > > installer experts could help that would be fantastic. > > It's fine with me. I could write the patch, but will likely forget - so > please remind me with every alpha that misses this. Also, contributions > are welcome. > Thanks. I think I have the basic idea of what's needed, so I'll write an initial patch. If you can check it that'd be great. Paul ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Add modeling file for Coverity Scan.
Am 23.07.2013 08:27, schrieb Antoine Pitrou: > On Tue, 23 Jul 2013 01:31:24 +0200 (CEST) > christian.heimes wrote: >> + >> +typedef int sdigit; >> +typedef long Py_ssize_t; > > Can't you write "typedef ssize_t Py_ssize_t" instead? No, but it really doesn't matter. Coverity just needs a similar type for modeling. "modeling_file.c", line 23: error #20: identifier "ssize_t" is undefined typedef ssize_t Py_ssize_t; ^ 1 error detected in the compilation of "modeling_file.c". ERROR: cov-translate returned with code 2 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Inherance of file descriptor and handles on Windows (PEP 446)
Hi,
Guido van Rossum and others asked me details on how file descriptors
and handles are inherited on Windows, for the PEP 446.
http://www.python.org/dev/peps/pep-0446/
I hacked Python 3.4 to add a os.get_cloexec() function (extracted from
my implementation of the PEP 433), here are some results.
Python functions open(), os.open() and os.dup() create file
descriptors with the HANDLE_FLAG_INHERIT flag set (cloexec=False),
whereas os.pipe() creates 2 file descriptors with the
HANDLE_FLAG_INHERIT flag unset (cloexec=False, see also issue #4708).
Even if the HANDLE_FLAG_INHERIT flag is set, all handles are closed if
subprocess is used with close_fds=True (which is the default value of
the parameter), and all file descriptors are closed except 0, 1 and 2.
If close_fds=False, handles with the HANDLE_FLAG_INHERIT flag set are
inherited, but all file descriptors are still closed except 0, 1 and
2.
(I didn't check if file descriptors 0, 1 and 2 are inherited,
duplicated or new file descriptors.)
The PEP 466 allows you to control which handles are inherited to child
process when you use subprocess with close_fds=False. (The subprocess
parameter should be called "close_handles" on Windows to avoid
confusion.)
Said differently: the HANDLE_FLAG_INHERIT flag only has an effect on
*handles*, as indicated in its name. On Windows, file *descriptors*
are never inherited (are always closed) in child processes. I don't
think that it is possible to inherit file descriptors on Windows.
By the way, using pass_fds on Windows raises an assertion error
("pass_fds not supported on Windows").
Another example in Python:
---
import subprocess, sys
code = """
import os, sys
fd = int(sys.argv[1])
f = os.fdopen(fd, "rb")
print(f.read())
"""
f = open(__file__, "rb")
fd = f.fileno()
subprocess.call([sys.executable, "-c", code, str(fd)], close_fds=False)
---
On Unix, the child process will write the script into stdout. On
Windows, you just get an OSError(9, "Bad file descriptor") exception.
To fix this example on Windows, you have to:
* Retrieve the handle of the file using msvcrt.get_osfhandle() ;
* Pass the handle, instead of the file descriptor, to the child ;
* Create a file descriptor from the handle using
msvcrt.open_osfhandle() in the child.
The fix would be simpler if Python would provide the handle of a file
object (ex: in a method) and if open() supported opening a handle as
it does with file descriptors on UNIX.
Victor
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Inherance of file descriptor and handles on Windows (PEP 446)
On 23/07/2013 11:45pm, Victor Stinner wrote: Said differently: the HANDLE_FLAG_INHERIT flag only has an effect on *handles*, as indicated in its name. On Windows, file*descriptors* are never inherited (are always closed) in child processes. I don't think that it is possible to inherit file descriptors on Windows. Actually, you can inherit fds if you use os.spawnv() instead of subprocess.Popen(). -- Richard ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Inherance of file descriptor and handles on Windows (PEP 446)
The multiprocessing module is an example of use case relying on inherance of handles. It calls CreateProcess() with bInheritHandles=TRUE to share a pipe between the manager (parent) and the worker (child process). Note: subprocess and multiprocess have their own function to set the HANDLE_FLAG_INHERIT flag: they use DuplicateHandle(), whereas SetHandleInformation() could be used (to reuse the existing handle instead of creating a new handle). 2013/7/24 Victor Stinner : > Python functions open(), os.open() and os.dup() create file > descriptors with the HANDLE_FLAG_INHERIT flag set (cloexec=False), > whereas os.pipe() creates 2 file descriptors with the > HANDLE_FLAG_INHERIT flag unset (cloexec=False, see also issue #4708). > (...) > If close_fds=False, handles with the HANDLE_FLAG_INHERIT flag set are > inherited, but all file descriptors are still closed except 0, 1 and > 2. Leaking handles in child processes is also an issue on Windows. Random examples. http://bugs.python.org/issue17634 "Win32: shutil.copy leaks file handles to child processes" "Win32's native CopyFile API call doesn't leak file handles to child processes." http://ghc.haskell.org/trac/ghc/ticket/2650 "The case in which I originally ran into this was System.Directory.copyFile intermittently reporting a "permission denied" error for a temp file it was using. I think it was trying to delete it, but failing because a child process somewhere was hanging on to the Handle." According to the issue, GHC calls CreateProcess with bInheritHandles=TRUE (as Python did until Python 3.2). http://support.microsoft.com/kb/315939 "This behavior can occur if two threads simultaneously create child processes and redirect the STD handles through pipes. In this scenario, there is a race condition during the creation of the pipes and processes, in which it is possible for one child to inherit file handles intended for the other child." => Python looks to be correct, it uses the (StartupInfo) "STARTF_USESTDHANDLES" flag http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6428742 Java is still calling CreateProcess() with bInheritHandles=TRUE which causes issues like "6347873: (so) Ports opened with ServerSocketChannel blocks when using Runtime.exec". Interesting comment: "Submitter has a point. Very risky to fix." :-/ For the record, the default value of close_fds parameter was also set to True on Windows by the following changeset: changeset: 66889:59b43dc34158 user:Gregory P. Smith date:Tue Dec 14 13:43:30 2010 + files: Doc/library/subprocess.rst Lib/subprocess.py Lib/test/test_subprocess.py Misc/NEWS Modules/_posixsubprocess.c description: Issue #6559: fix the subprocess.Popen pass_fds implementation. Add a unittest. Issue #7213: Change the close_fds default on Windows to better match the new default on POSIX. True when possible (False if stdin/stdout/stderr are supplied). Update the documentation to reflect all of the above. The changeset was written to fix http://bugs.python.org/issue7213 ; another example of leak of handles. > The PEP 466 allows you to control which handles are inherited to child > process when you use subprocess with close_fds=False. (The subprocess > parameter should be called "close_handles" on Windows to avoid > confusion.) Another advantage of the PEP 446 is that most of the time, the HANDLE_FLAG_INHERIT flag value can be set atomatically at the creation of the file descriptor (creation of the handle). It is a nice enhancement to fight against race conditions with threads ;-) "Most of the time": for example, socket are inherited by default, WSA_FLAG_NO_HANDLE_INHERIT flag was only added to Windows Vista. Victor ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Inherance of file descriptor and handles on Windows (PEP 446)
On 23 July 2013 23:45, Victor Stinner wrote: > Said differently: the HANDLE_FLAG_INHERIT flag only has an effect on > *handles*, as indicated in its name. On Windows, file *descriptors* > are never inherited (are always closed) in child processes. I don't > think that it is possible to inherit file descriptors on Windows. > That is correct - handles are the OS-level concept, fds are implemented in the CRT. So code that uses raw Windows APIs to create a new process won't have any means to inherit fds. > The fix would be simpler if Python would provide the handle of a file > object (ex: in a method) and if open() supported opening a handle as > it does with file descriptors on UNIX. > That would give a similar level of functionality to Unix. Whether it is used sufficiently often to be worth it, is a separate question, of course... Paul ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython (3.3): return NULL here
On Tue, Jul 23, 2013 at 8:46 AM, Ronald Oussoren wrote: > > On 23 Jul, 2013, at 17:36, Christian Heimes wrote: > > > Am 23.07.2013 17:10, schrieb Benjamin Peterson: > >>> PyErr_SetFromErrno() already and always returns NULL. Or do you prefer > >>> to return NULL explicitly? > >> > >> It might always return NULL, but the compiler sees (PyObject *)NULL > >> when this function returns dl_funcptr. > > > > Oh, you are right. I must have missed the compiler warning. How about we > > turn type return and type assignment warnings into fatal errors? > > That's probably possible with a '-Werror=' argument. But please > consider > issue 18211 before unconditionally adding such a flag, as that issue > mentions > new compiler flags also get used when compiling 3th-party extensions. > > I guess there needs to be (yet) another CFLAGS_xxx variable in the > Makefile that > gets added to $(CFLAGS) during the build of Python itself, but is ignored > by > distutils and sysconfig. > It seems fair to turn those on in 3.4 and require that third party extensions clean up their code when porting from 3.3 to 3.4. > Ronald > > > > > Christian > > > > ___ > > Python-Dev mailing list > > [email protected] > > http://mail.python.org/mailman/listinfo/python-dev > > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/ronaldoussoren%40mac.com > > ___ > Python-checkins mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-checkins > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
