[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 co

[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 ___ __

[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 tracke

[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 l

[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: +berker.pe

[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 __

[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 pa

[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 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 ___ _

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

Changes by irdb : -- nosy: +irdb ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailma

[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 custo

[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__ fr

[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 fu

[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 tracke

[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 ___ ___ Python-bugs-list mailing list Unsubscribe

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

Changes by Andrew Svetlov : -- resolution: -> fixed status: open -> closed ___ Python tracker ___ ___ Python-bugs-list mailing list U

[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 NT.set_docstrings(**

[issue16669] Docstrings for namedtuple

Changes by Raymond Hettinger : -- Removed message: http://bugs.python.org/msg242118 ___ Python tracker ___ ___ Python-bugs-list mailin

[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 dict

[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 t

[issue16669] Docstrings for namedtuple

Changes by Raymond Hettinger : -- Removed message: http://bugs.python.org/msg242119 ___ Python tracker ___ ___ Python-bugs-list mailin

[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 __

[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 ___ _

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

Changes by Berker Peksag : -- stage: needs patch -> resolved ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: ht

[issue23910] C implementation of namedtuple (WIP)

Raymond Hettinger added the comment: What kind of speed improvement have you gotten? -- ___ Python tracker ___ ___ Python-bugs-list ma

[issue22544] Inconsistent cmath.log behaviour

Changes by STINNER Victor : -- nosy: -haypo ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.pytho

[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 * pa

[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 __

[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 eve

[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 Window

[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 OpenB

[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 _

[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 ___ ___ Pytho

[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 EXIT_FAILUR

[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 har

[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. -- _

[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 track

[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 co

[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. -- _

[issue24065] Outdated *_RESTRICTED flags in structmember.h

Antoine Pitrou added the comment: +1 for deprecating them. -- nosy: +pitrou ___ Python tracker ___ ___ Python-bugs-list mailing list U

[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' conver

[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 len(resul

[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 ___ ___

[issue24064] Make the property doctstring writeable

Changes by Ethan Furman : -- nosy: +ethan.furman ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.p

[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 stat

[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 shoul

[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 method

[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 th

[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 ___ __

[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 stand

[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 on

[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 ___

[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 th

[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 wo

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

Changes by Guido van Rossum : -- nosy: +gvanrossum ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail

[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

[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 tran

[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 t

[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

[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 `Bcc`.

[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 (verified

[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

[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 tracke

[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 ___

[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 ___ ___ Python-bugs-list mailing lis

[issue24067] Weakproxy is an instance of collections.Iterator

Changes by Ned Deily : -- nosy: +fdrake, pitrou ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.py

[issue21345] multiprocessing.Pool._handle_workers sleeps too long

Changes by Davin Potts : -- nosy: +davin ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.or

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

Changes by Davin Potts : -- nosy: +davin ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org

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

Changes by Mark Lawrence : -- nosy: +steve.dower ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.p

[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 being

[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

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

Changes by Ned Deily : -- nosy: +rbcollins ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.

[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 wrote: > > Changes by Ned Deily >: > > > -

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

Kirill Elagin added the comment: x_x -- keywords: +patch Added file: http://bugs.python.org/file39219/multiple_to.patch ___ Python tracker ___ ___

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

Changes by Ned Deily : -- nosy: +barry, r.david.murray -ned.deily stage: -> patch review versions: +Python 3.5 ___ Python tracker ___ ___