[issue9767] Failures in json doc examples

Georg Brandl added the comment: FWIW if something is fixed, it should be the json output. However, I can imagine (without looking at the code) that this would mean a lot of special casing. -- ___ Python tracker

[issue9775] Multiprocessing, logging and atexit play not well together

Georg Brandl added the comment: I'll sort this out with Armin. -- nosy: +georg.brandl ___ Python tracker ___ ___ Python-bugs-list mail

[issue9775] Multiprocessing, logging and atexit play not well together

Changes by Georg Brandl : -- assignee: -> georg.brandl priority: normal -> high versions: +Python 3.2 -Python 2.6 ___ Python tracker ___ _

[issue9662] ctypes not building under OS X because of ffi_closure_free not being defined early enough

Georg Brandl added the comment: I don't think this should block 3.2a2. +1 for supporting LLVM in general. BTW, why doesn't it build because of warnings? -- nosy: +georg.brandl priority: release blocker -> deferred blocker ___ Python tracker

[issue9779] argparse.ArgumentParser not support unicode in print help

New submission from gkraser : argparse.ArgumentParser not support unicode in print help. Example: # -*- coding: utf-8 -*- import argparse import unittest class Test1(unittest.TestCase): def test_unicode_desc(self): h = u'Rus Рус' # unicode print h # ok

[issue9662] ctypes not building under OS X because of ffi_closure_free not being defined early enough

Ned Deily added the comment: It's not just LLVM. Building a standard OS X installer on OS X 10.5 or 10.6 (gcc-4.0, 10.4u SDK, i386/ppc, deployment target=10.3), _ctypes fails: *** WARNING: renaming "_ctypes" since importing it failed: dlopen(build/lib.macosx-10.3-fat-3.2/_ctypes.so, 2): Symb

[issue9662] ctypes not building under OS X because of ffi_closure_free not being defined early enough

Ned Deily added the comment: It's not just LLVM. Building a standard OS X installer on OS X 10.5 (gcc-4.0, 10.4u SDK, i386/ppc, deployment target=10.3) or 10.6 (gcc-4.2, 10.6 SDK, i386/x86_64, dept target 10.6), _ctypes fails: *** WARNING: renaming "_ctypes" since importing it failed: dlope

[issue9662] ctypes not building under OS X because of ffi_closure_free not being defined early enough

Changes by Ned Deily : -- Removed message: http://bugs.python.org/msg115631 ___ Python tracker ___ ___ Python-bugs-list mailing list Un

[issue9662] ctypes not building under OS X because of ffi_closure_free not being defined early enough

Georg Brandl added the comment: OK. Assigning to Ronald for now; he'll have to deal with it when building the binaries anyway. -- assignee: theller -> ronaldoussoren nosy: +ronaldoussoren ___ Python tracker _

[issue9437] can't build extensions with non-default ldflags (e.g. -m32)

Georg Brandl added the comment: Patch looks like it at least can't make things worse to me. linker_exe should probably also get LDFLAGS (but not LDSHARED). -- nosy: +georg.brandl ___ Python tracker __

[issue9116] test_capi.test_no_FatalError_infinite_loop crash on Windows

Georg Brandl added the comment: Once again, this is not important enough block 3.2a2. -- priority: release blocker -> deferred blocker ___ Python tracker ___

[issue8959] WINFUNCTYPE wrapped ctypes callbacks not functioning correctly in Python 2.7

Georg Brandl added the comment: Deferring for 3.2a2. -- priority: release blocker -> deferred blocker ___ Python tracker ___ ___ Pytho

[issue8611] Python3 doesn't support locale different than utf8 and an non-ASCII path (POSIX)

Georg Brandl added the comment: The Unicode import system won't be put in place before 3.2a2, deferring. -- priority: release blocker -> deferred blocker ___ Python tracker ___ _

[issue9437] can't build extensions with non-default ldflags (e.g. -m32)

Georg Brandl added the comment: It is however not important enough to block 3.2a2. -- priority: release blocker -> deferred blocker ___ Python tracker ___ ___

[issue9778] Make hash values the same width as a pointer (or Py_ssize_t)

Antoine Pitrou added the comment: > Correct. So it either needs to happen before 3.2, or wait until 4.0, Shouldn't there be a provision for ABI versioning? Or do you suggest bumping to the next major number (4.0, 5.0...) be done on the basis of ABI changes? -- ___

