[issue12821] test_fcntl failed on OpenBSD 5.x

Charles-François Natali added the comment: Note that it's been fixed in default with the recent sys.platform refactoring: 26 if (sys.platform.startswith(('netbsd', 'freebsd', 'openbsd', 'bsdos')) 27 or sys.platform == 'darwin'): 28 if struct.calcsize('l') == 8:

[issue12821] test_fcntl failed on OpenBSD 5.x

Remi Pointel added the comment: Thanks a lot, I prefer to use sys.platform.startswith too. Remi. -- ___ Python tracker ___ ___ Pytho

[issue6560] socket sendmsg(), recvmsg() methods

Charles-François Natali added the comment: > However, in doing this, I noticed that these methods will, at best, work > during the time between connection and the socket going secure and were not > added to the list of methods that the SSL is documented as exposing. Perhaps > we should just d

[issue12409] Moving "Documenting Python" to Devguide

Georg Brandl added the comment: +1, and as Eric says, we can do it without changing versions of Sphinx used. -- ___ Python tracker ___ __

[issue12822] NewGIL should use CLOCK_MONOTONIC if possible.

New submission from INADA Naoki : Using CLOCK_MONOTONIC is better than CLOCK_REALTIME (default) for GIL because settimeofday() may break the pthread_cond_timedwait(). Attached patch uses CLOCK_MONOTONIC and clock_gettime. But I don't know how to write appropriate configure script. "-lrt" is also

[issue12678] test_packaging and test_distutils failures under Windows

Éric Araujo added the comment: higery: Would you have a bit of free time to help use here? -- nosy: +higery ___ Python tracker ___ __

[issue12822] NewGIL should use CLOCK_MONOTONIC if possible.

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

[issue12822] NewGIL should use CLOCK_MONOTONIC if possible.

STINNER Victor added the comment: See also #10278. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://m

[issue10278] add time.wallclock() method

STINNER Victor added the comment: See also #12822. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://m

[issue12808] Coverage of codecs.py

Marc-Andre Lemburg added the comment: Tennessee Leeuwenburg wrote: > > Tennessee Leeuwenburg added the comment: > > Thanks for the review. Here is a patch incorporating the two comments being > to move some comments. Hmm, the documentation patch doesn't appear to have changed. Did you uploa

[issue12808] Coverage of codecs.py

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

[issue12823] Broken link in "SSL wrapper for socket objects" document

New submission from Roger Li : In http://docs.python.org/release/3.1.3/library/ssl.html You will find a link at the bottom named "Introducing SSL and Certificates using OpenSSL", it's a broken link. The server may be down or not exist, the only version I can find is http://web.archive.org/web/

[issue12824] Make the write_file() helper function in test_shutil return the file name it wrote to

New submission from Hynek Schlawack : test_shutil contains a handy helper function called write_file(filename. contents). If *filename* is a tuple, os.path.join() is used to concatenate it to a path. To be really useful, the resulting file name should be returned, so the user can work with it

[issue12721] Chaotic use of helper functions in test_shutil for reading and writing files

Hynek Schlawack added the comment: Done in Issue12824. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http

[issue12825] Missing and incorrect link to a command line option.

New submission from Kyle Simpson : The documentation for the runpy module has a link to the -m command line option. In version 2.7.2 of the docs, the link doesn't exist. http://docs.python.org/release/2.7/library/runpy.html http://docs.python.org/release/2.7.2/library/runpy.html If you run

[issue12825] Missing and incorrect link to a command line option.

Éric Araujo added the comment: It’s weird that the docs under /release/2.7 has the link but not the one under /. -- nosy: +eric.araujo, georg.brandl ___ Python tracker ___

[issue12826] module _socket failed to build on OpenBSD

New submission from Remi Pointel : Hello, I try to build Python 3.3 on OpenBSD, and it failed to build these modules: _socket (so _ssl too). Errors are: /home/remi/dev/cpython_test/Modules/socketmodule.c: In function 'sock_recvmsg': /home/remi/dev/cpython_test/Modules/socketmodule.c:2935: error

[issue12826] module _socket failed to build on OpenBSD

Changes by Remi Pointel : Added file: http://bugs.python.org/file23016/socketmodule_build_error_openbsd.log ___ Python tracker ___ ___ Python

[issue12826] module _socket failed to build on OpenBSD

Roundup Robot added the comment: New changeset b4b84e87dc6b by Victor Stinner in branch 'default': Close #12826: fix socketmodule.c for OpenBSD, include sys/uio.h http://hg.python.org/cpython/rev/b4b84e87dc6b -- nosy: +python-dev resolution: -> fixed stage: -> committed/rejected statu

