[issue19539] The 'raw_unicode_escape' codec buggy + not apropriate for Python 3.x

Serhiy Storchaka added the comment: The 'raw_unicode_escape' codec can't be neither removed nor changed because it is used in pickle protocol. Just don't use it if its behavior looks weird for you. Right way to decode raw_unicode_escape-encoded data is use 'raw_unicode_escape' decoder. If a

[issue19541] ast.dump(indent=True) prettyprinting

New submission from anatoly techtonik: ast.dump needs an indent argument for pretty printing. from pprint import pprint as pp pp(ast.dump(node)) "Assign(targets=[Tuple(elts=[Name(id='d', ctx=Store()), Name(id='m', ctx=Store())], ctx=Store())], value=Call(func=Name(id='divmod', ctx=Load()

[issue19540] PEP339: Fix link to Zephyr ASDL paper

Changes by anatoly techtonik : -- assignee: docs@python components: Documentation hgrepos: 213 nosy: docs@python, techtonik priority: normal severity: normal status: open title: PEP339: Fix link to Zephyr ASDL paper ___ Python tracker

[issue19539] The 'raw_unicode_escape' codec buggy + not apropriate for Python 3.x

New submission from Jan Kaliszewski: It seems that the 'raw_unicode_escape' codec: 1) produces data that could be suitable for Python 2.x raw unicode string literals and not for Python 3.x raw unicode string literals (in Python 3.x \u... escapes are also treated literally); 2) seems to be bug

[issue18802] ipaddress documentation errors

Changes by Ezio Melotti : -- stage: -> patch review ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://ma

[issue13248] deprecated in 3.2/3.3, should be removed in 3.4

Changes by Ezio Melotti : -- stage: -> patch review ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://ma

[issue10197] subprocess.getoutput fails on win32

Arfrever Frehtes Taifersar Arahesis added the comment: Lib/subprocess.py still has outdated comment: # NB This only works (and is only relevant) for POSIX. -- nosy: +Arfrever ___ Python tracker ___

[issue19530] cross thread shutdown of UDP socket exhibits unexpected behavior

mpb added the comment: After some research... > Which is normal, since UDP sockets aren't connected. But UDP sockets can be connected! If I connect the UDP sockets, then shutdown succeeds (no exception is raised), but recvfrom still appears to succeed, returning a zero length message with a

[issue19538] Changed function prototypes in the PEP 384 stable ABI

Changes by STINNER Victor : -- nosy: +haypo ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python

[issue1575020] Request wave support > 16 bit samples

Changes by Serhiy Storchaka : -- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed ___ Python tracker ___ _

[issue1575020] Request wave support > 16 bit samples

Roundup Robot added the comment: New changeset 5fbcb4aa48fa by Serhiy Storchaka in branch '2.7': Issue #1575020: Fixed support of 24-bit wave files on big-endian platforms. http://hg.python.org/cpython/rev/5fbcb4aa48fa New changeset 79b8b7c5fe8a by Serhiy Storchaka in branch '3.3': Issue #157502

[issue19533] Unloading docstrings from memory if -OO is given

R. David Murray added the comment: Hmm. If I turn on gc debugging before the def, I don't see anything get collected. If I allocate a series of new 10K strings, the memory keeps growing. Of course, that could still be down to the vagaries of OS memory management. Time to break out Victor's

[issue19533] Unloading docstrings from memory if -OO is given

Stefan Krah added the comment: R. David Murray wrote: > So the question is, if there is no longer a reference to the docstring, why > isn't it garbage collected? (I tested adding a gc.collect(), and it didn't > make any difference.) I think it probably is garbage collected but the freed memo

[issue16685] audioop functions shouldn't accept strings

Serhiy Storchaka added the comment: If there are no objections I will commit last patch tomorrow. -- ___ Python tracker ___ ___ Python

[issue5815] locale.getdefaultlocale() missing corner case

Serhiy Storchaka added the comment: Ping. There are two duplicate issues opened last month. -- ___ Python tracker ___ ___ Python-bugs-l

