[issue16979] Broken error handling in codecs.unicode_escape_decode()

New submission from Serhiy Storchaka: An error handler in unicode_escape_decode() eats at least one byte (or more) after illegal escape sequence. >>> import codecs >>> codecs.unicode_escape_decode(br'\u!@#', 'replace') ('�', 5) >>> codecs.unicode_escape_decode(br'\u!@#$', 'replace') ('�@#$', 6)

[issue16975] Broken error handling in codecs.escape_decode()

Serhiy Storchaka added the comment: See also issue16979. -- assignee: -> serhiy.storchaka stage: -> needs patch ___ Python tracker ___ _

[issue9501] Logging shutdown regressions with weakrefs

Vinay Sajip added the comment: Thanks for hunting these down. With the latest version, neither variant of the teardown script produces any error message on my system, either with 3.3 or 3.4 (default). -- ___ Python tracker

[issue16422] Decimal constants should be the same for py & c module versions

Roundup Robot added the comment: New changeset 733bb4fd9888 by Stefan Krah in branch '3.3': Issue #16422: Use strings for rounding mode constants for better readability http://hg.python.org/cpython/rev/733bb4fd9888 -- nosy: +python-dev ___ Python trac

[issue9501] Logging shutdown regressions with weakrefs

Xavier de Gaye added the comment: Yes, my last two messages refer to python 3.3.0 only. The changes logged in http://bugs.python.org/issue9501#msg180039 do fix the behavior of both versions of teardown_module.py. -- ___ Python tracker

[issue16975] Broken error handling in codecs.escape_decode()

Serhiy Storchaka added the comment: Here is a patch which fixes error handling in codecs.escape_decode(). >>> codecs.escape_decode(r'[\x1]\x2', 'replace') (b'[?]?', 8) New tests for escape_decode() added. -- keywords: +patch nosy: +doerwalter, lemburg stage: needs patch -> patch review

[issue16975] Broken error handling in codecs.escape_decode()

Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file28750/escape_decode_error_handling-2.7.patch ___ Python tracker ___ ___

[issue16974] when "python -c command" does a traceback, it open the file ""

R. David Murray added the comment: Ideally there would be an unambiguous way to know if the object came from a file or some other source (say, __file__ is None and another special attribute gives the clue to the actual source), but that's not the way things work now, and for backward compatibi

[issue16974] when "python -c command" does a traceback, it open the file ""

R. David Murray added the comment: Hmm. A backward compatible fix would be to add an attribute that indicates whether or not the __file__ attribute is supposed to be pointing to a real file. -- ___ Python tracker

[issue16422] Decimal constants should be the same for py & c module versions

Stefan Krah added the comment: In the version I committed the string constants are interned, so anything but legacy strings should be reasonably fast. -- assignee: -> skrah components: +Extension Modules resolution: -> fixed stage: -> committed/rejected status: open -> closed ___

[issue16974] when "python -c command" does a traceback, it open the file ""

