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)
Serhiy Storchaka added the comment:
See also issue16979.
--
assignee: - serhiy.storchaka
stage: - needs patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16975
___
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 rep...@bugs.python.org
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
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
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
Changes by Serhiy Storchaka storch...@gmail.com:
Added file:
http://bugs.python.org/file28750/escape_decode_error_handling-2.7.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16975
___
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
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 rep...@bugs.python.org
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
Ramchandra Apte added the comment:
+1
On 16 January 2013 17:43, R. David Murray rep...@bugs.python.org 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
Ramchandra Apte added the comment:
Though it may be valid in Python 2.7 still.
On 16 January 2013 10:53, Ramchandra Apte rep...@bugs.python.org wrote:
Ramchandra Apte added the comment:
Is this still valid because this seems fixed in latest Python 3.4 tip.
--
nosy:
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:
New submission from Serhiy Storchaka:
import codecs
codecs.unicode_escape_decode(b'\\\x80')
Traceback (most recent call last):
File stdin, line 1, in module
SystemError: invalid maximum character passed to PyUnicode_New
--
assignee: serhiy.storchaka
components: Unicode
keywords:
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
___
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:
Changes by Barry A. Warsaw ba...@python.org:
--
nosy: +barry
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue3585
___
___
Python-bugs-list mailing
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):
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 rep...@bugs.python.org
http://bugs.python.org/issue16981
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.
Changes by Serhiy Storchaka storch...@gmail.com:
--
assignee: - serhiy.storchaka
nosy: +serhiy.storchaka
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1483
___
Changes by Serhiy Storchaka storch...@gmail.com:
--
assignee: docs@python - serhiy.storchaka
nosy: +serhiy.storchaka
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2175
___
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).
--
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
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 rep...@bugs.python.org
http://bugs.python.org/issue13028
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 -
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 rep...@bugs.python.org
Changes by Brett Cannon br...@python.org:
--
status: pending - open
versions: +Python 3.4 -Python 3.2
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10535
___
Changes by Brett Cannon br...@python.org:
--
nosy: -brett.cannon
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11983
___
___
Python-bugs-list
Changes by Brett Cannon br...@python.org:
--
nosy: -brett.cannon
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11729
___
___
Python-bugs-list
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
Antoine Pitrou added the comment:
Woops, I saw Brett unnosied himself, sorry for nosying him by mistake.
--
nosy: -brett.cannon
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11983
___
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
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
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 rep...@bugs.python.org
http://bugs.python.org/issue16893
___
Ismail Donmez added the comment:
See http://sourceware.org/ml/libffi-discuss/2011/msg00024.html for the libffi
patch.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11729
___
Changes by Brett Cannon br...@python.org:
--
status: open - pending
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10535
___
___
Python-bugs-list
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
Changes by Serhiy Storchaka storch...@gmail.com:
--
assignee: - serhiy.storchaka
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10590
___
___
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 rep...@bugs.python.org
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?= f...@example.com
Since encountering something that looks like an encoded word but that is not is
a very
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
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 Jan
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
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:
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 rep...@bugs.python.org
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
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
Changes by Daniel Stutzbach stutzb...@google.com:
--
assignee: stutzbach - rhettinger
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2226
___
___
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), file, exec)
Traceback (most recent call last):
File stdin, line 1, in module
TypeError:
Changes by Andrew Svetlov andrew.svet...@gmail.com:
--
nosy: +asvetlov
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15436
___
___
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
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
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
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
55 matches
Mail list logo
