[issue4741] winsound.SND_PURGE has no effect
Georg Brandl ge...@python.org added the comment: In any case, this is not an issue in Python as PlaySound is only a thin wrapper around the OS' function. -- nosy: +georg.brandl resolution: - wont fix status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4741 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4748] yield expression vs lambda
New submission from Georg Brandl ge...@python.org: With lambda, the ban on return x in generators can be evaded: x = lambda: ((yield 1), (yield 2)) list(x()) [1, 2, (None, None)] dis.dis(x) 1 0 LOAD_CONST 0 (1) 3 YIELD_VALUE 4 LOAD_CONST 1 (2) 7 YIELD_VALUE 8 BUILD_TUPLE 2 11 RETURN_VALUE -- messages: 78291 nosy: georg.brandl priority: high severity: normal status: open title: yield expression vs lambda versions: Python 2.6, Python 3.0 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4748 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4718] wsgiref package totally broken
Graham Dumpleton graham.dumple...@gmail.com added the comment: If making changes in wsgireg.validate, may be worthwhile also fixing up one area where it isn't strictly correct according to WSGI PEP. As per discussion: http://groups.google.com/group/python-web-sig/browse_frm/thread/b14b862ec4c620c0 the check for number of arguments supplied to wsgi.input.read() is wrong as it allows for an optional argument, when argument is supposed to mandatory. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4718 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4749] Issue with RotatingFileHandler logging handler on Windows
New submission from Mohammad Al mramah...@hotmail.com: It seems that RotatingFileHandler is experiencing an issue when attempting to rotate log files under Windows. The following errors are received: Traceback (most recent call last): File C:\Python25\lib\logging\handlers.py, line 73, in emit if self.shouldRollover(record): File C:\Python25\lib\logging\handlers.py, line 147, in shouldRollover self.stream.seek(0, 2) #due to non-posix-compliant Windows feature ValueError: I/O operation on closed file Traceback (most recent call last): File C:\Python25\lib\logging\handlers.py, line 73, in emit if self.shouldRollover(record): I tried the code on Python 2.5.2 and 2.5.4 under Windows XP SP 2, with the same results. To reproduce run the attached scripts few times. The first time the handlers attempt to rotate the log files the error message above is received. In addition to crashing the application, log files are getting lost as a result, which is a serious issue. I have seen few complaints about this issue, but tickets were closed without a real resolution to the issue (unless I missed something) -- components: Library (Lib) files: rothandlerbug.py messages: 78293 nosy: mramahi77 severity: normal status: open title: Issue with RotatingFileHandler logging handler on Windows type: crash versions: Python 2.4, Python 2.5 Added file: http://bugs.python.org/file12449/rothandlerbug.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4749 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4718] wsgiref package totally broken
Dmitry Vasiliev d...@hlabs.spb.ru added the comment: Graham Dumpleton wrote: the check for number of arguments supplied to wsgi.input.read() is wrong as it allows for an optional argument, when argument is supposed to mandatory. I think it's a good idea. I'll update the patch soon. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4718 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4604] close() seems to have limited effect
Dmitry Vasiliev d...@hlabs.spb.ru added the comment: Attached more generic version of the patch. -- nosy: +hdima Added file: http://bugs.python.org/file12450/io_fixes.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4604 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4750] tarfile keeps excessive dir structure in compressed files
New submission from anatoly techtonik techto...@gmail.com:
When tarfile is directed to create tar.gz compressed archive file in a
path different from current, it saves full path information in .gz
header where only filename is required.
This causes problems with decompression utilities, such as 7zip. The
testsuite with patch are attached.
{{{
tar -czf dist\create_tar.tar.gz package
7z l dist\create_tar.tar.gz tar.out
python test_create.tar.gz.py
7z l dist\create_py.tar.gz py.out
diff -pu3 tar.out py.out
}}}
{{{
--- tar.out Fri Dec 26 15:12:42 2008
+++ py.out Fri Dec 26 15:12:42 2008
@@ -1,10 +1,10 @@
7-Zip 4.57 Copyright (c) 1999-2007 Igor Pavlov 2007-12-06
-Listing archive: dist\create_tar.tar.gz
+Listing archive: dist\create_py.tar.gz
Date TimeAttr Size Compressed Name
--- -
-2008-12-26 15:12:41 10240 170 create_tar.tar
+2008-12-26 15:03:39 10240 141 dist/create_py.tar
--- -
- 10240 170 1 files, 0 folders
+ 10240 141 1 files, 0 folders
}}}
See also issue 1886 and msg61515 in particular
--
components: Distutils, Library (Lib)
files: test_tarfile.extrapath.zip
messages: 78296
nosy: techtonik
severity: normal
status: open
title: tarfile keeps excessive dir structure in compressed files
versions: Python 2.5, Python 2.6, Python 2.7
Added file: http://bugs.python.org/file12451/test_tarfile.extrapath.zip
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4750
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4750] tarfile keeps excessive dir structure in compressed files
Changes by anatoly techtonik techto...@gmail.com: -- keywords: +patch Added file: http://bugs.python.org/file12452/tarfile.directory.fix.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4750 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4751] Patch for better thread support in hashlib
New submission from ebfe knabberknusperh...@yahoo.de: The hashlib functions provided by _hashopenssl.c hold the GIL all the time although the underlying openssl-library is basically thread-safe. I've attached a patch (svn diff) which basically does four things: * If python is compiled with thread-support, the EVPobject is extended by an additional PyThread_type_lock which protects the objects individually. * The 'update' function releases the GIL if the to-be-hashed object is a Bytes-object and therefor provides trustworthy locking (all other types, including subclasses, are not trustworthy!). This allows multiple threads to do hashing in parallel. * The EVP_hash function removes duplicated code. * The situation regarding unicode objects is now more meaningful. Upon passing a unicode-string to the .update() function, the original hashlib throws a TypeError: object supporting the buffer API required which is confusing. I think it's perfectly valid not to accept unicode-strings as input and people should required to call str.encode() upon their strings before hashing, so a well-defined byte-representation of their strings get hashed. Therefor I patched the MY_GET_BUFFER_VIEW_OR_ERROUT-macro to throw TypeError: Unicode-objects must be encoded before hashing. This also fixes issue #1118 I've tested this patch and did not run into problems. CPU occupancy relies on the buffer-size passed to .update() as releasing the GIL is basically not worth the effort for very small buffers. More testing may be needed... -- components: Library (Lib) files: hashopenssl_threads.diff keywords: patch messages: 78297 nosy: ebfe severity: normal status: open title: Patch for better thread support in hashlib type: performance versions: Python 3.0 Added file: http://bugs.python.org/file12453/hashopenssl_threads.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4751 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4718] wsgiref package totally broken
Dmitry Vasiliev d...@hlabs.spb.ru added the comment: Added check for wsgi.input.read() argument. Added file: http://bugs.python.org/file12454/wsgiref2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4718 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1885] [distutils] - error when processing the --formats=tar option
anatoly techtonik techto...@gmail.com added the comment: Please reopen this bug. issue#1886 is different it take a long time until it is committed. I attach patch from Giampaolo here. -- keywords: +patch nosy: +techtonik versions: +Python 2.5, Python 2.7 Added file: http://bugs.python.org/file12455/issue1885.tar.removed.fix.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1885 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1886] Permit to easily use distutils --formats=tar, gztar, bztar on all systems
anatoly techtonik techto...@gmail.com added the comment: I attach an improved patch1886.use.tarfile.module.diff that fixes all bugs addressed in this issue. It also removes second call to compression program leaving that privilege to tar. I notice that the archive generated by tarfile module looks different. Once I open it I see the following structure: dist (directory) - archive_name.tar - archive_name (directory) - other subfiles This bug is illustrated and patched (not released yet as somebody needs to reopen it) in issue 1885. The extra path component is taken from the name passed to GzipFile. -- nosy: +techtonik versions: +Python 2.7 Added file: http://bugs.python.org/file12456/patch1886.use.tarfile.module.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1886 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1886] Permit to easily use distutils --formats=tar, gztar, bztar on all systems
anatoly techtonik techto...@gmail.com added the comment: Oh, my mistake - the bug with extra dir component in archive is in issue4750 Second shell call to compression program is removed only for the case when tarfile or any of required compression modules are not available. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1886 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1886] Permit to easily use distutils --formats=tar, gztar, bztar on all systems
Roumen Petrov bugtr...@roumenpetrov.info added the comment: about patch1886.use.tarfile.module.diff - the original tar don't support -j flag. -- nosy: +rpetrov ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1886 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1886] Permit to easily use distutils --formats=tar, gztar, bztar on all systems
anatoly techtonik techto...@gmail.com added the comment: What are the systems where does this original tar still exist as a default utility? If there is no tarfile module on this systems and tar version is so old then you need a more modern system to wrap your releases or more modern tar. The ratio of such systems to windows systems without tar at all is less than 1%, so it doesn't worth the hassle. But the true reason why I won't revert the part where command line tar is used, to a double call scheme, is that when you do not pipe tar with compression program and use them separately with relative path - you will get the same weird header in your tar.gz That's why it is not uncommon on windows to meet tar.gz python packages with weird paths inside. Luckily, windows users are infrequently install something from sources and if they do - the .zip option is often preferred. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1886 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4718] wsgiref package totally broken
Antoine Pitrou pit...@free.fr added the comment: Hi, The patch looks ok to me, although the tests against mutable byte-like types are probably useless. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4718 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4722] _winreg.QueryValue fault while reading mangled registry values
Changes by Gabriel Genellina gagsl-...@yahoo.com.ar: -- nosy: +gagenellina ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4722 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4752] Error in SocketServer UDP documentation
New submission from Andrey Petrov andrey.pet...@shazow.net: In the SocketServer.UDPServer Example, the second last line: server = SocketServer.UDPServer((HOST, PORT), BaseUDPRequestHandler) Should be: server = SocketServer.UDPServer((HOST, PORT), MyUDPHandler) -- assignee: georg.brandl components: Documentation messages: 78305 nosy: georg.brandl, shazow severity: normal status: open title: Error in SocketServer UDP documentation versions: Python 2.6, Python 3.0 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4752 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4753] Faster opcode dispatch on gcc
Antoine Pitrou pit...@free.fr added the comment: Armin, by reading the pypy-dev mailing-list it looks like you were interested in this. -- nosy: +arigo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4753 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4751] Patch for better thread support in hashlib
STINNER Victor victor.stin...@haypocalc.com added the comment: I think that you don't use Py_BEGIN_ALLOW_THREADS / Py_END_ALLOW_THREADS correctly: the GIL can be released when the hashlib lock is acquired (to run hash functions in parallel threads). So the macros should be: #define ENTER_HASHLIB \ PyThread_acquire_lock(self-lock, 1); \ Py_BEGIN_ALLOW_THREADS #define LEAVE_HASHLIB \ Py_END_ALLOW_THREADS \ PyThread_release_lock(self-lock); If I'm right, issue #4738 (zlib) is also affected. -- nosy: +haypo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4751 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4751] Patch for better thread support in hashlib
Antoine Pitrou pit...@free.fr added the comment: Hi, Very good idea. However, you don't need to discriminate for the bytes type specifically. When a buffer is taken on the object (with PyObject_GetBuffer()), the object is internally locked until the buffer is release with PyBuffer_Release(). Try with a bytearray and you'll see: if you resize the bytearray while hashing it in another thread, you'll get a BufferError exception. All in all, it should make your code and macros much simpler. -- nosy: +pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4751 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4726] doctest gets line numbers wrong due to quotes in comments
Gabriel Genellina gagsl-...@yahoo.com.ar added the comment: I could not reproduce the behaviour you describe. Could you provide a test case? That fails with the current code and is fixed after applying your patch. (BTW, the r.e. should be a raw string literal, even the original one) -- nosy: +gagenellina ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4726 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4751] Patch for better thread support in hashlib
STINNER Victor victor.stin...@haypocalc.com added the comment: EVP_copy() and EVP_get_digest_size() should call ENTER_HASHLIB/LEAVE_HASHLIB to protect self-ctx. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4751 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4738] Patch to make zlib-objects better support threads
Changes by Antoine Pitrou pit...@free.fr: -- nosy: +pitrou priority: - normal stage: - patch review versions: -Python 2.5, Python 2.6, Python 3.0 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4738 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4751] Patch for better thread support in hashlib
STINNER Victor victor.stin...@haypocalc.com added the comment:
If view.len is negative, EVP_hash() may read invalid memory :-/ Be
careful of integer overflow in this block:
Py_ssize_t offset = 0, sublen = len;
while (sublen) {
unsigned int process = sublen MUNCH_SIZE ? MUNCH_SIZE :
sublen;
...
}
You removed Py_SAFE_DOWNCAST(len, Py_ssize_t, unsigned int) which
should be used (eg. on process?).
Note: you might modify len directly instead of using a second variable
(sublen), and cp instead of using an offset.
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4751
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4754] winsound documentation (about stoping sounds)
New submission from Hirokazu Yamamoto ocean-c...@m2.ccsnet.ne.jp: This comes from Issue4741. The patch - clarify meaning of None as the parameter of *sound* to PlaySound - notify SND_PURGE is not supported by MS now -- assignee: georg.brandl components: Documentation files: winsound_doc.patch keywords: patch messages: 78313 nosy: georg.brandl, ocean-city severity: normal status: open title: winsound documentation (about stoping sounds) versions: Python 2.6 Added file: http://bugs.python.org/file12458/winsound_doc.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4754 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4754] winsound documentation (about stoping sounds)
Hirokazu Yamamoto ocean-c...@m2.ccsnet.ne.jp added the comment: The patch is for release26-maint. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4754 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4716] Python 3.0 halts on shutdown when settrace is set
Gabriel Genellina gagsl-...@yahoo.com.ar added the comment:
Yes, this is exactly the problem. The execution never goes beyond print
('here'); if you print frame.f_lineno you'll see it blocks at io.py
line 1036, waiting for a Lock for the second time.
So the trace function cannot use print, not write to regular files
(because io.py is written in Python). This is a severe limitation.
As a workaround, you can use the _fileio module (written in C):
import _fileio
f = _fileio._FileIO(output.txt, w, True)
def tracing_func(frame, event, arg):
f.write('%s %s %d\n' % (frame.f_code.co_filename, frame.f_code.co_
name, frame.f_lineno))
return tracing_func
A possible fix would be to use an RLock instead of a Lock object, but
I haven't investigated it.
--
components: +Library (Lib)
nosy: +gagenellina
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4716
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4716] Python 3.0 halts on shutdown when settrace is set
Antoine Pitrou pit...@free.fr added the comment: Thanks for the investigation! The problem has already been reported in #3618. Closing this one. -- resolution: - duplicate status: open - closed superseder: - possible deadlock in IO library (Lib/io.py) ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4716 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4751] Patch for better thread support in hashlib
STINNER Victor victor.stin...@haypocalc.com added the comment: New version of ebfe's patch: - ENTER/LEAVE_HASHLIB: * don't touch GIL in ENTER_HASHLIB (it's useless) * add mandatory argument (explicit use of self) - EVP_hash(): * restore Py_SAFE_DOWNCAST * simplify the code: always use the while() instead of if+while * use while (0 len) to skip zero or negative value (even if pitrou told me that len should not be negative) - EVP_dealloc(): free the lock before the context - release the GIL for all calls to EVP_hash() - use the context lock in EVP_copy() and EVP_get_digest_size() to protect self - don't use the context lock in EVP_repr() (useless because we don't read OpenSSL context) - fix the indentation of the code (replace tab by spaces) Some rules for ENTER/LEAVE_HASHLIB: * it is only needed to protect the context attribute (eg. name doesn't need to be protected by the lock) * it doesn't touch the GIL: use an explicit call to Py_BEGIN_ALLOW_THREADS/Py_END_ALLOW_THREADS About the GIL: * EVP_DigestInit() and EVP_MD_CTX_copy() are consired fast enough to no release the GIL * The GIL is released for the slowest function: EVP_DigestUpdate() (called in our EVP_hash() function) Added file: http://bugs.python.org/file12459/hashopenssl_threads-2.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4751 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4738] Patch to make zlib-objects better support threads
STINNER Victor victor.stin...@haypocalc.com added the comment: New comments about the last patch: - GIL is not released for adler() or crc32() whereas these functions may be slow for long strings: just add Py_BEGIN_ALLOW_THREADS / Py_END_ALLOW_THREADS before / after adler(...) and crc32(...) - (As ENTER_HASHLIB, issue #4751) I think that Py_BEGIN_ALLOW_THREADS / Py_END_ALLOW_THREADS are useless in ENTER_ZLIB - You might add explicit self to ENTER/LEAVE_ZLIB because the macros are now dependent of self (and not the whole module) = ENTER_ZLIB(self) and LEAVE_ZLIB(self) Are deflateCopy() and inflateCopy() slow enough to release the GIL? ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4738 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3860] GzipFile and BZ2File should support context manager protocol
STINNER Victor victor.stin...@haypocalc.com added the comment: I love with ... as f: and I want it for gzip/bz2 files! Comment about the patch: (1) the IOError message is different for the two modules: I/O operation on closed GzipFile object vs I/O operation on closed file Specify the object name in both messages or remove it from both messages. I prefer verbose error message (I/O operation on closed BZ2File object). (2) For bz2module, Why don't you call BZ2File_close() directly instead of the generic version PyObject_CallMethod(... close ...)? -- nosy: +haypo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3860 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4640] optparse - dosn't distinguish between '--option' and '-option'
STINNER Victor victor.stin...@haypocalc.com added the comment: -debug may be equivalent to -d -e -b -u -g (if none of these options have an argument), but no to --debug. If you like to use -d as an alias to --debug, just use: add_option(-d, --debug, ...). -- nosy: +haypo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4640 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4708] os.pipe should return inheritable descriptors (Windows)
Gabriel Genellina gagsl-...@yahoo.com.ar added the comment: Patch to posixmodule.c including test case and documentation updates. Note: I've only run the tests on Windows. -- keywords: +patch Added file: http://bugs.python.org/file12460/inheritable_pipes.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4708 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4751] Patch for better thread support in hashlib
Changes by ebfe knabberknusperh...@yahoo.de: Removed file: http://bugs.python.org/file12453/hashopenssl_threads.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4751 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4751] Patch for better thread support in hashlib
ebfe knabberknusperh...@yahoo.de added the comment: Thanks for the advices. Antoine, maybe you could clarify the situation regarding buffer-locks for me. In older versions of PEP 3118 the PyBUF_LOCK flag was still present but it doesn't seem to have made it's way into the final draft. Is it save to assume that a buffer-view will not change until release() is called - for all types supporting the buffer protocol in py3k ?? I've done some testing and the overhead of releasing and re-locking the GIL is definitely a performance problem when trying to hash many small strings (doubled runtime for 100.000 times b'abc'). I've taken on haypo's patch to release the GIL only when the buffer is larger than 10kb. Added file: http://bugs.python.org/file12461/hashopenssl_threads-3.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4751 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4751] Patch for better thread support in hashlib
Antoine Pitrou pit...@free.fr added the comment: Is it save to assume that a buffer-view will not change until release() is called - for all types supporting the buffer protocol in py3k ?? Yes, it is! ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4751 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3860] GzipFile and BZ2File should support context manager protocol
Antoine Pitrou pit...@free.fr added the comment: (1) the IOError message is different for the two modules: I/O operation on closed GzipFile object vs I/O operation on closed file I've reused the same error message as used in other parts of each module. (2) For bz2module, Why don't you call BZ2File_close() directly instead of the generic version PyObject_CallMethod(... close ...)? Because someone may subclass BZ2File and override the close() method. I don't know if it's likely to happen, though. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3860 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4751] Patch for better thread support in hashlib
STINNER Victor victor.stin...@haypocalc.com added the comment: I've taken on haypo's patch to release the GIL only when the buffer is larger than 10kb You can factorize the code by moving Py_BEGIN_ALLOW_THREADS / Py_END_ALLOW_THREADS *into* EVP_hash ;-) 10 KB is a random value or the fast value for your computer? I wrote a small benchmark: md5sum.py, my Python multithreaded version of md5sum. Results on 129 files (between 7 and 10 MB) on an Intel Quad Core @ 2.5 GHz: - without the patch: best=10.6 sec / average ~= 11.5 sec - with the patch (version 3): best=7.7 sec / average ~= 8.5 sec My program creates N threads for N files, which is maybe stupid (eg. limit to C+1 thread for C cores). Added file: http://bugs.python.org/file12462/md5sum.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4751 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4738] Patch to make zlib-objects better support threads
ebfe knabberknusperh...@yahoo.de added the comment: new svn diff attached - GIL is now released for adler32 and crc32 if the buffer is larger than 5kb (we don't want to risk burning cpu cycles by GIL-stuff) - adler32 got it's param by s# but now does s* - why s# anyway? - ENTER_ZLIB no longer gives away the GIL. It's dangerous and useless as there is no pressure on the object's lock. - deflateCopy() and inflateCopy() are not worth the trouble.u Added file: http://bugs.python.org/file12463/zlib_threads-2.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4738 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4738] Patch to make zlib-objects better support threads
Changes by ebfe knabberknusperh...@yahoo.de: Removed file: http://bugs.python.org/file12448/zlib_threads.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4738 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4751] Patch for better thread support in hashlib
STINNER Victor victor.stin...@haypocalc.com added the comment: New version of my md5sum.py program limited to 10 threads. New benchmark with 160 files (size in 7..10 MB): - Python unpatched: best=4.8 sec - C version (/usr/bin/md5sum): best=3.6 sec - Python patched: best=2.1 sec As everybody knows, Python is faster than the C language ;-) And the patch is really useful (the program is more than twice faster with 4 cores). Added file: http://bugs.python.org/file12464/md5sum.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4751 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4751] Patch for better thread support in hashlib
Changes by STINNER Victor victor.stin...@haypocalc.com: Removed file: http://bugs.python.org/file12462/md5sum.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4751 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4751] Patch for better thread support in hashlib
ebfe knabberknusperh...@yahoo.de added the comment: Here is another simple benchmarker. For me it shows almost perfect scaling (2 cores = 196% performance) if the buffer put into .update() is large enough. I deliberately did not move Py_BEGIN_ALLOW_THREADS into EVP_hash as we might call this function without having some lock on the input buffer. The 10kb limit was based on my own computer (MacBook Pro 2x2.5GHz) and is somewhat more-safe-than-sorry. Hashing is *very* fast on modern CPUs and working on many small strings becomes very inefficient when releasing the GIL all the time. Just try to hash 10240 bytes vs. 10241 bytes. Added file: http://bugs.python.org/file12465/hashlibtest.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4751 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4738] Patch to make zlib-objects better support threads
STINNER Victor victor.stin...@haypocalc.com added the comment: Comments on zlib_threads-2.diff: - the indentation is strange: don't mix spaces and tabs! - I prefer ; after a call to a macro: ENTER_ZLIB(self); instead of ENTER_ZLIB(self). It makes vim happy (auto indent code correctly) and it works for ENTER_ZLIB and LEAVER_ZLIB. - ENTER_ZLIB and LEAVER_ZLIB prototype is wrong if WITH_THREAD is not defined - oh yeah, s* is needed to protect the buffer with a lock - why 5kb? is it a random value? I prefer power of two, like 4096 bytes :-) ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4738 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4751] Patch for better thread support in hashlib
STINNER Victor victor.stin...@haypocalc.com added the comment: hashlibtest.py results on my Quad Core with 4 threads: - unpatched: best=13.0 sec - patched: best=3.25 sec Some maths: 13.0 / 4 = 3.25 \o/ ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4751 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4738] Patch to make zlib-objects better support threads
ebfe knabberknusperh...@yahoo.de added the comment:
new svn diff attached
the indentation in this file is not my fault, it has tabs all over it...
The 5kb limits protects from the overhead of releasing the GIL. With
very small buffers the overall runtime in my benchmark tends to double.
I set it based on my testing and it remains being arbitrary to a certain
degree. Set the limit to 1 and try 1.000.000 times b'abc'...
May I also suggest to change the zlib module not to accept s* but y*:
- Internally zlib operates on bytes, characters don't mean a thing in
zlib-land.
- We rely on s* performing the encoding into default for us. This
behaviour is hidden from the programmer and somewhat violates the rule
of least surprise.
- type(zlib.decompress(zlib.compress('abc'))) == bytes
- Changing from s* to y* forces the programmer to use .encode() on his
strings (e.g. zlib.compress('abc'.encode()) which very clearly shows
what's happening.
Added file: http://bugs.python.org/file12466/zlib_threads-2.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4738
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4748] yield expression vs lambda
Benjamin Peterson benja...@python.org added the comment: Attaching patch? BTW, how did you find this bug? :) -- keywords: +needs review, patch nosy: +benjamin.peterson stage: - patch review type: - behavior Added file: http://bugs.python.org/file12467/nasty_lambda_generators.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4748 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4738] Patch to make zlib-objects better support threads
Changes by ebfe knabberknusperh...@yahoo.de: Removed file: http://bugs.python.org/file12463/zlib_threads-2.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4738 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4744] asynchat documentation needs to be more precise
Changes by Giampaolo Rodola' billiej...@users.sourceforge.net: -- nosy: +giampaolo.rodola, josiah.carlson ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4744 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4743] intra-pkg multiple import (import local1, local2) not fixed
Benjamin Peterson benja...@python.org added the comment: r67928 makes 2to3 more tolerant about multiple imports on a line. It also warns when there is an absolute import and relative import on the same line. -- nosy: +benjamin.peterson resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4743 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4745] socket.send obscure error message
Benjamin Peterson benja...@python.org added the comment: Fixed in r67929. -- nosy: +benjamin.peterson resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4745 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4740] pickle test for protocol 3 (HIGHEST_PROTOCOL in py3k)
Benjamin Peterson benja...@python.org added the comment: Looks fine to me. This happens in the trunk already, right? -- nosy: +benjamin.peterson ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4740 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4740] pickle test for protocol 3 (HIGHEST_PROTOCOL in py3k)
Hirokazu Yamamoto ocean-c...@m2.ccsnet.ne.jp added the comment: Not yet. This patch is for trunk. But HIGHEST_PROTOCOL is 2 in trunk, so no difference in behavior. (Just useful for consistency) Added file: http://bugs.python.org/file12468/trunk_use_HIGHEST_PROTOCOL.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4740 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4740] pickle test for protocol 3 (HIGHEST_PROTOCOL in py3k)
Benjamin Peterson benja...@python.org added the comment: Go ahead. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4740 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4755] Common path prefix
New submission from Skip Montanaro s...@pobox.com: os.path.commonprefix returns the common prefix of a list of paths taken character-by-character. This can return invalid paths. For example, os.path.commonprefix([/export/home/dave, /etc/passwd]) will return /e, which likely has no meaning as a path, at least in the context of the input list. Ideally, os.path.commonprefix would operate component-by-component, but people rely on the existing character-by-character operation, so it has been so far impossible to change semantics. There are several possible ways to solve this problem. One, change how commonprefix behaves. Two, add a flag to commonprefix to allow it to operate component-by-component if desired. Three, add a new function to os.path. I personally prefer the first option. Aside from the semantic change though, it presents the problem of where to put the old definition of commonprefix. It's clearly of some use or people wouldn't have co- opted it for non-filesystem use. It could go in the string module, but that's been living a life in limbo since the creation of string methods. People have been loathe to add new functionality there. The second option seems to me like would just be a hack on top of already broken behavior and probably require the currently slightly broken behavior as the default to boot, so I won't go there. Since option one is perhaps not going to be available to me, I've implemented the third option as a new function, commonpathprefix. See the attached patch. It includes test cases and documentation changes. -- components: Library (Lib) files: cpp.diff keywords: needs review, patch, patch messages: 78338 nosy: skip.montanaro severity: normal stage: patch review status: open title: Common path prefix type: behavior versions: Python 3.1 Added file: http://bugs.python.org/file12469/cpp.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4755 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4755] Common path prefix
Nick Coghlan ncogh...@gmail.com added the comment: A new function sounds like a good solution to me. How about just calling it os.path.commonpath though? I agree having a path component based prefix function in os.path is highly desirable, particularly since the addition of relpath in 2.6: base_dir = os.path.commonpath(paths) rel_paths = [os.path.relpath(p, base_dir) for p in paths] -- nosy: +ncoghlan ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4755 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4740] pickle test for protocol 3 (HIGHEST_PROTOCOL in py3k)
Hirokazu Yamamoto ocean-c...@m2.ccsnet.ne.jp added the comment: Done. Fixed in r67930(trunk), r67931(py3k) -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4740 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4740] pickle test for protocol 3 (HIGHEST_PROTOCOL in py3k)
Changes by Hirokazu Yamamoto ocean-c...@m2.ccsnet.ne.jp: -- stage: patch review - committed/rejected ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4740 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4710] [PATCH] zipfile.ZipFile does not extract directories properly
Gabriel Genellina gagsl-...@yahoo.com.ar added the comment: Your usage of os.sep is incorrect, both when reading and writing directories. Zip files are (more-or-less) platform independent. The specification *requires* forward slashes in paths [1], and the zipfile module already writes them that way. Checking for os.sep is wrong - at least on Windows. I've never encountered malformed entries of that kind (like directory \ instead of directory/) but if you want to suport such beasts, check for / *and* os.sep explicitely. [1] See APPNOTE.TXT (there is a link near the top of zipfile.py) -- nosy: +gagenellina ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4710 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4756] zipfile.is_zipfile: added support for file-like objects
New submission from Gabriel Genellina gagsl-...@yahoo.com.ar: Patch to zipfile.is_zipfile, adding support for file and file-like objects. Includes test cases and documentation updates. This fixes issue4241 too. -- components: Library (Lib) files: is_zipfile_filelike.diff keywords: patch messages: 78342 nosy: gagenellina severity: normal status: open title: zipfile.is_zipfile: added support for file-like objects type: behavior versions: Python 2.7, Python 3.1 Added file: http://bugs.python.org/file12470/is_zipfile_filelike.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4756 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4241] zipfile.py - is_zipfile leaves file open when error
Gabriel Genellina gagsl-...@yahoo.com.ar added the comment: The patch for issue4756 fixes this too. -- nosy: +gagenellina ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4241 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3618] possible deadlock in IO library (Lib/io.py)
Changes by Gabriel Genellina gagsl-...@yahoo.com.ar: -- nosy: +gagenellina ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3618 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