[issue12826] module _socket failed to build on OpenBSD

STINNER Victor added the comment: It's surprising that it works on FreeBSD but not on OpenBSD. Thanks for your patch. -- nosy: +haypo ___ Python tracker ___ ___

[issue12824] Make the write_file() helper function in test_shutil return the file name it wrote to

Éric Araujo added the comment: Hm, I don’t think the patch makes the test easier to read or maintain. As I wrote in the commit message for #12721: > For simple open then read/write calls, I have left the usual idiom > (with open + read/write), as it is short and readable enough. In the curre

[issue12827] OS-specific location in Lib/tempfile.py for OpenBSD

New submission from Remi Pointel : Hello, /usr/tmp is not (used) on OpenBSD. We have specific patch to do this, but I prefer to have this modification upstream. 2.5: http://www.openbsd.org/cgi-bin/cvsweb/ports/lang/python/2.5/patches/patch-Lib_tempfile_py 2.7: http://www.openbsd.org/cgi-bin

[issue6560] socket sendmsg(), recvmsg() methods

Antoine Pitrou added the comment: > However, in doing this, I noticed that these methods will, at best, > work during the time between connection and the socket going secure > and were not added to the list of methods that the SSL is documented > as exposing. Perhaps we should just ditch them en

[issue12678] test_packaging and test_distutils failures under Windows

