[issue24062] links to os.stat() in documentation lead to stat module instead

Roundup Robot added the comment: New changeset 5850f0c17c34 by Berker Peksag in branch '3.4': Issue #24062: Fix os.stat links. Patch by July Tikhonov. https://hg.python.org/cpython/rev/5850f0c17c34 New changeset 18882c93f4bd by Berker Peksag in branch 'default': Issue #24062: Fix os.stat links.

[issue24062] links to os.stat() in documentation lead to stat module instead

Berker Peksag added the comment: Thanks for the patch, July. -- nosy: +berker.peksag resolution: - fixed stage: - resolved status: open - closed versions: -Python 3.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24062

[issue16669] Docstrings for namedtuple

Peter Otten added the comment: Here's a variant that builds on your code, but makes for a nicer API. Single-line docstrings can be passed along with the attribute name, and with namedtuple.with_docstrings(... all info required to build the class ...) from a user perspective the factory looks

[issue24064] Make the property doctstring writeable

Berker Peksag added the comment: Here is a patch. I'm not familiar with this part of the CPython source. So please tell me if there is a better way to do it. I only updated Doc/whatsnew/3.5, but other places in the documentation needs to be updated. -- keywords: +patch nosy:

[issue24040] plistlib assumes dict_type is descendent of dict

Ronald Oussoren added the comment: To react to myself: checking for self.dict_type might break users that pass in a callable: x = plistlib.load(fp, dict_type=lambda:{}) As Behdad memtioned testing that the type isn't list would be better: if not isinstance(..., list): That attached

[issue20210] Provide configure options to enable/disable Python modules and extensions

Krasimir added the comment: @Thomas: Thank you for the patches! Adding more flexibility to the build system that allows for cross-compiling and building embeddable/distributable python is definitely something that needs to be done is my opinion. So I definitely find your work very valuable to

[issue24066] send_message should take all the addresses in the To: header into account

New submission from Kirill Elagin: If I have a message with multiple `To` headers and I send it using `send_message` not specifying `to_addrs`, the message gets sent only to one of the recipients. I’m attaching my patch that makes it send to _all_ the addresses listed in `To`, `Cc` and

[issue24053] Define EXIT_SUCCESS and EXIT_FAILURE constants in sys

Alexander Belopolsky added the comment: will confuse inexperienced users when they unexpectedly encounter with sys.exit(sys.EXIT_FAILURE) instead of sys.exit(1). Are you serious? I've seen senior programmers who thought that status 0 means failure and status = 0 means success. Why would

[issue23749] asyncio missing wrap_socket

Antoine Pitrou added the comment: So you need to: - have an API to wrap a clear-text protocol in a SSL protocol (see e.g. BaseProactorEventLoop._make_ssl_transport()... note how there's a waiter argument, what should be done with that?) - be able to replace a protocol with another on the

[issue11205] Evaluation order of dictionary display is different from reference manual.

Steve Dougherty added the comment: I've added a patch to change the order of evaluation and of STORE_MAP's arguments. It includes a test incorporating the review on the previous version. I noticed I had to remove existing .pyc files to avoid TypeErrors about values being unhashable. I take it

[issue24067] Weakproxy is an instance of collections.Iterator

New submission from Eyal Reuveni: Calling weakref.proxy() on an object returns something that is an instance of collections.Iterator, regardless of whether the object is an instance of collections.Iterator or even if the object itself is iterable. To reproduce, run the following code

[issue24017] Implemenation of the PEP 492 - Coroutines with async and await syntax

Changes by Guido van Rossum gu...@python.org: -- nosy: +gvanrossum ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24017 ___ ___ Python-bugs-list

[issue24053] Define EXIT_SUCCESS and EXIT_FAILURE constants in sys

Alexander Belopolsky added the comment: if you use them, your code won't work with long time supported CPython versions like 3.4 for the next decade or so. This would be a generic argument against any new feature. I don't think it is very compelling in this case. For people who develop on

[issue24018] add a Generator ABC

Raymond Hettinger added the comment: The latest patch looks good overall. Łukasz, assigning back to you. -- assignee: rhettinger - lukasz.langa ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24018

[issue23955] Add python.ini file for embedded/applocal installs

Steve Dower added the comment: Having looked at the implementation, the easiest way to do this will be to add an applocal = true option to pyvenv.cfg, which would behave identically to setting %PYTHONHOME% to the directory containing the config before launch. I wanted to support relative

[issue9858] Python and C implementations of io are out of sync

Laura Rupprecht added the comment: There were originally three methods present in RawIOBase that were not present in PyRawIOBase_Type: 1. readinto 2. write 3. __weakref__ I've created a patch that adds the first two to PyRawIOBase_Type. The python class readinto and write methods raise

[issue24018] add a Generator ABC

Stefan Behnel added the comment: Please either 1) drop the throw() method entirely or 2) make throw an abstractmethod() Ok, as I already said, I think it's important to provide the complete protocol as code will usually expect that. Also, close() has a helpful implementation, but it

