[issue9716] The inittab modules cannot be packages

Kay Hayen added the comment: Why did you remove Python2.7 from the versions list? Isn't this supposed to track the affected versions? (This is not the first time I encountered that.) I understand that you may not fix all bugs in 2.x, but is it already unsupported in the sense that its bugs ar

[issue8796] Deprecate codecs.open()

Marc-Andre Lemburg added the comment: We can reconsider this at some later time, when Python 2.x is not really used much anymore. -- resolution: -> postponed status: open -> closed ___ Python tracker

[issue9787] Release the TLS lock during allocations

Kristján Valur Jónsson added the comment: >The malloc >implementation just has no business looking at the thread state. Of course it does, if it you want to have any hope of instrumenting your python memory usage with detailed python runtime information. Your statement islike saying: "A profi

[issue9786] Native TLS support for pthreads

Kristján Valur Jónsson added the comment: I've changed the function as you suggest, although there are in fact no failure detection semantics defined for PyThread_create_key(). See e.g. thread.c:294 /* Return a new key. This must be called before any other functions in * this family, and ca

[issue9787] Release the TLS lock during allocations

Martin v. Löwis added the comment: > Note that we are not making any new requirements on python here. But you are. So far, there was no guarantee whatsoever about the state of Python when malloc is called. You are now introducing a requirement that Python must be in a certain state to make it c

[issue7994] object.__format__ should reject format strings

Florent Xicluna added the comment: now the PendingDeprecationWarnings are checked in the test suite, with r84772 (for 2.7). -- ___ Python tracker ___ ___

[issue9799] Compilation error for branch py3k on AIX 6

Sébastien Sablé added the comment: Yes, no problem; I will update the Misc/AIX-NOTES file with all the information I have been collecting recently on Python with AIX. I will do that when I will have solved some remaining issues I have on AIX, and also when I will have checked with AIX 5.3 as

[issue9786] Native TLS support for pthreads

Martin v. Löwis added the comment: Am 13.09.2010 10:00, schrieb Kristján Valur Jónsson: > > Kristján Valur Jónsson added the comment: > > I've changed the function as you suggest, although there are in fact no > failure detection semantics defined for PyThread_create_key(). Right. That's

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

Steven Bethard added the comment: Are you sure this is an argparse issue, and not a terminal issue? Here's what I see: >>> parser = argparse.ArgumentParser(description=u'Rus Рус') >>> print(parser.description) Rus Рус >>> sys.stderr.write(parser.description) Traceback (most recent call last):

[issue9716] The inittab modules cannot be packages

