Mark Dickinson dicki...@gmail.com 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
___
New submission from Mark Dickinson dicki...@gmail.com:
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,
Antoine Pitrou pit...@free.fr added the comment:
It would be nice to try to advance this at PyCon, or at another time.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue3783
___
Eric Smith e...@trueblade.com 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
New submission from Floris Bruynooghe floris.bruynoo...@gmail.com:
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
Eric Smith e...@trueblade.com 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
Changes by Eric Smith e...@trueblade.com:
--
versions: +Python 2.7
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue3382
___
___
Python-bugs-list
Mark Dickinson dicki...@gmail.com added the comment:
Looks good to me.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue3382
___
___
New submission from Titus Brown ti...@idyll.org:
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
Eric Smith e...@trueblade.com added the comment:
Committed (with a few more tests) in r76583.
--
resolution: - accepted
stage: - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue3382
Changes by Roumen Petrov bugtr...@roumenpetrov.info:
Added file: http://bugs.python.org/file15415/python-trunk-20091129-CROSS.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue3754
Changes by Roumen Petrov bugtr...@roumenpetrov.info:
Added file: http://bugs.python.org/file15416/python-trunk-20091129-MINGW.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue3871
Ned Deily n...@acm.org added the comment:
Also seeing it on 10.5 ...
--
nosy: +ned.deily
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7408
___
Tarek Ziadé ziade.ta...@gmail.com 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
David Bolen db3l@gmail.com 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).
Tarek Ziadé ziade.ta...@gmail.com 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:
Martin v. Löwis mar...@v.loewis.de 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
Titus Brown ti...@idyll.org 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
David Bolen db3l@gmail.com 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
Ned Deily n...@acm.org 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
David Bolen db3l@gmail.com 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
Ned Deily n...@acm.org 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
Martin v. Löwis mar...@v.loewis.de 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
David Bolen db3l@gmail.com 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,
New submission from Robert Collins robe...@robertcollins.net:
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
Benjamin Peterson benja...@python.org added the comment:
Fixed in r76591. Thanks!
--
nosy: +benjamin.peterson
resolution: - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7409
Tarek Ziadé ziade.ta...@gmail.com 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
Titus Brown ti...@idyll.org added the comment:
Fix verified, thanks!
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7408
___
___
Changes by Raymond Hettinger rhettin...@users.sourceforge.net:
--
assignee: georg.brandl - rhettinger
nosy: +rhettinger
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7407
___
Amaury Forgeot d'Arc amaur...@gmail.com added the comment:
Fixed with r76593 (py3k) and r76594 (release31-maint)
--
resolution: accepted - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6077
Eric Smith e...@trueblade.com 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
Eric Smith e...@trueblade.com added the comment:
Fixed in r76595.
--
resolution: - accepted
stage: - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5748
New submission from Robert Collins robe...@robertcollins.net:
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
Changes by Raymond Hettinger rhettin...@users.sourceforge.net:
--
assignee: - rhettinger
nosy: +rhettinger
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7410
___
Changes by Raymond Hettinger rhettin...@users.sourceforge.net:
--
priority: - low
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7410
___
___
Phillip M. Feldman pfeld...@verizon.net 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
New submission from Phillip M. Feldman pfeld...@verizon.net:
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
37 matches
Mail list logo
