[ python-Bugs-1647654 ] No obvious and correct way to get the time zone offset
Bugs item #1647654, was opened at 2007-01-30 13:48 Message generated for change (Comment added) made by jhenstridge 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: James Henstridge (jhenstridge) Date: 2007-03-01 18:09 Message: Logged In: YES user_id=146903 Originator: YES The localtime_tz() function sounds like it would probably fit the bill. Another option would be to expose tm_gmtoff and tm_zone as non-sequence fields of time.struct_time for systems that support them. This would provide the data without needing new APIs. -- Comment By: Paul Boddie (pboddie) Date: 2007-02-24 08:31 Message: Logged In: YES user_id=226443 Originator: NO See patch #1667546 for a time module function returning extended time tuples. The datetime-based solution you provide is quite a clever workaround using "naive" datetime objects, but I'm inclined to think that some more convenient way of getting "aware" datetime objects would be nicer. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1647654&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1628895 ] Pydoc sets choices for doc locations incorrectly
Bugs item #1628895, was opened at 2007-01-05 16:24
Message generated for change (Comment added) made by gbrandl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1628895&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: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Skip Montanaro (montanaro)
Assigned to: Nobody/Anonymous (nobody)
Summary: Pydoc sets choices for doc locations incorrectly
Initial Comment:
In pydoc.Helper.__init__ I see this code:
execdir = os.path.dirname(sys.executable)
homedir = os.environ.get('PYTHONHOME')
for dir in [os.environ.get('PYTHONDOCS'),
homedir and os.path.join(homedir, 'doc'),
os.path.join(execdir, 'doc'),
'/usr/doc/python-docs-' + split(sys.version)[0],
'/usr/doc/python-' + split(sys.version)[0],
'/usr/doc/python-docs-' + sys.version[:3],
'/usr/doc/python-' + sys.version[:3],
os.path.join(sys.prefix,
'Resources/English.lproj/Documenta$if dir and
os.path.isdir(os.path.join(dir, 'lib')):
self.docdir = dir
I think the third choice in the list of candidate directories is wrong.
execdir is the directory of the Python executable (e.g., it's /usr/local/bin by
default). I think it should be set as
execdir = os.path.dirname(os.path.dirname(sys.executable))
You're not going to find a "doc" directory in /usr/local/bin.
--
>Comment By: Georg Brandl (gbrandl)
Date: 2007-03-01 10:25
Message:
Logged In: YES
user_id=849994
Originator: NO
Looks like that is for Windows distributions, as there is
C:\Python24\python.exe and C:\Python24\Doc.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1628895&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ 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-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-Bugs-1671676 ] test_mailbox is hanging while doing gmake test on HP-UX v3
Bugs item #1671676, was opened at 2007-03-01 19:24 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=1671676&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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: shashi (shashikala) Assigned to: Nobody/Anonymous (nobody) Summary: test_mailbox is hanging while doing gmake test on HP-UX v3 Initial Comment: Hi , I am testing Python 2.5 on HP-UX 11iv3 using gmake test , while testing the test test_mailbox.py is hanging . when tried to track the problem i came to know that in the function if pid == 0: # In the child, lock the mailbox. self._box.lock() time.sleep(2) self._box.unlock() os._exit(0) # In the parent, sleep a bit to give the child time to acquire # the lock. time.sleep(0.5) try: self.assertRaises(mailbox.ExternalClashError, self._box.lock) finally: # Wait for child to exit. Locking should now succeed. exited_pid, status = os.waitpid(pid, 0) after forking the child , child is not returning status to the parent while its waiting for the return status. which part of the Python functionality is checked. Please assist me to solve this. Thanks in advance , shashi -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1671676&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1669743 ] Python needs a way to detect implementation
Bugs item #1669743, was opened at 2007-02-27 08:32 Message generated for change (Comment added) made by kayhayen2 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1669743&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: Feature Request Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Kay Hayen (kayhayen2) Assigned to: Nobody/Anonymous (nobody) Summary: Python needs a way to detect implementation Initial Comment: Hello, I am currently writing an application that will run under both CPython and PyPy. In this I encountered the need to discover the implementation of the current interpreter. For example, with PyPy the use of StringIO may offer benefits due to the possibility of more complete analysis of data flows during compilation or JIT execution. I want to take advantage of this. (Granted, currently pypy will run on top of CPython most of the time, so it's not the real solution to my problem until PyPy-c is at comparable performance). This is only example, a lot of different performance behaviors exist, that at times, will make sense to be abstracted. I have checked module sys of both implementations (plus Jython) and found in CPython only the property "subversion", which contains a tuple with CPython being the first element. My suspect is though that this is related to the detail of using svn in CPython development, and as such, would not be a good standard. So, what I believe with more and more Python versions existing (e.g. IronPython), it is needed to have sys.implementation that puts sys.version into context. My proposal is that CPython leads the effort to aid this, and the other Python variants can then adopt the standard property. Thank you in advance, Kay Hayen -- >Comment By: Kay Hayen (kayhayen2) Date: 2007-03-01 19:01 Message: Logged In: YES user_id=1730054 Originator: YES Well, I did find sys.subversion of CPython 2.5 and sys.pypy_svn_url of Pypy 0.99 or so. The docs currently say about sys.subversion: "A triple (repo, branch, version) representing the Subversion information of the Python interpreter. repo is the name of the repository, 'CPython'. branch is a string of one of the forms 'trunk', 'branches/name' or 'tags/name'. version is the output of svnversion [...]" Would you confirm that sys.subversion is a property that every implementation of Python should have? -- Comment By: Martin v. Löwis (loewis) Date: 2007-03-01 07:40 Message: Logged In: YES user_id=21627 Originator: NO Please take a look at sys.subversion. This is fixed in Python 2.5. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1669743&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1671965 ] shutil.copy2 modifies decimal part of last modification time
Bugs item #1671965, was opened at 2007-03-01 20: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=1671965&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: Guy Dalberto (guy-dalberto) Assigned to: Nobody/Anonymous (nobody) Summary: shutil.copy2 modifies decimal part of last modification time Initial Comment: Problem on Windows 2000 with Python 2.5. When copying a file with shutil.copy2, the last modification times should be copied. What happens is that : + the integer part is copied correctly + the decimal part is modified + some samples : source-lastmod-time copy-lastmod-time file_0.txt 1172574881.34375 => 1172574881.034375 file_1.txt 1172574881.46875 => 1172574881.046875 + what is really odd is that the decimal part is divided by 10 The attached file *test_shutil_copy2.py* contains an Unit Test that demonstrate the incorrect behaviour -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1671965&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1671411 ] python code fails with "MemoryError" on HP-UX 11.11 PA_RISC
Bugs item #1671411, was opened at 2007-03-01 05:27
Message generated for change (Comment added) made by loewis
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: Martin v. Löwis (loewis)
Date: 2007-03-01 22: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 12: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 07: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-Bugs-1671965 ] shutil.copy2 modifies decimal part of last modification time
Bugs item #1671965, was opened at 2007-03-01 20:44 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1671965&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: Guy Dalberto (guy-dalberto) Assigned to: Nobody/Anonymous (nobody) Summary: shutil.copy2 modifies decimal part of last modification time Initial Comment: Problem on Windows 2000 with Python 2.5. When copying a file with shutil.copy2, the last modification times should be copied. What happens is that : + the integer part is copied correctly + the decimal part is modified + some samples : source-lastmod-time copy-lastmod-time file_0.txt 1172574881.34375 => 1172574881.034375 file_1.txt 1172574881.46875 => 1172574881.046875 + what is really odd is that the decimal part is divided by 10 The attached file *test_shutil_copy2.py* contains an Unit Test that demonstrate the incorrect behaviour -- >Comment By: Martin v. Löwis (loewis) Date: 2007-03-01 22:36 Message: Logged In: YES user_id=21627 Originator: NO I believe this is a duplicate of #565150; it has been fixed in the maintenance branch. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1671965&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1669743 ] Python needs a way to detect implementation
Bugs item #1669743, was opened at 2007-02-27 08:32 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1669743&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: Feature Request Status: Closed >Resolution: Works For Me Priority: 5 Private: No Submitted By: Kay Hayen (kayhayen2) Assigned to: Nobody/Anonymous (nobody) Summary: Python needs a way to detect implementation Initial Comment: Hello, I am currently writing an application that will run under both CPython and PyPy. In this I encountered the need to discover the implementation of the current interpreter. For example, with PyPy the use of StringIO may offer benefits due to the possibility of more complete analysis of data flows during compilation or JIT execution. I want to take advantage of this. (Granted, currently pypy will run on top of CPython most of the time, so it's not the real solution to my problem until PyPy-c is at comparable performance). This is only example, a lot of different performance behaviors exist, that at times, will make sense to be abstracted. I have checked module sys of both implementations (plus Jython) and found in CPython only the property "subversion", which contains a tuple with CPython being the first element. My suspect is though that this is related to the detail of using svn in CPython development, and as such, would not be a good standard. So, what I believe with more and more Python versions existing (e.g. IronPython), it is needed to have sys.implementation that puts sys.version into context. My proposal is that CPython leads the effort to aid this, and the other Python variants can then adopt the standard property. Thank you in advance, Kay Hayen -- >Comment By: Martin v. Löwis (loewis) Date: 2007-03-01 22:40 Message: Logged In: YES user_id=21627 Originator: NO No; it should be only available in Python implementations that do indeed have subversion information available. If you truly want something that all Python implementations must implement to be valid implementations of the Python programming language, you will have to write a PEP. Closing this as "works for me". -- Comment By: Kay Hayen (kayhayen2) Date: 2007-03-01 19:01 Message: Logged In: YES user_id=1730054 Originator: YES Well, I did find sys.subversion of CPython 2.5 and sys.pypy_svn_url of Pypy 0.99 or so. The docs currently say about sys.subversion: "A triple (repo, branch, version) representing the Subversion information of the Python interpreter. repo is the name of the repository, 'CPython'. branch is a string of one of the forms 'trunk', 'branches/name' or 'tags/name'. version is the output of svnversion [...]" Would you confirm that sys.subversion is a property that every implementation of Python should have? -- Comment By: Martin v. Löwis (loewis) Date: 2007-03-01 07:40 Message: Logged In: YES user_id=21627 Originator: NO Please take a look at sys.subversion. This is fixed in Python 2.5. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1669743&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
