[ python-Bugs-1514451 ] zipfile "append" mode should create a file if not present
Bugs item #1514451, was opened at 2006-06-29 18:42 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1514451&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: Ritesh Raj Sarraf (riteshsarraf) Assigned to: Nobody/Anonymous (nobody) Summary: zipfile "append" mode should create a file if not present Initial Comment: The line filename = zipfile.ZipFile(zip_file_name, "a") throws an exception if the given filename is not present already. Shouldn't it create a file (in case one is not there) since it is "append" mode ?? It's throwing an OSError Exception stating "No such file/directory". Normal convention has been that when opening a file in append mode, if the file is not present a new file is created. Why is this non-standard? -- >Comment By: Martin v. Löwis (loewis) Date: 2007-02-13 11:10 Message: Logged In: YES user_id=21627 Originator: NO Technically, this is not a bug, as the documentation clearly states that 'a' should open existing files. For 2.6, the behavior is changed with said patch. -- Comment By: Gregory P. Smith (greg) Date: 2006-07-08 19:38 Message: Logged In: YES user_id=413 I agree. append semantics generally mean append or create. +1 from me on fixing this bug. if any existing code is depending on the side effect from opening a zip file in 'a' mode to tell them that it doesn't already exist this change would break that; but I'd argue that such code is already broken and should be cleaned up. -- Comment By: Thomas Lee (krumms) Date: 2006-07-06 04:31 Message: Logged In: YES user_id=315535 Patch #1517891 resolves this. See: http://sourceforge.net/tracker/index.php?func=detail&aid=1517891&group_id=5470&atid=305470 Waiting for review. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1514451&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1658794 ] This shouldn't be there: Note that this code that uses...
Bugs item #1658794, was opened at 2007-02-13 11:29 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=1658794&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: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Alf Lervåg (alfborge) Assigned to: Nobody/Anonymous (nobody) Summary: This shouldn't be there: Note that this code that uses... Initial Comment: In 21.2.1 Background, details, hints, tips and caveats; we have the following paragraph: The case conversion functions in the string module are affected by the locale settings. When a call to the setlocale() function changes the LC_CTYPE settings, the variables string.lowercase, string.uppercase and string.letters are recalculated. Note that this code that uses these variable through `from ... import ...', e.g. from string import letters, is not affected by subsequent setlocale() calls. I can't make sense of the last sentence unless I pretend that "this" shouldn't be there, i.e. Note that code that uses these variable(s?) through `from ... (...). -- Kind regards, Alf Lervåg -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1658794&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1656559 ] I think, I have found this bug on time.mktime()
Bugs item #1656559, was opened at 2007-02-10 03:41 Message generated for change (Comment added) made by sergiomb You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1656559&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: Closed Resolution: Works For Me Priority: 5 Private: No Submitted By: Sérgio Monteiro Basto (sergiomb) Assigned to: Nobody/Anonymous (nobody) Summary: I think, I have found this bug on time.mktime() Initial Comment: well, I think, I have found this bug on time.mktime() for dates less than 1976-09-26 when I do stringtotime of 1976-09-25 print "timeint %d" % time.mktime(__extract_date(m) + __extract_time(m) + (0, 0, 0)) extract date = 1976 9 25 extract time = 0 0 0 timeint 212454000 and timetostring(212454000) = 1976-09-24T23:00:00Z !? To be honest the date that kept me the action was the 1-1-1970 that appears 31-12-1969. After timetostring(stringtotime(date))) I made the test and time.mktime got a bug when date is less than 1976-09-26 see: for 1976-09-27T00:00:00Z time.mktime gives 212630400 for 1976-09-26T00:00:00Z time.mktime gives 212544000 for 1976-09-25T00:00:00Z time.mktime gives 212454000 212630400 - 212544000 = 86400 (seconds) , one day correct ! but 212544000 - 212454000 = 9 (seconds), one day more 3600 (seconds), more one hour ?!? -- Sérgio M. B. -- >Comment By: Sérgio Monteiro Basto (sergiomb) Date: 2007-02-13 11:06 Message: Logged In: YES user_id=4882 Originator: YES here with ubuntu 6.10 with python 2.4.4c1 >>> import time >>> time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0)) 9.0 -- Comment By: Martin v. Löwis (loewis) Date: 2007-02-13 05:57 Message: Logged In: YES user_id=21627 Originator: NO Looks like an FC6 bug to me (either in their C library, or in their Python port). On Debian 3.1, Python 2.4.1, I also get 86400.0. Please report this to Redhat; I'm closing this as "works for me". If you stil think there is a bug in Python, please point to the exact source that you think is erroneous, and the change that should be made. -- Comment By: Sérgio Monteiro Basto (sergiomb) Date: 2007-02-12 22:37 Message: Logged In: YES user_id=4882 Originator: YES python-2.4.4-1.fc6 >>> import time >>> time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0)) 9.0 -- Comment By: Martin v. Löwis (loewis) Date: 2007-02-12 12:38 Message: Logged In: YES user_id=21627 Originator: NO I can't reproduce this problem. On my system (OSX), I get >>> time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0)) 86400.0 What system are you using? What Python version? What timezone are you in? -- Comment By: Georg Brandl (gbrandl) Date: 2007-02-10 15:06 Message: Logged In: YES user_id=849994 Originator: NO This appears to be a timezone/DST issue: on Sept. 26, 1976 Daylight Saving Time ended at least in the European Union. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1656559&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1656559 ] I think, I have found this bug on time.mktime()
Bugs item #1656559, was opened at 2007-02-10 03:41 Message generated for change (Settings changed) made by sergiomb You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1656559&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: 6 Private: No Submitted By: Sérgio Monteiro Basto (sergiomb) Assigned to: Nobody/Anonymous (nobody) Summary: I think, I have found this bug on time.mktime() Initial Comment: well, I think, I have found this bug on time.mktime() for dates less than 1976-09-26 when I do stringtotime of 1976-09-25 print "timeint %d" % time.mktime(__extract_date(m) + __extract_time(m) + (0, 0, 0)) extract date = 1976 9 25 extract time = 0 0 0 timeint 212454000 and timetostring(212454000) = 1976-09-24T23:00:00Z !? To be honest the date that kept me the action was the 1-1-1970 that appears 31-12-1969. After timetostring(stringtotime(date))) I made the test and time.mktime got a bug when date is less than 1976-09-26 see: for 1976-09-27T00:00:00Z time.mktime gives 212630400 for 1976-09-26T00:00:00Z time.mktime gives 212544000 for 1976-09-25T00:00:00Z time.mktime gives 212454000 212630400 - 212544000 = 86400 (seconds) , one day correct ! but 212544000 - 212454000 = 9 (seconds), one day more 3600 (seconds), more one hour ?!? -- Sérgio M. B. -- Comment By: Sérgio Monteiro Basto (sergiomb) Date: 2007-02-13 11:06 Message: Logged In: YES user_id=4882 Originator: YES here with ubuntu 6.10 with python 2.4.4c1 >>> import time >>> time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0)) 9.0 -- Comment By: Martin v. Löwis (loewis) Date: 2007-02-13 05:57 Message: Logged In: YES user_id=21627 Originator: NO Looks like an FC6 bug to me (either in their C library, or in their Python port). On Debian 3.1, Python 2.4.1, I also get 86400.0. Please report this to Redhat; I'm closing this as "works for me". If you stil think there is a bug in Python, please point to the exact source that you think is erroneous, and the change that should be made. -- Comment By: Sérgio Monteiro Basto (sergiomb) Date: 2007-02-12 22:37 Message: Logged In: YES user_id=4882 Originator: YES python-2.4.4-1.fc6 >>> import time >>> time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0)) 9.0 -- Comment By: Martin v. Löwis (loewis) Date: 2007-02-12 12:38 Message: Logged In: YES user_id=21627 Originator: NO I can't reproduce this problem. On my system (OSX), I get >>> time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0)) 86400.0 What system are you using? What Python version? What timezone are you in? -- Comment By: Georg Brandl (gbrandl) Date: 2007-02-10 15:06 Message: Logged In: YES user_id=849994 Originator: NO This appears to be a timezone/DST issue: on Sept. 26, 1976 Daylight Saving Time ended at least in the European Union. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1656559&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1656559 ] I think, I have found this bug on time.mktime()
Bugs item #1656559, was opened at 2007-02-10 03:41 Message generated for change (Comment added) made by sergiomb You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1656559&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: 6 Private: No Submitted By: Sérgio Monteiro Basto (sergiomb) Assigned to: Nobody/Anonymous (nobody) Summary: I think, I have found this bug on time.mktime() Initial Comment: well, I think, I have found this bug on time.mktime() for dates less than 1976-09-26 when I do stringtotime of 1976-09-25 print "timeint %d" % time.mktime(__extract_date(m) + __extract_time(m) + (0, 0, 0)) extract date = 1976 9 25 extract time = 0 0 0 timeint 212454000 and timetostring(212454000) = 1976-09-24T23:00:00Z !? To be honest the date that kept me the action was the 1-1-1970 that appears 31-12-1969. After timetostring(stringtotime(date))) I made the test and time.mktime got a bug when date is less than 1976-09-26 see: for 1976-09-27T00:00:00Z time.mktime gives 212630400 for 1976-09-26T00:00:00Z time.mktime gives 212544000 for 1976-09-25T00:00:00Z time.mktime gives 212454000 212630400 - 212544000 = 86400 (seconds) , one day correct ! but 212544000 - 212454000 = 9 (seconds), one day more 3600 (seconds), more one hour ?!? -- Sérgio M. B. -- >Comment By: Sérgio Monteiro Basto (sergiomb) Date: 2007-02-13 11:18 Message: Logged In: YES user_id=4882 Originator: YES here with ubuntu 5.16 with python 2.4.2 kernel-2.6.12 >>> import time >>> time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0)) 9.0 >>> time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0)) 86400.0 >>> time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0)) 86400.0 -- Comment By: Sérgio Monteiro Basto (sergiomb) Date: 2007-02-13 11:06 Message: Logged In: YES user_id=4882 Originator: YES here with ubuntu 6.10 with python 2.4.4c1 >>> import time >>> time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0)) 9.0 -- Comment By: Martin v. Löwis (loewis) Date: 2007-02-13 05:57 Message: Logged In: YES user_id=21627 Originator: NO Looks like an FC6 bug to me (either in their C library, or in their Python port). On Debian 3.1, Python 2.4.1, I also get 86400.0. Please report this to Redhat; I'm closing this as "works for me". If you stil think there is a bug in Python, please point to the exact source that you think is erroneous, and the change that should be made. -- Comment By: Sérgio Monteiro Basto (sergiomb) Date: 2007-02-12 22:37 Message: Logged In: YES user_id=4882 Originator: YES python-2.4.4-1.fc6 >>> import time >>> time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0)) 9.0 -- Comment By: Martin v. Löwis (loewis) Date: 2007-02-12 12:38 Message: Logged In: YES user_id=21627 Originator: NO I can't reproduce this problem. On my system (OSX), I get >>> time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0)) 86400.0 What system are you using? What Python version? What timezone are you in? -- Comment By: Georg Brandl (gbrandl) Date: 2007-02-10 15:06 Message: Logged In: YES user_id=849994 Originator: NO This appears to be a timezone/DST issue: on Sept. 26, 1976 Daylight Saving Time ended at least in the European Union. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1656559&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1656559 ] I think, I have found this bug on time.mktime()
Bugs item #1656559, was opened at 2007-02-10 03:41 Message generated for change (Comment added) made by sergiomb You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1656559&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: 6 Private: No Submitted By: Sérgio Monteiro Basto (sergiomb) Assigned to: Nobody/Anonymous (nobody) Summary: I think, I have found this bug on time.mktime() Initial Comment: well, I think, I have found this bug on time.mktime() for dates less than 1976-09-26 when I do stringtotime of 1976-09-25 print "timeint %d" % time.mktime(__extract_date(m) + __extract_time(m) + (0, 0, 0)) extract date = 1976 9 25 extract time = 0 0 0 timeint 212454000 and timetostring(212454000) = 1976-09-24T23:00:00Z !? To be honest the date that kept me the action was the 1-1-1970 that appears 31-12-1969. After timetostring(stringtotime(date))) I made the test and time.mktime got a bug when date is less than 1976-09-26 see: for 1976-09-27T00:00:00Z time.mktime gives 212630400 for 1976-09-26T00:00:00Z time.mktime gives 212544000 for 1976-09-25T00:00:00Z time.mktime gives 212454000 212630400 - 212544000 = 86400 (seconds) , one day correct ! but 212544000 - 212454000 = 9 (seconds), one day more 3600 (seconds), more one hour ?!? -- Sérgio M. B. -- >Comment By: Sérgio Monteiro Basto (sergiomb) Date: 2007-02-13 11:19 Message: Logged In: YES user_id=4882 Originator: YES on my FC6 same first time >>> time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0)) 9.0 second and third time >>> time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0)) 86400.0 >>> time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0)) 86400.0 -- Comment By: Sérgio Monteiro Basto (sergiomb) Date: 2007-02-13 11:18 Message: Logged In: YES user_id=4882 Originator: YES here with ubuntu 5.16 with python 2.4.2 kernel-2.6.12 >>> import time >>> time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0)) 9.0 >>> time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0)) 86400.0 >>> time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0)) 86400.0 -- Comment By: Sérgio Monteiro Basto (sergiomb) Date: 2007-02-13 11:06 Message: Logged In: YES user_id=4882 Originator: YES here with ubuntu 6.10 with python 2.4.4c1 >>> import time >>> time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0)) 9.0 -- Comment By: Martin v. Löwis (loewis) Date: 2007-02-13 05:57 Message: Logged In: YES user_id=21627 Originator: NO Looks like an FC6 bug to me (either in their C library, or in their Python port). On Debian 3.1, Python 2.4.1, I also get 86400.0. Please report this to Redhat; I'm closing this as "works for me". If you stil think there is a bug in Python, please point to the exact source that you think is erroneous, and the change that should be made. -- Comment By: Sérgio Monteiro Basto (sergiomb) Date: 2007-02-12 22:37 Message: Logged In: YES user_id=4882 Originator: YES python-2.4.4-1.fc6 >>> import time >>> time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0)) 9.0 -- Comment By: Martin v. Löwis (loewis) Date: 2007-02-12 12:38 Message: Logged In: YES user_id=21627 Originator: NO I can't reproduce this problem. On my system (OSX), I get >>> time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0)) 86400.0 What system are you using? What Python version? What timezone are you in? -- Comment By: Georg Brandl (gbrandl) Date: 2007-02-10 15:06 Message: Logged In: YES user_id=849994 Originator: NO This appears to be a timezone/DST issue: on Sept. 26, 1976 Daylight Saving Time ended at least in the European Union. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1656559&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1656559 ] I think, I have found this bug on time.mktime()
Bugs item #1656559, was opened at 2007-02-10 03:41 Message generated for change (Comment added) made by sergiomb You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1656559&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: 6 Private: No Submitted By: Sérgio Monteiro Basto (sergiomb) Assigned to: Nobody/Anonymous (nobody) Summary: I think, I have found this bug on time.mktime() Initial Comment: well, I think, I have found this bug on time.mktime() for dates less than 1976-09-26 when I do stringtotime of 1976-09-25 print "timeint %d" % time.mktime(__extract_date(m) + __extract_time(m) + (0, 0, 0)) extract date = 1976 9 25 extract time = 0 0 0 timeint 212454000 and timetostring(212454000) = 1976-09-24T23:00:00Z !? To be honest the date that kept me the action was the 1-1-1970 that appears 31-12-1969. After timetostring(stringtotime(date))) I made the test and time.mktime got a bug when date is less than 1976-09-26 see: for 1976-09-27T00:00:00Z time.mktime gives 212630400 for 1976-09-26T00:00:00Z time.mktime gives 212544000 for 1976-09-25T00:00:00Z time.mktime gives 212454000 212630400 - 212544000 = 86400 (seconds) , one day correct ! but 212544000 - 212454000 = 9 (seconds), one day more 3600 (seconds), more one hour ?!? -- Sérgio M. B. -- >Comment By: Sérgio Monteiro Basto (sergiomb) Date: 2007-02-13 11:28 Message: Logged In: YES user_id=4882 Originator: YES Very strange ! >>> import time >>> time.mktime((1976,9,26,0,0,0,0,0,0)) 212544000.0 >>> time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0)) 9.0 >>> time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0)) 86400.0 >>> time.mktime((1976,9,26,0,0,0,0,0,0)) 212540400.0 -- Comment By: Sérgio Monteiro Basto (sergiomb) Date: 2007-02-13 11:19 Message: Logged In: YES user_id=4882 Originator: YES on my FC6 same first time >>> time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0)) 9.0 second and third time >>> time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0)) 86400.0 >>> time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0)) 86400.0 -- Comment By: Sérgio Monteiro Basto (sergiomb) Date: 2007-02-13 11:18 Message: Logged In: YES user_id=4882 Originator: YES here with ubuntu 5.16 with python 2.4.2 kernel-2.6.12 >>> import time >>> time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0)) 9.0 >>> time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0)) 86400.0 >>> time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0)) 86400.0 -- Comment By: Sérgio Monteiro Basto (sergiomb) Date: 2007-02-13 11:06 Message: Logged In: YES user_id=4882 Originator: YES here with ubuntu 6.10 with python 2.4.4c1 >>> import time >>> time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0)) 9.0 -- Comment By: Martin v. Löwis (loewis) Date: 2007-02-13 05:57 Message: Logged In: YES user_id=21627 Originator: NO Looks like an FC6 bug to me (either in their C library, or in their Python port). On Debian 3.1, Python 2.4.1, I also get 86400.0. Please report this to Redhat; I'm closing this as "works for me". If you stil think there is a bug in Python, please point to the exact source that you think is erroneous, and the change that should be made. -- Comment By: Sérgio Monteiro Basto (sergiomb) Date: 2007-02-12 22:37 Message: Logged In: YES user_id=4882 Originator: YES python-2.4.4-1.fc6 >>> import time >>> time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0)) 9.0 -- Comment By: Martin v. Löwis (loewis) Date: 2007-02-12 12:38 Message: Logged In: YES user_id=21627 Originator: NO I can't reproduce this problem. On my system (OSX), I get >>> time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0)) 86400.0 What system are you using? What Python version? What timezone are you in? -- Comment By: Georg Brandl (gbrandl) Date: 2007-02-10 15:06 Message: Logged In: YES user_id=849994 Originator: NO This appears to be a timezone/DST issue: on Sept. 26, 1976 Daylight Saving Time ended at least in the European Union. -
[ python-Bugs-1656559 ] I think, I have found this bug on time.mktime()
Bugs item #1656559, was opened at 2007-02-10 04:41 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1656559&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: 6 Private: No Submitted By: Sérgio Monteiro Basto (sergiomb) Assigned to: Nobody/Anonymous (nobody) Summary: I think, I have found this bug on time.mktime() Initial Comment: well, I think, I have found this bug on time.mktime() for dates less than 1976-09-26 when I do stringtotime of 1976-09-25 print "timeint %d" % time.mktime(__extract_date(m) + __extract_time(m) + (0, 0, 0)) extract date = 1976 9 25 extract time = 0 0 0 timeint 212454000 and timetostring(212454000) = 1976-09-24T23:00:00Z !? To be honest the date that kept me the action was the 1-1-1970 that appears 31-12-1969. After timetostring(stringtotime(date))) I made the test and time.mktime got a bug when date is less than 1976-09-26 see: for 1976-09-27T00:00:00Z time.mktime gives 212630400 for 1976-09-26T00:00:00Z time.mktime gives 212544000 for 1976-09-25T00:00:00Z time.mktime gives 212454000 212630400 - 212544000 = 86400 (seconds) , one day correct ! but 212544000 - 212454000 = 9 (seconds), one day more 3600 (seconds), more one hour ?!? -- Sérgio M. B. -- >Comment By: Martin v. Löwis (loewis) Date: 2007-02-13 13:04 Message: Logged In: YES user_id=21627 Originator: NO Please take a look at the implementation of mktime, and reformulate it as a C program. This should demonstrate you that the bug is not in Python, but in the C library. Also please respond to the question what timezone you are in. -- Comment By: Sérgio Monteiro Basto (sergiomb) Date: 2007-02-13 12:28 Message: Logged In: YES user_id=4882 Originator: YES Very strange ! >>> import time >>> time.mktime((1976,9,26,0,0,0,0,0,0)) 212544000.0 >>> time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0)) 9.0 >>> time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0)) 86400.0 >>> time.mktime((1976,9,26,0,0,0,0,0,0)) 212540400.0 -- Comment By: Sérgio Monteiro Basto (sergiomb) Date: 2007-02-13 12:19 Message: Logged In: YES user_id=4882 Originator: YES on my FC6 same first time >>> time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0)) 9.0 second and third time >>> time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0)) 86400.0 >>> time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0)) 86400.0 -- Comment By: Sérgio Monteiro Basto (sergiomb) Date: 2007-02-13 12:18 Message: Logged In: YES user_id=4882 Originator: YES here with ubuntu 5.16 with python 2.4.2 kernel-2.6.12 >>> import time >>> time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0)) 9.0 >>> time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0)) 86400.0 >>> time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0)) 86400.0 -- Comment By: Sérgio Monteiro Basto (sergiomb) Date: 2007-02-13 12:06 Message: Logged In: YES user_id=4882 Originator: YES here with ubuntu 6.10 with python 2.4.4c1 >>> import time >>> time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0)) 9.0 -- Comment By: Martin v. Löwis (loewis) Date: 2007-02-13 06:57 Message: Logged In: YES user_id=21627 Originator: NO Looks like an FC6 bug to me (either in their C library, or in their Python port). On Debian 3.1, Python 2.4.1, I also get 86400.0. Please report this to Redhat; I'm closing this as "works for me". If you stil think there is a bug in Python, please point to the exact source that you think is erroneous, and the change that should be made. -- Comment By: Sérgio Monteiro Basto (sergiomb) Date: 2007-02-12 23:37 Message: Logged In: YES user_id=4882 Originator: YES python-2.4.4-1.fc6 >>> import time >>> time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0)) 9.0 -- Comment By: Martin v. Löwis (loewis) Date: 2007-02-12 13:38 Message: Logged In: YES user_id=21627 Originator: NO I can't reproduce this problem. On my system (OSX), I get >>> time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0)) 86400.0 What
[ python-Bugs-1656559 ] I think, I have found this bug on time.mktime()
Bugs item #1656559, was opened at 2007-02-10 04:41 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1656559&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: Sérgio Monteiro Basto (sergiomb) Assigned to: Nobody/Anonymous (nobody) Summary: I think, I have found this bug on time.mktime() Initial Comment: well, I think, I have found this bug on time.mktime() for dates less than 1976-09-26 when I do stringtotime of 1976-09-25 print "timeint %d" % time.mktime(__extract_date(m) + __extract_time(m) + (0, 0, 0)) extract date = 1976 9 25 extract time = 0 0 0 timeint 212454000 and timetostring(212454000) = 1976-09-24T23:00:00Z !? To be honest the date that kept me the action was the 1-1-1970 that appears 31-12-1969. After timetostring(stringtotime(date))) I made the test and time.mktime got a bug when date is less than 1976-09-26 see: for 1976-09-27T00:00:00Z time.mktime gives 212630400 for 1976-09-26T00:00:00Z time.mktime gives 212544000 for 1976-09-25T00:00:00Z time.mktime gives 212454000 212630400 - 212544000 = 86400 (seconds) , one day correct ! but 212544000 - 212454000 = 9 (seconds), one day more 3600 (seconds), more one hour ?!? -- Sérgio M. B. -- >Comment By: Martin v. Löwis (loewis) Date: 2007-02-13 13:04 Message: Logged In: YES user_id=21627 Originator: NO Also, don't change the priority of bugs. -- Comment By: Martin v. Löwis (loewis) Date: 2007-02-13 13:04 Message: Logged In: YES user_id=21627 Originator: NO Please take a look at the implementation of mktime, and reformulate it as a C program. This should demonstrate you that the bug is not in Python, but in the C library. Also please respond to the question what timezone you are in. -- Comment By: Sérgio Monteiro Basto (sergiomb) Date: 2007-02-13 12:28 Message: Logged In: YES user_id=4882 Originator: YES Very strange ! >>> import time >>> time.mktime((1976,9,26,0,0,0,0,0,0)) 212544000.0 >>> time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0)) 9.0 >>> time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0)) 86400.0 >>> time.mktime((1976,9,26,0,0,0,0,0,0)) 212540400.0 -- Comment By: Sérgio Monteiro Basto (sergiomb) Date: 2007-02-13 12:19 Message: Logged In: YES user_id=4882 Originator: YES on my FC6 same first time >>> time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0)) 9.0 second and third time >>> time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0)) 86400.0 >>> time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0)) 86400.0 -- Comment By: Sérgio Monteiro Basto (sergiomb) Date: 2007-02-13 12:18 Message: Logged In: YES user_id=4882 Originator: YES here with ubuntu 5.16 with python 2.4.2 kernel-2.6.12 >>> import time >>> time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0)) 9.0 >>> time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0)) 86400.0 >>> time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0)) 86400.0 -- Comment By: Sérgio Monteiro Basto (sergiomb) Date: 2007-02-13 12:06 Message: Logged In: YES user_id=4882 Originator: YES here with ubuntu 6.10 with python 2.4.4c1 >>> import time >>> time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0)) 9.0 -- Comment By: Martin v. Löwis (loewis) Date: 2007-02-13 06:57 Message: Logged In: YES user_id=21627 Originator: NO Looks like an FC6 bug to me (either in their C library, or in their Python port). On Debian 3.1, Python 2.4.1, I also get 86400.0. Please report this to Redhat; I'm closing this as "works for me". If you stil think there is a bug in Python, please point to the exact source that you think is erroneous, and the change that should be made. -- Comment By: Sérgio Monteiro Basto (sergiomb) Date: 2007-02-12 23:37 Message: Logged In: YES user_id=4882 Originator: YES python-2.4.4-1.fc6 >>> import time >>> time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0)) 9.0 -- Comment By: Martin v. Löwis (loewis
[ python-Bugs-1656559 ] I think, I have found this bug on time.mktime()
Bugs item #1656559, was opened at 2007-02-10 03:41 Message generated for change (Comment added) made by cvalente You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1656559&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: Sérgio Monteiro Basto (sergiomb) Assigned to: Nobody/Anonymous (nobody) Summary: I think, I have found this bug on time.mktime() Initial Comment: well, I think, I have found this bug on time.mktime() for dates less than 1976-09-26 when I do stringtotime of 1976-09-25 print "timeint %d" % time.mktime(__extract_date(m) + __extract_time(m) + (0, 0, 0)) extract date = 1976 9 25 extract time = 0 0 0 timeint 212454000 and timetostring(212454000) = 1976-09-24T23:00:00Z !? To be honest the date that kept me the action was the 1-1-1970 that appears 31-12-1969. After timetostring(stringtotime(date))) I made the test and time.mktime got a bug when date is less than 1976-09-26 see: for 1976-09-27T00:00:00Z time.mktime gives 212630400 for 1976-09-26T00:00:00Z time.mktime gives 212544000 for 1976-09-25T00:00:00Z time.mktime gives 212454000 212630400 - 212544000 = 86400 (seconds) , one day correct ! but 212544000 - 212454000 = 9 (seconds), one day more 3600 (seconds), more one hour ?!? -- Sérgio M. B. -- Comment By: Claudio Valente (cvalente) Date: 2007-02-13 12:07 Message: Logged In: YES user_id=627298 Originator: NO I have the smae problem. My system info is: Python 2.4.3 (#1, Oct 18 2006, 16:42:32) [GCC 4.1.1 (Gentoo 4.1.1)] on linux2 Type "help", "copyright", "credits" or "license" for more information. my libc version is 2.4-r4. I'll try to run the analogous program in C and see whether this is a bug of libc and not python. More info later on. -- Comment By: Martin v. Löwis (loewis) Date: 2007-02-13 12:04 Message: Logged In: YES user_id=21627 Originator: NO Also, don't change the priority of bugs. -- Comment By: Martin v. Löwis (loewis) Date: 2007-02-13 12:04 Message: Logged In: YES user_id=21627 Originator: NO Please take a look at the implementation of mktime, and reformulate it as a C program. This should demonstrate you that the bug is not in Python, but in the C library. Also please respond to the question what timezone you are in. -- Comment By: Sérgio Monteiro Basto (sergiomb) Date: 2007-02-13 11:28 Message: Logged In: YES user_id=4882 Originator: YES Very strange ! >>> import time >>> time.mktime((1976,9,26,0,0,0,0,0,0)) 212544000.0 >>> time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0)) 9.0 >>> time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0)) 86400.0 >>> time.mktime((1976,9,26,0,0,0,0,0,0)) 212540400.0 -- Comment By: Sérgio Monteiro Basto (sergiomb) Date: 2007-02-13 11:19 Message: Logged In: YES user_id=4882 Originator: YES on my FC6 same first time >>> time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0)) 9.0 second and third time >>> time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0)) 86400.0 >>> time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0)) 86400.0 -- Comment By: Sérgio Monteiro Basto (sergiomb) Date: 2007-02-13 11:18 Message: Logged In: YES user_id=4882 Originator: YES here with ubuntu 5.16 with python 2.4.2 kernel-2.6.12 >>> import time >>> time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0)) 9.0 >>> time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0)) 86400.0 >>> time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0)) 86400.0 -- Comment By: Sérgio Monteiro Basto (sergiomb) Date: 2007-02-13 11:06 Message: Logged In: YES user_id=4882 Originator: YES here with ubuntu 6.10 with python 2.4.4c1 >>> import time >>> time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0)) 9.0 -- Comment By: Martin v. Löwis (loewis) Date: 2007-02-13 05:57 Message: Logged In: YES user_id=21627 Originator: NO Looks like an FC6 bug to me (either in their C library, or in their Python port). On Debian 3.1, Python 2.4.1, I also get 86400.0. Please report this to Redhat; I'm closing this as "works for me". If you stil think there is a bug in
[ python-Bugs-1658794 ] This shouldn't be there: Note that this code that uses...
Bugs item #1658794, was opened at 2007-02-13 11:29 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1658794&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: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Alf Lervåg (alfborge) Assigned to: Nobody/Anonymous (nobody) Summary: This shouldn't be there: Note that this code that uses... Initial Comment: In 21.2.1 Background, details, hints, tips and caveats; we have the following paragraph: The case conversion functions in the string module are affected by the locale settings. When a call to the setlocale() function changes the LC_CTYPE settings, the variables string.lowercase, string.uppercase and string.letters are recalculated. Note that this code that uses these variable through `from ... import ...', e.g. from string import letters, is not affected by subsequent setlocale() calls. I can't make sense of the last sentence unless I pretend that "this" shouldn't be there, i.e. Note that code that uses these variable(s?) through `from ... (...). -- Kind regards, Alf Lervåg -- >Comment By: Martin v. Löwis (loewis) Date: 2007-02-13 13:09 Message: Logged In: YES user_id=21627 Originator: NO Thanks for the report. This is now fixed in r53767 and r53768. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1658794&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1656559 ] I think, I have found this bug on time.mktime()
Bugs item #1656559, was opened at 2007-02-10 03:41 Message generated for change (Comment added) made by sergiomb You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1656559&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: Sérgio Monteiro Basto (sergiomb) Assigned to: Nobody/Anonymous (nobody) Summary: I think, I have found this bug on time.mktime() Initial Comment: well, I think, I have found this bug on time.mktime() for dates less than 1976-09-26 when I do stringtotime of 1976-09-25 print "timeint %d" % time.mktime(__extract_date(m) + __extract_time(m) + (0, 0, 0)) extract date = 1976 9 25 extract time = 0 0 0 timeint 212454000 and timetostring(212454000) = 1976-09-24T23:00:00Z !? To be honest the date that kept me the action was the 1-1-1970 that appears 31-12-1969. After timetostring(stringtotime(date))) I made the test and time.mktime got a bug when date is less than 1976-09-26 see: for 1976-09-27T00:00:00Z time.mktime gives 212630400 for 1976-09-26T00:00:00Z time.mktime gives 212544000 for 1976-09-25T00:00:00Z time.mktime gives 212454000 212630400 - 212544000 = 86400 (seconds) , one day correct ! but 212544000 - 212454000 = 9 (seconds), one day more 3600 (seconds), more one hour ?!? -- Sérgio M. B. -- >Comment By: Sérgio Monteiro Basto (sergiomb) Date: 2007-02-13 12:22 Message: Logged In: YES user_id=4882 Originator: YES timezone : WET in winter WEST in summer I try same with timezone of NEW YORK and >>> time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0)) 86400.0 -- Comment By: Claudio Valente (cvalente) Date: 2007-02-13 12:07 Message: Logged In: YES user_id=627298 Originator: NO I have the smae problem. My system info is: Python 2.4.3 (#1, Oct 18 2006, 16:42:32) [GCC 4.1.1 (Gentoo 4.1.1)] on linux2 Type "help", "copyright", "credits" or "license" for more information. my libc version is 2.4-r4. I'll try to run the analogous program in C and see whether this is a bug of libc and not python. More info later on. -- Comment By: Martin v. Löwis (loewis) Date: 2007-02-13 12:04 Message: Logged In: YES user_id=21627 Originator: NO Also, don't change the priority of bugs. -- Comment By: Martin v. Löwis (loewis) Date: 2007-02-13 12:04 Message: Logged In: YES user_id=21627 Originator: NO Please take a look at the implementation of mktime, and reformulate it as a C program. This should demonstrate you that the bug is not in Python, but in the C library. Also please respond to the question what timezone you are in. -- Comment By: Sérgio Monteiro Basto (sergiomb) Date: 2007-02-13 11:28 Message: Logged In: YES user_id=4882 Originator: YES Very strange ! >>> import time >>> time.mktime((1976,9,26,0,0,0,0,0,0)) 212544000.0 >>> time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0)) 9.0 >>> time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0)) 86400.0 >>> time.mktime((1976,9,26,0,0,0,0,0,0)) 212540400.0 -- Comment By: Sérgio Monteiro Basto (sergiomb) Date: 2007-02-13 11:19 Message: Logged In: YES user_id=4882 Originator: YES on my FC6 same first time >>> time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0)) 9.0 second and third time >>> time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0)) 86400.0 >>> time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0)) 86400.0 -- Comment By: Sérgio Monteiro Basto (sergiomb) Date: 2007-02-13 11:18 Message: Logged In: YES user_id=4882 Originator: YES here with ubuntu 5.16 with python 2.4.2 kernel-2.6.12 >>> import time >>> time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0)) 9.0 >>> time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0)) 86400.0 >>> time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0)) 86400.0 -- Comment By: Sérgio Monteiro Basto (sergiomb) Date: 2007-02-13 11:06 Message: Logged In: YES user_id=4882 Originator: YES here with ubuntu 6.10 with python 2.4.4c1 >>> import time >>> time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0)) 9.0 ---
[ python-Bugs-1448060 ] gettext.py breaks on plural-forms header (PATCH)
Bugs item #1448060, was opened at 2006-03-12 00:20
Message generated for change (Comment added) made by potorange
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1448060&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: 5
Private: No
Submitted By: Danilo Segan (dsegan)
Assigned to: Nobody/Anonymous (nobody)
Summary: gettext.py breaks on plural-forms header (PATCH)
Initial Comment:
See http://bugzilla.gnome.org/show_bug.cgi?id=334256
The problem is a PO file like the following:
test.po:
msgid ""
msgstr ""
"Content-Type: text/plain; charset=UTF-8\n"
"Plural-Forms: nplurals=2; plural=(n != 1);\n"
"#-#-#-#-# plo.po (PACKAGE VERSION) #-#-#-#-#\n"
(these kinds of entries are sometimes inserted by
msgmerge, so they're somewhat common)
Any Python program trying to access this breaks:
$ python test.py
Traceback (most recent call last):
File "test.py", line 7, in ?
gt = gettext.GNUTranslations(file)
File "/usr/lib/python2.4/gettext.py", line 177, in
__init__
self._parse(fp)
File "/usr/lib/python2.4/gettext.py", line 300, in _parse
v = v.split(';')
AttributeError: 'list' object has no attribute 'split'
test.py is simple:
#!/usr/bin/env python
import gettext
file = open("test.mo", "rb")
if file:
gt = gettext.GNUTranslations(file)
The problem is the corner-case: plural-forms precedes
this kind of comment, so "v" is split (v=v.split(";")).
In the next instance, lastk is "plural-forms", yet the
entry doesn't contain ":", so it tries to set plural
forms to v.split(";") again, which fails since v is
already a list.
The attached simple patch fixes this.
--
Comment By: Alexis Deruelle (potorange)
Date: 2007-02-13 13:31
Message:
Logged In: YES
user_id=1718193
Originator: NO
gettext chokes on empty Plural-Forms ?
#> audit2allow
Traceback (most recent call last):
File "/usr/bin/audit2allow", line 34, in ?
gettext.install('policycoreutils')
File "/usr/lib/python2.4/gettext.py", line 482, in install
t = translation(domain, localedir, fallback=True, codeset=codeset)
File "/usr/lib/python2.4/gettexTraceback (most recent call last):
File "/usr/bin/audit2allow", line 34, in ?
gettext.install('policycoreutils')
File "/usr/lib/python2.4/gettext.py", line 482, in install
t = translation(domain, localedir, fallback=True, codeset=codeset)
File "/usr/lib/python2.4/gettext.py", line 467, in translation
t = _translations.setdefault(key, class_(open(mofile, 'rb')))
File "/usr/lib/python2.4/gettext.py", line 177, in __init__
self._parse(fp)
File "/usr/lib/python2.4/gettext.py", line 302, in _parse
print v[1]
IndexError: list index out of range
t.py", line 467, in translation
t = _translations.setdefault(key, class_(open(mofile, 'rb')))
File "/usr/lib/python2.4/gettext.py", line 177, in __init__
self._parse(fp)
File "/usr/lib/python2.4/gettext.py", line 302, in _parse
print v[1]
IndexError: list index out of range
#> msgunfmt /usr/share/locale/fr/LC_MESSAGES/policycoreutils.mo | grep -i
plural
"Plural-Forms: \n"
Bellow is a patch that fixes this for me.
--- /usr/lib/python2.4/gettext.py.orig 2007-02-13 13:25:54.0
+0100
+++ /usr/lib/python2.4/gettext.py 2007-02-13 12:36:29.0
+0100
@@ -298,8 +298,9 @@
self._charset = v.split('charset=')[1]
elif k == 'plural-forms':
v = v.split(';')
-plural = v[1].split('plural=')[1]
- self.plural = c2py(plural)
+ if len(v) > 1:
+ plural = v[1].split('plural=')[1]
+ self.plural = c2py(plural)
# Note: we unconditionally convert both msgids and msgstrs
to
# Unicode using the character encoding specified in the
charset
# parameter of the Content-Type header. The gettext
documentation
--
Comment By: Danilo Segan (dsegan)
Date: 2006-03-22 00:28
Message:
Logged In: YES
user_id=219596
No. And based on what Bruno said, it's obviously not
supported (and since it's a GNU thingy, Bruno would probably
know best ;).
[btw, we need no plural forms in documentation at all, at
least not in static content translation; Yelp's
gnome-doc-utils stylesheets provide plural forms for where
they are appropriate]
--
Comment By: Martin v. Löwis (loewis)
Date: 2006-03-20 08:50
Message:
Logged In: YES
user_id=21627
dsegan: Can you give a real-world (i.e. non-documentation)
example of a PO file with a multi-li
[ python-Bugs-1656559 ] I think, I have found this bug on time.mktime()
Bugs item #1656559, was opened at 2007-02-10 03:41
Message generated for change (Comment added) made by cvalente
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1656559&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: Sérgio Monteiro Basto (sergiomb)
Assigned to: Nobody/Anonymous (nobody)
Summary: I think, I have found this bug on time.mktime()
Initial Comment:
well, I think, I have found this bug on time.mktime() for dates less
than 1976-09-26
when I do stringtotime of 1976-09-25
print "timeint %d" % time.mktime(__extract_date(m) + __extract_time(m) + (0, 0,
0))
extract date = 1976 9 25
extract time = 0 0 0
timeint 212454000
and
timetostring(212454000) = 1976-09-24T23:00:00Z !?
To be honest the date that kept me the action was the 1-1-1970 that
appears 31-12-1969. After timetostring(stringtotime(date)))
I made the test and time.mktime got a bug when date is less than
1976-09-26
see:
for 1976-09-27T00:00:00Z time.mktime gives 212630400
for 1976-09-26T00:00:00Z time.mktime gives 212544000
for 1976-09-25T00:00:00Z time.mktime gives 212454000
212630400 - 212544000 = 86400 (seconds) , one day correct !
but
212544000 - 212454000 = 9 (seconds), one day more 3600 (seconds),
more one hour ?!?
--
Sérgio M. B.
--
Comment By: Claudio Valente (cvalente)
Date: 2007-02-13 12:47
Message:
Logged In: YES
user_id=627298
Originator: NO
OK. This is almost surely NOT a Python bug but most likely a libc bug.
In c:
--
#include
#include
int main(int argc, char* argv[]){
struct tm t1;
struct tm t2;
/* midnight 26/SET/1076*/
t1.tm_sec = 0;
t1.tm_min = 0;
t1.tm_hour = 0;
t1.tm_mday = 26;
t1.tm_mon = 8;
t1.tm_year = 76;
/* midnight 25/SET/1076*/
t2.tm_sec = 0;
t2.tm_min = 0;
t2.tm_hour = 0;
t2.tm_mday = 25;
t2.tm_mon = 8;
t2.tm_year = 76;
printf("%li\n", mktime(&t1)-mktime(&t2));
printf("%li\n", mktime(&t1)-mktime(&t2));
return 0;
}
--
Outputs:
9
86400
In perl:
-
perl -le 'use POSIX; $t1=POSIX::mktime(0,0,0,26,8,76)
-POSIX::mktime(0,0,0,25,8,76); $t2 = POSIX::mktime(0,0,0,26,8,76)
-POSIX::mktime(0,0,0,25,8,76) ; print $t1."\n". $t2'
-
Outputs
9
86400
-
My system is gentoo with glibc 2.4-r4
and my timezone is:
/usr/share/zoneinfo/Europe/Lisbon
When I changed this to another timezone (Say London) the problem didn't
exist.
Thank you all for your time.
--
Comment By: Sérgio Monteiro Basto (sergiomb)
Date: 2007-02-13 12:22
Message:
Logged In: YES
user_id=4882
Originator: YES
timezone : WET in winter WEST in summer
I try same with timezone of NEW YORK and
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
86400.0
--
Comment By: Claudio Valente (cvalente)
Date: 2007-02-13 12:07
Message:
Logged In: YES
user_id=627298
Originator: NO
I have the smae problem.
My system info is:
Python 2.4.3 (#1, Oct 18 2006, 16:42:32)
[GCC 4.1.1 (Gentoo 4.1.1)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
my libc version is 2.4-r4.
I'll try to run the analogous program in C and see whether this is a bug
of libc and not python.
More info later on.
--
Comment By: Martin v. Löwis (loewis)
Date: 2007-02-13 12:04
Message:
Logged In: YES
user_id=21627
Originator: NO
Also, don't change the priority of bugs.
--
Comment By: Martin v. Löwis (loewis)
Date: 2007-02-13 12:04
Message:
Logged In: YES
user_id=21627
Originator: NO
Please take a look at the implementation of mktime, and reformulate it as
a C program. This should demonstrate you that the bug is not in Python, but
in the C library.
Also please respond to the question what timezone you are in.
--
Comment By: Sérgio Monteiro Basto (sergiomb)
Date: 2007-02-13 11:28
Message:
Logged In: YES
user_id=4882
Originator: YES
Very strange !
>>> import time
>>> time.mktime((1976,9,26,0,0,0,0,0,0))
212544000.0
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
9.0
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
86400.0
>>> time.mktime((1976,9,26,0,0,0,0,0,0))
212540400.0
--
Comment By: Sérgio Monteiro Bast
[ python-Bugs-1658959 ] os.wait child process fail when under stress
Bugs item #1658959, was opened at 2007-02-13 14:44 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=1658959&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: Threads Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: The Groff (thegroff) Assigned to: Nobody/Anonymous (nobody) Summary: os.wait child process fail when under stress Initial Comment: when having high amount of threads forking, os.wait fails from time to time giving a "No child" error". If you retry, eventually it will work. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1658959&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1656559 ] I think, I have found this bug on time.mktime()
Bugs item #1656559, was opened at 2007-02-10 03:41
Message generated for change (Comment added) made by sergiomb
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1656559&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: Sérgio Monteiro Basto (sergiomb)
Assigned to: Nobody/Anonymous (nobody)
Summary: I think, I have found this bug on time.mktime()
Initial Comment:
well, I think, I have found this bug on time.mktime() for dates less
than 1976-09-26
when I do stringtotime of 1976-09-25
print "timeint %d" % time.mktime(__extract_date(m) + __extract_time(m) + (0, 0,
0))
extract date = 1976 9 25
extract time = 0 0 0
timeint 212454000
and
timetostring(212454000) = 1976-09-24T23:00:00Z !?
To be honest the date that kept me the action was the 1-1-1970 that
appears 31-12-1969. After timetostring(stringtotime(date)))
I made the test and time.mktime got a bug when date is less than
1976-09-26
see:
for 1976-09-27T00:00:00Z time.mktime gives 212630400
for 1976-09-26T00:00:00Z time.mktime gives 212544000
for 1976-09-25T00:00:00Z time.mktime gives 212454000
212630400 - 212544000 = 86400 (seconds) , one day correct !
but
212544000 - 212454000 = 9 (seconds), one day more 3600 (seconds),
more one hour ?!?
--
Sérgio M. B.
--
>Comment By: Sérgio Monteiro Basto (sergiomb)
Date: 2007-02-13 14:25
Message:
Logged In: YES
user_id=4882
Originator: YES
ok bug openned on
http://sources.redhat.com/bugzilla/show_bug.cgi?id=4033
--
Comment By: Claudio Valente (cvalente)
Date: 2007-02-13 12:47
Message:
Logged In: YES
user_id=627298
Originator: NO
OK. This is almost surely NOT a Python bug but most likely a libc bug.
In c:
--
#include
#include
int main(int argc, char* argv[]){
struct tm t1;
struct tm t2;
/* midnight 26/SET/1076*/
t1.tm_sec = 0;
t1.tm_min = 0;
t1.tm_hour = 0;
t1.tm_mday = 26;
t1.tm_mon = 8;
t1.tm_year = 76;
/* midnight 25/SET/1076*/
t2.tm_sec = 0;
t2.tm_min = 0;
t2.tm_hour = 0;
t2.tm_mday = 25;
t2.tm_mon = 8;
t2.tm_year = 76;
printf("%li\n", mktime(&t1)-mktime(&t2));
printf("%li\n", mktime(&t1)-mktime(&t2));
return 0;
}
--
Outputs:
9
86400
In perl:
-
perl -le 'use POSIX; $t1=POSIX::mktime(0,0,0,26,8,76)
-POSIX::mktime(0,0,0,25,8,76); $t2 = POSIX::mktime(0,0,0,26,8,76)
-POSIX::mktime(0,0,0,25,8,76) ; print $t1."\n". $t2'
-
Outputs
9
86400
-
My system is gentoo with glibc 2.4-r4
and my timezone is:
/usr/share/zoneinfo/Europe/Lisbon
When I changed this to another timezone (Say London) the problem didn't
exist.
Thank you all for your time.
--
Comment By: Sérgio Monteiro Basto (sergiomb)
Date: 2007-02-13 12:22
Message:
Logged In: YES
user_id=4882
Originator: YES
timezone : WET in winter WEST in summer
I try same with timezone of NEW YORK and
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
86400.0
--
Comment By: Claudio Valente (cvalente)
Date: 2007-02-13 12:07
Message:
Logged In: YES
user_id=627298
Originator: NO
I have the smae problem.
My system info is:
Python 2.4.3 (#1, Oct 18 2006, 16:42:32)
[GCC 4.1.1 (Gentoo 4.1.1)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
my libc version is 2.4-r4.
I'll try to run the analogous program in C and see whether this is a bug
of libc and not python.
More info later on.
--
Comment By: Martin v. Löwis (loewis)
Date: 2007-02-13 12:04
Message:
Logged In: YES
user_id=21627
Originator: NO
Also, don't change the priority of bugs.
--
Comment By: Martin v. Löwis (loewis)
Date: 2007-02-13 12:04
Message:
Logged In: YES
user_id=21627
Originator: NO
Please take a look at the implementation of mktime, and reformulate it as
a C program. This should demonstrate you that the bug is not in Python,
but in the C library.
Also please respond to the question what timezone you are in.
--
Comment By: Sérgio Monteiro Basto (sergiomb)
Date: 2007-02-13 11:28
Message:
Logged In: YES
user_id=4882
Originator: YES
Very strange !
>>> import time
>>> time.mktime((1976,9,26,0,0,0,0,0,0))
212544000.0
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976
[ python-Bugs-1656559 ] I think, I have found this bug on time.mktime()
Bugs item #1656559, was opened at 2007-02-10 03:41
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1656559&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: Pending
Resolution: None
Priority: 5
Private: No
Submitted By: Sérgio Monteiro Basto (sergiomb)
Assigned to: Nobody/Anonymous (nobody)
Summary: I think, I have found this bug on time.mktime()
Initial Comment:
well, I think, I have found this bug on time.mktime() for dates less
than 1976-09-26
when I do stringtotime of 1976-09-25
print "timeint %d" % time.mktime(__extract_date(m) + __extract_time(m) + (0, 0,
0))
extract date = 1976 9 25
extract time = 0 0 0
timeint 212454000
and
timetostring(212454000) = 1976-09-24T23:00:00Z !?
To be honest the date that kept me the action was the 1-1-1970 that
appears 31-12-1969. After timetostring(stringtotime(date)))
I made the test and time.mktime got a bug when date is less than
1976-09-26
see:
for 1976-09-27T00:00:00Z time.mktime gives 212630400
for 1976-09-26T00:00:00Z time.mktime gives 212544000
for 1976-09-25T00:00:00Z time.mktime gives 212454000
212630400 - 212544000 = 86400 (seconds) , one day correct !
but
212544000 - 212454000 = 9 (seconds), one day more 3600 (seconds),
more one hour ?!?
--
Sérgio M. B.
--
Comment By: Sérgio Monteiro Basto (sergiomb)
Date: 2007-02-13 14:25
Message:
Logged In: YES
user_id=4882
Originator: YES
ok bug openned on
http://sources.redhat.com/bugzilla/show_bug.cgi?id=4033
--
Comment By: Claudio Valente (cvalente)
Date: 2007-02-13 12:47
Message:
Logged In: YES
user_id=627298
Originator: NO
OK. This is almost surely NOT a Python bug but most likely a libc bug.
In c:
--
#include
#include
int main(int argc, char* argv[]){
struct tm t1;
struct tm t2;
/* midnight 26/SET/1076*/
t1.tm_sec = 0;
t1.tm_min = 0;
t1.tm_hour = 0;
t1.tm_mday = 26;
t1.tm_mon = 8;
t1.tm_year = 76;
/* midnight 25/SET/1076*/
t2.tm_sec = 0;
t2.tm_min = 0;
t2.tm_hour = 0;
t2.tm_mday = 25;
t2.tm_mon = 8;
t2.tm_year = 76;
printf("%li\n", mktime(&t1)-mktime(&t2));
printf("%li\n", mktime(&t1)-mktime(&t2));
return 0;
}
--
Outputs:
9
86400
In perl:
-
perl -le 'use POSIX; $t1=POSIX::mktime(0,0,0,26,8,76)
-POSIX::mktime(0,0,0,25,8,76); $t2 = POSIX::mktime(0,0,0,26,8,76)
-POSIX::mktime(0,0,0,25,8,76) ; print $t1."\n". $t2'
-
Outputs
9
86400
-
My system is gentoo with glibc 2.4-r4
and my timezone is:
/usr/share/zoneinfo/Europe/Lisbon
When I changed this to another timezone (Say London) the problem didn't
exist.
Thank you all for your time.
--
Comment By: Sérgio Monteiro Basto (sergiomb)
Date: 2007-02-13 12:22
Message:
Logged In: YES
user_id=4882
Originator: YES
timezone : WET in winter WEST in summer
I try same with timezone of NEW YORK and
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
86400.0
--
Comment By: Claudio Valente (cvalente)
Date: 2007-02-13 12:07
Message:
Logged In: YES
user_id=627298
Originator: NO
I have the smae problem.
My system info is:
Python 2.4.3 (#1, Oct 18 2006, 16:42:32)
[GCC 4.1.1 (Gentoo 4.1.1)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
my libc version is 2.4-r4.
I'll try to run the analogous program in C and see whether this is a bug
of libc and not python.
More info later on.
--
Comment By: Martin v. Löwis (loewis)
Date: 2007-02-13 12:04
Message:
Logged In: YES
user_id=21627
Originator: NO
Also, don't change the priority of bugs.
--
Comment By: Martin v. Löwis (loewis)
Date: 2007-02-13 12:04
Message:
Logged In: YES
user_id=21627
Originator: NO
Please take a look at the implementation of mktime, and reformulate it as
a C program. This should demonstrate you that the bug is not in Python, but
in the C library.
Also please respond to the question what timezone you are in.
--
Comment By: Sérgio Monteiro Basto (sergiomb)
Date: 2007-02-13 11:28
Message:
Logged In: YES
user_id=4882
Originator: YES
Very strange !
>>> import time
>>> time.mktime((1976,9,26,0,0,0,0,0,0))
212544000.0
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime(
[ python-Bugs-1656559 ] I think, I have found this bug on time.mktime()
Bugs item #1656559, was opened at 2007-02-10 04:41
Message generated for change (Comment added) made by loewis
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1656559&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: 3rd Party
>Status: Closed
>Resolution: Invalid
Priority: 5
Private: No
Submitted By: Sérgio Monteiro Basto (sergiomb)
Assigned to: Nobody/Anonymous (nobody)
Summary: I think, I have found this bug on time.mktime()
Initial Comment:
well, I think, I have found this bug on time.mktime() for dates less
than 1976-09-26
when I do stringtotime of 1976-09-25
print "timeint %d" % time.mktime(__extract_date(m) + __extract_time(m) + (0, 0,
0))
extract date = 1976 9 25
extract time = 0 0 0
timeint 212454000
and
timetostring(212454000) = 1976-09-24T23:00:00Z !?
To be honest the date that kept me the action was the 1-1-1970 that
appears 31-12-1969. After timetostring(stringtotime(date)))
I made the test and time.mktime got a bug when date is less than
1976-09-26
see:
for 1976-09-27T00:00:00Z time.mktime gives 212630400
for 1976-09-26T00:00:00Z time.mktime gives 212544000
for 1976-09-25T00:00:00Z time.mktime gives 212454000
212630400 - 212544000 = 86400 (seconds) , one day correct !
but
212544000 - 212454000 = 9 (seconds), one day more 3600 (seconds),
more one hour ?!?
--
Sérgio M. B.
--
>Comment By: Martin v. Löwis (loewis)
Date: 2007-02-13 16:54
Message:
Logged In: YES
user_id=21627
Originator: NO
cvalente, thanks for the research. Making a second attempt at closing this
as third-party bug.
--
Comment By: Sérgio Monteiro Basto (sergiomb)
Date: 2007-02-13 15:25
Message:
Logged In: YES
user_id=4882
Originator: YES
ok bug openned on
http://sources.redhat.com/bugzilla/show_bug.cgi?id=4033
--
Comment By: Claudio Valente (cvalente)
Date: 2007-02-13 13:47
Message:
Logged In: YES
user_id=627298
Originator: NO
OK. This is almost surely NOT a Python bug but most likely a libc bug.
In c:
--
#include
#include
int main(int argc, char* argv[]){
struct tm t1;
struct tm t2;
/* midnight 26/SET/1076*/
t1.tm_sec = 0;
t1.tm_min = 0;
t1.tm_hour = 0;
t1.tm_mday = 26;
t1.tm_mon = 8;
t1.tm_year = 76;
/* midnight 25/SET/1076*/
t2.tm_sec = 0;
t2.tm_min = 0;
t2.tm_hour = 0;
t2.tm_mday = 25;
t2.tm_mon = 8;
t2.tm_year = 76;
printf("%li\n", mktime(&t1)-mktime(&t2));
printf("%li\n", mktime(&t1)-mktime(&t2));
return 0;
}
--
Outputs:
9
86400
In perl:
-
perl -le 'use POSIX; $t1=POSIX::mktime(0,0,0,26,8,76)
-POSIX::mktime(0,0,0,25,8,76); $t2 = POSIX::mktime(0,0,0,26,8,76)
-POSIX::mktime(0,0,0,25,8,76) ; print $t1."\n". $t2'
-
Outputs
9
86400
-
My system is gentoo with glibc 2.4-r4
and my timezone is:
/usr/share/zoneinfo/Europe/Lisbon
When I changed this to another timezone (Say London) the problem didn't
exist.
Thank you all for your time.
--
Comment By: Sérgio Monteiro Basto (sergiomb)
Date: 2007-02-13 13:22
Message:
Logged In: YES
user_id=4882
Originator: YES
timezone : WET in winter WEST in summer
I try same with timezone of NEW YORK and
>>>
time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
86400.0
--
Comment By: Claudio Valente (cvalente)
Date: 2007-02-13 13:07
Message:
Logged In: YES
user_id=627298
Originator: NO
I have the smae problem.
My system info is:
Python 2.4.3 (#1, Oct 18 2006, 16:42:32)
[GCC 4.1.1 (Gentoo 4.1.1)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
my libc version is 2.4-r4.
I'll try to run the analogous program in C and see whether this is a bug
of libc and not python.
More info later on.
--
Comment By: Martin v. Löwis (loewis)
Date: 2007-02-13 13:04
Message:
Logged In: YES
user_id=21627
Originator: NO
Also, don't change the priority of bugs.
--
Comment By: Martin v. Löwis (loewis)
Date: 2007-02-13 13:04
Message:
Logged In: YES
user_id=21627
Originator: NO
Please take a look at the implementation of mktime, and reformulate it as
a C program. This should demonstrate you that the bug is not in Python, but
in the C library.
Also please respond to the question what timezone you are in.
---
[ python-Bugs-1658959 ] os.wait child process fail when under stress
Bugs item #1658959, was opened at 2007-02-13 14:44 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1658959&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: Threads Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: The Groff (thegroff) Assigned to: Nobody/Anonymous (nobody) Summary: os.wait child process fail when under stress Initial Comment: when having high amount of threads forking, os.wait fails from time to time giving a "No child" error". If you retry, eventually it will work. -- >Comment By: Martin v. Löwis (loewis) Date: 2007-02-13 16:57 Message: Logged In: YES user_id=21627 Originator: NO What operating system are you using? Why do you think this is a bug in Python and not in your operating system? Are you sure there are any unwaited-for children when ECHILD is returned? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1658959&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1659171 ] Calling tparm from extension lib fails in Python 2.4
Bugs item #1659171, was opened at 2007-02-13 18:27 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=1659171&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: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Richard B. Kreckel (richyk) Assigned to: Nobody/Anonymous (nobody) Summary: Calling tparm from extension lib fails in Python 2.4 Initial Comment: Attached is a little C++ module that fetches the terminal capability string for turning off all attributes and runs it through tparm(). (All this is done in a static Ctor of a class without init function, but never mind.) Compile with: g++ -c testlib.cc g++ testlib.o -o testlib.so -shared -Wl,-soname,testlib.so -lncurses On SuSE Linux 10.1 (and older), I get the expected behavior: Python 2.4.2 (#1, Oct 13 2006, 17:11:24) [GCC 4.1.0 (SUSE Linux)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import testlib Terminal is "xterm" Dump of sgr0: 1b 5b 30 6d Dump of instance: 1b 5b 30 6d Traceback (most recent call last): File "", line 1, in ? ImportError: dynamic module does not define init function (inittestlib) >>> However, on SuSE Linux 10.2, tparm creates a NULL pointer: Python 2.5 (r25:51908, Jan 9 2007, 16:59:32) [GCC 4.1.2 20061115 (prerelease) (SUSE Linux)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import testlib Terminal is "xterm" Dump of sgr0: 1b 5b 30 6d Rats! tparm made a NULL pointer! Traceback (most recent call last): File "", line 1, in ImportError: dynamic module does not define init function (inittestlib) >>> Why, oh why? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1659171&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1659171 ] Calling tparm from extension lib fails in Python 2.5
Bugs item #1659171, was opened at 2007-02-13 18:27 Message generated for change (Settings changed) made by richyk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1659171&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: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Richard B. Kreckel (richyk) Assigned to: Nobody/Anonymous (nobody) >Summary: Calling tparm from extension lib fails in Python 2.5 Initial Comment: Attached is a little C++ module that fetches the terminal capability string for turning off all attributes and runs it through tparm(). (All this is done in a static Ctor of a class without init function, but never mind.) Compile with: g++ -c testlib.cc g++ testlib.o -o testlib.so -shared -Wl,-soname,testlib.so -lncurses On SuSE Linux 10.1 (and older), I get the expected behavior: Python 2.4.2 (#1, Oct 13 2006, 17:11:24) [GCC 4.1.0 (SUSE Linux)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import testlib Terminal is "xterm" Dump of sgr0: 1b 5b 30 6d Dump of instance: 1b 5b 30 6d Traceback (most recent call last): File "", line 1, in ? ImportError: dynamic module does not define init function (inittestlib) >>> However, on SuSE Linux 10.2, tparm creates a NULL pointer: Python 2.5 (r25:51908, Jan 9 2007, 16:59:32) [GCC 4.1.2 20061115 (prerelease) (SUSE Linux)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import testlib Terminal is "xterm" Dump of sgr0: 1b 5b 30 6d Rats! tparm made a NULL pointer! Traceback (most recent call last): File "", line 1, in ImportError: dynamic module does not define init function (inittestlib) >>> Why, oh why? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1659171&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1659173 ] Calling tparm from extension lib fails in Python 2.4
Bugs item #1659173, was opened at 2007-02-13 18:29 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=1659173&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: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Richard B. Kreckel (richyk) Assigned to: Nobody/Anonymous (nobody) Summary: Calling tparm from extension lib fails in Python 2.4 Initial Comment: Attached is a little C++ module that fetches the terminal capability string for turning off all attributes and runs it through tparm(). (All this is done in a static Ctor of a class without init function, but never mind.) Compile with: g++ -c testlib.cc g++ testlib.o -o testlib.so -shared -Wl,-soname,testlib.so -lncurses On SuSE Linux 10.1 (and older), I get the expected behavior: Python 2.4.2 (#1, Oct 13 2006, 17:11:24) [GCC 4.1.0 (SUSE Linux)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import testlib Terminal is "xterm" Dump of sgr0: 1b 5b 30 6d Dump of instance: 1b 5b 30 6d Traceback (most recent call last): File "", line 1, in ? ImportError: dynamic module does not define init function (inittestlib) >>> However, on SuSE Linux 10.2, tparm creates a NULL pointer: Python 2.5 (r25:51908, Jan 9 2007, 16:59:32) [GCC 4.1.2 20061115 (prerelease) (SUSE Linux)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import testlib Terminal is "xterm" Dump of sgr0: 1b 5b 30 6d Rats! tparm made a NULL pointer! Traceback (most recent call last): File "", line 1, in ImportError: dynamic module does not define init function (inittestlib) >>> Why, oh why? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1659173&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1659173 ] Calling tparm from extension lib fails in Python 2.4
Bugs item #1659173, was opened at 2007-02-13 18:29 Message generated for change (Comment added) made by richyk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1659173&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: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Richard B. Kreckel (richyk) Assigned to: Nobody/Anonymous (nobody) Summary: Calling tparm from extension lib fails in Python 2.4 Initial Comment: Attached is a little C++ module that fetches the terminal capability string for turning off all attributes and runs it through tparm(). (All this is done in a static Ctor of a class without init function, but never mind.) Compile with: g++ -c testlib.cc g++ testlib.o -o testlib.so -shared -Wl,-soname,testlib.so -lncurses On SuSE Linux 10.1 (and older), I get the expected behavior: Python 2.4.2 (#1, Oct 13 2006, 17:11:24) [GCC 4.1.0 (SUSE Linux)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import testlib Terminal is "xterm" Dump of sgr0: 1b 5b 30 6d Dump of instance: 1b 5b 30 6d Traceback (most recent call last): File "", line 1, in ? ImportError: dynamic module does not define init function (inittestlib) >>> However, on SuSE Linux 10.2, tparm creates a NULL pointer: Python 2.5 (r25:51908, Jan 9 2007, 16:59:32) [GCC 4.1.2 20061115 (prerelease) (SUSE Linux)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import testlib Terminal is "xterm" Dump of sgr0: 1b 5b 30 6d Rats! tparm made a NULL pointer! Traceback (most recent call last): File "", line 1, in ImportError: dynamic module does not define init function (inittestlib) >>> Why, oh why? -- >Comment By: Richard B. Kreckel (richyk) Date: 2007-02-13 18:33 Message: Logged In: YES user_id=1718463 Originator: YES Sorry, I was not aware that changing the subject opens a new bug report. This is more appropiately tracked in [1659171]. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1659173&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1659173 ] Calling tparm from extension lib fails in Python 2.4
Bugs item #1659173, was opened at 2007-02-13 17:29 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1659173&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: Extension Modules Group: None >Status: Closed >Resolution: Duplicate Priority: 5 Private: No Submitted By: Richard B. Kreckel (richyk) Assigned to: Nobody/Anonymous (nobody) Summary: Calling tparm from extension lib fails in Python 2.4 Initial Comment: Attached is a little C++ module that fetches the terminal capability string for turning off all attributes and runs it through tparm(). (All this is done in a static Ctor of a class without init function, but never mind.) Compile with: g++ -c testlib.cc g++ testlib.o -o testlib.so -shared -Wl,-soname,testlib.so -lncurses On SuSE Linux 10.1 (and older), I get the expected behavior: Python 2.4.2 (#1, Oct 13 2006, 17:11:24) [GCC 4.1.0 (SUSE Linux)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import testlib Terminal is "xterm" Dump of sgr0: 1b 5b 30 6d Dump of instance: 1b 5b 30 6d Traceback (most recent call last): File "", line 1, in ? ImportError: dynamic module does not define init function (inittestlib) >>> However, on SuSE Linux 10.2, tparm creates a NULL pointer: Python 2.5 (r25:51908, Jan 9 2007, 16:59:32) [GCC 4.1.2 20061115 (prerelease) (SUSE Linux)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import testlib Terminal is "xterm" Dump of sgr0: 1b 5b 30 6d Rats! tparm made a NULL pointer! Traceback (most recent call last): File "", line 1, in ImportError: dynamic module does not define init function (inittestlib) >>> Why, oh why? -- Comment By: Richard B. Kreckel (richyk) Date: 2007-02-13 17:33 Message: Logged In: YES user_id=1718463 Originator: YES Sorry, I was not aware that changing the subject opens a new bug report. This is more appropiately tracked in [1659171]. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1659173&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