[issue22057] The doc say all globals are copied on eval(), but only __builtins__ is copied

Raymond Hettinger added the comment: The patch looks good (though it would have been easier to check the diff if the text had not be reflowed). I will apply it when I get a chance. Or if anyone else wants to grab it, go ahead. -- ___ Python

[issue23910] C implementation of namedtuple (WIP)

Raymond Hettinger added the comment: Hmm, the presense of _PyTuple_DebugMallocStats, repeat_traverse, and visit_decref suggests that the profile may have been run with debugging code enabled and GC enabled. The property patch looks good. Depending on how far you want to go with this, you

[issue22408] Tkinter doesn't handle Unicode dead key combinations on Windows

Changes by irdb dalba.w...@gmail.com: -- nosy: +irdb ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22408 ___ ___ Python-bugs-list mailing list

[issue23975] numbers.Rational implements __float__ incorrectly

Wolfgang Maier added the comment: After considering this for a while, I think: return float(self.numerator / self.denominator) is the best solution: * it is simple and works reasonably well as a default * it fixes Rational.__float__ for cases, in which numerator / denominator returns a

[issue23910] C implementation of namedtuple (WIP)

Joe Jevnik added the comment: I switched to the static tuple. -- Added file: http://bugs.python.org/file39216/with-static-tuple.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23910 ___

[issue8027] distutils fail to determine c++ linker with unixcompiler if using ccache

Ronald Oussoren added the comment: I don't recall exactly why the universal build support is done the way it is, adding it is too long ago. The reason is likely no longer relevant with any reasonably up-to-date toolset. The patch was created around the time x86 support was added to OSX and

[issue23910] C implementation of namedtuple (WIP)

Joe Jevnik added the comment: I don't think that I can cache the __call__ of the fget object because it might be an instance of a heaptype, and if someone changed the __class__ of the object in between calls to another heaptype that had a different __call__, you would still get the __call__

[issue22906] PEP 479: Change StopIteration handling inside generators

Chris Angelico added the comment: Had a peek at the 2.7 branch in the web (https://hg.python.org/cpython/file/4234b0dd2a54/Lib/test) and all the tests appear to be testing the behaviour *with* the future directive, not bothering to test the old behaviour. It makes sense - that way, when the

[issue16669] Docstrings for namedtuple

Changes by Raymond Hettinger raymond.hettin...@gmail.com: -- Removed message: http://bugs.python.org/msg242118 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16669 ___

[issue21354] PyCFunction_New no longer exposed by python DLL breaking bdist_wininst installers

Andrew Svetlov added the comment: Fixed. Sorry for long delay. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21354 ___ ___ Python-bugs-list

[issue21354] PyCFunction_New no longer exposed by python DLL breaking bdist_wininst installers

Changes by Andrew Svetlov andrew.svet...@gmail.com: -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21354 ___

[issue16669] Docstrings for namedtuple

Raymond Hettinger added the comment: Ideally, I prefer to stick with either a separate customization step or with the original __new__ constructor, and that uses **kwds so we can use a standard syntax for the name value pairs and to allow that possibility of someone passing in an existing

[issue15064] Use context manager protocol for more multiprocessing types

Dan O'Reilly added the comment: It's probably too late to do anything about this now, but wouldn't it make more sense for `Pool.__exit__` to call `close`, rather than `terminate`? The vast majority of the time, that's probably what the user of the `Pool` would want to run. It also would make

[issue16669] Docstrings for namedtuple

Changes by Raymond Hettinger raymond.hettin...@gmail.com: -- Removed message: http://bugs.python.org/msg242119 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16669 ___

[issue21354] PyCFunction_New no longer exposed by python DLL breaking bdist_wininst installers

Roundup Robot added the comment: New changeset 69951573cb0e by Andrew Svetlov in branch '3.4': Issue #21354: PyCFunction_New function is exposed by python DLL again. https://hg.python.org/cpython/rev/69951573cb0e -- nosy: +python-dev ___ Python

[issue16669] Docstrings for namedtuple

Raymond Hettinger added the comment: Sorry Peter, I don't like that variant and want to stick with a separate customization step that uses **kwds so we can use normal syntax for the name value pairs and to allow that possibility of someone passing in an existing dict using

[issue16669] Docstrings for namedtuple

Raymond Hettinger added the comment: The need for this may be eliminated by issue 24064. Then we change the docstrings just like any other object with no special rules or methods. -- ___ Python tracker rep...@bugs.python.org

[issue23911] Move path-based bootstrap code to a separate frozen file.

Eric Snow added the comment: Glad to hear the patch is conceptually consistent with other components. :) And the internal/external suggestion is a good one. I'll update the patch when I have a minute. -- ___ Python tracker rep...@bugs.python.org

