[issue7503] multiprocessing AuthenticationError "digest sent was rejected" when pickling proxy

Pete Hunt added the comment: UPDATE: this example WORKS if you remove "authkey" - so it seems to be a problem with authentication. -- type: -> crash ___ Python tracker ___

[issue6472] Inconsistent use of "iterator" in ElementTree doc & diff between Py and C modules

flox added the comment: Small update of the patch for 3.2: the __cmp__method is replaced with __eq__ method (on CommentProxy and PIProxy). -- Added file: http://bugs.python.org/file15552/issue6472_upstream_py3k_v2.diff ___ Python tracker

[issue6472] Inconsistent use of "iterator" in ElementTree doc & diff between Py and C modules

Changes by flox : Removed file: http://bugs.python.org/file15471/issue6472_upstream_py3k.diff ___ Python tracker ___ ___ Python-bugs-list maili

[issue6472] Inconsistent use of "iterator" in ElementTree doc & diff between Py and C modules

Changes by flox : Removed file: http://bugs.python.org/file15513/issue6472_upstream_docs.diff ___ Python tracker ___ ___ Python-bugs-list maili

[issue6472] Inconsistent use of "iterator" in ElementTree doc & diff between Py and C modules

Changes by flox : Added file: http://bugs.python.org/file15553/issue6472_upstream_docs.diff ___ Python tracker ___ ___ Python-bugs-list mailing

[issue1975] signals not always delivered to main thread, since other threads have the signal unmasked

Changes by Laszlo (Laca) Peter : -- nosy: +laca ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pyth

[issue7475] codecs missing: base64 bz2 hex zlib ...

Marc-Andre Lemburg added the comment: Martin v. Löwis wrote: > > Martin v. Löwis added the comment: > >> So, after reading the above comments, I think we may end up with >> following changes: >> * restore the "bytes-to-bytes" codecs in the "encodings" package +1 >> * then create new helpe

[issue7503] multiprocessing AuthenticationError "digest sent was rejected" when pickling proxy

Changes by R. David Murray : -- nosy: +jnoller ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pytho

[issue7503] multiprocessing AuthenticationError "digest sent was rejected" when pickling proxy

Changes by R. David Murray : -- priority: -> normal type: crash -> behavior ___ Python tracker ___ ___ Python-bugs-list mailing list U

[issue7504] Same name cookies

New submission from Andrey Chichak : After setting cookies with same name and different path only nearest to root cookie is available. Attached patch: 1. Set Cookie to nearest value. 2. Collects all same name values in Cookie._multi[''] in order. -- components: Library (Lib) files: Co

[issue4757] reject unicode in zlib

flox added the comment: Definitely, zlib.compress should raise a TypeError (like bz2 does). >>> import bz2, zlib >>> bz2.compress('abc') Traceback (most recent call last): File "", line 1, in TypeError: argument 1 must be bytes or buffer, not str >>> zlib.compress('abc') b"x\x9cKLJ\x06\x00\x

[issue2259] Poor support other than 44.1khz, 16bit audio files?

Changes by R. David Murray : -- assignee: r.david.murray -> ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: htt

[issue1975] signals not always delivered to main thread, since other threads have the signal unmasked

Antoine Pitrou added the comment: I'm not sure there's any real issue here. The signal *does* get propagated to the main thread, it only takes some time to do so. If you want the program to be interruptible more quickly, just lower the timeout you give to select(). -- _

[issue4757] reject unicode in zlib

Antoine Pitrou added the comment: The patch lacks a test that TypeError is raised on unicode input, otherwise it's fine. -- ___ Python tracker ___ ___

[issue1975] signals not always delivered to main thread, since other threads have the signal unmasked

Jean-Paul Calderone added the comment: I don't like the suggestion to lower the timeout to select(). Lots of the rest of the world is pushing towards removing this kind of periodic polling (generally with the goal of improving power consumption). Python should be going this way too (the recent

[issue1975] signals not always delivered to main thread, since other threads have the signal unmasked

Antoine Pitrou added the comment: > I don't like the suggestion to lower the timeout to select(). Lots of > the rest of the world is pushing towards removing this kind of periodic > polling (generally with the goal of improving power consumption). Yes, I'm aware of this. I was only suggesting

