[issue11874] argparse assertion failure with brackets in metavars
Changes by Tshepang Lekhonkhobe tshep...@gmail.com: -- nosy: -tshepang ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11874 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22762] PyObject_Call called with an exception set while displaying a traceback
Roundup Robot added the comment: New changeset 9dddc95ef31e by Victor Stinner in branch '3.4': Issue #22762: Fix _Py_DisplaySourceLine(), clear the exception if https://hg.python.org/cpython/rev/9dddc95ef31e New changeset f4f5b942e5e0 by Victor Stinner in branch 'default': (Merge 3.4) Issue #22762: Fix _Py_DisplaySourceLine(), clear the exception if https://hg.python.org/cpython/rev/f4f5b942e5e0 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22762 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22762] PyObject_Call called with an exception set while displaying a traceback
STINNER Victor added the comment: Thanks for the report and the patch. It was not easy to reproduce the issue, but I reproduced the assertion error. I'm not sure that it's useful to add an unit test. -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22762 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18235] _sysconfigdata.py wrong on AIX installations
Phil Elson added the comment: FWIW - this doesn't appear to have been backported to v2.7.x. As a result, the ./Modules/ld_so_aix reference still exists in _sysconfigdata.py in v2.7.8 (and therefore I was unable to build numpy). The workaround is easy enough, it is just something that is worth noting. -- nosy: +pelson ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18235 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22764] object lifetime fragility in unittest tests
New submission from Robert Collins: test_assertRaises_frames_survival (unittest2.test.test_assertions.Test_Assertions Depends on refcount behaviour to pass - adding a gc.collect() before the weakref checks is sufficient to fix things on pypy. test_no_exception_leak (unittest2.test.test_case.Test_TestCase similarly here adding a juidicious gc.collect solves the issue. -- messages: 230258 nosy: rbcollins priority: normal severity: normal status: open title: object lifetime fragility in unittest tests versions: Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22764 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22764] object lifetime fragility in unittest tests
Robert Collins added the comment: Herewith a patch. Applied to unittest2 for backport to unbreak its tests on pypy. -- keywords: +patch Added file: http://bugs.python.org/file37072/issue22764.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22764 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22764] object lifetime fragility in unittest tests
Changes by Robert Collins robe...@robertcollins.net: -- type: - behavior ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22764 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20440] Use Py_REPLACE/Py_XREPLACE macros
Changes by Eldar Abusalimov eldar.abusali...@gmail.com: -- nosy: +abusalimov ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20440 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22764] object lifetime fragility in unittest tests
Antoine Pitrou added the comment: I think the change in test_assertions is wrong: it doesn't test what the change was meant to fix in the first place. -- nosy: +pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22764 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22764] object lifetime fragility in unittest tests
Antoine Pitrou added the comment: You could instead mark the test as cpython-specific. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22764 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22764] object lifetime fragility in unittest tests
Antoine Pitrou added the comment: Le 30/10/2014 12:00, Robert Collins a écrit : Ah, perhaps the test was flawed to start with, since no effort is made in it to capture the error and then process it. If we pass a result in, the traceback will have a ref and gc.collect() can't possibly be discarding the entire structure. Yes, that would be another way to fix it, probably. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22764 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22764] object lifetime fragility in unittest tests
Robert Collins added the comment: Hmm? I must have misunderstood the test. Here's my understanding: the test is testing that a an object ref only held in the traceback object of the exception is cleaned up such that it can be collected. In a refcount system that collection is immediate, in a gc world its after the next gc run. Ah, perhaps the test was flawed to start with, since no effort is made in it to capture the error and then process it. If we pass a result in, the traceback will have a ref and gc.collect() can't possibly be discarding the entire structure. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22764 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22764] object lifetime fragility in unittest tests
Antoine Pitrou added the comment: Here's my understanding: the test is testing that a an object ref only held in the traceback object of the exception is cleaned up such that it can be collected The best way to check would be to revert the case.py changes in 6ab3193e890e. My intuition is that the test would then fail, but succeed with your changes. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22764 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22765] Fixes for test_gdb (first frame address, entry values)
New submission from Bohuslav Slavek Kabrda: The attached patch fixes two test_gdb problems that can occur under some circumstances: - With new GDB (I think version = 7.4.0, but I'm not sure about the precise version), GDB sometimes prints entry-values for variables, which can lead to failures like: AssertionError: 'v@entry=()' != '()'. The cure for that is using set print entry-values no in GDB. I think this is also the root cause of issue 17126. - While building on ppc64 little endian for Fedora, we experienced GDB printing program counter for the first frame, which breaks regular expressions matching in tests, e.g. instead of #0 in PyObject_Print the lines can look like #0 0x3fffb7dd1798 in PyObject_Print I've talked to Fedora's GDB maintainer and I've been told that this can happen and it's not a GDB bug - GDB does not guarantee this. Therefore the second part of the attached patch turns printing program counters for *all* frames using set print address off to achieve same GDB output everywhere. -- components: Tests files: test_gdb-ppc64le-and-entry-values-fix.patch keywords: patch messages: 230265 nosy: bkabrda priority: normal severity: normal status: open title: Fixes for test_gdb (first frame address, entry values) versions: Python 2.7, Python 3.5 Added file: http://bugs.python.org/file37073/test_gdb-ppc64le-and-entry-values-fix.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22765 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22682] Add support of KZ1048 (RK1048) encoding
Amaury Forgeot d'Arc added the comment: Looks good to me. I checked that there are only 16 differences between cp1251 and kz1048, and that the two standards define the same mapping. -- nosy: +amaury.forgeotdarc ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22682 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22141] rlcompleter.Completer matches too much
Claudiu Popa added the comment: Looks good to me. You might want to sign the contributor agreement: https://www.python.org/psf/contrib/contrib-form/. This is required for non-trivial contributions. You'll get a * next to your name after signing it. -- stage: patch review - commit review ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22141 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22763] load_tests chaining into discover from non-discover entry point gets top_level_dir wrong
R. David Murray added the comment: +1 on the refactoring. I think it makes more conceptual sense. -- nosy: +r.david.murray ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22763 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22143] rlcompleter.Completer has duplicate matches
Claudiu Popa added the comment:
I don't know why there's no review link for your patch. Anyway..
+self.assertTrue(c.complete(A.foo, 0) in ['A.foo(', 'A.foobar('])
+self.assertTrue(c.complete(A.foo, 1) in ['A.foo(', 'A.foobar('])
You can use self.assertIn for these.
+self.assertEqual(c.complete(b.foo, 1), None)
self.assertIsNone.
Otherwise, the patch looks good to me.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22143
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22143] rlcompleter.Completer has duplicate matches
Lorenz Quack added the comment: Thanks for reviewing! test now use assertIn and assertIsNone as suggested PS: My Contributors Agreement is in progress. Just emailed the PSF with some question (but I intend to sign it) -- Added file: http://bugs.python.org/file37074/rlcompleter_22143.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22143 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22766] collections.Counter's in-place operators should return NotImplemented for unsupported types
New submission from Joshua Chin: Currently, in-place operations on 'collections.Counter' with unsupported types raises an 'AttributeError'. Example: import collections counter = collections.Counter() counter += 1 Traceback (most recent call last): File stdin, line 1, in module File /usr/local/Cellar/python3/3.4.2_1/Frameworks/Python.framework/Versions/3.4/lib/python3.4/collections/__init__.py, line 709, in __iadd__ for elem, count in other.items(): AttributeError: 'int' object has no attribute 'items' Instead, it should return 'NotImplemented' if 'other' is not a 'collections.Counter' -- components: Library (Lib) files: counter.patch keywords: patch messages: 230271 nosy: Joshua.Chin priority: normal severity: normal status: open title: collections.Counter's in-place operators should return NotImplemented for unsupported types type: behavior versions: Python 3.4 Added file: http://bugs.python.org/file37075/counter.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22766 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22766] collections.Counter's in-place operators should return NotImplemented for unsupported types
Changes by Ethan Furman et...@stoneleaf.us: -- assignee: - rhettinger nosy: +ethan.furman, rhettinger ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22766 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22766] collections.Counter's in-place operators should return NotImplemented for unsupported types
Changes by Ethan Furman et...@stoneleaf.us: -- versions: +Python 2.7, Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22766 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22766] collections.Counter's in-place operators should return NotImplemented for unsupported types
R. David Murray added the comment: That would prevent it from working with work alike (duck type) classes, though. -- nosy: +r.david.murray ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22766 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22766] collections.Counter's in-place operators should return NotImplemented for unsupported types
Ethan Furman added the comment: As I noted in my review, the docstring specifically says other Counter. If we want to relax that we could check for an 'items' attribute and 'return NotImplemented' if it isn't there, but one or the other should definitely happen. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22766 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22767] `separators` argument to json.dumps() behaves unexpectedly across 2.x vs 3.x
New submission from Tom Christie:
This is one of those behavioural issues that is a borderline bug.
The seperators argument to `json.dumps()` behaves differently across python 2
and 3.
* In python 2 it should be provided as a bytestring, and can cause a
UnicodeDecodeError otherwise.
* In python 3 it should be provided as unicode,and can cause a TypeError
otherwise.
Examples:
Python 2.7.2
print json.dumps({'snowman': '☃'}, separators=(':', ','),
ensure_ascii=False)
{snowman,☃}
print json.dumps({'snowman': '☃'}, separators=(u':', u','),
ensure_ascii=False)
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position 1:
ordinal not in range(128)
And:
Python 3.4.0
print(json.dumps({'snowman': '☃'}, separators=(':', ','),
ensure_ascii=False))
{snowman,☃}
print(json.dumps({'snowman': '☃'}, separators=(b':', b','),
ensure_ascii=False))
...
TypeError: sequence item 2: expected str instance, bytes found
Technically this isn't out of line with the documentation - in both cases it
uses `separators=(':', ',')` which is indeed the correct type in both v2 and
v3. However it's unexpected behaviour that it changes types between versions,
without being called out.
Working on a codebase with `from __future__ import unicode_literals` this is
particularly unexpected because we get a `UnicodeDecodeError` when running code
that otherwise looks correct.
It's also slightly awkward to fix because it's a bit of a weird branch
condition.
The fix would probably be to forcibly coerce it to the correct type regardless
of if it is supplied as unicode or a bytestring, or at least to do so for
python 2.7.
Possibly related to http://bugs.python.org/issue22701 but wasn't able to
understand if that ticket was in fact a different user error.
--
messages: 230274
nosy: Tom.Christie
priority: normal
severity: normal
status: open
title: `separators` argument to json.dumps() behaves unexpectedly across 2.x vs
3.x
type: behavior
versions: Python 2.7, Python 3.4
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22767
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22767] `separators` argument to json.dumps() behaves unexpectedly across 2.x vs 3.x
Georg Brandl added the comment: IMO the snowman should be a Unicode string in the second example for Python 2.7. -- nosy: +georg.brandl ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22767 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22767] `separators` argument to json.dumps() behaves unexpectedly across 2.x vs 3.x
Georg Brandl added the comment: in the second example or even, in both examples. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22767 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22766] collections.Counter's in-place operators should return NotImplemented for unsupported types
R. David Murray added the comment: 'counter' in the docstrings is in lower case, so that says nothing dispositive. However, __add__ does an ininstance check, so it is hard to see why __iadd__ does not. Personally I'd drop the isinstance checks and let the errors bubble up as they may. Why should subtract explicitly support other data types, but not __sub__/__isub__? But Raymond's opinion should hold the most weight here. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22766 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22766] collections.Counter's in-place operators should return NotImplemented for unsupported types
Ethan Furman added the comment:
Indeed -- we mostly discuss with each other to try and sway his opinion. :)
stdlib types should not let every error bubble up. Consider a dict:
-- d = {}
-- d += 2
Traceback (most recent call last):
File stdin, line 1, in module
TypeError: unsupported operand type(s) for +=: 'dict' and 'int'
now look at Counter
-- from collections import Counter
-- c = Counter()
-- c += 2
Traceback (most recent call last):
File stdin, line 1, in module
File /home/ethan/source/python/cpython/Lib/collections/__init__.py, line
709, in __iadd__
for elem, count in other.items():
AttributeError: 'int' object has no attribute 'items'
Counter is not user-friendly in this case.
There are other areas of Counter that accept arbitrary mappings, so I would be
fine the __ixxx__ methods also accepting arbitrary mappings, but if the thing
passed in *will not* work with Counter, then returning NotImplemented is the
appropriate course of action.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22766
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22767] `separators` argument to json.dumps() behaves unexpectedly across 2.x vs 3.x
R. David Murray added the comment: And that works, including with the future import. I don't remember if this is a bug we've fixed since 2.7.2, but I don't think so. In Python3, json explicitly does not support bytes. -- nosy: +r.david.murray resolution: - not a bug stage: - resolved status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22767 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22766] collections.Counter's in-place operators should return NotImplemented for unsupported types
Antoine Pitrou added the comment: I also think returning NotImplemented would be the right thing here. -- nosy: +pitrou type: behavior - enhancement versions: -Python 2.7, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22766 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22768] Add a way to get the peer certificate of a SSL Transport
New submission from Mathieu Pasquet: Currently, the only workaround is to use transport._sock.getpeercert(True) on the Transport returned by loop.create_connection(), which is not something to be encouraged. It is useful to get such information, for example to perform a manual certificate check against a previously recorded certificate or hash. I attached a trivial patch adding an extra 'peercert_bin' info, but I do not know if this is the right approach, as other issues of feature disparity might arise when more people try to switch to asyncio. Exposing a proxy SSLSocket object for read-only functions might be more beneficial. -- components: asyncio files: peercert_bin.patch keywords: patch messages: 230281 nosy: gvanrossum, haypo, mathieui, yselivanov priority: normal severity: normal status: open title: Add a way to get the peer certificate of a SSL Transport type: enhancement versions: Python 3.4 Added file: http://bugs.python.org/file37076/peercert_bin.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22768 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22768] Add a way to get the peer certificate of a SSL Transport
Antoine Pitrou added the comment: Thanks for the patch! other issues of feature disparity might arise when more people try to switch to asyncio. Exposing a proxy SSLSocket object for read-only functions might be more beneficial. I'm not sure that would make a difference. We still have to implement the proxy SSLSocket, which is no easier than adding the extra info by hand. Or did I misunderstand you? -- nosy: +pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22768 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8876] distutils should not assume that hardlinks will work
Roundup Robot added the comment: New changeset d94d8789e924 by Antoine Pitrou in branch '3.4': Issue #8876: distutils now falls back to copying files when hard linking doesn't work. https://hg.python.org/cpython/rev/d94d8789e924 New changeset ce484e0840e3 by Antoine Pitrou in branch 'default': Issue #8876: distutils now falls back to copying files when hard linking doesn't work. https://hg.python.org/cpython/rev/ce484e0840e3 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8876 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22768] Add a way to get the peer certificate of a SSL Transport
Mathieu Pasquet added the comment: I'm not sure that would make a difference. We still have to implement the proxy SSLSocket, which is no easier than adding the extra info by hand. Or did I misunderstand you? The difference would be that exposing methods can be more future-proof, as some methods take parameters (like the offender getpeercert(bool), or get_channel_binding() that takes an element of ssl.CHANNEL_BINDING_TYPES, list that may grow in the future) that need to be covered in the properties. But the API of SSLSocket is stable and small so I don't think it really matters. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22768 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8876] distutils should not assume that hardlinks will work
Roundup Robot added the comment: New changeset 263395345aa7 by Antoine Pitrou in branch '2.7': Issue #8876: distutils now falls back to copying files when hard linking doesn't work. https://hg.python.org/cpython/rev/263395345aa7 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8876 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8876] distutils should not assume that hardlinks will work
Antoine Pitrou added the comment: This should now be fixed. Thanks for your patience :) -- resolution: - fixed stage: patch review - resolved status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8876 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22768] Add a way to get the peer certificate of a SSL Transport
Antoine Pitrou added the comment: some methods take parameters (like the offender getpeercert(bool), or get_channel_binding() that takes an element of ssl.CHANNEL_BINDING_TYPES, list that may grow in the future) that need to be covered in the properties That's a good point. I don't have any strong feelings either way. Perhaps other people want to chime in? As for the patch, it will need to add a unit test as well. -- stage: - patch review versions: +Python 3.5 -Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22768 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22765] Fixes for test_gdb (first frame address, entry values)
Changes by Antoine Pitrou pit...@free.fr: -- nosy: +dmalcolm ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22765 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22417] PEP 476: verify HTTPS certificates by default
Alex Gaynor added the comment: Patch now makes more precise assertions about the type of error that's occurring. -- Added file: http://bugs.python.org/file37077/issue22417.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22417 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22767] `separators` argument to json.dumps() behaves unexpectedly across 2.x vs 3.x
Tom Christie added the comment: Not too fussed if this is addressed or not, but I think this is closed a little prematurely. I don't think there's a problem under Python 3, that's entirely reasonable. However under Python 2, `json.dumps()` will normally handle *either* bytes or unicode transparently for you (just altering the return type accordingly). If you happen to be using unicode separators, then the normally lax behaviour of either unicode or bytes that stops being the case. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22767 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8876] distutils should not assume that hardlinks will work
Éric Araujo added the comment: Thanks for the patches folks! -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8876 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22767] `separators` argument to json.dumps() behaves unexpectedly across 2.x vs 3.x
R. David Murray added the comment: But only if you use non-ascii in the binary input, in which case you get an encoding error, which is a correct error. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22767 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22759] pathlib: Path.exists broken
Antoine Pitrou added the comment: ENAMETOOLONG: that doesn't mean the file doesn't exist. For example, it could be accessed by changing the current directory and shortening the residual path name. ELOOP: unfortunately it doesn't guarantee that there is a real symlink loop, just that the OS decided to bail out after a certain number of indirections. So in both cases I think we should let the errors bubble up. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22759 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22759] pathlib: Path.exists broken
Antoine Pitrou added the comment: Here is a patch with tests. -- stage: test needed - patch review Added file: http://bugs.python.org/file37078/path_exists_enotdir.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22759 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22759] pathlib: Path.exists broken
Hristo Venev added the comment: Should I file bugs for is_dir, is_file, is_symlink, is_socket, is_fifo, is_block_device and is_char_device? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22759 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22759] pathlib: Path.exists broken
Antoine Pitrou added the comment: Le 30/10/2014 20:36, Hristo Venev a écrit : Hristo Venev added the comment: Should I file bugs for is_dir, is_file, is_symlink, is_socket, is_fifo, is_block_device and is_char_device? Hmm... good catch. No, this issue will do. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22759 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22759] pathlib: Path.exists broken
Antoine Pitrou added the comment: Updated patch for other querying function. -- Added file: http://bugs.python.org/file37079/path_exists_enotdir2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22759 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22767] `separators` argument to json.dumps() behaves unexpectedly across 2.x vs 3.x
R. David Murray added the comment: No, it is introducing the unicode that is the problem. Your first example is entirely binary. It is only when you *mix* binary and unicode that you have encoding problems (because python doesn't know the encoding of the binary data...well, more precisely it doesn't have one). This confusion is a large part of why python3 exists :) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22767 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22767] `separators` argument to json.dumps() behaves unexpectedly across 2.x vs 3.x
R. David Murray added the comment: Or, to put it another way, we agree with you that both cases should behave the same: using binary data in a json dumps call should raise an error. And in python3 they do. But in python2 there is a confusion as to what is text and what is binary, and so sometimes things work that shouldn't. In python2 a binary string with non-ascii characters is accepted by the dumps call...it shouldn't be since json is defined as a text protocol. But it is baked into the python2 string model that it such binary does work, because in python2 it was assumed that the programmer was responsible for making sure that the encoding of all their binary strings was consistent. But to mix unicode and binary, you *must* make the encoding of the binary strings explicit, otherwise there's no way to correctly compose the binary data with the text data. So, as soon as (but only as soon as) you mix unicode with your non-ascii data, your program blows up. Thus python3. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22767 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22767] `separators` argument to json.dumps() behaves unexpectedly across 2.x vs 3.x
Tom Christie added the comment:
But only if you use non-ascii in the binary input, in which case you get an
encoding error, which is a correct error.
Kind of, except that this (python 2.7) works just fine:
data = {'snowman': '☃'}
json.dumps(data, ensure_ascii=False)
'{snowman: \xe2\x98\x83}'
Whereas this raises an exception:
json.dumps(data, separators=(u':', u','), ensure_ascii=False)
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position 1:
ordinal not in range(128)
If it was the same in both cases then I wouldn't consider it a problem.
As it is, introducing the `seperators` parameter changes the behaviour.
Anyways, I'll get off my high horse now. :)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22767
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16561] bdist_wininst installers don't use UAC, then crash
Changes by Antoine Pitrou pit...@free.fr: -- assignee: eric.araujo - ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16561 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13719] bdist_msi upload fails
Changes by Antoine Pitrou pit...@free.fr: -- assignee: eric.araujo - ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13719 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2943] Distutils should generate a better error message when the SDK is not installed
Changes by Antoine Pitrou pit...@free.fr: -- assignee: tarek - ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2943 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22767] `separators` argument to json.dumps() behaves unexpectedly across 2.x vs 3.x
Tom Christie added the comment: So, as soon as (but only as soon as) you mix unicode with your non-ascii data, your program blows up. Indeed. For context tho my example of running into this the unicode literals used as seperators weren't even in the same package as the non-ASCII binary strings. (JSONRenderer in Django REST framework, being excersized by some third party test code. End result non-obvious exception. Anyways, okay with this resolution, although I am now using a compat branch to ensure that we use binary seperators in py2 to continue to get the more lax rendering style. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22767 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22767] `separators` argument to json.dumps() behaves unexpectedly across 2.x vs 3.x
R. David Murray added the comment: Yes, that third party problem is a prime example of exactly why this needed to be fixed, but it required python3 to fix it. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22767 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22410] Locale dependent regexps on different locales
Antoine Pitrou added the comment: Patch looks good to me. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22410 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22759] pathlib: Path.exists broken
Roundup Robot added the comment: New changeset 40497cc445f4 by Antoine Pitrou in branch '3.4': Issue #22759: Query methods on pathlib.Path() (exists(), is_dir(), etc.) now return False when the underlying stat call raises NotADirectoryError. https://hg.python.org/cpython/rev/40497cc445f4 New changeset ff5f5fd230d3 by Antoine Pitrou in branch 'default': Issue #22759: Query methods on pathlib.Path() (exists(), is_dir(), etc.) now return False when the underlying stat call raises NotADirectoryError. https://hg.python.org/cpython/rev/ff5f5fd230d3 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22759 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22759] pathlib: Path.exists broken
Antoine Pitrou added the comment: This is now fixed. Thanks for the report! -- resolution: - fixed stage: patch review - resolved status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22759 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22769] Tttk tag_has() throws TypeError when called without item
New submission from David Durrett:
Have only tried this on Python 2.7
To reproduce:
~
from Tkinter import *
import ttk
root = Tk()
tree = ttk.Treeview(root)
id = tree.insert('' , 'end', text='foo', tag='bar')
print tree.tag_has('bar', item=id)
# ^ this works..
print tree.tag_has('baz', item=id)
# ^ .. and this..
print tree.tag_has('bar')
# ^ .. this doesn't.
~
...
self.tk.call(self._w, tag, has, tagname, item))
TypeError: must be string, not tuple
Possibly introduced by Issue20072.
Removing the self.tk.getboolean() wrapper in tag_has() appears to fix things.
--
components: Tkinter
messages: 230305
nosy: ddurrett, gpolo, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Tttk tag_has() throws TypeError when called without item
type: behavior
versions: Python 2.7
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22769
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22410] Locale dependent regexps on different locales
Roundup Robot added the comment: New changeset 6d2788f9b20a by Serhiy Storchaka in branch '2.7': Issue #22410: Module level functions in the re module now cache compiled https://hg.python.org/cpython/rev/6d2788f9b20a New changeset cbdc658b7797 by Serhiy Storchaka in branch '3.4': Issue #22410: Module level functions in the re module now cache compiled https://hg.python.org/cpython/rev/cbdc658b7797 New changeset df9c1caf3654 by Serhiy Storchaka in branch 'default': Issue #22410: Module level functions in the re module now cache compiled https://hg.python.org/cpython/rev/df9c1caf3654 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22410 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22770] test_ttk_guionly and test_tk can cause Tk segfaults on OS X when run with regrtest -j option
New submission from Ned Deily: The changes to tkinter tests introduced by the changes for Issue22236 (2.7 32fdaf401e50, 3.4 dd1dffe6f0d2, and default/3.5 014060738f7f) may cause Python to crash due to a Tk segfault on OS X. The crash only shows up when using the -j option to regrtest and is dependent on other factors, e.g. 64-bit vs 32-bit and randomized address space allocations, so it is not 100% reproducible. But it happens often enough (to me) when running the Python test suite from an installed framework location with a current Cocoa Tk 8.5.x or 8.6.x, for example, with an instance from a python.org binary installer: /usr/local/bin/python3.4 -m test -w -uall -j3 The reasons for the segfault are due to an arcane bug in Tk which shows up when Tcl interpreter instances are destroyed and created within the execution of an OS X app bundle, behavior which now happens as a result of the above changes when -j 0 is used in an OS X framework build. There is a more detailed analysis in the Tk bug I've opened: https://core.tcl.tk/tk/tktview?name=c18c36f80c The bug is not one that most Tk users would run into, I think, so it's certainly not a critical bug in Tk. But it is annoying to run into when running Python tests. On the other hand, I'm not sure that it is worth trying to work around the problem in the tests; I think the basic idea of the Issue22236 changes is sound. There is a relatively easy workaround if one runs into the problem: exclude the two problematic Tk tests and run them separately sequentially. pythonx.y -m test -w -uall -j3 -x test_tk test_ttk_guionly pythonx.y -m test -w -ualltest_tk test_ttk_guionly (-m test.regrtest for Python 2.7.x) It may be sufficient to just document the workaround here in case others run into it. -- components: Tests, Tkinter messages: 230307 nosy: ned.deily, serhiy.storchaka priority: normal severity: normal status: open title: test_ttk_guionly and test_tk can cause Tk segfaults on OS X when run with regrtest -j option versions: Python 2.7, Python 3.4, Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22770 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22236] Do not use _default_root in Tkinter tests
Ned Deily added the comment: See Issue22770 for details of a potential Tk crash that can occur on OS X when running tests as a result of these changes and for a workaround. -- nosy: +ned.deily ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22236 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22770] test_ttk_guionly and test_tk can cause Tk segfaults on OS X when run with regrtest -j option
Ned Deily added the comment:
For the record, a typical instance of this failure will look like this:
$ /usr/local/bin/python3.4 -m test -w -uall -j2
== CPython 3.4.2 (v3.4.2:ab2c023a9432, Oct 5 2014, 20:42:22) [GCC 4.2.1 (Apple
Inc. build 5666) (dot 3)]
== Darwin-14.0.0-x86_64-i386-64bit little-endian
== hash algorithm: siphash24 64bit
== /private/var/folders/fm/9wjgctqx61n796zt88qmmnxcgq/T/test_python_89951
Testing with flags: sys.flags(debug=0, inspect=0, interactive=0, optimize=0,
dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=0,
verbose=0, bytes_warning=0, quiet=0, hash_randomization=1, isolated=0)
[...] test_ttk_guionly
Fatal Python error: Segmentation fault
Current thread 0x7fff747dd300 (most recent call first):
File
/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/tkinter/__init__.py,
line 496 in wait_visibility
File
/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/tkinter/test/test_ttk/test_extensions.py,
line 121 in test_horizontal_range
File
/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/unittest/case.py,
line 577 in run
File
/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/unittest/case.py,
line 625 in __call__
File
/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/unittest/suite.py,
line 125 in run
File
/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/unittest/suite.py,
line 87 in __call__
File
/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/unittest/suite.py,
line 125 in run
File
/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/unittest/suite.py,
line 87 in __call__
File
/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/unittest/runner.py,
line 168 in run
File
/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/test/support/__init__.py,
line 1750 in _run_suite
File
/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/test/support/__init__.py,
line 1784 in run_unittest
File
/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/test/test_ttk_guionly.py,
line 34 in test_main
File
/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/test/regrtest.py,
line 1280 in runtest_inner
File
/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/test/regrtest.py,
line 978 in runtest
File
/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/test/regrtest.py,
line 532 in main
File
/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/test/regrtest.py,
line 1564 in main_in_temp_cwd
File
/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/test/regrtest.py,
line 1589 in module
File
/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/runpy.py,
line 85 in _run_code
File
/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/runpy.py,
line 170 in _run_module_as_main
Traceback (most recent call last):
File
/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/runpy.py,
line 170, in _run_module_as_main
__main__, mod_spec)
File
/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/runpy.py,
line 85, in _run_code
exec(code, run_globals)
File
/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/test/__main__.py,
line 3, in module
regrtest.main_in_temp_cwd()
File
/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/test/regrtest.py,
line 1564, in main_in_temp_cwd
main()
File
/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/test/regrtest.py,
line 738, in main
raise Exception(Child error on {}: {}.format(test, result[1]))
Exception: Child error on test_ttk_guionly: Exit code -11
and the system crash report will look something like this:
[...]
Process: Python [89955]
Path:
/Library/Frameworks/Python.framework/Versions/3.4/Resources/Python.app/Contents/MacOS/Python
Identifier:org.python.python
Version: 3.4.2 (3.4.2)
Code Type: X86-64 (Native)
Parent Process:Python [89951]
Responsible: iTerm [64155]
User ID: 503
Date/Time: 2014-10-30 12:47:52.051 -0700
OS Version:Mac OS X 10.10 (14A389)
Report Version:11
Anonymous UUID:CFED52E3-698C-835B-D61C-F4B1F18D2CB6
Time Awake Since Boot: 60 seconds
Crashed Thread:0 Dispatch queue: com.apple.main-thread
Exception Type:EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x0170
VM Regions Near 0x170:
--
__TEXT 0001-00011000 [4K] r-x/rwx
SM=COW
/Library/Frameworks/Python.framework/Versions/3.4.2_10_6/Resources/Python.app/Contents/MacOS/Python
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 libsystem_kernel.dylib 0x7fff90cadc7e __kill + 10
1 ???
[issue22769] Tttk tag_has() throws TypeError when called without item
Changes by Serhiy Storchaka storch...@gmail.com: -- assignee: - serhiy.storchaka stage: - needs patch versions: +Python 3.4, Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22769 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22410] Locale dependent regexps on different locales
Roundup Robot added the comment: New changeset d565dbf576f9 by Serhiy Storchaka in branch '2.7': Fixed compile error in issue #22410. The _locale module is optional. https://hg.python.org/cpython/rev/d565dbf576f9 New changeset 0c016fa378db by Serhiy Storchaka in branch '3.4': Fixed compile error in issue #22410. The _locale module is optional. https://hg.python.org/cpython/rev/0c016fa378db New changeset 1d87ac92b041 by Serhiy Storchaka in branch 'default': Fixed compile error in issue #22410. The _locale module is optional. https://hg.python.org/cpython/rev/1d87ac92b041 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22410 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22764] object lifetime fragility in unittest tests
Robert Collins added the comment: I've done some experimentation. Yes, the updated test passes when the clear_frames call is removed in cPython 3.5 But the original test also passes when clear_frames is not called if one drops into pdb and steps through, which still fits the symptoms of having a loop. The problem is then, that gc-only interpreters make no guarantees about lifetime of objects and this test needs a guarantee. As such I think conditional skipping is probably best. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22764 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22764] object lifetime fragility in unittest tests
Changes by Robert Collins robe...@robertcollins.net: Added file: http://bugs.python.org/file37080/issue22764.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22764 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22153] Documentation of TestCase.runTest is incorrect and confusing
Robert Collins added the comment: I'll apply the patch monday if there are no further comments before then. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22153 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22764] object lifetime fragility in unittest tests
Antoine Pitrou added the comment: There's the cpython_only decorator in test.support. I think CPython is the only popular refcounting implementation. (of course I don't know which implementations may qualify as popular exactly :-)) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22764 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22410] Locale dependent regexps on different locales
Serhiy Storchaka added the comment: Thank you for your review Antoine. Committed patch has fixed only part of the problem. It doesn't fix the problem of explicitly compiled patterns. Better solution requires changes to the _sre module. -- resolution: - fixed stage: patch review - versions: -Python 2.7, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22410 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22457] load_tests not invoked in root __init__.py when start=package root
Robert Collins added the comment: (Pinging for reviews - I'm going to time out and land this early next week if I can't get a review on it, since this is actually a fairly significant oversight and I don't want unittest2 to run ahead of the stdlib - that way leads unmaintainable madness). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22457 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22542] Use arc4random under OpenBSD for os.urandom() if /dev/urandom is not present
STINNER Victor added the comment: The issue is about the base if /dev/urandom is not present. How is arc4random() PRNG/CPRNG initialized if /dev/urandom is *not* present? Can we rely on it if it only uses a poor seed? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22542 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22417] PEP 476: verify HTTPS certificates by default
Alex Gaynor added the comment: Updates to teh docs based on teh feedback from Antoine. -- Added file: http://bugs.python.org/file37081/issue22417.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22417 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22770] test_ttk_guionly and test_tk can cause Tk segfaults on OS X when run with regrtest -j option
Terry J. Reedy added the comment: when -j 0 is used in an OS X framework build Did you mean -j 1? I checked the buildbots and the x86 Tiger is run -j1 while the AMD Snow Leopard is not running. -- nosy: +terry.reedy ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22770 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22768] Add a way to get the peer certificate of a SSL Transport
Guido van Rossum added the comment:
Maybe
transport.get_extra_info('socket').getpeercert(True)
would be okay, no patch needed?
On Thu, Oct 30, 2014 at 11:56 AM, Antoine Pitrou rep...@bugs.python.org
wrote:
Antoine Pitrou added the comment:
some methods take parameters (like the offender getpeercert(bool), or
get_channel_binding() that takes an element of
ssl.CHANNEL_BINDING_TYPES, list that may grow in the future) that need
to be covered in the properties
That's a good point. I don't have any strong feelings either way. Perhaps
other people want to chime in?
As for the patch, it will need to add a unit test as well.
--
stage: - patch review
versions: +Python 3.5 -Python 3.4
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22768
___
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22768
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22770] test_ttk_guionly and test_tk can cause Tk segfaults on OS X when run with regrtest -j option
Ned Deily added the comment: Did you mean -j 1? No. I checked the buildbots and the x86 Tiger is run -j1 while the AMD Snow Leopard is not running. I'm not sure what you are referring to here. This crash would not be seen on either of those buildbots because (1) they are not configured as framework builds, (2) they don't install Python and run the tests from there (rather they run from the build directory), (3) the user name under which the buildbot tests run would have to be logged in as the current interactive user (e.g. owning the window server) to run test_tk or test_ttk_guionly; (4) Tiger (OS X 10.4) is too old to run Cocoa Tk. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22770 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
