[issue17131] subprocess.Popen.terminate can raise exception on Posix
New submission from S Arrowsmith: Compare this with the script in #14252: p = Popen(['/bin/sleep', '1']) time.sleep(1) p.terminate() print p.poll() p.terminate() Output is: 0 Traceback (most recent call last): File "", line 1, in File "/usr/lib/python2.6/subprocess.py", line 1269, in terminate self.send_signal(signal.SIGTERM) File "/usr/lib/python2.6/subprocess.py", line 1264, in send_signal os.kill(self.pid, sig) OSError: [Errno 3] No such process The 0 return from poll() indicates that the subprocess ran to completion, rather than being terminated by the first terminate. So the first terminate does nothing, but the second terminate raises an exception. In http://bugs.python.org/issue14252#msg155396 : "Raising an exception on terminate is a bug." -- components: Library (Lib) messages: 181425 nosy: siona priority: normal severity: normal status: open title: subprocess.Popen.terminate can raise exception on Posix type: behavior versions: Python 2.6, Python 2.7, Python 3.2 ___ Python tracker <http://bugs.python.org/issue17131> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4963] mimetypes.guess_extension result changes after mimetypes.init()
S Arrowsmith added the comment: That solution looks sound to me, in particular documenting the semantics of repeated init() calls! As for the underlying problem, it seems to me that an alternative to copying the existing structures rather than rebuilding them would be to use OrderedDicts. Although I can't think why it might be a preferable alternative, other than being a bit clearer that order of insertion can affect behaviour. -- ___ Python tracker <http://bugs.python.org/issue4963> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4963] mimetypes.guess_extension result changes after mimetypes.init()
S Arrowsmith added the comment: I've dug into it -- again -- and my original analysis still holds. Getting consistent guess_extension() results across an explicit init() call depends on dict.items() returning keys in the same order on two different dictionaries (the original, hard-coded types_map and the one created by the first, implicit init() call). Why should this be different on Debian to other Linuxes, even given same data as a "working" distribution? Is there something in the implementation details of dict.items() which is that distribution dependent? (A "fix", BTW, is to insert a call to _default_mime_types() either in init() or in MimeTypes.__init__ before it calls init().) -- ___ Python tracker <http://bugs.python.org/issue4963> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4963] mimetypes.guess_extension result changes after mimetypes.init()
S Arrowsmith added the comment:
>>> import mimetypes
>>> mimetypes.guess_extension('image/jpeg')
/etc/mime.types
'.jpe'
>>> mimetypes.init()
/etc/mime.types
>>> mimetypes.guess_extension('image/jpeg')
'.jpeg'
>>>
$ grep jpeg /etc/mime.types
image/jpeg jpeg jpg jpe
$
That big chunk of whitespace is 5 tabs. Not very helpful, I fear.
--
___
Python tracker
<http://bugs.python.org/issue4963>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4963] mimetypes.guess_extension result changes after mimetypes.init()
S Arrowsmith added the comment:
Sorry, still there:
Python 2.7rc2 (r27rc2:82137, Jun 26 2010, 11:27:59)
[GCC 4.3.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import mimetypes
>>> mimetypes.guess_extension('image/jpeg')
'.jpe'
>>> mimetypes.init()
>>> mimetypes.guess_extension('image/jpeg')
'.jpeg'
The fact that it's not reproducible on other Linux systems (I can't reproduce
on the RedHat box I have to hand) might suggest there's something odd about
Debian's mime.types . But I've just tried it passing init() the mime.types from
the (working) RedHat box, and it's still producing the odd behaviour. (And I'm
now on Debian 5.0, so it's not a Debian 4.0-specific issue either.) Wish I had
a convenient Ubuntu install to try it on.
Bizarre.
--
___
Python tracker
<http://bugs.python.org/issue4963>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6925] Doc for locals and vars
Changes by S Arrowsmith : -- nosy: +siona ___ Python tracker <http://bugs.python.org/issue6925> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4963] mimetypes.guess_extension result changes after mimetypes.init()
S Arrowsmith added the comment: Ah, yes, forgot to mention this is on Debian 4.0. I doubt you're going to run into it on a Windows system unless you explicitly give init() a mime.types file, looking at the knownfiles list used by default. ___ Python tracker <http://bugs.python.org/issue4963> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4963] mimetypes.guess_extension result changes after mimetypes.init()
New submission from S Arrowsmith :
Asking mimetypes to reload mime.types can cause guess_extension() to
return a different result if multiple extensions are mapped to that mime
type:
>>> import mimetypes
>>> mimetypes.guess_extension('image/jpeg')
'.jpe'
>>> mimetypes.init()
>>> mimetypes.guess_extension('image/jpeg')
'.jpeg'
>>>
This is because both the forward (extension to type) and inverse (type
to extension) type mapping dicts are populated by iterating through the
existing forward (extension to type) dict (types_map), then supplemented
by reading from mime.types (or any other files given to init()). The
fully populated forward dict becomes the new types_map. Initially,
types_map is hard-coded, but when the type mapping dicts are
repopulated, by explicitly or implicitly calling init() again, it is
done by iterating over the types_map created by the first init() call,
not the hard-coded one. If the iteration order for a set of extensions
with the same type is different in these two versions of the forward
dict, the order of extensions appearing for that type in the inverse
dict will change. And so the behavior of guess_all_extensions() and
hence guess_extension() will change.
--
components: Library (Lib)
messages: 79955
nosy: siona
severity: normal
status: open
title: mimetypes.guess_extension result changes after mimetypes.init()
type: behavior
versions: Python 2.4, Python 2.5
___
Python tracker
<http://bugs.python.org/issue4963>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
