[issue24536] os.pipe() should return a structsequence (or namedtuple.)

Ethan Furman added the comment: Okay, scratch the "not file descriptors" part of my comment, but the rest still stands. -- ___ Python tracker ___ ___

[issue24536] os.pipe() should return a structsequence (or namedtuple.)

Ethan Furman added the comment: Nowhere else in the stdlib is 'readfd' defined, and 'writefd' is only used once in a test. I think tacking on the 'fd' is both too low level as well as misleading since these are not file descriptors. If there is no agreement on read/write (understandable since

[issue23630] support multiple hosts in create_server/start_server

STINNER Victor added the comment: I reviewed multibind.patch. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue23883] __all__ lists are incomplete

Martin Panter added the comment: The technical bit of Issue23883_support_check__all__.v3.patch looks pretty good. Mainly some grammar suggestions for the documentation. Issue23883_test_gettext.v2.patch looks fine; just depends on check__all__() being added. Couple of comments about the APIs f

[issue24400] Awaitable ABC incompatible with functools.singledispatch

Changes by Yury Selivanov : -- status: open -> closed ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://m

[issue24536] os.pipe() should return a structsequence (or namedtuple.)

Yury Selivanov added the comment: Here's a patch, please review. -- keywords: +patch stage: -> patch review Added file: http://bugs.python.org/file39839/ospipe.patch ___ Python tracker

[issue24487] Change asyncio.async() → ensure_future()

Changes by Yury Selivanov : -- status: open -> closed ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://m

[issue24542] ssl - SSL_OP_NO_TICKET not reimplemented

New submission from Samuel Hoffman: Realizing the _ssl module does not import very many constants, I think it might be worth while to reimplement and document SSL_OP_NO_TICKET (0x4000) as it's another one of the "enable this for improved security at a cost" options like SSL_OP_SINGLE_DH_US

[issue24487] Change asyncio.async() → ensure_future()

Yury Selivanov added the comment: Thanks, Martin! -- resolution: out of date -> fixed ___ Python tracker ___ ___ Python-bugs-list mail

[issue24487] Change asyncio.async() → ensure_future()

Roundup Robot added the comment: New changeset 1b3be273e327 by Yury Selivanov in branch '3.5': Issue #24487: Rename async() -> ensure_future() in asyncio docs. https://hg.python.org/cpython/rev/1b3be273e327 New changeset 3dc2a113e8a7 by Yury Selivanov in branch 'default': Merge 3.5 (Issue #24487

[issue24541] test_eightteen() in test_inspect out of sync with documentation

Roundup Robot added the comment: New changeset bd45435fd081 by Yury Selivanov in branch '3.5': Issue #24541: Drop test_inspect.test_eightteen unittest; update docs https://hg.python.org/cpython/rev/bd45435fd081 -- ___ Python tracker

[issue24541] test_eightteen() in test_inspect out of sync with documentation

Yury Selivanov added the comment: Thanks for pushing this Martin. I didn't notice that you suggested to update inspect.rst as well. And it does make sense to just remove the number of is* functions from the docs (and after that we don't need the unittest). -- _

[issue24487] Change asyncio.async() → ensure_future()

Martin Panter added the comment: Reopening. The patch still applies to the current code (e.g. revision df310e5ac015, 30 June). It changes eight references of “async()” that still exist in this revision. -- status: closed -> open ___ Python tracker

[issue24541] test_eightteen() in test_inspect out of sync with documentation

Martin Panter added the comment: Okay but what about the documentation? It still claims sixteen. # This test is here for remember you to update Doc/library/inspect.rst -- ___ Python tracker ___

[issue24541] test_eightteen() in test_inspect out of sync with documentation

Yury Selivanov added the comment: This has already been fix (see issue24400). I've also updated the comment (16 -> 18). Let's keep the test as is. -- nosy: +yselivanov resolution: -> fixed stage: -> resolved status: open -> closed ___ Python trac

[issue24541] test_eightteen() in test_inspect out of sync with documentation

Roundup Robot added the comment: New changeset a5c6eaa7d733 by Yury Selivanov in branch '3.5': Issue #24541: Update comment in test_inspect.test_eightteen https://hg.python.org/cpython/rev/a5c6eaa7d733 -- nosy: +python-dev ___ Python tracker

[issue24400] Awaitable ABC incompatible with functools.singledispatch

Martin Panter added the comment: Opened Issue 24541 related to this latest change. The test and documentation are still inconsistent, even if the test passes. -- ___ Python tracker

[issue24541] test_eightteen() in test_inspect out of sync with documentation

