[issue24293] Windows installer unreadable with std/custom themes
New submission from Mike Miller: The new Windows installer displays itself with an HTML (or perhaps skinned) interface with hard-coded white background which does not adhere to the desktop GUI color scheme chosen by the user. Many times this is only an aesthetic problem, but it may cause the window to be unreadable if the user is using a darker, custom color scheme, or one of the standard Accessible themes such as High Contrast. Invariably the developer/framework sets only one out of two of the background/foreground pair, which I believe happened here. See attached, the white text is lost on a white background. Please set both the background/foreground to system colors to avoid this issue. These are available in CSS as well, though not commonly known. -- components: Installation, Windows files: pywin_setup.png messages: 244140 nosy: mixmastamyk, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Windows installer unreadable with std/custom themes type: behavior versions: Python 3.5 Added file: http://bugs.python.org/file39511/pywin_setup.png ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24293 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22758] Regression in Python 3.2 cookie parsing
Changes by Tim Graham timogra...@gmail.com: Added file: http://bugs.python.org/file39512/secure-httponly-3.2-backport.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22758 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22758] Regression in Python 3.2 cookie parsing
Tim Graham added the comment: Patch rebased again after cookie fix from #22931. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22758 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23560] Group the docs of similar methods in stdtypes.rst
Changes by Berker Peksag berker.pek...@gmail.com: -- nosy: +berker.peksag ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23560 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24292] wsgiref.simple_server.WSGIRequestHandler doesn't log request timeouts
Changes by Berker Peksag berker.pek...@gmail.com: -- nosy: +berker.peksag ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24292 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24293] Windows installer unreadable with std/custom themes
Steve Dower added the comment: Thanks, good catch. I'm not entirely sure how we ended up in this state, since the background is actually the system colour and the text is currently hardcoded, but I'll go through and make sure that the system colour indexes are used throughout. FWIW, it's just plain Win32 UI, nothing special, but it does use some controls that were added in Windows XP and don't get used very often. -- assignee: - steve.dower ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24293 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24293] Windows installer unreadable with std/custom themes
Roundup Robot added the comment: New changeset a77214dbf1f3 by Steve Dower in branch '3.5': Issue #24293: Fixes installer colors to use system settings throughout. https://hg.python.org/cpython/rev/a77214dbf1f3 New changeset 37ed61b1234a by Steve Dower in branch 'default': Issue #24293: Fixes installer colors to use system settings throughout. https://hg.python.org/cpython/rev/37ed61b1234a -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24293 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21970] Broken code for handling file://host in urllib.request.FileHandler.file_open
Martin Panter added the comment: I do not believe the change fixes anything on its own. It essentially just changed the error message to something even worse, and the added test case already passes without the change. I am posting a patch which cleans up the code and related tests. It also fixes three minor theoretical bugs: urlopen(file://127.0.0.1//dev/null) # Should succeed urllib.error.URLError: urlopen error unknown url type: file urlopen(file://127.1//dev/null) # 127.1 is localhost; should succeed urllib.error.URLError: urlopen error file:// scheme is supported only on localhost urlopen(file://remote/missing) # Should not try to access local file urllib.error.URLError: urlopen error [Errno 2] No such file or directory: '/missing' The localhost check in file_open() was added by revision 982c8ec73ae3 for Issue 10063. But notice how all the test cases involve strange URLs like file://ftp.example.com//foo.txt, with second extra double slash. I removed the check, because it is redundant with the more thorough and correct check that has existed since 1994 (revision 020d8c2d9d3c) in open_local_file(). For cases like file://remote/nonlocal-file, I think it is better to raise the correct error, even if that requires a DNS check, rather than raising a faster error with a misleading message. So I moved the check before the stat() call inside open_local_file(). -- keywords: +patch stage: - patch review type: - behavior versions: +Python 3.5, Python 3.6 Added file: http://bugs.python.org/file39513/file-handler.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21970 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24293] Windows installer unreadable with std/custom themes
Changes by Steve Dower steve.do...@microsoft.com: -- resolution: - fixed stage: - resolved status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24293 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24009] Get rid of rare format units in PyArg_Parse*
Martin Panter added the comment: “u#” should not be deprecated without first deprecating “u”, which is less useful due to not returning a buffer length. Also, I have always been mystified about how “s#”, “z#”, “y” and “y#” can properly to return a pointer into a buffer for arbitrary immutable bytes-like objects, without requiring PyBuffer_Release() to be called. Perhaps this is bad design to be discouraged. Or maybe a documentation oversight somewhere. -- nosy: +vadmium ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24009 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24287] Let ElementTree prolog include comments and processing instructions
Stefan Behnel added the comment: FTR, lxml's Element class has addnext() and addprevious() methods which are commonly used for this purpose. But ET can't adopt those due to its different tree model. I second Martin's comment that ET.append() is a misleading name. It suggests adding stuff to the end, whereas things are actually being inserted before the root element here. I do agree, however, that this is a helpful feature and that the ElementTree class is a good place to expose it. I propose to provide a prolog (that's the spec's spelling) property holding a list that users can fill and modify any way they wish. The serialiser would then validate that all content is proper XML prologue content, and would serialise it in order. My guess is that lxml would eventually use a MutableSequence here that maps changes directly to the underlying tree (and would thus validate them during modification), but ET can be more lenient, just like it allows arbitrary objects in the text and tail properties which only the serialiser rejects. Note that newlines can easily be generated on user side by setting the tail of a PI/Comment to \n. (The serialiser must also validate that the tail text is only allowed whitespace.) For reference: http://www.w3.org/TR/REC-xml/#sec-prolog-dtd -- components: +XML ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24287 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10685] trace does not ignore --ignore-module
Tom Hines added the comment: Test attached. Paste into test/test_trace.py. I tested in 2.7 and 3.4. Feel free to modify it. -- Added file: http://bugs.python.org/file39503/test_ignoredir.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10685 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24288] Include/opcode.h is modified during building
New submission from Serhiy Storchaka: Changeset eeeb666a5365 in issue24017 unintentionally changed formatting of generated file Include/opcode.h. Now clean building CPython modifies Include/opcode.h. One solution is to restore formatting of Include/opcode.h (regenerate it and commit). Other solution is to change Tools/scripts/generate_opcode_h.py to generate a file without trailing spaces. -- components: Build messages: 244089 nosy: asvetlov, gvanrossum, haypo, ncoghlan, python-dev, scoder, serhiy.storchaka, yselivanov priority: normal severity: normal stage: needs patch status: open title: Include/opcode.h is modified during building type: compile error versions: Python 3.5, Python 3.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24288 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24009] Get rid of rare format units in PyArg_Parse*
Martin Panter added the comment: Yes I just figured out that myself. Specifically, PyBufferProcs.bf_releasebuffer has to be NULL, and the buffer stays alive as long as the object stays alive. Also it looks like I was wrong about “u” being useless. I was tricked by a contradiction in the documentation, but I will try to fix this in a patch to Issue 24278. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24009 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24278] Docs on Parsing arguments should say something about mem mgmt for formatters returning C strings
Martin Panter added the comment: Here is a patch. Looking at the code, s#, z#, y and y# are the conversions that call convertbuffer(). These require that the object does not have a PyBufferProcs.bf_releasebuffer() method, which guarantees that the buffer’s lifetime is the same as the underlying object. In the patch I also removed a contradictory notice about nulls with the “u” conversion. -- keywords: +patch stage: needs patch - patch review versions: +Python 3.4, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file39504/buffer-convert.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24278 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24286] Should OrderedDict.viewitems compare equal to dict.viewitems when the items are equal?
Serhiy Storchaka added the comment: I don't know if it is worth to backport this feature (dict views were registered in 1f024a95e9d9), but the patch itself LGTM. I think tests should be foreported to 3.x (if they don't exist in 3.x). Are there generic set tests similar to mapping_tests and seq_tests? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24286 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24009] Get rid of rare format units in PyArg_Parse*
Serhiy Storchaka added the comment: “s#”, “z#”, “y” and “y#” work only with read-only buffers, for which PyBuffer_Release() is no-op operation. Initially they was designed for work with old buffer protocol that doesn't support releasing a buffer. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24009 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23359] Speed-up set_lookkey()
Changes by Raymond Hettinger raymond.hettin...@gmail.com: -- versions: +Python 3.6 -Python 3.5 Added file: http://bugs.python.org/file39505/nd_lookkey_insertkey3.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23359 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24286] Should OrderedDict.viewitems compare equal to dict.viewitems when the items are equal?
Roundup Robot added the comment: New changeset ff8b603ee51e by Raymond Hettinger in branch 'default': Issue #24286: Forward port dict view abstract base class tests. https://hg.python.org/cpython/rev/ff8b603ee51e -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24286 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24286] Should OrderedDict.viewitems compare equal to dict.viewitems when the items are equal?
Raymond Hettinger added the comment: I don't know if it is worth to backport this feature I don't think so either. The Iterator registry is a bit of a waste. Are there generic set tests similar to mapping_tests and seq_tests? Not that I know of. Also, I don't see the need. -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24286 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24286] Should OrderedDict.viewitems compare equal to dict.viewitems when the items are equal?
Changes by Raymond Hettinger raymond.hettin...@gmail.com: -- stage: - resolved ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24286 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24286] Should OrderedDict.viewitems compare equal to dict.viewitems when the items are equal?
Roundup Robot added the comment: New changeset 9213c70c67d2 by Raymond Hettinger in branch '2.7': Issue #24286: Register dict views with the MappingView ABCs. https://hg.python.org/cpython/rev/9213c70c67d2 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24286 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16927] Separate built-in types from functions and group similar functions in functions.rst
Changes by Martin Panter vadmium...@gmail.com: -- nosy: +vadmium ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16927 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24258] BZ2File objects do not have name attribute
Cliff Dyer added the comment: I'd be happy to take a look at this one, if no one else is working on it. -- nosy: +jcd ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24258 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24281] String formatting: incorrect number of decimal places
Eric V. Smith added the comment: And I just double checked: the entirety of the sentence you quoted is: The precision is a decimal number indicating how many digits should be displayed after the decimal point for a floating point value formatted with 'f' and 'F', or before and after the decimal point for a floating point value formatted with 'g' or 'G'. I think that's reasonably clear for 'g' and 'G', but if you think it could be improved, I'm open to suggestions. Maybe the disconnect is that 'g' is the default? The only reason I'm following up on this is that I'm familiar with all of this, yet it still took me some experimenting to remember what the issue is. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24281 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24285] regression for importing extensions in packages
Roundup Robot added the comment: New changeset 55e6f3f94b99 by Nick Coghlan in branch '3.5': Issue #24285: fix importing extensions from packages https://hg.python.org/cpython/rev/55e6f3f94b99 New changeset 32ee7b9d58c9 by Nick Coghlan in branch 'default': Merge fix for issue #24285 from 3.5 https://hg.python.org/cpython/rev/32ee7b9d58c9 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24285 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24268] PEP 489 -- Multi-phase extension module initialization
Nick Coghlan added the comment: I registered the fix for importing extension modules from packages against issue 24285 in the commit and NEWS file rather than against this original implementation RFE. Commit references in http://bugs.python.org/issue24285#msg244098 -- resolution: - fixed stage: - resolved status: open - closed type: - enhancement ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24268 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23560] Group the docs of similar methods in stdtypes.rst
Martin Panter added the comment: Here is a patch that groups similar methods of the str() class together at various levels. I added an alphabetical index of the methods, currently as a big paragraph of hyperlinks in the existing String Methods section. Then I added the following seven new sections. Ideally they would be ordered from important to obscure. * String Formatting * Searching and Replacing * Splitting and Joining * String Classification * Case Manipulation * Padding and Stripping * Translation and Encoding Within each section, most methods remain separate with no change to their descriptions. Some are grouped under a single description, where a there is an obvious pattern. I have tried put closely related methods nearby, while putting important and simple methods higher up, and moving their obscure and complex counterparts lower down. Depending on outcome of these changes to the string methods, I may also be interested in doing a similar job to the bytes() and bytearray() methods. -- keywords: +patch stage: needs patch - patch review versions: +Python 3.6 Added file: http://bugs.python.org/file39506/str-groups.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23560 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24260] TabError behavior doesn't match documentation
Stefan Krah added the comment: Prohibiting tabs after spaces is not enough. No, I really meant that once a new block is started with tabs, all following nested blocks must use tabs for indentation. The only place where spaces would be allowed is for aligment in logical lines that extend over multiple physical lines. Basically, just tab-oblivious formatting (which is generally nice for other languages). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24260 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24285] regression for importing extensions in packages
Nick Coghlan added the comment: Since this error was in the beta release, I used this issue reference in the NEWS file, rather than the original implementation issue. -- resolution: duplicate - fixed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24285 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24281] String formatting: incorrect number of decimal places
James Luscher added the comment:
Eric,
I am not familiar with the 'g' format and did not know it was the default, but
the documentation, read fully, is correct. It just took the response of
Christopher Welborn to wake me up (it was a LONG day and I was struggling
to understand the problem - I would hate to tell you how long I worked on this
problem ! {embarrassment!!}).
My programming usually involves text manipulation, data structures and GUIs.
The am familiar with the use of 'precision' as length of the decimal fraction
but was thrown by (the equally valid) use of 'precision' as the mathematical
idea referring to 'significant digits'. Counting BOTH sides of decimal point
was a difficult switch of word meaning to get my head around.
Just because I have never(!) used the 'g' format doesn't mean it isn't the
proper choice for 'default'. Language is often a challenge and 'precision'
with two meanings (# of digits to right of decimal AND total # of digits {right
and left of decimal)) does present a linguistic challenge to one's ability to
comprehend what the word means ;-)
I wish I could give you the solution but at least I (finally !) understand the
mental issue involved.
Thanks to both of you for your help getting me past my 'mental fugue' ;-)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24281
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21998] asyncio: support fork
Yury Selivanov added the comment: I was thinking only in the child. The parent should be able to continue to use the loop as if the fork didn't happen, right? Yes, everything should be fine. I'll rephrase my question: do you think there is a way (and need) to at least throw a warning in the master process that the fork has failed (without monkey patching os.fork() which is not an option)? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21998 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21998] asyncio: support fork
Martin Richard added the comment: Hi, My patch was a variation of haypo's patch. The goal was to duplicate the loop and its internal objects (loop and self pipes) without changing much to its state from the outside (keeping callbacks and active tasks). I wanted to be conservative with this patch, but it is not the option I prefer. I think that raising a RuntimeError in the child is fine, but may not be enough: Imho, saying the loop can't be used anymore in the child is fine, but a process in which lives an asyncio loop must not be forked is too restrictive (I'm not thinking of the fork+exec case, which is probably fine anyway) because a library may rely on child processes, for instance. Hence, we should allow a program to fork and eventually dispose the resources of the loop by calling loop.close() - or any other mechanism that you see fit (clearing all references to the loop is tedious because of the global default event loop and the cycles between futures/tasks and the loop). However, the normal loop.close() sequence will unregister all the fds registered to the selector, which will impact the parent. Under Linux with epoll, it's fine if we only close the selector. I would therefore, in the child after a fork, close the loop without breaking the selector state (closing without unregister()'ing fds), unset the default loop so get_event_loop() would create a new loop, then raise RuntimeError. I can elaborate on the use case I care about, but in a nutshell, doing so would allow to spawn worker processes able to create their own loop without requiring an idle blank child process that would be used as a base for the workers. It adds the benefit, for instance, of allowing to share data between the parent and the child leveraging OS copy-on-write. 2015-05-26 18:20 GMT+02:00 Yury Selivanov rep...@bugs.python.org: Yury Selivanov added the comment: How do other event loops handle fork? Twisted, Tornado, libuv, libev, libevent, etc. It looks like using fork() while an event loop is running isn't recommended in any of the above. If I understand the code correctly, libev gevent reinitialize loops in the forked process (essentially, you have a new loop). I think we have the following options: 1. Document that using fork() is not recommended. 2. Detect fork() and re-initialize event loop in the child process (cleaning-up callback queues, re-initializing selectors, creating new self-pipe). 3. Detect fork() and raise a RuntimeError. Document that asyncio event loop does not support forking at all. 4. The most recent patch by Martin detects the fork() and reinitializes self-pipe and selector (although all FDs are kept in the new selector). I'm not sure I understand this option. I'm torn between 2 3. Guido, Victor, Martin, what do you think? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21998 ___ -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21998 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21998] asyncio: support fork
Yury Selivanov added the comment: That's really the problem of the code that calls fork(), not directly of the event loop. There are some very solid patterns around that (I've written several in the distant past, and Unix hasn't changed that much :-). Alright ;) I'll draft a patch sometime soon. -- assignee: - yselivanov ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21998 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21998] asyncio: support fork
Guido van Rossum added the comment: I don't understand. If the fork fails nothing changes right? I guess I'm missing some context or use case. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21998 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21998] asyncio: support fork
Yury Selivanov added the comment: I don't understand. If the fork fails nothing changes right? I guess I'm missing some context or use case. Maybe I'm wrong about this. My line of thoughts is: a failed fork() call is a bug in the program. Now, the master process will continue operating as it was, no warnings, no errors. The child process will crash with a RuntimeError exception. Will it be properly reported/logged? I guess the forked child will share the stderr, so the exception won't pass completely unnoticed, right? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21998 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21998] asyncio: support fork
Yury Selivanov added the comment: I would therefore, in the child after a fork, close the loop without breaking the selector state (closing without unregister()'ing fds), unset the default loop so get_event_loop() would create a new loop, then raise RuntimeError. I can elaborate on the use case I care about, but in a nutshell, doing so would allow to spawn worker processes able to create their own loop without requiring an idle blank child process that would be used as a base for the workers. It adds the benefit, for instance, of allowing to share data between the parent and the child leveraging OS copy-on-write. The only solution to safely fork a process is to fix loop.close() to check if it's called from a forked process and to close the loop in a safe way (to avoid breaking the master process). In this case we don't even need to throw a RuntimeError. But we won't have a chance to guarantee that all resources will be freed correctly (right?) So the idea is (I guess it's the 5th option): 1. If the forked child doesn't call loop.close() immediately after forking we raise RuntimeError on first loop operation. 2. If the forked child calls (explicitly) loop.close() -- it's fine, we just close it, the error won't be raised. When we close we only close the selector (without unregistering or re-regestering any FDs), we cleanup callback queues without trying to close anything). Guido, do you still think that raising a RuntimeError in a child process in an unavoidable way is a better option? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21998 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16991] Add OrderedDict written in C
Eric Snow added the comment: Eric I realize that O (1) deletion is hard, and don't see a good way around it without changing the implementation ... I just think that the preserving the current C layout may be forcing an even more complicated solution than neccessary. I am nervous about pushing this to 3.5 because of the complexity. I agree that a simpler solution should (also?) wait for 3.6. Noted (and thanks for the feedback). I'm still comfortable with moving ahead for 3.5 with what we have. The code is documented and structured in such a way that it should be clear what's going on and relatively straightforward to adjust. There's a decent chance we will find a bug or two in corner cases, but nothing at a scale that would give me pause for a 3.5 release. Furthermore, the test suite for OrderedDict is pretty thorough so strict compatibility with the pure Python OrderedDict allows us to derive a lot of confidence about the C implementation. The question about dictheaher.h boils down to: if someone asks whether something is a dictview (not even using exact, though that isn't an option), an odictview will say false ... is that really what you want? Ah. I misunderstood your question to imply what should be added. Instead, you were just indicating what is already there. I don't think anything needs to be changed though. Those checks don't pass for the pure Python OrderedDict so I would not expect them to do so for the C implementation. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16991 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24289] can't start Python3 due to ImportError of copy_reg
Changes by Zachary Ware zachary.w...@gmail.com: -- components: -2to3 (2.x to 3.x conversion tool) ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24289 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21998] asyncio: support fork
Guido van Rossum added the comment: I think only (3) is reasonable -- raise RuntimeError. There are too many use cases to consider and the behavior of the selectors seems to vary as well. Apps should ideally not fork with an event loop open; the only reasonable thing to do after a fork with an event loop open is to exec another binary (hopefully closing FDs using close-on-exec). *Perhaps* it's possible to safely release some resources used by a loop after a fork but I'm skeptical even of that. Opportunistically closing the FDs used for the self-pipe and the selector seems fine (whatever is safe could be done the first time the loop is touched after the fork, just before raising RuntimeError). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21998 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24270] PEP 485 (math.isclose) implementation
Tal Einat added the comment: Attached is a revised patch including changed due to the reviews by Berker and Yuri. The significant changes from the previous patch are: 1. The rel_tol and abs_tol parameters have been made keyword-only. 2. The tests have been extracted into a separate TestCase sub-class. They are now better organized and will be easy to re-use for testing cmath.isclose when it is added (hopefully soon). -- Added file: http://bugs.python.org/file39509/math_isclose_v3.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24270 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24292] wsgiref.simple_server.WSGIRequestHandler doesn't log request timeouts
New submission from Jonathan Kamens: http.BaseHTTPRequestHandler logs request timeouts. In handle_one_request(): except socket.timeout as e: #a read or a write timed out. Discard this connection self.log_error(Request timed out: %r, e) self.close_connection = 1 return Unfortunately, wsgiref.simple_server.WSGIRequestHandler, which overrides BaseHTTPRequestHandler's handle() method, does _not_ catch and log request timeouts. Fixing this is a simple matter of wrapping the entire body of its handle() function in a try with this except clause: except socket.timeout as e: self.log_error(Request timed out: %r, e) raise -- components: Library (Lib) messages: 244134 nosy: Jonathan Kamens priority: normal severity: normal status: open title: wsgiref.simple_server.WSGIRequestHandler doesn't log request timeouts type: behavior versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24292 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24291] wsgiref.handlers.SimpleHandler truncates large output blobs
New submission from Jonathan Kamens: The _write method of wsgiref.handlers.SimpleHandler reads as follows: def _write(self,data): self.stdout.write(data) The problem here is that calling write() on a socket is not actually guaranteed to write all of the data in the buffer. If the length of data is large enough, then the kernel will take only part of it. In that case, the rest of the response data will be silently discarded by wsgiref. _write needs to check the return value of self.stdout.write(data), and if it is less than the length of data, repeat the write from the middle of the data buffer, etc., until all the data has been written. -- components: Library (Lib) messages: 244131 nosy: Jonathan Kamens priority: normal severity: normal status: open title: wsgiref.handlers.SimpleHandler truncates large output blobs type: behavior versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24291 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21998] asyncio: support fork
Guido van Rossum added the comment: I don't actually know if the 5th option is possible. My strong requirement is that no matter what the child process does, the parent should still be able to continue using the loop. IMO it's better to leak a FD in the child than to close a resource owned by the parent. Within those constraints I'm okay with various solutions. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21998 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24290] c_uint32 bitfields break structures
Ned Deily added the comment:
Without diving into the details of your test program, I get the same results on
a 64-bit Debian Python 2.7.9 as with a 64-bit OS X 2.7.10:
c_uint32 TESTS:
Class Name exponentnumber Signfloat
binary repr
IEEE754Float_u ('-0x7b', '0xbeb2aL', 0L, 69.95930480957031, ['0x42', '0x8b',
'0xeb', '0x2a'])
IEEE754Float_u ('-0x7b', '0xbeb2aL', 0L, 69.95930480957031, ['0x42', '0x8b',
'0xeb', '0x2a'])
AN575Float_uint ('0x0', '0xbeb2a', 0L, 1.094551427887186e-39, ['0x0', '0xb',
'0xeb', '0x2a'])
AN575Float_uint ('0x0', '0xbeb2a', 0L, 1.094551427887186e-39, ['0x0', '0xb',
'0xeb', '0x2a'])
AN575Float_uint ('-0x7b', '0xbeb2a', 0L, 1.094551427887186e-39, ['0x85', '0xb',
'0xeb', '0x2a'])
IEEE754Float_u ('-0x7b', '0xbeb2aL', 1L, -69.95930480957031, ['0xc2', '0x8b',
'0xeb', '0x2a'])
AN575Float_uint ('-0x7b', '0xbeb2a', 1L, 1.094551427887186e-39, ['0x85',
'0x8b', '0xeb', '0x2a'])
But using the same OS X 2.7.10 in 32-bit mode, I get:
c_uint32 TESTS:
Class Name exponentnumber Signfloat
binary repr
IEEE754Float_u ('-0x7b', '0xbeb2aL', 0L, 69.95930480957031, ['0x42', '0x8b',
'0xeb', '0x2a'])
IEEE754Float_u ('-0x7b', '0xbeb2aL', 0L, 69.95930480957031, ['0x42', '0x8b',
'0xeb', '0x2a'])
AN575Float_uint ('-0x7b', '0xbeb2a', 0L, 69.95930480957031, ['0x85', '0xb',
'0xeb', '0x2a'])
AN575Float_uint ('-0x7b', '0xbeb2a', 0L, 69.95930480957031, ['0x85', '0xb',
'0xeb', '0x2a'])
AN575Float_uint ('-0x7b', '0xbeb2a', 0L, 69.95930480957031, ['0x85', '0xb',
'0xeb', '0x2a'])
IEEE754Float_u ('-0x7b', '0xbeb2aL', 1L, -69.95930480957031, ['0xc2', '0x8b',
'0xeb', '0x2a'])
AN575Float_uint ('-0x7b', '0xbeb2a', 1L, -69.95930480957031, ['0x85', '0x8b',
'0xeb', '0x2a'])
--
nosy: +ned.deily
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24290
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24290] c_uint32 bitfields break structures
New submission from Rony Batista: ctypes Structures with c_uint32 bitfields have strange behaviour on OS X. In the attached code when the field number is set, it changes the whole 32 bits, even thou its meant to be 23 bits. The behavior is unexpected in: OS X: Python 2.7.9 The behavior is as expected in the following environments: Windows: python 2.7.9 Ubuntu: python 2.7.6 -- components: ctypes messages: 244125 nosy: Rony Batista priority: normal severity: normal status: open title: c_uint32 bitfields break structures type: behavior versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24290 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16500] Add an 'atfork' module
Changes by Yury Selivanov yseliva...@gmail.com: -- nosy: +yselivanov ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16500 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24284] Inconsistency in startswith/endswith
Serhiy Storchaka added the comment: Could you please help me with wording? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24284 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24290] c_uint32 bitfields break structures
Ronald Oussoren added the comment: You forgot to actually attach the code. -- nosy: +ronaldoussoren ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24290 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23509] Speed up Counter operators
Serhiy Storchaka added the comment: Perhaps correct __pos__ docstring? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23509 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23509] Speed up Counter operators
Changes by Serhiy Storchaka storch...@gmail.com: -- Removed message: http://bugs.python.org/msg244128 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23509 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23509] Speed up Counter operators
Serhiy Storchaka added the comment: Perhaps update __pos__ docstring? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23509 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21998] asyncio: support fork
Martin Richard added the comment: 015-05-26 20:40 GMT+02:00 Yury Selivanov rep...@bugs.python.org: Yury Selivanov added the comment: The only solution to safely fork a process is to fix loop.close() to check if it's called from a forked process and to close the loop in a safe way (to avoid breaking the master process). In this case we don't even need to throw a RuntimeError. But we won't have a chance to guarantee that all resources will be freed correctly (right?) If all the tasks are cancelled and loop's internal structures (callback lists, tasks sets, etc) are cleared, I believe that the garbage collector will eventually be able to dispose everything. However, it's indeed not enough: resources created by other parts of asyncio may leak (transports, subprocess). For instance, I proposed to add a detach() method for SubprocessTransport here: http://bugs.python.org/issue23540 : in this case, I need to close stdin, stdout, stderr pipes without killing the subprocess. So the idea is (I guess it's the 5th option): 1. If the forked child doesn't call loop.close() immediately after forking we raise RuntimeError on first loop operation. 2. If the forked child calls (explicitly) loop.close() -- it's fine, we just close it, the error won't be raised. When we close we only close the selector (without unregistering or re-regestering any FDs), we cleanup callback queues without trying to close anything). Guido, do you still think that raising a RuntimeError in a child process in an unavoidable way is a better option? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21998 ___ -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21998 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24290] c_uint32 bitfields break structures
Rony Batista added the comment: Silly me, Heres the code. -- Added file: http://bugs.python.org/file39508/ctypesBug.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24290 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24291] wsgiref.handlers.SimpleHandler truncates large output blobs
Changes by Ned Deily n...@acm.org: -- nosy: +pje versions: +Python 3.6 -Python 3.2, Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24291 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23359] Speed-up set_lookkey()
Changes by Raymond Hettinger raymond.hettin...@gmail.com: Added file: http://bugs.python.org/file39510/new_set_timings.txt ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23359 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24292] wsgiref.simple_server.WSGIRequestHandler doesn't log request timeouts
Changes by Ned Deily n...@acm.org: -- nosy: +pje versions: +Python 3.6 -Python 3.2, Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24292 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24270] PEP 485 (math.isclose) implementation
Tal Einat added the comment: Significant questions brought up by Berker Peksağ in his review of the latest patch (thanks for the review!): 1. Should the tolerance parameters be keyword-only? Berker suggests that they should be. I agree. 2. Should the math.isclose() tests be split into a separate TestCase class with many separate methods? It is currently a single method which does all of the testing for math.isclose(). (Chris's original code has it separated into several TestCase classes; I consolidated it into a single method to keep in line with the current structure of the math module's tests.) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24270 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24284] Inconsistency in startswith/endswith
R. David Murray added the comment: Just in the what's new porting section, I think. The fact that there should be very little to no code that relies on this is why I'd like to see it fixed. The fact that the report was a theoretical one, and not one that broke code, is why I think we should fix it only in 3.5. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24284 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24289] can't start Python3 due to ImportError of copy_reg
R. David Murray added the comment: copyreg.py is part of the standard library, but you obviously have a file shadowing it in your site-packages. If this is a result of the pip upgrade, you should report this to the pip tracker. -- nosy: +r.david.murray resolution: - third party stage: - resolved status: open - closed type: compile error - behavior ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24289 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24288] Include/opcode.h is modified during building
Yury Selivanov added the comment: Other solution is to change Tools/scripts/generate_opcode_h.py to generate a file without trailing spaces. I like this option. I saw the whitespace, but I usually don't touch autogenerated files, so I naturally thought that someone has modified the tooling before my commit and it's fine. Anyways, please see the attached patch. -- keywords: +patch Added file: http://bugs.python.org/file39507/opcodes_ws.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24288 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24289] can't start Python3 due to ImportError of copy_reg
New submission from Mike Basca:
Hello,
I recently upgraded pip and pip3 and now I can't start python3.
This is the Traceback I receive when I started python 3.4.3 (python2.7.10 is
fine).
localhost:PP4E Mike$ python3
Failed to import the site module
Traceback (most recent call last):
File
/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/site.py, line
562, in module
main()
File
/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/site.py, line
548, in main
known_paths = addusersitepackages(known_paths)
File
/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/site.py, line
281, in addusersitepackages
user_site = getusersitepackages()
File
/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/site.py, line
257, in getusersitepackages
user_base = getuserbase() # this will also set USER_BASE
File
/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/site.py, line
247, in getuserbase
USER_BASE = get_config_var('userbase')
File
/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/sysconfig.py,
line 589, in get_config_var
return get_config_vars().get(name)
File
/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/sysconfig.py,
line 568, in get_config_vars
import _osx_support
File
/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/_osx_support.py,
line 4, in module
import re
File /Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/re.py,
line 336, in module
import copyreg
File
/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/site-packages/copyreg.py,
line 3, in module
from copy_reg import *
ImportError: No module named 'copy_reg'
Any help would be appreciated.
--
components: 2to3 (2.x to 3.x conversion tool)
messages: 244107
nosy: abaskm
priority: normal
severity: normal
status: open
title: can't start Python3 due to ImportError of copy_reg
type: compile error
versions: Python 3.4
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24289
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24270] PEP 485 (math.isclose) implementation
Tal Einat added the comment: Regarding the tests, I now realize that most of them should be reused for testing cmath.isclose(), which means they'll have to be defined outside of test_math.MathTests. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24270 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24284] Inconsistency in startswith/endswith
Martin Panter added the comment: How about this for What’s New: * The :meth:`str.startswith` and :meth:`str.endswith` methods no longer return ``True`` when finding the empty string and the indexes are completely out of range. See :issue:`24284`. Perhaps that is good enough, but if you wanted to be more precise, I think the actual condition is if the *start* index is beyond the end of the string, or *end* is before *start*. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24284 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23756] Tighten definition of bytes-like objects
Changes by Martin Panter vadmium...@gmail.com: -- stage: needs patch - patch review ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23756 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24291] wsgiref.handlers.SimpleHandler truncates large output blobs
Martin Panter added the comment: [UTF-8 error workaround] What kind of object is “stdout”? Plain Python socket objects don’t have a write() method. Perhaps “stdout” is meant to implement the BufferedIOBase.write() interface, which guarantees everything is written, even if it takes multiple raw calls. Wrapping your output stream in BufferedWriter might be a solution. -- nosy: +vadmium ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24291 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23648] PEP 475 meta issue
Changes by STINNER Victor victor.stin...@gmail.com: -- status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23648 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1322] Deprecate platform.dist() and platform.linux_distribution() functions
Dimitri John Ledkov added the comment: Why not change them to parse os-release files as defined by http://www.freedesktop.org/software/systemd/man/os-release.html A lot of things use these functions to check what one is running on, despite the problems, and do different things at install time. This deprecation and eventual removal, will result in a pypi module created with such functionality anyway, that everyone will try to pull in or falling that copying in. Here in https://clearlinux.org team we have patches to switch these to parse /etc/os-release;/usr/lib/os-release files instead. Would you be open to deprecate parsing any other files but os-release going forward? As that is standard across all linux distributions for quite some time now. Regards, Dimitri. Debian Developer, Ubuntu Core Developer, Clear Linux* Project Developer. -- nosy: +xnox ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1322 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21998] asyncio: support fork
Yury Selivanov added the comment: How do other event loops handle fork? Twisted, Tornado, libuv, libev, libevent, etc. It looks like using fork() while an event loop is running isn't recommended in any of the above. If I understand the code correctly, libev gevent reinitialize loops in the forked process (essentially, you have a new loop). I think we have the following options: 1. Document that using fork() is not recommended. 2. Detect fork() and re-initialize event loop in the child process (cleaning-up callback queues, re-initializing selectors, creating new self-pipe). 3. Detect fork() and raise a RuntimeError. Document that asyncio event loop does not support forking at all. 4. The most recent patch by Martin detects the fork() and reinitializes self-pipe and selector (although all FDs are kept in the new selector). I'm not sure I understand this option. I'm torn between 2 3. Guido, Victor, Martin, what do you think? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21998 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21998] asyncio: support fork
Yury Selivanov added the comment: I think only (3) is reasonable -- raise RuntimeError. Just to be clear -- do we want to raise a RuntimeError in the parent, in the child, or both processes? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21998 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21998] asyncio: support fork
Changes by Christian Heimes li...@cheimes.de: -- nosy: +christian.heimes ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21998 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1322] Deprecate platform.dist() and platform.linux_distribution() functions
Dimitri John Ledkov added the comment: Note that things have changed in this space, since the issue was opened in 2007. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1322 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21998] asyncio: support fork
Guido van Rossum added the comment: I was thinking only in the child. The parent should be able to continue to use the loop as if the fork didn't happen, right? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21998 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