[issue19538] Changed function prototypes in the PEP 384 stable ABI

Ezio Melotti added the comment: See #9369 and #1772673. -- nosy: +ezio.melotti, serhiy.storchaka type: -> behavior ___ Python tracker ___ ___

[issue19020] Regression: Windows-tkinter-idle, unicode, and 0xxx filename

Serhiy Storchaka added the comment: Tests added in issue19085 have a special case for tuple values because widget[name] and widget.configure(name) return different results in such cases. When remove this special case, following tests fails: =

[issue19538] Changed function prototypes in the PEP 384 stable ABI

New submission from Thomas Heller: (As requested by email in python-dev I'm reporting this problem) Some function prototypes in the stable ABI have been changed between Python 3.3 and 3.4. PyObject_CallFunction is an example, the second parameter has been changed from 'char *' to 'const char *

[issue19227] test_multiprocessing_xxx hangs under Gentoo buildbots

Changes by Benjamin Peterson : -- resolution: -> fixed status: open -> closed ___ Python tracker ___ ___ Python-bugs-list mailing lis

[issue19499] "import this" is cached in sys.modules

Ezio Melotti added the comment: I think this should be closed as won't fix. Having "import this" behave differently from any other import is counter-intuitive (students will start asking "why if I reimport 'this' the code gets executed every time but it doesn't work with my module?"). If they

[issue19085] Add tkinter basic options tests

Roundup Robot added the comment: New changeset be8f9beca8aa by Serhiy Storchaka in branch '2.7': Fix Tkinter tests on Tk 8.5 with patchlevel < 8.5.11 (issue #19085). http://hg.python.org/cpython/rev/be8f9beca8aa New changeset 204e66190dbb by Serhiy Storchaka in branch '3.3': Fix Tkinter tests on

[issue18874] Add a new tracemalloc module to trace memory allocations

STINNER Victor added the comment: > 2013-11-09 06:53:03 neologixset files: + 3bf73dcd0b42.diff I guess that you clicked on [Create Patch]. This button doesn't work, it generates a patch with unrelated changes. Maybe I did something wrong on features/tracemalloc repository. Here

[issue19533] Unloading docstrings from memory if -OO is given

R. David Murray added the comment: So the question is, if there is no longer a reference to the docstring, why isn't it garbage collected? (I tested adding a gc.collect(), and it didn't make any difference.) -- nosy: +r.david.murray ___ Python trac

[issue19532] compileall -f doesn't force to write bytecode files

R. David Murray added the comment: test_compileall has fairly extensive tests of the command line behavior, added when we refactored from optparse to argparse. So a test should be added for this case. -- nosy: +r.david.murray ___ Python tracker

[issue19499] "import this" is cached in sys.modules

Antoine Pitrou added the comment: Terry is right here. The "this" module doesn't seem to have been thought as an educational tool in the first place. -- nosy: +pitrou ___ Python tracker ___

[issue19537] Fix misalignment in fastsearch_memchr_1char

Changes by Serhiy Storchaka : -- nosy: +serhiy.storchaka stage: -> patch review versions: +Python 3.4 ___ Python tracker ___ ___ Pyth

[issue19536] MatchObject should offer __getitem__()

Serhiy Storchaka added the comment: We discussed this recently on #python-dev, and I don't think that it's worth to add indexing to match object. It will be confused that len(match) != len(match.groups()). I don't know any use case for indexing, it doesn't add anything new except yet one way t

[issue19537] Fix misalignment in fastsearch_memchr_1char

New submission from Andreas Schwab: sizeof(foo) is never a good approximation for the alignment of foo -- components: Interpreter Core files: xx messages: 202487 nosy: schwab priority: normal severity: normal status: open title: Fix misalignment in fastsearch_memchr_1char type: behavior

[issue19533] Unloading docstrings from memory if -OO is given

Sworddragon added the comment: > Do realize this is a one-time memory cost, though, because next execution > will load from the .pyo and thus will never load the docstring into memory. Except in 2 cases: - The bytecode was previously generated with -O. - The bytecode couldn't be written (for e

[issue19533] Unloading docstrings from memory if -OO is given

Brett Cannon added the comment: Do realize this is a one-time memory cost, though, because next execution will load from the .pyo and thus will never load the docstring into memory. If you pre-compile all bytecode with -OO this will never even occur. -- nosy: +brett.cannon ___

[issue19531] Loading -OO bytecode files if -O was requested can lead to problems

Brett Cannon added the comment: This is a known problem and has been brought up over the years. Discussions have typically revolved around expanding the .pyc format to encode what optimizations were used so if the interpreter was using different optimizations it would not use the bytecode. --

[issue18864] Implementation for PEP 451 (importlib.machinery.ModuleSpec)

Brett Cannon added the comment: I should clarify why I want a clarification on step 1. On Friday my current plan (barring other bugs I need to squash for b1) is to just start working on the pep-451 repo and I want a TODO list to follow in this issue so I don't have to waste time trying to figu

[issue18864] Implementation for PEP 451 (importlib.machinery.ModuleSpec)

Brett Cannon added the comment: I don't quite know what you mean by "current functional changes in the clone". Is this changes to import to use exec_module() and such? Just a guess since step 3 suggests there are no loaders implementing the new API currently. As for the tests, I'm hoping that

[issue19536] MatchObject should offer __getitem__()

Ezio Melotti added the comment: This is something that the regex module already has, and since it is/was supposed to replace the re module in stdlib, I've been holding off to add to re for a long time. We also discussed this recently on #python-dev, and I think it's OK to add it, as long as i

[issue19536] MatchObject should offer __getitem__()

Changes by Brandon Rhodes : -- versions: +Python 3.4 -Python 3.5 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue19536] MatchObject should offer __getitem__()