higery added the comment: >>higery: Would you have a bit of free time to help use here? Certainly yes. I have run the test_packaging.py, the main error message is about "ValueError: path is on mount 'c:', start on mount 'D:'". One sample is: ERROR: test_uses (packaging.tests.test_database.Te

[issue12678] test_packaging and test_distutils failures under Windows

higery added the comment: For test_distutils.py, there is not an 'os.link()' function on Windows platform, so all the tests using this function will report error. -- ___ Python tracker ___

[issue12678] test_packaging and test_distutils failures under Windows

Éric Araujo added the comment: Thanks! There’s a patch on #12785 that may fix the test_database bug. Here we try to see the distutils test_sdist problem on 2.7. -- ___ Python tracker ___

[issue12827] OS-specific location in Lib/tempfile.py for OpenBSD

Charles-François Natali added the comment: > /usr/tmp is not (used) on OpenBSD. How is that a problem? Those are just possible temporary directories to try, so if it doesn't exist, it won't be used (typically ENOENT will be catched when opening a tmpfile). Also, since it's listed last, that's

[issue6560] socket sendmsg(), recvmsg() methods

Nick Coghlan added the comment: That's the part I'm questioning though. I'm not clear why you'd ever do that instead of doing everything on the original socket before invoking ssl.wrap_socket. What I missed on the original patch before committing it (mea culpa) is that the SSL part is neithe

[issue12827] OS-specific location in Lib/tempfile.py for OpenBSD

STINNER Victor added the comment: Because it's not exactly a bug, can you only apply the patch to Python 3.3? -- nosy: +haypo ___ Python tracker ___

[issue6484] No unit test for mailcap module

Nick Coghlan added the comment: The buildbots are reporting a test failure on Windows: == FAIL: test_listmailcapfiles (test.test_mailcap.HelperFunctionTest) --

[issue6560] socket sendmsg(), recvmsg() methods

Antoine Pitrou added the comment: > That's the part I'm questioning though. I'm not clear why you'd ever do > that instead of doing everything on the original socket before invoking > ssl.wrap_socket. > > What I missed on the original patch before committing it (mea culpa) is > that the SSL

[issue12827] OS-specific location in Lib/tempfile.py for OpenBSD

STINNER Victor added the comment: > can you only apply the patch ... Hum, I mean can *we* only apply ... -- ___ Python tracker ___ _

[issue6560] socket sendmsg(), recvmsg() methods

Roundup Robot added the comment: New changeset fd10d042b41d by Nick Coghlan in branch 'default': Remove the SSLSocket versions of sendmsg/recvmsg due to lack of proper tests and documentation in conjunction with lack of any known use cases (see issue #6560 for details) http://hg.python.org/cpy

[issue6560] socket sendmsg(), recvmsg() methods

Nick Coghlan added the comment: As you can see, I just pushed a change that removed the new methods from SSLSocket objects. If anyone wants to step up with a valid use case (not already covered by wrap_socket), preferably with a patch to add them back that includes proper tests and documentat

[issue6560] socket sendmsg(), recvmsg() methods

Nick Coghlan added the comment: Regarding the 'missing methods' aspect, the SSL docs are already pretty clear that SSLSocket objects don't expose the full socket API: http://docs.python.org/dev/library/ssl#ssl-sockets Those docs are actually what really got me started down the path of wonderi

[issue12817] test_multiprocessing: io.BytesIO() requires bytearray buffers

Stefan Krah added the comment: I've come to think that PyBUF_SIMPLE requests were really intended as a way of casting contiguous buffers with arbitrary formats to one-dimensional buffers of unsigned bytes. At least that is what Numpy does. Then test_multiprocessing would be correct. I've asked

[issue12817] test_multiprocessing: io.BytesIO() requires bytearray buffers

Antoine Pitrou added the comment: Please also see issue5231. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue12678] test_packaging and test_distutils failures under Windows

higery added the comment: >>Here we try to see the distutils test_sdist problem on 2.7. So sorry that there is not a developed cpython 2.7 on my pc, and my currently installed Python2.7 has not installed the _msi module, so the running of the tests does not work well. -- ___

[issue5231] Change format of a memoryview

Stefan Krah added the comment: I think this would be useful and I'll try it out in features/pep-3118#memoryview. Syntax options that I'd prefer: a = array.array('i', [1,2,3]) m = memoryview(a, 'B') Or go all the way and make memoryview take any flag: a = array.array('i', [1,2,3]) m = memor

[issue5231] Change format of a memoryview

Antoine Pitrou added the comment: > Or go all the way and make memoryview take any flag: > > a = array.array('i', [1,2,3]) > m = memoryview(a, getbuf=PyBUF_SIMPLE) This is good for testing, but Python developers shouldn't have to know about the low-level flags. -- ___

[issue6560] socket sendmsg(), recvmsg() methods

Nick Coghlan added the comment: And the Windows buildbots are now happy (at least with respect to this change, anyway - they're still griping about a few other issues). I don't know if it's feasible to support these new APIs at the socket module level on Windows, but any patches along those l

[issue9993] shutil.move fails on symlink source

Jonathan Niehof added the comment: Éric: I think copying a relative symlink should also be relative, and that's the behaviour of this patch. That was the use case that tripped me up with the original behaviour of shutil.move: a relative symlink which was dangling in its original location, but

[issue6484] No unit test for mailcap module

Gregory Nofi added the comment: There's a bug for that test failure: #9923. I submitted a patch with it. Committing that should fix the failure. -- ___ Python tracker ___ __

[issue9993] shutil.move fails on symlink source

Changes by STINNER Victor : -- nosy: +haypo, pitrou ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.

[issue5231] Change format of a memoryview

Stefan Krah added the comment: Antoine Pitrou wrote: > > Or go all the way and make memoryview take any flag: > > > > a = array.array('i', [1,2,3]) > > m = memoryview(a, getbuf=PyBUF_SIMPLE) > > This is good for testing, but Python developers shouldn't have to know > about the low-level flags

[issue11816] Refactor the dis module to provide better building blocks for bytecode analysis

Raymond Hettinger added the comment: Nick, I still want to work on this one. -- ___ Python tracker ___ ___ Python-bugs-list mailing l

[issue6484] No unit test for mailcap module

Nick Coghlan added the comment: Ah, cheers - closing this one again. /me wanders off to meta-tracker to ask for a list of "dependency of" and "superseder of" issues in the issue header... -- status: open -> closed ___ Python tracker

[issue11816] Refactor the dis module to provide better building blocks for bytecode analysis

Changes by Eugene Toder : -- nosy: -eltoder ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python

[issue12602] Missing using docs cross-references

Changes by Kyle Simpson : -- nosy: +Kyle.Simpson ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.py

[issue9923] mailcap module may not work on non-POSIX platforms if MAILCAPS env variable is set

Changes by Nick Coghlan : -- assignee: -> ncoghlan nosy: +ncoghlan ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscrib

[issue9923] mailcap module may not work on non-POSIX platforms if MAILCAPS env variable is set

Changes by Nick Coghlan : -- stage: test needed -> patch review versions: +Python 3.2, Python 3.3 -Python 3.1 ___ Python tracker ___ __

[issue9993] shutil.move fails on symlink source

Antoine Pitrou added the comment: Looks good to me. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://m

[issue5231] Change format of a memoryview

Antoine Pitrou added the comment: > Hmm, indeed. How about: > > 1) memoryview(a, format='B') > > Shadows a builtin function; annoying syntax highlighting in current Vim. > > 2) memoryview(a, fmt='B') > > I'm fully expecting a comment about 'strpbrk' again, but I like it. :) I really prefer

