[ python-Bugs-1672332 ] cPickle can pickle, but cannot unpickle on 64bit machines
Bugs item #1672332, was opened at 2007-03-02 12:10 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1672332&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: Platform-specific Status: Open Resolution: None Priority: 5 Private: No Submitted By: Bartlomiej Ogryczak (oneg) Assigned to: Nobody/Anonymous (nobody) Summary: cPickle can pickle, but cannot unpickle on 64bit machines Initial Comment: Seems that on 64-bit machines cPickle is able to pickle floats smaller then DBL_MIN, but it's unable to unpickle them. 64-bit machine (Solaris 10 on Sparc) Python 2.4.4 (#1, Oct 26 2006, 10:01:37) [GCC 3.3.4] on sunos5 Type "help", "copyright", "credits" or "license" for more information. >>> import cPickle >>> cPickle.dumps(1e-310) 'F9.9694e-311\n.' >>> cPickle.loads(_) Traceback (most recent call last): File "", line 1, in ? ValueError: could not convert string to float Same thing works fine on 32-bit machine (P4 with MS Windows) Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import cPickle >>> cPickle.dumps(1e-310) 'F0\n.' >>> -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1672332&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1672336 ] Building python 2.5 for AMD64 (windows) and VS2005
Bugs item #1672336, was opened at 2007-03-02 12:16 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1672336&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: fred2k (fred2k) Assigned to: Nobody/Anonymous (nobody) Summary: Building python 2.5 for AMD64 (windows) and VS2005 Initial Comment: When building pythoncore for AMD64 (WIndows) on VS2005, I get the following error : 3>generate buildinfo 3>cl.exe -c -D_WIN32 -DUSE_DL_EXPORT -D_WINDOWS -DWIN32 -D_WINDLL -MD -MD /USECL:MS_OPTERON ..\Modules\getbuildinfo.c -Fogetbuildinfo.o -I..\Include -I..\PC 3>Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.50727.42 for 80x86 3>Copyright (C) Microsoft Corporation. All rights reserved. 3>getbuildinfo.c 3>Linking... 3>LINK : warning LNK4044: unrecognized option '/USELINK:MS_SDK'; ignored 3>getbuildinfo.o : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64' 3>Build log was saved at "file://d:\users\fbr\python build\Python-2.5\PCbuild8\amd64-temp-release\pythoncore\BuildLog.htm" 3>pythoncore - 1 error(s), 225 warning(s) I already looked for the issue on google and on the ML archive (http://mail.python.org/pipermail/python-dev/2006-March/062753.html) but the workaround explained there (checking vsextcompiler) is specific for VC2003. Has anyone solved this problem ? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1672336&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: Closed
>Resolution: Fixed
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-02 14:37
Message:
Logged In: YES
user_id=849994
Originator: NO
Added some more search paths in rev. 54080.
--
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-1647654 ] No obvious and correct way to get the time zone offset
Bugs item #1647654, was opened at 2007-01-30 00:48 Message generated for change (Comment added) made by gvanrossum 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: Guido van Rossum (gvanrossum) Date: 2007-03-02 10:48 Message: Logged In: YES user_id=6380 Originator: NO Hm I'm not sure I understand why the first bit of code didn't work. Can you give a concrete example? (I.e. what was t, what was returned by localtime(t), and what were the three time variables that day.) I don't know the details of Western Australia's DST change. But looking at the source of timemodule.c, I notice that it simply samples the timezone on Jan 1st and July 1st, and if they differ, decides which one is summer time by which one is smaller. Your remark that the problem righted itself in January makes me wonder -- between what dates did you have DST? Alternatively, it could be that your system simply didn't have the correct DST change data loaded yet (this happens all the time when governments change the rules). Can you rule that out? I really don't want to have to change Python in order to correct for *that* problem. Yet another question, if you were to code this in C, how would you write it? Regardless, I think that it would be useful to support tm_gmtoff and other struct tm entries, the same way that we do this in struct stat. You could probably also get the correct result (assuming your system's timezone database is correct) by comparing localtime() and gmtime(). But the reverse engineering is a bit painful; your trick using datetime essentially does that. -- Comment By: James Henstridge (jhenstridge) Date: 2007-03-01 05: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-23 19: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-1646728 ] datetime.fromtimestamp fails with negative fractional times
Bugs item #1646728, was opened at 2007-01-28 21:21 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1646728&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: James Henstridge (jhenstridge) Assigned to: Nobody/Anonymous (nobody) Summary: datetime.fromtimestamp fails with negative fractional times Initial Comment: The datetime.fromtimestamp() function works fine with integer timestamps and positive fractional timestamps, but fails if I pass a negative fractional timestamp. For example: >>> import datetime >>> datetime.datetime.fromtimestamp(-1.05) Traceback (most recent call last): File "", line 1, in ValueError: microsecond must be in 0..99 It should return the same result as datetime.fromtimestamp(-1) - timedelta(seconds=.5). The same bug can be triggered in datetime.utcfromtimestamp(). I have been able to reproduce this bug in Python 2.4.4 and Python 2.5 on Linux. -- >Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-02 11:05 Message: Logged In: YES user_id=6380 Originator: NO Looks like a bug in the conversion from floats to ints. Anyone care to track it down more precisely? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1646728&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1672568 ] silent error in email.message.Message.get_payload
Bugs item #1672568, was opened at 2007-03-02 18:04 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=1672568&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: Not a Bug Status: Open Resolution: None Priority: 5 Private: No Submitted By: Renaud Blanch (blanch) Assigned to: Nobody/Anonymous (nobody) Summary: silent error in email.message.Message.get_payload Initial Comment: I rencently had trouble finding a bug in an email processing script because of an error that pass silently in the email module. The get_payload() method in the email.message module always return something when the decode argument is set to True. This behaviour is well documented, but is their a reason to catch the decoding errors ? Why not let them pop-up to the calling code ? renaud -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1672568&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1668032 ] PyMem_Realloc docs don't specifiy out-of-mem behavior
Bugs item #1668032, was opened at 2007-02-24 21:01 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1668032&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: Daniel Stutzbach (agthorr) Assigned to: Nobody/Anonymous (nobody) Summary: PyMem_Realloc docs don't specifiy out-of-mem behavior Initial Comment: I suggest adding the following text to the documentation for PyMem_Realloc: "If the request fails, PyMem_Realloc returns NULL and p remains a valid allocated pointer." I dug into obmalloc.c to figure out the behavior. -- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-02 20:30 Message: Logged In: YES user_id=849994 Originator: NO Fixed in rev. 54088, 54089 (2.5). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1668032&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1668036 ] PyMem_Resize docs don't specify that it modifies an argument
Bugs item #1668036, was opened at 2007-02-24 21:09 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1668036&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: Daniel Stutzbach (agthorr) Assigned to: Nobody/Anonymous (nobody) Summary: PyMem_Resize docs don't specify that it modifies an argument Initial Comment: PyMem_Resize is defined as follows: #define PyMem_Resize(p, type, n) \ ( (p) = (type *) PyMem_Realloc((p), (n) * sizeof(type)) ) The docs for PyMem_Resize don't specify that it modifies p. I suggest adding the following sentence: "On return, p will point to the new memory area, or NULL in the event of failure." -- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-02 20:30 Message: Logged In: YES user_id=849994 Originator: NO Fixed in rev. 54088, 54089 (2.5). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1668036&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1669304 ] Clarify PyMem_Realloc and PyMem_Resize docs
Bugs item #1669304, was opened at 2007-02-26 17:26 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1669304&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Steven Bethard (bediviere) Assigned to: Nobody/Anonymous (nobody) Summary: Clarify PyMem_Realloc and PyMem_Resize docs Initial Comment: This should close 1668036 and 1668032 which both looked like valid doc patch requests. The pymem_resize patch indicates the PyMem_Resize assigns to p (its first argument), and the pymem_realloc patch indicates that PyMem_Realloc will not modify the pointer if the realloc fails. -- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-02 20:30 Message: Logged In: YES user_id=849994 Originator: NO Fixed in rev. 54088, 54089 (2.5). -- Comment By: Steven Bethard (bediviere) Date: 2007-02-26 17:26 Message: Logged In: YES user_id=945502 Originator: YES File Added: pymem_realloc.diff -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1669304&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1672336 ] Building python 2.5 for AMD64 (windows) and VS2005
Bugs item #1672336, was opened at 2007-03-02 12:16 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1672336&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: fred2k (fred2k) >Assigned to: Kristj�n Valur (krisvale) Summary: Building python 2.5 for AMD64 (windows) and VS2005 Initial Comment: When building pythoncore for AMD64 (WIndows) on VS2005, I get the following error : 3>generate buildinfo 3>cl.exe -c -D_WIN32 -DUSE_DL_EXPORT -D_WINDOWS -DWIN32 -D_WINDLL -MD -MD /USECL:MS_OPTERON ..\Modules\getbuildinfo.c -Fogetbuildinfo.o -I..\Include -I..\PC 3>Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.50727.42 for 80x86 3>Copyright (C) Microsoft Corporation. All rights reserved. 3>getbuildinfo.c 3>Linking... 3>LINK : warning LNK4044: unrecognized option '/USELINK:MS_SDK'; ignored 3>getbuildinfo.o : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64' 3>Build log was saved at "file://d:\users\fbr\python build\Python-2.5\PCbuild8\amd64-temp-release\pythoncore\BuildLog.htm" 3>pythoncore - 1 error(s), 225 warning(s) I already looked for the issue on google and on the ML archive (http://mail.python.org/pipermail/python-dev/2006-March/062753.html) but the workaround explained there (checking vsextcompiler) is specific for VC2003. Has anyone solved this problem ? -- >Comment By: Martin v. Löwis (loewis) Date: 2007-03-03 02:49 Message: Logged In: YES user_id=21627 Originator: NO Kristjan, can you take a look? If not, please unassign. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1672336&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
