[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 <rep...@bugs.python.org>
<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 <rep...@bugs.python.org> <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 <rep...@bugs.python.org> <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 <m...@gilgamezh.me>: -- nosy: +gilgamezh ___ Python tracker <rep...@bugs.python.org> <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 <rep...@bugs.python.org> <http://bugs.python.org/issue25358> ___ ___ 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 n...@beerfactory.org: -- nosy: +njouanin ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19084 ___ ___ 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 n...@beerfactory.org: -- nosy: +njouanin ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11943 ___ ___ 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 rep...@bugs.python.org 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
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 rep...@bugs.python.org 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
Changes by Nicolas Limage nicolas.lim...@gmail.com: -- nosy: -Nicolas.Limage resolution: - duplicate status: open - closed ___ Python tracker rep...@bugs.python.org 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 rep...@bugs.python.org http://bugs.python.org/issue16472 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14223] curses addch broken on Python3.3a1
Changes by Nicolas Schodet nico-pyt...@ni.fr.eu.org: -- nosy: -schodet ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14223 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15785] curses.get_wch() returns keypad codes incorrectly
Changes by Nicolas Schodet nico-pyt...@ni.fr.eu.org: -- nosy: -schodet ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15785 ___ ___ 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 nicolas-gau...@laposte.net: 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 rep...@bugs.python.org 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 nicd...@gmail.com 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=64125r2=68611pathrev=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 rep...@bugs.python.org 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
New submission from Nicolas Goutte nicolas.gou...@extragroup.de: 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 rep...@bugs.python.org 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
Changes by Nicolas Goutte nicolas.gou...@extragroup.de: Added file: http://bugs.python.org/file23841/windows_1252ok.py ___ Python tracker rep...@bugs.python.org 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 n...@chdir.org 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 rep...@bugs.python.org 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 n...@chdir.org added the comment: Martin v. Löwis rep...@bugs.python.org 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 rep...@bugs.python.org 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 ni...@no-log.org: 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 rep...@bugs.python.org 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 nicolas.estib...@gmail.com added the comment: Thanks for your help and the interesting discussion with this issue. -- ___ Python tracker rep...@bugs.python.org 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 nicolas.estib...@gmail.com 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 rep...@bugs.python.org 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 nicolas.estib...@gmail.com 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 rep...@bugs.python.org 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 nicolas.estib...@gmail.com 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 rep...@bugs.python.org 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 nicolas.estib...@gmail.com: 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 rep...@bugs.python.org 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 n...@chdir.org 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 rep...@bugs.python.org
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 n...@chdir.org 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 rep...@bugs.python.org
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 n...@chdir.org:
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 rep...@bugs.python.org
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 nj...@pasteur.fr: 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 rep...@bugs.python.org 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 delaby.nico...@gmail.com added the comment: the PyXML sax parser support this feature. May be it can be backported into stdlib ? -- nosy: +Nicolas.Delaby ___ Python tracker rep...@bugs.python.org 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 nicd...@gmail.com 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 rep...@bugs.python.org 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 nj...@pasteur.fr 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 rep...@bugs.python.org
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 nj...@pasteur.fr: 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 rep...@bugs.python.org 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 ni...@nikai.net 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 rep...@bugs.python.org 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 ni...@nikai.net:
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 rep...@bugs.python.org
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 ni...@nikai.net: -- keywords: +patch Added file: http://bugs.python.org/file19504/python-binascii.diff ___ Python tracker rep...@bugs.python.org 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 ni...@nikai.net 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 rep...@bugs.python.org 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 nico-pyt...@ni.fr.eu.org: -- nosy: +schodet ___ Python tracker rep...@bugs.python.org 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 nicd...@gmail.com 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 rep...@bugs.python.org 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 nicd...@gmail.com 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 rep...@bugs.python.org 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 nicd...@gmail.com: -- nosy: +nicdumz ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6715 ___ ___ 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 nicd...@gmail.com 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 rep...@bugs.python.org http://bugs.python.org/issue6005 ___ ___ 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 nicd...@gmail.com: 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=64125r2=68611pathrev=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 rep...@bugs.python.org http://bugs.python.org/issue6774 ___ ___ 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 nicd...@gmail.com: 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 rep...@bugs.python.org http://bugs.python.org/issue6775 ___ ___ 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 nicd...@gmail.com: 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 rep...@bugs.python.org http://bugs.python.org/issue6776 ___ ___ 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 nicd...@gmail.com 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 rep...@bugs.python.org http://bugs.python.org/issue6026 ___ ___ 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 nicd...@gmail.com 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 rep...@bugs.python.org http://bugs.python.org/issue5851 ___ ___ 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 nicolas.gou...@extragroup.de:
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 rep...@bugs.python.org
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 nicd...@gmail.com 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 module 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 rep...@bugs.python.org 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 n.frant...@gmail.com: 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 = taghello/tag doc = xml.dom.minidom.parsString(xml) And here is my error trace: Traceback (most recent call last): File C:\test.py, line 6, in module 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 rep...@bugs.python.org 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 nicd...@gmail.com: 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 rep...@bugs.python.org http://bugs.python.org/issue5851 ___ ___ 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 nicolas.gou...@extragroup.de: 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 rep...@bugs.python.org http://bugs.python.org/issue5751 ___ ___ 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 nicd...@gmail.com: -- nosy: +nicdumz ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5154 ___ ___ 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