[issue9437] can't build extensions with non-default ldflags (e.g. -m32)

Łukasz Langa added the comment: This was broken in r83837 with a patch for issue #5504. -- nosy: +lukasz.langa ___ Python tracker ___

[issue9437] can't build extensions with non-default ldflags (e.g. -m32)

Changes by Łukasz Langa : -- Removed message: http://bugs.python.org/msg115640 ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue9662] ctypes not building under OS X because of ffi_closure_free not being defined early enough

Łukasz Langa added the comment: This was broken in r83837 with a patch for issue #5504. -- nosy: +lukasz.langa ___ Python tracker ___

[issue9437] can't build extensions with non-default ldflags (e.g. -m32)

Antoine Pitrou added the comment: Other patch, fixes all failures. -- Added file: http://bugs.python.org/file18758/m32-2.patch ___ Python tracker ___

[issue3978] ZipFileExt.read() can be incredibly slow; patch included

Antoine Pitrou added the comment: The patch has been outdated by other independent performance work on the zipfile module. In Python 3.2, the zipfile module is actually slightly faster than the "unzip" program: - first with the supplied "zeroes.zip" file: $ rm -f zeroes && time -p unzip -e z

[issue4941] Tell GCC Py_DECREF is unlikely to call the destructor

Antoine Pitrou added the comment: The whole approach doesn't seem to bear much fruit. I tried to apply again likely_decref.diff and got a 0% performance change on 3.2 (on a Core i3 processor). -- resolution: -> rejected status: open -> closed ___

[issue4194] default subprocess.Popen buffer size

Antoine Pitrou added the comment: The subprocess doc now has a note about buffering and performance issues, closing. -- resolution: -> out of date status: open -> closed ___ Python tracker ___

[issue1568] PATCH: Armin's attribute lookup caching for 3.0

Antoine Pitrou added the comment: Closing: Neil's algorithm is not different from what is already in 3.2, except for the additional type_attrcache_callback() which probably doesn't make a difference in normal workloads. -- resolution: accepted -> out of date status: open -> closed __

[issue5504] ctypes should work with systems where mmap can't be PROT_WRITE and PROT_EXEC

Ronald Oussoren added the comment: Fixing the alloc_closure error is easy enough: Index: ../setup.py === --- ../setup.py (revision 84528) +++ ../setup.py (working copy) @@ -1653,7 +1653,9 @@ '_ctypes/callbacks.

[issue5504] ctypes should work with systems where mmap can't be PROT_WRITE and PROT_EXEC

Łukasz Langa added the comment: Please find attached a "fix" for #9662. Some explanation is in order: - the Windows, Linux and OS X implementations of FFI included in the SVN are different in terms of maturity - Thomas originally when fixing #5504 used a bit of functionality regarding closur

[issue9662] ctypes not building under OS X because of ffi_closure_free not being defined early enough

Ronald Oussoren added the comment: I'm looking into this issue. One problem is that the version of libffi used on OSX is no longer in sync with the version that is used on other platforms. The version that is used on OSX does not have some of the symbols expected by ctypes, such as 'ffi_prep

[issue9662] ctypes not building under OS X because of ffi_closure_free not being defined early enough

Łukasz Langa added the comment: Ronald, please see #5504. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: ht

[issue1677872] Efficient reverse line iterator

Antoine Pitrou added the comment: Suggestions: - do it on BufferedReader, rather than TextIOWrapper: if you want full-speed scanning of log files, you probably want to open them in binary mode - rather than implementing a full-blown iterator, you can start with simple primitives: e.g. a meth

[issue5504] ctypes should work with systems where mmap can't be PROT_WRITE and PROT_EXEC

Ronald Oussoren added the comment: Łukasz' patch fixes the issue for me. As the patch only affects code-paths used on OSX (patches to the libffi version for OSX and an #ifdef that makes OSX use ffi_prep_closure instead of ffi_prep_closure_loc) I intend to commit the patch later today to be ab

[issue9662] ctypes not building under OS X because of ffi_closure_free not being defined early enough

Ronald Oussoren added the comment: Thanks! That patch fixes the issue for me and I will commit it later today. -- ___ Python tracker ___ _

