[issue13643] 'ascii' is a bad filesystem default encoding
New submission from Martin : Currently when running Python on a non-OSX posix environment under either the C locale, or with an invalid or missing locale, it's not possible to operate using unicode filenames outside the ascii range. Using bytes works, as does reading expecting unicode, using the surrogates hack. This makes robustly working with non-ascii filenames on different platforms needlessly annoying, given no modern nix should have problems just using UTF-8 in these cases. See the downstream bzr bug for more: <https://bugs.launchpad.net/bzr/+bug/794353> One option is to just use UTF-8 for encoding and decoding filenames when otherwise ascii would be used. As a strict superset, this shouldn't break too many existing assumptions, and it's unlikely that non-UTF-8 filenames will accidentally be mangled due to a locale setting blip. See the attached patch for this behaviour change. It does not include a test currently, but it's possible to write one using subprocess and overriden LANG and LC_ALL vars. -- components: Interpreter Core files: /tmp/filesystem_encoding_utf8.patch keywords: patch messages: 149924 nosy: benjamin.peterson, gz priority: normal severity: normal status: open title: 'ascii' is a bad filesystem default encoding versions: Python 3.3 Added file: http://bugs.python.org/file24064//tmp/filesystem_encoding_utf8.patch ___ Python tracker <http://bugs.python.org/issue13643> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13643] 'ascii' is a bad filesystem default encoding
Martin added the comment: > I'm not sure why having a locale set to C or something invalid should be > considered a Python bug. You have to handle un-decodable filenames no > matter what you do, since things aren't always encoded in utf-8 on non-OSX > unix even when that is the system locale. It's just something you have to > live with. This is more about un-encodable filenames. At the moment work with non-ascii filenames in Python robustly requires two branches, one using unicode and one that encodes to bytestrings and deals with the case where the name can't be represented in the declared filesystem encoding. That may be something that just had to be lived with, but it's a little annoying when even without a UTF-8 locale for a particular process, that's what most systems will want on disk. -- type: -> behavior ___ Python tracker <http://bugs.python.org/issue13643> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13643] 'ascii' is a bad filesystem default encoding
Martin added the comment: > It was already discussed: using a different encoding for filenames and for > other things is really not a good idea. The main problem is the interaction > with other programs. Yes, for many programs, a change like this will mean they create the file, but then throw a traceback anyway when trying to print its name to stdout or something. > Read discussion of issues #8622, #8775 and #9992. Thanks. I agree that spreading different values to things like subprocess arguments and the environment is asking for trouble. Just changing how unicode filename are encoded by default seems safer, though it certainly won't help all code. > The right fix is to fix your locale, not Python. I've found that hard to stick to in the face of bug reports where "your locale" turns out to be "the locale used by some cronjob". Fixing my library to work under LANG=C is easier than bugging every downstream project. -- ___ Python tracker <http://bugs.python.org/issue13643> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13643] 'ascii' is a bad filesystem default encoding
Martin added the comment: > During 1 month, we had PYTHONFSENCODING environment variable. It was not a > good idea. I strongly agree. There is no sense in having a separate configurable value, anyone who would think about using a PYTHONFSENCODING should just change their locale instead. However, avoiding the need for manual intervention completely in a relatively narrow set of cases is still useful. > Not after Python start. Using two encodings at the same would just adds new > problems. On UNIX (at least on Linux?), it is mandatory to use the same > encoding for: > > - command line arguments > - environment variables > - filenames > - and more generally, all data exchanged with the system and other programs Having more than one encoding on unix is already a reality, there's nothing to stop someone setting LANG=de_DE.UTF-8 and LC_MESSAGES=C say. The real lesson is not that having more than one encoding is dangerous, but that having incompatible encodings is dangerous. As 'ascii' is a strict subset of 'utf-8' the cross process communication issues are greatly lessened, at worst stuff just breaks still. Expanding the filesystem default encoding to utf-8 should be a very narrow change, mostly just affecting io and os operations. Other actions involving paths will still break if a non-ascii string is used, but without the possibility of mangling data. -- ___ Python tracker <http://bugs.python.org/issue13643> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13643] 'ascii' is a bad filesystem default encoding
Martin added the comment:
> Nope. The locale encoding is chosen using LC_ALL, LC_CTYPE or LANG
> variable: use the first non-empty variable. LC_MESSAGES doesn't affect
> the encoding. Example:
That's good to know, thanks. Only leaves the case where setlocale is called
again with a different value.
> Yes, and ASCII and UTF-8 are incompatible. ASCII is unable to decode an
> UTF-8 encoded string.
I think we're envisioning different things here.
os.stat("\u2601") # with LANG=C
current -> UnicodeEncodeError
changed -> works if utf-8 encoded file exists
os.listdir() # with LANG=C
current -> returns non-ascii as unicode with funky surrogates
changed -> returns non-utf-8 as unicode with funky surrogates
> It affects everything because filenames are used everywhere.
But currently everything handling filenames as unicode on nix needs to worry
about surrogates (that can't be encoded as ascii) already, or it will still be
passing values that can't be interpreted by other processes as you highlighed
earlier. Making utf-8 names come out correctly rather than as surrogates
doesn't seem like it increases the burden.
--
___
Python tracker
<http://bugs.python.org/issue13643>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13703] Hash collision security issue
Martin added the comment: I built random-2.patch on my windows xp box (updating the project and fixing some compile errors in random.c required), and initialising crypto has a noticeable impact on startup time. The numbers vary a fair bit naturally, two representative runs are as follows: changeset 52796:1ea8b7233fd7 on default branch: >timeit %PY3K% -c "import sys;print(sys.version)" 3.3.0a0 (default, Jan 7 2012, 00:12:45) [MSC v.1500 32 bit (Intel)] Version Number: Windows NT 5.1 (Build 2600) Exit Time:0:16 am, Saturday, January 7 2012 Elapsed Time: 0:00:00.218 Process Time: 0:00:00.187 System Calls: 4193 Context Switches: 445 Page Faults: 1886 Bytes Read: 642542 Bytes Written:272 Bytes Other: 31896 with random-2.patch and fixes applied: >timeit %PY3K% -c "import sys;print(sys.version)" 3.3.0a0 (default, Jan 7 2012, 00:58:32) [MSC v.1500 32 bit (Intel)] Version Number: Windows NT 5.1 (Build 2600) Exit Time:0:59 am, Saturday, January 7 2012 Elapsed Time: 0:00:00.296 Process Time: 0:00:00.234 System Calls: 4712 Context Switches: 642 Page Faults: 2049 Bytes Read: 1059381 Bytes Written:272 Bytes Other: 34544 This is with hot caches, cold will likely be worse, but a smaller percentage change. On a faster box, or with an SSD, or win 7, the delta will likely be smaller too. A 50-100ms slow down is consistent with the difference on Python 2.7 between calling `os.urandom(1)` or not. However, the baseline is faster with Python 2, frequently dipping under 100ms, so there this change could double the runtime of trivial scripts. -- nosy: +gz ___ Python tracker <http://bugs.python.org/issue13703> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12100] Incremental encoders of CJK codecs reset the codec at each call to encode()
Martin added the comment: Does Victor Stinner have a psychic link with Armin Rigo? :) https://bitbucket.org/pypy/pypy/src/7f593e7877d4/pypy/module/_multibytecodec/app_multibytecodec.py """ # My theory is that they are not widely used on CPython either, because # I found two bugs just by looking at their .c source: they always call # encreset() after a piece of data, even though I think it's wrong --- # it should be called only once at the end; and mbiencoder_reset() calls # decreset() instead of encreset(). """ The answer to Armin's theory is that they're bugs but not ones users are likely to notice? -- nosy: +arigo, gz ___ Python tracker <http://bugs.python.org/issue12100> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12171] Reset method of the incremental encoders of CJK codecs calls the decoder reset function
Martin added the comment: New cjk_encreset.patch looks good to me. As with issue 12100 this likely wasn't reported before because decoders are robust against escape sequence oddities. -- ___ Python tracker <http://bugs.python.org/issue12171> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12544] Avoid using a pseudo-dict for _type_equality_funcs in unittest
New submission from Martin : The fix for issue 10326 landing on Python 2.7 trunk has interfered with a hack I wrote in Bazaar to break the reference cycles the private `unittest.TestCase._type_equality_funcs` member creates. As the change to make pickling work is nearly enough to avoid the test and the dict referencing each other, it would be good to remove that breakage and the need for the hack in the first place. Downstream bug: <https://bugs.launchpad.net/ubuntu/+source/bzr/+bug/809048> -- components: Library (Lib) messages: 140217 nosy: MarkRoddy, gz, michael.foord priority: normal severity: normal status: open title: Avoid using a pseudo-dict for _type_equality_funcs in unittest type: behavior versions: Python 2.7, Python 3.2, Python 3.3 ___ Python tracker <http://bugs.python.org/issue12544> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12544] Avoid using a pseudo-dict for _type_equality_funcs in unittest
Changes by Martin : -- keywords: +patch Added file: http://bugs.python.org/file22636/avoid_TestCase_refcycle.diff ___ Python tracker <http://bugs.python.org/issue12544> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12544] Avoid using a pseudo-dict for _type_equality_funcs in unittest
Martin added the comment: Michael: See attached patch, that should merge up to Python 3 without too much pain as well. -- ___ Python tracker <http://bugs.python.org/issue12544> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12544] Avoid using a pseudo-dict for _type_equality_funcs in unittest
Changes by Martin : Removed file: http://bugs.python.org/file22636/avoid_TestCase_refcycle.diff ___ Python tracker <http://bugs.python.org/issue12544> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12544] Avoid using a pseudo-dict for _type_equality_funcs in unittest
Martin added the comment: ...typo in the first patch, this one should be okay. But... already landed without the testcase? -- Added file: http://bugs.python.org/file22637/avoid_TestCase_refcycle.diff ___ Python tracker <http://bugs.python.org/issue12544> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10003] signal.SIGBREAK regression on windows
New submission from Martin : The change in response to bug 9324 breaks bzr on windows as we use signal.SIGBREAK to listen for a ctrl+break keyboard press. Although SIGBREAK is not documented as valid on: <http://msdn.microsoft.com/library/xdkz3x12> It does in fact work and corresponds to CTRL_BREAK_EVENT in native windows terms. -- components: Extension Modules, Windows messages: 117769 nosy: brian.curtin, gz priority: normal severity: normal status: open title: signal.SIGBREAK regression on windows versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3 ___ Python tracker <http://bugs.python.org/issue10003> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10003] signal.SIGBREAK regression on windows
Martin added the comment: Also, the test seems to set signal handlers and never unset them, which I've also corrected. -- keywords: +patch Added file: http://bugs.python.org/file19076/sigbreak_windows_10003.patch ___ Python tracker <http://bugs.python.org/issue10003> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10003] signal.SIGBREAK regression on windows
Martin added the comment: Thanks for the quick resolution Brian, head now works as expected. -- ___ Python tracker <http://bugs.python.org/issue10003> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10501] make_buildinfo regression with unquoted path
New submission from Martin : My build got broken by the change for issue 9981 in revision 86137. The problem is it adds $(IntDir) to various places in the vcproj file, including the command line arguments to make_buildinfo, and my svn checkout is under a dir with a space in. Ideally it could just use a relative path, but just making sure it's quoted works too. -- components: Build files: issue9981_regression.patch keywords: patch messages: 122104 nosy: gz, krisvale priority: normal severity: normal status: open title: make_buildinfo regression with unquoted path versions: Python 3.2 Added file: http://bugs.python.org/file19769/issue9981_regression.patch ___ Python tracker <http://bugs.python.org/issue10501> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10501] make_buildinfo regression with unquoted path
Martin added the comment: Thanks. Don't actually need to quote the whole path, but what you've landed works for me. -- ___ Python tracker <http://bugs.python.org/issue10501> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10765] Build regression from automation changes on windows
New submission from Martin : The build changes in r87093 broke me, as my py3k branch is under a dir with a space in the name, and the OutDir path needs escaping in the makefiles. Various extra quoting seems to be sufficient, though inelegant. -- components: Build, Windows files: py3k_build.patch keywords: patch messages: 124575 nosy: gz, loewis priority: normal severity: normal status: open title: Build regression from automation changes on windows type: behavior versions: Python 3.2 Added file: http://bugs.python.org/file20151/py3k_build.patch ___ Python tracker <http://bugs.python.org/issue10765> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10765] Build regression from automation changes on windows
Martin added the comment: Oh, and after building with this, I get: $ svn st ? PC/python3dll.obj So either that wants moving or svn:ignore needs updating. -- ___ Python tracker <http://bugs.python.org/issue10765> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11034] Build problem on Windows with MSVC++ Express 2008
Martin added the comment: Removing the quotes rebreaks the case where tmppath contains a space. Instead, either: * Call subwcrev.exe directly without going through COMSPEC: switch 'system' to 'CreateProcess'. * More quotes! Change `"A" .. "B"` to `""A" .. "B""` which when it hits case 2 from what Amuary was quoting, does what's intended. """ 1. If all of the following conditions are met... """ ... they aren't... """ 2. Otherwise, old behavior is to see if the first character is a quote character and if so, strip the leading character and remove the last quote character on the command line, preserving any text after the last quote character. """ -- nosy: +gz ___ Python tracker <http://bugs.python.org/issue11034> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11034] Build problem on Windows with MSVC++ Express 2008
Martin added the comment: This bug only hits people who: 1) Have TortoiseSVN installed (buildbots won't, I don't) 2) ...on a path that needs quoting. -- ___ Python tracker <http://bugs.python.org/issue11034> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10765] Build regression from automation changes on windows
Martin added the comment: My build is still affected by this, can you find some time to look at the attached patch please? Relevant bit of log is: Performing Makefile project actions Microsoft (R) Program Maintenance Utility Version 9.00.21022.08 Copyright (C) Microsoft Corporation. All rights reserved. NMAKE : fatal error U1073: don't know how to make 'User\py3k\PCbuild\' Stop. Project : error PRJ0019: A tool returned an error code from "Performing Makefile project actions" -- ___ Python tracker <http://bugs.python.org/issue10765> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11034] Build problem on Windows with MSVC++ Express 2008
Martin added the comment: Eli, was just answering your question about why this didn't fail for other people. Try the attached patch to see if it fixes the problem for you. -- keywords: +patch Added file: http://bugs.python.org/file20571/issue11034.patch ___ Python tracker <http://bugs.python.org/issue11034> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11034] Build problem on Windows with MSVC++ Express 2008
Martin added the comment: ...and this apparently came up on the mailinglist as well with Prasun providing nearly exactly the same patch: <http://mail.python.org/pipermail/python-dev/2011-January/107599.html> -- ___ Python tracker <http://bugs.python.org/issue11034> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7815] Regression in unittest traceback formating extensibility
New submission from Martin :
Prior to being split up into a package, unittest had an extensible method of
trimming uninteresting, testing-framework related parts from tracebacks. As an
unintended side effect, this is no longer the case, only modules actually named
"unittest" are excluded. Code depending on the old method exists in a number of
different projects, and there is no benefit to breaking them.
More details and discussion of this issue on python-dev can be read at:
<http://mail.python.org/pipermail/python-dev/2009-December/094734.html>
Reverting this change is trivial, something along the lines of:
--- old/Lib/unittest/case.py
+++ new/Lib/unittest/case.py
@@ -9,7 +9,9 @@
from . import result, util
+__unittest = True
+
class SkipTest(Exception):
"""
Raise this exception in a test to skip it.
--- old/Lib/unittest/result.py
+++ new/Lib/unittest/result.py
@@ -94,11 +94,7 @@
return ''.join(traceback.format_exception(exctype, value, tb))
def _is_relevant_tb_level(self, tb):
-globs = tb.tb_frame.f_globals
-is_relevant = '__name__' in globs and \
-globs["__name__"].startswith("unittest")
-del globs
-return is_relevant
+return tb.tb_frame.f_globals.has_key('__unittest')
def _count_relevant_tb_levels(self, tb):
length = 0
--
components: Library (Lib)
messages: 98573
nosy: gz
severity: normal
status: open
title: Regression in unittest traceback formating extensibility
type: behavior
versions: Python 2.7, Python 3.2
___
Python tracker
<http://bugs.python.org/issue7815>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8347] string capitalize erroneously lower-case any non-first letters
New submission from Martin : When the following is run: s='the Los Angeles Symphony'; s.capitalize(); it displays 'The los angeles symphony' instead of 'The Los Angeles Symphony' the str.capitalize() should only deal with the first letter, not lower-case the rest of the letters. The manual correctly describes this, but the actual behavior is not consistent with this description. -- components: None messages: 102629 nosy: famart severity: normal status: open title: string capitalize erroneously lower-case any non-first letters type: behavior versions: Python 2.6 ___ Python tracker <http://bugs.python.org/issue8347> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8354] siginterrupt with flag=False is reset when signal received
Martin added the comment: This patch has been reviewed by both Andrew and myself, it would be nice if someone made the time to land it. The test change is unlikely to break anything, and hey, that's what buildbots are for. -- nosy: +gz ___ Python tracker <http://bugs.python.org/issue8354> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43656] StackSummary.format fails if str(value) fails
New submission from Martin : With `capture_locals=True`, `StackSummary.format` prints the local variables for every frame: https://github.com/python/cpython/blob/4827483f47906fecee6b5d9097df2a69a293a85c/Lib/traceback.py#L440 This will fail, however, if string conversion fails. StackSummary.format should be robust towards such possibilities. An easy fix would be a utility function: ``` def try_str(x): try: return str(x) except: return "" ``` -- messages: 389679 nosy: moi90 priority: normal severity: normal status: open title: StackSummary.format fails if str(value) fails type: enhancement versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue43656> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43656] StackSummary.format fails if str(value) fails
Martin added the comment: I have to correct myself: The conversion to string already happens during construction, in `FrameSummary.__init__`: https://github.com/python/cpython/blob/4827483f47906fecee6b5d9097df2a69a293a85c/Lib/traceback.py#L273 The issue remains as severe and the fix remains as easy. -- ___ Python tracker <https://bugs.python.org/issue43656> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43656] StackSummary.format fails if str(value) fails
Change by Martin : -- keywords: +patch pull_requests: +23812 stage: -> patch review pull_request: https://github.com/python/cpython/pull/25062 ___ Python tracker <https://bugs.python.org/issue43656> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43656] StackSummary.format fails if str(value) fails
Martin added the comment: Yes, it is repr in FrameSummary.__init__. -- ___ Python tracker <https://bugs.python.org/issue43656> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43656] StackSummary.format fails if str(value) fails
Martin added the comment: I didn't know repr is supposed to always succeed. Does the documentation mention this? -- ___ Python tracker <https://bugs.python.org/issue43656> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43656] StackSummary.format fails if str(value) fails
Martin added the comment: I can't find any mention of this in the documentation: https://docs.python.org/3/reference/datamodel.html#object.__repr__ https://docs.python.org/3/library/functions.html#repr I think this should be mentioned somewhere. -- ___ Python tracker <https://bugs.python.org/issue43656> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39228] traceback.FrameSummary does not handle exceptions from `repr()`
Martin added the comment: > As is true for most special methods, it is a bug for __repr__ methods to > raise. Is this codified anywhere? I only learned about that in this bug report. -- nosy: +moi90 ___ Python tracker <https://bugs.python.org/issue39228> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39228] traceback.FrameSummary does not handle exceptions from `repr()`
Martin added the comment: > Even correctly raised code can raise exceptions such as MemoryError, > RecursionError and KeybordInterrupt. For me, this is an argument in favor of the change (although KeybordInterrupt and probably a couple more should not be caught). traceback is used in contexts where an error already occured and it should do its best to help the user find the cause for it. It does not help much if itself then fails because some values are not repr'eable. What does pdb do in this case? -- ___ Python tracker <https://bugs.python.org/issue39228> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39228] traceback.FrameSummary does not handle exceptions from `repr()`
Martin added the comment: pdb uses vanilla repr as well: https://github.com/python/cpython/blob/f3ab670fea75ebe177e3412a5ebe39263cd428e3/Lib/pdb.py#L1180 -- ___ Python tracker <https://bugs.python.org/issue39228> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43656] StackSummary.format fails if repr(value) fails
Martin added the comment: Thanks for the explanations. I think this issue can be closed then. -- title: StackSummary.format fails if str(value) fails -> StackSummary.format fails if repr(value) fails ___ Python tracker <https://bugs.python.org/issue43656> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41539] print blocks with multiprocessing and buffered output
Martin added the comment: Yes, I think it should at least be documented. But then it practically says: "Do not use print in your library because it might be used in a threading context" This sounds unacceptable to me. It would be great to "just make it work". > I debugged it a bit and I think the race may be between your print statement > and the util._flush_std_streams() Why would print deadlock with a flush? -- ___ Python tracker <https://bugs.python.org/issue41539> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41539] print blocks with multiprocessing and buffered output
Martin added the comment: Thanks for the pointer, @pitrou! -- ___ Python tracker <https://bugs.python.org/issue41539> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43656] TracebackException or StackSummary.extract with capture_locals=True fail to catch exceptions raised by repr() on value of frame local variable in FrameSummary.__init__.
Martin added the comment: Thanks, Joe, this is a very good summary of all the problems. Another idea to fix this could be an additional parameter "repr=repr" to StackSummary.extract. This way, the default behavior is not changed, but the user is allowed to supply their own repr (safe_repr for example). -- ___ Python tracker <https://bugs.python.org/issue43656> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43656] TracebackException or StackSummary.extract with capture_locals=True fail to catch exceptions raised by repr() on value of frame local variable in FrameSummary.__init__.
Martin added the comment: > Can we determine if they came from an initialized object or from object in > the middle of initialization? That would be very nice because inside __init__ is the only place where we have to deal with partly initialized objects. But I think Python does not provide a way to detect this state. Although I would very much like having FrameSummary robust to any kind error, I acknowledge that this might not be possible. It might be frustrating for beginners, but I think the only way to "fix" this, is by having people implement their `repr`s correctly. The documentation currently says[1]: > This is typically used for debugging, so it is important that the > representation is information-rich and unambiguous. It should be added that __repr__ might be used to display partly initialized objects during debugging and therefore should deal with these gracefully. [1] https://docs.python.org/3/reference/datamodel.html#object.__repr__ -- ___ Python tracker <https://bugs.python.org/issue43656> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43656] TracebackException or StackSummary.extract with capture_locals=True fail to catch exceptions raised by repr() on value of frame local variable in FrameSummary.__init__.
Martin added the comment: Irit, I'm unsure about the wording. Something like ":meth:`__repr__` should always succeed, even if errors prevent a full description of the object."? "... even if the object is only partly initialized."? Andrei, I think you can not simply omit the first argument. For virtually all methods, `self` is an important value for debugging. It could be omitted for __init__, but that would break consistency. Also, __init__ could call other methods that help initialize the object and therefore also deal with partly initialized objects. I really think one important part of the solution to this problem is making people aware, that under some rare conditions, repr might receive a partly initialized object. I'm also still convinced that the other part of the solution is a way to customize the behavior of StackSummary.extract and friends. Context: I have written a tool (https://github.com/moi90/experitur) to run batches of (machine learning) experiments (so it is not interactive). In case of an error, the traceback is dumped into a file, together with the respective local variables (using `traceback.TracebackException.from_exception(...).format()`). I want this to succeed *in any case*, even if I was too ignorant to implement correct `__repr__`s in my experiment code (which is mostly on-time-use, so why should I care). In the end, this whole problem only affects users of `capture_locals=True`, so we could just change the semantics of this parameter a bit: False: do nothing, True: use repr (as before), : use this callable to convert the value to a string. This way, we could avoid adding an additional parameter to many of the methods in traceback AND give users an easy way to customize exception formatting for easy debugging. -- ___ Python tracker <https://bugs.python.org/issue43656> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43656] TracebackException or StackSummary.extract with capture_locals=True fail to catch exceptions raised by repr() on value of frame local variable in FrameSummary.__init__.
Martin added the comment: Once again a very good summary, thanks Joe! > it would be quite useful if this function parameter was given not just the > local variable values, but also the name of the local variable and maybe also > the stack frame it is in So this would be something like `format_locals(filename, lineno, name, locals) -> dict[str,str]` that could be used inside FrameSummary.__init__. I like that! I wouldn't bother with detecting un-repr-able objects in Python itself, but if the above `format_locals` was implemented, you could easily prepare such a formatter for your students that hides `self` et al. and/or catch exceptions during `repr` to your liking. What is needed to get an OK for such a change? -- ___ Python tracker <https://bugs.python.org/issue43656> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43656] TracebackException or StackSummary.extract with capture_locals=True fail to catch exceptions raised by repr() on value of frame local variable in FrameSummary.__init__.
Change by Martin : -- pull_requests: +27563 stage: resolved -> patch review pull_request: https://github.com/python/cpython/pull/29299 ___ Python tracker <https://bugs.python.org/issue43656> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23597] Allow easy display of local variables in log messages?
Martin added the comment:
In this pull request[1] I introduced a `format_locals` which can be provided to
customize the serialization of the local variables of each frame. This could be
used to filter out variables with certain names, for example. In this context,
you could use a certain naming convention for variables with sensitive
information and filter them out:
def _format_locals(filename, lineno, name, locals):
return {k: repr(v) for k,v in locals.items() if not
k.endsswith("_sensitive")}
traceback.TracebackException.from_exception(e, capture_locals=True,
format_locals=format_locals).format()
(This should be exactly what Robert was suggesting.)
[1] https://github.com/python/cpython/pull/29299
--
keywords: +patch
message_count: 3.0 -> 4.0
nosy: +moi90
nosy_count: 4.0 -> 5.0
pull_requests: +27572
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/29299
___
Python tracker
<https://bugs.python.org/issue23597>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43656] TracebackException or StackSummary.extract with capture_locals=True fail to catch exceptions raised by repr() on value of frame local variable in FrameSummary.__init__.
Martin added the comment: Could the participants of this issue please have a look at my pull request: https://github.com/python/cpython/pull/29299 What do you like, what don't you like? Does it work for your use case? -- ___ Python tracker <https://bugs.python.org/issue43656> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41544] multiprocessing.dummy.Process lacks daemon parameter
Change by Martin : -- nosy: +davin, pitrou type: -> behavior ___ Python tracker <https://bugs.python.org/issue41544> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41544] multiprocessing.dummy.Process lacks daemon parameter
Martin added the comment: Could someone have a look at my pull request? I have trouble with the tests. -- ___ Python tracker <https://bugs.python.org/issue41544> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39228] traceback.FrameSummary does not handle exceptions from `repr()`
Martin added the comment: I submitted a pull request for the related issue43656: https://github.com/python/cpython/pull/29299 It introduces a format_locals parameter that enables the customized formatting of a FrameSummary. This way, a user of traceback could provide a function that handles exceptions within __repr__ if necessary. -- ___ Python tracker <https://bugs.python.org/issue39228> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43656] TracebackException or StackSummary.extract with capture_locals=True fail to catch exceptions raised by repr() on value of frame local variable in FrameSummary.__init__.
Martin added the comment: I see two scenarious discussed here: Scenario 1 (Offline / Batch-Mode): A system runs user-supplied jobs that may fail. In the case of an error, the system shouldn't crash but rather store a maximally helpful message and carry on with the next job. Most likely, the relevant information is the situation that lead to the error in the first place, not that repr() has also gone wrong as a result. This could be a a system to automatically test the homework code of your students. Or, like in my case, a framework that runs experiments. You would very likely want a system that does not crash if a __repr__ is wrongly implemented but prints a readable traceback and carries on with the next job. Here, format_locals could be used to fall back to a different representation of an object if repr() fails. This is the use case that my pull request tries to address primarily. Scenario 2 (Online / Write, Test, Repeat): A user frequently rewrites and executes their code until the desired outcome appears. Errors inevitably happen. In this case, a maximally helpful stack trace is needed. Again, the relevant information is the situation that lead to the error in the first place, not that repr() has also gone wrong as a result. Yes, it would be hard for unexperienced users to come up with StackSummary.extract(format_locals=...) by themselves. But, the correct way would be to use a debugger anyway, not some hand-written code to print exceptions on the fly. However, if your students receive a template file where they fill in missing function bodies etc, there might already be a substantial amount of code which they don't understand at first, nor do they need to care. Therefore, a piece of code that formats exceptions nicely would hurt here. I think the most useful change for Scenario 2 (if, for some reason, a proper debugger is not an option) could be to add a command line option (e.g. -X capture_locals) so that a complete stack trace is printed if an exception bubbles up to interpreter level. (Here, it wouldn't hurt to handle exceptions in repr() because the interpreter already stopped exection anyway.) This option would be very easy to teach to inexperienced users. My pull request would provide preparation for this more extensive change. -- ___ Python tracker <https://bugs.python.org/issue43656> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43656] TracebackException or StackSummary.extract with capture_locals=True fail to catch exceptions raised by repr() on value of frame local variable in FrameSummary.__init__.
Martin added the comment: Just to avoid misunderstandings: My pull request is not at all about silencing exceptions. It is about customizing the output of the traceback module. (Just like the introduction of capture_locals previously: #22936) (-X capture_locals, on the other hand, is a hypothetical idea that might help with debugging, but we don't have to discuss this now.) My main argument for the proposed change is that traceback is useless in certain situations, because capture_locals is not "robust" (it *might* raise exceptions; I could handle these in the calling code but that would again hide the stack trace that I was about to investigate) and might dump sensitive data like passwords into logfiles (msg237320, msg237323). Nothing is taken away or hidden, but flexibility is added. (The only other option to resolve these issues would be to re-implement much of the current functionality of traceback in a third-party module, which would lead to maintainability problems and fragmentation.) -- nosy: +rbcollins ___ Python tracker <https://bugs.python.org/issue43656> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43656] TracebackException or StackSummary.extract with capture_locals=True fail to catch exceptions raised by repr() on value of frame local variable in FrameSummary.__init__.
Martin added the comment: I improved the example in traceback.rst to illustrate how format_locals works. -- ___ Python tracker <https://bugs.python.org/issue43656> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43656] TracebackException or StackSummary.extract with capture_locals=True fail to catch exceptions raised by repr() on value of frame local variable in FrameSummary.__init__.
Martin added the comment: Thanks Joe! > 1. The changes are sufficient to let the user make things work the way it is > requested that they work and anyone who does not start using the new > format_locals parameter will get the old behavior. That was my goal :) > 2. A side comment: I just noticed that the docstring for > FrameSummary.__init__ does not document the filename, lineno, and name > parameters. Perhaps this could be fixed at the same time? I agree and already updated the pull request. > 3. The new parameter format_locals is slightly confusingly named, because it > does not format a single string from all the locals but instead gives a > dictionary of strings with one string for each local. I think format_locals is OK here (local*s*: plural), but I'm open to better suggestions. > 4. I personally think it would be better to include something like the > example value for format_locals as an extra attribute of the traceback module > so everybody doesn't have to write the same function. That said, the > documented example is sufficient. I sort of agree, but I also don't know what such a general-purpose function would entail. Suggestions? > 5. It is not clear to me why this stringify-ing of the locals can't be done > in StackSummary._extract_from_extended_frame_gen. It passes the dictionary > of locals and also the function to transform it to FrameSummary. It would > make more sense to transform it first. I suppose there might be some user > somewhere who is directly calling FrameSummary so the interface needs to stay. I agree! In principle, FrameSummary has been little more than a container without (much) logic of its own. Memory efficiency requires that that FrameSummary does not hold references to the original locals, thats why repr() was used. I think as well that it would have been better to keep FrameSummary as a mere container and do the conversion of the locals elsewhere. But at this point, this shouldn't be changed anymore. > 6. I fantasize that the new format_locals parameter would have access to the > frame object. In order for this to happen, the frame object would have to be > passed to FrameSummary instead of the 3 values (locals, name, filename) that > are extracted from it. I think the current interface of FrameSummary was > designed to interoperate with very old versions of Python. Oh well. Do you have a use case for that? I have no clue what you would do with the frame object at this point. > 7. If anyone wanted to ever refactor FrameSummary (e.g., to enable my fantasy > in point #6 just above), it becomes harder after this. This change has the > effect of exposing details of the interface of FrameSummary to users of > StackSummary.extract and TracebackException. The four parameters that the > new parameter format_locals takes are most of the parameters of FrameSummary. Previously, I totally misread your request to "not just the local variable values, but also the name of the local variable and maybe also the stack frame it is in". This is why I included filename, lineno and name as parameters to format_locals which now seems totally useless to me and I'll remove them (if nobody objects). -- ___ Python tracker <https://bugs.python.org/issue43656> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43656] TracebackException or StackSummary.extract with capture_locals=True fail to catch exceptions raised by repr() on value of frame local variable in FrameSummary.__init__.
Martin added the comment: Irit, would you be able to take a look at the patch? --- I found another application scenario for the patch: In Numpy and Pandas, the assert_* functions in testing have a __tracebackhide__ local that advises pytest to hide the frame. With the patch in place, we could at least not display any locals if __tracebackhide__ is present. -- ___ Python tracker <https://bugs.python.org/issue43656> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43656] TracebackException or StackSummary.extract with capture_locals=True fail to catch exceptions raised by repr() on value of frame local variable in FrameSummary.__init__.
Martin added the comment: Thanks for your definitive answer, this is what I was waiting for. I understand and I totally agree that subclassing is the way to go to make traceback more flexible. Would you mind linking the other issues concerning the general improvement of traceback? -- ___ Python tracker <https://bugs.python.org/issue43656> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41539] print blocks with multiprocessing and buffered output
New submission from Martin : I experience a problem with multiprocessing and print. I tried to make a minimal working example, please see the attached file. WITHOUT the offending print statement in the queue filler thread, everything works: - pytest experiments/mp_problem.py - pytest experiments/mp_problem.py -s - python experiments/mp_problem.py WITH the offending print statement, not so much: - pytest experiments/mp_problem.py WORKS (Probably because pytest captures fd 1) - pytest experiments/mp_problem.py -s FAILS eventually (after a couple of workers have been started) - python experiments/mp_problem.py FAILS eventually (same). WITH the offending print statement AND PYTHONUNBUFFERED=1, everything works again: - pytest experiments/mp_problem.py - pytest experiments/mp_problem.py -s - python experiments/mp_problem.py Environment: Ubuntu 18.04.5 LTS python 3.8.5 (hcff3b4d_1) on conda 4.8.3 -- files: mp_problem.py messages: 375298 nosy: moi90 priority: normal severity: normal status: open title: print blocks with multiprocessing and buffered output type: behavior versions: Python 3.8 Added file: https://bugs.python.org/file49385/mp_problem.py ___ Python tracker <https://bugs.python.org/issue41539> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41539] print blocks with multiprocessing and buffered output
Martin added the comment: python experiments/mp_problem.py also fails for: - 3.8.3, 3.8.2, 3.8.1, 3.8.0 - 3.7.7 - 3.6.10 -- ___ Python tracker <https://bugs.python.org/issue41539> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41544] multiprocessing.dummy.Process lacks daemon parameter
New submission from Martin : Although multiprocessing.Process has a `daemon` parameter, multiprocessing.dummy.Process doesn't. As multiprocessing.dummy is meant to replicate the API of multiprocessing and the daemon parameter is readily available in threading.Thread, it should also be available in multiprocessing.dummy.Process. -- messages: 375347 nosy: moi90 priority: normal severity: normal status: open title: multiprocessing.dummy.Process lacks daemon parameter ___ Python tracker <https://bugs.python.org/issue41544> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41544] multiprocessing.dummy.Process lacks daemon parameter
Change by Martin : -- keywords: +patch pull_requests: +20993 stage: -> patch review pull_request: https://github.com/python/cpython/pull/21869 ___ Python tracker <https://bugs.python.org/issue41544> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41539] print blocks with multiprocessing and buffered output
Martin added the comment: While I appreciate your suggestion, it does not help me much. The problem that people usually have is that the output is scrambled. That is not the problem I'm dealing with. I'm experiencing a deadlock caused by the print statement which seems like a python bug to me. Furthermore, the problem appears in a library that is supposed to be used by other people and I have no control over their use of IO. The particular behavior seems to be specific to using threading and multiprocessing together: - If I use multiprocessing.dummy (multiprocessing API implemented with threads; so only a single processes are involved), my example works fine. - If I use a process instead of a thread to fill the queue (filler = multiprocessing.Process(...); so no threads are involved), my example also works fine. - Only if I have two threads in the main process and additional processes, the example fails. -- ___ Python tracker <https://bugs.python.org/issue41539> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13703] Hash collision security issue
Martin added the comment: > Has anyone had a chance to try this patch on Windows? Martin? I'm > hoping that it doesn't impose a startup cost in the default > no-randomization cost, and that any startup cost in the -R case is > acceptable. Just tested as requested. Is the patch against 3.1 for a reason? Can't really be compared to earlier results, but get enough weird outliers that that may not be useful anyway. Also needed the following change: -+chunk = Py_MIN(size, INT_MAX); ++chunk = size > INT_MAX ? INT_MAX : size; Summary, looks like extra work in the default case is avoided and isn't crippling otherwise, though there were a couple of very odd runs not presented probably due to other disk access. Vanilla: >timeit PCbuild\python.exe -c "import sys;print(sys.version)" 3.1.4+ (default, Jan 30 2012, 22:38:52) [MSC v.1500 32 bit (Intel)] Version Number: Windows NT 5.1 (Build 2600) Exit Time:10:42 pm, Monday, January 30 2012 Elapsed Time: 0:00:00.218 Process Time: 0:00:00.187 System Calls: 3974 Context Switches: 574 Page Faults: 1696 Bytes Read: 480331 Bytes Written:0 Bytes Other: 190860 Patched: >timeit PCbuild\python.exe -c "import sys;print(sys.version)" 3.1.4+ (default, Jan 30 2012, 22:55:06) [MSC v.1500 32 bit (Intel)] Version Number: Windows NT 5.1 (Build 2600) Exit Time:10:55 pm, Monday, January 30 2012 Elapsed Time: 0:00:00.218 Process Time: 0:00:00.187 System Calls: 3560 Context Switches: 441 Page Faults: 1660 Bytes Read: 461956 Bytes Written:0 Bytes Other: 24926 >timeit PCbuild\python.exe -Rc "import sys;print(sys.version)" 3.1.4+ (default, Jan 30 2012, 22:55:06) [MSC v.1500 32 bit (Intel)] Version Number: Windows NT 5.1 (Build 2600) Exit Time:11:05 pm, Monday, January 30 2012 Elapsed Time: 0:00:00.249 Process Time: 0:00:00.234 System Calls: 3959 Context Switches: 483 Page Faults: 1847 Bytes Read: 892464 Bytes Written:0 Bytes Other: 27090 -- ___ Python tracker <http://bugs.python.org/issue13703> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29167] Race condition in enum.py:_decompose()
Martin added the comment: Our production system hit this issue using Python 3.6.7 once a few days ago, so presumably the race is still possible with the applied patch, just less likely? ``` RuntimeError: dictionary changed size during iteration at _decompose (/usr/lib/python3.6/enum.py:858) at _create_pseudo_member_ (/usr/lib/python3.6/enum.py:773) at _missing_ (/usr/lib/python3.6/enum.py:764) at __new__ (/usr/lib/python3.6/enum.py:535) at __call__ (/usr/lib/python3.6/enum.py:293) at __or__ (/usr/lib/python3.6/enum.py:800) at create_urllib3_context (/usr/local/lib/python3.6/dist-packages/urllib3/util/ssl_.py:279) at connect (/usr/local/lib/python3.6/dist-packages/urllib3/connection.py:332) at _validate_conn (/usr/local/lib/python3.6/dist-packages/urllib3/connectionpool.py:839) at _make_request (/usr/local/lib/python3.6/dist-packages/urllib3/connectionpool.py:343) at urlopen (/usr/local/lib/python3.6/dist-packages/urllib3/connectionpool.py:600) at send (/usr/local/lib/python3.6/dist-packages/requests/adapters.py:449) at send (/usr/local/lib/python3.6/dist-packages/requests/sessions.py:646) at request (/usr/local/lib/python3.6/dist-packages/requests/sessions.py:533) at __call__ (/usr/local/lib/python3.6/dist-packages/google/auth/transport/requests.py:120) at _token_endpoint_request (/usr/local/lib/python3.6/dist-packages/google/oauth2/_client.py:106) at jwt_grant (/usr/local/lib/python3.6/dist-packages/google/oauth2/_client.py:145) at refresh (/usr/local/lib/python3.6/dist-packages/google/oauth2/service_account.py:322) at before_request (/usr/local/lib/python3.6/dist-packages/google/auth/credentials.py:122) at request (/usr/local/lib/python3.6/dist-packages/google/auth/transport/requests.py:198) at wait_and_retry (/usr/local/lib/python3.6/dist-packages/google/resumable_media/_helpers.py:146) at http_request (/usr/local/lib/python3.6/dist-packages/google/resumable_media/requests/_helpers.py:101) at consume (/usr/local/lib/python3.6/dist-packages/google/resumable_media/requests/download.py:169) at _do_download (/usr/local/lib/python3.6/dist-packages/google/cloud/storage/blob.py:498) at download_to_file (/usr/local/lib/python3.6/dist-packages/google/cloud/storage/blob.py:560) ``` -- nosy: +gz ___ Python tracker <https://bugs.python.org/issue29167> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33112] SequenceMatcher bug
New submission from Martin :
difflib.SequenceMatcher fails to make a proper alignment between 2 sequences
with only 3 single letter changes. Its performance is completely off with a
similarity ratio of 0.16, in stead of the more accurate 0.99.
Here is a snippet to replicate the failure:
>>> aa_ref =
>>> 'MTLFTTLLVLIFERLFKLGEHWQLDHRLEAFFRRVKHFSLGRTLGMTIIAMGVTFLLLRALQGVLFNVPTLLVWLLIGLLCIGAGKVRLHYHAYLTAASRNDSHARATMAGELTMIHGVPAGCDEREYLRELQNALLWINFRFYLAPLFWLIVGGTWGPVTLMGYAFLRAWQYWLARYQTPHHRLQSGIDAVLHVLDWVPVRLAGVVYALIGHGEKALPAWFASLGDFHTSQYQVLTRLAQFSLAREPHVDKVETPKAAVSMAKKTSFVIALLTIYGALV'
>>> aa_seq =
>>> 'MTLFTTLLVLIFERLFKLGEHWQLDHRLEAFFRRVKHFSLGRTLCMTIIAMGVTFLLLRALQGVLFNVPTLLVWLLIGLLCIGAGKVRLHYHAYLTAASRNDSHAHATMAGELTMIHGVPAGCDEREYLRELQNALLWINFRFYLAPLFWLIVGGTWGPVTLMGYAFLRAWQYWLARYQTPHHRLQSGIDAVLHALDWVPVRLAGVVYALIGHGEKALPAWFASLGDFHTSQYQVLTRLAQFSLAREPHVDKVETPKAAVSMAKKTSFVIALLTIYGALV'
>>> sum(a!=b for a, b in zip(aa_ref, aa_seq))
3
>>> match = SequenceMatcher(a=aa_ref, b=aa_seq)
>>> match.ratio()
0.1619718309859155
>>> match.get_opcodes()
[('equal', 0, 43, 0, 43), ('delete', 43, 79, 43, 43), ('equal', 79, 81, 43,
45), ('replace', 81, 122, 45, 80), ('equal', 122, 123, 80, 81), ('replace',
123, 284, 81, 284)]
--
messages: 314163
nosy: mcft
priority: normal
severity: normal
status: open
title: SequenceMatcher bug
type: behavior
versions: Python 3.5
___
Python tracker
<https://bugs.python.org/issue33112>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32135] Dict creation with update will result to NoneType
New submission from Martin :
>>> x = {"x":123}.update({"abc":123})
>>> type(x)
--
messages: 306977
nosy: thedemz
priority: normal
severity: normal
status: open
title: Dict creation with update will result to NoneType
type: behavior
versions: Python 3.6
___
Python tracker
<https://bugs.python.org/issue32135>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32315] can't run any scripts with 2.7.x, 32 and 64-bit
New submission from Martin : When I try to run a really simple script like: def fun(a): print a return I get this error: Exception in Tkinter callback Traceback (most recent call last): File "C:\Python27\lib\lib-tk\Tkinter.py", line 1541, in __call__ return self.func(*args) File "C:\Python27\lib\idlelib\MultiCall.py", line 166, in handler r = l[i](event) File "C:\Python27\lib\idlelib\ScriptBinding.py", line 149, in run_module_event if PyShell.use_subprocess: AttributeError: 'module' object has no attribute 'use_subprocess' It basically means Python is only usable by copy-pasting code into Shell, any kind of script fails with that error. -- components: Library (Lib) messages: 308260 nosy: DoctorEvil priority: normal severity: normal status: open title: can't run any scripts with 2.7.x, 32 and 64-bit versions: Python 2.7 ___ Python tracker <https://bugs.python.org/issue32315> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32315] can't run any scripts with 2.7.x, 32 and 64-bit
Martin added the comment: I used Python on other machines, I know how it's supposed to work. I'm using Windows 7 and this problem happened with 2.7.14, 2.7.13 and 2.7.9. I didn't bother trying all other versions because it looked like it didn't matter what version it was. For every version, I was running scripts with PyShell file (59 KB) from idlelib. I found another two files called "idle" in idlelib, one with and other without console. Either of those when ran starts Shell window and I can run scripts perfectly fine from there. I don't know what the problem is with PyShell file, but since with idle files it works as expected, I won't chase the cause of this. -- ___ Python tracker <https://bugs.python.org/issue32315> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10765] Build regression from automation changes on windows
Martin added the comment: Yes, this is still reproducible. For instance, by: > hg clone -b default 3.3 "feature branch" > cd "feature branch/PCbuild" > call build_env.bat > call build.bat It seems python33.dll now does get created so it's less severe, but the python3dll still fails due to the makefile OutDir not being quoted: NMAKE : fatal error U1073: don't know how to make 'branch\PCbuild\' -- versions: +Python 3.3 ___ Python tracker <http://bugs.python.org/issue10765> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16828] bz2 error on compression of empty string
New submission from Martin: The fix from issue 14398 for >4GB inputs regressed the behaviour when compressing an empty string. Going by issue 853061 the expectation is this should work. The problem was noticed when using the updated Python 2.7 package in Ubuntu Raring caused test failures in the Bazaar suite: <https://bugs.launchpad.net/bzr/+bug/1090043> -- components: Extension Modules messages: 178705 nosy: gz, nadeem.vawda priority: normal severity: normal status: open title: bz2 error on compression of empty string type: behavior versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5 ___ Python tracker <http://bugs.python.org/issue16828> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16828] bz2 error on compression of empty string
Martin added the comment: On trunk, both the compressor and the standalone function (which uses the compressor) are affected. The easiest fix is rearranging the logic in function shared between BZ2Compressor.compress and BZ2Compressor.flush so the exit on no remaining input for the former case happens before the library call. -- keywords: +patch Added file: http://bugs.python.org/file28512/bz2_compress_empty_string_trunk.patch ___ Python tracker <http://bugs.python.org/issue16828> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16828] bz2 error on compression of empty string
Martin added the comment: On 2.7 only the compress() function is affected, and the fix is much simpler. Just using BZ_FINISH when the input is less then 4GB is sufficient. -- Added file: http://bugs.python.org/file28513/bz2_compress_empty_string_27.patch ___ Python tracker <http://bugs.python.org/issue16828> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19149] python bug report
New submission from Martin: Hello! My name is Martin, a member of Free Software in Comahue National University of Neuquén, Argentina. We have detected an error in the compiler for Python 2.7 using Ubuntu 12.04: I write the code, without realizing I leave a comment with syntax error in that line (do not put the # of comments), compile and get error of sistaxis in that line. Fix the error adding # to comment, I do compile again and it shows me various errors that take over the Python compiler and I am forced to close it. Hope your response with a possible solution to this problem, my idea is to continue using this version of Python. Thank yo -- messages: 198878 nosy: Grupobetatesting priority: normal severity: normal status: open title: python bug report ___ Python tracker <http://bugs.python.org/issue19149> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19150] python bug report
New submission from Martin: Hello! My name is Martin, a member of Free Software in Comahue National University of Neuquén, Argentina. We have detected an error in the compiler for Python 2.7 using Ubuntu 12.04: I write the code, without realizing I leave a comment with syntax error in that line (do not put the # of comments), compile and get error of sistaxis in that line. Fix the error adding # to comment, I do compile again and it shows me various errors that take over the Python compiler and I am forced to close it. Hope your response with a possible solution to this problem, my idea is to continue using this version of Python. Thank yo -- components: IDLE files: Captura de pantalla de 2013-10-02 23:52:10.png messages: 198879 nosy: Grupobetatesting priority: normal severity: normal status: open title: python bug report type: compile error versions: Python 2.7 Added file: http://bugs.python.org/file31948/Captura de pantalla de 2013-10-02 23:52:10.png ___ Python tracker <http://bugs.python.org/issue19150> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19150] IDLE shell fails: "ModifiedInterpreter instance has no attribute 'interp'"
Martin added the comment: I have three shell windows open because everytime i run the code corrected, it opens a new shell, I try to close them but there is one that keeps open, unless I kill it by terminal (kill) I attach a photo of compiling the line of code, closing leftover shell ... What I do is compile with three lines that should be comments, it makes syntax error for not to have commented lines, I comment them (#) and when I want to recompile, errors appears in the main shell. -- resolution: -> invalid Added file: http://bugs.python.org/file31950/Captura de pantalla de 2013-10-03 02:27:12.png ___ Python tracker <http://bugs.python.org/issue19150> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19150] IDLE shell fails: "ModifiedInterpreter instance has no attribute 'interp'"
Martin added the comment:
Thank you very much for your help.
Specification of error :
In python 2.7.3 for Ubuntu 12.04 32-bit
It creates a program with the following line of code :
Python is a programming language That lets you work more quickly and integrate
your systems more effectively.
You can learn to use Python and see almost immediate gains in productivity and
lower maintenance costs.
import math
elCociente def (x, y):
ratio = x / y
return ratio
theRemainder def (x, y):
remainder = x% y
return other
laRaiz def ( x ) :
root = math.sqrt ( x )
return root
LaSegRaiz def (y):
segraiz = math.sqrt ( y)
return segraiz
def main ( ) :
x = input (" Enter a number: " )
y = input (" Enter a second number :")
print " the quotient of dividing " , x , "with" , and , " is" , elCociente
( x , y)
print " the remainder of dividing " , x , " for " and , " is" ,
theRemainder ( x , y)
print " the root of " , x , " is" , laRaiz ( x )
print " the root ," and , " is" , LaSegRaiz ( y)
Where the lines 1 and 2 are not discussed , when compiling the program ( f5 )
warns us to a syntax error , open the sheel , we force the compilation typing
the main and opens another blank shell . not saying that is the error line .
If commented lines 1 and 2 and compile again ( f5 ) jump several errors in the
shell which can not close and forces us to have to kill python process .
I hope I have been much clearer .
thanks
Corrected with cometary Program
# Python is a programming language That lets you work more quickly and
integrate your systems more effectively.
# You can learn to use Python and see almost immediate gains in productivity
and lower maintenance costs.
import math
elCociente def (x, y):
ratio = x / y
return ratio
theRemainder def (x, y):
remainder = x% y
return other
laRaiz def ( x ) :
root = math.sqrt ( x )
return root
LaSegRaiz def (y):
segraiz = math.sqrt ( y)
return segraiz
def main ( ) :
x = input (" Enter a number: " )
y = input (" Enter a second number :")
print " the quotient of dividing " , x , "with" , and , " is" , elCociente
( x , y)
print " the remainder of dividing " , x , " for " and , " is" ,
theRemainder ( x , y)
print " the root of " , x , " is" , laRaiz ( x )
print " the root ," and , " is" , LaSegRaiz ( y)
--
___
Python tracker
<http://bugs.python.org/issue19150>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5505] sys.stdin.read() doesn't return after first EOF on Windows
Martin added the comment: Looks like python needs eof() or something for file objects, just like any other languages. Since read() is using the system call, that's the right behavior: read() blocks until EOF, and returns whatever was buffered. EOF character is consumed, but since it's a stdin, it is never closed. The next read() will again wait for normal input. The 2nd EOF mark without anything in-between will return an empty string. -- nosy: +famart ___ Python tracker <http://bugs.python.org/issue5505> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9501] Logging shutdown regressions with weakrefs
New submission from Martin : With the logging change to using weakrefs for handler cleanup done by the follow-on patch in issue 6615 exceptions may now be thrown during module teardown. There are two distinct problem cases: 1) The new `_removeHandlerRef` function may run during teardown (when module globals are being set to None) but uses the module globals `_acquireLock`, `_releaseLock`, and `_handlerList`. 2) The `Handler.close` method no longer removes the instance from the module global list, this means if the caller then closes the underlying file but keeps a reference to the handler, the `shutdown` function will attempt to flush the already-closed file. It may be that this new way of doing things is preferred and the response to closing underlying files or holding on to handler references is Don't Do That Then, but this seems like an accidental regression. -- components: Library (Lib) messages: 112713 nosy: flox, gz, vinay.sajip priority: normal severity: normal status: open title: Logging shutdown regressions with weakrefs type: behavior versions: Python 2.7, Python 3.2, Python 3.3 ___ Python tracker <http://bugs.python.org/issue9501> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9501] Logging shutdown regressions with weakrefs
Martin added the comment: This could be fixed in a similar way to was done for the shutdown function in r51206 (which incidentally seems both unnecessary and incomplete - the function runs atexit which precedes module teardown, but also uses the raiseExceptions module global which is not rebound locally). -- Added file: http://bugs.python.org/file18360/loggingcleanup.py ___ Python tracker <http://bugs.python.org/issue9501> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9501] Logging shutdown regressions with weakrefs
Martin added the comment: For the second case, just reverting the change to Handler.close may be best, I don't see why the module should be keeping responsibility for flushing and closing handlers it no longer has a strong reference to. -- Added file: http://bugs.python.org/file18361/loggingclose.py ___ Python tracker <http://bugs.python.org/issue9501> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9543] 2.6.6 rc1 socket.py flush() calls del on unbound 'view' variable
Martin added the comment: spiv wrote a script to repo the issue in the downstream ubuntu bug: https://bugs.launchpad.net/python/+bug/615240 -- nosy: +gz ___ Python tracker <http://bugs.python.org/issue9543> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17541] Importing `webbrowser` module gives NameError in Python 2.7.4rc1
Martin added the comment: This looks like a downstream issue in a patch Debian is applying: <http://bugs.debian.org/cgi-bin/bugreport.cgi?archive=no&bug=703872> <http://patch-tracker.debian.org/patch/series/view/python2.7/2.7.4~rc1-2/webbrowser.diff> -- nosy: +gz ___ Python tracker <http://bugs.python.org/issue17541> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1449496] Python should use 3GB Address Space on Windows
Martin Gfeller Martin Gfeller added the comment: Martin, we're running with this for years and with many extensions modules, without an issue. What is 64-bit safe should be 32-bit safe, not only 31-bit safe. But you're right, this is not a proof, and we have switched to 64-bit ourselves. -- ___ Python tracker <http://bugs.python.org/issue1449496> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1497532] C API to retain GIL during Python Callback
Martin Gfeller Martin Gfeller added the comment: Lukas, I'm afraid to admit you're right :-;. Assuming that the Python code called under the "not release the GIL" regime would not do anything that could be potentially blocking is probably dangerous and could result in an unstable interpreter. So I withdraw my feature request and thank you for your efforts and interest. Best regards, Martin -- status: open -> closed ___ Python tracker <http://bugs.python.org/issue1497532> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40059] Provide a toml module in the standard library
Martin Reboredo added the comment: A new python-ideas mail thread was created for this, you can check it out at https://mail.python.org/archives/list/python-id...@python.org/thread/IWJ3I32A4TY6CIVQ6ONPEBPWP4TOV2V7/. -- nosy: +YakoYakoYokuYoku ___ Python tracker <https://bugs.python.org/issue40059> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46062] In IDLE, 'File > Save As' seems not to allow creation of a new folder
New submission from Martin Whitehead : The problem: In both the IDLE shell and the editor, 'File > Save As' seems not to allow creation of a new folder. My system: IDLE v3.8.10 (64 bit) Python 3.8.10 Tk version 8.6.10 Linus Mint 20.2 Uma (64 bit), which is based on Ubuntu 20.04 LTS (Focal Fossa) -- assignee: terry.reedy components: IDLE messages: 408437 nosy: suffolkpunch, terry.reedy priority: normal severity: normal status: open title: In IDLE, 'File > Save As' seems not to allow creation of a new folder versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue46062> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40059] Provide a toml module in the standard library
Martin Reboredo added the comment: > Not officially, no. But I'm personally not going to bring it forward right > now. If someone else wants to formulate a complete proposal for the SC on > this then they are definitely welcome to! You will need to address where the > code is coming from, why that code should be used, what's the API, etc. > > The only reason the SC is mentioned here is there will be a discussion about > how to maintain the stdlib, but it simply hasn't happened yet. You don't have > to wait for it and asking for a TOML module might actually force the issue. I've been working on a document detailing the API implementation (as a PEP draft) see https://gitlab.com/YakoYakoYokuYoku/pep-toml. Although I've yet to write the code I'll to move forward with it. -- ___ Python tracker <https://bugs.python.org/issue40059> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46319] datetime.utcnow() should return a timezone aware datetime
Martin Panter added the comment: Perhaps this is a duplicate of Issue 12756? -- nosy: +martin.panter superseder: -> datetime.datetime.utcnow should return a UTC timestamp ___ Python tracker <https://bugs.python.org/issue46319> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46352] Steps To Do Arlo Setup
Change by Jacob Martin : -- components: Installation files: Arlo camera setup.jpg nosy: jacobmartin717 priority: normal severity: normal status: open title: Steps To Do Arlo Setup type: security versions: Python 3.8 Added file: https://bugs.python.org/file50558/Arlo camera setup.jpg ___ Python tracker <https://bugs.python.org/issue46352> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46375] io.BytesIO does not have peek()
New submission from Marcel Martin : It would be great to be able to use peek() on BytesIO objects. I have a function that gets passed a file-like object and uses peek() on it. This works for nearly all types of files relevant in my library, except BytesIO instances (which I use during testing), for which I need to add a small workaround using tell() and seek(). -- components: Library (Lib) messages: 410552 nosy: marcelm priority: normal severity: normal status: open title: io.BytesIO does not have peek() type: enhancement versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue46375> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46375] io.BytesIO does not have peek()
Change by Marcel Martin : -- keywords: +patch pull_requests: +28996 stage: -> patch review pull_request: https://github.com/python/cpython/pull/30808 ___ Python tracker <https://bugs.python.org/issue46375> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46375] io.BytesIO does not have peek()
Marcel Martin added the comment: I opened a PR, but I now wonder whether the missing peek() is by design. First, I noticed that instead of using BytesIO directly, I can wrap the instance in an io.BufferedReader, which does have peek(). (It’s just a bit inconvenient.) The second thing is that BytesIO is currently documented to inherit from BufferedIOBase, but if peek() is implemented, one could argue that BytesIO now should inherit from BufferedReader because it then has all the methods. And that seems to great a change from my perspective. I’ll defer to someone more knowledgeable and do not mind at all if this issue is closed without action. -- ___ Python tracker <https://bugs.python.org/issue46375> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46517] Review exception handling in urllib
Martin Panter added the comment:
The linked code is for urllib.parse.urlencode, looking something like
try:
if len(query) and not isinstance(query[0], tuple):
raise TypeError
except TypeError:
ty, va, tb = sys.exc_info()
raise TypeError("not a valid non-string sequence "
"or mapping object").with_traceback(tb)
I guess it raises twice so that the error message is not duplicated in the
code. The author probably also wants the TypeError initially raised from the
"len(query)" and "query[0]" operations to get the same "not a valid . . ."
message.
Regarding the OSError, originally it was catching socket.error and raising
IOError. I guess someone only wanted the caller to have catch IOError and not
need to import the socket module. Later these exception types became aliases of
each other.
Anyway, the URLopener class is documented as deprecated, so is it really worth
changing anything in that?
--
nosy: +martin.panter
___
Python tracker
<https://bugs.python.org/issue46517>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46537] zipfile crash on windows, detected during pip install pyodbc-4.0.32-cp310-cp310-win_amd64.whl
New submission from Martin Forster : pyth10n 3.10.1, windows x64 install of yodbc-4.0.32-cp310-cp310-win_amd64.whl crashes. pos: 74196 pos: 74226 pos: -3 ERROR: Could not install packages due to an OSError. Traceback (most recent call last): File "C:\git\idfunctiondb\venv\lib\site-packages\pip\_internal\commands\install.py", line 390, in run installed = install_given_reqs( File "C:\git\idfunctiondb\venv\lib\site-packages\pip\_internal\req\__init__.py", line 73, in install_given_reqs requirement.install( File "C:\git\idfunctiondb\venv\lib\site-packages\pip\_internal\req\req_install.py", line 758, in install install_wheel( File "C:\git\idfunctiondb\venv\lib\site-packages\pip\_internal\operations\install\wheel.py", line 794, in install_wheel _install_wheel( File "C:\git\idfunctiondb\venv\lib\site-packages\pip\_internal\operations\install\wheel.py", line 637, in _install_wheel file.save() File "C:\git\idfunctiondb\venv\lib\site-packages\pip\_internal\operations\install\wheel.py", line 404, in save with self._zip_file.open(zipinfo) as f: File "C:\Python310\lib\zipfile.py", line 1520, in open fheader = zef_file.read(sizeFileHeader) File "C:\Python310\lib\zipfile.py", line 743, in read self._file.seek(self._pos) OSError: [Errno 22] Invalid argument Please note i added the line 742 with the content: print(str(self) + ' pos: ' + str(self._pos) ) to help to find the root cause. it Looks like that file.tell, returns a negative number, which kill file.seek. -- components: Windows messages: 411750 nosy: Martin-Forster, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: zipfile crash on windows, detected during pip install pyodbc-4.0.32-cp310-cp310-win_amd64.whl type: crash versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue46537> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46537] zipfile crash on windows, detected during pip install pyodbc-4.0.32-cp310-cp310-win_amd64.whl
Martin Forster added the comment: it tried one built on my own, and the one from https://www.lfd.uci.edu/~gohlke/pythonlibs/#pyodbc -- ___ Python tracker <https://bugs.python.org/issue46537> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46537] zipfile crash on windows, detected during pip install pyodbc-4.0.32-cp310-cp310-win_amd64.whl
Martin Forster added the comment: i opened a issue at pyodbc as well, https://github.com/mkleehammer/pyodbc/issues/1015 -- ___ Python tracker <https://bugs.python.org/issue46537> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46537] zipfile crash on windows, detected during pip install pyodbc-4.0.32-cp310-cp310-win_amd64.whl
Martin Forster added the comment: The wheel file was corrupt, due to git taking care of "CRLF/LF" conversion. Sorry for the fuss -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue46537> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46740] Improve Telnetlib's throughput
New submission from Martin Kirchgessner : While using `telnetlib` I sometimes received unusually "large" messages (around 1Mb) from another process on the same machine, and was surprised `read_until` took more than a second. After instrumenting I discovered such messages were received at roughly 500kbyte/s. I think this low throughput comes from two implementation details: - `Telnet.fill_rawq` is calling `self.sock.recv(50)`, whereas 4096 is now recommended - the `Telnet.process_rawq` method is transferring from raw queue to cooked queue by appending byte per byte. For the latter, transferring by slices looks much faster (I'm measuring at least 5x). I'm preparing a PR. -- components: Library (Lib) messages: 413195 nosy: martin_kirch priority: normal severity: normal status: open title: Improve Telnetlib's throughput type: resource usage versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue46740> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46738] Allow http.server to emit HTML 5
Change by Martin Panter : -- superseder: -> Generate HTML 5 with SimpleHTTPRequestHandler.list_directory ___ Python tracker <https://bugs.python.org/issue46738> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46756] Incorrect authorization check in urllib.request
Martin Panter added the comment: Maybe the same as Issue 42766? -- nosy: +martin.panter ___ Python tracker <https://bugs.python.org/issue46756> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46740] Improve Telnetlib's throughput
Change by Martin Kirchgessner : -- keywords: +patch pull_requests: +29577 stage: -> patch review pull_request: https://github.com/python/cpython/pull/31449 ___ Python tracker <https://bugs.python.org/issue46740> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
