[issue12107] TCP listening sockets created without FD_CLOEXEC flag

Changes by STINNER Victor : -- versions: +Python 3.4 -Python 3.3 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue12107] TCP listening sockets created without FD_CLOEXEC flag

STINNER Victor added the comment: > There is a similar question (atomic or best effort) for the #16860 issue. It > looks like more people prefer the best effort option. Oops, it's the issue #16850: Add "e" mode to open(): close-and-exec (O_CLOEXEC) / O_NOINHERIT -- __

[issue12107] TCP listening sockets created without FD_CLOEXEC flag

STINNER Victor added the comment: Oh, I completly forgot the client socket for TCP servers: updated patch. The patch version 2 uses fcntl()+FD_CLOEXEC after accept(). It is not atomic, but I prefer to leave to problem to issue #10115: "can be fixed on systems that support it through accept4(),

[issue16891] Fix docs about module search order

Nick Coghlan added the comment: That said, the originally proposed docs change looks like a solid improvement to me. It's still a lie, but an appropriate one for the tutorial. -- ___ Python tracker __

[issue5066] IDLE documentation for Unix obsolete/incorrect

Todd Rovito added the comment: Thanks Senthil but I don't deserve all the credit this issue is a team effort with lots of help from Zach, Éric, and Ezio. All of which have improved the patch's quality a great deal. Hopefully we can address the issues then let you make the commit soon. -

[issue16814] use --directory option of make in describing how to build the docs

Chris Jerdonek added the comment: For the record, we do have tutorial-like documentation and document more than one way to do things in multiple places throughout the devguide. For example: http://docs.python.org/devguide/faq.html#how-do-i-list-the-files-in-conflict-after-a-merge Unlike the s

[issue14468] Update cloning guidelines in devguide

Ezio Melotti added the comment: I just noticed that the devguide already contains a section in the FAQ about Mercurial. Would it make sense to move/keep questions for committers only in the committing.rst page, and leave the generic question in faq.rst? -- ___

[issue5066] IDLE documentation for Unix obsolete/incorrect

Todd Rovito added the comment: I took all the comments and created a new patch version 4 which should address all the issues. Thanks for the excellent review and support from everybody. I think this patch is a much higher quality now. -- Added file: http://bugs.python.org/file28643/

[issue14468] Update cloning guidelines in devguide

Chris Jerdonek added the comment: Since this patch is on the longer side, would it be possible to use the "Remote hg repo" feature so Rietveld will work? I assume this is possible for devguide patches. Regarding the FAQ, it seems preferable to me to keep all questions in the FAQ, even if non

[issue14468] Update cloning guidelines in devguide

Ezio Melotti added the comment: > Since this patch is on the longer side, would it be possible to use > the "Remote hg repo" feature so Rietveld will work? I was actually thinking about doing this for the devguide and for the peps repos, using the "components" to determine what repo should be

[issue13899] re pattern r"[\A]" should work like "A" but matches nothing. Ditto B and Z.

Changes by Ezio Melotti : -- assignee: -> ezio.melotti stage: needs patch -> patch review ___ Python tracker ___ ___ Python-bugs-list

[issue16851] Hint about correct ismethod and isfunction usage

Changes by Ezio Melotti : -- assignee: docs@python -> ezio.melotti stage: needs patch -> patch review ___ Python tracker ___ ___ Pytho

[issue16896] Fix test discovery for test_asyncore.py

Changes by Ezio Melotti : -- assignee: -> ezio.melotti stage: -> patch review ___ Python tracker ___ ___ Python-bugs-list mailing li

[issue14468] Update cloning guidelines in devguide

Chris Jerdonek added the comment: > I'm not sure the remote hg repo supports non-cpython repos. Can you try? I would be surprised if it didn't. > What I was doing was converting the current prose in smaller FAQ-like sections Okay, then it sounds like they're more like sections that fit into t

[issue16897] Fix test discovery for test_bisect.py

Ezio Melotti added the comment: The best thing would be converting them to unittest (if there aren't already unittests for that). A general comment about these patches: I think it would be better to remove test_main() (and related unnecessary code) with unittest.main(). One of the advantage

[issue16898] Fix test discovery for test_bufio.py

Changes by Ezio Melotti : -- assignee: -> ezio.melotti stage: -> committed/rejected ___ Python tracker ___ ___ Python-bugs-list mail

[issue16814] use --directory option of make in describing how to build the docs

Ezio Melotti added the comment: > I frequently go back and forth between `make html` and `hg diff`. Mercurial commands work on the whole repo, regardless on the dir you are in (unlike SVN ones). That's why I usually just cd in Doc/ and do everything (opening files with editor/browser, make *,

[issue14468] Update cloning guidelines in devguide

Ezio Melotti added the comment: > Can you try? I would be surprised if it didn't. IIRC it does a diff between the head of the cpython repo and the head of the linked one. > Okay, then it sounds like they're more like sections that fit into > the natural flow of the main body of text. Yes, t

[issue16897] Fix test discovery for test_bisect.py

Zachary Ware added the comment: > A general comment about these patches: I think it would be better to remove test_main() (and related unnecessary code) with unittest.main(). One of the advantage of doing it now is that you can simply test discovery by doing ./python Lib/test/test_foo.py. > > Th

[issue16897] Fix test discovery for test_bisect.py

Ezio Melotti added the comment: I think that here all the test_main() can be removed except support.run_doctest(test_bisect, verbose). This should probably be moved after unittest.main() (unless the doctests are removed/converted to unittest). Refcounting is already provided by regrtest. --

[issue14468] Update cloning guidelines in devguide

Changes by Chris Jerdonek : -- hgrepos: +168 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python

[issue14468] Update cloning guidelines in devguide

Changes by Chris Jerdonek : -- hgrepos: -168 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pytho

[issue14468] Update cloning guidelines in devguide

Changes by Chris Jerdonek : -- hgrepos: +169 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python

[issue14468] Update cloning guidelines in devguide

Chris Jerdonek added the comment: Sorry, my apologies for the mess-ups! -- hgrepos: +170 ___ Python tracker ___ ___ Python-bugs-list m

[issue14468] Update cloning guidelines in devguide

Changes by Chris Jerdonek : -- hgrepos: -169 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pytho

[issue14468] Update cloning guidelines in devguide

Chris Jerdonek added the comment: Okay, it looks like you can't do it. It failed with a "repository is unrelated" error. -- ___ Python tracker ___ _

[issue16868] Python Developer Guide: Include a reminder to "ping" bug report if not reviewed in timely manner

Roundup Robot added the comment: New changeset 3f2637a6fbfa by Ezio Melotti in branch 'default': #16868: mention that you can "ping" issues before writing to python-dev. http://hg.python.org/devguide/rev/3f2637a6fbfa -- nosy: +python-dev ___ Python tr

[issue16868] Python Developer Guide: Include a reminder to "ping" bug report if not reviewed in timely manner

Ezio Melotti added the comment: Fixed with a slightly different wording (thanks Chris for the suggestion). Thanks Todd for the report and the initial patch! -- assignee: docs@python -> ezio.melotti resolution: -> fixed stage: commit review -> committed/rejected status: open -> closed ty

[issue16891] Fix docs about module search order

Dmitry Mugtasimov added the comment: Further investigation led me to the conclusion that "TO BE" should look like this: 6.1.2. The Module Search Path When a module named spam is imported, the interpreter first searches in the containing package (the package of which the current module is a su

<    1   2