[issue7411] allow import from file having name containing hyphen or blank

New submission from Phillip M. Feldman : It appears that there is currently no way to import from a file whose name contains a hyphen or blank. This makes it difficult to encode a version number or date in the file name. The solution that I favor would be to allow the name of the file to be sp

[issue1859] textwrap doesn't linebreak on "\n"

Phillip M. Feldman added the comment: As a temporary workaround, you can use the `wrap` function in my strnum module (http://pypi.python.org/pypi/strnum/2.4). Phillip -- nosy: +pfeld...@verizon.net ___ Python tracker

[issue7410] deepcopy of itertools.count resets the count

Changes by Raymond Hettinger : -- priority: -> low ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.

[issue7410] deepcopy of itertools.count resets the count

Changes by Raymond Hettinger : -- assignee: -> rhettinger nosy: +rhettinger ___ Python tracker ___ ___ Python-bugs-list mailing list U

[issue7410] deepcopy of itertools.count resets the count

New submission from Robert Collins : >>> from copy import deepcopy >>> from itertools import count >>> c = count() >>> c.next() 0 >>> deepcopy(c) count(0) >>> c.next() 1 >>> deepcopy(c) count(0) >>> c count(2) >>> deepcopy(c).next() 0 I don't see any reason why these shouldn't be deepcopyable (

[issue5748] Objects/bytesobject.c should include stringdefs.h, instead of defining its own macros

Eric Smith added the comment: Fixed in r76595. -- resolution: -> accepted stage: -> committed/rejected status: open -> closed ___ Python tracker ___ ___

[issue5748] Objects/bytesobject.c should include stringdefs.h, instead of defining its own macros

Eric Smith added the comment: This does not apply to 2.x. In both py3k and trunk, Objects/bytearrayobject.c uses stringlib with some private defines. But since those defines are only used in bytearrayobject.c, there's nothing to be gained by factoring then out into a bytearraydef.h file. So, I'

[issue6077] Unicode issue with tempfile on Windows

Amaury Forgeot d'Arc added the comment: Fixed with r76593 (py3k) and r76594 (release31-maint) -- resolution: accepted -> fixed status: open -> closed ___ Python tracker ___ _

[issue7407] Minor Queue doc improvement

Changes by Raymond Hettinger : -- assignee: georg.brandl -> rhettinger nosy: +rhettinger ___ Python tracker ___ ___ Python-bugs-list ma

[issue7408] test_distutils fails on Mac OS X 10.5

Titus Brown added the comment: Fix verified, thanks! -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://

[issue7408] test_distutils fails on Mac OS X 10.5

Tarek Ziadé added the comment: I've dropped the gid control and just check the uid. >From Distutils PoV, as long as this uid test pass, I can defer the complete uid/gid test to the dedicated tarfile tests. What is important here is being able to check that I can force a different uid/gid for s

[issue7409] cleanup now deepcopy copies instance methods

Benjamin Peterson added the comment: Fixed in r76591. Thanks! -- nosy: +benjamin.peterson resolution: -> fixed status: open -> closed ___ Python tracker ___

[issue7409] cleanup now deepcopy copies instance methods

New submission from Robert Collins : With deepcopy fixed, I ran across this little fixable component. -- components: Library (Lib) files: deepcopy-works.patch keywords: patch messages: 95823 nosy: rbcollins severity: normal status: open title: cleanup now deepcopy copies instance methods

[issue7408] test_distutils fails on Mac OS X 10.5

David Bolen added the comment: > I think that's difficult to implement, as the files are not there > anymore when the check is made (only the tarfile); somebody correct > me if I'm wrong. The files are created during setup, and I think exist through the duration of the test, only being removed

[issue7408] test_distutils fails on Mac OS X 10.5

Martin v. Löwis added the comment: > At some level, I'm not sure it really matters as long as the test uses > whatever actual filesystem ownership is in place checking for default > values. I think that's difficult to implement, as the files are not there anymore when the check is made (only th

[issue7408] test_distutils fails on Mac OS X 10.5

Ned Deily added the comment: BTW, it's trivial to demonstrate the difference. On OS X: $ cd $HOME $ mkdir test $ touch test/test $ chown :musicg test $ touch test/test2 $ ls -l test total 0 -rw-r- 1 nad staff 0 Nov 29 14:01 test -rw-r- 1 nad musicg 0 Nov 29 14:01 test2 On my li

[issue7408] test_distutils fails on Mac OS X 10.5

David Bolen added the comment: > I can generate the error on my iMac but not my laptop, which are > equivalent versions/upgrades of Mac OS X AFAIK. The /tmp directory > in both has drwxrwxrwt, and the subdirectories within which I'm doing > the builds are drwxr-xr-x, so it doesn't seem to be on

[issue7408] test_distutils fails on Mac OS X 10.5

Ned Deily added the comment: This does seem to be a long standing Unix*-flavor behavior difference. The open(2) man page on OS X (and presumably FreeBSD) reads: When a new file is created, it is given the group of the directory which contains it. The Linux open(2) page has: O_

[issue7408] test_distutils fails on Mac OS X 10.5

David Bolen added the comment: >From Tarek: > Thanks for the digging David, I'll check for /tmp rights in that case. > What's important in distutils, is to make sure it was able to create > tarballs with various uid/gid using the new tarfile feature. Right, and that part of the test (explicitl

[issue7408] test_distutils fails on Mac OS X 10.5

Titus Brown added the comment: I can generate the error on my iMac but not my laptop, which are equivalent versions/upgrades of Mac OS X AFAIK. The /tmp directory in both has drwxrwxrwt, and the subdirectories within which I'm doing the builds are drwxr-xr-x, so it doesn't seem to be only dir p

[issue7408] test_distutils fails on Mac OS X 10.5

Martin v. Löwis added the comment: David, could it be that the directories where a change of group occurs also have the s-bit set? The sticky bit should have no such effect. -- nosy: +loewis ___ Python tracker

[issue7408] test_distutils fails on Mac OS X 10.5

Tarek Ziadé added the comment: Thanks for the digging David, I'll check for /tmp rights in that case. What's important in distutils, is to make sure it was able to create tarballs with various uid/gid using the new tarfile feature. -- priority: -> high resolution: -> accepted ___

[issue7408] test_distutils fails on Mac OS X 10.5

David Bolen added the comment: I don't think its OSX specific. My FreeBSD slaves (both 6.4 and 7.2) have been getting the same error recently (sounds like probably around the same time frame). The error always seems to be that member.gid (0) is not matching os.getgid (1001). The os.getgid cal

[issue7408] test_distutils fails on Mac OS X 10.5

Tarek Ziadé added the comment: This test makes sure that a tarball created with sidist has the same owner/group than your current user in each one of its member. Maybe somehow, the previous tarball creation breaks this test. Can you try this on your side: Comment everything in "test_make_distr

[issue7408] test_distutils fails on Mac OS X 10.5

Ned Deily added the comment: Also seeing it on 10.5 ... -- nosy: +ned.deily ___ Python tracker ___ ___ Python-bugs-list mailing list U

[issue3871] cross and native build of python for mingw32 with distutils

Changes by Roumen Petrov : Added file: http://bugs.python.org/file15416/python-trunk-20091129-MINGW.patch ___ Python tracker <http://bugs.python.org/issue3871> ___ ___

[issue3754] minimal cross-compilation support for configure

Changes by Roumen Petrov : Added file: http://bugs.python.org/file15415/python-trunk-20091129-CROSS.patch ___ Python tracker <http://bugs.python.org/issue3754> ___ ___

[issue3382] Make '%F' and float.__format__('F') convert results to upper case.

Eric Smith added the comment: Committed (with a few more tests) in r76583. -- resolution: -> accepted stage: -> committed/rejected status: open -> closed ___ Python tracker ___

[issue7408] test_distutils fails on Mac OS X 10.5

New submission from Titus Brown : Here's the error: test_distutils test test_distutils failed -- Traceback (most recent call last): File "/private/tmp/tmp8UfLPT/python27/Lib/distutils/tests/test_sdist.py", line 342, in test_make_distribution_owner_group self.assertEquals(member.gid, os.getg

[issue3382] Make '%F' and float.__format__('F') convert results to upper case.

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

[issue3382] Make '%F' and float.__format__('F') convert results to upper case.

Changes by Eric Smith : -- versions: +Python 2.7 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pyt

[issue3382] Make '%F' and float.__format__('F') convert results to upper case.

Eric Smith added the comment: Here's a patch which adds some tests and fixes complex. I'm currently testing with PY_NO_SHORT_FLOAT_REPR on Windows. If that's okay, and if you don't have any objections, I'll commit this. While I'm at it I'll modify Objects/stringlib/formatter.h in py3k to keep t

[issue7407] Minor Queue doc improvement

New submission from Floris Bruynooghe : The documentation of the queue module (Queue in 2.x) does not mention that the constructors have a default argument of 0 for "maxsize". The trivial patch adds this (patch against py3k trunk). -- assignee: georg.brandl components: Documentation fil

[issue3382] Make '%F' and float.__format__('F') convert results to upper case.

Eric Smith added the comment: Thanks for looking at this, Mark. Your patch looks okay to me, but Objects/stringlib/formatter.h still has some 'F' -> 'f' logic in it, although it turns out that it's wrong: #if PY_VERSION_HEX < 0x0301000 /* 'F' is the same as 'f', per the PEP */ /* This

[issue3783] dbm.sqlite proof of concept

Antoine Pitrou added the comment: It would be nice to try to advance this at PyCon, or at another time. -- ___ Python tracker ___ ___

[issue7406] int arithmetic relies on C signed overflow behaviour

New submission from Mark Dickinson : Much of the code in Objects/intobject.c assumes that an arithmetic operation on signed longs will wrap modulo 2**(bits_in_long) on overflow. However, signed overflow causes undefined behaviour according to the C standards (e.g., C99 6.5, para. 5), and gcc

[issue3382] Make '%F' and float.__format__('F') convert results to upper case.

Mark Dickinson added the comment: Eric, any further thoughts about making this change in 2.7? Here's a patch that does it (I think). -- keywords: +patch Added file: http://bugs.python.org/file15412/issue3382_trunk.patch ___ Python tracker