[issue1680159] Misleading exception from unicode.__contains__

R. David Murray added the comment: Committed in r76831. (I changed the test assertion to check specifically for UnicodeDecodeError.) -- ___ Python tracker ___ ___

[issue4757] reject unicode in zlib

flox added the comment: Patch from haypo updated for r76830 . Additional tests for TypeError, and to check that bytearray objects are accepted. -- Added file: http://bugs.python.org/file1/issue4757_zlib_bytes.diff ___ Python tracker

[issue4757] reject unicode in zlib

Antoine Pitrou added the comment: The patch produces a number of errors in test_tarfile, test_distutils, test_gzip and test_xmlrpc. -- ___ Python tracker ___

[issue4757] reject unicode in zlib

flox added the comment: Fixed. And some "bytearray" tests improved in test_zlib. -- Added file: http://bugs.python.org/file15556/issue4757_zlib_bytes_v2.diff ___ Python tracker

[issue7505] ctypes not converting None to Null in 64-bit system

New submission from Venkateswaran : The attached code is failing to convert None to Null. It is successful if the int* is shifted towards the beginning of argument list. The bug is actually in 32/64 bit pointers as the code works on a 32 bit system. The bug disappears if I reduce the number of

[issue4757] reject unicode in zlib

Changes by Antoine Pitrou : -- assignee: -> pitrou resolution: -> accepted ___ Python tracker ___ ___ Python-bugs-list mailing list U

[issue1975] signals not always delivered to main thread, since other threads have the signal unmasked

Adam Olsen added the comment: The real, OS signal does not get propagated to the main thread. Only the python-level signal handler runs from the main thread. Correctly written programs are supposed to let select block indefinitely. This allows them to have exactly 0 CPU usage, especially impo

[issue7119] email: msg.items() returns different values before and after msg.as_string()

R. David Murray added the comment: Here's a doc patch. -- keywords: +patch stage: needs patch -> patch review Added file: http://bugs.python.org/file15558/email_generate_mutates_message_docfix.patch ___ Python tracker

[issue1680159] Misleading exception from unicode.__contains__

Changes by R. David Murray : -- resolution: -> fixed stage: commit review -> committed/rejected status: open -> closed versions: -Python 2.6 ___ Python tracker ___ __

[issue1975] signals not always delivered to main thread, since other threads have the signal unmasked

Antoine Pitrou added the comment: > The real, OS signal does not get propagated to the main thread. Only > the python-level signal handler runs from the main thread. Well, the signals /are/ delivered as far as Python code is concerned. I don't think Python makes any promise as to the delivery

[issue4757] reject unicode in zlib

Antoine Pitrou added the comment: The patch was committed to py3k and 3.1. Thank you! -- resolution: accepted -> fixed status: open -> closed ___ Python tracker ___ _

[issue1975] signals not always delivered to main thread, since other threads have the signal unmasked

