[issue3566] httplib persistent connections violate MUST in RFC2616 sec 8.1.4.
Martin Panter added the comment: Hi Demian, my intention is to demonstrate normal usage of Python’s HTTP client, whether or not its implementation misbehaves. I am trying to demonstrate a valid persistent server that happens to decide to close the connection after the first request but before reading a second request. Quoting the original post: “Servers may close a persistent connection after a request due to a timeout or other reason.” I am attaching a second demo script which includes short sleep() calls to emulate a period of time elapsing and the server timing out the connection, which is common for real-world servers. The new script also avoids the EPIPE race by waiting until the server has definitely shut down the socket, and also demonstrates ECONNRESET. However this synchronization is artificial: in the real world the particular failure mode (BadStatusLine/EPIPE/ECONNRESET) may be uncertain. If you are worried about detecting a misbehaving server that closes the connection before even responding to the first request, perhaps the HTTPConnection class could maintain a flag and handle the closed connection differently if it has not already seen a complete response. If you are worried about detecting a misbehaving server that sends an empty status line without closing the connection, there will still be a newline code received. This is already handled separately by existing code: Lib/http/client.py:210 versus Lib/http/client.py:223. I think there should be a separate exception, say called ConnectionClosed, for when the “status line” is an empty string (), which is caused by reading the end of the stream. This is valid HTTP behaviour for the second and subsequent requests, so the HTTP library should understand it. BadStatusLine is documented for “status codes we don’t understand”. The new ConnectionClosed exception should probably be a subclass of BadStatusLine for backwards compatibility. A further enhancement could be to wrap any ConnectionError during the request() stage, or first part of the getresponse() stage, in the same ConnectionClosed exception. Alternatively, the new ConnectionClosed exception could subclass both BadStatusLine and ConnectionError. Either way, code like the XML-RPC client could be simplified to: try: return self.single_request(...) except http.client.ConnectionClosed: #except ConnectionError: # Alternative #retry request once if cached connection has gone cold return self.single_request(...) -- Added file: http://bugs.python.org/file37778/persistent-closing.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3566 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23276] hackcheck is broken in association with __setattr__
eryksun added the comment:
super(type, cls).__setattr__(key, value)
In your case, super(type, cls).__setattr__ references object.__setattr__.
super(type, MyClass).__setattr__.__objclass__
class 'object'
That's from the method resolution order (__mro__):
print(*MyMeta.__mro__, sep='\n')
class '__main__.MyMeta'
class '__main__.MetaA'
class '__main__.MetaB'
class 'type'
class 'object'
Instead use super(MyMeta, cls), or in Python 3 just use super() in a method
(under the hood the function uses a closure variable named __class__).
super(MyMeta, MyClass).__setattr__.__objclass__
class 'type'
type.__setattr__(MyClass, 'test', 42)
The above won't work for a Qt subclass. You need __setattr__ from
sip.wrappertype.
type.__setattr__(QtClass, 'test', 42)
Traceback (most recent call last):
File stdin, line 1, in module
TypeError: can't apply this __setattr__ to sip.wrappertype object
print(*QtMeta.__mro__, sep='\n')
class '__main__.QtMeta'
class '__main__.MetaA'
class 'sip.wrappertype'
class 'type'
class 'object'
super(QtMeta, QtClass).__setattr__.__objclass__
class 'sip.wrappertype'
super(QtMeta, QtClass).__setattr__('test', 42)
QtClass.test
42
--
nosy: +eryksun
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23276
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3566] httplib persistent connections violate MUST in RFC2616 sec 8.1.4.
Martin Panter added the comment: Calling self.wfile.write(b) should be equivalent to not calling write() at all, as far as I understand. Using strace, it does not seem to invoke send() at all. So the result will depend on what is written next. In the case of my code, nothing is written next; the connection is shut down instead. So I don’t believe this case is any different from “a connection unexpectedly closed by the server”. To be clear, I think the situation we are talking about is: 1. Client connects to server and sends short request; server accepts connection and possibly reads request 2. Server does not write any response, or just calls write(b), which is equivalent 3. Server shuts down connection 4. Client reads end of stream (b) instead of proper status line But to address your concern in any case, see the third paragram in https://bugs.python.org/issue3566#msg234330. I propose some internal flag like HTTPConnection._initial_response, that gets set to False after the first proper response is received. Then the code could be changed to something like: if not line: # Presumably, the server closed the connection before # sending a valid response. if self._initial_response: raise BadStatusLine(line) else: raise ConnectionClosed(Stream ended before receiving response) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3566 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20702] warning in cmdline.rst
Berker Peksag added the comment: I couldn't reproduce it with Sphinx 1.2.3. The only warning I got was Doc/whatsnew/3.4.rst:2138: WARNING: undefined label: idle (if the link has no caption the label must precede a section header) -- nosy: +berker.peksag resolution: - out of date stage: - resolved status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20702 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3566] httplib persistent connections violate MUST in RFC2616 sec 8.1.4.
Robert Collins added the comment: FWIW, I agree with the analysis here, its standard HTTP behaviour in the real world, and we should indeed handle it. -- nosy: +rbcollins ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3566 ___ ___ 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: Updated the patch for 3.5. Currently, building fails with TypeError: init_builtin() takes exactly 1 argument (0 given) This is probably due to an argument counting bug, but I am not sure how to debug it. -- nosy: +neil.g Added file: http://bugs.python.org/file37779/starunpack3.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
[issue3566] httplib persistent connections violate MUST in RFC2616 sec 8.1.4.
Demian Brecht added the comment: Sorry Martin, I should really not dig into issues like this first thing in the morning ;) My concern about the proposed change isn't whether or not it isn't valid HTTP behaviour, it is. My concern (albeit a small one) is that the change implies an assumption that may not necessarily be true. No matter how valid based on the HTTP spec, it's still an assumption that /can/ potentially lead to confusion. I do agree that a change /should/ be made, I just want to make sure that all potential cases are considered before implementing one. For example, applying the following patch to the first attachment: 52,57c52,53 self.wfile.write( bHTTP/1.1 200 Dropping connection\r\n bContent-Length: 0\r\n b\r\n ) --- self.wfile.write(b'') Should the proposed change be made, the above would error out with a ConnectionClosed exception, which is invalid because the connection has not actually been closed and BadStatusLine is actually closer to being correct. Admittedly, this is a little contrived, doesn't adhere to the HTTP spec and is much less likely to happen in the real world than a connection unexpectedly closed by the server, but I don't think it's an unreasonable assumption for lesser used servers or proxies or those in development. In those cases, the proposed change would result in just as much confusion as the current behaviour with connections that are intended to be persistent. In my mind, the one constant through both of these cases is that the response that the client has read is unexpected. In light of that, rather than a ConnectionClosed error, what about UnexpectedResponse, inheriting from BadStatusLine for backwards compatibility and documented as possibly being raised as a result of either case? I think this would cover both cases where a socket has been closed as well as an altogether invalid response. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3566 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23278] multiprocessing maxtasksperchild=1 + logging = task loss
New submission from Nelson Minar: I have a demonstration of a problem where the combination of multiprocessing with maxtasksperchild=1 and the Python logging library causes tasks to occasionally get lost. The bug might be related to issue 22393 or issue 6721, but I'm not certain. issue 10037 and issue 9205 also might be relevant. I've attached sample code, it can also be found at https://gist.github.com/NelsonMinar/022794b6a709ea5b7682 My program uses Pool.imap_unordered() to execute 200 tasks. Each worker task writes a log message and sleeps a short time. The master process uses a timeout on next() to log a status message occasionally. When it works, 200 jobs are completed quickly. When it breaks, roughly 195 of 200 jobs will have completed and next() never raises StopIteration. If everything logs to logging.getLogger() and maxtasksperchild=1, it usually breaks. It appears that sometimes jobs just get lost and don't complete. We've observed that with maxtasksperchild=1 sometimes a new worker process gets created but no work assigned to it. When that happens the task queue never runs to completion. If we log straight to stderr or don't set maxtasksperchild, the run completes. The bug has been observed in Python 2.7.6 and Python 3.4.0 on Ubuntu 14.04 This is a distillation of much more complex application-specific code. Discussion of the bug and original code can be found at https://github.com/openaddresses/machine/issues/51 https://github.com/openaddresses/machine/blob/7c3d0fba8ba0915af2101ace45dfaf5519d5ad85/openaddr/jobs.py Thank you, Nelson -- components: Library (Lib) files: bug-demo.py messages: 234336 nosy: nelson priority: normal severity: normal status: open title: multiprocessing maxtasksperchild=1 + logging = task loss type: behavior versions: Python 2.7, Python 3.4 Added file: http://bugs.python.org/file37781/bug-demo.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23278 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23277] Cleanup unused and duplicate imports in tests
New submission from Jon Dufresne: Ran variations of the command: $ find . -wholename '*/test/*.py' | xargs flake8 --select=F401,F811 To look for unused or duplicate imports. The attached patch removes them. -- components: Tests files: cleanup-unused-imports.patch keywords: patch messages: 234334 nosy: jdufresne priority: normal severity: normal status: open title: Cleanup unused and duplicate imports in tests versions: Python 3.6 Added file: http://bugs.python.org/file37780/cleanup-unused-imports.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23277 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23255] SimpleHTTPRequestHandler refactor for more extensible usage.
Changes by Demian Brecht demianbre...@gmail.com: -- nosy: +demian.brecht ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23255 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17911] traceback: add a new thin class storing a traceback without storing local variables
Robert Collins added the comment: Stack and Frame looking good, next update will be next Monday, when I finish off my TracebackException class. -- Added file: http://bugs.python.org/file37782/issue17911-1.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17911 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23278] multiprocessing maxtasksperchild=1 + logging = task loss
Changes by Ned Deily n...@acm.org: -- nosy: +sbt, vinay.sajip stage: - needs patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23278 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20898] Missing 507 response description
Berker Peksag added the comment: Committed now, sorry about the delay. Thanks for the patch, Demian. -- resolution: - fixed stage: commit review - resolved status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20898 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23279] test_site/test_startup_imports fails when mpl_toolkit or logilab based modules installed
New submission from Douglas Rudd:
pth files for logilab (e.g. logilab_common, logilab_astng) and mpl_toolkit
(e.g. basemap, matplotlib) contain code like the following (taken from basemap
1.0.7):
import sys, types, os;p = os.path.join(sys._getframe(1).f_locals['sitedir'],
*('mpl_toolkits',));ie = os.path.exists(os.path.join(p,'__init__.py'));m = not
ie and sys.modules.setdefault('mpl_toolkits',
types.ModuleType('mpl_toolkits'));mp = (m or []) and
m.__dict__.setdefault('__path__',[]);(p not in mp) and mp.append(p)
This leads to the types module being loaded on import, which then causes
test_site/test_startup_imports to fail since types is in collection_mods:
collection_mods = {'_collections', 'collections', 'functools',
'heapq', 'itertools', 'keyword', 'operator',
'reprlib', 'types', 'weakref'
}.difference(sys.builtin_module_names)
self.assertFalse(modules.intersection(collection_mods), stderr)
$ python3.4 -c 'import sys; print(set(sys.modules))'
{'builtins', '_codecs', 'io', 'errno', 'abc', '_weakref', '_collections_abc',
'_bootlocale', 'stat', 'os', '_frozen_importlib', 'encodings.utf_8',
'_sitebuiltins', '_sysconfigdata', 'sysconfig', 'posixpath', 'sys',
'mpl_toolkits', '_weakrefset', 'encodings', 'encodings.aliases', 'signal',
'__main__', '_stat', 'zipimport', 'genericpath', 'site', '_io', 'posix',
'codecs', 'types', '_imp', 'os.path', '_warnings', 'marshal', '_locale',
'_thread', 'encodings.latin_1'}
This is a similar bug to http://bugs.python.org/issue20986
I don't know the purpose of this test well enough to propose a fix, but given
the number of exceptions already there it doesn't seem to be a robust test.
--
components: Tests
messages: 234345
nosy: drudd
priority: normal
severity: normal
status: open
title: test_site/test_startup_imports fails when mpl_toolkit or logilab based
modules installed
versions: Python 3.4
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23279
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22317] action argument is not documented in argparse add_subparser() docs
Roundup Robot added the comment: New changeset 350b8e109c42 by Berker Peksag in branch '3.4': Issue #22317: Document the action parameter in ArgumentParser.add_subparsers() docs. https://hg.python.org/cpython/rev/350b8e109c42 New changeset 4709290253e3 by Berker Peksag in branch 'default': Issue #22317: Document the action parameter in ArgumentParser.add_subparsers() docs. https://hg.python.org/cpython/rev/4709290253e3 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22317 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22317] action argument is not documented in argparse add_subparser() docs
Roundup Robot added the comment: New changeset 430236ef507b by Berker Peksag in branch '2.7': Issue #22317: Document the action parameter in ArgumentParser.add_subparsers() docs. https://hg.python.org/cpython/rev/430236ef507b -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22317 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22317] action argument is not documented in argparse add_subparser() docs
Berker Peksag added the comment: Thanks for the patch, Mike. Anne, thank you for the ticket triage! The only missing place was the ArgumentParser.add_subparsers() documentation: https://docs.python.org/3/library/argparse.html#argparse.ArgumentParser.add_subparsers -- nosy: +berker.peksag resolution: - fixed stage: needs patch - resolved status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22317 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20121] quopri_codec newline handling
Martin Panter added the comment: Here is patch v2, which fixes some more bugs I uncovered in the quoted-printable encoders: * The binascii version would unnecessarily break a 76-character line (maximum length) if it would end with an =XX escape code * The native Python version would insert soft line breaks in the middle of =XX escape codes -- type: - behavior Added file: http://bugs.python.org/file37783/quopri-newline.v2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20121 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2292] Missing *-unpacking generalizations
Chris Angelico added the comment: The third version of the patch is huge compared to the other two. Is it all important? I'm seeing a different build failure, and with the size of patch, I'm not sure I'm well placed to figure out what's going on. -- cut -- Traceback (most recent call last): File frozen importlib._bootstrap, line 2420, in _install File frozen importlib._bootstrap, line 2366, in _setup File frozen importlib._bootstrap, line 2329, in _builtin_from_name File frozen importlib._bootstrap, line 1144, in _load_unlocked File frozen importlib._bootstrap, line 1114, in _load_backward_compatible File frozen importlib._bootstrap, line 551, in _requires_builtin_wrapper File frozen importlib._bootstrap, line 1247, in load_module File frozen importlib._bootstrap, line 321, in _call_with_frames_removed TypeError: init_builtin() takes exactly 1 argument (0 given) Fatal Python error: Py_Initialize: importlib install failed Current thread 0x2b7f066c6b20 (most recent call first): Aborted generate-posix-vars failed -- cut -- -- ___ 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
[issue20898] Missing 507 response description
Demian Brecht added the comment: No worries, thanks for taking care of merging it Berker. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20898 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20898] Missing 507 response description
Roundup Robot added the comment: New changeset c8647dab4780 by Berker Peksag in branch 'default': Issue #20898: Add a HTTP status codes section to avoid duplication in HTTP docs. https://hg.python.org/cpython/rev/c8647dab4780 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20898 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3566] httplib persistent connections violate MUST in RFC2616 sec 8.1.4.
Demian Brecht added the comment: Calling self.wfile.write(b) should be equivalent to not calling write() at all, as far as I understand. Right (or at least, as I understand it as well). Really, this boils down to a philosophical debate: Should the standard library account for unexpected conditions where possible (within reason of course), or should it only account for conditions as described by specifications? 1. Client connects to server and sends short request; server accepts connection and possibly reads request [snip] This flow makes sense and is well accounted for with your proposed change. However, misbehaving cases such as: 1. Client connects to server or proxy (possibly through a tunnel) and sends request; server/proxy accepts connection and possibly reads request 2. Server/proxy intends to send a response, but doesn't for any number of reasons (bug, still in development, etc) 3. The connection is not closed and subsequent requests may succeed Granted, the result is unexpected and doesn't comply with HTTP RFCs. However, leading the user to believe that the connection has been closed when it actually hasn't is misleading. I've spent many an hour trying to hunt down root causes of issues like this and bashed my head against a keyboard in disbelief when I found out what the cause /really/ was. Because of those headaches, I still think that the introduction of an UnexpectedResponse, if well documented, covers both cases nicely, but won't heatedly argue it further :) If others (namely core devs) think that the introduction of ConnectionClosed exception is a better way to go, then I'll bow out. It would maybe be nice to have Senthil chime in on this. But to address your concern in any case, see the third paragram in https://bugs.python.org/issue3566#msg234330. I don't think that should be added at all as the issue that I'm describing can occur at any point, not only the first request. On another note, were you interested in submitting a patch for this? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3566 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23277] Cleanup unused and duplicate imports in tests
Berker Peksag added the comment: +1 for cleanup. -- nosy: +berker.peksag stage: - patch review versions: +Python 3.4, Python 3.5 -Python 3.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23277 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3566] httplib persistent connections violate MUST in RFC2616 sec 8.1.4.
Changes by Gregory P. Smith g...@krypto.org: -- nosy: -gregory.p.smith ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3566 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23281] Access violation - pyc file
New submission from Paweł Zduniak: (950.e58): Access violation - code c005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. *** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\Windows\SysWOW64\python27.dll - python27!PyEval_EvalFrameEx+0x1895: 1e0bcb45 8b74b00cmov esi,dword ptr [eax+esi*4+0Ch] ds:002b:0224207c= -- components: Windows files: test.pyc messages: 234357 nosy: Paweł.Zduniak, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Access violation - pyc file type: crash versions: Python 2.7 Added file: http://bugs.python.org/file37785/test.pyc ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23281 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23280] Convert binascii.{un}hexlify to Argument Clinic (fix docstrings)
Serhiy Storchaka added the comment: LGTM. -- stage: patch review - commit review ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23280 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3566] httplib persistent connections violate MUST in RFC2616 sec 8.1.4.
Martin Panter added the comment: Yeah I’m happy to put a patch together, once I have an idea of the details. I’d also like to understand your scenario that would mislead the user to believe that the connection has been closed when it actually hasn’t. Can you give a concrete example or demonstration? Given your misbehaving flow: 1. Client connects to server or proxy (possibly through a tunnel) and sends request; server/proxy accepts connection and possibly reads request 2. Server/proxy intends to send a response, but doesn't for any number of reasons (bug, still in development, etc) 3. The connection is not closed and subsequent requests may succeed I would expect the client would still be waiting to read the status line of the response that was never sent in step 2. Eventually the server _would_ probably drop the connection (so ConnectionClosed would not be misleading), or the client would time it out (a different error would be raised). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3566 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3566] httplib persistent connections violate MUST in RFC2616 sec 8.1.4.
R. David Murray added the comment: I think that in other stdlib networking modules, a connection closed error is raised when an operation is attempted on a closed connection. For example, in smtplib, the server may return an error code and then (contrary to the RFC) close the connection. We fixed a bug in smtplib where this was mishandled (the error code was lost and SMTPServerDisconnected was raised instead). Now we return the error code, and the *next* operation on the connection gets the connection closed error. I think this is a good model, but I'm not sure if/how it can be applied here. That is, if the connection has been closed, I think an operation attempted on the connection should raise an exception that makes it clear that the connection is closed (in the case of some stdlib modules, that may be a socket level exception for the operation on the closed socket). I think the remote server writing a blank line to the socket is a very different thing from the remote server closing the connection without writing anything, so I may be misunderstanding something here. Note that handling this is potentially more complicated with https, since in that case we have a wrapper around the socket communication that has some buffering involved. But also note that if a new exception is introduced this becomes a feature and by our normal policies can only go into 3.5. -- versions: +Python 3.4, Python 3.5 -Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3566 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23280] Convert binascii.{un}hexlify to Argument Clinic (fix docstrings)
New submission from Zachary Ware:
The Argument Clinic conversion of the binascii module left hexlify and
unhexlify with bad docstrings:
hexlify(...)
b2a_hex($module, data, /)
--
Hexadecimal representation of binary data.
The return value is a bytes object. This function is also
available as hexlify().
unhexlify(...)
a2b_hex($module, hexstr, /)
--
Binary data of hexadecimal representation.
hexstr must contain an even number of hex digits (upper or lower case).
This function is also available as unhexlify().
Attached patch fixes it, removes the note that the function is also available
as itself (leaving the note on {a2b,b2a}_hex), and tests that the functions are
in fact aliases.
--
components: Extension Modules
files: binascii_clinic_fix.diff
keywords: patch
messages: 234353
nosy: serhiy.storchaka, zach.ware
priority: normal
severity: normal
stage: patch review
status: open
title: Convert binascii.{un}hexlify to Argument Clinic (fix docstrings)
type: behavior
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file37784/binascii_clinic_fix.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23280
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20898] Missing 507 response description
Martin Panter added the comment: Just noticed the new documentation says “http.HTTPStatus.OK is also available as . . . http.server.OK”. I think this is wrong; only the client module (and now the top-level package) have those constants. The enum values are only available in the server module via http.server.BaseHTTPRequestHandler.responses.keys() as far as I can tell. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20898 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20898] Missing 507 response description
Roundup Robot added the comment: New changeset 3a95a74aca4e by Berker Peksag in branch 'default': Issue #20898: Enum names are only available in the http.client module as constants. https://hg.python.org/cpython/rev/3a95a74aca4e -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20898 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20898] Missing 507 response description
Berker Peksag added the comment: Good catch, thank you Martin. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20898 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23276] hackcheck is broken in association with __setattr__
New submission from Alfred Krohmer: The following code: import traceback import sys from PyQt5.QtCore import Qt class MetaA(type): pass class A(metaclass=MetaA): pass class MetaB(type): pass class B(metaclass=MetaB): pass for ClassB in B, Qt: print(Trying class %s % (ClassB.__name__, )) class MyMeta(type(A), type(ClassB)): def __setattr__(cls, key, value): print(cls) super(type, cls).__setattr__(key, value) class MyClass(A, ClassB, metaclass=MyMeta): pass try: setattr(MyClass, 'abc', 123) except: traceback.print_exc(file=sys.stdout) try: type.__setattr__(MyClass, 'test', 42) except: traceback.print_exc(file=sys.stdout) Fails with the following output: Trying class B class '__main__.MyClass' Traceback (most recent call last): File test3.py, line 31, in module setattr(MyClass, 'abc', 123) File test3.py, line 25, in __setattr__ super(type, cls).__setattr__(key, value) TypeError: can't apply this __setattr__ to type object Trying class Qt class '__main__.MyClass' Traceback (most recent call last): File test3.py, line 31, in module setattr(MyClass, 'abc', 123) File test3.py, line 25, in __setattr__ super(type, cls).__setattr__(key, value) TypeError: can't apply this __setattr__ to sip.wrappertype object Traceback (most recent call last): File test3.py, line 36, in module type.__setattr__(MyClass, 'test', 42) TypeError: can't apply this __setattr__ to sip.wrappertype object The metaclass of a class should be able to update its class' __dict__ my calling super(type, cls).__setattr__ (there is no other way known to me to do this). Furthermore, if subclassing an external class, like Qt, it should be possible to use type.__setattr__(MyClass, ...) externally to change the class' attributes. The error is caused by the hackcheck function in objects/typeobject.c. -- components: Interpreter Core, Library (Lib) messages: 234329 nosy: devkid priority: normal severity: normal status: open title: hackcheck is broken in association with __setattr__ type: behavior versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23276 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23271] Unicode HOWTO documentation error
Eric V. Smith added the comment: The example is correct. If you type it into a python interpreter, you get the results as shown in the example. The .replace() method does not modify the string s. It returns the new value. In the example, the new value is displayed, but is not assigned back to s, so s does not change. -- nosy: +eric.smith resolution: - not a bug stage: - resolved status: open - closed type: enhancement - ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23271 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23271] Unicode HOWTO documentation error
New submission from Dionysis Zindros:
In the Unicode HOTWO documentation for Python 2.x [0], there's an error in the
fourth code sample under the section The Unicode Type.
The code states:
```
s = u'Was ever feather so lightly blown to and fro as this multitude?'
s.count('e')
5
s.find('feather')
9
s.find('bird')
-1
s.replace('feather', 'sand')
u'Was ever sand so lightly blown to and fro as this multitude?'
s.upper()
u'WAS EVER FEATHER SO LIGHTLY BLOWN TO AND FRO AS THIS MULTITUDE?'
```
Notice that in the last line, sand was turned back into feather. The
correct last line should have been:
```
u'WAS EVER SAND SO LIGHTLY BLOWN TO AND FRO AS THIS MULTITUDE?'
```
[0] https://docs.python.org/2/howto/unicode.html
--
assignee: docs@python
components: Documentation
messages: 234312
nosy: Dionysis.Zindros, docs@python
priority: normal
severity: normal
status: open
title: Unicode HOWTO documentation error
type: enhancement
versions: Python 2.7
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23271
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23272] Python built-in comparison problem
Changes by Lukáš Němec lu.ne...@gmail.com: -- nosy: Lukáš.Němec priority: normal severity: normal status: open title: Python built-in comparison problem ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23272 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23272] Python built-in comparison problem
Changes by Lukáš Němec lu.ne...@gmail.com: -- resolution: - not a bug status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23272 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7665] test_urllib2 and test_ntpath fail if path contains \
Senthil Kumaran added the comment: I reviewed the patch Serhiy. It looks good to me, You can go ahead and commit. Thanks! -- assignee: orsenthil - serhiy.storchaka ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7665 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23269] Tighten-up search loops in sets
New submission from Raymond Hettinger: First draft of patch to switch from a table[(i+j)mask] style of entry calculation to an entry++ style. The entry computation simplifies from add/shl4/and/lea to a single add16. To do this, the linear probes are limited to the length of table rather than wrapping-around. I haven't timed this one yet (have just looked at the assembly) or worked through the implications. The new approach is a little less attractive but may be easier to reason about than the mask wrap-around. Also, it disadvantages small sets where the wrap-around property assured that the linear probes would always fine a hit without any entry being checked more than once. There is a extra setup time before the linear probes to compute the limit. Also, since the loop size is now variable instead of fixed, the inner loop for set_insert_clean() no longer gets unrolled by either GCC or CLANG. With the change, the inner loop of set_insert_clean() is very tight: L436: addq$16, %rax #, entry entry limit cmpq%rdx, %rax # limit, entry ja L399#, entry-key == NULL cmpq$0, (%rax) #,* entry jne L436 The code for lookkey() is also tight (though I can't tell why the entry-key gets loaded from memory twice): L102: cmpq%r15, %r13 # tmp170, D.12706 entry-key == dummy jne L103#, testq %r12, %r12 # freeslot cmove %r14, %r12 # entry - freeslot L103: addq$16, %r14 #, entryentry++ cmpq%r14, %rbx # entry, limit jb L146#, movq(%r14), %r13# MEM[base: entry_65, offset: 0B], D.12706 testq %r13, %r13 # D.12706 entry-key == NULL je L147#, cmpq%rbp, 8(%r14) # hash, MEM[base: entry_104, offset: 8B] je L148#, entry-hash == hash ? movq(%r14), %r13# MEM[base: entry_104, offset: 0B], D.12706 jmp L102# -- assignee: rhettinger components: Interpreter Core files: limit.diff keywords: patch messages: 234308 nosy: rhettinger priority: low severity: normal stage: patch review status: open title: Tighten-up search loops in sets type: performance versions: Python 3.5 Added file: http://bugs.python.org/file37773/limit.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23269 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23269] Tighten-up search loops in sets
Changes by Serhiy Storchaka storch...@gmail.com: -- nosy: +pitrou, serhiy.storchaka ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23269 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23228] Crashes when tarfile contains a symlink and unpack directory contain it too
Michael Vogt added the comment: Thanks SilentGhost for your feedback and sorry for my slow reply. I looked into this some more and attached a updated patch with a more complete test. It also covers a crash now that happens when there is a symlink cycle in the tar and on disk. My fix is to remove existing links before unpack and replace them with the link in the tar. This is what gnu tar is also doing (according to http://www.gnu.org/software/tar/manual/html_node/Dealing-with-Old-Files.html). However this seems to be a behavior change of what the tarfile module has traditionally been done so feel free to reject it, I'm open to alternative ideas of course (even though I feel like having the same behavior as gnu tar is desirable). Thanks, Michael -- Added file: http://bugs.python.org/file37774/possible-fix-23228-with-test2.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23228 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23270] Use the new __builtin_mul_overflow() of Clang and GCC 5 to check for integer overflow
New submission from STINNER Victor:
In CPython, almost all memory allocations are protected against integer
overflow with code looking like that:
if (length ((PY_SSIZE_T_MAX - struct_size) / char_size - 1)) {
PyErr_NoMemory();
return NULL;
}
new_size = (struct_size + (length + 1) * char_size);
For performances, GCC 5 introduces __builtin_mul_overflow() which is an integer
multiplication with overflow check. On x86/x86_64, it is implemented in
hardware (assembler instruction JO, jump if overflow, if I remember correctly).
The function already exists in Clang: ... which existed in Clang/LLVM for a
while says http://lwn.net/Articles/623368/ According to this mail sent to the
Linux kernel mailing list, the Linux kernel has functions like
check_mul_overflow(X, Y, C).
For other compilers, it should be easy to reimplement it, but I don't know what
is the most efficient implementation (Py_LOCAL_INLINE function in an header?)
GCC 5 changelog:
https://gcc.gnu.org/gcc-5/changes.html
Note: GCC 5 is not released yet.
--
messages: 234310
nosy: haypo
priority: normal
severity: normal
status: open
title: Use the new __builtin_mul_overflow() of Clang and GCC 5 to check for
integer overflow
versions: Python 3.5
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23270
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23217] help() function incorrectly captures comment preceding a nested function
anupama srinivas murthy added the comment: In Python 2.7, the capture happens even if there is no decorator. The code: #Hey this is f def f(): return help(f) gives the output: Help on function f in module __main__: f() #Hey this is f whereas a docstring inside the function causes the comment to be ignored. Therefore, the code: #Hey this is f def f(): '''this is the function f''' return help(f) gives the output: Help on function f in module __main__: f() this is the function f @Gwenllina:I need to clarify my previous comment. The docstring that would cause the preceding comment to be ignored must be in the inner function in case of the first example. Placing it in f() still causes comment capture as you said -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23217 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23270] Use the new __builtin_mul_overflow() of Clang and GCC 5 to check for integer overflow
Changes by STINNER Victor victor.stin...@gmail.com: -- components: +Interpreter Core nosy: +serhiy.storchaka type: - performance ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23270 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3566] httplib persistent connections violate MUST in RFC2616 sec 8.1.4.
Demian Brecht added the comment: I'm not sure whether or not this was your intention, but your example demonstrates a misbehaving client, one that seems to expect a persistent connection from a non-persistent server. TCPServer will only serve a single request and will shutdown and close the socket once the response has been written. Sorry, I mis-worded that. I'm /assuming/ that the misbehaving client is what you were intending on demonstrating as it shows the server closing the connection before the client expects it to do so. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3566 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23199] libpython27.a in amd64 release is 32-bit
Zach Welch added the comment: Yes, pe-i386 and pe-x86-64 are the respective 32-bit and 64-bit object formats. Your commands seem reasonable. With gendef, I just let it create a .def file with the same name (i.e. skip the '-' and redirection); in my mind, that reinforces the association between the dll and def files. With dlltool, I did not have to use the -m flag (as x86-64 is the default for me), but I don't see anything wrong with being explicit. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23199 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1103213] Adding the missing socket.recvall() method
Changes by Jean-Paul Calderone jean-p...@hybridcluster.com: -- nosy: -exarkun ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1103213 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3566] httplib persistent connections violate MUST in RFC2616 sec 8.1.4.
Demian Brecht added the comment: Hi Martin, Thanks for the example code. I'm not sure whether or not this was your intention, but your example demonstrates a misbehaving client, one that seems to expect a persistent connection from a non-persistent server. TCPServer will only serve a single request and will shutdown and close the socket once the response has been written. The reason that you're seeing different responses sometimes (varying between BadStatusLine and BrokenPipeError) is because of an understandable race condition between the client sending the requests and the server fully shutting down the socket and the client receiving FIN. After digging into this, I'm not sure that there is a better way of handling this case. This exception can occur whether the client has issued a request prior to cleaning up and is expecting a response, or the server is simply misbehaving and sends an invalid status line (i.e. change your response code to an empty string to see what I mean). I'll do some further digging, but I don't believe that there's really a good way to determine whether the BadStatusLine is due to a misbehaving server (sending a non-conforming response) or a closed socket. Considering that the client potentially has no way of knowing whether or not a server socket has been closed (in the case of TCPServer, it does a SHUT_WR), I think that BadStatusLine may be the appropriate exception to use here and the resulting action would have to be left up to the client implementation, such as in xmlrpc.client. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3566 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14218] include rendered output in addition to markup
Changes by Berker Peksag berker.pek...@gmail.com: -- keywords: +easy ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14218 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23275] Can assign [] = (), but not () = []
Changes by Cesar Kawakami cesarkawak...@gmail.com: -- nosy: +Cesar.Kawakami ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23275 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23275] Can assign [] = (), but not () = []
R. David Murray added the comment: My guess is that it is not worth complicating the parser in order to make these two cases consistent, and it should be treated as a doc error. We'll see what other developers think. -- nosy: +r.david.murray ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23275 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23273] traceback: formatting a traceback stats the filesystem
New submission from Robert Collins: Discovered in issue 17911, all the traceback calls that render a stack trace end up calling linecache.checkcache, which stats files on disk, making getting a traceback rather more expensive than folk may expect. For oops, it crashed situations thats fine, but when used to gather diagnostic details like tulip does, it becomes substantially more wasteful. Since we know when we've reloaded a module, there should be no need to go out to disk at any other time - particularly since if we *haven't* reloaded the module, doing so will just end up showing the wrong source. Further, PEP 302 source code isn't refreshed when the cache is checked, which can lead to stale code in modules that *have* been reloaded. -- messages: 234318 nosy: rbcollins priority: normal severity: normal status: open title: traceback: formatting a traceback stats the filesystem ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23273 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17911] traceback: add a new thin class storing a traceback without storing local variables
Robert Collins added the comment: I've split out the stat question to http://bugs.python.org/issue23273 - we can optimise it slightly in this patch, but I think its scope creep here, and will be unclear, to dive after a full fix in this issue. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17911 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23274] make_ssl_data.py in Python 2.7.9 needs Python 3 to run
New submission from Michael Schlenker: The make_ssl_data.py script in Tools/ssl/ needs a python3 to run due to the usage of open(..., encoding='latin1'). This makes usage on a host without python3 installed more complex than needed. It should use io.open(...) to run on both python3 and python2. -- components: Demos and Tools messages: 234320 nosy: schlenk priority: normal severity: normal status: open title: make_ssl_data.py in Python 2.7.9 needs Python 3 to run type: enhancement ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23274 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23274] make_ssl_data.py in Python 2.7.9 needs Python 3 to run
Antoine Pitrou added the comment: That shouldn't be very important. The already-generated _ssl_data.h in the distribution should be enough. -- nosy: +alex, pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23274 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23274] make_ssl_data.py in Python 2.7.9 needs Python 3 to run
Antoine Pitrou added the comment: Yesterday I've regenerated _ssl_data.h with the latest OpenSSL git, so that should suit you. Be sure to update your hg clone of Python. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23274 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23274] make_ssl_data.py in Python 2.7.9 needs Python 3 to run
Michael Schlenker added the comment: yes, priority is probably low. Just stumbled over it when building against openssl 1.0.1L and trying to regen the datafile automatically in a build script. -- versions: +Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23274 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23275] Can assign [] = (), but not () = []
New submission from Devin Jeanpierre: [] = () () = [] File stdin, line 1 SyntaxError: can't assign to () This contradicts the assignment grammar, which would make both illegal: https://docs.python.org/3/reference/simple_stmts.html#assignment-statements -- components: Interpreter Core messages: 234324 nosy: Devin Jeanpierre priority: normal severity: normal status: open title: Can assign [] = (), but not () = [] type: behavior ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23275 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23275] Can assign [] = (), but not () = []
Raymond Hettinger added the comment: The starting point is recognizing that this has been around for very long time and is harmless. -- nosy: +rhettinger ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23275 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23269] Tighten-up search loops in sets
Changes by Raymond Hettinger raymond.hettin...@gmail.com: Added file: http://bugs.python.org/file3/measure_build_set.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23269 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23269] Tighten-up search loops in sets
Changes by Raymond Hettinger raymond.hettin...@gmail.com: Added file: http://bugs.python.org/file37776/limit2.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23269 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23269] Tighten-up search loops in sets
Raymond Hettinger added the comment: Patch timings give inconsistent results. GCC-4.9 generates faster code and CLang generates slower code :-( -- Added file: http://bugs.python.org/file37775/timings.txt ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23269 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23269] Tighten-up search loops in sets
Antoine Pitrou added the comment: Either way the improvement doesn't look terrific, so I would suggest not to bother with this. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23269 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