[issue11205] Evaluation order of dictionary display is different from reference manual.

Nick Coghlan added the comment: The pyc issue suggests the magic number embedded in pyc files to indicate bytecode compatibility needs to be incremented. If I recall correctly, that lives in Lib/importlib/_bootstrap.py these days. -- ___ Python

[issue17908] Unittest runner needs an option to call gc.collect() after each test

Adam added the comment: Is this enhancement still open? I've run into this problem previously, and would be more than happy to implement this feature. -- nosy: +azsorkin ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17908

[issue15064] Use context manager protocol for more multiprocessing types

Ned Deily added the comment: Dan, this issue was closed and the code associated with it released a few years ago. Comments here will likely be ignored. If you want to pursue your suggestion, please open a new issue for it. -- nosy: +ned.deily ___

[issue9782] _multiprocessing.c warnings under 64-bit Windows

Changes by Davin Potts pyt...@discontinuity.net: -- nosy: +davin ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9782 ___ ___ Python-bugs-list

[issue24066] send_message should take all the addresses in the To: header into account

Ned Deily added the comment: Kirill, the patch is missing. -- nosy: +ned.deily ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24066 ___ ___

[issue21345] multiprocessing.Pool._handle_workers sleeps too long

Changes by Davin Potts pyt...@discontinuity.net: -- nosy: +davin ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21345 ___ ___ Python-bugs-list

[issue24067] Weakproxy is an instance of collections.Iterator

Changes by Ned Deily n...@acm.org: -- nosy: +fdrake, pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24067 ___ ___ Python-bugs-list mailing

[issue16620] Avoid using private function glob.glob1() in msi module and tools

Changes by Mark Lawrence breamore...@yahoo.co.uk: -- nosy: +steve.dower ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16620 ___ ___

[issue23614] Opaque error message on UTF-8 decoding to surrogates