[issue5231] Change format of a memoryview

Stefan Krah added the comment: Good, I'll use 'format'. I was mainly worried about the shadowing issue. -- ___ Python tracker ___ ___

[issue11816] Refactor the dis module to provide better building blocks for bytecode analysis

Changes by Nick Coghlan : Added file: http://bugs.python.org/file23018/7cead6bf5832.diff ___ Python tracker ___ ___ Python-bugs-list mailing l

[issue11816] Refactor the dis module to provide better building blocks for bytecode analysis

Changes by Nick Coghlan : Removed file: http://bugs.python.org/file23018/7cead6bf5832.diff ___ Python tracker ___ ___ Python-bugs-list mailing

[issue11816] Refactor the dis module to provide better building blocks for bytecode analysis

Nick Coghlan added the comment: The diff generator didn't work - I've uploaded the current patch manually to make it easier to review than it is in my bitbucket repo. I just noticed there's a missing element in the docs patch at the moment - to make testing easier, Ryan added a 'file' argumen

[issue5231] Change format of a memoryview

Stefan Krah added the comment: Rethinking a bit: Casting to arbitrary formats might go a bit far. Currently, the combination (format=NULL, shape=NULL) can serve as a warning "This buffer has been cast to unsigned bytes". If we allow casts from bytes to int32, we'll have (format="i", shape=x) a

[issue5231] Change format of a memoryview