[issue1677872] Efficient reverse line iterator

Changes by Guido van Rossum : -- nosy: -gvanrossum ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://ma

[issue5412] extend configparser to support mapping access(__*item__)

Changes by Łukasz Langa : Removed file: http://bugs.python.org/file18441/issue5412.diff ___ Python tracker ___ ___ Python-bugs-list mailing lis

[issue5412] extend configparser to support mapping access(__*item__)

Łukasz Langa added the comment: Patch updated to avoid fuzzes from other commits. -- Added file: http://bugs.python.org/file18760/issue5412.diff ___ Python tracker ___ __

[issue9778] Make hash values the same width as a pointer (or Py_ssize_t)

Changes by Case Van Horsen : -- nosy: +casevh ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python

[issue9739] Output of help(...) is wider than 80 characters

Case Van Horsen added the comment: I edited the doc string for math.modf since an indent of 8 spaces is used for the doc string with help(math). An indent of 4 spaces is used with help(math.modf). I've attached a new patch for just the math module that includes the return type as part of sig

[issue9778] Make hash values the same width as a pointer (or Py_ssize_t)

Martin v. Löwis added the comment: Am 05.09.2010 13:12, schrieb Antoine Pitrou: > > Antoine Pitrou added the comment: > >> Correct. So it either needs to happen before 3.2, or wait until 4.0, > > Shouldn't there be a provision for ABI versioning? There is certainly support for ABI versionin

[issue9778] Make hash values the same width as a pointer (or Py_ssize_t)

Georg Brandl added the comment: I would suggest making this change before the ABI freeze starts, then. -- ___ Python tracker ___ ___ P

[issue9747] os.getresgid() documentation mentions "user ids", not "group ids"

Georg Brandl added the comment: Thanks, fixed in r84530. -- nosy: +georg.brandl resolution: -> fixed status: open -> closed ___ Python tracker ___ __

[issue9776] Inconsistent spacing in fcntl.fcntl docstring

Georg Brandl added the comment: Thanks, applied in r84531. -- nosy: +georg.brandl resolution: -> fixed status: open -> closed ___ Python tracker ___

[issue9720] zipfile writes incorrect local file header for large files in zip64

Alan McIntyre added the comment: Thanks for the patch, Craig; I should have some time later today or tomorrow to do a review. Did you have a patch for the test suite(s) as well? If not, I can just make sure your test case is covered in test_zipfile64. -- ___

[issue9437] can't build extensions with non-default ldflags (e.g. -m32)

Éric Araujo added the comment: I agree with Georg: The patch seems not to make things worse, and if it makes the tests pass, I think it should be committed. Antoine, you decide if you want to commit it now or wait for Tarek’s review. -- ___ Python

[issue9437] can't build extensions with non-default ldflags (e.g. -m32)

Antoine Pitrou added the comment: > I agree with Georg: The patch seems not to make things worse, and if > it makes the tests pass, I think it should be committed. Antoine, you > decide if you want to commit it now or wait for Tarek’s review. Well, ideally, someone should have knowledge of what

[issue9437] can't build extensions with non-default ldflags (e.g. -m32)

Éric Araujo added the comment: I agree. This expert is not me, and my reply was only pragmatic. Martin: This is a bug about LDSHARED vs. LDFLAGS vs. PY_LDFLAGS vs. CONFIGURE_LDFLAGS. Could you maybe shed some light about the difference between these configure variables and review the small pa

[issue9217] 2to3 crashes with some doctests

Changes by Éric Araujo : -- stage: -> committed/rejected status: open -> closed ___ Python tracker ___ ___ Python-bugs-list mailing li

[issue9761] stale .pyc files aren't cleaned out

Changes by Éric Araujo : Removed file: http://bugs.python.org/file18734/unnamed ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubs

[issue9761] stale .pyc files aren't cleaned out

Changes by Éric Araujo : Removed file: http://bugs.python.org/file18735/unnamed ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubs

[issue9761] stale .pyc files aren't cleaned out

