[issue21802] Reader of BufferedRWPair is not closed if writer's close() fails
Antoine Pitrou added the comment: Why don't you reuse the API from issue21715? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21802 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22929] cp874 encoding almost empty
New submission from era: I created a simple script to map character codes in the 8bit range to Unicode for simple lookup: https://github.com/tripleee/8bit In the generated output, on Python 2.6.6 (but corroborated on Python 2.7.6), almost all character codes come up as undefined in CP874. According to http://en.wikipedia.org/wiki/ISO/IEC_8859-11, CP874 should be a superset of ISO-8859-11, with a few character codes *added* in the ISO control range. -- components: Unicode messages: 231596 nosy: era, ezio.melotti, haypo priority: normal severity: normal status: open title: cp874 encoding almost empty type: behavior versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22929 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22929] cp874 encoding almost empty
Changes by STINNER Victor victor.stin...@gmail.com: -- nosy: +lemburg ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22929 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22930] Value of time.timezone is sometimes wrong
New submission from Dmitry Shachnev: Here, on Linux, I get: $ python3 -c import time; print(time.timezone) -14400 … which means I am in UTC+4. However, Russia recently (in October) switched time, and moved from UTC+4 to UTC+3 timezone (my tzdata is up-to-date), so this reported value is wrong. The relevant code in timemodule.c looks like (simplified): #define YEAR ((time_t)((365 * 24 + 6) * 3600)) time_t t = (time((time_t *)0) / YEAR) * YEAR; struct tm *p = localtime(t); janzone = -p-tm_gmtoff; PyModule_AddIntConstant(m, timezone, janzone); The value of t is the *January 1st* of current year, i.e. 2014-01-01 currently. But the timezone of a country in the year beginning may be different from its timezone in the year end, which is the case for me. This bug will be relevant for Russia until the end of 2014, but may be still relevant for other countries that wish to change their timezone. -- components: Extension Modules messages: 231597 nosy: mitya57 priority: normal severity: normal status: open title: Value of time.timezone is sometimes wrong type: behavior versions: Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22930 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22929] cp874 encoding almost empty
Marc-Andre Lemburg added the comment: I'm not sure I understand the bug report. What's the problem ? :-) The codec is a charmap codec generated from the file MAPPINGS/VENDORS/MICSFT/WINDOWS/CP874.TXT (http://ftp.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WINDOWS/CP874.TXT) This mapping does have quite a few undefined characters. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22929 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22929] cp874 encoding almost empty
Marc-Andre Lemburg added the comment: BTW: The table on the wiki page shows the same undefined chars. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22929 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22929] cp874 encoding almost empty
era added the comment: My apologies -- I already attemptd to close this as a mistake on my part, but apparently, that failed too. )-: Sorry. -- resolution: - not a bug status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22929 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20954] Bug in subprocess._args_from_interpreter_flags causes MemoryError
Martin Dengler added the comment: FWIW, I've been using a this patch for 2.7.5 in a production setting for a month now and have had no problems. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20954 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22928] HTTP header injection in urrlib2/urllib/httplib/http.client
Changes by R. David Murray rdmur...@bitdance.com: -- nosy: +orsenthil, r.david.murray ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22928 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22930] Value of time.timezone is sometimes wrong
R. David Murray added the comment: This is a duplicate of issue 22752. -- nosy: +r.david.murray resolution: - duplicate stage: - resolved status: open - closed superseder: - incorrect time.timezone value ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22930 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22929] cp874 encoding almost empty
Changes by R. David Murray rdmur...@bitdance.com: -- stage: - resolved ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22929 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22752] incorrect time.timezone value
Dmitry Shachnev added the comment: Is it possible to set timezone based on localtime(current_time) where current_time is the result of time() call? This bug is not just about returning the wrong timezone. Because of it, the full time string produced with Python may be wrong. For example, my mail sending program uses `email.utils.formatdate(localtime=True)', and that is returning a time one hour in the past currently. -- nosy: +mitya57 status: pending - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22752 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22919] Update PCBuild for VS 2015
Zachary Ware added the comment: Another round of review posted on Rietveld. I'll try to get the VS2015 preview downloaded today and give some more feedback after using it. Just one inconsequential note on python3.diff: the 'lib' command in python3dll.vcxproj could use a '/nologo' flag. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22919 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22931] cookies with square brackets in value
New submission from Waldemar Parzonka: There seems to be weird behaviour in BaseCookie.load() when cookie that has '[' in one of the values is being loaded. There is no exception being thrown as the key is still legal but the cookie is not getting loaded properly and everything that was after the '[' valued cookie is being silently ignored. dd = SimpleCookie() dd SimpleCookie: s = 'a=b; c=[; d=r; f=h' dd.load(s) dd SimpleCookie: a='b' -- components: Library (Lib) messages: 231605 nosy: Waldemar.Parzonka priority: normal severity: normal status: open title: cookies with square brackets in value type: behavior versions: Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22931 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1962] ctypes feature request: Automatic type conversion of input arguments to C functions
Changes by Amaury Forgeot d'Arc amaur...@gmail.com: -- resolution: - works for me status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1962 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22752] incorrect time.timezone value
Alexander Belopolsky added the comment: Is it possible to set timezone based on localtime(current_time) where current_time is the result of time() call? No. time.timezone is a constant it cannot change with time. This is a limitation of the POSIX and C standards on which time module is based. For example, my mail sending program uses `email.utils.formatdate(localtime=True)', and that is returning a time one hour in the past currently. I thought email.utils.formatdate was fixed in 3.x series. Can you report this as a separate issue? -- nosy: +barry, r.david.murray ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22752 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22931] cookies with square brackets in value
Changes by R. David Murray rdmur...@bitdance.com: -- nosy: +r.david.murray ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22931 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7255] Default word boundaries for Unicode data?
Amaury Forgeot d'Arc added the comment: Closing this old issue: either use the 'regex' module, or wait for issue2636. -- nosy: +amaury.forgeotdarc resolution: - works for me status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7255 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22932] email.utils.formatdate uses unreliable time.timezone constant
New submission from Dmitry Shachnev: The value of time.timezone may be wrong sometimes (see http://bugs.python.org/issue22752), so I think the email library should not use it: $ python3 -c from email.utils import formatdate; print(formatdate(localtime=True)) Mon, 24 Nov 2014 19:16:32 +0400 $ date -R Mon, 24 Nov 2014 19:16:32 +0300 Using something from datetime module may be a better solution. -- components: Library (Lib) messages: 231608 nosy: belopolsky, mitya57 priority: normal severity: normal status: open title: email.utils.formatdate uses unreliable time.timezone constant versions: Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22932 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22932] email.utils.formatdate uses unreliable time.timezone constant
Alexander Belopolsky added the comment: See also issue 665194. -- nosy: +barry, r.david.murray ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22932 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22932] email.utils.formatdate uses unreliable time.timezone constant
Alexander Belopolsky added the comment: I was able to reproduce the problem on a Mac as follows: $ TZ=Europe/Moscow date +%c %z Mon Nov 24 19:27:51 2014 +0300 $ TZ=Europe/Moscow python3 -c from email.utils import formatdate; print(formatdate(localtime=True)) Mon, 24 Nov 2014 19:28:03 +0400 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22932 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22932] email.utils.formatdate uses unreliable time.timezone constant
Alexander Belopolsky added the comment: Using something from datetime module works as expected: $ TZ=Europe/Moscow python3 -c from datetime import datetime, timezone; print(datetime.now(timezone.utc).astimezone()) 2014-11-24 19:30:27.141542+03:00 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22932 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22932] email.utils.formatdate uses unreliable time.timezone constant
Changes by Alexander Belopolsky alexander.belopol...@gmail.com: -- stage: - needs patch type: - behavior ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22932 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22933] Misleading sentence in doc for shutil.move
New submission from newbie: First sentence of 3rd paragraph of 10.10. shutil documentation for shutil.move command, The destination directory must not already exist, is misleading and contradicts other information in the entry. I took it to mean that if dst did not exist, python would create it as a directory. What actually happens is that python renames src to dst. In my test, I was moving several files to a new directory, and the result was a file with the pathname dst and contents matching the last move command, consistent with the behavior described in the rest of the paragraph and the following one. When I changed the code to create the directory with os.mkdirs before calling shutil.move, it worked as I wanted, so obviously there's nothing wrong with the destination directory already existing. The preceding paragraph implies this with its description of behavior when dst refers to a directory. I suggest removing this sentence, and maybe adding some text indicating what to do if you want to move a fi le to a new directory. I was using Python 2.7.5 on Windows, and branch 2.7.8 of the documentation (there does not appear to be a branch 2.7.5 available.) -- assignee: docs@python components: Documentation messages: 231612 nosy: docs@python, newbie priority: normal severity: normal status: open title: Misleading sentence in doc for shutil.move type: behavior versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22933 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22932] email.utils.formatdate uses unreliable time.timezone constant
Dmitry Shachnev added the comment: This patch fixes the issue for me. -- keywords: +patch Added file: http://bugs.python.org/file37266/issue22932.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22932 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22932] email.utils.formatdate uses unreliable time.timezone constant
R. David Murray added the comment: email.utils.format_datetime uses datetime. formatdate wasn't touched, for backward compatibility reasons. If it has an actual bug we can fix it. If it can be converted to use datetime without sacrificing backward compatibility, that's also fine with me. Frankly I don't know enough at the moment to know if the proposed patch is correct. Alexander? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22932 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22932] email.utils.formatdate uses unreliable time.timezone constant
Changes by R. David Murray rdmur...@bitdance.com: -- stage: needs patch - patch review versions: +Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22932 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22932] email.utils.formatdate uses unreliable time.timezone constant
Alexander Belopolsky added the comment: The proposed patch will not work on platforms that don't support tm_gmtoff. A proper fix may look like this: dt = datetime.fromtimestamp(timeval, timezone.utc) if localtime: dt = dt.astimezone() return format_datetime(dt, usegmt) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22932 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22933] Misleading sentence in doc for shutil.move
R. David Murray added the comment: I think you are correct that that sentence should just be deleted. The preceding sentence should start If the destination is an existing directory... I also wonder if shutil should be changed to use os.replace, but that is a separate issue. -- nosy: +r.david.murray versions: +Python 3.4, Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22933 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22934] Python/importlib.h is now generated by Programs/_freeze_importlib.c, change comment
New submission from joseph: Since the changeset 91853:88a532a31eb3 _freeze_importlib.c resides in the Programs dir. The header comment of Python/importlib.h should be changed to reflect this. -- components: Build files: freeze_importlib_comment.patch keywords: patch messages: 231617 nosy: crozzy priority: normal severity: normal status: open title: Python/importlib.h is now generated by Programs/_freeze_importlib.c, change comment versions: Python 3.5 Added file: http://bugs.python.org/file37267/freeze_importlib_comment.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22934 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22934] Python/importlib.h is now generated by Programs/_freeze_importlib.c, change comment
Roundup Robot added the comment: New changeset 0ddcc455e001 by Berker Peksag in branch 'default': Issue #22934: Update the comment to mention Programs/_freeze_importlib.c. https://hg.python.org/cpython/rev/0ddcc455e001 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22934 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22934] Python/importlib.h is now generated by Programs/_freeze_importlib.c, change comment
Berker Peksag added the comment: Thanks for the patch, Joseph. -- assignee: - berker.peksag nosy: +berker.peksag resolution: - fixed stage: - resolved status: open - closed type: - enhancement ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22934 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20351] Add doc examples for DictReader and DictWriter
Roundup Robot added the comment: New changeset 268ceaa78cf9 by Berker Peksag in branch '3.4': Issue #20351: Add examples for csv.DictReader and csv.DictWriter. https://hg.python.org/cpython/rev/268ceaa78cf9 New changeset c2b36196b7f5 by Berker Peksag in branch 'default': Issue #20351: Add examples for csv.DictReader and csv.DictWriter. https://hg.python.org/cpython/rev/c2b36196b7f5 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20351 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20351] Add doc examples for DictReader and DictWriter
Roundup Robot added the comment: New changeset e504c3bc6897 by Berker Peksag in branch '2.7': Issue #20351: Add examples for csv.DictReader and csv.DictWriter. https://hg.python.org/cpython/rev/e504c3bc6897 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20351 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20351] Add doc examples for DictReader and DictWriter
Berker Peksag added the comment: Thanks for the patch, Charles-Axel. -- assignee: rhettinger - berker.peksag resolution: - fixed stage: patch review - resolved status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20351 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16056] shadowed test names in std lib regression tests
Roundup Robot added the comment: New changeset fd786e4e331c by Berker Peksag in branch '2.7': Issue #16056: Rename test methods to avoid conflict. https://hg.python.org/cpython/rev/fd786e4e331c -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16056 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16056] shadowed test names in std lib regression tests
Changes by Berker Peksag berker.pek...@gmail.com: -- assignee: - berker.peksag resolution: - fixed stage: patch review - resolved status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16056 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22935] Disabling SSLv3 support
New submission from Kurt Roeckx: Hi, The attached patch makes python work when openssl doesn't have SSLv3 support. It also updates the documentation, which has already improved a lot since my original patch. The current upstream openssl when compiled with no-ssl2 it defines OPENSSL_NO_SSL2, drops the SSLv2_* method and drops support for SSLv2 in the SSLv23_* methods. When build with no-ssl3 it defines OPENSSL_NO_SSL3 and currently just drops supports for SSLv3 in the SSLv23_method, it does not yet drop the SSLv3_* methods. It's still being argued whether no-ssl3 should drop those symbols or that a new option will be used instead. So that means that with OPENSSL_NO_SSL3 defined it could be that the SSLv3_* methods still exist and that you can create a socket that only support SSLv3. I made the SSLv3 methods go away in python if OPENSSL_NO_SSL3 is defined. This at least makes things easier for the test suite so that you know you can test a combination like v3 with v23 or not. This patch is for 2.7. Please let me know if you need a patch for a different version. -- files: python2.7-nossl3.patch keywords: patch messages: 231624 nosy: kroeckx priority: normal severity: normal status: open title: Disabling SSLv3 support Added file: http://bugs.python.org/file37268/python2.7-nossl3.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22935 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22935] Disabling SSLv3 support
Alex Gaynor added the comment: FWIW, Debian expiremental appears to be using a different #define for this. Here's how we handled it in pyca/cryptography: https://github.com/pyca/cryptography/commit/04a3f1f2c4086c0d7162b6dd79b6332d9115b2c0 -- nosy: +alex, christian.heimes, dstufft, giampaolo.rodola, janssen, pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22935 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22935] Disabling SSLv3 support
Kurt Roeckx added the comment: I know what I uploaded to Debian experimental. And I can't promise that I'll keep that define. I suggest you assume that NO_SSL3 will disable both. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22935 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22935] Disabling SSLv3 support
Alex Gaynor added the comment: Good to know, thanks. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22935 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22935] Disabling SSLv3 support
Changes by Antoine Pitrou pit...@free.fr: -- stage: - patch review type: - compile error versions: +Python 2.7, Python 3.4, Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22935 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22936] traceback module has no way to show locals
New submission from Robert Collins: From https://github.com/testing-cabal/testtools/issues/111 - any code that is data dependent can be hard to diagnose from a backtrace alone. Many unittest and server environments address this by doing custom tracebacks that include locals. To address this in unittest, we need to add a similar capacity to traceback, and then use it from unittest (as we can't just depend on a module from PyPI in the stdlib). -- components: Library (Lib) messages: 231628 nosy: rbcollins priority: normal severity: normal status: open title: traceback module has no way to show locals versions: Python 3.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22936 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22936] traceback module has no way to show locals
Changes by Robert Collins robe...@robertcollins.net: -- type: - enhancement ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22936 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22937] unittest errors can't show locals
New submission from Robert Collins: From https://github.com/testing-cabal/testtools/issues/111 - any code that is data dependent can be hard to diagnose from a backtrace alone. Many unittest and server environments address this by doing custom tracebacks that include locals. To address this in unittest, we need to add a similar capacity to traceback, and then use it from unittest (as we can't just depend on a module from PyPI in the stdlib). This issue is for the unittest part of it. For the traceback dependency see http://bugs.python.org/issue22936 . -- components: Library (Lib) messages: 231629 nosy: rbcollins priority: normal severity: normal status: open title: unittest errors can't show locals type: enhancement versions: Python 3.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22937 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22936] traceback module has no way to show locals
Robert Collins added the comment: See http://bugs.python.org/issue22936 for the unittest aspect of this. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22936 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22919] Update PCBuild for VS 2015
Zachary Ware added the comment: After a debug build with VS2015, my biggest concern is this: ..\PC\bdist_wininst\install.rc(19): fatal error RC1015: cannot open include file 'afxres.h'. [P:\ath\to\cpython\PCbuild\bdist_wininst.vcxproj] There's also a slew of new warnings, mostly C4456 and C4457 with a few C4459s thrown in. I think we can safely disable those three (which are all about name shadowing), perhaps with a XXX comment alongside to the effect of 'it might be nice to not disable these warnings someday'. Interestingly, there's also this warning: C:\Program Files (x86)\Windows Kits\8.1\Include\um\shlobj.h(1054): warning C4091: 'typedef ': ignored on left of 'tagGPFIDL_FLAGS' when no variable is declared [P:\ath\to\cpython\PCbuild\pylauncher.vcxproj] And a matching one for pywlauncher.vcxproj. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22919 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22676] _pickle's whichmodule() is slow
Zachary Ware added the comment: This is still causing a somewhat serious warning on Windows, see [1] for example. The condition warned about affects every platform. It took me some time to make sense of that function, but I think I finally understand what's going on. I think Steve's suggestion of initializing module to Py_None would be fine, or just pass in a known good object like global instead since the 'obj' parameter is only used for error message formatting. Either way, I think the error check at Modules/_pickle.c:1657 [2] should either use reformat_attribute_error() or do the reformatting itself (to provide a different message) because I don't think the AttributeError message from get_dotted_path would be anywhere close to correct (especially if 'obj' is given as Py_None). [1] http://buildbot.python.org/all/builders/x86%20Windows7%203.x/builds/8969/steps/compile/logs/stdio [2] Steve: the 'Comment:' label in the form is a handy link to the devguide section about how magic links work. In this case, it's filepath.ext:number -- nosy: +zach.ware resolution: fixed - stage: resolved - commit review status: closed - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22676 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22938] assignment operator += does not behave same as a = a + b for List
New submission from Archana Pandey: List is mutable with += operator. But the same cannot be achieved when we use arithmatic + and assignment = operator used Please Find the attached python module -- components: Windows files: Operator_bug_python.py messages: 231633 nosy: archi-pandey, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: assignment operator += does not behave same as a = a + b for List type: behavior versions: Python 3.2 Added file: http://bugs.python.org/file37269/Operator_bug_python.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22938 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22919] Update PCBuild for VS 2015
Steve Dower added the comment: After a debug build with VS2015, my biggest concern is this: ..\PC\bdist_wininst\install.rc(19): fatal error RC1015: cannot open include file 'afxres.h'. [P:\ath\to\cpython\PCbuild\bdist_wininst.vcxproj] I thought I had a workaround for this, but I'll have to check it out. Oddly enough, all of my builds have been fine (I think I'm mostly doing release builds - does that make a difference?) There's also a slew of new warnings, mostly C4456 and C4457 with a few C4459s thrown in. I think we can safely disable those three (which are all about name shadowing), perhaps with a XXX comment alongside to the effect of 'it might be nice to not disable these warnings someday'. I'm torn about that. Ideally I'd like to suppress the existing ones and still have new ones appear, but that probably requires going through and fixing them. Maybe leaving the warnings there will encourage someone to do it? :) Interestingly, there's also this warning: C:\Program Files (x86)\Windows Kits\8.1\Include\um\shlobj.h(1054): warning C4091: 'typedef ': ignored on left of 'tagGPFIDL_FLAGS' when no variable is declared [P:\ath\to\cpython\PCbuild\pylauncher.vcxproj] And a matching one for pywlauncher.vcxproj. This is a known issue with the Windows SDK - they need to release a new version to handle the changes in the compiler. It doesn't affect the Python build, though it is currently breaking some of my installer work :( I'm confident it will be fixed soon - they're getting a lot of reports about it. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22919 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22919] Update PCBuild for VS 2015
Steve Dower added the comment: Added changes from Zach's last review. Highlight: I deleted the make_versioninfo project and build step :) -- Added file: http://bugs.python.org/file37270/round4.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22919 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21236] patch to use cabinet.lib instead of fci.lib (fixes build with Windows SDK 8.0)
Steve Dower added the comment: I've inadvertently picked this up with my changes for #22919, so it'll get into 3.5 that way. Do we need to apply this to 3.4 as well? What about 2.7? -- assignee: - steve.dower nosy: +steve.dower ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21236 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22938] assignment operator += does not behave same as a = a + b for List
Steve Dower added the comment: This is by design. I'm sure if you email python-list then someone there will be able to explain how the difference can help you write clearer code than if they both behaved exactly the same. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22938 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22938] assignment operator += does not behave same as a = a + b for List
Steve Dower added the comment: Info about python-list is at https://mail.python.org/mailman/listinfo/python-list -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22938 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21236] patch to use cabinet.lib instead of fci.lib (fixes build with Windows SDK 8.0)
Zachary Ware added the comment: Definitely not 2.7, since it's still on VS2008 and would require so many changes for this to matter that it's just not an issue; I'm not sure on 3.4. Is cabinet.lib available (and have everything we need) for MSVC10 and SDK 7.1 (which are the important targets for 3.4)? -- versions: +Python 3.5 -Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21236 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22938] assignment operator += does not behave same as a = a + b for List
Changes by Steve Dower steve.do...@microsoft.com: -- resolution: - not a bug status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22938 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22752] incorrect time.timezone value
Akira Li added the comment: C standard delegates to implementations: The local time zone and Daylight Saving Time are implementation-defined. gcc (one of the implementations) says [1]: [timezone] contains the difference between UTC and the latest local standard time, in seconds west of UTC. Notice the word latest. To be fair, gcc (the actual implementation) uses a weird logic to assign timezone, daylight values in Europe/Moscow timezone in 2011-2015. Python own tests assume that time.timezone reflects the *current* (most recent) time http://bugs.python.org/issue22799 C tzname, timezone, daylight are not constants. They may change e.g., see http://bugs.python.org/issue22798 (the C code demonstrates that tzname changes even for the same local timezone). POSIX specifies a profile (additional restrictions but no conflict) of C standard for the time functions e.g., tzset(), mktime() [2], ctime(), localtime() may change tzname, timezone, daylight (but *not* gmtime() or asctime()). To summarize: - timezone is implementation-defined in C - gcc (one of implementations) says that timezone corresponds to the latest time (the actual behavior is complicated) - POSIX says that time functions shall set timezone info i.e., timezone is not a constant (it is obvious due to tzset() existence) - Python tests assume that timezone corresponds to the current time (not january or july) I'm not sure what time.timezone behaviour should be: - leave it as is (unsynchronized with C values and it may be different from the current correct value) -- it makes time module unusable in some timezones (60% all time, 11% since 2001), some of the time - use latest correct (gmtoff where available) value during importing the time module -- it would fix this issue22752 - synchronize with C values -- it improves some things e.g., it may fix http://bugs.python.org/issue22426 but it might make the behavior more platform dependent (tests needed) and it make things worse in some timezones e.g., where dst() != 1 hour (13% all time, 0.9% since 2000) [1] http://www.gnu.org/software/libc/manual/html_node/Time-Zone-Functions.html [2] http://pubs.opengroup.org/onlinepubs/9699919799/functions/mktime.html -- nosy: +akira ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22752 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22938] assignment operator += does not behave same as a = a + b for List
Changes by Zachary Ware zachary.w...@gmail.com: -- stage: - resolved ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22938 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22938] assignment operator += does not behave same as a = a + b for List
Changes by Zachary Ware zachary.w...@gmail.com: -- components: -Windows ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22938 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21802] Reader of BufferedRWPair is not closed if writer's close() fails
Serhiy Storchaka added the comment: Because this API was not still committed. Here is a patch which uses it. -- Added file: http://bugs.python.org/file37271/bufferedrwpair_close_2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21802 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22896] Don't use PyObject_As*Buffer() functions
Serhiy Storchaka added the comment: Here is a patch which replaces deprecated functions with PyObject_GetBuffer() and like. It also introduce _PyBuffer_Converter for using in PyArgs_Parse* and clinic converter simple_buffer_converter which unlike to Py_buffer_converter (y*) does not not force C contiguousity (is it correct?). -- keywords: +patch nosy: +larry, pitrou stage: needs patch - patch review Added file: http://bugs.python.org/file37272/buffers.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22896 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
