[ python-Bugs-1561333 ] -xcode=pic32 option is not supported on Solaris x86 Sun C
Bugs item #1561333, was opened at 2006-09-19 10:15 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1561333&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.4 >Status: Closed >Resolution: Out of Date Priority: 5 Private: No Submitted By: James Lick (jlick) Assigned to: Nobody/Anonymous (nobody) Summary: -xcode=pic32 option is not supported on Solaris x86 Sun C Initial Comment: Python's ./configure script on Solaris systems sets the compiler flag -xcode=pic32 when Sun C is used. Unfortunately, the -xcode flag is only available in the sparc version of Sun C. The x86 version of Sun C does not support the -xcode option at all and generates a warning that an illegal option was used. The portable flag supported on both platforms to use independent 32-bit addressing is -KPIC. -- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-07 08:02 Message: Logged In: YES user_id=849994 Originator: NO Superseded by #1675511. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1561333&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1675516 ] random.randint fails on lists
Bugs item #1675516, was opened at 2007-03-07 08:10 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1675516&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: sardonics (sardonics) Assigned to: Nobody/Anonymous (nobody) Summary: random.randint fails on lists Initial Comment: >>> for i in range(400): ... l[random.randint(0,7)] ... 'g' 'g' 'c' 'c' 'b' 'b' 'g' 'g' 'd' 'g' 'd' 'f' 'd' 'a' Traceback (most recent call last): File "", line 2, in ? IndexError: list index out of range >>> l ['a', 'b', 'c', 'd', 'e', 'f', 'g'] >>> have no idea what the problem is. check out the error though -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1675516&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1675511 ] Python still uses broken -xcode option on Solaris/x86
Bugs item #1675511, was opened at 2007-03-07 15:54 Message generated for change (Comment added) made by jlick You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1675511&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Carson Gaspar (cgaspar) Assigned to: Nobody/Anonymous (nobody) Summary: Python still uses broken -xcode option on Solaris/x86 Initial Comment: Bug 1561333 was submitted against Python 2.4 with no action, so I'm submitting a new bug against 2.5 in the hopes that someone will read it... text updated with minor corrections. Python 2.5, Solaris x86 10 Update 3, Sun Studio 11 xcode=pic32 option is not supported on Solaris x86 Sun C . Python's ./configure script on Solaris systems sets the compiler flag -xcode=pic32 when any compiler other than gcc is used. Unfortunately, the -xcode flag is only available in the sparc version of Sun C. The x86 version of Sun C does not support the -xcode option at all and generates an error that an illegal option was used. The portable flag supported on both platforms to use independent 32-bit addressing is -KPIC. -- Comment By: James Lick (jlick) Date: 2007-03-07 16:34 Message: Logged In: YES user_id=673069 Originator: NO Perhaps I was unclear in bug #1561333 that this resulted in only a warning. Actually the build will fail because of the incorrect flag. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1675511&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1675516 ] random.randint fails on lists
Bugs item #1675516, was opened at 2007-03-07 17:10 Message generated for change (Comment added) made by quiver You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1675516&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 >Status: Closed >Resolution: Invalid Priority: 5 Private: No Submitted By: sardonics (sardonics) Assigned to: Nobody/Anonymous (nobody) Summary: random.randint fails on lists Initial Comment: >>> for i in range(400): ... l[random.randint(0,7)] ... 'g' 'g' 'c' 'c' 'b' 'b' 'g' 'g' 'd' 'g' 'd' 'f' 'd' 'a' Traceback (most recent call last): File "", line 2, in ? IndexError: list index out of range >>> l ['a', 'b', 'c', 'd', 'e', 'f', 'g'] >>> have no idea what the problem is. check out the error though -- >Comment By: George Yoshida (quiver) Date: 2007-03-07 17:35 Message: Logged In: YES user_id=671362 Originator: NO Please read the doc carefully. randint(a, b) can return b: http://docs.python.org/lib/module-random.html > Return a random integer N such that a <= N <= b. So in your case, randint(0,7) is returning 7 and tries to access l's 8th element, which results in IndexError. Closing as invalid. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1675516&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1675533 ] setup.py LDFLAGS regexp is wrong
Bugs item #1675533, was opened at 2007-03-07 03:45 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1675533&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Carson Gaspar (cgaspar) Assigned to: Nobody/Anonymous (nobody) Summary: setup.py LDFLAGS regexp is wrong Initial Comment: Python 2.5 setup.py mangles LDFLAGS and CPPFLAGS via: env_val = re.sub(r'(^|\s+)-(-|(?!%s))' % arg_name[1], '', env_val) This causes '-L/path/to/foo -R/path/to/bar' to become '-L/path/to/fooR/path/to/bar', which obviously doesn't work. The fix is simple - eat non-whitespace after the unrecognized option: env_val = re.sub(r'(^|\s+)-(-|(?!%s))\S+' % arg_name[1], '', env_val) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1675533&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1675533 ] setup.py LDFLAGS regexp is wrong
Bugs item #1675533, was opened at 2007-03-07 03:45 Message generated for change (Comment added) made by cgaspar You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1675533&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None >Priority: 7 Private: No Submitted By: Carson Gaspar (cgaspar) Assigned to: Nobody/Anonymous (nobody) Summary: setup.py LDFLAGS regexp is wrong Initial Comment: Python 2.5 setup.py mangles LDFLAGS and CPPFLAGS via: env_val = re.sub(r'(^|\s+)-(-|(?!%s))' % arg_name[1], '', env_val) This causes '-L/path/to/foo -R/path/to/bar' to become '-L/path/to/fooR/path/to/bar', which obviously doesn't work. The fix is simple - eat non-whitespace after the unrecognized option: env_val = re.sub(r'(^|\s+)-(-|(?!%s))\S+' % arg_name[1], '', env_val) -- >Comment By: Carson Gaspar (cgaspar) Date: 2007-03-07 03:48 Message: Logged In: YES user_id=664506 Originator: YES Or I could get the regexp correct and eat _option_ non-whitespace... env_val = re.sub(r'(^|\s+)-(-|(?!%s))\S*' % arg_name[1], '', env_val) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1675533&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1675511 ] Python still uses broken -xcode option on Solaris/x86
Bugs item #1675511, was opened at 2007-03-07 02:54 Message generated for change (Settings changed) made by cgaspar You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1675511&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None >Priority: 7 Private: No Submitted By: Carson Gaspar (cgaspar) Assigned to: Nobody/Anonymous (nobody) Summary: Python still uses broken -xcode option on Solaris/x86 Initial Comment: Bug 1561333 was submitted against Python 2.4 with no action, so I'm submitting a new bug against 2.5 in the hopes that someone will read it... text updated with minor corrections. Python 2.5, Solaris x86 10 Update 3, Sun Studio 11 xcode=pic32 option is not supported on Solaris x86 Sun C . Python's ./configure script on Solaris systems sets the compiler flag -xcode=pic32 when any compiler other than gcc is used. Unfortunately, the -xcode flag is only available in the sparc version of Sun C. The x86 version of Sun C does not support the -xcode option at all and generates an error that an illegal option was used. The portable flag supported on both platforms to use independent 32-bit addressing is -KPIC. -- Comment By: James Lick (jlick) Date: 2007-03-07 03:34 Message: Logged In: YES user_id=673069 Originator: NO Perhaps I was unclear in bug #1561333 that this resulted in only a warning. Actually the build will fail because of the incorrect flag. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1675511&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1648957 ] HP-UX: _ctypes/libffi/src/ia64/ffi/__attribute__/native cc
Bugs item #1648957, was opened at 2007-01-31 10:07 Message generated for change (Comment added) made by cgaspar You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1648957&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Johannes Abt (jabt) Assigned to: Nobody/Anonymous (nobody) Summary: HP-UX: _ctypes/libffi/src/ia64/ffi/__attribute__/native cc Initial Comment: _ctypes/libffi/src/ia64/ffi.c uses __attribute__((...)) twice. Consequently, ffi.c does not compile with the native compiler (cc: HP C/aC++ B3910B A.06.12 [Aug 17 2006]). -- Comment By: Carson Gaspar (cgaspar) Date: 2007-03-07 04:05 Message: Logged In: YES user_id=664506 Originator: NO Fails on Solaris x86 10 U3 / Sun Studio 11 for the same reasons. It's uncompilable on x86_64 anyway though, as Sun has no 128-bit integer type, so the __int128_t in x86/ffi64.c will never compile. I haven't tried building it in 32-bit mode. -- Comment By: Thomas Heller (theller) Date: 2007-01-31 14:43 Message: Logged In: YES user_id=11105 Originator: NO I tried that on a HP testdrive machine. While the _ctypes extension buils fine with GCC (*), it does indeed not compile with the native C compiler. But cc not understanding __attribute__ is only the first problem; if it is removed there are lots of other compilation problems. Unless someone can provide a patch, I'll close this as 'won't fix'. (*) _ctypes_test.so is also built but fails to load as shared library, because the symbol __divsf3 is not defined. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1648957&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1669331 ] document that shutil.copyfileobj does not seek()
Bugs item #1669331, was opened at 2007-02-26 17:53 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1669331&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Steven Bethard (bediviere) Assigned to: Nobody/Anonymous (nobody) Summary: document that shutil.copyfileobj does not seek() Initial Comment: This should close bug 1656578 which asks for documentation that shutil.copyfileobj() copies only from the current file position to the end of the file. While this is standard behavior for pretty much any function that accepts a file-like object, the phrase "the contents of the file-like object" could be confusing. The patch adds a little clarification text. -- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-07 09:35 Message: Logged In: YES user_id=849994 Originator: NO Committed as rev. 54202, 54203 (2.5). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1669331&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1656578 ] shutil.copyfileobj description is incomplete
Bugs item #1656578, was opened at 2007-02-10 05:37 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1656578&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Witten (herrwitten) Assigned to: Nobody/Anonymous (nobody) Summary: shutil.copyfileobj description is incomplete Initial Comment: shutil.copyfileobj reads the source's data starting from the source's current file position. Thus, a user must issue seek(0) in order to have all of the source file object's contents read. This needs to be documented. -- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-07 09:35 Message: Logged In: YES user_id=849994 Originator: NO Patch #1669331 fixed this. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1656578&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1115886 ] os.path.splitext don't handle unix hidden file correctly
Bugs item #1115886, was opened at 2005-02-04 02:27
Message generated for change (Comment added) made by loewis
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1115886&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Jeong-Min Lee (falsetru)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.path.splitext don't handle unix hidden file correctly
Initial Comment:
I expected this.
>>> os.path.splitext('/path/to/.Hiddenfile')
('/path/to/.Hiddenfile', '')
but got this.
>>> os.path.splitext('/path/to/.Hiddenfile')
('/path/to/', '.Hiddenfile')
--
>Comment By: Martin v. Löwis (loewis)
Date: 2007-03-07 12:05
Message:
Logged In: YES
user_id=21627
Originator: NO
After some discussion on python-dev, I fixed this in r54204.
--
Comment By: Jim Jewett (jimjjewett)
Date: 2007-03-07 00:20
Message:
Logged In: YES
user_id=764593
Originator: NO
1462106 is a patch, though perhaps not the latest.
python-dev is currently debating whether to fix this behavior or maintain
backwards-compatibility.
That suggests that it at least won't be changed in a bugfix version (like
2.4.x), and the group should be changed to 2.6.
--
Comment By: John J Lee (jjlee)
Date: 2005-12-04 15:44
Message:
Logged In: YES
user_id=261020
-1
I hate to be a stick-in-the-mud, but the existing behaviour
is what I would expect, and seems to be regular -- always
picks the last dot:
>>> os.path.splitext('a/b/c/foo.bar')
('a/b/c/foo', '.bar')
>>> os.path.splitext('a/b/c/f.oo.bar')
('a/b/c/f.oo', '.bar')
>>> os.path.splitext('a/b/c/.foo')
('a/b/c/', '.foo')
>>> os.path.splitext('a/b/c/.foo.txt')
('a/b/c/.foo', '.txt')
Changing it would surely break somebody's code too, of course.
--
Comment By: Georg Brandl (birkenfeld)
Date: 2005-06-18 23:05
Message:
Logged In: YES
user_id=1188172
Interestingly, altering the behaviour of splitext in such a
way does not contradict the documentation, which is:
"""
Split the pathname path into a pair (root, ext) such that
root + ext == path, and ext is empty or begins with a period
and contains at most one period.
"""
Personally I'm in favour of this change (on Unix it makes
sense, while on Windows you can hardly find an
"extension-only" file).
--
Comment By: engelbert gruber (grubert)
Date: 2005-06-13 16:12
Message:
Logged In: YES
user_id=147070
from test_posixpath.py ::
self.assertEqual(posixpath.splitext(".ext"), ("", ".ext"))
IMHO should then return (".ext",""). if this is desired ::
if i<=p.rfind('/'):
return p, ''
else:
return p[:i], p[i:]
should do
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1115886&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1550263 ] Enhance and correct unittest's docs (redux)
Bugs item #1550263, was opened at 2006-09-01 02:02
Message generated for change (Comment added) made by gbrandl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1550263&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.4
>Status: Closed
Resolution: Accepted
Priority: 5
Private: No
Submitted By: Collin Winter (collinwinter)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Enhance and correct unittest's docs (redux)
Initial Comment:
Following up on SF #1534922 ("Cleanup/error-correction
for unittest's docs"), this patch adds the following
corrections and clairifications to Doc/lib/libunittest.tex:
1) Add language to the section on
TestLoader.loadTestsFromName() to make it explicit in
what order the "module/test case class/TestSuite
instance/test method within a test case class/callable
object which returns a TestCase or TestSuite instance"
tests are applied.
2) Add language to the section on
TestLoader.getTestCaseNames() to make it explicit that
the method's argument should be a subclass of TestCase.
3) Add language to the docs for TestCase.run() to
clairfying the relationship between TestCase.run() and
TestCase.defaultTestResult().
4) Better specify the purpose of
TestCase.defaultTestResult(). The previous docs were
vague and misleading.
5) Add language to the docs for the TestCase class that
better explains and illustrates the class's purpose and
usage. In particular, docs on the constructor's
optional ``methodName'' parameter were added; this
parameter was previously undocumented.
6) Add a brief mention of TestResult to the "Classes
and functions" section.
7) Add information on the default implementation of
several TestResult methods.
In addition, numerous smaller tweaks to grammar and
phrasing were made.
--
>Comment By: Georg Brandl (gbrandl)
Date: 2007-03-07 11:38
Message:
Logged In: YES
user_id=849994
Originator: NO
Now that there will be no 2.4.x anymore, closing again.
--
Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2006-09-01 04:02
Message:
Logged In: YES
user_id=3066
Re-opening; these should be considered for Python 2.4.4 as well.
--
Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2006-09-01 03:58
Message:
Logged In: YES
user_id=3066
Committed as revisions 51675 (Python 2.5) and 51676 (Python
2.6). Anthony agreed that documentation improvements were
acceptable changes from 2.5 release candidate to 2.5 final.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1550263&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-878275 ] Handle: class MyTest(unittest.TestSuite)
Bugs item #878275, was opened at 2004-01-16 14:22
Message generated for change (Comment added) made by gbrandl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=878275&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 6
Private: No
Submitted By: Raymond Hettinger (rhettinger)
Assigned to: Steve Purcell (purcell)
Summary: Handle: class MyTest(unittest.TestSuite)
Initial Comment:
TestCases are supposed to be derived from
unittest.TestCase; however, if they are derived from
unittest.TestSuite, the traceback is inexplicable and
hard to diagnose:
Traceback (most recent call last):
File "C:/pydev/tmp.py", line 10, in -toplevel-
unittest.TextTestRunner(verbosity=2).run(suite)
File "C:\PY24\lib\unittest.py", line 690, in run
test(result)
File "C:\PY24\lib\unittest.py", line 423, in __call__
test(result)
File "C:\PY24\lib\unittest.py", line 423, in __call__
test(result)
File "C:\PY24\lib\unittest.py", line 423, in __call__
test(result)
TypeError: 'str' object is not callable
Let's either improve the error message or make it
possible to derive from TestSuite.
The above traceback is produced by the following script:
import unittest
class TestStats(unittest.TestSuite):
def testtwo(self):
self.assertEqual(2,2)
suite = unittest.TestSuite()
suite.addTest(unittest.makeSuite(TestStats))
unittest.TextTestRunner(verbosity=2).run(suite)
--
>Comment By: Georg Brandl (gbrandl)
Date: 2007-03-07 11:55
Message:
Logged In: YES
user_id=849994
Originator: NO
Added a few sanity checks in rev. 54207, 54208 (2.5).
--
Comment By: John J Lee (jjlee)
Date: 2005-12-04 19:24
Message:
Logged In: YES
user_id=261020
In fact in jlgijsbers' case (TestSuite class passed to
TestSuite, rather than another bug: TestCase class passed to
TestSuite), that check just pushes the problem back a bit:
import unittest
class TestStats(unittest.TestSuite):
def testtwo(self):
self.assertEqual(2,2)
suite = unittest.TestSuite([TestStats('testtwo')])
unittest.TextTestRunner(verbosity=2).run(suite)
TypeError: 'str' object is not callable
Another test could be added to TestSuite addTest():
if not callable(test): raise TypeError('addTest argument 1
must be callable')
Again, though it does makes the error clearer, it seems
debatable that it's worth the change...
--
Comment By: John J Lee (jjlee)
Date: 2005-12-04 18:52
Message:
Logged In: YES
user_id=261020
Just to be clear: The issue with jlgijsbers' odd error
message (in his 2004-11-07 followup) is not that a TestSuite
is passed to the TestSuite constructor, but rather that he's
passing in a class, not an instance.
The error would show up a bit earlier if a check were added
to TestSuite.addTest():
if type(test) == type: raise TypeError('addTest argument 1
must be instance, not class')
I will post that line as a patch if anyone emails me to
request it!
--
Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-11-07 15:53
Message:
Logged In: YES
user_id=469548
Well, the error message above has been fixed, but here's
another equally confusing variant:
import unittest
class TestStats(unittest.TestSuite):
def testtwo(self):
self.assertEqual(2,2)
suite = unittest.TestSuite([TestStats])
unittest.TextTestRunner(verbosity=2).run(suite)
giving:
Traceback (most recent call last):
File "test-foo.py", line 8, in ?
unittest.TextTestRunner(verbosity=2).run(suite)
File "/home/johannes/python/Lib/unittest.py", line 695, in run
test(result)
File "/home/johannes/python/Lib/unittest.py", line 426, in
__call__
test(result)
File "/home/johannes/python/Lib/unittest.py", line 396, in
__init__
self.addTests(tests)
File "/home/johannes/python/Lib/unittest.py", line 416, in
addTests
for test in tests:
TypeError: iteration over non-sequence
so I'm leaving this open.
--
Comment By: Irmen de Jong (irmen)
Date: 2004-11-07 13:39
Message:
Logged In: YES
user_id=129426
patch is at #1061904
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=878275&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1646728 ] datetime.fromtimestamp fails with negative fractional times
Bugs item #1646728, was opened at 2007-01-28 21:21 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1646728&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: Fixed Priority: 5 Private: No Submitted By: James Henstridge (jhenstridge) Assigned to: Nobody/Anonymous (nobody) Summary: datetime.fromtimestamp fails with negative fractional times Initial Comment: The datetime.fromtimestamp() function works fine with integer timestamps and positive fractional timestamps, but fails if I pass a negative fractional timestamp. For example: >>> import datetime >>> datetime.datetime.fromtimestamp(-1.05) Traceback (most recent call last): File "", line 1, in ValueError: microsecond must be in 0..99 It should return the same result as datetime.fromtimestamp(-1) - timedelta(seconds=.5). The same bug can be triggered in datetime.utcfromtimestamp(). I have been able to reproduce this bug in Python 2.4.4 and Python 2.5 on Linux. -- >Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-07 10:17 Message: Logged In: YES user_id=6380 Originator: NO Thanks! I'm skipping these tests on Windows now. Committed revision 54209. Georgbot, would you be so kind... :-) -- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2007-03-07 02:34 Message: Logged In: YES user_id=1200846 Originator: NO Hello, I'm user of Windows (Now building Python2.5 with VC6) I heard localtime() can only handle positive time_t on windows, so datetime.fromtimestamp() also fails for negative value. >>> datetime.datetime.fromtimestamp(-1.05) Traceback (most recent call last): File "", line 1, in ValueError: timestamp out of range for platform localtime()/gmtime() function >>> datetime.datetime.fromtimestamp(-1) Traceback (most recent call last): File "", line 1, in ValueError: timestamp out of range for platform localtime()/gmtime() function I'll attach workaround for unittest. Probably there is better way skip this test on non-negative platform though :-) Index: Lib/test/test_datetime.py === --- Lib/test/test_datetime.py (revision 54194) +++ Lib/test/test_datetime.py (working copy) @@ -1428,9 +1428,17 @@ def test_negative_float_fromtimestamp(self): # The result is tz-dependent; at least test that this doesn't # fail (like it did before bug 1646728 was fixed). +try: +self.theclass.fromtimestamp(-1) +except ValueError: # cannot handle negative value +return self.theclass.fromtimestamp(-1.05) def test_negative_float_utcfromtimestamp(self): +try: +self.theclass.utcfromtimestamp(-1) +except ValueError: # cannot handle negative value +return d = self.theclass.utcfromtimestamp(-1.05) self.assertEquals(d, self.theclass(1969, 12, 31, 23, 59, 58, 95)) -- Comment By: Georg Brandl (gbrandl) Date: 2007-03-06 13:45 Message: Logged In: YES user_id=849994 Originator: NO Not from me, no Windows around. -- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-06 13:34 Message: Logged In: YES user_id=6380 Originator: NO That's too bad. More details? -- Comment By: Georg Brandl (gbrandl) Date: 2007-03-06 13:15 Message: Logged In: YES user_id=849994 Originator: NO Though, the new tests seem to fail on Windows (I noticed that only after backporting, since most other buildbot failures were due to the cmp/key problem in setup.py). -- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-06 12:59 Message: Logged In: YES user_id=6380 Originator: NO Georgbot backported this to 2.5. -- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-06 10:50 Message: Logged In: YES user_id=6380 Originator: NO Committed revision 54167. I'm leaving this open until it's been backported to the 2.5 branch. -- Comment By: James Henstridge (jhenstridge) Date: 2007-03-05 19:03 Message: Logged In: YES user_id=146903 Originator: YES I just tried the patch, and can confirm that it fixes the problem with datetime.fromtimestamp() and datetime.utcfromtimestamp(). The logic in the patch looks correct. -
[ python-Bugs-1646728 ] datetime.fromtimestamp fails with negative fractional times
Bugs item #1646728, was opened at 2007-01-29 02:21 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1646728&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 >Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: James Henstridge (jhenstridge) Assigned to: Nobody/Anonymous (nobody) Summary: datetime.fromtimestamp fails with negative fractional times Initial Comment: The datetime.fromtimestamp() function works fine with integer timestamps and positive fractional timestamps, but fails if I pass a negative fractional timestamp. For example: >>> import datetime >>> datetime.datetime.fromtimestamp(-1.05) Traceback (most recent call last): File "", line 1, in ValueError: microsecond must be in 0..99 It should return the same result as datetime.fromtimestamp(-1) - timedelta(seconds=.5). The same bug can be triggered in datetime.utcfromtimestamp(). I have been able to reproduce this bug in Python 2.4.4 and Python 2.5 on Linux. -- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-07 16:13 Message: Logged In: YES user_id=849994 Originator: NO Certainly. Backported in rev. 54211. -- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-07 15:17 Message: Logged In: YES user_id=6380 Originator: NO Thanks! I'm skipping these tests on Windows now. Committed revision 54209. Georgbot, would you be so kind... :-) -- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2007-03-07 07:34 Message: Logged In: YES user_id=1200846 Originator: NO Hello, I'm user of Windows (Now building Python2.5 with VC6) I heard localtime() can only handle positive time_t on windows, so datetime.fromtimestamp() also fails for negative value. >>> datetime.datetime.fromtimestamp(-1.05) Traceback (most recent call last): File "", line 1, in ValueError: timestamp out of range for platform localtime()/gmtime() function >>> datetime.datetime.fromtimestamp(-1) Traceback (most recent call last): File "", line 1, in ValueError: timestamp out of range for platform localtime()/gmtime() function I'll attach workaround for unittest. Probably there is better way skip this test on non-negative platform though :-) Index: Lib/test/test_datetime.py === --- Lib/test/test_datetime.py (revision 54194) +++ Lib/test/test_datetime.py (working copy) @@ -1428,9 +1428,17 @@ def test_negative_float_fromtimestamp(self): # The result is tz-dependent; at least test that this doesn't # fail (like it did before bug 1646728 was fixed). +try: +self.theclass.fromtimestamp(-1) +except ValueError: # cannot handle negative value +return self.theclass.fromtimestamp(-1.05) def test_negative_float_utcfromtimestamp(self): +try: +self.theclass.utcfromtimestamp(-1) +except ValueError: # cannot handle negative value +return d = self.theclass.utcfromtimestamp(-1.05) self.assertEquals(d, self.theclass(1969, 12, 31, 23, 59, 58, 95)) -- Comment By: Georg Brandl (gbrandl) Date: 2007-03-06 18:45 Message: Logged In: YES user_id=849994 Originator: NO Not from me, no Windows around. -- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-06 18:34 Message: Logged In: YES user_id=6380 Originator: NO That's too bad. More details? -- Comment By: Georg Brandl (gbrandl) Date: 2007-03-06 18:15 Message: Logged In: YES user_id=849994 Originator: NO Though, the new tests seem to fail on Windows (I noticed that only after backporting, since most other buildbot failures were due to the cmp/key problem in setup.py). -- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-06 17:59 Message: Logged In: YES user_id=6380 Originator: NO Georgbot backported this to 2.5. -- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-06 15:50 Message: Logged In: YES user_id=6380 Originator: NO Committed revision 54167. I'm leaving this open until it's been backported to the 2.5 branch. -- Comment By: James Henstridge (jhenstridge) Date: 2007-03-06 00:03 Messag
[ python-Bugs-1675967 ] Python2.5 can't read a (complex) pickle build by python2.4
Bugs item #1675967, was opened at 2007-03-07 18:16
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1675967&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Michael Vogt (mvo)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python2.5 can't read a (complex) pickle build by python2.4
Initial Comment:
Part of gnome-app-install in ubuntu is a pickle data structure cache. If I
create this pickle with python 2.4 and read it later with 2.5. I get the
following error:
$ python2.5 -c 'import pickle;
pickle.load(open("/var/cache/app-install/menu.p"))'
/usr/lib/python2.5/pickle.py:1124: DeprecationWarning: The sre module is
deprecated, please import re.
__import__(module)
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python2.5/pickle.py", line 1370, in load
return Unpickler(file).load()
File "/usr/lib/python2.5/pickle.py", line 858, in load
dispatch[key](self)
File "/usr/lib/python2.5/pickle.py", line 1090, in load_global
klass = self.find_class(module, name)
File "/usr/lib/python2.5/pickle.py", line 1126, in find_class
klass = getattr(mod, name)
AttributeError: 'module' object has no attribute '_compile'
With:
$ python2.4 -c 'import pickle;
pickle.load(open("/var/cache/app-install/menu.p"))'
[EMAIL PROTECTED] ~ $
It loads just fine.
The test pickle can be found here:
http://people.ubuntu.com/~mvo/gnome-app-install/menu.p.gz
Cheers,
Michael
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1675967&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-974757 ] urllib2's HTTPPasswordMgr and uri's with port numbers
Bugs item #974757, was opened at 2004-06-17 09:09 Message generated for change (Comment added) made by akrherz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=974757&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Chris Withers (fresh) Assigned to: Jeremy Hylton (jhylton) Summary: urllib2's HTTPPasswordMgr and uri's with port numbers Initial Comment: Python 2.3.3 The title just about sums it up. If you add a password with a uri containing a port number using add_password, then it probably won't be returned by find_user_password. That's not right ;-) -- Comment By: Daryl Herzmann (akrherz) Date: 2007-03-07 13:27 Message: Logged In: YES user_id=341971 Originator: NO Just for anybody like me stumbling into this. It isn't fixed in python 2.4.3 and only works in python 2.5 . Another reason to upgrade :) -- Comment By: Jeremy Hylton (jhylton) Date: 2004-12-22 08:27 Message: Logged In: YES user_id=31392 Fixed in rev 1.78 of urllib2 -- Comment By: Chris Withers (fresh) Date: 2004-11-05 04:08 Message: Logged In: YES user_id=24723 This patch fixes it for me: --- urllib2.py.cvs Fri Nov 05 10:02:26 2004 +++ urllib2.py.new Fri Nov 05 10:05:48 2004 @@ -720,7 +720,7 @@ return self.retry_http_basic_auth(host, req, realm) def retry_http_basic_auth(self, host, req, realm): -user,pw = self.passwd.find_user_password(realm, host) +user,pw = self.passwd.find_user_password(realm, req.get_full_url()) if pw is not None: raw = "%s:%s" % (user, pw) auth = 'Basic %s' % base64.encodestring(raw).strip() -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=974757&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1675967 ] Python2.5 can't read a (complex) pickle build by python2.4
Bugs item #1675967, was opened at 2007-03-07 19:16
Message generated for change (Comment added) made by zseil
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1675967&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Michael Vogt (mvo)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python2.5 can't read a (complex) pickle build by python2.4
Initial Comment:
Part of gnome-app-install in ubuntu is a pickle data structure cache. If I
create this pickle with python 2.4 and read it later with 2.5. I get the
following error:
$ python2.5 -c 'import pickle;
pickle.load(open("/var/cache/app-install/menu.p"))'
/usr/lib/python2.5/pickle.py:1124: DeprecationWarning: The sre module is
deprecated, please import re.
__import__(module)
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python2.5/pickle.py", line 1370, in load
return Unpickler(file).load()
File "/usr/lib/python2.5/pickle.py", line 858, in load
dispatch[key](self)
File "/usr/lib/python2.5/pickle.py", line 1090, in load_global
klass = self.find_class(module, name)
File "/usr/lib/python2.5/pickle.py", line 1126, in find_class
klass = getattr(mod, name)
AttributeError: 'module' object has no attribute '_compile'
With:
$ python2.4 -c 'import pickle;
pickle.load(open("/var/cache/app-install/menu.p"))'
[EMAIL PROTECTED] ~ $
It loads just fine.
The test pickle can be found here:
http://people.ubuntu.com/~mvo/gnome-app-install/menu.p.gz
Cheers,
Michael
--
Comment By: Žiga Seilnacht (zseil)
Date: 2007-03-07 20:43
Message:
Logged In: YES
user_id=1326842
Originator: NO
This happens because of SRE_Pattern objects in jour pickle.
The sre module was renamed to re in Python 2.5, but the
old pickles still expect the _compile function in sre module.
I posted the patch here:
http://freeweb.siol.net/chollus/
Could you try if it fixes the problem for you and in that
case, attach it to this report?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1675967&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-665194 ] datetime-RFC2822 roundtripping
Feature Requests item #665194, was opened at 2003-01-09 19:24 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=665194&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Walter Dörwald (doerwalter) Assigned to: Nobody/Anonymous (nobody) Summary: datetime-RFC2822 roundtripping Initial Comment: It would be good to have a simply way to convert between datetime objects and RFC2822 style strings. From string to datetime is easy with datetime.datetime(*email.Utils.parsedate(m)[:7]) (but this drops the timezone), but the other direction seems impossible. email.Utils.formatdate takes a timestamp argument, but AFAICT there's no way to get a timestamp out of a datetime object. Of course the best solution (ignoring backwards compatibility) would be for parsedate und formatdate to return/accept datetime objects or for datetime to have the appropriate methods. -- >Comment By: Walter Dörwald (doerwalter) Date: 2007-03-07 20:55 Message: Logged In: YES user_id=89016 Originator: YES Here is a patch that implements to formatting part. It adds a method mimeformat() to the datetime class. The datetime object must have a tzinfo for this to work. File Added: datetime-mimeformat.diff -- Comment By: A.M. Kuchling (akuchling) Date: 2006-12-21 16:16 Message: Logged In: YES user_id=11375 Originator: NO Moving to feature requests. -- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-26 18:56 Message: Logged In: YES user_id=89016 time.strptime() is locale aware, but RFC1123 & RFC822 require english day and month names, so time.strptime() can't be used as-is. (And of course time.strptime() only works for formatting, not for parsing) -- Comment By: Brett Cannon (bcannon) Date: 2003-05-24 00:46 Message: Logged In: YES user_id=357491 time.strptime doesn't solve your problem? -- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-13 14:05 Message: Logged In: YES user_id=89016 totimestamp() should be the inverse of fromtimestamp(), i.e. foo.totimestamp() should be the same as time.mktime(foo.timetuple()). datetime.datetime.totimestamp() should raise OverflowError iff time.mktime() raises OverflowError. But as this may lose precision, I'd say it would be better, if datetime supported RFC1123 conversion directly, i.e. two methods frommime() and tomime(), that parse and format strings like "Sun, 06 Nov 1994 08:49:37 GMT" (what rfc822.parsedate() and rfc822.formatdate() do) -- Comment By: Tim Peters (tim_one) Date: 2003-01-11 17:32 Message: Logged In: YES user_id=31435 Define what totimestamp() should do. The range of timestamps supported by the *platform* C library (and so indirectly by Python's time module) isn't defined by any standard, and isn't easily discoverable either. It may or may not work before 1970, may or may not after 2038. datetime covers days far outside that range. Note that even a double doesn't have enough bits of precision to cover the full range of datetime values, either. In contrast, ordinals are wholly under Python's control, so we can promise surprise-free conversion in both directions. All we can promise about timestamps is that if the platform supports a timestamp for a time in datetime's range, datetime can make sense of it. -- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-11 13:33 Message: Logged In: YES user_id=89016 OK, I'll mark this a feature request. datetime has fromordinal() and toordinal(), it has fromtimestamp(), so I'd say a totimestamp() method would be a logical addition. -- Comment By: Tim Peters (tim_one) Date: 2003-01-11 06:10 Message: Logged In: YES user_id=31435 You can get a timestamp like so: >>> time.mktime(datetime.date(2002, 1, 1).timetuple()) 1009861200.0 >>> The dates for which this works depends on the platform mktime implementation, though. BTW, this sounds a lot more like a new feature request than a bug! -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=665194&group_id=5470 ___ Python-bugs-list ma
[ python-Bugs-1676121 ] Problem linking to readline lib on x86(64) Solaris
Bugs item #1676121, was opened at 2007-03-07 17:07 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1676121&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Alexander Belopolsky (belopolsky) Assigned to: Nobody/Anonymous (nobody) Summary: Problem linking to readline lib on x86(64) Solaris Initial Comment: Configuring with ./configure --with-gcc="gcc -m64 -L/usr/sfw/lib/64 -R/usr/sfw/lib/64" where 64bit libreadline is found in /usr/sfw/lib/64, configure script fails to realize that readline lib is present. I was able to fix the problem by editing config script manually as follows: $ diff configure~ configure 20744c20744 < if test "$ac_cv_have_readline_readline" = no --- > if test "$ac_cv_lib_readline_readline" = no 20747c20747 < echo "$as_me:$LINENO: checking for readline in -ltermcap" >&5 --- > echo "$as_me:$LINENO: checking for readline in -lreadline -ltermcap" >&5 20753c20753 < LIBS="-ltermcap $LIBS" --- > LIBS="-lreadline -ltermcap $LIBS" A proper fix would be to change configure.in, but I don't know enough about autoconf to submit a proper patch. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1676121&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1647654 ] No obvious and correct way to get the time zone offset
Bugs item #1647654, was opened at 2007-01-30 06:48 Message generated for change (Comment added) made by pboddie You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1647654&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: James Henstridge (jhenstridge) Assigned to: Nobody/Anonymous (nobody) Summary: No obvious and correct way to get the time zone offset Initial Comment: It would be nice if the Python time module provided an obvious way to get the local time UTC offset for an arbitrary time stamp. The existing constants included in the module are not sufficient to correctly determine this value. As context, the Bazaar version control system (written in Python), the local time UTC offset is recorded in a commit. The method used in releases prior to 0.14 made use of the "daylight", "timezone" and "altzone" constants from the time module like this: if time.localtime(t).tm_isdst and time.daylight: return -time.altzone else: return -time.timezone This worked most of the time, but would occasionally give incorrect results. On Linux, the local time system can handle different daylight saving rules for different spans of years. For years where the rules change, these constants can provide incorrect data. Furthermore, they may be incorrect for time stamps in the past. I personally ran into this problem last December when Western Australia adopted daylight saving -- time.altzone gave an incorrect value until the start of 2007. Having a function in the standard library to calculate this offset would solve the problem. The implementation we ended up with for Bazaar was: offset = datetime.fromtimestamp(t) - datetime.utcfromtimestamp(t) return offset.days * 86400 + offset.seconds Another alternative would be to expose tm_gmtoff on time tuples (perhaps using the above code to synthesise it on platforms that don't have the field). -- Comment By: Paul Boddie (pboddie) Date: 2007-03-08 01:30 Message: Logged In: YES user_id=226443 Originator: NO Patch #1667546 now tries to export tm_gmtoff in a covertly extended time tuple. (I think tm_gmtoff originates from BSD, by the way.) -- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-06 23:39 Message: Logged In: YES user_id=6380 Originator: NO I see. There is code to decide the values for time.timezone, time.altzone and time.daylight that compares tm_gmtoff for Jan 1st of the current year to tm_gmtoff for July 1st; it uses this to decide whether DST is in effect and on which hemisphere you're on. I don't know why I didn't think of checking the tm_isdst flag instead, but either way the code would have failed for you prior to Jan 1st 07, because it could not have seen a difference if your timezone database was correct. You're just lucky you weren't running CYGWIN; the code inside #ifdef __CYGWIN__ doesn't even entertain the possibility that there's life possible on the Southern hemisphere. ;-) I think we should do two things; (a) export tm_zone and tm_gmtoff if they exist; (b) change the code that probes Jan 1st and Jul 1st of the current year to instead probe 4-6 spots starting today and covering the year forward. Unfortunately tm_zone and tm_gmtoff appear glibc inventions, so for supporting Solaris, Windows etc. I think we still need these. We really could use a module that accesses the entire timezone database but that's even more platform specific. If you want this to happen, please lobby for someone to help out on python-dev or c.l.py; I'm kind of overcommitted. :-) -- Comment By: James Henstridge (jhenstridge) Date: 2007-03-05 11:03 Message: Logged In: YES user_id=146903 Originator: YES In Western Australia, a 3 year daylight saving trial was introduced starting on 3rd December 2006. Prior to that, we had no daylight saving shifts (the previous time we had daylight saving was 15 years ago in another trial). Since there was no daylight savings for 1st January 2006 and 1st July 2006, time.timezone and time.altzone were both equal to -28800 (UTC+8) for Python interpreters run in 2006. I am sure that I had the tzdata updates installed: my computer displayed the correct time, and listed the UTC offset as +0900 in December. Creating a time tuple for a date in December 2006 had the tm_isdst flag set to 1. If I was programming this in C, I'd use the tm_gmtoff field of "struct tm" if it was available. On platforms that don't provide tm_gmtoff, other platform specific methods would be needed (e.g. using timezone/altzone). The other alternati
[ python-Bugs-1671411 ] python code fails with "MemoryError" on HP-UX 11.11 PA_RISC
Bugs item #1671411, was opened at 2007-03-01 11:27
Message generated for change (Comment added) made by shashikala
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1671411&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Performance
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: shashi (shashikala)
Assigned to: Nobody/Anonymous (nobody)
Summary: python code fails with "MemoryError" on HP-UX 11.11 PA_RISC
Initial Comment:
Hi,
Python-2.5 code fails with "MemoryError". This is happening only on one
system, PA-RISC running HP-UX 11.11.Failing system has 12 GB of RAM installed,
non-failing system has 8 GB.
1) spark 9GB phys mem(Python is working fine)
2) stalker 12GB phys mem (that has problem with python 2.5 )
please assist me in this.
Thanks in advance
Shashi
--
>Comment By: shashi (shashikala)
Date: 2007-03-08 10:57
Message:
Logged In: YES
user_id=1506183
Originator: YES
Hi ,
I added "import gc" and "gc.collect()" , it worked out fine , I dint get
any further MemoryError is this the correct approach , please let me know
about the same.
Thanks and Reagrds,
shashi
--
Comment By: Martin v. Löwis (loewis)
Date: 2007-03-02 04:34
Message:
Logged In: YES
user_id=21627
Originator: NO
Can you also provide a gdb/dbx backtrace of where the problem occurred?
--
Comment By: shashi (shashikala)
Date: 2007-03-01 18:47
Message:
Logged In: YES
user_id=1506183
Originator: YES
File Added: Pythonmemoryerror.txt
--
Comment By: Martin v. Löwis (loewis)
Date: 2007-03-01 13:38
Message:
Logged In: YES
user_id=21627
Originator: NO
This tracker is not about assistance. If at all, we need you to assist
us.
Can you please report more details, like stack traces, causes of the
crash, patches? If not, I think there is little we can do about this report
("it crashes" is pretty unspecific).
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1671411&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1673409 ] datetime module missing some important methods
Feature Requests item #1673409, was opened at 2007-03-04 06:59 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1673409&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Python Library >Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jon Ribbens (jribbens) >Assigned to: Tim Peters (tim_one) Summary: datetime module missing some important methods Initial Comment: The datetime module is missing some important methods for interacting with timestamps (i.e. seconds since 1970-01-01T00:00:00). There are methods to convert from a timestamp, i.e. date.fromtimestamp and datetime.fromtimestamp, but there are no methods to convert back. In addition, timedelta has no method for returning the number of seconds it represents (i.e. days*86400+seconds+microseconds/100). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1673409&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1643369 ] function breakpoints in pdb
Bugs item #1643369, was opened at 2007-01-24 02:22 Message generated for change (Comment added) made by isandler You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1643369&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 6 Private: No Submitted By: decitre (decitre) Assigned to: Nobody/Anonymous (nobody) Summary: function breakpoints in pdb Initial Comment: pdb.Pdb.find_function method is not able to recognize class methods, since the regular expression it uses only looks for "def" at beginning of lines. Please replace r'def\s+%s\s*[(]' % funcname with r'\s*def\s+%s\s*[(]' % funcname test file in attachment. this file shows that pdb can set a breakpoint on foo but not on readline function. Regards, Emmanuel www.e-rsatz.info -- Comment By: Ilya Sandler (isandler) Date: 2007-03-07 22:25 Message: Logged In: YES user_id=971153 Originator: NO I think it's a bit more complicated than it seems: it's more than common for different classes to have methods with the same name. So looking for "\s*def func" will just grab the first matching method...Which is probably not what one would want...And dealing with multiple matches might be more hassle than it's worth.. So maybe the current behaviour should be kept as is NOTE: you CAN currently set breakpoints in methods by doing b Class.method -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1643369&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