New submission from Martin Panter: Revision 0b7c313851ca highlights an inconsistency in the test case at the top of the TestPredicates class. After removing isawaitable() in Issue 24400, there are now actually eighteen is* functions. The comment in the test case still says there are sixteen (f

[issue24536] os.pipe() should return a structsequence (or namedtuple.)

Yury Selivanov added the comment: +1 for readfd/writefd. I think 'fd' suffix is necessary to make it explicit that those aren't file objects. -- nosy: +yselivanov ___ Python tracker __

[issue24400] Awaitable ABC incompatible with functools.singledispatch

Yury Selivanov added the comment: > Look like you forgot to adjust test_inspect for the removal. eg: My bad. Thanks, David! -- ___ Python tracker ___ ___

[issue24400] Awaitable ABC incompatible with functools.singledispatch

Roundup Robot added the comment: New changeset 0b7c313851ca by Yury Selivanov in branch '3.5': Issue #24400: Fix failing unittest https://hg.python.org/cpython/rev/0b7c313851ca New changeset 8c85291e86bf by Yury Selivanov in branch 'default': Merge 3.5 (Issue #24400) https://hg.python.org/cpytho

[issue24400] Awaitable ABC incompatible with functools.singledispatch

R. David Murray added the comment: Look like you forgot to adjust test_inspect for the removal. eg: http://buildbot.python.org/all/builders/AMD64%20Windows8.1%20Non-Debug%203.x/builds/54 -- nosy: +r.david.murray status: closed -> open ___ Python trac

[issue24132] Direct sub-classing of pathlib.Path

Kevin Norris added the comment: If I were designing pathlib from scratch, I would not have a separate Path class. I would instead do something like this: In pathlib.py: if os.name == 'nt': Path = WindowsPath else: Path = PosixPath Alternatively, Path() could be a fact

[issue24535] SELinux reporting writes, executes, and dac_overwrites

Nick Levinson added the comment: Thank you. I didn't know enough to understand the relevance of blueman. -- ___ Python tracker ___ ___

Re: [issue24534] disable executing code in .pth files

On 01.07.2015 00:16, Min RK wrote: > >> Just because a feature can be misused doesn't make it a bad feature. > > That's fair. I'm just not aware of any uses of this feature that aren't > misuses, hence the patch. I don't remember the details of why this feature was added, but can imagine that i

[issue24400] Awaitable ABC incompatible with functools.singledispatch

Roundup Robot added the comment: New changeset e20c197f19d6 by Yury Selivanov in branch '3.5': Issue #24400: Remove inspect.isawaitable(). https://hg.python.org/cpython/rev/e20c197f19d6 New changeset 800bf6a0e0d5 by Yury Selivanov in branch 'default': Merge 3.5 (Issue #24400) https://hg.python.o

[issue24534] disable executing code in .pth files

Min RK added the comment: > Just because a feature can be misused doesn't make it a bad feature. That's fair. I'm just not aware of any uses of this feature that aren't misuses, hence the patch. > Perhaps you could submit a fix for this to the setuptools maintainers instead. Yes, that's defin

[issue24400] Awaitable ABC incompatible with functools.singledispatch

Ben Darnell added the comment: Yes, I can switch use the ABC instead, and I agree that it doesn't make sense to have the inspect method if it's going to be equivalent to the ABC. I'm happy with the outcome here but AFAIK the original issue still stands: the Awaitable ABC is unusual in that `is

[issue24400] Awaitable ABC incompatible with functools.singledispatch

Yury Selivanov added the comment: > > isawaitable(), however, should continue using abc.Awaitable, since it only > > checks for __await__ presence on the type (or should we just drop it?) > I'd really remove it. It's not referring to an actual type, so it doesn't fit > the purpose of the inspe

[issue24534] disable executing code in .pth files

Marc-Andre Lemburg added the comment: On 30.06.2015 22:49, Min RK wrote: > >> Could you please post an example of where the feature is problematic ? > > setuptools/easy_install is the major one, which effectively does > `sys.path[:0] = pth_contents`, breaking import priority. This has been kno

[issue24534] disable executing code in .pth files

Min RK added the comment: > Could you please post an example of where the feature is problematic ? setuptools/easy_install is the major one, which effectively does `sys.path[:0] = pth_contents`, breaking import priority. This has been known to result in adding `/usr/lib/pythonX.Y/dist-packages

[issue24534] disable executing code in .pth files

Marc-Andre Lemburg added the comment: On 30.06.2015 20:52, Min RK wrote: > > Thanks for the feedback, I thought it might be a long shot. I will go back to > removing the *use* of the feature everywhere I can find it, since it is so > problematic and rarely, if ever, desirable. Could you pleas

[issue24540] Documentation about skipkeys parameter for json.dumps is incorrect

New submission from Matthew Havard: The documentation from json.dumps says this about skipkeys: If ``skipkeys`` is false then ``dict`` keys that are not basic types (``str``, ``int``, ``float``, ``bool``, ``None``) will be skipped instead of raising a ``TypeError``. However, that co

[issue24534] disable executing code in .pth files

Min RK added the comment: Thanks for the feedback, I thought it might be a long shot. I will go back to removing the *use* of the feature everywhere I can find it, since it is so problematic and rarely, if ever, desirable. > it's an essential feature that has been documented for a very long ti

[issue24528] Misleading exeption for await in comprehensions.

Changes by Yury Selivanov : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___ ___

[issue24528] Misleading exeption for await in comprehensions.

Roundup Robot added the comment: New changeset 30b676e8b21f by Yury Selivanov in branch '3.5': Issue #24528: Improve error message for awaits in comprehensions https://hg.python.org/cpython/rev/30b676e8b21f New changeset 9598bc916186 by Yury Selivanov in branch 'default': Merge 3.5 (Issue #24528

[issue24294] DeprecationWarnings should be visible by default in the interactive REPL

Matthias Bussonnier added the comment: Note that I've signed the CLA, and it has been taken into account, as now I have a small star agains my name (if it was the limiting factor, we never know). -- ___ Python tracker

[issue23496] Steps for Android Native Build of Python 3.4.2

Cyd Haselton added the comment: On June 30, 2015 9:20:45 AM CDT, Ryan Gonzalez wrote: > >Ryan Gonzalez added the comment: > >On June 30, 2015 8:14:34 AM CDT, Cyd Haselton >wrote: >> >>Cyd Haselton added the comment: >> >>Your question about -fPIE brings up a question: How should the >>differenc

[issue24536] os.pipe() should return a structsequence (or namedtuple.)

Jonathan Slenders added the comment: Niki Spahiev made a valid argument saying that the following code is common: if not hasattr(src, 'read'): src = open(src) This will break if we name it 'read'/'write' like the methods of a file object. -- ___ Py

[issue24536] os.pipe() should return a structsequence (or namedtuple.)

Ethan Furman added the comment: 'read'/'write' is sufficient. +1 for the proposal. -- nosy: +ethan.furman ___ Python tracker ___ ___

[issue23496] Steps for Android Native Build of Python 3.4.2

Ryan Gonzalez added the comment: On June 30, 2015 8:14:34 AM CDT, Cyd Haselton wrote: > >Cyd Haselton added the comment: > >Your question about -fPIE brings up a question: How should the >differences between Android 5 and previous versions be handled in >regards to this issue? > >Other than mand

[issue24538] os.setxattr PermissionError on panfs propagates up causing `copystat`, `copytree`, and `pip install .` to fail unhepfully

Gerrit Holl added the comment: Perhaps the solution would be some kind of flag, at least for copytree and possibly others, on what to do when attributes cannot be completely copied — a bit like numpys options to raise, warn, or ignore? -- ___ Python

[issue23496] Steps for Android Native Build of Python 3.4.2

Cyd Haselton added the comment: Your question about -fPIE brings up a question: How should the differences between Android 5 and previous versions be handled in regards to this issue? Other than mandatory -fPIE, there are changes to Android[s libc that may make patches for python on Android 4

[issue24538] os.setxattr PermissionError on panfs propagates up causing `copystat`, `copytree`, and `pip install .` to fail unhepfully

R. David Murray added the comment: There are a couple of related open issues. I think there is an stdlib problem here, but I"m not sure what the solution is. -- nosy: +r.david.murray ___ Python tracker __

[issue24539] StreamReaderProtocol.eof_received() should return True to keep the transport open

New submission from Guido van Rossum: See https://github.com/python/asyncio/issues/251. I'm on vacation and may or may not find the time to actually fix this (it needs a unittest written). -- components: asyncio messages: 245986 nosy: gvanrossum, haypo, yselivanov priority: normal sever

[issue24538] os.setxattr PermissionError on panfs propagates up causing `copystat`, `copytree`, and `pip install .` to fail unhepfully

New submission from Gerrit Holl: `shutil.copystat` fails on [panfs](https://en.wikipedia.org/wiki/Panasas#PanFS) if the source file lacks u+w, because setting extended attributes results in a `PermissionError`. This leads to higher end functions such as `shutil.copytree` to fail. More seriou

[issue24538] os.setxattr PermissionError on panfs propagates up causing `copystat`, `copytree`, and `pip install .` to fail unhepfully

Changes by Gerrit Holl : -- type: -> crash ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python

[issue24520] Stop using deprecated floating-point environment functions on FreeBSD

Changes by Ed Maste : -- nosy: +emaste ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/

[issue24520] Stop using deprecated floating-point environment functions on FreeBSD

Changes by koobs : -- keywords: +needs review nosy: +koobs ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http

[issue24537] Py_Initialize unable to load the file system codec

New submission from Dana Christen: I'm using the C API to embed the Python interpreter (see the attached example). Everything works fine until I try to run the resulting executable on a machine without a Python installation. In that case, the call to Py_Initialize fails with the following mess

[issue24534] disable executing code in .pth files

Changes by Christian Heimes : -- nosy: +christian.heimes ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https:

[issue24534] disable executing code in .pth files

Nick Coghlan added the comment: As others have noted, we're not going to change this default in the standard CPython executable (due to the degree of disruption involved), and the -S and -I switches already effectively turn it off (by disabling site module processing entirely) However, it cou

[issue24536] os.pipe() should return a structsequence (or namedtuple.)

Chris Angelico added the comment: Another good option is read/write without the 'fd' suffix. Either works, I'd prefer the shorter one but by a small margin. -- nosy: +Rosuav ___ Python tracker

[issue24536] os.pipe() should return a structsequence (or namedtuple.)

New submission from Jonathan Slenders: As discussed on python-ideas, os.pipe should return a structsequence instead of a plain tuple. To be decided is the naming for the read and write end. Personally, I'm in favour of using readfd/writefd. > our_pipe = pipe() > os.write(our_pipe.writefd, b'da