[issue20334] make inspect Signature hashable
Antony Lee added the comment: The hash function of the Signature class is actually incompatible with the definition of Signature equality, which doesn't consider the order of keyword-only arguments: from inspect import signature s1 = signature(lambda *, x, y: None); s2 = signature(lambda *, y, x: None) s1 == s2 True hash(s1) == hash(s2) False Actually the implementation of Signature.__eq__ seems way too complicated; I would suggest making a helper method returning (return_annotation, tuple(non-kw-only-params), frozenset(kw-only-params)) so that __eq__ can compare these values while __hash__ can hash that tuple. -- nosy: +Antony.Lee ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20334 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22192] dict_values objects are hashable
Raymond Hettinger added the comment: Do you want to submit a patch and tests? Also take a look at the collections.abc MappingViews. -- assignee: - rhettinger nosy: +gvanrossum priority: normal - low stage: - needs patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22192 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22196] namedtuple documentation could/should mention the new Enum type
Changes by Raymond Hettinger raymond.hettin...@gmail.com: -- assignee: docs@python - rhettinger nosy: +rhettinger priority: normal - low ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22196 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22186] Typos in .py files
Raymond Hettinger added the comment: I'll apply this shortly. -- assignee: docs@python - rhettinger nosy: +rhettinger ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22186 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22193] Add _PySys_GetSizeOf()
Serhiy Storchaka added the comment: Here is a patch which adds overflow check. The question is: should sys.getsizeof with the default argument catch OverflowError in additional to TypeError and replace it by default value? -- Added file: http://bugs.python.org/file36376/_PySys_GetSizeOf_overflow.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22193 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22192] dict_values objects are hashable
Serhiy Storchaka added the comment: There is a question. What builtin types should be hashable? In particular, should be hashable iterators, generators? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22192 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6973] subprocess.Popen.send_signal doesn't check whether the process has terminated
Changes by Tshepang Lekhonkhobe tshep...@gmail.com: -- nosy: +tshepang versions: -Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6973 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6973] subprocess.Popen.send_signal doesn't check whether the process has terminated
Changes by Tshepang Lekhonkhobe tshep...@gmail.com: -- versions: +Python 3.5 -Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6973 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22200] Remove distutils checks for Python version
Changes by Berker Peksag berker.pek...@gmail.com: -- stage: - patch review type: - enhancement versions: +Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22200 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22203] inspect.getargspec() returns wrong spec for builtins
R. David Murray added the comment: These used to raise an error. Not sure if the fact that they don't now is intentional or not (eventually they will return a real value when the argument clinic project is finished). -- nosy: +r.david.murray ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22203 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8797] urllib2 basicauth broken in 2.6.5: RuntimeError: maximum recursion depth exceeded in cmp
Senthil Kumaran added the comment: This bug has been open for a while and I had lost sight of it. Upon prompted recently, I dug bit into history and could think of a good solution. A brief history. 1. The bug maximum recursion depth exceeded when doing Basic Authentication was introduced in 5f9939af2f71 (issue3819). I verified it by doing hg update 5f9939af2f71 and running basic authentication test against a server. 2. This was 'fixed' with giving an upper limit to retries and doing it similar to Digest Authentication as part of this ticket and it is case recent current tip (acb30ed7eceb when I ran the test). However, this fix is not satisfactory for multiple reasons like fix is not satisfactory and not having concrete reasons for doing retries for Basic Auth and why 401 error should be considered special. I agree with this, this fix was more like to avoid recursion and throw the correct HTTPError. Also, it is important to note that, before a regression was introduced in r59118, the prior revision ( hg update 5f9939af2f71^ -which led me to c8ef906b11b8) had correct behavior, where HTTPError was thrown upon invalid user:pass immediately. So, going back to that behavior was the right thing to do. Sam Bull's suggestion and patch looks right to me. It is correct to verify the un-redirected hdrs too when checking for auth and go with the behavior as it in c8ef906b11b8) I have improved upon the patch for 3.5 and added tests which were not present too. I think, this should go in all active versions of python as there is no api change or behavior behavior, but improvement in way HTTPError is thrown. -- versions: +Python 3.4, Python 3.5 -Python 2.6 Added file: http://bugs.python.org/file36377/issue8797_with_tests.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8797 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22204] 2014 USA CONFERENCE/INVITATION!!
New submission from LuisC: Dear Colleagues On behalf of California Human Welfare Foundation. It is a great privilege for us to invite you to global Congress meeting Against Economic Crisis, Prostitution, Human Trafficking and child abuse HIV/AIDS Treatment, held in the united state and in Dakar Senegal. All interested delegates that requires entry visa to enter the United States to attend this meeting will be assisted by the organization in obtaining the visa in their passport free air round trip tickets to attend this meeting will be provided to all participants. For registration contact the secretariat at: secretaryand...@foxmail.com Please share the information with your colleagues. Sincerely, Dr.Tyler Lockett (Ph.D) Senior Activities Coordinator. -- messages: 225350 nosy: lcarrionr priority: normal severity: normal status: open title: 2014 USA CONFERENCE/INVITATION!! ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22204 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22204] 2014 USA CONFERENCE/INVITATION!!
Changes by Ezio Melotti ezio.melo...@gmail.com: -- Removed message: http://bugs.python.org/msg225350 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22204 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22204] spam
Changes by Ezio Melotti ezio.melo...@gmail.com: -- nosy: -lcarrionr resolution: - not a bug stage: - resolved status: open - closed title: 2014 USA CONFERENCE/INVITATION!! - spam ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22204 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22195] Make it easy to replace print() calls with logging calls
Vinay Sajip added the comment:
Here's a tentative suggestion. Does it meet your needs?
import logging
import sys
class LoggerWriter(object):
def __init__(self, logger='', level=logging.DEBUG):
if isinstance(logger, str):
logger = logging.getLogger(logger)
self.logger = logger
self.level = level
self.buffer = ''
def _output(self, force):
lines = self.buffer.split('\n')
if force:
self.buffer = ''
else:
self.buffer = lines.pop()
for line in lines:
self.logger.log(self.level, line)
def flush(self):
self._output(True)
def write(self, text):
self.buffer += text
self._output(False)
def main():
stream = LoggerWriter()
with open('lwtest.txt', 'w') as f:
print('foo', 1, 'bar\n\n', 2.0, 'baz', file=stream)
print(file=stream)
print('foo', 1, 'bar\n\n', 2.0, 'baz', file=f)
print(file=f)
print('frob', end=' ', file=stream)
print('frob', end=' ', file=f)
f.flush()
stream.flush()
if __name__ == '__main__':
logging.basicConfig(level=logging.DEBUG, format='%(levelname)-8s
%(message)s',
filename='lwtest.log')
sys.exit(main())
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22195
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22193] Add _PySys_GetSizeOf()
Martin v. Löwis added the comment:
Christian: I don't see why 24 bytes overhead sounds strange. GC_Head is
typedef union _gc_head {
struct {
union _gc_head *gc_next;
union _gc_head *gc_prev;
Py_ssize_t gc_refs;
} gc;
double dummy; /* force worst-case alignment */
} PyGC_Head;
which happens to be 3*8=24 bytes on a 64-bit system.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22193
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22195] Make it easy to replace print() calls with logging calls
Changes by Barry A. Warsaw ba...@python.org: -- nosy: +barry ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22195 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22192] dict_values objects are hashable
Ben Roberts added the comment: I have a patch with tests for this (running the test suite now) but I am increasingly unsure if python isn't doing the right thing already. Intuitively, it feels wrong (to me) to allow a dict_values view to be hashable since the mapping onto which it provides a view is certainly mutable. And mutable things shouldn't be hashable, everyone knows that. However the dict_values object /itself/ doesn't violate the contract of hashability - its hash (which just uses its id()) doesn't change across its lifetime, and some_values_view == foo will only be true iff foo is some_values_view whereas e.g. some_keys_view == some_other_keys_view CAN change across the lifetime of those objects - so the asymmetry here does make sense. It is taking me a while to wrap my brain around this because I often think in terms of mutable/immutable but the only thing that's important is the hashability contract, which is not currently violated by dict_values objects. I'm certainly willing to be talked out of my change of opinion here :-), my intuition hasn't fully caught up with my logic. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22192 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22192] dict_values objects are hashable
Guido van Rossum added the comment: It's clear that dict.values() shouldn't be hashable -- using the identity is plain wrong here. But shouldn't the fix be to implement rich comparisons for dict.values()? I think just a a.keys() == set(a.keys()), a.values() should be == set(a.values()). Let's move the question about whether generators and iterators should be hashable elsewhere. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22192 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22202] Function Bug?
Reza Shahrzad added the comment: Hi Steve, Thank you very much for your prompt reply, explanation and the concise resolution included. I guess, it will be a while before I can hope to find any real bugs in Python and that is something a beginner such as myself should only be grateful for! Thanks again, Respectfully, Reza Shahrzad -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22202 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22192] dict_values objects are hashable
Serhiy Storchaka added the comment: I think just a a.keys() == set(a.keys()), a.values() should be == set(a.values()). Every element of a.keys() is hashable and unique. a.values() can contain non- hashable repeated elements. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22192 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22194] access to cdecimal / libmpdec API
Changes by Stefan Krah stefan-use...@bytereef.org: Added file: http://bugs.python.org/file36378/api-demo[1].c ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22194 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22194] access to cdecimal / libmpdec API
Stefan Krah added the comment: I'm a little unsure what to do with the API, see also #15237: 1) I'm not too fond of the Capsule method, especially because it *seems* possible to get at the symbols directly on Linux and Windows (provided that they aren't static of course). 2) I would not like to spend time on it if we go ahead and make decimal a builtin (double effort). 3) It's not clear whether users would not be served better by using functions from libmpdec directly (much faster, probably less error handling). For 3) I've attached a draft that illustrates the issue. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22194 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22192] dict_values objects are hashable
Guido van Rossum added the comment: Oh. Yeah. Then I think there's nothing to do. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22192 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22198] Odd floor-division corner case
Stefan Krah added the comment: I think the intention of the standard is pretty much as Mark said in msg225314. The fact that decimal behaves that way is another indicator, since Cowlishaw really tried to mirror the 2008 standard as closely as possible. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22198 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22198] Odd floor-division corner case
Tim Peters added the comment: To be clear, I agree -0.0 is the correct answer, and -1.0 is at best defensible via a mostly-inappropriate limit argument. But in Py3 floor division of floats returns an integer, and there is no integer -0. Nor, God willing, will there ever be ;-) Looks to me like what (Py3's, at least) floatobject.c's floor_divmod() returns (the source of float floor division's result) when the 2nd argument is infinite is largely an accident, depending on what the platform C fmod() and floor() happen to return. So it would require special-casing an infinite denominator in that function to force any specific cross-platform result. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22198 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20334] make inspect Signature hashable
Yury Selivanov added the comment: Thanks, Antony, this is a good catch. Your suggestion seems like a good idea. I'll look into this more closely soon. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20334 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22205] debugmallocstats test is cpython only
New submission from Martin Matusiak: sys._debugmallocstats is a cpython specific feature, so test_debugmallocstats should be marked as such. -- files: debugmallocstats.diff keywords: patch messages: 225362 nosy: numerodix, serhiy.storchaka priority: normal severity: normal status: open title: debugmallocstats test is cpython only Added file: http://bugs.python.org/file36379/debugmallocstats.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22205 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22181] os.urandom() should use Linux 3.17 getrandom() syscall
STINNER Victor added the comment: Manual page of the OpenBSD getentropy() function: http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man2/getentropy.2 LibreSSL didn't wait for the libc, search for getentropy_getrandom(): http://openbsd.cs.toronto.edu/cgi-bin/cvsweb/src/lib/libcrypto/crypto/getentropy_linux.c?rev=1.32content-type=text/x-cvsweb-markup The code is currently disabled with #if 0. The syscall is directly used, the function doesn't handle the ENOSYS error. See also this issue of the cryptography project, Use getentropy(2) and getrandom(2) syscalls when available 1299: https://github.com/pyca/cryptography/issues/1299 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22181 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20334] make inspect Signature hashable
Antony Lee added the comment:
Actually, that specific solution (using a helper method) will fail because
there may be unhashable params (due to unhashable default values or
annotations) among the keyword-only arguments, so it may not be possible to
build a frozenset (rather, one should compare the {param.name: param if
param.kind == KEYWORD_ONLY} dict). The frozenset approach still works for
computing the hash as this requires all params to be hashable anyways.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20334
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22198] Odd floor-division corner case
eryksun added the comment:
decimal.Decimal 'floor division' is integer division that truncates toward 0
(see 9.4.2).
Decimal('-0.5').__floor__()
-1
Decimal('-0.5').__floordiv__(1)
Decimal('-0')
Numpy 1.8.1:
np.float32(-0.5) // 1
-1.0
np.float32(-0.5) // float('inf')
-0.0
np.array([-0.5]) // 1
array([-1.])
np.array([-0.5]) // float('inf')
array([-0.])
--
nosy: +eryksun
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22198
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22156] Fix compiler warnings
Roundup Robot added the comment: New changeset 9b84ff16edd4 by Victor Stinner in branch 'default': Issue #22156: Fix comparison between signed and unsigned integers compiler http://hg.python.org/cpython/rev/9b84ff16edd4 New changeset a0b38f4eb79e by Victor Stinner in branch 'default': Issue #22156: Fix comparison between signed and unsigned integers compiler http://hg.python.org/cpython/rev/a0b38f4eb79e -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22156 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22206] PyThread_create_key(): fix comparison between signed and unsigned numbers
New submission from STINNER Victor: The issue #22110 enabled more compiler warnings. I would like to fix this one: --- gcc -pthread -c -Wno-unused-result -Wsign-compare -g -O0 -Wall -Wstrict-prototypes-Werror=declaration-after-statement -I. -IInclude -I./Include-DPy_BUILD_CORE -o Python/thread.o Python/thread.c In file included from Python/thread.c:86:0: Python/thread_pthread.h: In function ‘PyThread_create_key’: Python/thread_pthread.h:611:22: attention : signed and unsigned type in conditional expression [-Wsign-compare] return fail ? -1 : key; ^ --- Attached patch uses Py_SAFE_DOWNCAST() to explicitly downcast to int. On Linux (on my Fedora 20/amd64), pthread_key_t is defined as an unsigned int, whereas the result type of PyThread_create_key is a signed int. Nobody complained before, so I get that nobody noticed the possible overflow for a key INT_MAX. I checked the code, we only check if PyThread_create_key() returns -1, if you reach UINT_MAX keys. UINT_MAX keys sounds insane, you probably hit another limit before. On Linux, it looks like the key is a counter and deleted values are reused: haypo@selma$ ./python Python 3.5.0a0 (default:a0b38f4eb79e, Aug 15 2014, 23:37:42) [GCC 4.8.3 20140624 (Red Hat 4.8.3-1)] on linux Type help, copyright, credits or license for more information. import ctypes ctypes.pythonapi.PyThread_create_key() 2 ctypes.pythonapi.PyThread_create_key() 3 ctypes.pythonapi.PyThread_create_key() 4 ctypes.pythonapi.PyThread_delete_key(3) 0 ctypes.pythonapi.PyThread_create_key() 3 -- files: PyThread_create_key.patch keywords: patch messages: 225367 nosy: haypo, neologix priority: normal severity: normal status: open title: PyThread_create_key(): fix comparison between signed and unsigned numbers versions: Python 3.5 Added file: http://bugs.python.org/file36380/PyThread_create_key.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22206 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22156] Fix compiler warnings
STINNER Victor added the comment: I created a specific issue for PyThread_create_key() of Python/thread_pthread.h: issue #22206. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22156 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22206] PyThread_create_key(): fix comparison between signed and unsigned numbers in Python/thread_pthread.h
Changes by STINNER Victor victor.stin...@gmail.com: -- title: PyThread_create_key(): fix comparison between signed and unsigned numbers - PyThread_create_key(): fix comparison between signed and unsigned numbers in Python/thread_pthread.h ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22206 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22207] Test for integer overflow on Py_ssize_t: explicitly cast to size_t
New submission from STINNER Victor: Python contains a lot of tests like this one: if (length PY_SSIZE_T_MAX / 4) return PyErr_NoMemory(); where length type is Py_ssize_t. This test uses signed integers. There is usually a assert(length 0); before. The issue #22110 enabled more compiler warnings and there are now warnings when the test uses an unsigned number. Example: if (size PY_SSIZE_T_MAX - PyBytesObject_SIZE) ... where PyBytesObject_SIZE is defined using offsetof() which returns a size_t. I propose to always cast Py_ssize_t length to size_t to avoid undefined behaviour (I never know if the compiler chooses signed or unsigned at the end) to ensure that the test also fail for negative number. For example, the following test must fail for negative size: if ((size_t)size (size_t)PY_SSIZE_T_MAX - PyBytesObject_SIZE) ... Attached patch changes bytesobject.c, tupleobject.c and unicodeobject.c (and asdl.c). If the global approach is accepted, more files should be patched. -- files: test_overflow_ssize_t.patch keywords: patch messages: 225369 nosy: haypo, neologix, serhiy.storchaka priority: normal severity: normal status: open title: Test for integer overflow on Py_ssize_t: explicitly cast to size_t versions: Python 3.5 Added file: http://bugs.python.org/file36381/test_overflow_ssize_t.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22207 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22156] Fix compiler warnings
STINNER Victor added the comment: I created another more specific issue: #22207, Test for integer overflow on Py_ssize_t: explicitly cast to size_t. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22156 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20779] Add pathlib.chown method
Changes by Chris Rebert pyb...@rebertia.com: -- nosy: +cvrebert ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20779 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22156] Fix compiler warnings comparison between signed and unsigned integers
Changes by STINNER Victor victor.stin...@gmail.com: -- title: Fix compiler warnings - Fix compiler warnings comparison between signed and unsigned integers ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22156 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22156] Fix compiler warnings comparison between signed and unsigned integers
Roundup Robot added the comment: New changeset e831a98b3f43 by Victor Stinner in branch 'default': Issue #22156: Fix some comparison between signed and unsigned integers http://hg.python.org/cpython/rev/e831a98b3f43 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22156 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22207] Test for integer overflow on Py_ssize_t: explicitly cast to size_t
STINNER Victor added the comment: overflow2.patch: more changes for this issue (it doesn't replace my previous patch). -- Added file: http://bugs.python.org/file36382/overflow2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22207 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22156] Fix compiler warnings comparison between signed and unsigned integers
STINNER Victor added the comment: Ok, I fixed many warnings in this issue. I will open new issues for other warnings. -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22156 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22208] tarfile can't add in memory files (reopened)
New submission from Mark Grandi:
So I ran into this problem today, where near impossible to create a
tarfile.TarFile object, then add files to the archive, when the files are in
memory file-like objects (like io.BytesIO, io.StringIO, etc)
code example:
###
import tarfile, io
tarFileIo = io.BytesIO()
tarFileObj = tarfile.open(fileobj=tarFileIo, mode=w:xz)
fileToAdd = io.BytesIO(hello world!.encode(utf-8))
# fixes AttributeError: '_io.BytesIO' object has no attribute 'name'
fileToAdd.name=helloworld.txt
# fails with 'io.UnsupportedOperation: fileno'
tarInfo = tarFileObj.gettarinfo(arcname=helloworld.txt, fileobj=fileToAdd)
# never runs
tarFileObj.addfile(tarInfo, fileobj=fileToAdd)
###
this was previously reported as this bug: http://bugs.python.org/issue10369 but
I am unhappy with the resolution of its not a bug, and the 'hack' that Lars
posted as a solution. My reasons:
1: The zipfile module supports writing in memory files / bytes , using the
following code (which is weird but it works)
tmp = zipfile.ZipFile(tmp.zip, mode=w)
import io
x = io.BytesIO(hello world!.encode(utf-8))
tmp.writestr(helloworld.txt, x.getbuffer())
tmp.close()
2: the 'hack' that Lars posted, while it works, this is unintuitive and
confusing, and isn't the intended behavior. What happens if your script is
cross platform, what file do you open to give to os.stat()? In the code posted
it uses open('/etc/passwd/') for the fileobj parameter to gettarinfo(), but
that file doesn't exist on windows, now not only are you doing this silly hack,
you have to have code that checks platform.system() to get a valid file that is
known to exist for every system, or use sys.executable, except the
documentation for that says it can return None or an empty string.
3: it is easy to fix (at least to me), in tarfile.gettarinfo(), if fileobj is
passed in, and it doesn't have a fileno, then to create the TarInfo object, you
set 'name' to be the arcname parameter, size = len(fileobj), then have default
(maybe overridden by keyword args to gettarinfo()) values for
uid/gid/uname/gname.
On a random tar.gz file that I downloaded from sourceforge, the uid/gid are
'500' (when my gid is 20 and uid is 501), and the gname/uname are just empty
strings. So its obvious that those don't matter most of the time, and when they
do matter, you can modify the TarInfo object after creation or pass in values
for them in a theoretical keywords argument to gettarinfo().
If no one wants to code this I can provide a patch, I just want the previous
bug report's status of not a bug to be reconsidered.
--
components: Library (Lib)
messages: 225374
nosy: markgrandi
priority: normal
severity: normal
status: open
title: tarfile can't add in memory files (reopened)
versions: Python 3.4
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22208
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22191] warnings.__all__ incomplete
Jon Poler added the comment: Here is a patch that changes __all__ in Lib/warnings.py to include the functions mentioned in the library reference https://docs.python.org/dev/library/warnings.html#available-functions. A unittest is included. This is my first patch, so comments/feedback are welcome (from now on, I should probably add). -- keywords: +patch Added file: http://bugs.python.org/file36383/warnings.__all__.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22191 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14146] IDLE: source line in editor doesn't highlight when debugging
Terry J. Reedy added the comment: Regardless of what I said in the previous message, highlighting of found text is NOT working in any current release -- 2.7.8, 3.3.5 (final release) and 3.4.1. Mark Lawrence opened #22179. I propose there to use the 'found' highlight, as used in the replace dialog. for the find dialog also. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14146 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17535] IDLE: Add an option to show line numbers along the left side of the editor window, and have it enabled by default.
Ned Deily added the comment: As Terry requested, here are a few comments on running linenumber-text-widget-v1.diff on OS X. Overall, this looks to me to be a useful option. 1. Having line numbering enabled by default was a bit of a surprise, particularly in light of 2. 2. The Toggle Linenumbering menu item should be in the Options menu cascade, not the Window(s) one. I believe Options is where other extensions add their menu items. Initially, I could see no way to disable line numbering without knowing how to create, if necessary, and edit ~/.idlerc/config-extensions.cfg, which presumable few users do. Only later did I stumble across the Toggle Linenumbering menu option in the Window menu cascade. As an OS X user, I would never have thought to look there; normally on OS X, that menu cascade is limited to options related to selecting windows or tabs and selected options related to them, like Zoom or Minimize. (Presumably, the edit extensions preferences feature will help provide another, standard way for the user to deal with this in the long run.) 3. I found the default color values made the line numbers difficult to read. Perhaps a better default would be fgcolor=White instead of Black when bgcolor=Gray? 4. The extension fails to load with Tk 8.4.x: _tkinter.TclError: unknown option -inactiveselectbackground It appears that option is new in Tk 8.5: http://www.tcl.tk/man/tcl8.4/TkCmd/text.htm http://www.tcl.tk/man/tcl8.5/TkCmd/text.htm#M-inactiveselectbackground I'm not sure what to recommend here. Eventually, 8.4.x usage will slowly fade away so demanding that IDLE, especially extensions, not depend on any post-8.4 features may be a too-restrictive constraint. Perhaps it is OK to just test for pre-8.5 at extension initialization and cleanly skip if Tk is too old. 5. The LineNumber extension should be added to the list of default extensions in the IDLE Help file (Lib/idlelib/help.txt) and the IDLE section of the Library Reference (Doc/library/idle.rst). Also add the Toggle Linenumbering menu item. 6. The LineNumber extension config-extensions.def options need to be documented for the user (this is a generic issue for IDLE extensions). For example, I would not have had any clue that it was possible to enable line numbers for the shell window without examining the file and noticing the enable_shell=0 hint. (Noted in passing: while the help/doc suggests: See the beginning of config-extensions.def in the idlelib directory for further information., even in the unlikely event that a user knew in what directory to look for it, it's not possible to open that file in an IDLE editor window with the current default Cocoa Tk's since Cocoa Tk does not provide a filter option on the open window; only .py* and .txt files can be opened.) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17535 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22209] Idle: add better access to extension information
New submission from Terry J. Reedy: In msg225377 of #17535, Ned Daily says (Noted in passing: while the help/doc suggests: See the beginning of config-extensions.def in the idlelib directory for further information., even in the unlikely event that a user knew in what directory to look for it, it's not possible to open that file in an IDLE editor window with the current default Cocoa Tk's since Cocoa Tk does not provide a filter option on the open window; only .py* and .txt files can be opened.) Users should not normally poke around idlelib and should not need to or be asked to. The extension information should either be added to the idle doc or make accessible on the help menu with an new 'Extensions' entry. If the docstring were moved to, say, configHandler.py, it would be trivial to access: 'from configHandler import __doc__ and help_extension. Since configHandler already knows how to find the file, we can just read it up to the second line. Note: regardless of the resolution of this issue, show_text() should be altered to start wide enough to show 80 char lines. -- messages: 225378 nosy: terry.reedy priority: normal severity: normal stage: needs patch status: open title: Idle: add better access to extension information type: enhancement versions: Python 2.7, Python 3.4, Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22209 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17535] IDLE: Add an option to show line numbers along the left side of the editor window, and have it enabled by default.
Terry J. Reedy added the comment: Thanks for the comments. 1. I previously said somewhere 'enabled but initially off' by default. I intend to make sure of that before committing. 2. Option menu sounds good.. 3. I tried out a *much* lighter gray, as with Notepad++. Saimadhav is leaving that to me to determin and change. 4. If inactiveselectbackground is needed and there is no alternative (Saimadhav?) I would be inclined to skip pre-8.5. 5. I have put off writing a doc until the spec is finished. (And I would like to have help.txt auto-generated from idle.rst, which is an issue somewhere.) 6. I do not intend line numbering for Shell. Rather, the sidebar should be used for prompt and output markers to solve #7676. The patch has been written with this in mind. How to handle this vis-a-vis config-extensions had not been decided yet. I would prefer one [sidebar] section, but Saimadhav does not think that is possible. In any case, we have focused first on just line numbering, which I would like to push with the revisions indicated above, and then adding breakpoint toggling (in a followup patch, separately reviewed) and the shell sidebar (in yet another patch, ditto). (Note. see #22209) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17535 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14146] IDLE: source line in editor doesn't highlight when debugging
Terry J. Reedy added the comment: Sorry, wrong issue (should have been #17511). Debugger source line highlighting works fine. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14146 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22208] tarfile can't add in memory files (reopened)
Changes by Ned Deily n...@acm.org: -- nosy: +lars.gustaebel ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22208 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17511] Idle find function closes after each find operation
Terry J. Reedy added the comment: Immediate highlighting of SearchDialog found text (before closing) does not work on Windows in any current release -- 2.7.8, 3.3.5 (final release) and 3.4.1. Though I continued to use ^F, ^G. Mark Lawrence noticed this and opened #22179. I propose there to use the 'found' highlight, as already used in the replace dialog, for the find dialog also. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17511 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22179] Idle. Search dialog found text not highlited on Windows
Terry J. Reedy added the comment: The focus *should* stay on the dialog, #17511, but the found text should be highlighted with the 'found' highlight, as it is for Replace in Editor (but not Output) windows. The issue is that found text on Windows is not hightlighted in any way. It apparently is on other platforms, though I am not sure which way (but probably as 'selected' rather than 'found'). Hence the title change. There must be some difference between the Find Next code in Search dialog and the Find code in Replace. The relevant code for Find Next is SearchDialog.SearchDialog.find_again, after 'if res:' (if pattern found). The corresponding code in Find is ReplaceDialog.ReplaceDialog.do_find after the 'if not res:' block. I believe I found the crucial difference. Do_find is similar to find_again except for putting the tag and show code in a separate .show_hit method. Show_hit has code to clear and then set a 'hit' tag. The hit tag is associated with the hit (found) highlight in ColorDelegator.LoadTagDefs and config_colors. # The following is used by ReplaceDialog: hit: idleConf.GetHighlight(theme, hit), and self.tag_configure(tag, **cnf) The fix is to use 'hit' in SearchDialog also. I believe the show_hit slightly modified could be moved to SearchDialogBase and used in find_again. For output windows, Search is active but ColorDelegator is not. ColorDelegator does not use 'hit'. The tag_configure for 'hit' can and should be moved to SearchDialogBase. (I either have or will moved 'break' confiuration away.) A note on selection highlighting. When Debugger is running with [x]Source, source lines are marked with the 'selected; highlight. Debugger.Debugger.show_source calls Debugger.sync_source_line which calls self.flist.gotofileline(filename, lineno) which selects the line in the file. In msg186609 of #17511, which was about keeping the dialog open after Find Next, Roger claimed that the patch for #14146, which was about highlighting source (as selected) when debugger is open, would also fix highlighting found source when Find is open. The patch, b56ae3f878cb (for 3.4) adds a Windows-specific def _highlight_workaround(self) to EditorWindow. But is does not cause select highlighting in either Search or Replace windows. I believe it works for Debugger because gotofileline temporarily changes focus to the editor window containing the file, raising it to the top, before focus shifts back to Debugger, putting it back on top of the editor (usually) if there is overlap. The highlight workaround highlights the sel_fix tag (a substitute for sel) as focus leaves the editor. To mark found text with the 'selected' highlight, we would have to shift focus temporarily to the editor by some other means. But 1. the 'experimental' debugger is temperamental and sometimes freezes Idle, and I don't know if the focus shifting has anything to do with that; 2. I think consistently using the 'found' highlight for both search dialog is better anyway. -- nosy: +roger.serwy stage: - test needed title: Focus stays on Search Dialog when text found in editor - Idle. Search dialog found text not highlited on Windows versions: +Python 2.7, Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22179 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22210] pdb-run-restarting-a-pdb-session
New submission from linuxie: I was running pdb from the command line. Whenever I restart, It throws the error: Traceback (most recent call last): File /usr/local/lib/python2.7/dist-packages/tornado/web.py, line 861, in _execute getattr(self, self.request.method.lower())(*args, **kwargs) File main.py, line 33, in post res = user.login( platform_id, platform_type) File main.py, line 33, in post res = user.login( platform_id, platform_type) File /home/work/src/Python-2.7.8/Lib/bdb.py, line 49, in trace_dispatch return self.dispatch_line(frame) File /home/work/src/Python-2.7.8/Lib/bdb.py, line 67, in dispatch_line self.user_line(frame) File /home/work/src/Python-2.7.8/Lib/pdb.py, line 158, in user_line self.interaction(frame, None) File /home/work/src/Python-2.7.8/Lib/pdb.py, line 210, in interaction self.cmdloop() File /home/work/src/Python-2.7.8/Lib/cmd.py, line 142, in cmdloop stop = self.onecmd(line) File /home/work/src/Python-2.7.8/Lib/pdb.py, line 279, in onecmd return cmd.Cmd.onecmd(self, line) File /home/work/src/Python-2.7.8/Lib/cmd.py, line 221, in onecmd return fu nc(arg) File /home/work/src/Python-2.7.8/Lib/pdb.py, line 679, in do_run raise Restart Restart I wonder why a so big bug has not been solved. -- messages: 225383 nosy: zhengxiexie priority: normal severity: normal status: open title: pdb-run-restarting-a-pdb-session type: behavior versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22210 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