Ramchandra Apte added the comment: +1 On 16 January 2013 17:43, R. David Murray wrote: > > R. David Murray added the comment: > > Ideally there would be an unambiguous way to know if the object came from > a file or some other source (say, __file__ is None and another special > attribute gives

[issue5773] Crash on shutdown after os.fdopen(2) in debug builds

Ramchandra Apte added the comment: Though it may be valid in Python 2.7 still. On 16 January 2013 10:53, Ramchandra Apte wrote: > > Ramchandra Apte added the comment: > > Is this still valid because this seems fixed in latest Python 3.4 tip. > > -- > nosy: +ramchandra.apte > >

[issue10701] Error pickling a dict

Charles-François Natali added the comment: > It's interesting. The example behaves unstable on 3.3+ with C implementation > of picle, sometimes works, sometimes fails. With Python implementation and on > 3.2 it works always. On 2.7 it fails always. That's hash randomization. -- nosy:

[issue16980] SystemError in codecs.unicode_escape_decode()

New submission from Serhiy Storchaka: >>> import codecs >>> codecs.unicode_escape_decode(b'\\\x80') Traceback (most recent call last): File "", line 1, in SystemError: invalid maximum character passed to PyUnicode_New -- assignee: serhiy.storchaka components: Unicode keywords: 3.3regr

[issue16980] SystemError in codecs.unicode_escape_decode()

Serhiy Storchaka added the comment: Here is a fix. The complete test suite will be in issue16979. -- keywords: +patch stage: needs patch -> patch review Added file: http://bugs.python.org/file28751/unicode_escape_decode_escaped_nonascii.patch ___ Pyt

[issue16979] Broken error handling in codecs.unicode_escape_decode()

Serhiy Storchaka added the comment: Here is a patch for 3.4. Patches for other versions will be different a lot. -- dependencies: +SystemError in codecs.unicode_escape_decode() keywords: +patch stage: needs patch -> patch review Added file: http://bugs.python.org/file28752/unicode_escap

[issue3585] pkg-config support

Changes by Barry A. Warsaw : -- nosy: +barry ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.

[issue16981] ImportError hides real error when there too many open files during an import

New submission from Brian Sutherland: When running Python inside PostgreSQL using plpython on OSX 10.7.5 I started coming across very strange and apparently random ImportErrors. For example, failing to find the stat module while importing site: Traceback (most recent call last): Fi

[issue16981] ImportError hides real error when there too many open files during an import

R. David Murray added the comment: I wonder if importlib replicates this behavior, it may need fixing as well. -- nosy: +brett.cannon, eric.snow, r.david.murray ___ Python tracker __

[issue16982] _ssl not built --without-threads

New submission from Stefan Krah: _ssl is not built on the Fedora buildbot: http://buildbot.python.org/all/builders/AMD64%20Fedora%20without%20threads%203.x/builds/3798/steps/test/logs/stdio building '_ssl' extension gcc -fPIC -Wno-unused-result -g -O0 -Wall -Wstrict-prototypes -I./Include -I.

[issue1483] xml.sax.saxutils.prepare_input_source ignores character stream in InputSource

Changes by Serhiy Storchaka : -- assignee: -> serhiy.storchaka nosy: +serhiy.storchaka ___ Python tracker ___ ___ Python-bugs-list mai

[issue2175] Expat sax parser silently ignores the InputSource protocol

Changes by Serhiy Storchaka : -- assignee: docs@python -> serhiy.storchaka nosy: +serhiy.storchaka ___ Python tracker ___ ___ Python-bu

[issue16981] ImportError hides real error when there too many open files during an import

Brett Cannon added the comment: A quick trace through importlib._bootstrap through hg.python.org would suggest that the OSError would propagate when accessing source (OSError is swallowed when you try and write bytecode, but that's legitimate semantics). -- ___

[issue16893] Create IDLE help.txt from Doc/library/idle.rst

Zachary Ware added the comment: Sorry, I wasn't as clear as I meant to be in my last message, I was suddenly rushed and didn't realize I'd left out what I meant to say, which was: Now that Andrew has committed Todd's fix to issue 5066, idle.rst and help.txt are very well-aligned. I believe th

[issue13028] python wastes linux users time by checking for dylib on each dynamic library load

Brett Cannon added the comment: Since this has been pending for over two months I'm claiming it's outdated. -- resolution: -> out of date status: pending -> closed ___ Python tracker __

[issue4347] Circular dependency causes SystemError when adding new syntax

Brett Cannon added the comment: Since this has been sitting here for two months as pending I'm closing as won't fix since mucking with the grammar is such a rarity and getting the build rules right is so complicated it isn't worth changing. -- resolution: -> wont fix status: pending -

[issue10535] Enable warnings by default in unittest

Brett Cannon added the comment: Ezio, do you want to create separate issues for any of the TODOs you wanted in http://bugs.python.org/issue10535#msg122779 so we can close this bug? -- status: open -> pending ___ Python tracker

[issue10535] Enable warnings by default in unittest

Changes by Brett Cannon : -- status: pending -> open versions: +Python 3.4 -Python 3.2 ___ Python tracker ___ ___ Python-bugs-list mai

[issue11983] Inconsistent hash and comparison for code objects

Changes by Brett Cannon : -- nosy: -brett.cannon ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.p

[issue11729] libffi assembler relocation check is not robust, fails with clang

Changes by Brett Cannon : -- nosy: -brett.cannon ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.p

[issue11983] Inconsistent hash and comparison for code objects

Antoine Pitrou added the comment: > It doesn't actually fix the bug and makes hash inconsistent with cmp. The only constraint is that a == b imply hash(a) == hash(b). But the converse doesn't have to be true, i.e. if it perfectly possible to have hash(a) == hash(b) and a != b (pretty much by d

[issue11983] Inconsistent hash and comparison for code objects

Antoine Pitrou added the comment: Woops, I saw Brett unnosied himself, sorry for nosying him by mistake. -- nosy: -brett.cannon ___ Python tracker ___ __

[issue12939] Add new io.FileIO using the native Windows API

Guido van Rossum added the comment: Just a note of support for Richard -- having I/O use the native APIs directly rather than via emulation or other wrappers is a good idea, because the emulations / wrappers usually add restrictions that are not present in the native API. This is also the rea

[issue11729] libffi assembler relocation check is not robust, fails with clang

Stefan Krah added the comment: In 3.3 libffi has been updated to 3.0.11. Our clang buildbot does not show this particular warning, but still fails to compile libffi: http://buildbot.python.org/all/builders/AMD64%20FreeBSD%209.0%20dtrace%2Bclang%203.3/builds/320/steps/compile/logs/stdio It woul

[issue16893] Create IDLE help.txt from Doc/library/idle.rst

Georg Brandl added the comment: I did test the Makefile change, so this should be good to go. I'll upate PEP 101 once it's in. -- ___ Python tracker ___ ___

[issue11729] libffi assembler relocation check is not robust, fails with clang

Ismail Donmez added the comment: See http://sourceware.org/ml/libffi-discuss/2011/msg00024.html for the libffi patch. -- ___ Python tracker ___ _

[issue10535] Enable warnings by default in unittest

Changes by Brett Cannon : -- status: open -> pending ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mai

[issue11983] Inconsistent hash and comparison for code objects

Brett Cannon added the comment: Making as pending for someone to prove my fix is bad for the problem (since it passes an explicit test), else I will close it in the near-ish future. -- nosy: +brett.cannon status: open -> pending ___ Python tracker <

[issue10590] Parameter type error for xml.sax.parseString(string, ...)

Changes by Serhiy Storchaka : -- assignee: -> serhiy.storchaka ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue16978] fix grammar in 'threading' documentation

New submission from Tshepang Lekhonkhobe: Also, sentence starting with "Due to the" does not flow so nice for me... maybe a comma is needed after "CPython"? -- type: -> enhancement ___ Python tracker

[issue16983] header parsing could apply postel's law to encoded words inside quotes

New submission from R. David Murray: It has come to my attention that at least some mail agents apply postel's law to addresses like the following: From: "=?utf-8?Q?not_really_valid?=" Since encountering something that looks like an encoded word but that is not is a very unlikely occurren

[issue12758] time.time() returns local time instead of UTC

Craig McQueen added the comment: Alexander Belopolsky wrote: > No. Seconds since the epoch is neither local nor UTC. It is just > an elapsed number of seconds since an agreed upon time called the > "epoch". This statement just seems wrong. And I have just been confused by the current document

[issue12758] time.time() returns local time instead of UTC

Antoine Pitrou added the comment: > It makes a difference. It seems with the current behaviour, the > "epoch" is _in the local timezone_. No it isn't. Two different machines: $ LANG=C date Wed Jan 16 21:47:03 UTC 2013 $ python -c "import time; print(time.time())" 1358372827.5 $ LANG=C date Wed

[issue16984] idle problem with dark color schemes in kde

New submission from Sureyya Sahin: I am trying to use IDLE in kde linux environment (kubuntu 12.10). I recently switched to a dark color scheme from kde settings and discovered that IDLE is having issues with dark colors. The Completions boxes are not readable, after I switched to the dark col

[issue16886] Doctests in test_dictcomp depend on dict order

Roundup Robot added the comment: New changeset 6d06b223c664 by Frank Wierzbicki in branch '2.7': Closed #16886: test_dictcomps no longer depends on dict order http://hg.python.org/cpython/rev/6d06b223c664 New changeset c7dfc307b88e by Frank Wierzbicki in branch '3.2': Closed #16886: test_dictcom

[issue12758] time.time() returns local time instead of UTC

R. David Murray added the comment: On linux/posix, the epoch is *defined* to be 1970, 1, 1 in UTC. Python just uses whatever the OS defines the epoch to be, as far as I know. -- ___ Python tracker ___

[issue11729] libffi assembler relocation check is not robust, fails with clang

Roundup Robot added the comment: New changeset 190a115b7748 by Stefan Krah in branch '3.3': Issue #11729: Backport commit bff052d9 from libffi upstream in order to fix http://hg.python.org/cpython/rev/190a115b7748 -- nosy: +python-dev ___ Python track

[issue11729] libffi assembler relocation check is not robust, fails with clang

Stefan Krah added the comment: Thanks for the link. The diff was committed last week to the upstream libffi development tree, so I backported it. -- assignee: -> skrah resolution: -> fixed stage: -> committed/rejected status: open -> closed type: -> behavior versions: +Python 3.4 __

[issue2226] Small _abcoll Bugs / Oddities

Changes by Daniel Stutzbach : -- assignee: stutzbach -> rhettinger ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe

[issue16795] Patch: some changes to AST to make it more useful for static language analysis

Sven Brauch added the comment: I think I got it mostly working now (it was quite simple in fact), but there's one issue which I can't seem to solve. This fails: >>> compile(ast.parse("def fun(): pass"), "", "exec") Traceback (most recent call last): File "", line 1, in TypeError: required fi

[issue15436] __sizeof__ is not documented

Changes by Andrew Svetlov : -- nosy: +asvetlov ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pyth

[issue11983] Inconsistent hash and comparison for code objects

Eugene Toder added the comment: My comment will make more sense if you follow the links that I provided. Brett's check-in (http://hg.python.org/cpython-fullhistory/rev/8127a55a57cb) says that it fixes bug #1190011 (http://www.mail-archive.com/python-bugs-list@python.org/msg02440.html). The bu

[issue15359] Sockets support for CAN_BCM

Brian Thorne added the comment: Thanks for the review Charles-François. I can't make your suggested bcm_msg_fmt work - it was deadlocking on my machine! -- Added file: http://bugs.python.org/file28756/bcm3.patch ___ Python tracker

[issue16984] idle problem with dark color schemes in kde

Roger Serwy added the comment: This is a duplicate of issue7949, but for KDE instead of GTK. I will close this report in favor of the prior one. -- nosy: +serwy resolution: -> duplicate status: open -> closed superseder: -> idle does not handle dark gtk color schemes

[issue7949] IDLE: problems with dark GTK or KDE color schemes

Roger Serwy added the comment: Updated the issue to reflect information from 16984. A screenshot was provided in that report. -- nosy: +sahin, serwy title: idle does not handle dark gtk color schemes -> IDLE: problems with dark GTK or KDE color schemes versions: +Python 2.7, Python 3.1