Adam Olsen added the comment: You forget that the original report is about ctrl-C. Should we abandon support of it for threaded programs? Close as won't-fix? We could also just block SIGINT, but why? That means we don't support python signal handlers in threaded programs (signals sent to the

[issue1975] signals not always delivered to main thread, since other threads have the signal unmasked

Antoine Pitrou added the comment: > You forget that the original report is about ctrl-C. Should we abandon > support of it for threaded programs? We haven't abandoned support, have we? Where is the spec that is currently broken? Besides, as Jean-Paul pointed out, the user can now setup a file

[issue7506] multiprocessing.managers.BaseManager.__reduce__ references BaseManager.from_address

New submission from Pete Hunt : BaseManager.__reduce__ references from_address, which, to my knowledge, has been eliminated from the package. -- components: Library (Lib) messages: 96392 nosy: peterhunt severity: normal status: open title: multiprocessing.managers.BaseManager.__reduce__

[issue1975] signals not always delivered to main thread, since other threads have the signal unmasked

John Levon added the comment: The spec broken is here: http://docs.python.org/library/signal.html Namely: # Some care must be taken if both signals and threads are used in the same program. The fundamental thing to remember in using signals and threads simultaneously is: always perform signal

[issue4770] binascii module, crazy error messages, unexpected behavior

flox added the comment: I agree, we need consistency between all functions of this package. I've run a small script to check what happens for all 16 functions of the binascii package when they receive unicode input... See attached script (and sample output). IMHO 4 functions should be fixed t

[issue1975] signals not always delivered to main thread, since other threads have the signal unmasked

Antoine Pitrou added the comment: > The spec broken is here: > > http://docs.python.org/library/signal.html I would argue it is not broken. This documentation page is about a module of the standard library, it doesn't specify the underlying C implementation. That "the main thread will be the o

[issue4757] reject unicode in zlib

Changes by flox : Removed file: http://bugs.python.org/file1/issue4757_zlib_bytes.diff ___ Python tracker ___ ___ Python-bugs-list mailing

[issue1975] signals not always delivered to main thread, since other threads have the signal unmasked

Marcin Stepnicki added the comment: > I don't have any strong view over whether the interpreter should, > theoretically, block signals in non-main threads. But, practically, > blocking signals apparently produced issues with readline (and possibly > other libs relying on signals), which is why t

[issue1975] signals not always delivered to main thread, since other threads have the signal unmasked

Changes by Antoine Pitrou : -- assignee: -> georg.brandl components: +Documentation nosy: +georg.brandl versions: +Python 3.2 -Python 2.4, Python 2.5, Python 3.0 ___ Python tracker _

[issue1975] signals not always delivered to main thread, since other threads have the signal unmasked

Jean-Paul Calderone added the comment: > > http://docs.python.org/library/signal.html > I would argue it is not broken. If it's not broken, then the docs are at least confusing. They should make clear whether they are talking about the underlying signal or the Python signal handler. This mak

[issue7506] multiprocessing.managers.BaseManager.__reduce__ references BaseManager.from_address

R. David Murray added the comment: See also issue 5862 and issue 3518. One or more of these three tickets could possibly be closed as duplicates. -- assignee: -> jnoller keywords: +easy nosy: +jnoller, r.david.murray priority: -> normal stage: -> needs patch ___

[issue7506] multiprocessing.managers.BaseManager.__reduce__ references BaseManager.from_address

Changes by R. David Murray : -- versions: +Python 2.7, Python 3.1, Python 3.2 ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue4770] binascii module, crazy error messages, unexpected behavior

flox added the comment: This patch removes implicit encoding in binascii functions: - a2b_hex (=unhexlify) - a2b_qp - rledecode_hqx * Tests module "test_binascii" is reviewed and simplified. * Fixes for "email", "pickle" and "quopri" modules to encode input. All tests pass. -- k

[issue6560] socket sendmsg(), recvmsg() methods