Éric Araujo added the comment: Can you reproduce the bug with a newer Python? 2.6 only gets security fixes now, bug fixes go into stable (2.7 and 3.1) and active (3.2) versions. (Minor remarks: Could you set up your email client not to send HTML email to the tracker? It creates unnamed files

[issue9761] stale .pyc files aren't cleaned out

Changes by Éric Araujo : -- versions: -Python 2.6 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.p

[issue6074] .pyc files created readonly if .py file is readonly, python won't overwrite

Changes by Éric Araujo : Removed file: http://bugs.python.org/file18739/unnamed ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubs

[issue6074] .pyc files created readonly if .py file is readonly, python won't overwrite

Éric Araujo added the comment: Bug fixes go into 2.7 but not 2.6. See msg115664. -- nosy: +eric.araujo versions: -Python 2.6 ___ Python tracker ___ _

[issue9662] ctypes not building under OS X because of ffi_closure_free not being defined early enough

Ronald Oussoren added the comment: I've committed the patch in #5504 in r84535 (3.2) and that fixes this issue. The same problem affects 2.7, I'm currently running the testsuite with the backport of this commit. -- resolution: -> fixed stage: needs patch -> committed/rejected versio

[issue8420] Objects/setobject.c contains unsafe code

Éric Araujo added the comment: I’m doing the backport, I’ll assign back to Raymond when the patch is ready. -- assignee: rhettinger -> eric.araujo nosy: +eric.araujo versions: -Python 2.6 ___ Python tracker __

[issue9630] Reencode filenames when setting the filesystem encoding

STINNER Victor added the comment: > Do we really want to support this kind of configuration? There is also a problem is the directory name is b'py3k\xe9': at startup (utf-8 encoding), the name is decoded to 'py3k\udce9'. When the locale encoding is set to iso-8859-1: the name should be reenco

[issue8372] socket: Buffer overrun while reading unterminated AF_UNIX addresses

David Watson added the comment: > > baikie: why did the test pass for you? > > The test passes (I assume) if linux-pass-unterminated.diff is applied. The > latter patch is only meant to exhibit the issue, though, not to be checked in. No, I meant for linux-pass-unterminated.diff to be checked

[issue9748] .inputrc magic-space breaks interactive mode

Amaury Forgeot d'Arc added the comment: I didn't know what "magic space" is. But a quick google search shows that it is specific to Bash. in http://www.ukuug.org/events/linux2003/papers/bash_tips/#S16 """ There are other readline-based programs without this feature, so make it only apply in B

[issue9756] Crash with custom __getattribute__

Meador Inge added the comment: > To fix the segfault, I suppose that we use a more strict validation on > the input type. Eg. Use PyUnicode_Check() instead of > PyObject_IsInstance()? Where would the more strict validation take place? This problem is not unique to Unicode objects: motherbr

[issue9720] zipfile writes incorrect local file header for large files in zip64

Craig de Stigter added the comment: Hi, sorry no I haven't had time to add a real test for this -- ___ Python tracker ___ ___ Python-b

[issue8372] socket: Buffer overrun while reading unterminated AF_UNIX addresses

Martin v. Löwis added the comment: baikie, coming back to your original message: what precisely makes you believe that sun_path does not need to be null-terminated on Linux? -- ___ Python tracker _

[issue4388] test_cmd_line fails on MacOS X

Skip Montanaro added the comment: Any progress on this? Is the best thing to just set LANG? -- nosy: +skip.montanaro ___ Python tracker ___ _

[issue9748] .inputrc magic-space breaks interactive mode

stephenk added the comment: Didn't know about the inputrc conditional; that works. I verified that magic-space (without the conditional) also interferes with mysql, so this seems like less of an oversight on the side of python and more of a bash-user-beware situation. Anyway, thanks for the

[issue6656] locale.format_string fails on escaped percentage

R. David Murray added the comment: Well, I let this bake so long I missed 2.6, but I've backported the fix to 3.1 in r84543. -- status: open -> closed ___ Python tracker ___ ___

[issue1467619] Header.decode_header eats up spaces

Changes by R. David Murray : -- priority: high -> normal ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http

[issue9293] Unsupported IO operations should raise UnsupportedOperation

Antoine Pitrou added the comment: Committed in r84544. -- resolution: -> fixed status: open -> closed ___ Python tracker ___ ___ Pyth

[issue9780] fill character cannot be '{'

New submission from Florent Xicluna : According to the documentation: "The fill character can be any character other than ‘}’ (which signifies the end of the field)." http://docs.python.org/dev/library/string.html#format-specification-mini-language However the format() builtin accepts both '{'

[issue9780] fill character cannot be '{'

Éric Araujo added the comment: Looks more like a behavior bug than a doc bug to me. Does the doc comply with the PEP? -- nosy: +eric.araujo, eric.smith ___ Python tracker ___ __

[issue1343] XMLGenerator: nice elements

Éric Araujo added the comment: Patch looks good to me. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http:

[issue1222585] C++ compilation support for distutils

Changes by Éric Araujo : -- nosy: +eric.araujo versions: +Python 2.5, Python 2.6, Python 3.1 -Python 3.3 ___ Python tracker ___ ___

[issue9780] fill character cannot be '{'

Florent Xicluna added the comment: The PEP 3101 does not prohibit any character for the 'fill' argument. Another example which just works: >>> '{:{fill}^6}'.format(42, fill='{') '{{42{{' >>> '{:{fill}^6}'.format(42, fill='}') '}}42}}' I don't care if '{' and '}' are prohibited when using si

[issue8524] SSL sockets do not retain the parent socket's attributes

Éric Araujo added the comment: In case someone lands here from the 3.2 what’s new document: The method has been renamed to detach. -- nosy: +eric.araujo ___ Python tracker ___ _

[issue1552880] [Python2] Use utf-8 in the import machinery on Windows to support unicode paths

Kristján Valur Jónsson added the comment: Well, it was, originally, but it met with so little interest that I couldn't be bothered to polish it to inclusion standards. Anyway, there was the incompatibility problem of what to do with the __file__ attribute, and the fact that the patch was Win

[issue7418] hashlib : the names of the different hash algorithms

Éric Araujo added the comment: Could the module also grow an attribute listing all available algos, or non-guaranteed algos? (Please tell me if I should open a new report.) -- nosy: +eric.araujo ___ Python tracker

[issue9780] fill character cannot be '{'

Éric Araujo added the comment: Thanks for clarifying. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http:/

[issue1552880] [Python2] Use utf-8 in the import machinery on Windows to support unicode paths

Éric Araujo added the comment: There is no such place that I know of, sorry. -- stage: -> committed/rejected ___ Python tracker ___ __

[issue1466065] base64 module ignores non-alphabet characters

R. David Murray added the comment: Comments on patch: 1) if I'm reading the RFC correctly, to be validating strictly in compliance with the RFC \r and \n should also raise an error. Do you agree? 2) We've pretty much dropped the convention of adding history notes to the file itself. 3) The

