[issue20104] expose posix_spawn(p)
Danek Duvall added the comment: Oh, for what it's worth, Solaris added setsid support to posix_spawn a few years ago, as a result of this conversation. I still think it would be worthwhile supporting this in the stdlib, since we keep running into processes which have a lot of memory reserved and can't fork some small program because they're running in a memory-limited environment. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue20104> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26414] os.defpath too permissive
Changes by Danek Duvall <duv...@comfychair.org>: -- nosy: +dhduvall ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26414> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7918] distutils always ignores byte compilation errors
Changes by Danek Duvall duv...@comfychair.org: -- nosy: +dhduvall ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7918 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7918] distutils always ignores byte compilation errors
Danek Duvall added the comment: As a distribution maintainer of several Python modules, I've run into this bug twice in the past week. In each case, the python file in question had a SyntaxError and failed to compile, but the error just scrolled past in a large log and was missed because no failure occurred until we attempted to package the result, and the .pyc files were missing. While we managed to track the problem down fairly easily in both cases, if we only had folks working on the problem that didn't have lots of experience in tracking down build issues, this could have wasted a lot of otherwise valuable engineering time. I understand the desire to be able to package files that fail to compile, but having that be the default seems to me like it fails basic expectations, even given how long this bug has been around. I can't imagine that the number of deliberately-broken python files is particularly large compared to the number of python files that might get broken accidentally (or files that are broken for one version of python but not another) and so being required to maintain an exception list doesn't seem unreasonable. (Neither does some amount of transition period -- one or two minor releases of Python? -- between the introduction of the mechanism and the change of the default.) Would people be interested in a patch to that effect? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7918 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7918] distutils always ignores byte compilation errors
Danek Duvall added the comment: Absolutely true that developers should have tests that would detect such bugs. However, the sooner you detect a bug, the more time you save. And by the time it reaches someone like me, who is just packaging up the module for distribution with an OS, it's just going to waste my time, too, with less benefit (because I'm still not going to have much of an incentive to write tests). Imagine if your C compiler only warned about code that wouldn't compile, and failed to produce the corresponding .o file without erroring out, and the linker failed to error out when that .o file was missing, and that you only noticed the problem when you ran your tests (or, if you're just shipping someone else's code, when your customer calls you to complain). Wouldn't you think that was stunningly broken? Again, I get that there are use cases for having broken code pass through unscathed, but it seems very odd to me (as someone with a long unix background) that this would have been a conscious default. Now that it is the default, I understand the need for caution, but caution needn't (and shouldn't) prevent bugs from getting fixed. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7918 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20104] expose posix_spawn(p)
Danek Duvall added the comment: Our project (the Solaris packaging system, IPS), relies on posix_spawn() primarily for the ability to fork without making a large memory reservation (and possibly failing) because the forking process was itself very large. That's the (a?) bug benefit of posix_spawn() -- it's not a benefit for the programmer using it (who might have to fall back to fork/exec), but for the end-user that benefits from its streamlined operation. You're right that it doesn't handle everything that subprocess.Popen() does -- though at least on Solaris there's a way to change the cwd in the file actions, and I'm sure we'd consider adding a way to do the setsid() as well. The rest should be possible cross-platform. -- nosy: +dhduvall ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20104 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20104] expose posix_spawn(p)
Danek Duvall added the comment: Cool. We implemented our own version as a straight-up native module (https://java.net/projects/ips/sources/pkg-gate/content/src/modules/pspawn.c), and our Popen replacement is not at present a complete replacement for the one in the stdlib, but it does what we need it to do. We'd absolutely switch if it came in to the stdlib, though, and I think there would be plenty of programs that would benefit from it (certainly a number of large Python programs in Solaris have run into exactly this problem). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20104 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1222585] C++ compilation support for distutils
Changes by Danek Duvall duv...@comfychair.org: -- nosy: +dhduvall ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1222585 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13405] Add DTrace probes
Danek Duvall duv...@comfychair.org added the comment: - I have added a sys.trace_capabilities, so a program can know if any system-trace functionality is compiled in. Current values are None and (dtrace, Sun). I'm not sure Sun is the right name here. I'd say either SunOS or Solaris (or the lowercase of either). Sun typically refers to Sun hardware, which isn't relevant here, and the company, which doesn't exist anymore, also isn't particularly relevant. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13405 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1298835] vendor-packages directory.
Danek Duvall duv...@comfychair.org added the comment: So this has come up again within the Solaris group. Since Rich's original request, we've been using a vendor-packages.pth file in the site-packages directory, which enables the vendor-packages directory. However, I have a concern that this would completely disappear when Py_NoSiteFlag is enabled. I would like to run the interpreter with -SE on all system-provided scripts, so that modules installed by the user in a private PYTHONPATH or in site-packages via easy_install (or similar) don't inadvertently interpose on system-provided modules which are the ones we've tested against. I'm attaching a patch (against 2.6.4; sorry, haven't looked at anything newer yet) that modifies pythonrun.c to add initvendor() as a parallel with initmain() and initsite(), and is always run, regardless of Py_NoSiteFlag, but inserts vendor-packages after site-packages for when the user or a script is okay with the potential interposition. If support for vendor-packages is being considered in general, I'd like to address the request for a rationale that has been brought up a handful of times before. Specifically, distro vendors (such as ourselves) want to be able to deliver non-core python modules -- some written ourselves, some available from the community at large. If we do that in the canonical site-packages directory, then those modules are at risk of being overwritten by local administrators installing python packages as they normally would. This means that system programs -- including critical ones on Solaris, such as the packaging system -- might suddenly stop working. If we separate the vendor space from the end-user space, then local admins can do anything they want without fear of breaking the system. And if they really want to replace the vendor-supplied modules, then they can either go to the lengths of making the modules install in vendor-packages, or build using the same mechanisms we do (whi ch for almost all the python we ship are still open-source) and install the resulting (system, not python) package. I'd love feedback on my patch, regardless. -- nosy: +dhduvall Added file: http://bugs.python.org/file22030/vps.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1298835 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4111] Add Systemtap/DTrace probes
Changes by Danek Duvall duv...@comfychair.org: -- nosy: +dhduvall ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4111 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6529] get{pw,gr}{nam,[ug]id}() calls are not re-entrant
New submission from Danek Duvall duv...@comfychair.org:
In tracking down
6861990 getgrnam_r() str2group() function makes decisions based
on return value before it's set
(viewable on bugs.opensolaris.org), I noted that the pwd and grp modules
don't use the MT-safe interfaces to the password and group name service
tables. The _r() interfaces have been around for a long time, are
standard, and should be used if at all possible. That said, I can't
imagine it's terribly likely that people will go to the lengths
necessary to actually put multiple calls in flight at the same time in
CPython, but should it ever become easy to put this code into concurrent
threads, it'll likely fall over.
--
components: Library (Lib)
messages: 90743
nosy: dhduvall
severity: normal
status: open
title: get{pw,gr}{nam,[ug]id}() calls are not re-entrant
type: behavior
versions: Python 2.6
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6529
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
