[issue46625] timeout option of socket.create_connection is not respected
New submission from Nicolas SURRIBAS : When passing to socket.create_connection a timeout option above (approximately) 127 seconds, the timeout is not respected. Code to reproduce the issue : import socket from time import monotonic print(socket.getdefaulttimeout()) start = monotonic() try: socket.create_connection(("1.1.1.1", 21), 300) except Exception as exception: print(exception) print(monotonic() - start) Output at execution: None [Errno 110] Connection timed out 129.3075186319984 Expected behavior would be that the "Connection timed out" exception is raised after 300 seconds, as given in argument, not 129. Observed with Python 3.9.1 -- components: IO messages: 412443 nosy: Nicolas SURRIBAS priority: normal severity: normal status: open title: timeout option of socket.create_connection is not respected type: behavior versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue46625> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46284] DirEntry returns invalid values for is_dir and is_file on NFS
New submission from Nicolas SURRIBAS : Hello, I bumped into this strange behavior several times when using os.scandir on mounted NFS shares. I'm using Python 3.9.1 >>> path = b'/mnt/nfs_share/sdb1/System Volume Information/' >>> l = list(os.scandir(path)) >>> print(l[2].name) b'WPSettings.dat' >>> print(l[2].path) b'/mnt/nfs_share/sdb1/System Volume Information/WPSettings.dat' >>> print(l[2].is_file()) False >>> print(l[2].is_dir()) True >>> print(os.path.isfile(l[2].path)) True >>> print(os.path.isdir(l[2].path)) False -- components: Library (Lib) messages: 409869 nosy: Nicolas SURRIBAS priority: normal severity: normal status: open title: DirEntry returns invalid values for is_dir and is_file on NFS type: behavior versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue46284> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39632] variadic function call broken on armhf when passing a float argument
Nicolas Dessart added the comment: I've just rebased this PR but the CI builds failed (for unrelated reasons?). That being said I think that this particular issue should mostly be resolved by bpo-41100 and PR-22855 in particular. My PR 18560 still brings the support for Ellipsis/... inside ctypes function arguments type list. This is nice because it allows ctypes to automatically perform the necessary type promotions even if a variadic function is called without extra arguments. Since I've rebased my PR on top of bpo-41100 PRs, I had to resolve a few conflicts but didn't tried to limit the diff to the minimum (PR 18560 may be simplified). https://bugs.python.org/issue41100 https://github.com/python/cpython/pull/22855 -- versions: +Python 3.10, Python 3.11 ___ Python tracker <https://bugs.python.org/issue39632> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36207] robotsparser deny all with some rules
Nicolas added the comment: Sorry, I meant https://www.meridigital.com -- ___ Python tracker <https://bugs.python.org/issue36207> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36207] robotsparser deny all with some rules
Nicolas added the comment: Seems like we have the same issue with http://meridigital.com/robots.txt -- nosy: +nico702 -matthieuhemea ___ Python tracker <https://bugs.python.org/issue36207> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40664] Documentation error: itertools.dropwhile(is_even, itertools.count()) output
Nicolas Gimenez added the comment: Relase: 0.32 Lang: English Python version: 3.8.3 -- ___ Python tracker <https://bugs.python.org/issue40664> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40664] Documentation error: itertools.dropwhile(is_even, itertools.count()) output
New submission from Nicolas Gimenez : On this page: https://docs.python.org/3/howto/functional.html The example: "itertools.dropwhile(is_even, itertools.count()) => 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, ..." is wrong. It should be: "itertools.dropwhile(is_even, itertools.count()) => 1, 3, 5, 7, 9, ..." -- assignee: docs@python components: Documentation messages: 369146 nosy: docs@python, nicobao priority: normal severity: normal status: open title: Documentation error: itertools.dropwhile(is_even, itertools.count()) output versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue40664> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39632] variadic function call broken on armhf when passing a float argument
Nicolas Dessart added the comment: As I said in the associated PR, the build is failing on macOS because ctypes uses an obsolete libffi version bundled into Modules/_ctypes/libffi_osx for this platform. This old version of libffi is missing ffi_prep_cif_var. There is an open issue that propose to remove the bundled libffi for OSX. https://bugs.python.org/issue28491 -- versions: -Python 2.7, Python 3.5, Python 3.6 ___ Python tracker <https://bugs.python.org/issue39632> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39632] variadic function call broken on armhf when passing a float argument
Change by Nicolas Dessart : -- versions: +Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue39632> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39632] variadic function call broken on armhf when passing a float argument
Change by Nicolas Dessart : -- pull_requests: +17940 stage: -> patch review pull_request: https://github.com/python/cpython/pull/18560 ___ Python tracker <https://bugs.python.org/issue39632> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39632] variadic function call broken on armhf when passing a float argument
Change by Nicolas Dessart : Removed file: https://bugs.python.org/file48895/ctypes_variadic_function_tests.diff ___ Python tracker <https://bugs.python.org/issue39632> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39632] variadic function call broken on armhf when passing a float argument
Change by Nicolas Dessart : Added file: https://bugs.python.org/file48896/ctypes_variadic_function_tests.diff ___ Python tracker <https://bugs.python.org/issue39632> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39632] variadic function call broken on armhf when passing a float argument
New submission from Nicolas Dessart : On armhf and for variadic functions (and contrary to non-variadic functions), the VFP co-processor registers are not used for float argument parameter passing. This specificity is apparently completely disregarded by ctypes which always uses `ffi_prep_cif` to prepare the parameter passing of a function while it should most probably use `ffi_prep_cif_var` for variadic functions. As such variadic function call with float arguments through ctypes is currently broken on armhf targets. I think that ctypes API should be updated to let the user specify if a function is variadic. I've attached a patch to the ctypes unit tests that I'm using to reproduce this bug. pi@raspberrypi:~/code/cpython $ ./python -m test test_ctypes 0:00:00 load avg: 0.00 Run tests sequentially 0:00:00 load avg: 0.00 [1/1] test_ctypes _testfunc_d_bhilfd_var got 2 3 4 -1242230680 -0.00 -0.00 test test_ctypes failed -- Traceback (most recent call last): File "/home/pi/code/cpython/Lib/ctypes/test/test_functions.py", line 146, in test_doubleresult_var self.assertEqual(result, 21) AssertionError: -7.086855952261741e-44 != 21 test_ctypes failed == Tests result: FAILURE == 1 test failed: test_ctypes Total duration: 3.8 sec Tests result: FAILURE -- components: ctypes files: ctypes_variadic_function_tests.diff keywords: patch messages: 361992 nosy: Nicolas Dessart priority: normal severity: normal status: open title: variadic function call broken on armhf when passing a float argument versions: Python 3.9 Added file: https://bugs.python.org/file48895/ctypes_variadic_function_tests.diff ___ Python tracker <https://bugs.python.org/issue39632> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34155] email.utils.parseaddr mistakenly parse an email
Change by Nicolas Évrard : -- nosy: +nicoe ___ Python tracker <https://bugs.python.org/issue34155> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34798] pprint ignores the compact parameter for dicts
Nicolas Hug added the comment: Thanks for the link, But I don't see any justification for this behavior*? Why should lists be compacted but not dicts (even when explicitly asked)? At the very least it should be made clear in the documentation that dicts are not compacted. * Maybe there's more content in the patch reviews but I am unable to see them -- ___ Python tracker <https://bugs.python.org/issue34798> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34798] pprint ignores the compact parameter for dicts
Nicolas Hug added the comment: Sorry: [2] https://github.com/scikit-learn/scikit-learn/pull/11705/files#diff-f83e8d9362766b385472f1be7fed9482R96 -- ___ Python tracker <https://bugs.python.org/issue34798> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34798] pprint ignores the compact parameter for dicts
Nicolas Hug added the comment: Thank you for the feedback! I'll try the python-ideas mail list. I posted a message on Python-list [1] a few weeks ago but it didn't get much traction. I'm not sure about what the final solution could be (if any), but I had to hack pprint myself [2] for the scikit-learn project, and what I did was simply copy pasting _format_items into _format_dict_items, with some minimal changes. [1] https://mail.python.org/pipermail/python-list/2018-September/737082.html [2] -- ___ Python tracker <https://bugs.python.org/issue34798> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34798] pprint ignores the compact parameter for dicts
Change by Nicolas Hug : -- versions: +Python 3.8 -Python 3.7 ___ Python tracker <https://bugs.python.org/issue34798> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34798] pprint ignores the compact parameter for dicts
New submission from Nicolas Hug : Dict representations that exceed the line width are printed with one line per key-value pair, ignoring the compact=True parameter: >>> pprint.pprint({i: 0 for i in range(15)}, compact=True) {0: 0, 1: 0, 2: 0, 3: 0, 4: 0, 5: 0, 6: 0, 7: 0, 8: 0, 9: 0, 10: 0, 11: 0, 12: 0, 13: 0, 14: 0} Expected behavior: >>> pprint.pprint({i: 0 for i in range(15)}, compact=True) {0: 0, 1: 0, 2: 0, 3: 0, 4: 0, 5: 0, 6: 0, 7: 0, 8: 0, 9: 0, 10: 0, 11: 0, 12: 0, 13: 0, 14: 0} Note that lists are correctly compacted, and that dicts that don't exceed line width are printed on a single line, regardless on the compact parameter. I could try to work on that if needed? -- messages: 326358 nosy: Nicolas Hug priority: normal severity: normal status: open title: pprint ignores the compact parameter for dicts type: behavior versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue34798> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33934] locale.getlocale() seems wrong when the locale is yet unset (python3 on linux)
Nicolas Hainaux added the comment: I understand that the statement "when python starts, it runs using the C locale..." should not be correct anymore (and the doc should then be updated), but in fact this statement is still true on the systems I tested; only, the output of locale.getlocale() at start is in contradiction with the locale really set in fact. It looks like the setting done by setlocale(LC_ALL, "") at an early stage is lost at some point (only locale.getlocale() seems to "remember" it). For instance, my box locale is 'fr_FR.UTF-8', so the decimal point is a comma, but when starting python 3.7: >>> import locale >>> locale.str(2.4) '2.4' # Wrong: if the locale in use is 'fr_FR.UTF-8', then '2,4' is expected instead >>> locale.getlocale() ('fr_FR', 'UTF-8') >>> locale.localeconv() {'int_curr_symbol': '', 'currency_symbol': '', 'mon_decimal_point': '', 'mon_thousands_sep': '', 'mon_grouping': [], 'positive_sign': '', 'negative_sign': '', 'int_frac_digits': 127, 'frac_digits': 127, 'p_cs_precedes': 127, 'p_sep_by_space': 127, 'n_cs_precedes': 127, 'n_sep_by_space': 127, 'p_sign_posn': 127, 'n_sign_posn': 127, 'decimal_point': '.', 'thousands_sep': '', 'grouping': []} >>> Note that the output of localeconv() does match C locale, not 'fr_FR.UTF-8'. Compare this with the outputs of locale.str() and locale.localeconv() when the locale is explicitly set at start: >>> import locale >>> locale.setlocale(locale.LC_ALL, '') 'LC_CTYPE=fr_FR.utf8;LC_NUMERIC=fr_FR.UTF-8;LC_TIME=fr_FR.UTF-8;LC_COLLATE=fr_FR.utf8;LC_MONETARY=fr_FR.UTF-8;LC_MESSAGES=fr_FR.utf8;LC_PAPER=fr_FR.UTF-8;LC_NAME=fr_FR.UTF-8;LC_ADDRESS=fr_FR.UTF-8;LC_TELEPHONE=fr_FR.UTF-8;LC_MEASUREMENT=fr_FR.UTF-8;LC_IDENTIFICATION=fr_FR.UTF-8' >>> locale.str(2.4) '2,4' # Correct! >>> locale.localeconv() # Output of localeconv() does match 'fr_FR.UTF-8' >>> locale {'int_curr_symbol': 'EUR ', 'currency_symbol': '€', 'mon_decimal_point': ',', 'mon_thousands_sep': '\u202f', 'mon_grouping': [3, 0], 'positive_sign': '', 'negative_sign': '-', 'int_frac_digits': 2, 'frac_digits': 2, 'p_cs_precedes': 0, 'p_sep_by_space': 1, 'n_cs_precedes': 0, 'n_sep_by_space': 1, 'p_sign_posn': 1, 'n_sign_posn': 1, 'decimal_point': ',', 'thousands_sep': '\u202f', 'grouping': [3, 0]} >>> Maybe the title of this issue should be turned to "at start, the C locale is in use in spite of locale.getlocale()'s output (python3 on linux)"? As to the behaviour on Windows, I guess this is another topic (locales belonging to another world on Windows)... but it may be interesting to note that it complies with the current documentation: at start python 3.6 also uses the C locale, and the output of locale.getlocale() is consistent with that. Here is a test on Windows 10: Python 3.6.3 (v3.6.3:2c5fed8, Oct 3 2017, 18:11:49) [MSC v.1900 64 bit (AMD64)] on win32 >>> import locale >>> locale.getlocale() (None, None) >>> locale.localeconv() {'decimal_point': '.', 'thousands_sep': '', 'grouping': [], 'int_curr_symbol': '', 'currency_symbol': '', 'mon_decimal_point': '', 'mon_thousands_sep': '', 'mon_grouping': [], 'positive_sign': '', 'negative_sign': '', 'int_frac_digits': 127, 'frac_digits': 127, 'p_cs_precedes': 127, 'p_sep_by_space': 127, 'n_cs_precedes': 127, 'n_sep_by_space': 127, 'p_sign_posn': 127, 'n_sign_posn': 127} >>> locale.str(2.4) '2.4' >>> locale.getdefaultlocale() ('fr_FR', 'cp1252') -- components: +Library (Lib) -Documentation ___ Python tracker <https://bugs.python.org/issue33934> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33934] locale.getlocale() seems wrong when the locale is yet unset (python3 on linux)
Nicolas Hainaux added the comment: Sorry, I did not realize that using the word "unset" was completely misleading: I only meant "before any use of locale.setlocale() in python". So I'll rephrase this all, and add details about the python versions and platforms in this message. So, first, I do not unset the environment variables from the shell before running python. The only steps required to reproduce this behaviour are: open a terminal and run python3: Python 3.6.5 (default, May 11 2018, 04:00:52) [GCC 8.1.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import locale >>> locale.getlocale() ('fr_FR', 'UTF-8') # Wrong: the C locale is actually in use, so (None, None) is expected Explanation: when python starts, it runs using the C locale, on any platform (Windows, Linux, BSD), any python version (2, 3...), until locale.setlocale() is used to set another locale. This is expected (the doc says so in the getdefaultlocale() paragraph that you mentioned) and can be confirmed by the outputs of locale.localeconv() and locale.str(). So, before any use of locale.setlocale(), locale.getlocale() should return (None, None) (as this value matches the C locale). This is the case on Windows, python2 and 3, and on Linux and FreeBSD python2. But on Linux and FreeBSD, python>=3.4 (could not test 3.0<=python<=3.3), locale.getlocale() returns the value deduced from the environment variables instead, like locale.getdefaultlocale() already does, e.g. ('fr_FR', 'UTF-8'). All python versions I tested are from the platform distributors (3.7 only is compiled, but it's an automatic build from an AUR). Here is a more detailed list of the python versions and Linux and BSD platforms where I could observe this behaviour: - Python 3.4.8, 3.5.5, 3.6.5 and 3.7.0rc1 on an up to date Manjaro (with "LTS" kernel): Linux 4.14.48-2-MANJARO #1 SMP PREEMPT Fri Jun 8 20:41:40 UTC 2018 x86_64 GNU/Linux - Python 3.6.5 on Xubuntu 18.04 (as virtual box guest) Linux 4.15.0-23-generic #25-Ubuntu SMP Wed May 23 18:02:16 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux - Python 3.4.6 on openSUSE Leap 42.3 (as virtual box guest) Linux 4.4.76-1-default #1 SMP Fri Jul 14 08:48:13 UTC 2017 (9a2885c) x86_64 x86_64 x86_64 GNU/Linux - Python 3.4.8 and 3.6.1 on FreeBSD 10.4-RELEASE-p8 FreeBSD 10.4-RELEASE-p8 #0: Tue Apr 3 18:40:50 UTC 2018 r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 Problem of this behaviour on Linux and FreeBSD python>=3.4 is first, of course, that it's not consistent throughout all platforms, and second, that it makes it impossible for a python library to guess, from locale.getlocale() if the user (a python app) has set the locale or not (and is actually still using the C locale). (It is still possible to rely on locale.localeconv() to get correct elements). Hope this message made things clear now :-) -- versions: +Python 3.4, Python 3.5, Python 3.7 ___ Python tracker <https://bugs.python.org/issue33934> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33934] locale.getlocale() seems wrong when the locale is yet unset (python3 on linux)
New submission from Nicolas Hainaux : Expected behaviour: When unset, the locale in use is `C` (as stated in python documentation) and `locale.getlocale()` returns `(None, None)` on Linux with python2.7 or on Windows with python2.7 and python 3.6 (at least): $ python2 Python 2.7.15 (default, May 1 2018, 20:16:04) [GCC 7.3.1 20180406] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import locale >>> locale.getlocale() (None, None) >>> Issue: But when using python3.4+ on Linux, instead of `(None, None)`, `locale.getlocale()` returns the same value as `locale.getdefaultlocale()`: $ python Python 3.6.3 (default, Oct 24 2017, 14:48:20) [GCC 7.2.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import locale >>> locale.getlocale() ('fr_FR', 'UTF-8') >>> locale.localeconv() {'int_curr_symbol': '', 'currency_symbol': '', 'mon_decimal_point': '', 'mon_thousands_sep': '', 'mon_grouping': [], 'positive_sign': '', 'negative_sign': '', 'int_frac_digits': 127, 'frac_digits': 127, 'p_cs_precedes': 127, 'p_sep_by_space': 127, 'n_cs_precedes': 127, 'n_sep_by_space': 127, 'p_sign_posn': 127, 'n_sign_posn': 127, 'decimal_point': '.', 'thousands_sep': '', 'grouping': []} >>> locale.str(2.5) '2.5' Though the locale actually in use is still `C` (as shown above by the output of `locale.localeconv()` and confirmed by the result of `locale.str(2.5)`, which shows a dot as decimal point and not a comma (as expected with `fr_FR.UTF-8`)). I could observe this confusing behaviour on Linux with python3.4, 3.5, 3.6 and 3.7 (rc1). (Also on FreeBSD with python3.6.1). A problematic consequence of this behaviour is that it becomes impossible to detect whether the locale has already been set by the user, or not. I could not find any other similar issue and hope this is not a duplicate. -- components: Library (Lib) messages: 320192 nosy: zezollo priority: normal severity: normal status: open title: locale.getlocale() seems wrong when the locale is yet unset (python3 on linux) type: behavior versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7 ___ Python tracker <https://bugs.python.org/issue33934> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33911] [EASY] test_docxmlrpc fails when run with -Werror
Change by Nicolas Noé : -- keywords: +patch pull_requests: +7457 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue33911> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33911] [EASY] test_docxmlrpc fails when run with -Werror
Nicolas Noé added the comment: I'm willing to try solving this! -- nosy: +niconoe ___ Python tracker <https://bugs.python.org/issue33911> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28969] fnmatch is not threadsafe
New submission from Nicolas Savoire: With python3.5, fnmatch appears not to be thrad safe. It fails with the following exception: Traceback (most recent call last): File "test.py", line 18, in f.result() File "/opt/anaconda3/lib/python3.5/concurrent/futures/_base.py", line 405, in result return self.__get_result() File "/opt/anaconda3/lib/python3.5/concurrent/futures/_base.py", line 357, in __get_result raise self._exception File "/opt/anaconda3/lib/python3.5/concurrent/futures/thread.py", line 55, in run result = self.fn(*self.args, **self.kwargs) File "test.py", line 12, in foo fnmatch(ref, s) File "/opt/anaconda3/lib/python3.5/fnmatch.py", line 36, in fnmatch return fnmatchcase(name, pat) File "/opt/anaconda3/lib/python3.5/fnmatch.py", line 70, in fnmatchcase match = _compile_pattern(pat) KeyError: ('SXJ8WZ9F7Z', ) Here is a minimal example reproducing the issue: import concurrent.futures from fnmatch import fnmatch import random import string def str_generator(size=10, chars=string.ascii_uppercase + string.digits): return ''.join(random.choice(chars) for _ in range(size)) def foo(strs, ref): for s in strs: fnmatch(ref, s) some_strings = [str_generator() for _ in range(500)] with concurrent.futures.ThreadPoolExecutor() as executor: futures = [executor.submit(foo, some_strings, some_strings[0]) for _ in range(8)] for f in futures: f.result() $ python3 --version Python 3.5.2 :: Anaconda 4.2.0 (64-bit) -- components: Library (Lib) files: test.py messages: 283185 nosy: Nicolas Savoire priority: normal severity: normal status: open title: fnmatch is not threadsafe type: crash versions: Python 3.5 Added file: http://bugs.python.org/file45895/test.py ___ Python tracker <http://bugs.python.org/issue28969> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26552] Failing ensure_future still creates a Task
New submission from Damien Nicolas: When calling asyncio.ensure_future() on a coroutine, and if the loop is closed, ensure_future() will raise a RuntimeError. However, it still creates a Task, which will generate a RuntimeWarning that we can’t fix since there is no way to cancel the Task. Here is the code to reproduce the bug: import asyncio l = asyncio.get_event_loop() l.close() async def foo(): pass try: # Since the exception raises here, fut is never set # so we can't call fut.cancel() fut = asyncio.ensure_future(foo()) except RuntimeError: pass # stderr: # aio.py:12: RuntimeWarning: coroutine 'foo' was never awaited # pass -- components: asyncio messages: 261696 nosy: gordon, gvanrossum, haypo, yselivanov priority: normal severity: normal status: open title: Failing ensure_future still creates a Task type: behavior versions: Python 3.5 ___ Python tracker <http://bugs.python.org/issue26552> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26097] 2.7 documentation about TextTestRunner do not specify all the arguments
New submission from Nicolas Évrard: Some of the arguments although specified further in the documentation do not appear in the signature of TextTestRunner. Here's a simple patch to include them. -- assignee: docs@python components: Documentation files: unittest_doc_bug.diff keywords: patch messages: 258140 nosy: docs@python, nicoe priority: normal severity: normal status: open title: 2.7 documentation about TextTestRunner do not specify all the arguments type: enhancement versions: Python 2.7 Added file: http://bugs.python.org/file41600/unittest_doc_bug.diff ___ Python tracker <http://bugs.python.org/issue26097> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25675] doc for BaseEventLoop.run_in_executor() says its a coroutine, but it is not
Changes by Nicolas Demarchi : -- nosy: +gilgamezh ___ Python tracker <http://bugs.python.org/issue25675> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25358] Unexpected behaviour when converting large float to int
New submission from Nicolas Primeau: Converting arbitrarily large float type numbers to integer type number results in a non trivially different number. This can be repeated in all Python versions, same with Python 2 with longs. Expected behaviour would be an integer representation of 1e+44, and some_number == int_version. Example: >>> some_number = 1 >>> type(some_number) >>> float_version = float(some_number) >>> float_version 1e+44 >>> type(float_version) >>> int_version = int(float_version) >>> type(int_version) >>> int_version 18821361405306422640701865984 >>> int_version == some_number False >>> int_version == float_version True -- components: Interpreter Core messages: 252642 nosy: Nicolas Primeau priority: normal severity: normal status: open title: Unexpected behaviour when converting large float to int type: behavior versions: Python 3.5 ___ Python tracker <http://bugs.python.org/issue25358> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11943] Add TLS-SRP (RFC 5054) support to ssl, _ssl, http, and urllib
Changes by Nicolas Jouanin : -- nosy: +njouanin ___ Python tracker <http://bugs.python.org/issue11943> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19084] No way to use TLS-PSK from python ssl
Changes by Nicolas Jouanin : -- nosy: +njouanin ___ Python tracker <http://bugs.python.org/issue19084> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24875] pyvenv doesn´t install PIP inside a new venv with --system-site-package
New submission from Nicolas Demarchi: When Envbuilder creates a new virtualenv with system_site_packages=True, in the process of installing pip itself it actually doesn't install it inside the virtualenv because it is already there in the system. However when you do it manually using "virtualenv" it does install pip inside the virtualenv as you would expect to. ``` (22d667c6-e383-47be-9785-ec044008b654) ~/.local/share/fades/22d667c6-e383-47be-9785-ec044008b654 pwd /home/gilgamezh/.local/share/fades/22d667c6-e383-47be-9785-ec044008b654 (22d667c6-e383-47be-9785-ec044008b654) ~/.local/share/fades/22d667c6-e383-47be-9785-ec044008b654 ll total 16 drwxr-xr-x 2 gilgamezh users 4096 Aug 16 00:05 bin drwxr-xr-x 2 gilgamezh users 4096 Aug 16 00:05 include drwxr-xr-x 3 gilgamezh users 4096 Aug 16 00:05 lib lrwxrwxrwx 1 gilgamezh users3 Aug 16 00:05 lib64 -> lib -rw-r--r-- 1 gilgamezh users 68 Aug 16 00:05 pyvenv.cfg (22d667c6-e383-47be-9785-ec044008b654) ~/.local/share/fades/22d667c6-e383-47be-9785-ec044008b654 ll bin total 12 -rw-r--r-- 1 gilgamezh users 2251 Aug 16 00:05 activate -rw-r--r-- 1 gilgamezh users 1367 Aug 16 00:05 activate.csh -rw-r--r-- 1 gilgamezh users 2503 Aug 16 00:05 activate.fish lrwxrwxrwx 1 gilgamezh users7 Aug 16 00:05 python -> python3 lrwxrwxrwx 1 gilgamezh users 16 Aug 16 00:05 python3 -> /usr/bin/python3 (22d667c6-e383-47be-9785-ec044008b654) ~/.local/share/fades/22d667c6-e383-47be-9785-ec044008b654 bin/python -Im ensurepip --upgrade --default-pip -v Ignoring indexes: https://pypi.python.org/simple URLs to search for versions for setuptools in /usr/lib/python3.4/site-packages: Skipping link /tmp/tmpe8rbjkcq (from -f); not a file Skipping link file:///tmp/tmpe8rbjkcq/pip-6.0.8-py2.py3-none-any.whl; wrong project name (not setuptools) Found link file:///tmp/tmpe8rbjkcq/setuptools-12.0.5-py2.py3-none-any.whl, version: 12.0.5 Local files found: /tmp/tmpe8rbjkcq/setuptools-12.0.5-py2.py3-none-any.whl Installed version (18.1) is most up-to-date (past versions: 12.0.5) Requirement already up-to-date: setuptools in /usr/lib/python3.4/site-packages URLs to search for versions for pip in /usr/lib/python3.4/site-packages: Found link file:///tmp/tmpe8rbjkcq/pip-6.0.8-py2.py3-none-any.whl, version: 6.0.8 Skipping link file:///tmp/tmpe8rbjkcq/setuptools-12.0.5-py2.py3-none-any.whl; wrong project name (not pip) Local files found: /tmp/tmpe8rbjkcq/pip-6.0.8-py2.py3-none-any.whl Installed version (7.1.0) is most up-to-date (past versions: 6.0.8) Requirement already up-to-date: pip in /usr/lib/python3.4/site-packages Cleaning up... (22d667c6-e383-47be-9785-ec044008b654) ~/.local/share/fades/22d667c6-e383-47be-9785-ec044008b654 ``` "bin/python -Im ensurepip --upgrade --default-pip -v" is from /usr/lib/python3.4/venv/__init__.py line 255 -- components: Library (Lib) messages: 248673 nosy: gilgamezh priority: normal severity: normal status: open title: pyvenv doesn´t install PIP inside a new venv with --system-site-package type: behavior versions: Python 3.4 ___ Python tracker <http://bugs.python.org/issue24875> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21828] added/corrected containment relationship for networks in lib ipaddress
Changes by Nicolas Limage : -- nosy: -Nicolas.Limage resolution: -> duplicate status: open -> closed ___ Python tracker <http://bugs.python.org/issue21828> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21828] added/corrected containment relationship for networks in lib ipaddress
New submission from Nicolas Limage: The current version of the ipaddress library implements containment relationship in a way that a network is never contained in another network : >>> from ipaddress import IPv4Network,IPv4Address >>> IPv4Network(u'192.168.22.0/24') in IPv4Network(u'192.168.0.0/16') False I think it would be better to define the containment relationship between networks as such : - if network A contains all the ip addresses of network B, then B in A is True - by extension of this rule, A in A is True It is useful to quickly determine if a network is a subnet of another -- components: Library (Lib) files: ipaddress-network-containment.diff keywords: patch messages: 221350 nosy: Nicolas.Limage priority: normal severity: normal status: open title: added/corrected containment relationship for networks in lib ipaddress type: behavior versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5 Added file: http://bugs.python.org/file35737/ipaddress-network-containment.diff ___ Python tracker <http://bugs.python.org/issue21828> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16472] Distutils+mingw links agains msvcr90, while python27.dll is linked agains msvcrt
Nicolas Frattaroli added the comment: I had the same issue. It wouldn't just crash, it would crash sometimes, and not other times. About 50% of the time. The solution to remove msvcr as suggested by Marek did work. I didn't apply his patch, however, because I'm using a MinGW64Compiler definition instead of the standard mingw32 one, which I got from a different distutils bug with a submitted patch that hasn't been reviewed yet. Great work, gents. -- nosy: +fratti ___ Python tracker <http://bugs.python.org/issue16472> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15785] curses.get_wch() returns keypad codes incorrectly
Changes by Nicolas Schodet : -- nosy: -schodet ___ Python tracker <http://bugs.python.org/issue15785> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14223] curses addch broken on Python3.3a1
Changes by Nicolas Schodet : -- nosy: -schodet ___ Python tracker <http://bugs.python.org/issue14223> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13946] readline completer could return an iterable
New submission from Nicolas : The function set by readline.set_completer must return one completion per call. This should be great if we can return an iterable, because with current implementation I have to write a wrapper: cache = None def completer(text, state): if cache: if len(cache) > 0: return cache.pop(0) else: cache = None return None res = completer_returning_iterable(text) if isinstance(res, str) or res == None: return res cache = res return completer(text, state) readline.set_completer(completer) And completer_returning_list, the true completer, returns a pythonic iterable for all possible completion. -- components: Library (Lib) messages: 152703 nosy: nicolas_49 priority: normal severity: normal status: open title: readline completer could return an iterable type: enhancement versions: Python 3.1 ___ Python tracker <http://bugs.python.org/issue13946> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6774] socket.shutdown documentation: on some platforms, closing one half closes the other half
Nicolas Dumazet added the comment: > It's the other end which decides to return ENOTCONN upon shutdown(SHUT_RD) on > OS X, which is questionable > (not sure it's against the BSD socket API, since shutdown(SHUT_RD) doesn't > have any counterpart in the TCP layer). Exactly. The same code raises a socket.error in one platform (mac os) and not on another (linux). Why not document this questionable behavior? I'm sorry, I realize that my original patch was imprecise. I'm not an expert here, and I simply read http://svn.python.org/view/python/trunk/Lib/test/test_socket.py?r1=64125&r2=68611&pathrev=68611 . Ok, fine -- it doesn't close the other end per se, but shutdown(SH_RD) after a FIN on MacOS raises a socket.error . This is questionable, unexpected, and should be documented. If possible, I'd like to push for a rewording instead of a revert. -- ___ Python tracker <http://bugs.python.org/issue6774> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13525] Tutorial: Example of Source Code Encoding triggers error
Changes by Nicolas Goutte : Added file: http://bugs.python.org/file23841/windows_1252ok.py ___ Python tracker <http://bugs.python.org/issue13525> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13525] Tutorial: Example of Source Code Encoding triggers error
New submission from Nicolas Goutte : Current Behaviour The tutorial of Python 3.2.x has an example to set an encoding in a source file: http://docs.python.org/py3k/tutorial/interpreter.html#source-code-encoding It explains to set the following line at the start of the source code: # -*- coding: cp-1252 -*- However when done exactly so, Python raises the following exception: SyntaxError: encoding problem: with BOM The problem seems to be that Python knows Windows codepage 1252 as windows-1252 (its IANA charset name, see http://www.iana.org/assignments/charset-reg/windows-1252 ) or alternatively as cp1252 (without dash) but not as cp-1252 (with dash). As this is an example in the tutorial is particularly problematic, as users might not understand how to do it correctly. This is still the case in the tutorial of Python 3.3 alpha: http://docs.python.org/dev/tutorial/interpreter.html#source-code-encoding Expected Behaviour The tutorial should give a correct example, for example with: # -*- coding: windows-1252 -*- Alternatively a totally other example as for Python 2.7 would be nice too: http://docs.python.org/tutorial/interpreter.html#source-code-encoding Notes: I have tested this with following Python implementations: - Python 3.2.1 (openSUSE 12.1) on Linux - Python 3.2.2 on Windows 7 SP1 64 Bits - Python 3.2.2 on MacOS 10.5.8 (Always on the command line; I have not tested in IDLE.) -- assignee: docs@python components: Documentation files: cp_1252broken.py messages: 148798 nosy: docs@python, nicolasg priority: normal severity: normal status: open title: Tutorial: Example of Source Code Encoding triggers error versions: Python 3.2 Added file: http://bugs.python.org/file23840/cp_1252broken.py ___ Python tracker <http://bugs.python.org/issue13525> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10441] some stdlib modules need to be updated to handle SSL certificate validation
Nicolas Bareil added the comment: Martin v. Löwis writes: >> what do you think about a DeprecationWarning at runtime? > > What API exactly should this deprecate? Ooops, lapsus. I was thinking about a RuntimeWarning raised on HTTPS request (in httplib.HTTPSConnection.connect for instance). -- ___ Python tracker <http://bugs.python.org/issue10441> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10441] some stdlib modules need to be updated to handle SSL certificate validation
Nicolas Bareil added the comment: Hello, Your patch about SSLContext is great! But what can we do about python 2.x? I understand that we have to keep backward compatibility but something has to be done for improving current situation, even Paypal API (*) recommends using urllib.urlopen() to check sensitive things on HTTPS :( If backporting SSLContext into python 2.x is not an option, what do you think about a DeprecationWarning at runtime? Thanks, (*) https://www.x.com/devzone/articles/getting-started-paypal-django And even the popular Django paypal module uses urllib2 https://github.com/johnboxall/django-paypal -- nosy: +nbareil ___ Python tracker <http://bugs.python.org/issue10441> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13283] removal of two unused variable in locale.py
New submission from Nicolas Évrard : While using pyflake on some of my file I noticed in a copied version of _group two unused variables. The attached patch fixed that very little annoyance. -- components: Library (Lib) files: locale.diff keywords: patch messages: 146549 nosy: nicoe priority: normal severity: normal status: open title: removal of two unused variable in locale.py type: resource usage versions: Python 2.7 Added file: http://bugs.python.org/file23540/locale.diff ___ Python tracker <http://bugs.python.org/issue13283> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12147] smtplib.send_message does not implement corectly rfc 2822
Nicolas Estibals added the comment: Thanks for your help and the interesting discussion with this issue. -- ___ Python tracker <http://bugs.python.org/issue12147> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12147] smtplib.send_message does not implement corectly rfc 2822
Nicolas Estibals added the comment: Sorry for the late, my week-end was more busy than expected. Here is the corrected version of the patch. -- Added file: http://bugs.python.org/file22511/send_message_rfc2822_v2.patch ___ Python tracker <http://bugs.python.org/issue12147> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12147] smtplib.send_message does not implement corectly rfc 2822
Nicolas Estibals added the comment: I wasn't aware of the problem of guessing which are the correct Resent-* field, tthis does not seem to be that easy, however taking only the first one should be a good heuristic for next release. I think we now agree on the "automatic processing" part, this only for the receipt part and section 3.6.6 mostly means that From, To, ... fields schould be considered (not the Resent-* fields) while sending an answer for example. For our case it schould be ok to use them as long as ther is no ambiguity (only one Resent-* block). I'm ok for modifying my patch to reflect our discussion. You'll heard some news from it very soon. I'll also add the patch for not mutating the original message. After 3.2.1, I'll work on implementing the few api change you discuss this will make the code very usable. -- ___ Python tracker <http://bugs.python.org/issue12147> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12147] smtplib.send_message does not implement corectly rfc 2822
Nicolas Estibals added the comment: Hi, Treating this as a bug is a good news, if we don't user of the function will ask for python 3.3 I also think the part concerning the Sender header is pretty clear and we can fix it easily. About the Resent-* fields, I'm not sure of the right thing to do. But I haven't found the mention of no automatic processing for them but I found that RFC 2822 specify more exactly how to use them. Contrary to the other fields, they have to be in block and the more recent block have to be at the beginning of the mail, moreover they must not be reordered during transfer. Thus I think we have to consider the first block of Resent-* fields if present. (cf. RFC 2822 third paragraph in section 3.6 and appendix A.3) However perhaps we have to wait for an answer from email-sig. I have one more concern about the send_mesage method: if the Bcc field is present this one is deleted, thus we lose information if we copy it in a sent directory for instance. What do you think about the idea that send_message method should not modify the message ? (The sent message should get rid of the Bcc header but not the one the user keep after using the method.) Best regards. -- ___ Python tracker <http://bugs.python.org/issue12147> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12147] smtplib.send_message does not implement corectly rfc 2822
New submission from Nicolas Estibals : smtplib.send_message permits to send messages that are in python Message representation by selecting smtp's "from" and "to" in the message headers. Most of the time the implementation is correct but if the message is bounced (Resent-* headers have to be considered) or if there is a Sender field (this one supersede the From field if present), the current implementation does not select the right addresses (not as specified in rfc 2822). I have wrote a patch to make the method compliant. This is my first patch to python but I followed the "Lifecycle of a Patch" webpage and hope my code will be usable. Please ask me if some revision of the code is needed. -- components: Library (Lib) files: send_message_rfc2822.patch keywords: patch messages: 136508 nosy: Nicolas.Estibals priority: normal severity: normal status: open title: smtplib.send_message does not implement corectly rfc 2822 type: behavior versions: Python 3.2 Added file: http://bugs.python.org/file22061/send_message_rfc2822.patch ___ Python tracker <http://bugs.python.org/issue12147> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12000] SSL certificate verification failed if no dNSName entry in subjectAltName
Nicolas Bareil added the comment: Hello Mads > Until now Python failed to the safe side by not matching on > subjectAltName iPAddress but also not falling back to commonName > if they were specified. AFAICS, with this change it is possible to > create strange certificates that Python would accept when an IP > address matched commonName but other implementations would reject > because of iPAddress mismatch. Good point! But I think we already have this issue with a certificate like this one: cert = { 'subject': ((('commonName', '192.168.1.1'),),)} ok(cert, '192.168.1.1') Do you think this test should fail? -- ___ Python tracker <http://bugs.python.org/issue12000> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12000] SSL certificate verification failed if no dNSName entry in subjectAltName
Nicolas Bareil added the comment: Hello Antoine, Steffen, You are absolutely right about removing the 'not san' part. Here is the new patch, with tests : diff -r c22d5b37f6a4 Lib/ssl.py --- a/Lib/ssl.pyFri May 06 09:31:02 2011 +0300 +++ b/Lib/ssl.pyFri May 06 12:47:14 2011 +0200 @@ -122,8 +122,9 @@ if _dnsname_to_pat(value).match(hostname): return dnsnames.append(value) -if not san: -# The subject is only checked when subjectAltName is empty +if not dnsnames: +# The subject is only checked when there is no dNSName entry +# in subjectAltName for sub in cert.get('subject', ()): for key, value in sub: # XXX according to RFC 2818, the most specific Common Name diff -r c22d5b37f6a4 Lib/test/test_ssl.py --- a/Lib/test/test_ssl.py Fri May 06 09:31:02 2011 +0300 +++ b/Lib/test/test_ssl.py Fri May 06 12:47:14 2011 +0200 @@ -277,6 +277,24 @@ (('organizationName', 'Google Inc'),))} fail(cert, 'mail.google.com') +# No DNS entry in subjectAltName but a commonName +cert = {'notAfter': 'Dec 18 23:59:59 2099 GMT', +'subject': ((('countryName', 'US'),), +(('stateOrProvinceName', 'California'),), +(('localityName', 'Mountain View'),), +(('commonName', 'mail.google.com'),)), +'subjectAltName': (('othername', 'blabla'), )} +ok(cert, 'mail.google.com') + +# No DNS entry subjectAltName and no commonName +cert = {'notAfter': 'Dec 18 23:59:59 2099 GMT', +'subject': ((('countryName', 'US'),), +(('stateOrProvinceName', 'California'),), +(('localityName', 'Mountain View'),), +(('organizationName', 'Google Inc'),)), +'subjectAltName': (('othername', 'blabla'),)} +fail(cert, 'google.com') + # Empty cert / no cert self.assertRaises(ValueError, ssl.match_hostname, None, 'example.com') self.assertRaises(ValueError, ssl.match_hostname, {}, 'example.com') Steffen, I will submit a bug report to Mercurial as soon as this patch is expected to be integrate in py3k. -- versions: +Python 3.4 ___ Python tracker <http://bugs.python.org/issue12000> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12000] SSL certificate verification failed if no dNSName entry in subjectAltName
New submission from Nicolas Bareil : When connecting to a SSL server, the certificate verification failed if it has a subjectAltName extension without any dNSName entry inside: it should fallback to the Common Name. Example: >>> cert = conn.getpeercert() >>> cert {'notAfter': 'May 15 14:31:42 2011 GMT', 'subject': ((('countryName', u'FR'),), (('stateOrProvinceName', u'Ile-de-France'),), (('localityName', u'Paris'),), (('organizationName', 'xxx'),), (('organizationalUnitName', 'xxx'),), (('commonName', 'foobar.corp'),), (('emailAddress', u't...@test.net'),)), 'subjectAltName': (('email', t...@test.net'),)} This certificate is valid according to RFC 2818: If a subjectAltName extension of type dNSName is present, that MUST be used as the identity. Otherwise, the (most specific) Common Name field in the Subject field of the certificate MUST be used. Although the use of the Common Name is existing practice, it is deprecated and Certification Authorities are encouraged to use the dNSName instead. Even if the use of CommonName is deprecated, we should not break existing systems. Current revision of Lib/ssl.py : 108 def match_hostname(cert, hostname): ... 119 san = cert.get('subjectAltName', ()) 120 for key, value in san: 121 if key == 'DNS': 122 if _dnsname_to_pat(value).match(hostname): 123 return 124 dnsnames.append(value) 125 if not san: 126 # The subject is only checked when subjectAltName is empty 127 for sub in cert.get('subject', ()): 128 for key, value in sub: 129 # XXX according to RFC 2818, the most specific Common Name 130 # must be used. 131 if key == 'commonName': 132 if _dnsname_to_pat(value).match(hostname): 133 return 134 dnsnames.append(value) ... Proposed patch is: diff -r 513f6dfd3173 Lib/ssl.py --- a/Lib/ssl.pySun May 01 20:24:59 2011 -0500 +++ b/Lib/ssl.pyMon May 02 11:16:46 2011 +0200 @@ -122,8 +122,9 @@ if _dnsname_to_pat(value).match(hostname): return dnsnames.append(value) - if not san: - # The subject is only checked when subjectAltName is empty + if not san and not dnsnames: + # The subject is only checked when there is no dNSName entry + # in subjectAltName for sub in cert.get('subject', ()): for key, value in sub: # XXX according to RFC 2818, the most specific Common Name -- components: Library (Lib) messages: 135119 nosy: nbareil priority: normal severity: normal status: open title: SSL certificate verification failed if no dNSName entry in subjectAltName type: behavior versions: Python 3.2, Python 3.3, Python 3.4 ___ Python tracker <http://bugs.python.org/issue12000> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11225] getcwd fix for NetBSD to handle ERANGE errno
New submission from Nicolas Joly : NetBSD do require the very same fix from issue 9185, to handle ERANGE errno returned when the size argument is greater than zero but smaller than the length of the pathname plus 1. Without it, the testsuite do indeed loops indefinitely. Thanks. -- components: Interpreter Core files: python-getcwd.diff keywords: patch messages: 128698 nosy: njoly priority: normal severity: normal status: open title: getcwd fix for NetBSD to handle ERANGE errno versions: Python 2.7 Added file: http://bugs.python.org/file20773/python-getcwd.diff ___ Python tracker <http://bugs.python.org/issue11225> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10664] xml.sax.expatreader should support namespace prefixes
Nicolas Delaby added the comment: the PyXML sax parser support this feature. May be it can be backported into stdlib ? -- nosy: +Nicolas.Delaby ___ Python tracker <http://bugs.python.org/issue10664> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10924] Adding salt and Modular Crypt Format to crypt library.
Nicolas Dumazet added the comment: Hello, 1) Can you please avoid putting several statements in the same line? 2) wouldnt it be better to compute only once the contents of methods()? I'm not sure that module-initialization time is okay for CPython, but at the very least you can lazily fill a module-level variable, and return it directly from methods()? 3) what happens when a user uses one of the Crypt methods that are referenced from the Module, if this method is not available? Arguably, if I know what I'm doing, I will call mksalt(METHOD_SHA512) without checking that METHOD_SHA512 was in methods(). That's not very intuitive, and it seems that mksalt could break. 4) saltchars should probably be string.ascii_letters+string.digits instead of the hardcoded value 5) you should mention in the documentation that if not salt parameter is given, a different salt will be used for each crypt() call 6) is _MethodClass an old-style class? 7) it seems that the patch duplicates twice the diff of crypt.py, not sure of what happened there? -- nosy: +nicdumz ___ Python tracker <http://bugs.python.org/issue10924> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10475] hardcoded compilers for LDSHARED/LDCXXSHARED on NetBSD
Nicolas Joly added the comment: I do not tested it extensively, but seems so. nj...@petaure [temp/python27]> ./python Python 2.7.1+ (release27-maint:87432M, Dec 22 2010, 01:10:26) [GCC 4.1.3 20080704 prerelease (NetBSD nb2 20081120)] on netbsd5 Type "help", "copyright", "credits" or "license" for more information. >>> import sys >>> sys.version '2.7.1+ (release27-maint:87432M, Dec 22 2010, 01:10:26) \n[GCC 4.1.3 20080704 prerelease (NetBSD nb2 20081120)]' >>> import os >>> os.uname() ('NetBSD', 'petaure.lan', '5.99.41', 'NetBSD 5.99.41 (PETAURE) #7: Mon Dec 20 23:06:49 CET 2010 nj...@petaure.lan:/local/src/NetBSD/obj.amd64/sys/arch/amd64/compile/PETAURE', 'amd64') -- ___ Python tracker <http://bugs.python.org/issue10475> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10475] hardcoded compilers for LDSHARED/LDCXXSHARED on NetBSD
New submission from Nicolas Joly : The configure script do hardcode compilers for LDSHARED/LDCXXSHARED on NetBSD, which should be avoided. [...] checking for gcc... gcc checking whether gcc accepts -g... yes [...] checking SO... .so checking LDSHARED... cc -shared checking CCSHARED... -fPIC [...] -- components: Build files: python-cc.diff keywords: patch messages: 121817 nosy: njoly priority: normal severity: normal status: open title: hardcoded compilers for LDSHARED/LDCXXSHARED on NetBSD versions: Python 2.7 Added file: http://bugs.python.org/file19719/python-cc.diff ___ Python tracker <http://bugs.python.org/issue10475> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10324] Modules/binascii.c: simplify expressions
Nicolas Kaiser added the comment: Sorry, found it - with patched builds of Python 2.6.5 and 3.1.2: python2.6 test_binascii.py test_base64invalid (__main__.BinASCIITest) ... ok test_base64valid (__main__.BinASCIITest) ... ok test_crc32 (__main__.BinASCIITest) ... ok test_empty_string (__main__.BinASCIITest) ... ok test_exceptions (__main__.BinASCIITest) ... ok test_functions (__main__.BinASCIITest) ... ok test_hex (__main__.BinASCIITest) ... ok test_qp (__main__.BinASCIITest) ... ok test_uu (__main__.BinASCIITest) ... ok -- Ran 9 tests in 0.002s OK python3.1 test_binascii.py test_base64invalid (__main__.BinASCIITest) ... ok test_base64valid (__main__.BinASCIITest) ... ok test_crc32 (__main__.BinASCIITest) ... ok test_empty_string (__main__.BinASCIITest) ... ok test_exceptions (__main__.BinASCIITest) ... ok test_functions (__main__.BinASCIITest) ... ok test_hex (__main__.BinASCIITest) ... ok test_no_binary_strings (__main__.BinASCIITest) ... ok test_qp (__main__.BinASCIITest) ... ok test_uu (__main__.BinASCIITest) ... ok -- Ran 10 tests in 0.006s OK -- ___ Python tracker <http://bugs.python.org/issue10324> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10324] Modules/binascii.c: simplify expressions
Nicolas Kaiser added the comment: That's ./Lib/test/test_unittest.py? With patched builds of Python 2.6.5 and 3.1.2: -- Ran 126 tests in 0.015s OK -- Ran 187 tests in 0.054s OK -- ___ Python tracker <http://bugs.python.org/issue10324> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10324] Modules/binascii.c: simplify expressions
Changes by Nicolas Kaiser : -- keywords: +patch Added file: http://bugs.python.org/file19504/python-binascii.diff ___ Python tracker <http://bugs.python.org/issue10324> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10324] Modules/binascii.c: simplify expressions
New submission from Nicolas Kaiser : Hi there! I noticed two expressions that can be simplified like: (a || (!a && b)) => (a || b) Best regards, Nicolas Kaiser --- --- a/Modules/binascii.c2010-11-05 13:21:22.075303326 +0100 +++ b/Modules/binascii.c2010-11-05 13:24:16.986174756 +0100 @@ -1337,8 +1337,7 @@ binascii_b2a_qp (PyObject *self, PyObjec ((data[in] == '\t' || data[in] == ' ') && (in + 1 == datalen)) || ((data[in] < 33) && (data[in] != '\r') && (data[in] != '\n') && - (quotetabs || -(!quotetabs && ((data[in] != '\t') && (data[in] != ' ')) + (quotetabs || ((data[in] != '\t') && (data[in] != ' ') { if ((linelen + 3) >= MAXLINESIZE) { linelen = 0; @@ -1410,8 +1409,7 @@ binascii_b2a_qp (PyObject *self, PyObjec ((data[in] == '\t' || data[in] == ' ') && (in + 1 == datalen)) || ((data[in] < 33) && (data[in] != '\r') && (data[in] != '\n') && - (quotetabs || -(!quotetabs && ((data[in] != '\t') && (data[in] != ' ')) + (quotetabs || ((data[in] != '\t') && (data[in] != ' ') { if ((linelen + 3 )>= MAXLINESIZE) { odata[out++] = '='; -- components: Extension Modules messages: 120490 nosy: nikai priority: normal severity: normal status: open title: Modules/binascii.c: simplify expressions type: feature request versions: Python 3.3 ___ Python tracker <http://bugs.python.org/issue10324> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6755] Patch: new method get_wch for ncurses bindings: accept wide characters (unicode)
Changes by Nicolas Schodet : -- nosy: +schodet ___ Python tracker <http://bugs.python.org/issue6755> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1974] email.MIMEText.MIMEText.as_string incorrectly folding long subject header
Nicolas Dumazet added the comment: Sure, where was my head. So, a simple patch like this one: _oldheaderinit = email.Header.Header.__init__ def _unifiedheaderinit(self, *args, **kw): # override continuation_ws kw['continuation_ws'] = ' ' _oldheaderinit(self, *args, **kw) email.Header.Header.__dict__['__init__'] = _unifiedheaderinit fixes the issue for us, and might be helpful to others. -- ___ Python tracker <http://bugs.python.org/issue1974> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1974] email.MIMEText.MIMEText.as_string incorrectly folding long subject header
Nicolas Dumazet added the comment: Hello folks. (stumbling on this bug with Python2.7 release, noting that a few Mercurial tests broke with 2.7) I have no problem whatsoever with the fix itself (you know emails better than me), but you broke backwards compatibility for email.generator.Generator here, without propagating the changes to previous versions. 1) It would have been nice to flag this somewhere in the release notes, and/or the documentation for email.generator.Generator. Finding the reason of the Mercurial failures was... a bit trickier than necessary :) 2) What durable solutions can you propose for those of us that have to support several Python versions and share a similar behaviour? In a perfect world, I would simply do this: class CompatibleHeader(email.Header.Header.__class__): """ Python2.7 introduces a backwards incompatible change (Python issue1974, r70772) in email.generaor.Generator code: pre-2.7 code passed "continuation_ws='\t'" to the Header constructor, and 2.7 removed this parameter. Default argument is continuation_ws=' ', which means that the behaviour is different in <2.7 and 2.7 We consider the 2.7 behaviour to be preferable, but need to have an unified behaviour for versions 2.4 to 2.7 """ def __init__(self, **kw): # override continuation_ws kw['continuation_ws'] = ' ' email.Header.Header.__init__(self, **kw) email.Header.Header.__class__ = CompatibleHeader and get over it, but you'll notice that Header is still an old-style class... so that's not possible. Any suggestions? Thanks! -- nosy: +djc, nicdumz ___ Python tracker <http://bugs.python.org/issue1974> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6715] xz compressor support
Changes by Nicolas Dumazet : -- nosy: +nicdumz ___ Python tracker <http://bugs.python.org/issue6715> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5851] Add a stream parameter to gc.set_debug
Nicolas Dumazet added the comment: Sure, I'd be happy to contribute a patch. I uploaded a patch on Rietveld, at http://codereview.appspot.com/110078 Let me know how it looks. -- ___ Python tracker <http://bugs.python.org/issue5851> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6026] test_(zipfile|zipimport|gzip|distutils|sqlite) fail if zlib is not available
Nicolas Dumazet added the comment: Great, I don't know how I missed that bug. It looks really similar to the patch I had written at http://codereview.appspot.com/111041 So your patch looks correct to me, and does solve the issue locally. -- nosy: +nicdumz ___ Python tracker <http://bugs.python.org/issue6026> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6776] A few tests are failing when zlib is not supported
New submission from Nicolas Dumazet : test_distutils, test_zipfile, test_gzip and test_zimport are not completely safe when zlib module is not available. I've uploaded a patch on Rietveld which solves the issue here: http://codereview.appspot.com/111041 Those are my first steps with Rietveld, please let me know if I can improve something :) Thanks, Nicolas. -- components: Tests messages: 91923 nosy: nicdumz severity: normal status: open title: A few tests are failing when zlib is not supported type: behavior ___ Python tracker <http://bugs.python.org/issue6776> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6775] readme: correct python.org/community/lists url
New submission from Nicolas Dumazet : README shows http://www.python.org/community/lists.html as an URL for mailing list details, but it should be http://www.python.org/community/lists/ Attaching a patch. -- assignee: georg.brandl components: Documentation files: readme-url-mls.patch keywords: patch messages: 91913 nosy: georg.brandl, nicdumz severity: normal status: open title: readme: correct python.org/community/lists url Added file: http://bugs.python.org/file14779/readme-url-mls.patch ___ Python tracker <http://bugs.python.org/issue6775> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6774] socket.shudown documentation: on some platforms, closing one half closes the other half
New submission from Nicolas Dumazet : I had a bad time understanding what happens in Mac OS X after a shutdown call: after calling shutdown(SH_WR) on side A, a corresponding shutdown(SH_RD) on side B would raise a socket.error: socket is not connected. It is quite surprising when you are used to sockets in Linux, which expect you to shut one end, and then the other one. It turns out that under Mac OS X, a shutdown call closes the connection on the other half. And the only mention I could find of this behavior was here, r68611 : http://svn.python.org/view/python/trunk/Lib/test/test_socket.py?r1=64125&r2=68611&pathrev=68611 I think that the documentation should specify that (surprising) behavior: I attached a patch explaining that detail. Thanks! -- assignee: georg.brandl components: Documentation files: socketshutdown.patch keywords: patch messages: 91912 nosy: georg.brandl, nicdumz severity: normal status: open title: socket.shudown documentation: on some platforms, closing one half closes the other half type: behavior Added file: http://bugs.python.org/file14778/socketshutdown.patch ___ Python tracker <http://bugs.python.org/issue6774> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6005] Bug in socket example
Nicolas Dumazet added the comment: I'm including a patch which replaces send by sendall in the examples in both socket and socketserver. -- keywords: +patch nosy: +nicdumz Added file: http://bugs.python.org/file14776/socket.patch ___ Python tracker <http://bugs.python.org/issue6005> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6723] csv.writer: example does not work
New submission from Nicolas Goutte : In the documentation for csv.writer, the example spamWriter = csv.writer(open('eggs.csv', 'w'), delimiter=' ', quotechar='|', quoting=QUOTE_MINIMAL) does not work, as Python complains about "SyntaxError: invalid syntax", as QUOTE_MINIMAL is not a global identifier. By replacing QUOTE_MINIMAL by csv.QUOTE_MINIMAL there is no syntax error anymore. I have discovered the issue with python 2.6.2. All online documentation version (2.6, 2.7, 3.1, 3.2) seem to have the same documentation (e.g. http://docs.python.org/library/csv.html ) -- assignee: georg.brandl components: Documentation messages: 91682 nosy: georg.brandl, nicolasg severity: normal status: open title: csv.writer: example does not work versions: Python 2.6 ___ Python tracker <http://bugs.python.org/issue6723> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6377] distutils compiler switch ignored
Nicolas Dumazet added the comment: It seems that the fix is still not perfect. At the moment ( r73906 ), if you try to build trunk using Python 2.6, you get: > python setup.py build running build running build_ext Traceback (most recent call last): File "setup.py", line 1901, in main() File "setup.py", line 1896, in main 'Lib/smtpd.py'] File "/usr/lib/python2.6/distutils/core.py", line 152, in setup dist.run_commands() File "/usr/lib/python2.6/distutils/dist.py", line 975, in run_commands self.run_command(cmd) File "/usr/lib/python2.6/distutils/dist.py", line 995, in run_command cmd_obj.run() File "/usr/lib/python2.6/distutils/command/build.py", line 135, in run self.run_command(cmd_name) File "/usr/lib/python2.6/distutils/cmd.py", line 333, in run_command self.distribution.run_command(command) File "/usr/lib/python2.6/distutils/dist.py", line 995, in run_command cmd_obj.run() File "/usr/lib/python2.6/distutils/command/build_ext.py", line 345, in run self.build_extensions() File "setup.py", line 103, in build_extensions missing = self.detect_modules() File "setup.py", line 302, in detect_modules add_dir_to_list(self.compiler_obj.library_dirs, '/usr/local/lib') File "/usr/lib/python2.6/distutils/cmd.py", line 112, in __getattr__ raise AttributeError, attr AttributeError: compiler_obj -- nosy: +nicdumz ___ Python tracker <http://bugs.python.org/issue6377> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5873] Minidom: parsestring() error
New submission from Nicolas Frantzen : Hi, I'm pretty new to the community but I get an error using the minidom parseString() method. Here is my code (ulta simple!): import xml.dom.minidom xml = "hello" doc = xml.dom.minidom.parsString(xml) And here is my error trace: Traceback (most recent call last): File "C:\test.py", line 6, in doc = xml.dom.minidom.parsString(xml) AttributeError: 'str' object has no attribute 'dom' I get this error no what string I gave it. I use python 2.6 (latest stable release). Can someone point in the right direction...google has not been very helpful. Thanks! Nico -- components: XML messages: 86776 nosy: naf305 severity: normal status: open title: Minidom: parsestring() error type: crash versions: Python 2.6 ___ Python tracker <http://bugs.python.org/issue5873> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5851] Add a stream parameter to gc.set_debug
New submission from Nicolas Dumazet : Hello! gc.set_debug is provided to help debugging a leaking program. That tool can be very useful indeed. Debugging information, however, is written to sys.stderr, and there are cases where this behavior can be a problem: chances are that stderr can be already used to output other information. Currently, to debug a verbose program writing to stderr, one has to either first reduce/suppress the stderr output noise from its program before activating set_debug, OR has to redirect the whole mixed stderr output, and filter it afterwards. I'd like very much the possibility to configure myself where the gc debugger will write its output. My suggestion would be to have set_debug converted from set_debug(flags) to set_debug(flags, stream=sys.stderr), stream being any valid file object, but any solution allowing me to customize the output target of the gc debugger would be welcome. Thanks! -- components: Extension Modules messages: 86647 nosy: nicdumz severity: normal status: open title: Add a stream parameter to gc.set_debug type: feature request versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue5851> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5154] OSX broken poll testing doesn't work
Changes by Nicolas Dumazet : -- nosy: +nicdumz ___ Python tracker <http://bugs.python.org/issue5154> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5751] Typo in documentation of print function parameters
New submission from Nicolas Goutte : In http://docs.python.org/library/functions.html#print the print function is documented to have a parameter named end with a default 'n'. However the default should be '\n' as documented in Python 3 ( http://docs.python.org/3.0/library/functions.html#print ) -- assignee: georg.brandl components: Documentation messages: 85962 nosy: georg.brandl, nicolasg severity: normal status: open title: Typo in documentation of print function parameters versions: Python 2.6 ___ Python tracker <http://bugs.python.org/issue5751> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3006] subprocess.Popen causes socket to remain open after close
Changes by Nicolas Grilly <[EMAIL PROTECTED]>: -- nosy: +ngrilly ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3006> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1398] Can't pickle partial functions
Nicolas Grilly <[EMAIL PROTECTED]> added the comment: It seems using protocol version 2 is not enough: >>> s = pickle.dumps(partial_f, 2) >>> f = pickle.loads(s) Traceback (most recent call last): ... TypeError: type 'partial' takes at least one argument Am I missing something? -- nosy: +ngrilly ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1398> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2255] Change Mandrake by Mandriva for platform.dist()
Nicolas Lécureuil added the comment: is there a fix applied on mandriva python : --- (empty file) +++ cooker/python/current/SOURCES/python-2.5.1-detect-mandriva.patch Sat Mar 8 03:22:50 2008 @@ -0,0 +1,10 @@ +--- Lib/platform.py.old2007-10-05 20:17:15.0 +0800 Lib/platform.py2007-10-05 20:18:00.0 +0800 +@@ -225,7 +225,7 @@ + + def dist(distname='',version='',id='', + +- supported_dists=('SuSE', 'debian', 'fedora', 'redhat', 'mandrake')): ++ supported_dists=('SuSE', 'debian', 'fedora', 'mandriva', 'redhat', 'mandrake')): + + """ Tries to determine the name of the Linux OS distribution name. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2255> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2255] Change Mandrake by Mandriva for platform.dist()
New submission from Nicolas Lécureuil: here is a patch fixing the issue by changing mandrake to mandriva -- components: Library (Lib) files: python-2.5-change-mandrake.patch keywords: patch messages: 63370 nosy: neoclust severity: normal status: open title: Change Mandrake by Mandriva for platform.dist() type: behavior versions: Python 2.5 Added file: http://bugs.python.org/file9633/python-2.5-change-mandrake.patch __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2255> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
I founded a bug.
script: (to extend c++ in python) filename: stpwsusr.py CANT BE "wsusr.py"!!! its bad,because everybody usally name the files like the program/module. source: /*/ from distutils.core import setup, Extension mylib_dirs=['/home/dev/WireLessStudio/wsusrlib/debug/src'] libs_trace=['wsusr'] <- My module 's name. module3 = Extension('wsl', sources = ['srcwsl.cpp'], library_dirs=mylib_dirs, libraries = libs_trace) setup (name = 'PackageName', version = '1.0', description = 'probando claes en piton, gross', ext_modules = [module3]) /**/ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com