[issue9733] Can't iterate over multiprocessing.managers.DictProxy

Changes by R. David Murray : -- nosy: +asksol ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python

[issue7418] hashlib : the names of the different hash algorithms

Gregory P. Smith added the comment: Sounds like a good idea. frozensets for both. -- ___ Python tracker ___ ___ Python-bugs-list mail

[issue7418] hashlib : the names of the different hash algorithms

Éric Araujo added the comment: Thanks for the reply. Reopening. I cannot propose a patch since I don’t know how to introspect OpenSSL (or how to write C, for that matter). -- stage: -> needs patch status: closed -> open ___ Python tracker

[issue4769] b64decode should accept strings or bytes

R. David Murray added the comment: After thinking about it, I'm inclined to reject this and say that quopri should be fixed to reject string input to decode. On python-dev Guido opined that a kind of polymorphism in the stdlib was good (bytes in --> bytes out, string in --> string out). str

[issue9741] msgfmt.py generates invalid mo because msgfmt.make() does not clear dictionary

Changes by R. David Murray : -- nosy: +loewis ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python

[issue1552880] [Python2] Use utf-8 in the import machinery on Windows to support unicode paths

Martin v. Löwis added the comment: Having patches in the tracker is fine to me. Even if the patch is closed, it's still available. Of course, there are many ways to publish code on the net: you could post the patch to Rietveld, to the Python wiki, or publish an entire clone to bitbucket. ---

[issue9780] fill character cannot be '{'

Georg Brandl added the comment: Fixed docs in r84553. (That builtin format() supports this is no surprise, and has no influence on the validity in format strings.) -- nosy: +georg.brandl resolution: -> fixed status: open -> closed ___ Python track