R. David Murray added the comment: We use versions to track which versions we are going to fix, not which versions are affected (which is why we don't list any versions pre-2.5...2.5 and 2.6 occasionally get security fixes, but no earlier versions even get those). Now, why Brett removed 2.7 i

[issue9820] Windows : os.listdir(b'.') doesn't raise an errorfor unencodablefilenames

STINNER Victor added the comment: > I fail to see why removing incorrect file names from the result > list is any better than keeping them. The result list will > be incorrect either way. It depends if you focus on displaying the content of the directory, or on processing files and directorie

[issue9820] Windows : os.listdir(b'.') doesn't raise an errorfor unencodablefilenames

STINNER Victor added the comment: > I think trying to emulate, in Python, what the *A functions > do is futile. My problem is that some functions will use mbcs in strict mode (functions using PyUnicode_EncodeFSDefault): raise UnicodeEncodeError, and other will use mbcs in replace mode (funct

[issue6011] python doesn't build if prefix contains non-ascii characters

Baptiste Carvello added the comment: Eric: the bug does not exist with 2.7, as the Makefile is read as bytes. It exists with 3.1.2. By the way, when I say the bug is solved on 3.2, I only mean the narrow problem of using a non-ascii prefix that *is* decodable with the current locale. I do not

[issue9820] Windows : os.listdir(b'.') doesn't raise an errorfor unencodablefilenames

R. David Murray added the comment: After the decision to ignore undecodable file names in os.listdir but before PEP 383 there was a long discussion on python-dev (in which I was a participant) about how horrible just ignoring the undecodable filenames was. This applies *especially* to the os

[issue9820] Windows : os.listdir(b'.') doesn't raise an errorfor unencodablefilenames

R. David Murray added the comment: But in the case of BZ2File and ssl.SSLContext.load_cert_chain(), isn't it the case that they are trying to open the files? So producing an early error about the decoding problem makes sense. Are there any functions other than listdir where the decoded file

[issue9845] Allow changing the method in urllib.request.Request

New submission from Tarek Ziadé : Right now you have to override Request or patch its get_method() method to be able to send HTTP requests where the method is not GET or POST. This is making some assumptions on what the users wants to do with the request. The way get_method guesses the method

[issue9845] Allow changing the method in urllib.request.Request

Tarek Ziadé added the comment: sorry - Removed the assignment (the name is not followed by *) -- assignee: orsenthil -> ___ Python tracker ___ __

[issue9716] The inittab modules cannot be packages

Nick Coghlan added the comment: I assume Brett marked this 3.x only because we currently don't support builtin packages at all, so making this work crosses way over into feature request territory. That makes it unsuitable for a branch in maintenance mode (i.e. 2.7). Added the relevant depende

[issue1475397] time.asctime_tz, time.strftime %z %C

Alexander Belopolsky added the comment: Would issue9527 address your request? Note that datetime.strftime already supports %z: >>> from datetime import * >>> datetime.now(timezone.utc).strftime('%c %z') 'Mon Sep 13 13:43:19 2010 +' (I assume you meant to write %c, not %C.) -- as

[issue9784] _msi.c warnings under 64-bit Windows

Changes by Jon Anglin : -- nosy: +janglin ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org

[issue9783] _elementtree.c warnings under 64-bit Windows

Changes by Jon Anglin : -- nosy: +janglin ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org

[issue1076515] shutil.move clobbers read-only files.

Antoine Pitrou added the comment: I agree that this follows Unix behaviour: a read-only file is a file whose contents cannot be modified, but you can replace it with another totally different file. You can also delete it, by the way (*). Also, even if this weren't the desired behaviour, chang

[issue9782] _multiprocessing.c warnings under 64-bit Windows

Changes by Jon Anglin : -- nosy: +janglin ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org

[issue1076515] shutil.move clobbers read-only files.

Changes by Antoine Pitrou : -- stage: unit test needed -> type: behavior -> feature request versions: -Python 2.7, Python 3.1 ___ Python tracker ___ _

[issue6706] asyncore's accept() is broken

Changes by jan matejek : -- nosy: +matejcik ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.o

[issue9181] Solaris extension building does not work with 64 bit python

Antoine Pitrou added the comment: Can you try using CC="cc -m64" OPT="-O3" instead? (replace "cc" with the proper compiler name, of course) -- nosy: +pitrou ___ Python tracker __

[issue9566] Compilation warnings under x64 Windows

Changes by Jon Anglin : -- nosy: +janglin ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org

[issue9323] trace.py bug with the main file being traced

Alexander Belopolsky added the comment: > The full path *could* be easily passed, but I think we should > address this problem from regrtest.py's side. I disagree. There may be other scripts that rely on __main__.__file__ being an absolute path and we cannot require everyone to change their

[issue9614] _pickle is not entirely 64-bit safe

Changes by Jon Anglin : -- nosy: +janglin ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org

[issue9828] Repeated Py_Initialize and Py_Finalize usage brings fatal error?

Antoine Pitrou added the comment: Fix committed in r84774. Thank you! -- resolution: -> fixed stage: -> committed/rejected status: open -> closed ___ Python tracker ___ ___

[issue4761] create Python wrappers for openat() and others

Changes by Chris Gerhard : -- nosy: +Chris.Gerhard ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.p

[issue9786] Native TLS support for pthreads

Antoine Pitrou added the comment: > Right. That's why I'm thinking that we should introduce some. TLS > creation *can* fail, and it is unfortunate that the original > introduction of this API forgot to consider that. Your patch did > (de facto) introduce an error return code (originally 0, now -

[issue9181] Solaris extension building does not work with 64 bit python

Charles Solar added the comment: I just recompiled using your suggested flags and it is now properly linking my extensions. I guess using CFLAGS and LDFLAGS was causing the problem. Is specifying CC the recommended way to build 64 bit python? If so when I guess this issue is not really an is

[issue9181] Solaris extension building does not work with 64 bit python

Antoine Pitrou added the comment: > Is specifying CC the recommended way to build 64 bit python? Currently, yes. LDFLAGS is supposed to work, but it doesn't (open bug: #9437). -- ___ Python tracker ___

[issue1538778] pyo's are not overwritten by different optimization levels

Barry A. Warsaw added the comment: How is this different than overwriting pyc files, except that there's probably less of a use case for pycs? IOW, if we were to do something about this, it should probably be an option to ignore any existing pyc (or pyo if -O is used) files and write new one

[issue9807] deriving configuration information for different builds with the same prefix

Barry A. Warsaw added the comment: My (I think fairly straightforward) idea is to just compile the useful values in Makefile and config.h into _sysconfig.c and arrange for sysconfig to import that and check it first (fallback to parsing mf and conf.h). I'll see if I can whip up a patch for th

[issue9807] deriving configuration information for different builds with the same prefix

Antoine Pitrou added the comment: Is there any point in creating another extension module? We already have Modules/getpath.c which receives various configuration values at compile-time, themselves exposed as sys.prefix and friends. The simpler the better, IMO. sysconfig can choose to expose t

[issue7280] PCBuild instruction says to use nasmw.exe but it no longer exist

sorin added the comment: Please reopen the bug, current documentation change is not a proper solution and also it does not work (see below). Python's openssl repository contain pregenerated mak files (/ms/*.mak), when it should not. If you check openssl repository you will see that these ar

[issue1294232] Error in metaclass search order

Amaury Forgeot d'Arc added the comment: What also worries me is the difference between the "class" statement and the type() function. class M_A(type): def __new__(mcls, name, bases, ns): print('M_A.__new__', mcls, name, bases) return super().__new__(mcls, name, bases, ns) cl

[issue9561] distutils: set encoding to utf-8 for input and output files

Toshio Kuratomi added the comment: >>> - RPM spec files, which use ASCII or UTF-8 according to >>> http://en.opensuse.org/openSUSE:Specfile_guidelines#Specfile_Encoding but >>> it’s not confirmed in >>> http://www.rpm.org/max-rpm/s1-rpm-build-creating-spec-file.html (linked >>> from the LSB site

[issue9841] sysconfig and distutils.sysconfig differ in subtle ways

Tarek Ziadé added the comment: That's what I wanted to do first but it turned out to be a bad idea. This duplication is unfortunate but the freeze is also to prevent third party code that patches distutils to break. For instance, there's a lot of code out there that just patches distutils.sy

[issue9315] The trace module lacks unit tests

Alexander Belopolsky added the comment: Hmm, it looks like patches 5 and 6 lost the fix for the class name issue. I'll check if I can merge in patch 4. -- ___ Python tracker ___

[issue9699] invalid call of Windows API _popen() generating The input line is too long error message

sorin added the comment: I made a small but important update to quote_command(), now it does quote the command line only under Windows because doing this under other platforms may break the command line. -- ___ Python tracker

[issue9323] trace.py bug with the main file being traced

Florent Xicluna added the comment: I've made the wrong assumption that test.regrtest.__file__ is always absolute. Here is a patch which should fix it. -- nosy: +ezio.melotti Added file: http://bugs.python.org/file18870/issue9323_regrtest.diff ___ Py

[issue9846] ZipExtFile provides no mechanism for closing the underlying file object

New submission from John Admanski : When creating a ZipExtFile through ZipFile.open, the if the original ZipFile object was created with a filename then a new file object will be opened and given to the ZipExtFile to use for its file operations. There is no explicit mechanism that will allow y

[issue9716] The inittab modules cannot be packages

Brett Cannon added the comment: Both David and Nick are correct as to why I did what I did. -- ___ Python tracker ___ ___ Python-bugs-

[issue1538778] pyo's are not overwritten by different optimization levels

Toshio Kuratomi added the comment: Here's a usage where this matters. It's a simplification of the bug report that I got that prompted me to open this. Let's say I have the following code: /usr/lib/python2.7/site-packages/foo.py:: def help(): """I'm a little docstring, short and

[issue1538778] pyo's are not overwritten by different optimization levels

Arfrever Frehtes Taifersar Arahesis added the comment: compileall module supports -f (force) option, so you can use: python3.2 -O -m compileall -f ${files} -- nosy: +Arfrever ___ Python tracker _

[issue1538778] pyo's are not overwritten by different optimization levels

Barry A. Warsaw added the comment: Uh, duh. Thanks for reminding me about that Arfrever! :) That should be everything Toshio needs I think. Plus this request is 4 years old. Closing as won't fix. -- resolution: -> wont fix status: open -> closed __

[issue9315] The trace module lacks unit tests

Alexander Belopolsky added the comment: Committed with minor changes in r84777. Eli, please keep lines under 80 characters. Leaving the issue open pending py3k port. -- resolution: -> accepted stage: patch review -> committed/rejected ___ Python t

[issue1538778] pyo's are not overwritten by different optimization levels

Toshio Kuratomi added the comment: It doesn't fix the problem as it falls into the third class of solutions (one that requires cooperation by the system administrator to diagnose and fix). OTOH, at this point in time I'm putting all of my packages in system packages where the .pyos are pregen

[issue9846] ZipExtFile provides no mechanism for closing the underlying file object

Antoine Pitrou added the comment: Indeed. However, the ZipFile itself knows whether to close the file (self._filePassed). By adding a constructor argument to ZipExtFile and a __del__ method, it would solve the issue. -- nosy: +pitrou stage: -> needs patch versions: +Python 3.2 -Pytho

[issue1397474] timeit execution enviroment

Changes by Eli Bendersky : -- nosy: +eli.bendersky ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mai

[issue1397474] timeit execution enviroment

Eli Bendersky added the comment: Terry, I'm attaching a patch for 2.7, however it's more proof-of-concept than final, because I have a few comments. The patch generally implements your documentation suggestion without the `import *` warning and without adding the final example. The latter fo

[issue9847] Binary strings never compare equal to raw/normal strings

New submission from James Hutchison : Tested on Python 3.1.2 Windows XP 32-bit Binary strings (such as what is returned by filereader.readline()) are never equal to raw or normal strings, even when both strings are empty if(b"" == ""): print("Strings are equal"); else: if(b"" =

[issue9844] calling nonexisting function under __INSURE__

Eli Bendersky added the comment: Barry, I've taken the liberty to add you to the nosy list because I found in the logs you've originally added this code (in 2001!!) I hope it's OK with you :-) -- nosy: +barry ___ Python tracker

[issue9323] trace.py bug with the main file being traced

Florent Xicluna added the comment: regrtest fixed with r84776 (3.x) and r84779 (2.7) -- ___ Python tracker ___ ___ Python-bugs-list ma

[issue9323] trace.py bug with the main file being traced

Alexander Belopolsky added the comment: Thanks, Florent. -- status: open -> closed ___ Python tracker ___ ___ Python-bugs-list mailing

[issue9847] Binary strings never compare equal to raw/normal strings

Florent Xicluna added the comment: This is by design in Python 3 http://docs.python.org/py3k/whatsnew/3.0.html#text-vs-data-instead-of-unicode-vs-8-bit -- nosy: +flox resolution: -> works for me status: open -> closed ___ Python tracker

[issue9315] The trace module lacks unit tests

Alexander Belopolsky added the comment: Eli, while porting your tests to py3k, I had to change expected output for list comprehension testing. This is not really surprising because 3.x comprehensions differ from 2.x (they don't leak the loop variable anymore). The difference between versions

[issue1538778] pyo's are not overwritten by different optimization levels

Barry A. Warsaw added the comment: Thanks Toshio, I get it now. I think pre-generating the proper pyo's is probably the best solution. -- ___ Python tracker ___

[issue9315] The trace module lacks unit tests

Alexander Belopolsky added the comment: Committed in: py3k: r84780 release31-maint: r84783 release27-maint: r84777 Need a separate issue for the problem highlighted in msg116336. -- status: open -> closed ___ Python tracker

[issue665761] reduce() masks exception

Alexander Belopolsky added the comment: Since noone have spoken in favor of 2.7 backport, I am closing this issue as committed to py3k. -- keywords: -needs review resolution: -> accepted stage: patch review -> committed/rejected status: pending -> closed versions: -Python 2.7 _

[issue9820] Windows : os.listdir(b'.') doesn't raise an errorfor unencodablefilenames

STINNER Victor added the comment: - ignore unencodable filenames is not a good idea - raise an error on unencodable filenames breaks backward compatibility - I don't think that emit a warning will change anything Even if I don't like mbcs+replace (current behaviour of os.listdir(bytes)), I now

[issue9315] The trace module lacks unit tests

Florent Xicluna added the comment: You probably missed Lib/test/tracedmodules/ in r84780 ;) -- keywords: +buildbot nosy: +flox ___ Python tracker ___

[issue9360] nntplib cleanup

Antoine Pitrou added the comment: Here is an updated patch, but it's a work in progress. Since we are breaking compatibility anyway, I think a larger cleanup is deserved. For example: - remove old exception aliases - make return types consistent (for example, newgroups() should returned struc

[issue9848] setup.py contains needless references to built-in _weakref module

New submission from Arfrever Frehtes Taifersar Arahesis : _weakref module is a built-in module in Python 3 since r58602, but references to _weakref module in setup.py haven't been removed. They can be removed in py3k and 3.1 branches. setup.py in 2.7 branch (since r84233) contains unused, com

[issue6706] asyncore's accept() is broken

Changes by Santoso Wijaya : -- nosy: +santa4nt ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pytho

[issue9802] Document 'stability' of builtin min() and max()

Mark Dickinson added the comment: > Of course, there are subtle implications of how it will be implemented Indeed. Ideally, as you mention, the implementation would only use __lt__ (as with sort and bisect). I think that constraint only leaves one reasonable choice: namely, max and min for

[issue767645] incorrect os.path.supports_unicode_filenames

Changes by STINNER Victor : Removed file: http://bugs.python.org/file18841/test_pep277.patch ___ Python tracker ___ ___ Python-bugs-list mail

[issue9786] Native TLS support for pthreads

Martin v. Löwis added the comment: > Perhaps we can simply call Py_FatalError() instead? There's not much we > can do when such a failure occurs anyway. Sounds fine as well. Python's own usage definitely shouldn't fail. If extension modules use this in an aggressive manner, they may actually ex

[issue9807] deriving configuration information for different builds with the same prefix

Martin v. Löwis added the comment: > My (I think fairly straightforward) idea is to just compile the > useful values in Makefile and config.h into _sysconfig.c and arrange > for sysconfig to import that and check it first (fallback to parsing > mf and conf.h). You seem to suggest that by doing

[issue767645] incorrect os.path.supports_unicode_filenames

STINNER Victor added the comment: r84784 sets os.path.supports_unicode_filenames to True on Mac OS X (macpath module). About test_supports_unicode_filenames.patch. test_unicode_listdir() is wrong: os.listdir(str) always return str (see r84701). "verify that the new file's name is equal to th

[issue767645] incorrect os.path.supports_unicode_filenames

STINNER Victor added the comment: I backported r84701 and r84784 to Python 2.7 (r84787). -- ___ Python tracker ___ ___ Python-bugs-l

[issue9360] nntplib cleanup

R. David Murray added the comment: Assuming we can break backward compatibility, it sounds fine to me. -- ___ Python tracker ___ ___ P

[issue9819] TESTFN_UNICODE and TESTFN_UNDECODABLE

Changes by STINNER Victor : -- resolution: -> fixed status: open -> closed ___ Python tracker ___ ___ Python-bugs-list mailing list Un

[issue9360] nntplib cleanup

Changes by Giampaolo Rodola' : -- nosy: +giampaolo.rodola ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http:/

[issue7994] object.__format__ should reject format strings

Eric Smith added the comment: Manually merged to py3k in r84790. I'll leave this open until I create the 3.3 issue to change it to a DeprecationWarning. -- keywords: -needs review versions: -Python 3.3 ___ Python tracker

[issue9315] The trace module lacks unit tests

Alexander Belopolsky added the comment: You must be right. I thought I did all the svn adds, but may have missed something. I'll take care of this tonight, but I am off the grid for the next 3-4 hours. On Sep 13, 2010, at 3:13 PM, Florent Xicluna wrote: > > Florent Xicluna added the comm

[issue9213] range purports to implement the Sequence ABC, but is missing index and count methods

Daniel Stutzbach added the comment: Committed as r84791. Question: should this bugfix be backported to Python 3.1 and to xrange objects in Python 2.7? Since it's a bugfix that adds new methods, it's a gray-area. (same question applies to the closely related Issue #9212) -- ___

[issue9840] Recursive Repr

Raymond Hettinger added the comment: Committed in r84792. -- resolution: -> fixed status: open -> closed ___ Python tracker ___ ___ P

[issue767645] incorrect os.path.supports_unicode_filenames

Ned Deily added the comment: There seems to be some confusion about the macpath.py module. I'm not sure why it even exists in Python 3. Note it has to do with obsolete Classic MacOS-style paths (colon-separated paths) which are available on Mac OS X only through deprecated Carbon interfaces

[issue9849] Argparse needs better error handling for nargs

New submission from Jason Baker : This is referring to argparse 1.1 installed under Python 2.6. When I was passing in an nargs flag, I figured that since '+' and '*' are valid options, I should pass in strings. So when I tried passing in the string '1' instead of the integer 1, I got the fol

[issue9846] ZipExtFile provides no mechanism for closing the underlying file object

John Admanski added the comment: I'm not sure that's much of an improvement on the existing behavior, though; as I mentioned you can already work around it by killing all the references to the ZipExtFile and the underlying file object will get automatically closed if the ZipExtFile is the onl

[issue9849] Argparse needs better error handling for nargs

Ned Deily added the comment: Note, argparse is not part of the Python standard library in 2.6 but the 2.7 and 3.2 versions exhibit the same behavior. -- assignee: -> bethard nosy: +bethard, ned.deily versions: +Python 2.7, Python 3.2 -Python 2.6 __

[issue9315] The trace module lacks unit tests

Alexander Belopolsky added the comment: > You probably missed Lib/test/tracedmodules/ fixed in r84794. -- ___ Python tracker ___ ___

[issue9810] bzip2 build sometimes fails (VS8.0)

Hirokazu Yamamoto added the comment: I propose following solution. * svn copy http://svn.python.org/projects/external/bzip2-1.0.5 http://svn.python.org/projects/external/bzip2-1.0.5.0 * fix makefile in http://svn.python.org/projects/external/bzip2-1.0.5 * svn copy http://svn.python.org/p

[issue9815] test_tarfile sometimes ends with error "Cannot remove dir"

Hirokazu Yamamoto added the comment: I tried test_tar_pipe_open_read_error_v2.py on py3k, I saw 3 uncollectable objects are reported. But they are *collected* by gc.collect() without gc.set_debug(gc.DEBUG_LEAK). (I'm not familiar to gc, so maybe this is normal) I didn't see uncollectable object

[issue9846] ZipExtFile provides no mechanism for closing the underlying file object

R. David Murray added the comment: Antoine, any reason not to put the close in the ZipFileExt close method instead of a __del__ method? (And document it, of course). -- nosy: +r.david.murray ___ Python tracker __

[issue9759] GzipFile object should raise ValueError on .read() after .close()

Jeffrey Finkelstein added the comment: Here is a patch for the py3k branch which adds a check for whether the GzipFile is closed on each call to GzipFile.read(). If the file is closed already, the method raises a ValueError if it is (with the message text copied from the corresponding fileobj

[issue9759] GzipFile object should raise ValueError on .read() after .close()

Jeffrey Finkelstein added the comment: Here's the 2.7 branch patch. -- Added file: http://bugs.python.org/file18875/issue9759.patch ___ Python tracker ___ ___

[issue9810] bzip2 build sometimes fails (VS8.0)

Martin v. Löwis added the comment: Another solution would be not to make clean, but del *.obj. However, I would prefer if we stopped using makefile.msc altogether, and explicitly included the source files of bzip2 into bz2.vcproj, similar to the way _bsddb is built (in 2.7). -- _

[issue9850] obsolete macpath module dangerously broken and should be removed

New submission from Ned Deily : The macpath module in the standard library purports to supply "the Mac OS 9 (and earlier) implementation of the os.path module. It can be used to manipulate old-style Macintosh pathnames on Mac OS X (or any other platform). The following functions are availabl

[issue767645] incorrect os.path.supports_unicode_filenames

Ned Deily added the comment: (I've opened Issue9850 to document the brokenness of macpath and suggest its deprecation and removal.) -- ___ Python tracker ___ _

[issue9850] obsolete macpath module dangerously broken and should be removed

Ned Deily added the comment: The macpath module in the standard library purports to supply "the Mac OS 9 (and earlier) implementation of the os.path module. It can be used to manipulate old-style Macintosh pathnames on Mac OS X (or any other platform). The following functions are available

[issue9850] obsolete macpath module dangerously broken and should be removed

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

[issue9815] test_tarfile sometimes ends with error "Cannot remove dir"

Hirokazu Yamamoto added the comment: The error went away when I commented out following line. Lib/unittest/case.py(133) self.exception = exc_value.with_traceback(None) I found this by brute force I noticed that test_tar_pipe_open_read_error_v2.py starts to fail from r75241. It stor

[issue9815] test_tarfile sometimes ends with error "Cannot remove dir"

Hirokazu Yamamoto added the comment: Here is the patch to fix this issue. (Please forget first patch) E:\python-dev>py3k -m test.regrtest test_tarfile [1/1] test_tarfile 1 test OK. [85902 refs] E:\python-dev>py3k test_assert_raises.py -- [('foo 2',), None, RuntimeError(

[issue9729] Unconnected SSLSocket.{send, recv} raises TypeError: 'member_descriptor' object is not callable

Andrew Bennetts added the comment: Here's a conservative fix for Python 2.7. It replaces the attempts to call baseclass.method with direct calls to the decorated object (i.e. replace socket.meth(self, ...) with self._sock.meth(...)). It also corrects a bunch of incorrect arguments being pass

[issue9315] The trace module lacks unit tests

Georg Brandl added the comment: Note that if you add new directories under /Lib, you need to make the build system aware of them in several places (I don't remember all of them right now, one is in the Makefile). Otherwise they don't get shipped and/or installed, and tests fail. --

  1   2   >