[issue23292] Enum doc suggestion
Mark Summerfield added the comment: Georg said to assign this to Ethan Furman but I don't seem to have that facility. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23292 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23291] Documentation about Py_Finalize(): Freeing objects
New submission from Albert Zeyer: The documentation about Py_Finalize() about freeing objects is not exactly clear. Esp., when I have called Py_INCREF somewhere, those objects will always have ob_refcnt 0 unless I call Py_DECREF somewhere, what about these objects? Will they be freed in Py_Finalize() or not? If not, what can I do? I guess calling Py_DECREF after Py_Finalize() is not allowed. I studied the Py_Finalize() code but I'm not exactly sure. It looks like such objects would not get freed (unless some implicit magic is happening somewhere). The comment about the last commented-out PyGC_Collect() call is also insightful and somewhat unsatisfying. Maybe PyObject_Free() still works, although that would not free any further referenced objects, I guess. Also, I'm not exactly sure about the pymalloc arenas. With pymalloc, maybe we could just free all pymalloc arenas and it would free all memory allocated by Python objects? Of course, that would not call any advanced tp_dealloc functions which might be important to be called, but we would never ever call those anyway anymore, or would we (how?)? So, maybe it would be good to do that? -- components: Interpreter Core messages: 234441 nosy: Albert.Zeyer priority: normal severity: normal status: open title: Documentation about Py_Finalize(): Freeing objects versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23291 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23292] Enum doc suggestion
New submission from Mark Summerfield: I think it would be worth documenting globals().update(MyEnumeration.__members__) in the Interesting Examples section of the enum docs. I suspect that most people will find that importing enums is annoying because they'll get import A print(A.MyEnumeration.MAX) when they're more used to import A print(A.MAX) Of course the latter is easily achieved using the globals().update() trick (as used in signals.py in 3.5). Georg suggested I add this to the tracker. -- assignee: docs@python components: Documentation files: py-enum.tar.gz messages: 234442 nosy: docs@python, mark priority: normal severity: normal status: open title: Enum doc suggestion type: enhancement versions: Python 3.5, Python 3.6 Added file: http://bugs.python.org/file37809/py-enum.tar.gz ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23292 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23095] [Windows] asyncio: race condition when cancelling a _WaitHandleFuture
STINNER Victor added the comment: To wait for the exit of the subprocess, we use RegisterWaitForSingleObject(). To cancel this wait, we can use UnregisterWait() which returns immediatly. Problem: UnregisterWait() doesn't tell us if the wait was cancelled or not, the cancellation is asynchronous. Second problem: the wait may have been signaled to the IOCP... or not. The wait may be signaled after the call to UnregisterWait(), since the cancellation is asynchronous (I'm not sure of that, but it doesn't change everything). This can be explained by the implementation: RegisterWaitForSingleObject() is implemented with a pool of threads. Windows XP introduced UnregiterWaitEx() which can be used to be notified when the wait has been cancelled. Cool. But the notification requires an Event object. And how can we asynchronously wait for this Event? Using RegisterWaitForSingleObject()! Wait, what? We were cancelling another RegisterWaitForSingleObject(). To be fully asynchronous (no performance impact), cancelling a RegisterWaitForSingleObject() wait requires a new Event object and call RegisterWaitForSingleObject() on it. -- In Python, we must ensure that the Overlapped object used by RegisterWaitForSingleObject() is kept alive until the wait is signalled, or until we are sure that the wait was cancelled. Otherwise, the program may crash. To keep the Overlapped object alive, we keep indirectly in a _WaitHandleFuture object, and this future is registered in IocpProactor._cache. I'm working on a change to use UnregiterWaitEx(). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23095 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17620] Python interactive console doesn't use sys.stdin for input
Drekin added the comment: Unfortunately, I have little or no experience with Python C code and I even don't have a C compiler installed so I cannot experiment. I'll just put my ideas how to solve this here. • Add sys.__readlinehook__ attribute, which can be set to a function taking a prompt string and returing a line. • Add C function PyOS_UnicodeReadline (possibly with a better name) which has the same signature as sys.__readlinehook__ (in contrast with the signature of PyOS_Readline). If sys.__readlinehook__ is set, call it; otherwise encode the prompt string using stdout encoding and delegate to PyOS_Readline and decode the string returned using stdin encoding. • Change the tokenizer and the implementation of input() so it uses PyOS_UnicodeReadline rather than PyOS_Readline. This would solve the problem that utf-16 encoded string cannot be given to the tokenizer and also would bypass the silent assumption that stdin and stdout encodings are the same. Also, readline hook could be easily set from Python code – no need for ctypes. The package pyreadline could use this. Also, the issue #1602 could be then solved just by changing sys.std* streams and providing a trivial sys.__readlinehook__ delegating to sys.stdout.write and sys.stdin.readline. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17620 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22885] Arbitrary code execution vulnerability due to unchecked eval() call in dumbdbm module
Changes by Claudiu Popa pcmantic...@gmail.com: -- priority: normal - high stage: - patch review versions: +Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22885 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23292] Enum doc suggestion
Changes by Georg Brandl ge...@python.org: -- assignee: docs@python - ethan.furman nosy: +ethan.furman ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23292 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2292] Missing *-unpacking generalizations
Joshua Landau added the comment: I think I've fixed the memory leaks (plural). There were also a host of other problems with the _UNPACK opcodes in ceval. Here are the things I remember fixing, although I think I did slightly more: - Not throwing an error when PyDict_New or PyDict_Update fails. - Not doing Py_DECREF on stack items being popped. - Not checking if intersection is non-NULL. - Not doing Py_DECREF on intersection. Now the primary problem is giving good errors; I don't know how to make them look like they came from the function call. I'm not sure I want to, either, since these opcodes are used elsewhere. I do need to check something about this (what requirements are there on how you leave the stack when you goto error?), but that's an easy fix if my current guess isn't right. -- Added file: http://bugs.python.org/file37811/starunpack13.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2292 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23166] urllib2 ignores opener configuration under certain circumstances
Enrico Tröger added the comment: I got the same error suddenly with Python 2.7.9. I think this is quite unfortunate because it somewhat breaks existing behaviour, especially that SSL certificate verification is enabled by default. Don't get me wrong, this is the right thing in general and it is important. Still, adding this feature in a 2.7 patch level release and enabling it by default feels quite hard. I guess this will break many scripts and applications which rely on non-verification of SSL certs (which is bad but it was the exisiting behaviour). Anyway, attached is my use case where I use a HTTPS request coupled with HTTP basic authentication and disabled SSL cert verification. As described above, passing a context to urlopen() will override previously configured handlers, unfortunately. In the attached script there is also a workaround which works for me by not using urlopen() but instead calling opener.open() manually after adding the necessary handlers myself. Not nice but works for the moment. -- nosy: +eht16 Added file: http://bugs.python.org/file37810/urllib_ssl_auth_test.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23166 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22885] Arbitrary code execution vulnerability due to unchecked eval() call in dumbdbm module
Guido van Rossum added the comment: Python 3's exception chaining allows us to do the second (easier to catch without resorting to except Exception: or even except:) while still showing the original exception in the traceback. -- nosy: +gvanrossum ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22885 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22885] Arbitrary code execution vulnerability due to unchecked eval() call in dumbdbm module
Claudiu Popa added the comment: Here's a patch which uses ast.literal_eval instead. This doesn't get code executed, since literal_eval will fail loudly for anything other than a literal. There are some issues to consider: - let the current ast.literal_eval call bubble out with a lot of different exceptions - normalize the exception to dbm.dumb.error. I'm leaning towards the first, since it clearly shows that something bad happened in the module and it's a first indicator that someone tampered with the data file. -- keywords: +patch nosy: +Claudiu.Popa Added file: http://bugs.python.org/file37812/issue22885.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22885 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23294] A typo in the tutorial
New submission from aruseni: https://docs.python.org/3/tutorial/controlflow.html In many ways the object returned by range() behaves as if it is a list, but in fact it isn’t. -- messages: 234449 nosy: aruseni priority: normal severity: normal status: open title: A typo in the tutorial ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23294 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23095] [Windows] asyncio: race condition when cancelling a _WaitHandleFuture
Roundup Robot added the comment: New changeset fb8a093db8b1 by Victor Stinner in branch '3.4': Issue #23095, asyncio: Rewrite _WaitHandleFuture.cancel() https://hg.python.org/cpython/rev/fb8a093db8b1 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23095 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23095] [Windows] asyncio: race condition when cancelling a _WaitHandleFuture
Roundup Robot added the comment: New changeset d3804307cce4 by Victor Stinner in branch '3.4': Issue #23095, asyncio: IocpProactor.close() must not cancel pending https://hg.python.org/cpython/rev/d3804307cce4 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23095 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23293] [Windows] asyncio: race condition related to IocpProactor.connect_pipe()
Changes by STINNER Victor victor.stin...@gmail.com: -- title: [Windows] asyncio: race condition related in IocpProactor.connect_pipe() - [Windows] asyncio: race condition related to IocpProactor.connect_pipe() ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23293 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23095] [Windows] asyncio: race condition when cancelling a _WaitHandleFuture
STINNER Victor added the comment: It took me several months to understand this issue. For the beginning of the story, see: https://code.google.com/p/tulip/issues/detail?id=196 But I think that *this* issue can be closed: UnregisterWaitEx() really do what we need in asyncio. I don't like the complex IocpProactor._unregister() function and _WaitCancelFuture class, but it looks that it's how we are supposed to wait until a wait for a handle is cancelled... Windows IOCP API is much complex that what I expected. It's probably because some parts (especially RegisterWaitForSingleObject()) are implemented with threads in user land, not in the kernel. In short, I'm very happy that have fixed this very complex but also very annoying IOCP bug in asyncio. -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23095 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23293] [Windows] asyncio: race condition related in IocpProactor.connect_pipe()
New submission from STINNER Victor: Currently, IocpProactor.connect_pipe() is implemented with QueueUserWorkItem() which starts a thread that cannot be interrupted. Because of that, this function requires special cases in _register() and close() methods of IocpProactor. While fixing the issue #23095, I saw that IocpProactor.connect_pipe() causes GetQueuedCompletionStatus() returned an unexpected event messages to be logged, but also to hang the test suite. I propose a solution to reimplement IocpProactor.connect_pipe() without a thread: https://code.google.com/p/tulip/issues/detail?id=197 It should fix this issue. -- components: Windows, asyncio messages: 234448 nosy: gvanrossum, haypo, steve.dower, tim.golden, yselivanov, zach.ware priority: normal severity: normal status: open title: [Windows] asyncio: race condition related in IocpProactor.connect_pipe() versions: Python 3.4, Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23293 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2292] Missing *-unpacking generalizations
Joshua Landau added the comment: The _UNPACK opcodes are new in this changelist. Yup, but they're used in the other unpacking syntax too: (*(1, 2, 3), *(4, 5, 6)) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2292 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23095] [Windows] asyncio: race condition when cancelling a _WaitHandleFuture
Guido van Rossum added the comment: Congrats with the fix, and thanks for your perseverance! -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23095 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23295] [Windows] asyncio: add UDP support to ProactorEventLoop
New submission from STINNER Victor: ProactorEventLoop lacks UDP support: create_datagram_endpoint() is not supported. New functions should be added to the _overlapped modul. Example: add maybe WSARecvFrom()? -- components: Windows, asyncio messages: 234456 nosy: gvanrossum, haypo, steve.dower, tim.golden, yselivanov, zach.ware priority: normal severity: normal status: open title: [Windows] asyncio: add UDP support to ProactorEventLoop versions: Python 3.4, Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23295 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22885] Arbitrary code execution vulnerability due to unchecked eval() call in dumbdbm module
Claudiu Popa added the comment: Thanks for the tip, Guido. The new patch uses exception chaining. If this needs backporting, most probably the first patch can be used. -- Added file: http://bugs.python.org/file37813/issue22885_1.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22885 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23294] A typo in the tutorial
Changes by aruseni aruseni.mag...@gmail.com: -- assignee: - docs@python components: +Documentation nosy: +docs@python ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23294 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23095] [Windows] asyncio: race condition when cancelling a _WaitHandleFuture
STINNER Victor added the comment: IocpProactor.close() must not cancel pending _WaitCancelFuture futures FYI I found this bug when running the trollius test suite. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23095 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2292] Missing *-unpacking generalizations
Neil Girdhar added the comment: Very nice! So what's left besides errors? * Fixing the grammar, ast, and compilation for the list, dict, and set comprehension element unpackings Now the primary problem is giving good errors; I don't know how to make them look like they came from the function call. I'm not sure I want to, either, since these opcodes are used elsewhere. The _UNPACK opcodes are new in this changelist. You can do hg vdiff to give a side-by-side diff or just check in the patch review. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2292 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23297] ‘tokenize.detect_encoding’ is confused between text and bytes: no ‘startswith’ method on a byte string
R. David Murray added the comment: bytes does support startswith: b'abc'.startswith(b'a') True -- nosy: +r.david.murray ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23297 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14910] argparse: disable abbreviation
Andy Zobro added the comment: This breaks custom actions. e.g.: class dict_action(argparse.Action): def __init__(self, *a, **k): argparse.Action.__init__(self, *a, **k) TypeError: __init__() got an unexpected keyword argument 'allow_abbrev' -- nosy: +xobes ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14910 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2292] Missing *-unpacking generalizations
Neil Girdhar added the comment: Also maybe not in this changelist, but we should consider replacing STORE_MAP and BUILD_MAP with a single opcode BUILD_MAP(n) that produces a dict out of the top n items on the stack just like BUILD_LIST(n) does. What do you think? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2292 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17776] IDLE Internationalization
Terry J. Reedy added the comment: I answered my Q1 in msg187219: test.test_gettest is currently passing, with no skips, on 2.7 and 3.4 on Win 7. patch.diff: I would rather add the 4 lines of the proposed idle_i18n.py to an existing module, perhaps Bindings.py itself, since that is the first place _ will be used. I think +-60 modules is already too many. The binding of '_' to gettext.gettext conflicts with the somewhat common use of '_' as a dummy identifier. I do not know of any such uses in idlelib, but there might be. There are about 4500 lines in idlelib with '_'; too many to review. Someone should do a more refined search with an re that excludes '_' preceded or followed by an identifier char, to skip '__xyz__' or '_x' or 'y_'. If '_ is used for gettest, a new rule to not otherwise bind '_' should be added the currently non-existent Idle maintainer guide. patch2.tar.gz is not readable by Rietveld, Firefox, IE, or Windows. Patches should be uploaded as plaintext.diff or .patch. Damien: Contributors must submit a signed Contributor Agreement. See https://www.python.org/psf/contrib/ and https://www.python.org/psf/contrib/contrib-form/ (the online form). Please do this even before re-uploading patch2. Receipt and acceptance of a form is acknowledged by addition of an * after Author: nick(real name). -- versions: +Python 3.5 -Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17776 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23298] Add ArgumentParser.add_mutually_dependence_group
New submission from dongwm:
Sometimes I need to use argparse like this:
parser = argparse.ArgumentParser(prog='PROG')
group = parser.add_mutually_dependence_group()
group.add_argument('--foo')
group.add_argument('--bar')
parser.parse_args(['--foo', 'f', '--bar', 'b'])
Namespace(bar='b', foo='f')
parser.parse_args(['--foo', 'f'])
PROG: error: --foo dependence on --bar
parser.parse_args(['--bar', 'b'])
PROG: error: --bar dependence on --foo
I have some optional argument. but if any argument in a group was present on
the command line. i need the others must also was present on. so i think
``add_mutually_dependence_group`` does make sense.
--
components: Library (Lib)
files: argparse_lib.patch
keywords: patch
messages: 234475
nosy: bethard, dongwm
priority: normal
severity: normal
status: open
title: Add ArgumentParser.add_mutually_dependence_group
type: enhancement
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file37814/argparse_lib.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23298
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23298] Add ArgumentParser.add_mutually_dependence_group
Changes by dongwm ciici...@gmail.com: Added file: http://bugs.python.org/file37816/argparse_test.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23298 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14910] argparse: disable abbreviation
Andy Zobro added the comment: Ignore previous comment, I wish I could delete it. I simply provided the allow_abbrev to the wrong function and spent zero time investigating the error. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14910 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23296] ‘tokenize.detect_encoding’ is confused between text and bytes: no ‘startswith’ method on a byte string
Changes by Benjamin Peterson benja...@python.org: -- resolution: - duplicate status: open - closed superseder: - ‘tokenize.detect_encoding’ is confused between text and bytes: no ‘startswith’ method on a byte string ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23296 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23298] Add ArgumentParser.add_mutually_dependence_group
Changes by dongwm ciici...@gmail.com: Added file: http://bugs.python.org/file37815/argparse_doc.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23298 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23294] A typo in the tutorial
Eric V. Smith added the comment: What's the typo? I'm not seeing it. -- nosy: +eric.smith ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23294 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2292] Missing *-unpacking generalizations
Joshua Landau added the comment: According to the standard, int can be only 16 bits long so that only leaves 255/255. However, if the offset is on top of the dictionary count, this is easily enough to clear the limits for the maximum function size (worst case is a merge of 255 dicts with an offset of 1 or a merge of 2 dicts with an offset of 254). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2292 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2292] Missing *-unpacking generalizations
Neil Girdhar added the comment: You're right. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2292 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2292] Missing *-unpacking generalizations
Neil Girdhar added the comment: I am a huge fan of giving good errors. Looks good to me. Will we need to make sure that the call helper function we worked on produces additional BUILD_MAP_UNPACK opcodes every 256 dictionaries just in case? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2292 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2292] Missing *-unpacking generalizations
Neil Girdhar added the comment: Another option to consider is to just use a bit on the BUILD_MAP_UNPACK and then have a stack marking opcode at the function call (not sure what to call it, but say FUNCTION_CALL_MARK) The advantage would be you don't store or calculate relative stack positions. When the interpreter sees the mark, it stores the function call address for use in BUILD_MAP_UNPACK errors. Although I guess you have 24 bits to store the relative stack position? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2292 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2292] Missing *-unpacking generalizations
Joshua Landau added the comment: Functions are already limited to 255 arguments, so I don't think so. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2292 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2292] Missing *-unpacking generalizations
Neil Girdhar added the comment: Oh, I see. For BUILD_MAP_UNPACK we don't want to raise on duplicate dict comprehension element unpackings, right? Maybe we should add a different opcode, or else a flag to the opcodes, or else use the top bit of the length parameter? What do you think? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2292 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2292] Missing *-unpacking generalizations
Neil Girdhar added the comment: I see your point: if there are 255 dictionaries, there's no room for neither preceding keyword arguments nor positional arguments. Okay, then I like your solution. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2292 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2292] Missing *-unpacking generalizations
Joshua Landau added the comment: We wouldn't want to replace STORE_MAP since that's used in dictionary comprehensions, but replacing BUILD_MAP with BUILD_MAP(n) sounds like a great idea. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2292 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2292] Missing *-unpacking generalizations
Joshua Landau added the comment: Good catch. CALL_FUNCTION seems to split its opcode into two to give it a positional-keyword pair so this seems fine. I'd hope we can do the same thing; personally I would do: BUILD_MAP_UNPACK( position_of_function_in_stack_or_0 8 | number_to_pack ) This way if building for a function we can do the check *and* give good errors that match the ones raised from CALL_FUNCTION. When the top 8 bits are 0, we don't do checks. What do you think? Would dual-usage be too confusing? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2292 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23297] ‘tokenize.detect_encoding’ is confused between text and bytes: no ‘startswith’ method on a byte string
New submission from Ben Finney: In `tokenize.detect_encoding` is the following code:: first = read_or_stop() if first.startswith(BOM_UTF8): # … The `read_or_stop` function is defined as:: def read_or_stop(): try: return readline() except StopIteration: return b'' So, on catching ``StopIteration``, the return value will be a byte string. The `detect_encoding` code then immediately calls `sartswith`, which fails:: File /usr/lib/python3.4/tokenize.py, line 409, in detect_encoding if first.startswith(BOM_UTF8): TypeError: startswith first arg must be str or a tuple of str, not bytes One or both of those locations in the code is wrong. Either `read_or_stop` should never return a byte string; or `detect_encoding` should not assume it can call `startswith` on the result. -- components: Library (Lib) messages: 234471 nosy: bignose priority: normal severity: normal status: open title: ‘tokenize.detect_encoding’ is confused between text and bytes: no ‘startswith’ method on a byte string type: crash versions: Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23297 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23296] ‘tokenize.detect_encoding’ is confused between text and bytes: no ‘startswith’ method on a byte string
New submission from Ben Finney: In `tokenize.detect_encoding` is the following code:: first = read_or_stop() if first.startswith(BOM_UTF8): # … The `read_or_stop` function is defined as:: def read_or_stop(): try: return readline() except StopIteration: return b'' So, on catching ``StopIteration``, the return value will be a byte string. The `detect_encoding` code then immediately calls `sartswith`, which fails:: File /usr/lib/python3.4/tokenize.py, line 409, in detect_encoding if first.startswith(BOM_UTF8): TypeError: startswith first arg must be str or a tuple of str, not bytes One or both of those locations in the code is wrong. Either `read_or_stop` should never return a byte string; or `detect_encoding` should not assume it can call `startswith` on the result. -- components: Library (Lib) messages: 234470 nosy: bignose priority: normal severity: normal status: open title: ‘tokenize.detect_encoding’ is confused between text and bytes: no ‘startswith’ method on a byte string versions: Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23296 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23297] ‘tokenize.detect_encoding’ is confused between text and bytes: no ‘startswith’ method on a byte string
Ben Finney added the comment: Possibly related to issue9969. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23297 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23154] MSVC 2013 Express needlessly rebuilds code
Mark Lawrence added the comment: I've noticed a similar problem this morning with 5 modules rebuilt under Debug but 29 under Release. I believe the change that triggered me spotting it is this fb8a093db8b1 Issue #23095. Do we need a new issue for this? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23154 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23288] subprocess.Popen close_fds behaviour differs between 3.2 and 3.4
New submission from Mike Sampson:
I'm seeing differing behaviour with subprocess.Popen(..., close_fds = False)
between 3.2 and 3.4. The docs don't say this is meant to be the case as far as
I can see.
Python 3.2.3 on Debian Wheezy
=
import subprocess
import os
r,w = os.pipe()
p = subprocess.Popen('ls /dev/fd/*', shell = True, close_fds = False)
ls: cannot access /dev/fd/5: No such file or directory
/dev/fd/0 /dev/fd/1 /dev/fd/2 /dev/fd/3 /dev/fd/4
Python 3.4.2 on Arch Linux
==
import subprocess
import os
r,w = os.pipe()
p = subprocess.Popen('ls /dev/fd/*', shell = True, close_fds = False)
ls: cannot access /dev/fd/3: No such file or directory
/dev/fd/0 /dev/fd/1 /dev/fd/2
In 3.4 even though close_fds is False the fds are closed in the child. Using
pass_fds works around this though I would like to know if this is a bug,
documentation issue, or am I missing something here?
--
assignee: docs@python
components: Documentation
messages: 234428
nosy: docs@python, mfs
priority: normal
severity: normal
status: open
title: subprocess.Popen close_fds behaviour differs between 3.2 and 3.4
type: behavior
versions: Python 3.2, Python 3.4
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23288
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23288] subprocess.Popen close_fds behaviour differs between 3.2 and 3.4
Mike Sampson added the comment: Ah, got it. Didn't see the note on the os.pipe() docs. Thanks. Closing. Sorry for the noise. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23288 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23288] subprocess.Popen close_fds behaviour differs between 3.2 and 3.4
Changes by Mike Sampson m...@sambodata.com: -- status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23288 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22176] update internal libffi copy to 3.1, introducing AArch64 and POWER ELF ABIv2
Changes by koobs koobs.free...@gmail.com: -- nosy: +koobs ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22176 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23286] A typo in the tutorial
Changes by Mayank Tripathi oqua...@gmail.com: -- keywords: +patch Added file: http://bugs.python.org/file37804/intro_typo.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23286 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23285] PEP 475 - EINTR handling
Charles-François Natali added the comment: The review diff is weird: it seems it contains changes that aren't EINTR-related (see e.g. argparse.rst). Here's a manually generated diff. -- Added file: http://bugs.python.org/file37802/eintr.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23285 ___diff -r fe0fddd6fd21 Lib/_pyio.py --- a/Lib/_pyio.py Sun Jan 18 11:17:39 2015 +0200 +++ b/Lib/_pyio.py Wed Jan 21 05:55:58 2015 + @@ -1006,10 +1006,7 @@ current_size = 0 while True: # Read until EOF or until read() would block. -try: -chunk = self.raw.read() -except InterruptedError: -continue +chunk = self.raw.read() if chunk in empty_values: nodata_val = chunk break @@ -1028,10 +1025,7 @@ chunks = [buf[pos:]] wanted = max(self.buffer_size, n) while avail n: -try: -chunk = self.raw.read(wanted) -except InterruptedError: -continue +chunk = self.raw.read(wanted) if chunk in empty_values: nodata_val = chunk break @@ -1060,12 +1054,7 @@ have = len(self._read_buf) - self._read_pos if have want or have = 0: to_read = self.buffer_size - have -while True: -try: -current = self.raw.read(to_read) -except InterruptedError: -continue -break +current = self.raw.read(to_read) if current: self._read_buf = self._read_buf[self._read_pos:] + current self._read_pos = 0 @@ -1214,8 +1203,6 @@ while self._write_buf: try: n = self.raw.write(self._write_buf) -except InterruptedError: -continue except BlockingIOError: raise RuntimeError(self.raw should implement RawIOBase: it should not raise BlockingIOError) diff -r fe0fddd6fd21 Lib/distutils/spawn.py --- a/Lib/distutils/spawn.pySun Jan 18 11:17:39 2015 +0200 +++ b/Lib/distutils/spawn.pyWed Jan 21 05:55:58 2015 + @@ -137,9 +137,6 @@ try: pid, status = os.waitpid(pid, 0) except OSError as exc: -import errno -if exc.errno == errno.EINTR: -continue if not DEBUG: cmd = executable raise DistutilsExecError( diff -r fe0fddd6fd21 Lib/multiprocessing/connection.py --- a/Lib/multiprocessing/connection.py Sun Jan 18 11:17:39 2015 +0200 +++ b/Lib/multiprocessing/connection.py Wed Jan 21 05:55:58 2015 + @@ -365,10 +365,7 @@ def _send(self, buf, write=_write): remaining = len(buf) while True: -try: -n = write(self._handle, buf) -except InterruptedError: -continue +n = write(self._handle, buf) remaining -= n if remaining == 0: break @@ -379,10 +376,7 @@ handle = self._handle remaining = size while remaining 0: -try: -chunk = read(handle, remaining) -except InterruptedError: -continue +chunk = read(handle, remaining) n = len(chunk) if n == 0: if remaining == size: @@ -595,13 +589,7 @@ self._unlink = None def accept(self): -while True: -try: -s, self._last_accepted = self._socket.accept() -except InterruptedError: -pass -else: -break +s, self._last_accepted = self._socket.accept() s.setblocking(True) return Connection(s.detach()) diff -r fe0fddd6fd21 Lib/multiprocessing/forkserver.py --- a/Lib/multiprocessing/forkserver.py Sun Jan 18 11:17:39 2015 +0200 +++ b/Lib/multiprocessing/forkserver.py Wed Jan 21 05:55:58 2015 + @@ -188,8 +188,6 @@ finally: os._exit(code) -except InterruptedError: -pass except OSError as e: if e.errno != errno.ECONNABORTED: raise @@ -230,13 +228,7 @@ data = b'' length = UNSIGNED_STRUCT.size while len(data) length: -while True: -try: -s = os.read(fd, length - len(data)) -except InterruptedError: -pass -else: -break +s = os.read(fd, length - len(data)) if not s: raise
[issue2292] Missing *-unpacking generalizations
Neil Girdhar added the comment: Added many tests, six of which fail. Started work on grammar to fix new tests. -- Added file: http://bugs.python.org/file37805/starunpack11.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2292 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23288] subprocess.Popen close_fds behaviour differs between 3.2 and 3.4
STINNER Victor added the comment: File descriptors are not closed, but not inherited neither, in Python 3.4. See the PEP 446. To have a reliable behaviour on all platforms and all Python versions, just use the pass_fds parameter. -- nosy: +haypo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23288 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23288] subprocess.Popen close_fds behaviour differs between 3.2 and 3.4
STINNER Victor added the comment: https://docs.python.org/dev/library/os.html#os.pipe Changed in version 3.4: The new file descriptors are now non-inheritable. If you don't use the subprocess module, you may use os.set_inheritable(). https://docs.python.org/dev/library/os.html#os.set_inheritable -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23288 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5907] repr of time.struct_time type does not eval
Changes by lilydjwg lilyd...@gmail.com: -- nosy: +lilydjwg ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5907 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11698] Improve repr for structseq objects to show named, but unindexed fields
Changes by lilydjwg lilyd...@gmail.com: -- nosy: +lilydjwg ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11698 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23193] Please support numeric_owner in tarfile
Michael Vogt added the comment: Thanks everyone for the comments and feedback! Attached is a updated patch with tests and a documentation update. Feedback is very welcome. I decided to skip the test on systems where root is not uid,gid=0. I could also mock that of course if you prefer it this way. Thanks, Michael -- Added file: http://bugs.python.org/file37803/tarfile-numeric-owner-with-tests.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23193 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23289] concurrent.futures.Executor.map is not equivalent to map.
New submission from Piotr Majkrzak: In documentation https://docs.python.org/3/library/concurrent.futures.html#concurrent.futures.Executor.map is writen that this fucntion is equivalent to the builtin map. But it is not true due to the fact that it is not lazy evalueded. The reason is in https://hg.python.org/cpython/file/0893b9ee44ea/Lib/concurrent/futures/_base.py#l548 where the full list of features is created. I don't find any reasonable solutions, but in my case following code was suitable. https://gist.github.com/06bbd83eccd4083c68d0 -- components: Library (Lib) messages: 234433 nosy: majkrzak priority: normal severity: normal status: open title: concurrent.futures.Executor.map is not equivalent to map. type: behavior versions: Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23289 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12029] Catching virtual subclasses in except clauses
Yuriy Taraday added the comment: Can we move forward and land this patch? It seems to be working and for some reason it even makes that microbenchmark work faster. -- versions: +Python 3.5 -Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12029 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23290] Faster set copying
Serhiy Storchaka added the comment:
Here is even faster patch. When there are no dummies in source set we can just
dump a table, placing entries at the same indices.
$ ./python -m timeit -s s = set(range(10**4)) -- frozenset(s)
Unpatched: 1000 loops, best of 3: 658 usec per loop
Patched: 1000 loops, best of 3: 631 usec per loop
$ ./python -m timeit -s s = {i+(j64) for i in range(10**3) for j in
range(10)} -- frozenset(s)
Unpatched: 100 loops, best of 3: 6.72 msec per loop
Patched: 1000 loops, best of 3: 930 usec per loop
$ ./python -m timeit -s s = {i+(j64) for i in range(10**2) for j in
range(10**2)} -- frozenset(s)
Unpatched: 100 loops, best of 3: 14 msec per loop
Patched: 1000 loops, best of 3: 1.12 msec per loop
To test other branch we should add dummy entry: s.add(-1); s.discard(-1).
$ ./python -m timeit -s s = {i+(j64) for i in range(10**3) for j in
range(10)}; s.add(-1); s.discard(-1) -- frozenset(s)
Unpatched: 1000 loops, best of 3: 661 usec per loop
Patched: 1000 loops, best of 3: 643 usec per loop
$ ./python -m timeit -s s = {i+(j64) for i in range(10**3) for j in
range(10)}; s.add(-1); s.discard(-1) -- frozenset(s)
Unpatched: 100 loops, best of 3: 6.8 msec per loop
Patched: 100 loops, best of 3: 2.1 msec per loop
$ ./python -m timeit -s s = {i+(j64) for i in range(10**2) for j in
range(10**2)}; s.add(-1); s.discard(-1) -- frozenset(s)
Unpatched: 100 loops, best of 3: 14 msec per loop
Patched: 100 loops, best of 3: 2.71 msec per loop
--
Added file: http://bugs.python.org/file37808/set_faster_copy_2.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23290
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23288] subprocess.Popen close_fds behaviour differs between 3.2 and 3.4
Changes by R. David Murray rdmur...@bitdance.com: -- resolution: - not a bug stage: - resolved ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23288 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2292] Missing *-unpacking generalizations
Joshua Landau added the comment: Some of the tests seemed to be failing simply because they were incorrect. This fixes that. -- Added file: http://bugs.python.org/file37806/starunpack12.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2292 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23290] Faster set copying
New submission from Serhiy Storchaka:
Proposed patch makes faster creating new set from other set. The benefit is
only few percents when there are no hash conflicts, but can be significant if
there are hash duplicates.
$ ./python -m timeit -s s = set(range(10**4)) -- frozenset(s)
Unpatched: 1000 loops, best of 3: 658 usec per loop
Patched: 1000 loops, best of 3: 620 usec per loop
$ ./python -m timeit -s s = {i+(j64) for i in range(10**3) for j in
range(10)} -- frozenset(s)
Unpatched: 100 loops, best of 3: 6.72 msec per loop
Patched: 100 loops, best of 3: 2.05 msec per loop
$ ./python -m timeit -s s = {i+(j64) for i in range(10**2) for j in
range(10**2)} -- frozenset(s)
Unpatched: 100 loops, best of 3: 14 msec per loop
Patched: 100 loops, best of 3: 2.67 msec per loop
It should also affect set.copy and operations which makes implicit copy (most
set operators). The effect should be larger for objects with slow equality
operator.
set_find_free_slot() can be used to prevent a catastrophic linear pile-up in
issue23259.
--
components: Interpreter Core
messages: 234437
nosy: serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Faster set copying
type: performance
versions: Python 3.5
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23290
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12312] is ok
Changes by Ezio Melotti ezio.melo...@gmail.com: -- Removed message: http://bugs.python.org/msg234435 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12312 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12029] Catching virtual subclasses in except clauses
Changes by Berker Peksag berker.pek...@gmail.com: -- stage: needs patch - patch review ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12029 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12312] is ok
liyang added the comment: -- name:李洋 celephone：15011548154 -- nosy: +liyang1...@gmail.com ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12312 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23290] Faster set copying
Changes by Serhiy Storchaka storch...@gmail.com: -- keywords: +patch nosy: +pitrou, rhettinger Added file: http://bugs.python.org/file37807/set_faster_copy.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23290 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
