[issue2889] curses for windows (alternative patch)
Changes by Christoph Gohlke cgoh...@uci.edu: -- nosy: +cgohlke ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2889 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10052] Python/dtoa.c:158: #error Failed to find an exact-width 32-bit integer type (FreeBSD 4.11 + gcc 2.95.4)
New submission from Akira Kitada akit...@gmail.com: Building Python 2.7 fails on FreeBSD 4.11 with gcc 2.95.4 as below: gcc -pthread -c -fno-strict-aliasing -g -O2 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -IInclude -I./Include -DPy_BUILD_CORE -o Python/dtoa.o Python/dtoa.c Python/dtoa.c:158: #error Failed to find an exact-width 32-bit integer type gmake: *** [Python/dtoa.o] Error 1 This error occurs when HAVE_UINT32_T or HAVE_INT32_T are not defined. Those constants are defined in Include/pyport.h as: #if (defined UINT32_MAX || defined uint32_t) #ifndef PY_UINT32_T #define HAVE_UINT32_T 1 #define PY_UINT32_T uint32_t #endif #endif #if (defined INT32_MAX || defined int32_t) #ifndef PY_INT32_T #define HAVE_INT32_T 1 #define PY_INT32_T int32_t #endif #endif This doesn't work for FreeBSD 4, where exact-width integer types are defined #typedef and does not provide *_MAX for them. I don't think this is the right fix but adding following macro to pyport.h fixed the problem. #define UINT32_MAX 0x #define INT32_MAX 0x7fff -- components: Build messages: 118246 nosy: akitada priority: normal severity: normal status: open title: Python/dtoa.c:158: #error Failed to find an exact-width 32-bit integer type (FreeBSD 4.11 + gcc 2.95.4) type: compile error versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10052 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7771] dict view comparison methods are not documented
Sandro Tosi sandro.t...@gmail.com added the comment: gaah, sorry about that. I've prepared another patch that removes the '^' part and adds an example about that. About the reference to Collections.Set to be a link to the Collections page, do you think it's acceptable to define all the Collection ABCs as :class:`...` ? I looked at http://docs.python.org/documenting/markup.html but didn't find a specific markup for ABC, so I suppose 'class' is fine. If you think it might worth the effort, I can mark those ABCs up as class, and scan the documentation for references to them and convert to link (if not already done automagically). -- Added file: http://bugs.python.org/file19169/issue7771-py3k-v3.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7771 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8533] regrtest: use backslashreplace error handler for stdout
Hirokazu Yamamoto ocean-c...@m2.ccsnet.ne.jp added the comment: I noticed fd must be dup-ed before passing to io.open. And I noticed direct test run like py3k -m test.test_time still produces unicode error. (Maybe this is reasonable limitation) I can confirm we can suppress the unicode error in such case with newly attached patch. py3k_also_no_unicode_error_on_direct_test_run.patch -- Added file: http://bugs.python.org/file19170/py3k_also_no_unicode_error_on_direct_test_run.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8533 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10053] Probably fd should not be closed when FileIO#__init__ failed
New submission from Hirokazu Yamamoto ocean-c...@m2.ccsnet.ne.jp: I suppose when _io.FileIO(fd) failed, passed fd should not be closed. Otherwise, we cannot write the code like this. fd = os.open(path, os.O_RDONLY) try: buf = io.open(fd, wb) except: os.close(fd) raise I found some corner case (rarely happens) in FileIO#__init__ Is this patch correct? Thank you. -- components: IO files: py3k_ensure_fd_not_closed_after_fileio_init_failed.patch keywords: patch messages: 118249 nosy: ocean-city priority: normal severity: normal stage: patch review status: open title: Probably fd should not be closed when FileIO#__init__ failed versions: Python 2.7, Python 3.1, Python 3.2 Added file: http://bugs.python.org/file19171/py3k_ensure_fd_not_closed_after_fileio_init_failed.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10053 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10053] Probably fd should not be closed when FileIO#__init__ failed
Hirokazu Yamamoto ocean-c...@m2.ccsnet.ne.jp added the comment: Here is the test script also run on py2.7. -- Added file: http://bugs.python.org/file19172/test_ensure_fd_not_closed_after_fileio_init_failed.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10053 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10054] select extension does not build on platforms where uintptr_t is provided in inttypes.h
New submission from Akira Kitada akit...@gmail.com: Some platforms have uintptr_t in inttypes.h but Python bulid system assumes it's defined in stdint.h and it causes build failure: building 'select' extension gcc -pthread -fPIC -fno-strict-aliasing -g -O2 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -IInclude -I./Include -I/usr/local/include -I/usr/home/akitada/ src/release27-maint/Include -I/usr/home/akitada/src/release27-maint -c /usr/home/akitada/src/release27-maint/Modules/selectmodule.c -o build/temp.freebsd-4. 11-RELEASE-i386-2.7/usr/home/akitada/src/release27-maint/Modules/selectmodule.o /usr/home/akitada/src/release27-maint/Modules/selectmodule.c:1189: #error uintptr_t does not match void *! -- components: Build messages: 118251 nosy: akitada priority: normal severity: normal status: open title: select extension does not build on platforms where uintptr_t is provided in inttypes.h type: compile error versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10054 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10054] select extension does not build on platforms where uintptr_t is provided in inttypes.h
Akira Kitada akit...@gmail.com added the comment: This patch fixes this. -- keywords: +patch Added file: http://bugs.python.org/file19173/issue10054.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10054 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8533] regrtest: use backslashreplace error handler for stdout
STINNER Victor victor.stin...@haypocalc.com added the comment: py3k_also_no_unicode_error_on_direct_test_run.patch comes a little bit too late: $ LANG= ./python Lib/test/regrtest.py -v test_time == CPython 3.2a2+ (py3k, Oct 8 2010, 01:40:20) [GCC 4.4.5 20100909 (prerelease)] == Linux-2.6.32-trunk-686-i686-with-debian-squeeze-sid little-endian == Traceback (most recent call last): File Lib/test/regrtest.py, line 1478, in module main() File Lib/test/regrtest.py, line 454, in main print(== , os.getcwd()) UnicodeEncodeError: 'ascii' codec can't encode characters in position 20-21: ordinal not in range(128) My working directory is /home/haypo/prog/SVN/py3ké. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8533 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4388] test_cmd_line fails on MacOS X
STINNER Victor victor.stin...@haypocalc.com added the comment: For the record, this can be now reproduced under Linux by forcing different locale and filesystem encodings: $ PYTHONFSENCODING=utf8 LANG=ISO-8859-1 ./python -m test.regrtest test_cmd_line I opened a separated issue for Linux, #9992, because some Mac OS X users say that this issue looks like a Mac OS X bug and the fix may be different. Extract of msg111432 (#8775): To be honest, I'd say the behavior of OSX 10.4 is a bug and we might add a workaround on that platform that uses CFStringGetSystemEncoding() to fetch the actual system encoding when LANG=C. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4388 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10055] C99 code in _json.c
New submission from Akira Kitada akit...@gmail.com: I found some C99 code in _json.c. Attached patch makes it C89. The C99 part is only used for ucs4 Python. That's probably the reason it's overlooked. -- components: Build files: _json.c.diff keywords: patch messages: 118255 nosy: akitada priority: normal severity: normal status: open title: C99 code in _json.c type: compile error versions: Python 2.7 Added file: http://bugs.python.org/file19174/_json.c.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10055 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8533] regrtest: use backslashreplace error handler for stdout
Hirokazu Yamamoto ocean-c...@m2.ccsnet.ne.jp added the comment: Oops, sorry. I'll withdraw my last patch. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8533 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8533] regrtest: use backslashreplace error handler for stdout
Changes by Hirokazu Yamamoto ocean-c...@m2.ccsnet.ne.jp: Removed file: http://bugs.python.org/file19170/py3k_also_no_unicode_error_on_direct_test_run.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8533 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9992] Command line arguments are not correctly decodedif locale and fileystem encodings aredifferent
Martin v. Löwis mar...@v.loewis.de added the comment: Antoine: Python cannot possibly know whether a command line argument is meant as a file name or as some other text, and what encoding the receiving application will apply to it (if any). I agree it's best to have all IO encodings being the same in Python, but perhaps there are use cases where you have to use a different encoding for file names, so I don't think it is necessary to rip this feature out. So perhaps it would be best if Python had two external default encodings: the IO one (command line arguments, environment variables, text files), and the file name encoding (defaulting to the IO encoding if not set). If they differ and you get mojibake in subprocesses: bad luck - it's exactly what you asked for. The fsname encoding should *only* be used for file names, not for command line arguments in subprocess. If we have tests that rely on the fsname encoding and the IO encoding being the same, then those tests should get skipped if the encodings are actually different. The tricky parts remains determining the IO encoding. If PYTHONIOENCODING can override the locale's encoding, then the tricky question is how command line arguments should get decoded in absence of the codec machinery on Unix. They must get decoded for uniformity with Windows (which received the command line as a Unicode string already). That problem may be the reason why we need *three* encodings (as it is now), the IOENCODING only applying to file streams. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9992 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10053] Don’t close fd when FileIO.__ini t__ fails
Changes by Éric Araujo mer...@netwok.org: -- nosy: +pitrou title: Probably fd should not be closed when FileIO#__init__ failed - Don’t close fd when FileIO.__init__ fails ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10053 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9992] Command line arguments are not correctly decodedif locale and fileystem encodings aredifferent
Antoine Pitrou pit...@free.fr added the comment: Antoine: Python cannot possibly know whether a command line argument is meant as a file name or as some other text, and what encoding the receiving application will apply to it (if any). I understand. But practicality seems to suggest that, most of the time, non-ASCII arguments on a command line will be filenames. We should probably try to favour the common case (barring implementation issues, though, and it seems using the filesystem encoding in the interpreter bootup phase is not easy). So perhaps it would be best if Python had two external default encodings: the IO one (command line arguments, environment variables, text files), and the file name encoding (defaulting to the IO encoding if not set). Looking at environment variables here, they seem to be either: - integers (pids, port numbers...) - conventional variables (such as fr_FR.utf8) - usernames - file paths The most likely values to be non-ASCII are, therefore, file paths. So it would make sense to also use the filesystem encoding for environment variables (so as to satisfy the common case). As for text files, I agree it's different, and the encoding choice routine in TextIOWrapper already favours locale.getpreferredencoding() and ignores the filesystem encoding. If we have tests that rely on the fsname encoding and the IO encoding being the same, then those tests should get skipped if the encodings are actually different. Agreed, but only when this discussion has come to a conclusion :) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9992 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue812369] module shutdown procedure based on GC
Antoine Pitrou pit...@free.fr added the comment: The patch is obviously against 2.x (there are some PyString_Check's on module names, for example). It should be regenerated against 3.x. Also, it would be nice if a test could be devised to check that the shutdown procedure works as expected (I'm not sure how such a test would look like). -- versions: -Python 2.7, Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue812369 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10056] Can't build tkinter with libtk 8.6
New submission from Antoine Pitrou pit...@free.fr: This is only with 3.1. Following patch allows building: Index: setup.py === --- setup.py(révision 85336) +++ setup.py(copie de travail) @@ -1450,7 +1450,7 @@ # The versions with dots are used on Unix, and the versions without # dots on Windows, for detection by cygwin. tcllib = tklib = tcl_includes = tk_includes = None -for version in ['8.5', '85', '8.4', '84', '8.3', '83', '8.2', +for version in ['8.6', '86', '8.5', '85', '8.4', '84', '8.3', '83', '8.2', '82', '8.1', '81', '8.0', '80']: tklib = self.compiler.find_library_file(lib_dirs, 'tk' + version) tcllib = self.compiler.find_library_file(lib_dirs, 'tcl' + version) However, there is then a test failure: == FAIL: test_tag_configure (tkinter.test.test_ttk.test_widgets.TreeviewTest) -- Traceback (most recent call last): File /home/antoine/py3k/31/Lib/tkinter/test/test_ttk/test_widgets.py, line 1116, in test_tag_configure 'blue') AssertionError: color object at 0x202a8f0 != 'blue' -- assignee: gpolo components: Build messages: 118260 nosy: gpolo, pitrou priority: normal severity: normal status: open title: Can't build tkinter with libtk 8.6 type: compile error versions: Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10056 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10056] Can't build tkinter with libtk 8.6
Antoine Pitrou pit...@free.fr added the comment: Fixed in r85337. -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10056 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8445] buildbot: test_ttk_guionly failures (test_traversal, test_tab_identifiers, test_identify, test_heading_callback)
Antoine Pitrou pit...@free.fr added the comment: I backported the patch to 2.7 (r85335) and to 3.1 (r85338). Hopefully things will be ok now. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8445 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9992] Command line arguments are not correctly decodedif locale and fileystem encodings aredifferent
Martin v. Löwis mar...@v.loewis.de added the comment: The most likely values to be non-ASCII are, therefore, file paths. So it would make sense to also use the filesystem encoding for environment variables (so as to satisfy the common case). -1. Environment variables are typically set in a text editor or on the command line, so they will typically have the locale's encoding. Applications that wish to support the case that fsencoding != locale can recode the file names if desired, or use environb in the first place. If the mere existence of the fsname encoding leads to that much confusion, I think I also support its removal. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9992 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9992] Command line arguments are not correctly decodedif locale and fileystem encodings aredifferent
Antoine Pitrou pit...@free.fr added the comment: -1. Environment variables are typically set in a text editor or on the command line, so they will typically have the locale's encoding. Fair enough. If the mere existence of the fsname encoding leads to that much confusion, I think I also support its removal. Well, the fsname encoding has a hardwired value under OS X (regardless of the locale), which kind of justifies its existence, no? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9992 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9951] introduce bytes.hex method
Changes by Arnon Yaari wiggi...@gmail.com: Added file: http://bugs.python.org/file19175/bytes.hex.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9951 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9951] introduce bytes.hex method
Changes by Arnon Yaari wiggi...@gmail.com: Removed file: http://bugs.python.org/file19018/bytes.hex.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9951 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1553375] Add traceback.print_full_exception()
Pascal Chambon chambon.pas...@gmail.com added the comment:
Indeed I don't understand the following part :
+Traceback (most recent call last):
+ File testmod.py, line 16, in module
+{exception_action}
+ File testmod.py, line 6, in foo
+bar()
+ File testmod.py, line 11, in bar
+raise Exception
+Exception
Why does the f_back of the first exception, when chain=True, leads back to the
{exception_action} part, in the except: black, instead of the initial foo()
call inside the try: block ?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1553375
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10052] Python/dtoa.c:158: #error Failed to find an exact-width 32-bit integer type (FreeBSD 4.11 + gcc 2.95.4)
Changes by Eric Smith e...@trueblade.com: -- nosy: +eric.smith, mark.dickinson ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10052 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1553375] Add traceback.print_full_exception()
Vinay Sajip vinay_sa...@yahoo.co.uk added the comment: The regression tests are failing for me, see http://gist.github.com/618117 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1553375 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1553375] Add traceback.print_full_exception()
Vinay Sajip vinay_sa...@yahoo.co.uk added the comment: Also, fullstack remains in one place in the docs. Should now say allframes. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1553375 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9992] Command line arguments are not correctly decodedif locale and fileystem encodings aredifferent
Martin v. Löwis mar...@v.loewis.de added the comment: If the mere existence of the fsname encoding leads to that much confusion, I think I also support its removal. Well, the fsname encoding has a hardwired value under OS X (regardless of the locale), which kind of justifies its existence, no? Perhaps. We could also declare that command line arguments and environment variables are always UTF-8-encoded on OSX (which I think would be fairly accurate), and stop relying on the locale to determine encodings on OSX (which Apple didn't like as a mechanism, anyway). I think OSX converges faster to UTF-8 than the other Unices. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9992 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9992] Command line arguments are not correctly decodediflocale and fileystem encodingsaredifferent
STINNER Victor victor.stin...@haypocalc.com added the comment: Perhaps. We could also declare that command line arguments and environment variables are always UTF-8-encoded on OSX (which I think would be fairly accurate) Python uses the filesystem encoding to encode/decode environment variables, and OSX, fs encoding is utf-8. For the command line, it would mean that we introduced a new encoding: command line encoding, which will be utf-8 on OSX. -- title: Command line arguments are not correctly decodedif localeand fileystem encodings aredifferent - Command line arguments are not correctly decodediflocaleand fileystem encodingsaredifferent ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9992 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9992] Command line arguments are not correctly decodediflocale and fileystem encodingsaredifferent
Antoine Pitrou pit...@free.fr added the comment: For the command line, it would mean that we introduced a new encoding: command line encoding, which will be utf-8 on OSX. Or more generally environment encoding, if it's also used for env vars. This could solve the subprocess issue neatly. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9992 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9992] Command line arguments are not correctly decodediflocale and fileystem encodingsaredifferent
STINNER Victor victor.stin...@haypocalc.com added the comment: So perhaps it would be best if Python had two external default encodings: the IO one (command line arguments, environment variables, text files), and the file name encoding (defaulting to the IO encoding if not set) Hum, I prefer to consider the FS encoding as an *internal* encoding. ... But it's not completly true: it is used for the environment variables. Let's consider that FS encoding is only an internal encoding. Wee need 3 encodings: - FS encoding: any operation on the filesystem - IO encoding: text file contents (included stdin, stdout, stderr which are text files) - a 3rd encoding (let's call it the command line encoding): used for the command line arguments and the environment variables For technical reasons (bootstrap: Python initialization issues), I would like that the 3rd encoding is set using the locale encoding. The user can only control it using the classical locale variables (LC_ALL, LC_CTYPE, LANG). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9992 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9951] introduce bytes.hex method
Arnon Yaari wiggi...@gmail.com added the comment: fixed to Py_UNICODE -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9951 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8445] buildbot: test_ttk_guionly failures (test_traversal, test_tab_identifiers, test_identify, test_heading_callback)
Stephen Hansen me+pyt...@ixokai.io added the comment: For the record, everything (2.7, 3.1, and 3.x) runs this test successfully now. :) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8445 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10049] Add a no-op (null) context manager to contextlib
Hrvoje Nikšić hnik...@gmail.com added the comment: Here is a more complete patch that includes input from Nick, as well as the patch to test_contextlib.py and the documentation. For now I've retained the function-returning-singleton approach for consistency and future extensibility. -- keywords: +patch Added file: http://bugs.python.org/file19176/nullcontext.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10049 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1553375] Add traceback.print_full_exception()
R. David Murray rdmur...@bitdance.com added the comment: Pascal: my question exactly. The question is whether the code is accurately reflecting the state of the python stack at exception time (which it seems like it ought to), in which case I don't understand how Python handles the chained exception, or it doesn't, in which case (more likely) I'm not understanding how the stack frame is put together. Vinay: so in your run the subprocess call is not producing the final 'exception detail' line...it looks like the last line of the output from subprocess is getting lost. I've updated the patch to add a p.wait() before the assert...can you see if that fixes it? I also fixed the doc nit, thanks. -- Added file: http://bugs.python.org/file19177/full_traceback3.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1553375 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9003] urllib.request and http.client should allow certificate checking
Antoine Pitrou pit...@free.fr added the comment: Here is another patch for http.client containing more tests, including with a mismatching cert. Comments welcome. -- Added file: http://bugs.python.org/file19178/httpcli2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9003 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10055] C99 code in _json.c
Antoine Pitrou pit...@free.fr added the comment: Fixed in 3.2 (r85342), 3.1 (r85343) and 2.7 (r85344). Thank you! -- nosy: +pitrou resolution: - fixed stage: - committed/rejected status: open - closed versions: +Python 3.1, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10055 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9951] introduce bytes.hex method
Changes by Benjamin Peterson benja...@python.org: -- Removed message: http://bugs.python.org/msg117862 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9951 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9992] Command line arguments are not correctly decodediflocale and fileystem encodingsaredifferent
Martin v. Löwis mar...@v.loewis.de added the comment: Am 09.10.2010 14:07, schrieb Antoine Pitrou: Antoine Pitrou pit...@free.fr added the comment: For the command line, it would mean that we introduced a new encoding: command line encoding, which will be utf-8 on OSX. Or more generally environment encoding, if it's also used for env vars. This could solve the subprocess issue neatly. Please no. We run into problems because we have two inconsistent encodings, and now you propose to introduce another one, allowing for even more inconsistencies??? -- title: Command line arguments are not correctly decodediflocale and fileystem encodingsaredifferent - Command line arguments are not correctly decodediflocale and fileystem encodingsaredifferent ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9992 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9992] Command line arguments are not correctly decodediflocale and fileystem encodingsaredifferent
Antoine Pitrou pit...@free.fr added the comment: Please no. We run into problems because we have two inconsistent encodings, and now you propose to introduce another one, allowing for even more inconsistencies??? It would not really be a third encoding, since it would replace the locale encoding for all pratical purposes, if I understand Victor's proposal correctly. -- title: Command line arguments are not correctly decodediflocale and fileystem encodingsaredifferent - Command line arguments are not correctly decodediflocale and fileystem encodingsaredifferent ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9992 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10008] Two links point to same place
Terry J. Reedy tjre...@udel.edu added the comment: *Your initial post* only lists one index entry, and *does not* describe a problem. Thread module is in the file you have pointed to twice, in its alphabetical position. I have no idea what you think is wrong with the z section. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10008 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10057] Unclear if exception should be set
New submission from Jan Kratochvil jan.kratoch...@redhat.com: http://docs.python.org/py3k/c-api/object.html PyObject_GetItem Return element [...] or NULL on failure. Found element = return its pointer. Found no element = return NULL (with no exception set). But it is unclear whether the function can also: Error happened = return NULL with an exception set. It affects multiple versions of the doc, did not check which all. -- assignee: d...@python components: Documentation messages: 118281 nosy: d...@python, jankratochvil priority: normal severity: normal status: open title: Unclear if exception should be set versions: Python 2.7, Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10057 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10057] Unclear if exception should be set
Martin v. Löwis mar...@v.loewis.de added the comment: I find it quite clear. failure not only means that no item was found, but also that the operation failed, i.e. raised an exception. In general, a NULL pointer returned from a function that returns PyObject* *always* means that there is an exception. There is no need to repeat that every time. -- nosy: +loewis ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10057 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10057] Unclear if exception should be set
Jan Kratochvil jan.kratoch...@redhat.com added the comment: OK, I am not used to Python, thanks. -- resolution: - invalid status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10057 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1553375] Add traceback.print_full_exception()
R. David Murray rdmur...@bitdance.com added the comment: After giving this some thought, I'm sure that the observed results are not what we want, so I've changed the test to be the result that we want. I haven't been able to figure out what is causing it, and am starting to wonder if it represents an actual bug in exception handling. -- Added file: http://bugs.python.org/file19179/full_traceback4.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1553375 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1553375] Add traceback.print_full_exception()
Vinay Sajip vinay_sa...@yahoo.co.uk added the comment: It's still failing - the existing gist has been updated with the output from the new run: http://gist.github.com/618117 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1553375 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1553375] Add traceback.print_full_exception()
R. David Murray rdmur...@bitdance.com added the comment: vinay: duh. I'm using a debug build and my test is slicing off the refount line. I think there's a helping in test.support for that... -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1553375 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1553375] Add traceback.print_full_exception()
Vinay Sajip vinay_sa...@yahoo.co.uk added the comment:
David, I don't think it's that - I think it's the subprocess comms. This works:
def _do_test(self, program, exc_text):
with open(self.testfn, 'w') as testmod:
testmod.writelines(program.format(
exception_action=self.exception_action))
p = subprocess.Popen([sys.executable, 'testmod.py'],
stderr=subprocess.PIPE)
streams = p.communicate()
v1 = streams[1].decode('utf-8') # this shouldn't be hardcoded!
v2 = exc_text.format(exception_action=self.exception_action)
self.assertEqual(v1, v2)
But I don't think the 'utf-8' encoding should be hardcoded. Not sure what to
use - sys.getfilesystemencoding()? locale.getpreferredencoding()?
Decisions, decisions :-(
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1553375
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1553375] Add traceback.print_full_exception()
Vinay Sajip vinay_sa...@yahoo.co.uk added the comment: Also, the use of literal 'testmod.py' in _do_test should probably be replaced by self.testfn. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1553375 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1553375] Add traceback.print_full_exception()
Vinay Sajip vinay_sa...@yahoo.co.uk added the comment: On reflection, perhaps we should use sys.stdin.encoding to decode the value received from the subprocess. What do you think? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1553375 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1553375] Add traceback.print_full_exception()
Vinay Sajip vinay_sa...@yahoo.co.uk added the comment: Attached a patch which works on my machine. -- Added file: http://bugs.python.org/file19180/full_traceback5.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1553375 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9003] urllib.request and http.client should allow certificate checking
geremy condra debat...@gmail.com added the comment: Any chance on folding the HTTPSServer class into http.server? Geremy Condra -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9003 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9003] urllib.request and http.client should allow certificate checking
Antoine Pitrou pit...@free.fr added the comment: Any chance on folding the HTTPSServer class into http.server? Its API and implementation would first have to be cleaned up. I'd prefer if it were the subject of a separate issue. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9003 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10052] Python/dtoa.c:158: #error Failed to find an exact-width 32-bit integer type (FreeBSD 4.11 + gcc 2.95.4)
Mark Dickinson dicki...@gmail.com added the comment: Thanks for the report. Some questions: 1. Have you tested this with Python 3.x at all? I'd expect the same issues to show up for Python 3.1 and 3.2. 2. Also, do you have the relevant configure output to hand? On my machine, the output from './configure' includes: checking for uint32_t... yes checking for uint64_t... yes checking for int32_t... no checking for int64_t... no checking for ssize_t... yes what do you get here? (Aside: those 'no's look odd to me; I think there may be an autoconf bug here.) 3. Do you know which header file declares uint32_t on FreeBSD 4? IIRC, the theory is that if stdint.h or inttypes.h #defines/typedefs uint32_t, then the UINT32_T_MAX macro should also be #defined somewhere in one of those header files; OTOH if neither stdint nor inttypes includes declarations for uint32_t then the configure script should find something suitable, and #define uint32_t. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10052 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10058] Unclear PyString_AsStringAndSize return value
New submission from Nikolaus Rath nikol...@rath.org: http://docs.python.org/c-api/string.html says about the return value of AsStringAndSize: If length is NULL, the resulting buffer may not contain NUL characters; if it does, the function returns -1 and a TypeError is raised. If string is not a string object at all, PyString_AsStringAndSize() returns -1 and raises TypeError. This makes me wonder what the return code is if a) the function succeeds and b) it encounteres some other problem (i.e. out of memory when it tries to encode a unicode string into its default encoding). I guess that the return value is 0 on success and -1 on all errors, but it would be nice if the documentation would be clear about this. -- assignee: d...@python components: Documentation messages: 118294 nosy: Nikratio, d...@python priority: normal severity: normal status: open title: Unclear PyString_AsStringAndSize return value type: feature request versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10058 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10008] Two links point to same place
Hirokazu Yamamoto ocean-c...@m2.ccsnet.ne.jp added the comment: Well, please see r85262 (10/6). This issue seems to be recently solved in release27-maint. And http://docs.python.org/ was updated after that, so when I posted this issue, the issue was actually there, but when you saw that site, (probably after 10/6, the issue was gone) http://docs.python.org/release/2.7/ was created when officially Python2.7 was released, so we can see this issue still there. Like time machine. ;-) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10008 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10059] add the method `index` to collections.deque
New submission from Simon Liedtke liedtke.si...@googlemail.com: I'd like to have the method `index` not only for list, but also for collections.deque. Here is my attempt: http://bitbucket.org/derdon/hodgepodge/src/tip/extended_deque.py I'm looking forward to see this method implemented in the stdlib! -- components: Library (Lib) messages: 118296 nosy: Simon.Liedtke priority: normal severity: normal status: open title: add the method `index` to collections.deque type: feature request ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10059 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10059] add the method `index` to collections.deque
Ned Deily n...@acm.org added the comment: Since you are requesting adding a method to an existing data type, you should probably raise this issue first on the python-ideas mailing list and be prepared to justify use cases for it. http://mail.python.org/mailman/listinfo/python-ideas -- nosy: +ned.deily, rhettinger, stutzbach versions: +Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10059 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10060] python.exe crashes or hangs on help() modules when bad modules found
New submission from Dev Player devpla...@gmail.com: 2010-10-10 python.exe crashes or hangs on help() modules when bad modules found ### SUMMARY The python.exe command line interpreter crashes or hangs when typing first help() then modules and a corrupt module is found. Python 2.7 WinXP SP3 see version details in OUTPUT sections ### EXPLANATION # --- I have a workaround as a user. However it appears to be a bug from previous Python versions, 2.5 and 2.6 from what I've seen through Google and other help() module tickets. The workaround is simply remove the corrupt package. # --- I've noticed when there is a corrupt package on my PC in the Q:\Python27\Lib\site-packages folder that seems to cause a problem when issuing help() then modules in Python. Python command line interperter doesn't gracefully exit the assertion, it crashes or hangs. When entering python.exe, idle.exe or pycrust.bat (runs pycrust.py), typing help(), then typing modules, the help routine runs most of the search-for-packages routine fine (see OUTPUT SECTION below) and seems to find all the installed modules but when it's finished it does the following: - python.exe either crashes, or puts up a help prompt window and then drops to the DOS command prompt as seen below. MS window error: python.exe has encountered a problem and needs to clos. We are sorry for the inconvienience AppName: python.exe AppVer: 0.0.0.0 ModName: unknown ModVer: 0.0.0.0 Offset: 00a20fdf - IDLE.py doesn't crash but after the help() modules it shows the errors in .py files - PyCrust.py runs the help() modules it then shows errors in .py files, it then crashes In my case you will note the problem occurs on my install of the pythonwin package. On my system pythonwin will work until I exit. I installed a new version pythonwin just after installing Python 2.7. The pythonwin version always crashed on exit since it was installed. The old pythonwin was deinstalled before installation of the new. However, having a corrupt installed package shouldn't crash python. pythonwin version: pywin32 build214 # --- Something of note: All my development, including Python 2.7 installation and packages and projects are on my Q: drive, which is a mapped drive pointing to a sub-folder on a networked-shared folder in WinXP. Actual Folder: D:\SUBST_DRIVES\DRIVE_Q_DEVELOPMENT Net-shared Folder: \\Mycomp\D$\Subst_drives Mapped Folder: Q: = \\Mycomp\D$\Subst_drives\DRIVE_Q_DEVELOPMENT Although not directly used by the user (me) I also have subst'd drives attached to sub-folders of: D:\SUBST_DRIVES\DRIVE_Q_DEVELOPMENT such as: U: = D:\SUBST_DRIVES\DRIVE_Q_DEVELOPMENT\Projects\Python27\current I only mention this in case the help() modules routine, while seeking modules, can traverse folder structure attached to soft and hard link combos, symbolic links and junction points or whether they have an effect on traversing the folder structure while searching for packages. However, I went directly to the folder holding python.exe at D:\SUBST_DRIVES\DRIVE_Q_DEVELOPMENT\Python27\python.exe When doing help() modules .\python.exe crashed at the end of executing modules as well. # --- So far, I personally have not come across any other issues with my installation and python programs and demo code run with Python 2.7 except the previously noted exiting-of-pythonwin # --- Further details and output from running help() modules below for each of python.exe, pycrust and idle. ### OUTPUT (3 Sections for 3 programs packaged with Python distribution) ### ### ### SECTION 1 OF 3 python.exe #-- Q:\Projects\Python27python.exe Python 2.7 (r27:82525, Jul 4 2010, 09:01:59) [MSC v.1500 32 bit (Intel)] on win32 Type help, copyright, credits or license for more information. help() Welcome to Python 2.7! This is the online help utility. If this is your first time using Python, you should definitely check out the tutorial on the Internet at http://docs.python.org/tutorial/. Enter the name of any module, keyword, or topic to get help on writing Python programs and using Python modules. To quit this help utility and return to the interpreter, just type quit. To get a list of available modules, keywords, or topics, type modules, keywords, or topics. Each module also comes with a one-line
[issue10052] Python/dtoa.c:158: #error Failed to find an exact-width 32-bit integer type (FreeBSD 4.11 + gcc 2.95.4)
Akira Kitada akit...@gmail.com added the comment: 1. Have you tested this with Python 3.x at all? I'd expect the same issues to show up for Python 3.1 and 3.2. Yes, I can reproduce this in 2.7, 3.1 and 3.2. 2. Also, do you have the relevant configure output to hand? On my machine, the output from './configure' includes: checking for uint32_t... yes checking for uint64_t... yes checking for int32_t... no checking for int64_t... no checking for ssize_t... yes what do you get here? (Aside: those 'no's look odd to me; I think there may be an autoconf bug here.) Same here. It looks like a bug in autoconf: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=560105 My output is below: checking for uint32_t... yes checking for uint64_t... yes checking for int32_t... no checking for int64_t... no checking for ssize_t... yes 3. Do you know which header file declares uint32_t on FreeBSD 4? They are declared in inttypes.h. /* * This file is in the public domain. * $FreeBSD: src/sys/sys/inttypes.h,v 1.2 1999/08/28 00:51:47 peter Exp $ */ #ifndef _SYS_INTTYPES_H_ #define _SYS_INTTYPES_H_ #include machine/ansi.h typedef __int8_tint8_t; typedef __int16_t int16_t; typedef __int32_t int32_t; typedef __int64_t int64_t; typedef __uint8_t uint8_t; typedef __uint16_t uint16_t; typedef __uint32_t uint32_t; typedef __uint64_t uint64_t; typedef __intptr_t intptr_t; typedef __uintptr_t uintptr_t; #endif /* !_SYS_INTTYPES_H_ */ -- versions: +Python 3.1, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10052 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: [issue10029] Equivalent to code for zip is wrong in Python 3
On Fri, Oct 08, 2010 at 06:25:26PM +, Alexander Belopolsky wrote: In this case, I wonder if equivalent to code should be added to the section for enumerate() and map(). Also since any() and all() have equivalent to code, I think min(), max() and sum() deserve it as well. I think, you are asking for consistency in docs, right? As a sidenote those explanations should be okay, but merging it with the explanation of the functions may add to confusion (like the zip example did in this case). Even I am +1 on removing that complex equivalent code in the zip documentation, as it can confusing to the newcomer. But I am also okay with moving that 'equivalent to code' further down in the explanation. ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10049] Add a no-op (null) context manager to contextlib
Changes by Nick Coghlan ncogh...@gmail.com: -- assignee: - ncoghlan ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10049 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10060] python.exe crashes or hangs on help() modules when bad modules found
R. David Murray rdmur...@bitdance.com added the comment: There isn't much that Python can do if there is a sufficiently broken C-based module in sys.path. All you report about the problematic module is that it is 'bad' or 'corrupt'. Can you give more information about what makes it bad? -- nosy: +r.david.murray ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10060 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10054] select extension does not build on platforms where uintptr_t is provided in inttypes.h
Akira Kitada akit...@gmail.com added the comment: It seems this problem was introduced by a patch in issue7211. 3.1 branch does not have this problem because that patch was not applied to release31-maint. Is this intentional? -- versions: +Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10054 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10008] Two links point to same place
Terry J. Reedy tjre...@udel.edu added the comment: If I understand, the issue you were concerned about has been fixed. If so, please close this. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10008 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10059] add the method `index` to collections.deque
Raymond Hettinger rhettin...@users.sourceforge.net added the comment: The absence of index() from collections deque wasn't an oversight. Deques are not really about indexed access, they are about appending and popping from the ends. I'm curious about your use case and whether it is a good match for this data structure. -- assignee: - rhettinger components: +Extension Modules -Library (Lib) priority: normal - low ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10059 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10059] add the method `index` to collections.deque
Daniel Stutzbach dan...@stutzbachenterprises.com added the comment: Hello Simon, Accessing an arbitrary element of a deque takes O(n) time, making your .index implementation O(n**2). If you describe the kinds of operations that you need to perform efficiently, we may be able to suggest a better data structure for you to use. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10059 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10029] Equivalent to code for zip is wrong in Python 3
Raymond Hettinger rhettin...@users.sourceforge.net added the comment: Max, thanks for reporting this. I've replaced the sample code, making it work correctly and more clearly showing the logic. See r85345 and r85346. Daniel, we need to sync-up on the meaning of marking a report as accepted. Traditionally it denotes an approved patch, not a agreement that the bug is valid. -- resolution: accepted - fixed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10029 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10029] Equivalent to code for zip is wrong in Python 3
Changes by Raymond Hettinger rhettin...@users.sourceforge.net: -- status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10029 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