Chris Angelico added the comment: Got around to tracking down where this is actually being done. It's in Objects/stringlib/codecs.h and it looks to be a hot area for optimization. I don't want to fiddle with it without knowing a lot about the performance implications (UTF-8 encode/decode

[issue17908] Unittest runner needs an option to call gc.collect() after each test

Changes by Ned Deily n...@acm.org: -- nosy: +rbcollins ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17908 ___ ___ Python-bugs-list mailing list

[issue19543] Add -3 warnings for codec convenience method changes

Serhiy Storchaka added the comment: I think we should just backport issue19619 and issue20404. -- nosy: +serhiy.storchaka ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19543 ___

[issue22544] Inconsistent cmath.log behaviour

Changes by STINNER Victor victor.stin...@gmail.com: -- nosy: -haypo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22544 ___ ___ Python-bugs-list

[issue23910] C implementation of namedtuple (WIP)

Raymond Hettinger added the comment: What kind of speed improvement have you gotten? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23910 ___

[issue23910] C implementation of namedtuple (WIP)

Joe Jevnik added the comment: I am currently on a different machine so these numbers are not relative to the others posted earlier. * default ./python -m timeit -s from collections import namedtuple as n;a = n('n', 'a b c')(1, 2, 3) a.a 1000 loops, best of 3: 0.0699 usec per loop * patch

[issue21354] PyCFunction_New no longer exposed by python DLL breaking bdist_wininst installers

Changes by Berker Peksag berker.pek...@gmail.com: -- stage: needs patch - resolved ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21354 ___ ___

[issue24053] Define EXIT_SUCCESS and EXIT_FAILURE constants in sys

Antoine Pitrou added the comment: We already have over a dozen BSDish exit codes in os that are hardly ever used. Then precisely, those new codes should go in the os module as well. -- ___ Python tracker rep...@bugs.python.org

[issue24053] Define EXIT_SUCCESS and EXIT_FAILURE constants in sys

Alexander Belopolsky added the comment: Those should be in the os module, not in sys. I disagree. The whole point of this proposal is to have platform-independent status codes available next to the sys.exit() function. We already have over a dozen BSDish exit codes in os that are hardly

[issue23955] Add python.ini file for embedded/applocal installs

Thomas Kluyver added the comment: Would that option be the only thing that needs to be set to make Python app-local? I'm not familiar with what lives in pyvenv.cfg. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23955

[issue23955] Add python.ini file for embedded/applocal installs

Steve Dower added the comment: None of the other options really have much use in this case, since they're mostly about how to combine multiple environments rather than excluding implicit ones. Setting PYTHONHOME to the current directory certainly seems to be enough AFAICT, at least for

[issue21791] Proper return status of os.WNOHANG is not always (0, 0)

Davin Potts added the comment: The man pages for waitpid on OpenBSD 5.x do not suggest any meaningful value will be returned in status when WNOHANG is requested and no child processes have anything to report. The following session attempts to exercise os.waitpid using Python 2.7.9 on an

[issue24053] Define EXIT_SUCCESS and EXIT_FAILURE constants in sys

Ethan Furman added the comment: I agree with Antoine -- all the exit codes should be in one place. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24053 ___

[issue24053] Define EXIT_SUCCESS and EXIT_FAILURE constants in sys

Antoine Pitrou added the comment: Well, my favourite answer would be use sys.exit(0) and sys.exit(1), respectively (or raise SystemExit without or with an error message), as everyone is already doing right now. Since I don't really get the usability argument of adding those constants, it's

[issue24053] Define EXIT_SUCCESS and EXIT_FAILURE constants in sys

Alexander Belopolsky added the comment: Ethan all the exit codes should be in one place. Do you realize that os.EX_* codes are not available on Windows? Having platform-independent EXIT_* codes next to posix-only EX_* codes will send the wrong message about their availability. --

[issue23749] asyncio missing wrap_socket

Guido van Rossum added the comment: We didn't do this originally because the 3.4 SSL module didn't have this functionality (or maybe it was 3.3 that didn't have this) but now that we do have it I'd be very happy if you could implement this! I'm not sure what the right interface is, probably

[issue24065] Outdated *_RESTRICTED flags in structmember.h

Antoine Pitrou added the comment: +1 for deprecating them. -- nosy: +pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24065 ___ ___

[issue24065] Outdated *_RESTRICTED flags in structmember.h

New submission from Berker Peksag: Looks like READ_RESTRICTED, PY_WRITE_RESTRICTED and RESTRICTED flags were used for restricted mode [1] in Python 2. restricted mode has been deprecated in Python 2.3. Also, the current documentation is outdated. WRITE_RESTRICTED is now PY_WRITE_RESTRICTED:

[issue24053] Define EXIT_SUCCESS and EXIT_FAILURE constants in sys

Alexander Belopolsky added the comment: Antoine Since I don't really get the usability argument of adding those constants .. If I am alone in finding exit(EXIT_FAILURE) clearer than exit(1), I should certainly drop my proposal. -- ___ Python

[issue24053] Define EXIT_SUCCESS and EXIT_FAILURE constants in sys

Antoine Pitrou added the comment: Well it would be clearer if not for the widely established knowledge (amongst most or all programming languages) that zero means success and non-zero means failure. So in this case I find it personally useless. --

[issue24053] Define EXIT_SUCCESS and EXIT_FAILURE constants in sys

Stefan Krah added the comment: I'm +0 on adding these. The only reason is that I've seen academic code written by well-known researchers that used 1 for a successful exit. :) I'm not sure about the os module. These are C99 and not OS specific. --

[issue24037] Argument Clinic: add the boolint converter

Tal Einat added the comment: If I was writing a function/method with a conceptually boolean parameter (True/False), I wouldn't want that to accept any Python object. For example, I would want passing a tuple or list to raise a TypeError. But according to the docs[1], that's what the 'p'

[issue24053] Define EXIT_SUCCESS and EXIT_FAILURE constants in sys

Alexander Belopolsky added the comment: Then precisely, those new codes should go in the os module as well. What is your logic? Having os.EX_ codes in os does not help as far as sys.exit() is concerned: no-one is using them and they are not available on all platforms. If we add

[issue24053] Define EXIT_SUCCESS and EXIT_FAILURE constants in sys

Alexander Belopolsky added the comment: This can be implemented as separate module on PyPI. Sure! Make them even less discoverable! Let me try to state my motivations for adding these constants: 1. I find exit(EXIT_FAILURE) much clearer than exit(1). 2. I want people to standardize on

[issue24053] Define EXIT_SUCCESS and EXIT_FAILURE constants in sys

Ethan Furman added the comment: An entire PyPI module for two constants? Change of heart, I'm okay with them going in sys, but only +0 on adding them. This SO answer* has an interesting point to make about the nature of return codes and what their values should be; tl;dr - the convention

[issue24053] Define EXIT_SUCCESS and EXIT_FAILURE constants in sys

Alexander Belopolsky added the comment: the convention should be between your program and the other program(s) you are trying communicate with. This may be true in general, but Python stdlib sets the convention in its subprocess.check_call and subprocess.check_output methods. These methods

[issue24053] Define EXIT_SUCCESS and EXIT_FAILURE constants in sys

Antoine Pitrou added the comment: I want people to standardize on status=1 for a generic failure code. Why that? Multiple error codes can be used by the same program, depending on the kind of error. I want discourage people from using computed integer results as exit status. Ok, that's the

[issue17908] Unittest runner needs an option to call gc.collect() after each test

Guido van Rossum added the comment: Does the cpython test runner have this? Might be nice there. Not sure if the default test runner is something to extend at this point. Eveybody is using py.test anyway... On Monday, April 27, 2015, Ned Deily rep...@bugs.python.org wrote: Changes by Ned

[issue24053] Define EXIT_SUCCESS and EXIT_FAILURE constants in sys

Alexander Belopolsky added the comment: Stefan I've seen academic code written by well-known researchers Stefan that used 1 for a successful exit. Thank you! What I've seen more than once was exit(True) to indicate success where True is not necessarily a literal, but something like

[issue24053] Define EXIT_SUCCESS and EXIT_FAILURE constants in sys

Serhiy Storchaka added the comment: This can be implemented as separate module on PyPI. No need to add these aliases for 0 and 1 to the stdlib. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24053

[issue24064] Make the property doctstring writeable

Changes by Ethan Furman et...@stoneleaf.us: -- nosy: +ethan.furman ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24064 ___ ___ Python-bugs-list

[issue24053] Define EXIT_SUCCESS and EXIT_FAILURE constants in sys

Berker Peksag added the comment: 1. I find exit(EXIT_FAILURE) much clearer than exit(1). import sys exit(sys.EXIT_FAILURE) or import sys sys.exit(sys.EXIT_FAILURE) don't look too clear to me. On the other hand, these constants may helpful to people who came from C world.

[issue24053] Define EXIT_SUCCESS and EXIT_FAILURE constants in sys

Stefan Behnel added the comment: why not spell them sys.exit.FAILURE and sys.exit.SUCCESS ? -- nosy: +scoder ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24053 ___

[issue24053] Define EXIT_SUCCESS and EXIT_FAILURE constants in sys

Alexander Belopolsky added the comment: I want people to standardize on status=1 for a generic failure code. Why that? Multiple error codes can be used by the same program, depending on the kind of error. Antoine, please read what I write carefully before disagreeing. I want to

[issue24053] Define EXIT_SUCCESS and EXIT_FAILURE constants in sys

Serhiy Storchaka added the comment: How often you see EXIT_SUCCESS and EXIT_FAILURE in C code besides GNU tools that should support VMS? And even GNU tools usually use multiple error codes for different kinds of errors. I think that these constants are rather unusual for C programmers. I'm

[issue24053] Define EXIT_SUCCESS and EXIT_FAILURE constants in sys

Alexander Belopolsky added the comment: And even GNU tools usually use multiple error codes for different kinds of errors. And how often do they not give them symbolic names? -- ___ Python tracker rep...@bugs.python.org

[issue24053] Define EXIT_SUCCESS and EXIT_FAILURE constants in sys

Stefan Behnel added the comment: Actually, my guess is also that these constants will not be used. Not because they are not helpful, but because they'd only be available in Python 3.5+. Meaning that if you use them, your code won't work with long time supported CPython versions like 3.4 for