Nick Coghlan added the comment: Casting to a flat 1-D array of bytes is reasonable (it's essentially saying 'look, just give me the raw data, it's on my own head if I stuff up the formatting'). However, requiring an explicit two-step process for any other casting (i.e. take a 1-D view, then

[issue5231] Change format of a memoryview

Antoine Pitrou added the comment: > However, requiring an explicit two-step process for any other casting > (i.e. take a 1-D view, then a shaped view of that flat 1-D view) also > sounds reasonable. > > So I agree with Victor that 1-D bytes -> any shape/format and any > shape/format -> 1-D byte

[issue12827] OS-specific location in Lib/tempfile.py for OpenBSD

Charles-François Natali added the comment: > Because it's not exactly a bug, can you only apply the patch to Python 3.3? Well, we could, but: - it doesn't fix a bug - it doesn't bring any obvious benefit (performance, security, etc) - it introduces an OS-specific case for no reason I'm open to

[issue11657] multiprocessing_{send,recv}fd fail with fds > 256

Antoine Pitrou added the comment: > For 3.3, it may be relevant that send/recvmsg are now available via > the socket API (see #6560) I think sendfds/recvfds helper methods could be added to the socket type, so that programmers don't have to get the incantations right by themselves (note the

[issue11657] multiprocessing_{send,recv}fd fail with fds > 256

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

[issue12827] OS-specific location in Lib/tempfile.py for OpenBSD

Charles-François Natali added the comment: > We can keep this patch in our tree, I understand your position. I could be missing something, but why do you have this patch in the first place? If it turns out to be useful, then it's of course better to include it upstream, I just don't see what t

[issue12827] OS-specific location in Lib/tempfile.py for OpenBSD

Remi Pointel added the comment: I was reporting this because I thought it was better to include this upstream. However, I understand if you don't want to include this specific case. We can keep this patch in our tree, I understand your position. --

[issue11657] multiprocessing_{send,recv}fd fail with fds > 256

Antoine Pitrou added the comment: Now that I think of it, it would be nice to add some simple tests for recvfd and sendfd in test_multiprocessing. (also, when os.dup2() is available, you can easily generate an arbitrary big file descriptor) -- ___

[issue12827] OS-specific location in Lib/tempfile.py for OpenBSD

Remi Pointel added the comment: > I could be missing something, but why do you have this patch in the first > place? I'm recently working on porting Python for OpenBSD, and this patch exists since python2.5 (since 4 years in our tree). So I don't have all responses, but I think this issue co

[issue12827] OS-specific location in Lib/tempfile.py for OpenBSD

Charles-François Natali added the comment: > it seems that this patch could be safely removed from our port tree. Alright, I'm closing then. > Thanks for all information. And thanks for your help and bug reports concerning OpenBSD-specific issues! -- resolution: -> rejected stage:

[issue5231] Change format of a memoryview

Stefan Krah added the comment: Nick Coghlan wrote: > So I agree with Victor that 1-D bytes -> any shape/format and any > shape/format -> 1-D bytes should be allowed, but I think we should > hold off on allowing arbitrary transformations in a single step. 1-D bytes -> any shape/format would wor

[issue12821] test_fcntl failed on OpenBSD 5.x

Roundup Robot added the comment: New changeset f1f1d9f4b14e by Charles-François Natali in branch '2.7': Issue #12821: Fix test_fcntl failures on OpenBSD 5. http://hg.python.org/cpython/rev/f1f1d9f4b14e -- nosy: +python-dev ___ Python tracker

[issue12821] test_fcntl failed on OpenBSD 5.x

Roundup Robot added the comment: New changeset 9157a9e77740 by Charles-François Natali in branch '3.2': Issue #12821: Fix test_fcntl failures on OpenBSD 5. http://hg.python.org/cpython/rev/9157a9e77740 -- ___ Python tracker

[issue12821] test_fcntl failed on OpenBSD 5.x

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

[issue12828] xml.dom.minicompat is not documented

New submission from Sandro Tosi : There's no documentation for xml.dom.minicompat - it's a public module and it should have (even a brief) doc. -- assignee: docs@python components: Documentation messages: 142845 nosy: docs@python, sandro.tosi priority: normal severity: normal status: op

[issue12821] test_fcntl failed on OpenBSD 5.x

Charles-François Natali added the comment: Committed to 3.2 and 2.7. Rémi, thanks for the report. -- resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed ___ Python tracker ___

[issue11657] multiprocessing_{send,recv}fd fail with fds > 256

Roundup Robot added the comment: New changeset 5b2f357989bb by Antoine Pitrou in branch '3.2': Issue #11657: Fix sending file descriptors over 255 over a multiprocessing Pipe. http://hg.python.org/cpython/rev/5b2f357989bb New changeset 4e7a4e098f38 by Antoine Pitrou in branch 'default': Issue #

[issue12828] xml.dom.minicompat is not documented

Éric Araujo added the comment: I’m not sure at all this module should be treated as anything but an internal detail. The docstring of xml.dom only mentions two submodules. -- components: +XML nosy: +eric.araujo ___ Python tracker

[issue11657] multiprocessing_{send,recv}fd fail with fds > 256

Roundup Robot added the comment: New changeset d4d9a3e71897 by Antoine Pitrou in branch '2.7': Issue #11657: Fix sending file descriptors over 255 over a multiprocessing Pipe. http://hg.python.org/cpython/rev/d4d9a3e71897 -- ___ Python tracker

[issue12828] xml.dom.minicompat is not documented

Sandro Tosi added the comment: > Éric Araujo added the comment: > > I’m not sure at all this module should be treated as anything but an internal > detail.  The docstring of xml.dom only mentions two submodules. If it's an implementation detail, then probably a small reference in the module d

[issue11657] multiprocessing_{send,recv}fd fail with fds > 256

Antoine Pitrou added the comment: I committed a patch with some tests. Thank you! -- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed ___ Python tracker __

[issue12802] Windows error code 267 should be mapped to ENOTDIR, not EINVAL

Antoine Pitrou added the comment: I would add it in test_exceptions, since errno mapping is ultimately used by exceptions. -- ___ Python tracker ___ ___

[issue12823] Broken link in "SSL wrapper for socket objects" document

Antoine Pitrou added the comment: I would simply remove the link, or point it to a similar document -- keywords: +easy nosy: +pitrou stage: -> needs patch versions: +Python 2.7, Python 3.2, Python 3.3 -Python 3.1 ___ Python tracker

[issue11564] pickle not 64-bit ready

Nadeem Vawda added the comment: I was playing around with pickling large Unicode strings in an interactive interpreter, and it seems that you have to have at least 4G chars (not bytes) to trigger the OverflowError. Consider the following snippet of code: out = dumps(data) del data r

[issue11564] pickle not 64-bit ready

Nadeem Vawda added the comment: Some more info: the first few bytes of the output for the _2G case are this: b'\x80\x03X\x00\x00\x00\x80aa' -- ___ Python tracker ___ __

[issue12822] NewGIL should use CLOCK_MONOTONIC if possible.

Charles-François Natali added the comment: > Using CLOCK_MONOTONIC is better than CLOCK_REALTIME (default) for GIL > because settimeofday() may break the pthread_cond_timedwait(). Indeed. A couple remarks: - regular locks and conditions variables exposed by the threading module suffer from the

[issue11564] pickle not 64-bit ready

Nadeem Vawda added the comment: > With data as (b"a" * _4G) the result is as expected: > > Traceback (most recent call last): > File "pickle-bigmem-test.py", line 5, in > out = dumps(data) > OverflowError: cannot serialize a string larger than 4GB > > But with (b"a" * _2G)

[issue12822] NewGIL should use CLOCK_MONOTONIC if possible.

Antoine Pitrou added the comment: The patch is ok on the principle, but we do need a check that CLOCK_MONOTONIC is supported at build time. -- nosy: +pitrou ___ Python tracker

[issue12822] NewGIL should use CLOCK_MONOTONIC if possible.

Marc-Andre Lemburg added the comment: Antoine Pitrou wrote: > > The patch is ok on the principle, but we do need a check that CLOCK_MONOTONIC > is supported at build time. I think we need both: a check at build time to avoid compiler errors and a check at runtime whether the deployment platfo

[issue12678] test_packaging and test_distutils failures under Windows

Roundup Robot added the comment: New changeset aa27461759f2 by Éric Araujo in branch 'default': Try to fix packaging tests using build_ext on Windows (#12678) http://hg.python.org/cpython/rev/aa27461759f2 -- ___ Python tracker

[issue12820] Tests for Lib/xml/dom/minicompat.py

Sandro Tosi added the comment: Hi, I just left a very light review on rietveld (the 'review' link below). I think in the next run you can add the tests for defproperty. Thanks for working on code coverage! -- nosy: +ezio.melotti, sandro.tosi stage: -> patch review __

[issue12678] test_packaging and test_distutils failures under Windows

Éric Araujo added the comment: Nadeem, please try this patch. -- Added file: http://bugs.python.org/file23020/windows-build_ext.diff ___ Python tracker ___ _

[issue12678] test_packaging and test_distutils failures under Windows

Nadeem Vawda added the comment: Testing on 3.2, the latest patch doesn't fix the test_record_extensions failure :/ It does change the traceback for the exception, though. Before: == ERROR: test_record_extensions (dis

[issue12678] test_packaging and test_distutils failures under Windows

Nadeem Vawda added the comment: Testing on 3.2, the latest patch doesn't fix the test_record_extensions failure :/ It does change the traceback for the exception, though. Before: == ERROR: test_record_extensions (dis

[issue12678] test_packaging and test_distutils failures under Windows

Changes by Nadeem Vawda : -- Removed message: http://bugs.python.org/msg142863 ___ Python tracker ___ ___ Python-bugs-list mailing lis

[issue12810] Remove check for negative unsigned value in socketmodule.c

Charles-François Natali added the comment: Thanks. I'll commit this patch tomorrow. I noticed you didn't indicate your full name: do you mind being listed in Misc/ACKS? -- components: +Extension Modules keywords: +easy nosy: +neologix stage: -> commit review type: -> behavior version

[issue12798] Update mimetypes documentation

Sandro Tosi added the comment: Here attached a new patch incorporating Ezio & Eric suggestions. -- Added file: http://bugs.python.org/file23021/mimetypes_doc_update-v2.patch ___ Python tracker

[issue12819] PEP 393 - Flexible Unicode String Representation

STINNER Victor added the comment: utf8_fast.patch: fast path for pure ASCII string in the UTF-8 decoder. -- Added file: http://bugs.python.org/file23022/utf8_fast.patch ___ Python tracker _

[issue12829] pyexpat segmentation fault caused by multiple calls to Parse()

New submission from David H. Gutteridge : I stumbled across this bug because of a misunderstanding I had about how the pyexpat module works. I'd inferred that a given instance could be reused to parse multiple files, which is apparently not supported. (There's already a documentation bug ope

[issue12678] test_packaging and test_distutils failures under Windows

Changes by Éric Araujo : Added file: http://bugs.python.org/file23024/windows-build_ext.diff ___ Python tracker ___ ___ Python-bugs-list maili

[issue12678] test_packaging and test_distutils failures under Windows

Changes by Éric Araujo : Removed file: http://bugs.python.org/file23020/windows-build_ext.diff ___ Python tracker ___ ___ Python-bugs-list mai

[issue12829] pyexpat segmentation fault caused by multiple calls to Parse()

David H. Gutteridge added the comment: I believe this may be an OS-specific bug somehow, albeit one that affects multiple OSes. I cannot duplicate the crash on NetBSD 5.1_STABLE/i386 with Python 2.6.7, or on OpenSuSE 11.3 with Python 2.6.5. (It's interesting that it doesn't crash on the old

  1   2   >