New submission from Brandon Rhodes: Regular expression re.MatchObject objects are sequences. They contain at least one “group” string, possibly more, which are integer-indexed starting at zero. Today, groups can be accessed in one of two ways. (1) You can call the method match.group(N). (2) You

[issue19532] compileall -f doesn't force to write bytecode files

Vajrasky Kok added the comment: Attached the patch to fix the problem. I did not modify the unit test because the bug was located in the __main__ part of Lib/compileall. -- keywords: +patch nosy: +vajrasky Added file: http://bugs.python.org/file32553/compileall_force.patch

[issue19504] Change "customise" to "customize".

Changes by Tshepang Lekhonkhobe : -- nosy: +tshepang ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://ma

[issue11849] glibc allocator doesn't release all free()ed memory

STINNER Victor added the comment: Extract of the "workaround" section: "You could also run your Python jobs using Jython, which uses the Java JVM and does not exhibit this behavior. Likewise, you could upgrade to Python 3.3 ," Which contains a link to this issu

[issue19535] Test failures with -OO

Serhiy Storchaka added the comment: Failure of test_pkg is sporadic. $ ./python -OO -m test.regrtest test_pkg [1/1] test_pkg test test_pkg failed -- Traceback (most recent call last): File "/home/serhiy/py/cpython/Lib/test/test_pkg.py", line 259, in test_7 '__name__', '__package__', '__pat

[issue19535] Test failures with -OO

New submission from Serhiy Storchaka: $ ./python -OO -m test.regrtest test_docxmlrpc test_functools test_inspect test_pkg [1/4] test_docxmlrpc test test_docxmlrpc failed -- Traceback (most recent call last): File "/home/serhiy/py/cpython/Lib/test/test_docxmlrpc.py", line 210, in test_annotati

[issue19533] Unloading docstrings from memory if -OO is given

Changes by Serhiy Storchaka : -- versions: +Python 3.3 -Python 2.7 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscrib

[issue19531] Loading -OO bytecode files if -O was requested can lead to problems

Serhiy Storchaka added the comment: Some tests fail when ran with -OO and then with -O. Short example (there are more examples): $ rm -rf Lib/test/__pycache__ $ ./python -OO -m test.regrtest test_property [1/1] test_property 1 test OK. $ ./python -O -m test.regrtest test_property [1/1] test_pro