David Watson added the comment: Hi, I'm afraid there may have been some duplication of effort here - I set about reworking Heiko Wundram's original patch (issue #1194378) without knowing about this one. I don't have unit tests yet either, but I saw this and thought I'd better post what I had.

[issue4770] binascii module, crazy error messages, unexpected behavior

Marc-Andre Lemburg added the comment: flox wrote: > > flox added the comment: > > This patch removes implicit encoding in binascii functions: > - a2b_hex (=unhexlify) > - a2b_qp > - rledecode_hqx > > * Tests module "test_binascii" is reviewed and simplified. > * Fixes for "email", "pic

[issue4770] binascii module, crazy error messages, unexpected behavior

flox added the comment: > Are you sure that this patch is correct (which RFC says > that quoted printable should use our raw-unicode-escape > codec ?): I am not sure of anything. It is an "educated guess" at the most. Since 'base64' and 'x-uuencode' both use 'raw-unicode-escape'... See longer

[issue4770] binascii module, crazy error messages, unexpected behavior

Marc-Andre Lemburg added the comment: flox wrote: > > flox added the comment: > >> Are you sure that this patch is correct (which RFC says >> that quoted printable should use our raw-unicode-escape >> codec ?): > > I am not sure of anything. It is an "educated guess" at the most. > Since 'ba

[issue4770] binascii module, crazy error messages, unexpected behavior

Antoine Pitrou added the comment: I agree with Marc-André that enforcing ASCII looks like the only sensible solution. Perhaps Barry knows the purpose of using "raw-unicode-escape" here, though? -- nosy: +barry, pitrou ___ Python tracker

[issue7507] pipes.quote does not correctly escape !

New submission from Ben Gertzfield : The undocumented (but unit tested!) pipes.quote does not correctly escape '!', which cannot be passed to the shell outside of single- quotes: sh-3.2$ python Python 2.6.1 (r261:67515, Jul 7 2009, 23:51:51) [GCC 4.2.1 (Apple Inc. build 5646)] on darwin Type

[issue1975] signals not always delivered to main thread, since other threads have the signal unmasked

Antoine Pitrou added the comment: As I said, a flexible solution would be for thread creation functions to take an optional argument specifying whether to block signals or not. (I don't mind the default value of the argument :-)) -- ___ Python tracke

[issue4770] binascii module, crazy error messages, unexpected behavior

Marc-Andre Lemburg added the comment: The email interface ate part of the code snippet. Here's the complete version: >>> import base64 >>> base64.b64decode('äöü'.encode('raw-unicode-escape')) b'' >>> base64.b64decode('äöü'.encode('ascii')) Traceback (most recent call last): File "", line 1, i

[issue7502] All DocTestCase instances compare and hash equal to each other

Antoine Pitrou added the comment: There doesn't seem to be an __eq__ or __cmp__ method in DocTestCase, which implies that the issue is with unittest.TestCase (from which DocTestCase inherits). -- nosy: +michael.foord, pitrou priority: -> normal stage: -> needs patch versions: +Python

[issue7471] GZipFile.readline too slow

Antoine Pitrou added the comment: Ah, a patch. Now we're talking :) -- resolution: wont fix -> stage: -> patch review status: closed -> open versions: +Python 2.7, Python 3.2 -Python 2.6 ___ Python tracker __

[issue7502] All DocTestCase instances compare and hash equal to each other

Jean-Paul Calderone added the comment: Or an interaction between TestCase and DocTestCase. TestCase.__eq__ and TestCase.__hash__ are both implemented in terms of the _testMethodName attribute. It looks like this is *always* "runTest" for a DocTestCase instance. It probably doesn't make sense

[issue7502] All DocTestCase instances compare and hash equal to each other

Michael Foord added the comment: Agreed, defining __eq__ and __hash__ on DocTestCase sounds like the way to go. -- ___ Python tracker ___

[issue7471] GZipFile.readline too slow

Antoine Pitrou added the comment: The patch doesn't apply against the SVN trunk (some parts are rejected). I suppose it was done against 2.6 or earlier, but those versions are in bug fixing-only mode (which excludes performance improvements), so you'll have to regenerate it against the SVN trunk

[issue7471] GZipFile.readline too slow

Antoine Pitrou added the comment: Ah, my bad, I hadn't seen that the patch is for 3.2. Sorry for the confusion. -- ___ Python tracker ___

[issue4770] binascii module, crazy error messages, unexpected behavior

flox added the comment: I perform a "grep" on the email package (with patch applied). There's some places where 'raw-unicode-escape' is used. I understand that all "payload.encode('raw-unicode-escape')" should be changed to "payload.encode('ascii')" when the payload is processed by another tran

[issue1975] signals not always delivered to main thread, since other threads have the signal unmasked

Adam Olsen added the comment: A better solution would be to block all signals by default, then unblock specific ones you expect. This avoids races (as undeliverable signals are simply deferred.) Note that readline is not threadsafe anyway, so it doesn't necessarily need to allow calls from the

[issue7471] GZipFile.readline too slow

Antoine Pitrou added the comment: I confirm that the patch gives good speedups. It would be nice if there was a comment explaining what extrabuf, extrastart and extrasize are. In 3.x, a better but more involved approached would be to rewrite the gzip module so as to take advantage of the standa

[issue7498] test_multiprocessing test_rapid_restart fails if port 9999 already in use

R. David Murray added the comment: Committed in r76840 on trunk, r76842 for 2.6, r76843 for py3k, and r76844 for 3.1. -- resolution: -> fixed stage: patch review -> committed/rejected ___ Python tracker __

[issue4770] binascii module, crazy error messages, unexpected behavior

flox added the comment: Patch updated: * Added documentation * Switched to "payload.encode('ascii')" in the "email.message" module Note: there was no ambiguity on the first line of the documentation: « [These functions] convert between binary and various ASCII-encoded binary representations »

[issue4770] binascii module, crazy error messages, unexpected behavior

Changes by flox : Removed file: http://bugs.python.org/file15562/issue4770_binascii_py3k_v2.diff ___ Python tracker ___ ___ Python-bugs-list ma

[issue4770] binascii module, crazy error messages, unexpected behavior

Changes by flox : Added file: http://bugs.python.org/file15563/issue4770_binascii_py3k_v2.diff ___ Python tracker ___ ___ Python-bugs-list mail

[issue7508] Update 'file object' doc

New submission from Terry J. Reedy : "5.9. File Objects¶ File objects are implemented using C’s stdio package and can be created with the built-in open() function." As I understand, the part about stdio is no longer true. Also, as I understand, there is no longer a class object. Rather there ar

[issue7509] AttributeError: MSVCCompiler instance has no attribute '_MSVCCompiler__root'

New submission from Sridhar Ratnakumar : This error happened while installing pycrypto 2.0.1 on XP 64-bit with VS 2008 express installed using Python 2.6.4 64-bit (via buildout). Getting distribution for 'pycrypto>=1.9'. Traceback (most recent call last): File "", line 1, in File "build\bd

[issue7510] AttributeError: MSVCCompiler instance has no attribute '_MSVCCompiler__root'

New submission from Sridhar Ratnakumar : This error happened while installing pycrypto 2.0.1 on XP 64-bit with VS 2008 express installed using Python 2.5.4 64-bit (via buildout). See also: http://twistedmatrix.com/trac/ticket/3352 Getting distribution for 'pycrypto>=1.9'. Traceback (most recen

[issue7511] msvc9compiler.py: ValueError: [u'path']

New submission from Sridhar Ratnakumar : Win XP 64-bit Python 2.6.4 64-bit Getting distribution for 'pycrypto>=1.9'. Traceback (most recent call last): File "", line 1, in File "build\bdist.win-amd64\egg\setuptools\command\easy_install.py", line 1714, in main File "build\bdist.win-amd64

[issue7509] AttributeError: MSVCCompiler instance has no attribute '_MSVCCompiler__root'

Sridhar Ratnakumar added the comment: Duplicate of issue7510 -- status: open -> closed ___ Python tracker ___ ___ Python-bugs-list mai

[issue7510] AttributeError: MSVCCompiler instance has no attribute '_MSVCCompiler__root'

Martin v. Löwis added the comment: Python 2.5 is no longer maintained, except for security issues (which this one is not). Closing as won't fix. -- nosy: +loewis resolution: -> wont fix status: open -> closed ___ Python tracker

[issue7511] msvc9compiler.py: ValueError: [u'path']

Martin v. Löwis added the comment: Most likely, the problem is that visual studio is not installed on your system. -- nosy: +loewis ___ Python tracker ___ ___

[issue7511] msvc9compiler.py: ValueError: [u'path']

Sridhar Ratnakumar added the comment: I have Visual C++ 2008 express edition installed. Maybe it is a quirk of express edition as I was able to install pycrypto fine with the Visual Studio 2008 professional edition at work machine. In any case, I believe this is a bug with distutils. ---

[issue7512] shutil.copystat may fail EOPNOTSUPP

New submission from Kuang-che Wu : "flags" is only supported on certain OS. FreeBSD is one of them. FreeBSD itself support chflags but not all of its file systems do. On FreeBSD, copystat() will fail on zfs. The exception is OSError and errno is EOPNOTSUPP. According to manpage chflags(2), the e

[issue1975] signals not always delivered to main thread, since other threads have the signal unmasked

Andriy Pylypenko added the comment: Let me add my 2 cents. I understood the considerations about differences between Python code level interrupt handling and OS level interrupts. What I cannot get is why to preserve the handling of signals in the user threads on OSes like FreeBSD and Solaris