[ python-Bugs-1473625 ] cPickle produces locale-dependent dumps
Bugs item #1473625, was opened at 2006-04-20 17:25 Message generated for change (Comment added) made by ivilata You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1473625&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 Submitted By: Ivan Vilata i Balaguer (ivilata) Assigned to: Nobody/Anonymous (nobody) Summary: cPickle produces locale-dependent dumps Initial Comment: Dumping a float with cPickle produces a result which is locale-dependent. This causes problems when trying to load the dump under a different locale (the regular pickle module is not affected by this bug). IMHO, the dump should be locale-independent to ensure portability. See the attached file for a sample session log showing the behaviour of both pickle and cPickle under C and ca_ES.UTF-8 locales (Catalan uses a comma to separate the integer and decimal part). -- >Comment By: Ivan Vilata i Balaguer (ivilata) Date: 2006-04-21 11:42 Message: Logged In: YES user_id=1064183 The problem seems to be in save_float() in the cPickle.c module. It uses PyOS_snprintf() to dump floats, but it is locale-dependent. Fortunately, the PyOS_ascii_formatd() function can be used. The attached patch seems to fix the problem, and pickling tests run OK. It would be nice to see this patch applied to 2.4 also. (BTW, I meant PEP 331 in the previous comment, not 311, sorry.) -- Comment By: Martin v. Löwis (loewis) Date: 2006-04-20 23:54 Message: Logged In: YES user_id=21627 Right, cPickle should use C locale floating point numbers, using the PEP 331 API. Would you like to investigate a patch? -- Comment By: Ivan Vilata i Balaguer (ivilata) Date: 2006-04-20 17:28 Message: Logged In: YES user_id=1064183 As a side note, does this have anything to do with PEP 311? http://www.python.org/dev/peps/pep-0331/ -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1473625&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1471806 ] IDLE does not start 2.4.3
Bugs item #1471806, was opened at 2006-04-17 11:58 Message generated for change (Comment added) made by egrimes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1471806&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: IDLE Group: Python 2.4 >Status: Closed Resolution: None Priority: 5 Submitted By: Erin (egrimes) Assigned to: Kurt B. Kaiser (kbk) Summary: IDLE does not start 2.4.3 Initial Comment: IDLE does not start. 2.4.3 Installed Python 2.4.3 on Windows XP SP 2 I shutoff my ZoneAlarm Firewall and Stopped the Windows Firewall, turned off all Anti-Virus services. Python was 2.4.2 was previously installed on this machine and worked fine. Machine was wiped, reloaded and Python 2.4.3 was available. Steps: 1. Click Start -> All Programs -> Python 2.4 -> IDLE (Python GUI) 2. pythonw.exe process starts for a few seconds, then stops 3. Nothing happens -- >Comment By: Erin (egrimes) Date: 2006-04-21 08:25 Message: Logged In: YES user_id=1503943 When Python installed, my admin account was not given permission to access the C:\Documents and Settings\Admin\.idlerc folder which was preventing Python from starting. Thanks for showing me how to start IDLE in cmd prompt, that showed me the permission denied error on the folder. Might want to have python throw some sort of error if it tries to open via shortcut and that folder is blocked. -- Comment By: Terry J. Reedy (tjreedy) Date: 2006-04-21 01:59 Message: Logged In: YES user_id=593130 I have opposite experience. Winxp home sp2, upgraded without uninstall. Did not turn off Win Firewall or AV. Idle 1.1.3 starts up nice as can be. File/Recent File list is still there. Opened one with test code and it just reran; all tests pass as did before with, I believe, same test report output. What happens when you open a Python command window? Have you run test/regrtest.py or anything else? -- Comment By: Josiah Carlson (josiahcarlson) Date: 2006-04-21 01:53 Message: Logged In: YES user_id=341410 1. Start up a command line (Start -> Run -> cmd). 2. Change to the directory in which Python is installed (the following will likely work, if you installed Python using the default configuration)... c: cd \python24 3. Run idle from the command line... python lib\idlelib\idle.pyw Tell us what it prints out. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1471806&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1471806 ] IDLE does not start 2.4.3
Bugs item #1471806, was opened at 2006-04-17 08:58 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1471806&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: IDLE Group: Python 2.4 Status: Closed Resolution: None Priority: 5 Submitted By: Erin (egrimes) Assigned to: Kurt B. Kaiser (kbk) Summary: IDLE does not start 2.4.3 Initial Comment: IDLE does not start. 2.4.3 Installed Python 2.4.3 on Windows XP SP 2 I shutoff my ZoneAlarm Firewall and Stopped the Windows Firewall, turned off all Anti-Virus services. Python was 2.4.2 was previously installed on this machine and worked fine. Machine was wiped, reloaded and Python 2.4.3 was available. Steps: 1. Click Start -> All Programs -> Python 2.4 -> IDLE (Python GUI) 2. pythonw.exe process starts for a few seconds, then stops 3. Nothing happens -- Comment By: Josiah Carlson (josiahcarlson) Date: 2006-04-21 08:52 Message: Logged In: YES user_id=341410 A patch which offers such functionality would surely be appreciated. -- Comment By: Erin (egrimes) Date: 2006-04-21 05:25 Message: Logged In: YES user_id=1503943 When Python installed, my admin account was not given permission to access the C:\Documents and Settings\Admin\.idlerc folder which was preventing Python from starting. Thanks for showing me how to start IDLE in cmd prompt, that showed me the permission denied error on the folder. Might want to have python throw some sort of error if it tries to open via shortcut and that folder is blocked. -- Comment By: Terry J. Reedy (tjreedy) Date: 2006-04-20 22:59 Message: Logged In: YES user_id=593130 I have opposite experience. Winxp home sp2, upgraded without uninstall. Did not turn off Win Firewall or AV. Idle 1.1.3 starts up nice as can be. File/Recent File list is still there. Opened one with test code and it just reran; all tests pass as did before with, I believe, same test report output. What happens when you open a Python command window? Have you run test/regrtest.py or anything else? -- Comment By: Josiah Carlson (josiahcarlson) Date: 2006-04-20 22:53 Message: Logged In: YES user_id=341410 1. Start up a command line (Start -> Run -> cmd). 2. Change to the directory in which Python is installed (the following will likely work, if you installed Python using the default configuration)... c: cd \python24 3. Run idle from the command line... python lib\idlelib\idle.pyw Tell us what it prints out. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1471806&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1350060 ] built-in method .__cmp__
Bugs item #1350060, was opened at 2005-11-07 08:55 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1350060&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 Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Armin Rigo (arigo) Summary: built-in method .__cmp__ Initial Comment: Bound methods of built-in objects have a strange __cmp__/__hash__ combination: they compare equal only if their __self__ are identical, but they hash based on the hash of __self__ instead of its _Py_HashPointer(). Built-in methods should consistently be based on the identity *or* the equality of __self__. For reference, regular instance methods are based on the equality. So I propose to fix built-in method objects in the same way. -- >Comment By: Armin Rigo (arigo) Date: 2006-04-21 16:41 Message: Logged In: YES user_id=4771 I've just been bitten by this problem. It's an arguably reasonable use case about why instance methods should work like immutable containers (they are immutable, after all) in the sense that equality should be structural. If nobody object I will check in a fix that makes instance methods and built-in instance methods compare their 'self' recursively. -- Comment By: Armin Rigo (arigo) Date: 2005-12-01 10:40 Message: Logged In: YES user_id=4771 Sorry, my mistake: regular instance methods behave like built-in methods. They are both based on the identity of their 'self' but use its hash to compute their own hash. This bug report is thus only about why should the hash of methods and built-in methods depend on the hash of their 'self'. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1350060&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1409460 ] email.Utils.parseaddr() gives arcane result
Bugs item #1409460, was opened at 2006-01-18 14:19
Message generated for change (Comment added) made by msapiro
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1409460&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
Submitted By: Mark Sapiro (msapiro)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: email.Utils.parseaddr() gives arcane result
Initial Comment:
email.Utils.parseaddr('Real Name ((comment))
<[EMAIL PROTECTED]>')
returns
('comment <[EMAIL PROTECTED]>', 'Real')
Granted the string above is invalid as RFC 2822 does
not allow parentheses within comments, but most mail
agents seem to at least take the contents of the angle
brackets as the address in this case.
rfc822.parseaddr() returns the same result in this case.
If these functions aren't going to return their
respective failure indication in this case, I think
they should at least return '[EMAIL PROTECTED]' as
the second item of the returned tuple.
Note that
parseaddr('Real Name <[EMAIL PROTECTED]> ((comment))')
does return
('Real Name', '[EMAIL PROTECTED]')
as 'expected'.
--
>Comment By: Mark Sapiro (msapiro)
Date: 2006-04-21 10:01
Message:
Logged In: YES
user_id=1123998
It looks like this is addressed by patch 1464708
http://sourceforge.net/tracker/index.php?func=detail&aid=1464708&group_id=5470&atid=305470
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1409460&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1473760 ] TempFile can hang on Windows
Bugs item #1473760, was opened at 2006-04-20 18:35
Message generated for change (Comment added) made by arigo
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1473760&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: 7
Submitted By: Tim Peters (tim_one)
Assigned to: Nobody/Anonymous (nobody)
Summary: TempFile can hang on Windows
Initial Comment:
Attached is a simple module. If you try to import it
("import hang"), it prints "asking for temp file", and
hangs there, never returning from its call to
tempfile.TemporaryFile(). It's in fact stuck in
ntpath.py, on the "from nt import _getfullpathname"
line in function `abspath`.
Of course hang.py spawns another thread, and is hung
waiting for the import lock. That thread isn't doing
any imports the _user_ knows about, and Python's
standard library should be coded more defensively than
this.
The symptom was reported on zodb-dev today, where
Martin Gfeller reported ZEO hanging on Windows for what
appears to be the same reason:
http://mail.zope.org/pipermail/zodb-dev/2006-April/009989.html
As it says there, it looks like this problem was
introduced (indirectly) by patch
http://www.python.org/sf/810914
which appears to have been revision 34396 (October
2003! -- but not backported to 2.3, so nobody would
notice this before 2.4).
I haven't dug deeper than this, and don't know why
nobody noticed ZEO hanging before ;-)
--
>Comment By: Armin Rigo (arigo)
Date: 2006-04-21 17:22
Message:
Logged In: YES
user_id=4771
The general problem keeps showing up again and again.
I can't find all reference (I remember more), but there
are at least the following open bugs about it:
#689895 #683658 #1175194.
It would certainly help matters if we implemented
something along the lines of putting a recursive lock on
each module object, held while this specific module is
being imported. More advanced solutions are possible
too, but possibly more disruptive compatibility-wise...
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1473760&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1470422 ] Logging doesn't report the correct filename or line numbers
Bugs item #1470422, was opened at 2006-04-14 15:48 Message generated for change (Comment added) made by vsajip You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1470422&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 Submitted By: Michael Tsai (michaeltsai) >Assigned to: Vinay Sajip (vsajip) Summary: Logging doesn't report the correct filename or line numbers Initial Comment: I have a logger that prints out %(filename)s:%(lineno)d along with the message. Instead of printing the file and line in my code where I call the logger, it prints out a location in logging/__init__.py. I was able to fix this, at least for my purposes, by changing logging.currentframe from sys._getframe to lambda:sys._getframe(3). -- >Comment By: Vinay Sajip (vsajip) Date: 2006-04-21 18:20 Message: Logged In: YES user_id=308438 Please can you provide a small script which demonstrates the problem? Which platform are you running on? Is there anything unusual about your setup (e.g. running from a frozen system)? I'm not sure your patch is the correct solution. The system looks up the call stack until a file is found which is not the source file of the logging module itself - that is presumed to be the caller. However, determining the source file of the logging module can come unstuck in scenarios such as py2exe-ified programs. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1470422&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1470422 ] Logging doesn't report the correct filename or line numbers
Bugs item #1470422, was opened at 2006-04-14 11:48
Message generated for change (Comment added) made by michaeltsai
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1470422&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
Submitted By: Michael Tsai (michaeltsai)
Assigned to: Vinay Sajip (vsajip)
Summary: Logging doesn't report the correct filename or line numbers
Initial Comment:
I have a logger that prints out %(filename)s:%(lineno)d along with the
message. Instead of printing the file and line in my code where I call the
logger, it prints out a location in logging/__init__.py.
I was able to fix this, at least for my purposes, by changing
logging.currentframe from sys._getframe to lambda:sys._getframe(3).
--
>Comment By: Michael Tsai (michaeltsai)
Date: 2006-04-21 15:04
Message:
Logged In: YES
user_id=817528
I'm running on Mac OS X 10.4.6.
Here's a simple script:
"""#!/usr/local/bin/python2.4
import logging
logging.basicConfig(format=u"%(filename)s:%(lineno)d %(message)s")
log = logging.getLogger("test")
log.error(u"this is an error")
"""
Unfortunately, it doesn't reliably fail; most of the time it works. I haven't
figured out how to trigger it.
It does reliably fail when I use a frozen system created with "py2app -A" in
which the Python libraries are symlinked in (rather than in a Zip). Then,
logging._srcfile is "logging/__init__.py", but __file__ is something like "/
System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/
logging/__init__.py" Maybe py2app shouldn't set sys.frozen in this case?
Anyway, I don't think that's the real problem, because I've seen this happen
when not using py2app (but, sorry, I'm not able to reliably duplicate it at
this
time).
My patch isn't really the right fix, but I do think it works because, at least
with
the current logging module, currentframe() is always called with the same
sequence of frames on the top of the stack.
--
Comment By: Vinay Sajip (vsajip)
Date: 2006-04-21 14:20
Message:
Logged In: YES
user_id=308438
Please can you provide a small script which demonstrates the
problem? Which platform are you running on? Is there
anything unusual about your setup (e.g. running from a
frozen system)?
I'm not sure your patch is the correct solution. The system
looks up the call stack until a file is found which is not
the source file of the logging module itself - that is
presumed to be the caller. However, determining the source
file of the logging module can come unstuck in scenarios
such as py2exe-ified programs.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1470422&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1473760 ] TempFile can hang on Windows
Bugs item #1473760, was opened at 2006-04-20 14:35
Message generated for change (Comment added) made by tim_one
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1473760&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: 7
Submitted By: Tim Peters (tim_one)
Assigned to: Nobody/Anonymous (nobody)
Summary: TempFile can hang on Windows
Initial Comment:
Attached is a simple module. If you try to import it
("import hang"), it prints "asking for temp file", and
hangs there, never returning from its call to
tempfile.TemporaryFile(). It's in fact stuck in
ntpath.py, on the "from nt import _getfullpathname"
line in function `abspath`.
Of course hang.py spawns another thread, and is hung
waiting for the import lock. That thread isn't doing
any imports the _user_ knows about, and Python's
standard library should be coded more defensively than
this.
The symptom was reported on zodb-dev today, where
Martin Gfeller reported ZEO hanging on Windows for what
appears to be the same reason:
http://mail.zope.org/pipermail/zodb-dev/2006-April/009989.html
As it says there, it looks like this problem was
introduced (indirectly) by patch
http://www.python.org/sf/810914
which appears to have been revision 34396 (October
2003! -- but not backported to 2.3, so nobody would
notice this before 2.4).
I haven't dug deeper than this, and don't know why
nobody noticed ZEO hanging before ;-)
--
>Comment By: Tim Peters (tim_one)
Date: 2006-04-21 17:26
Message:
Logged In: YES
user_id=31435
Fixed in rev 45631 on the trunk, and rev 45632 on the 2.4
branch.
Armin, I agree this could use a better approach. I settled
for a micro-fix here because this specific one accounts for
a report of Zope Corp's ZEO hanging on Windows, and it was
an odd way to change ntpath.abspath to begin with.
Note that I added a new Lib/test/threaded_import_hangers.py
to check that tempfile.TemporaryFile and os.path.abspath
don't hang anymore, and that's designed to make it easy to
add additional tests of this kind.
--
Comment By: Armin Rigo (arigo)
Date: 2006-04-21 13:22
Message:
Logged In: YES
user_id=4771
The general problem keeps showing up again and again.
I can't find all reference (I remember more), but there
are at least the following open bugs about it:
#689895 #683658 #1175194.
It would certainly help matters if we implemented
something along the lines of putting a recursive lock on
each module object, held while this specific module is
being imported. More advanced solutions are possible
too, but possibly more disruptive compatibility-wise...
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1473760&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