[issue19533] Unloading docstrings from memory if -OO is given

Changes by Serhiy Storchaka : -- Removed message: http://bugs.python.org/msg202474 ___ Python tracker ___ ___ Python-bugs-list mailing

[issue19533] Unloading docstrings from memory if -OO is given

Changes by Serhiy Storchaka : -- components: -Tests type: behavior -> enhancement versions: -Python 3.3, Python 3.4 ___ Python tracker ___ _

[issue19533] Unloading docstrings from memory if -OO is given

Serhiy Storchaka added the comment: Some tests fail when ran with -OO and then with -O. Short example (there are more examples): $ rm -rf Lib/test/__pycache__ $ ./python -OO -m test.regrtest test_property [1/1] test_property 1 test OK. $ ./python -O -m test.regrtest test_property [1/1] test_pro

[issue18907] urllib2.open FTP open times out at 20 secs despite timeout parameter

Changes by Charles-François Natali : -- resolution: -> wont fix stage: -> committed/rejected status: open -> closed ___ Python tracker ___ _

[issue19534] normalize() in locale.py fails for sr_RS.UTF-8@latin

Serhiy Storchaka added the comment: Seems this is a duplicate of issue5815. -- nosy: +serhiy.storchaka superseder: -> locale.getdefaultlocale() missing corner case ___ Python tracker __

[issue19534] normalize() in locale.py fails for sr_RS.UTF-8@latin

Mike FABIAN added the comment: The patch http://bugs.python.org/file32552/0001-Issue-19534-fix-normalize-in-locale.py-to-make-it-wo.patch is against the current HEAD of the 2.7 branch, but Python 3.3 has exactly the same problem, the same patch fixes it for python 3.3 as well. --

[issue19534] normalize() in locale.py fails for sr_RS.UTF-8@latin

Mike FABIAN added the comment: I think the patch I attach here is a better fix than the patch in http://bugs.python.org/msg202469 because it makes the normalize() function behave more logical overall, with this patch, my test program prints: mfabian@ari:/local/mfabian/src/cpython (2.7-mike %) $

[issue19534] normalize() in locale.py fails for sr_RS.UTF-8@latin

Mike FABIAN added the comment: in locale.py, the comment above “locale_alias = {” says: # Note that the normalize() function which uses this tables # removes '_' and '-' characters from the encoding part of the # locale name before doing the lookup. This saves a lot of # space in the table. But

[issue19534] normalize() in locale.py fails for sr_RS.UTF-8@latin

Mike FABIAN added the comment: A simple fix for that problem could look like this: mfabian@ari:~ $ diff -u /usr/lib64/python2.7/locale.py.orig /usr/lib64/python2.7/locale.py --- /usr/lib64/python2.7/locale.py.orig 2013-11-09 09:08:24.807331535 +0100 +++ /usr/lib64/python2.7/locale.py 2013-1

[issue19534] normalize() in locale.py fails for sr_RS.UTF-8@latin

Mike FABIAN added the comment: The problem turns out to be caused by a problem in normalizing the locale name, see the output of this test program: mfabian@ari:~ $ cat ~/tmp/mike-test.py #!/usr/bin/python2 import sys import os import locale import encodings import encodings.aliases test_local

[issue19534] normalize() in locale.py fails for sr_RS.UTF-8@latin

New submission from Mike FABIAN: Originally reported here: https://bugzilla.redhat.com/show_bug.cgi?id=1024667 I found that Serbian translations in Latin do not work when the locale name is written as sr_RS.UTF-8@latin (one gets the cyrillic translations instead), but they *do* work when the l

[issue19532] compileall -f doesn't force to write bytecode files

Ned Deily added the comment: Looking at the compileall module, it appears that -f and options other than -b have never (or, at least, for a long time, not) been supported when directories or files are not supplied and it defaults to . Note the call in main() to compile_path vs those to compil