[ python-Bugs-1678380 ] 0.0 and -0.0 identified, with surprising results
Bugs item #1678380, was opened at 2007-03-11 18:16
Message generated for change (Comment added) made by loewis
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1678380&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: Wont Fix
Priority: 5
Private: No
Submitted By: Mark Dickinson (marketdickinson)
Assigned to: Nobody/Anonymous (nobody)
Summary: 0.0 and -0.0 identified, with surprising results
Initial Comment:
The identification of -0.0 and 0.0 in scripts leads to some surprising
results. In particular, code that behaves one way in the interpreter can
behave differently in a script. For example:
Python 2.6a0 (trunk:54183M, Mar 6 2007, 20:16:00)
[GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from math import atan2;
>>> x = -0.
>>> y = 0.
>>> print atan2(y, -1.)
3.14159265359
But:
>>> exec("from math import atan2; x = -0.; y = 0.; print atan2(y, -1.)")
-3.14159265359
A simpler example:
>>> x, y = -0., 0.
>>> x, y
(-0.0, -0.0)
>>> id(x) == id(y)
True
But:
>>> x = -0.
>>> y = 0.
>>> x, y
(-0.0, 0.0)
This occurs both on SuSE Linux 9.3/i686 and on OS X 10.4.8/PowerPC.
--
>Comment By: Martin v. Löwis (loewis)
Date: 2007-03-12 10:04
Message:
Logged In: YES
user_id=21627
Originator: NO
I also expressed myself badly. I not only meant that programs should not
rely on +0 and -0 being different things across platforms, but that they
should also not rely on them being either always different or always the
same in a single program. If Python would randomly chose to interpret +0 as
-0, or would do so for every third occurence, I still couldn't see a
problem.
--
Comment By: Alex Martelli (aleax)
Date: 2007-03-12 02:54
Message:
Logged In: YES
user_id=60314
Originator: NO
Oops,sorry, I meant patch 1678668 (copy-and-pasted the wrong ID:-).
Alex
--
Comment By: Alex Martelli (aleax)
Date: 2007-03-12 02:51
Message:
Logged In: YES
user_id=60314
Originator: NO
Also see my patch 1678380 which fixes this bug (and checks for it in a new
unittest).
--
Comment By: Mark Dickinson (marketdickinson)
Date: 2007-03-12 02:15
Message:
Logged In: YES
user_id=703403
Originator: YES
I expressed myself badly. I apologise. This really isn't about +0. and
-0.
being different, or not. I'm perfectly comfortable with the idea that +0.
and -0. may or may not be distinguishable on any given platform.
The surprise is the other way around: two *identical* calls to atan(0.,
-1.)
(or to repr(0.) for that matter) give *different* results, depending
solely
on whether a -0. literal has appeared earlier on in the code unit being
compiled.
So if the first float zero literal encountered in a source file just
happens to be a
-0. rather than a 0., the meaning of str(0.) later on suddenly becomes
"-0.0"
rather than "0.0". I'd like to be able to rely on str(0.) meaning "0.0"
without
having to worry about whether there might be a -0. literal appearing in
some
faraway and otherwise completely irrelevant portion of the file.
--
Comment By: Martin v. Löwis (loewis)
Date: 2007-03-11 23:27
Message:
Logged In: YES
user_id=21627
Originator: NO
marketdickinson, you should ask this question (is this really acceptable)
on python-dev. I find it perfectly acceptable. No program should rely on -0
and +0 being two different things (and thus also not relying on atan2
giving two different results).
--
Comment By: Gabriel Genellina (gagenellina)
Date: 2007-03-11 21:10
Message:
Logged In: YES
user_id=479790
Originator: NO
It appears to be a problem in the way compile.c handles literals.
See http://mail.python.org/pipermail/python-list/2007-March/430302.html
--
Comment By: Mark Dickinson (marketdickinson)
Date: 2007-03-11 20:21
Message:
Logged In: YES
user_id=703403
Originator: YES
May I beg for reconsideration.
Is the following really considered acceptable?
>>> x = -0.; atan2(0., -1)
-3.1415926535897931
>>> x = -(0.); atan2(0., -1)
3.1415926535897931
>>> atan2(0., -1)
3.1415926535897931
A single x = -0. at the start of a script can have
side effects several hundred lines later, even when
the variable x is never referred to again. I guess
the advice should be: "To avoid surprises, -0. should
never appear in any script."
---
[ python-Bugs-1675511 ] Python still uses broken -xcode option on Solaris/x86
Bugs item #1675511, was opened at 2007-03-07 15:54 Message generated for change (Comment added) made by jlick You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1675511&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Carson Gaspar (cgaspar) Assigned to: Nobody/Anonymous (nobody) Summary: Python still uses broken -xcode option on Solaris/x86 Initial Comment: Bug 1561333 was submitted against Python 2.4 with no action, so I'm submitting a new bug against 2.5 in the hopes that someone will read it... text updated with minor corrections. Python 2.5, Solaris x86 10 Update 3, Sun Studio 11 xcode=pic32 option is not supported on Solaris x86 Sun C . Python's ./configure script on Solaris systems sets the compiler flag -xcode=pic32 when any compiler other than gcc is used. Unfortunately, the -xcode flag is only available in the sparc version of Sun C. The x86 version of Sun C does not support the -xcode option at all and generates an error that an illegal option was used. The portable flag supported on both platforms to use independent 32-bit addressing is -KPIC. -- Comment By: James Lick (jlick) Date: 2007-03-12 17:52 Message: Logged In: YES user_id=673069 Originator: NO The patch I posted in the last comment also will apply (with warning) to Python 2.4.4 and builds OK. -- Comment By: James Lick (jlick) Date: 2007-03-12 15:37 Message: Logged In: YES user_id=673069 Originator: NO I've made a patch for configure.in to fix this bug. There are two notes to explain why it was written the way it is: The first problem is to determine which processor type we are using. 'uname -p' was chosen because it returns the most generic response on both SPARC (sparc) and x86/x64 (i386) systems. There is some controversy about why it returns 'i386' even on Pentium or AMD64 systems, but Sun points to the isainfo, isalist, or psrinfo commands to get more specific processor information, so it appears they don't intend to change the behavior. The second choice is how to handle the default case if the result of the above is neither sparc or i386. I chose to use '-xcode=pic32' for sparc only, and '-Kpic' for all other responses. My reasoning is that since -Kpic existed before -xcode=pic32 was implemented that it is the more generic option, even though it and -KPIC are deprecated on sparc. I am therefore making the assumption that any possible new platforms supported by Studio 11 would in some fashion support -Kpic. This patch is a diff against Python 2.5's configure.in file. I've tested it against a Solaris 10 32-bit x86 system and a Solaris 10 64-bit sparc system both with Studio 11 installed. I don't have a 64-bit x86 system to test against. The build is mostly successful on both though there is a problem with the _ctypes module which causes test_ctypes to fail. This is a known problem covered by other bug reports which I believe is unrelated to this patch. I couldn't find the option to upload a file, so here is the patch inline: ---snip--- *** configure.in.old2007-03-11 23:01:16.879612000 -0700 --- configure.in2007-03-11 23:31:48.098734000 -0700 *** *** 1543,1551 then case $ac_sys_system/$ac_sys_release in SunOS*) if test "$GCC" = yes; ! then CCSHARED="-fPIC"; ! else CCSHARED="-xcode=pic32"; ! fi;; hp*|HP*) if test "$GCC" = yes; then CCSHARED="-fPIC"; else CCSHARED="+z"; --- 1543,1553 then case $ac_sys_system/$ac_sys_release in SunOS*) if test "$GCC" = yes; ! then CCSHARED="-fPIC"; ! elif test `uname -p` = sparc; ! then CCSHARED="-xcode=pic32"; ! else CCSHARED="-Kpic"; ! fi;; hp*|HP*) if test "$GCC" = yes; then CCSHARED="-fPIC"; else CCSHARED="+z"; ---snip--- -- Comment By: Martin v. Löwis (loewis) Date: 2007-03-11 03:06 Message: Logged In: YES user_id=21627 Originator: NO The manual claims (in "Supported Platforms") that "x86" refers to both 32-bit and 64-bit systems, and promises to use "32-bit x86" for 32-bit specific information, so I guess -Kpic works on AMD64 as well. -- Comment By: James Lick (jlick) Date: 2007-03-11 02:35 Message: Logged In: YES user_id=673069 Originator: NO According the the Studio 11 man page for cc '-KPIC' is an alias for '-Kpic' on x86, though it doesn't explicitly s
[ python-Bugs-1675511 ] Python still uses broken -xcode option on Solaris/x86
Bugs item #1675511, was opened at 2007-03-07 08:54 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1675511&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Carson Gaspar (cgaspar) Assigned to: Nobody/Anonymous (nobody) Summary: Python still uses broken -xcode option on Solaris/x86 Initial Comment: Bug 1561333 was submitted against Python 2.4 with no action, so I'm submitting a new bug against 2.5 in the hopes that someone will read it... text updated with minor corrections. Python 2.5, Solaris x86 10 Update 3, Sun Studio 11 xcode=pic32 option is not supported on Solaris x86 Sun C . Python's ./configure script on Solaris systems sets the compiler flag -xcode=pic32 when any compiler other than gcc is used. Unfortunately, the -xcode flag is only available in the sparc version of Sun C. The x86 version of Sun C does not support the -xcode option at all and generates an error that an illegal option was used. The portable flag supported on both platforms to use independent 32-bit addressing is -KPIC. -- >Comment By: Martin v. Löwis (loewis) Date: 2007-03-12 11:52 Message: Logged In: YES user_id=21627 Originator: NO Thanks for the patch. Committed as r54283 and r54284. -- Comment By: James Lick (jlick) Date: 2007-03-12 10:52 Message: Logged In: YES user_id=673069 Originator: NO The patch I posted in the last comment also will apply (with warning) to Python 2.4.4 and builds OK. -- Comment By: James Lick (jlick) Date: 2007-03-12 08:37 Message: Logged In: YES user_id=673069 Originator: NO I've made a patch for configure.in to fix this bug. There are two notes to explain why it was written the way it is: The first problem is to determine which processor type we are using. 'uname -p' was chosen because it returns the most generic response on both SPARC (sparc) and x86/x64 (i386) systems. There is some controversy about why it returns 'i386' even on Pentium or AMD64 systems, but Sun points to the isainfo, isalist, or psrinfo commands to get more specific processor information, so it appears they don't intend to change the behavior. The second choice is how to handle the default case if the result of the above is neither sparc or i386. I chose to use '-xcode=pic32' for sparc only, and '-Kpic' for all other responses. My reasoning is that since -Kpic existed before -xcode=pic32 was implemented that it is the more generic option, even though it and -KPIC are deprecated on sparc. I am therefore making the assumption that any possible new platforms supported by Studio 11 would in some fashion support -Kpic. This patch is a diff against Python 2.5's configure.in file. I've tested it against a Solaris 10 32-bit x86 system and a Solaris 10 64-bit sparc system both with Studio 11 installed. I don't have a 64-bit x86 system to test against. The build is mostly successful on both though there is a problem with the _ctypes module which causes test_ctypes to fail. This is a known problem covered by other bug reports which I believe is unrelated to this patch. I couldn't find the option to upload a file, so here is the patch inline: ---snip--- *** configure.in.old2007-03-11 23:01:16.879612000 -0700 --- configure.in2007-03-11 23:31:48.098734000 -0700 *** *** 1543,1551 then case $ac_sys_system/$ac_sys_release in SunOS*) if test "$GCC" = yes; ! then CCSHARED="-fPIC"; ! else CCSHARED="-xcode=pic32"; ! fi;; hp*|HP*) if test "$GCC" = yes; then CCSHARED="-fPIC"; else CCSHARED="+z"; --- 1543,1553 then case $ac_sys_system/$ac_sys_release in SunOS*) if test "$GCC" = yes; ! then CCSHARED="-fPIC"; ! elif test `uname -p` = sparc; ! then CCSHARED="-xcode=pic32"; ! else CCSHARED="-Kpic"; ! fi;; hp*|HP*) if test "$GCC" = yes; then CCSHARED="-fPIC"; else CCSHARED="+z"; ---snip--- -- Comment By: Martin v. Löwis (loewis) Date: 2007-03-10 20:06 Message: Logged In: YES user_id=21627 Originator: NO The manual claims (in "Supported Platforms") that "x86" refers to both 32-bit and 64-bit systems, and promises to use "32-bit x86" for 32-bit specific information, so I guess -Kpic works on AMD64 as well.
[ 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 (Comment added) 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? -- >Comment By: Richard B. Kreckel (richyk) Date: 2007-03-12 12:30 Message: Logged In: YES user_id=1718463 Originator: YES Sorry, I cannot do that test anytime soon. (I've not enough time and my company doesn't let me access your SVN.) -- Comment By: Neal Norwitz (nnorwitz) Date: 2007-02-25 23:16 Message: Logged In: YES user_id=33168 Originator: NO Can you test with 2.5 from SVN and confirm your program works in the complete context? -- Comment By: Richard B. Kreckel (richyk) Date: 2007-02-22 13:25 Message: Logged In: YES user_id=1718463 Originator: YES The error message about the undefined init function is a red herring. The example is actually a stripped-down testcase from a much larger Boost.Python module, which of course does have an init function. The point here is the NULL pointer returned by tparm. -- Comment By: Martin v. Löwis (loewis) Date: 2007-02-14 22:24 Message: Logged In: YES user_id=21627 Originator: NO I fail to see the bug. The exception precisely describes the error in your code ImportError: dynamic module does not define init function (inittestlib) Why do you expect any meaningful behavior in the presence of this error? Your shared library isn't an extension module. If you think it is related to #1548092, please try out the subversion trunk, which has fixed this bug. -- Comment By: Richard B. Kreckel (richyk) Date: 2007-02-14 09:52 Message: Logged In: YES user_id=1718463 Originator: YES I suspect that this is a duplicate of Bug [1548092]. Note that, there it is asserted that tparm returns NULL on certain invalid strings. That does not seem to be true. It returns NULL for valid trivial strings, too. -- 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
Re: sys.settrace closure interaction bug
Can you file a bug report for this? I'm guessing that the trace code
has some bad interaction with LOAD_LOCALS, such that a free variable
passed through the class gets treated as local instead. I can
reproduce this problem in Python 2.4, so it's a long-standing bug.
Also, as a matter of terminology, there is no currying going on. It's
just a problem with closures.
Jeremy
On 10/1/06, Scott Marks <[EMAIL PROTECTED]> wrote:
> The code below exhibits different behavior depending on whether it invokes
> sys.settrace ('-t' option) or not. This means that (in a more complicated
> case) debugging the code (which uses sys.settrace) makes it fail. Any
> ideas?
>
> """ Demonstrace that tracing messes up curried class definitions """
>
> # Some simple command line parsing: -t or --trace means trace, nothing
> means don't trace
> import sys
>
> def usage( ):
> print 'Usage:', sys.argv[ 0 ], '[-t | --trace]'
> sys.exit( 1 )
>
> if 1 == len( sys.argv ):
> pass
> elif 2 == len( sys.argv ):
> if sys.argv[ 1 ]=='-t' or sys.argv[ 1 ]=='--trace':
> def trace ( frame, event, arg ):
> # print frame, event, arg
> return trace
> sys.settrace( trace )
> else:
> usage( )
> else:
> usage( )
>
>
>
> # The test: define a class factory with a curried member function
>
> def the_factory( parm1 ):
> class the_class( object ):
> def curried( self ): return parm1
> return the_class
>
> x = the_factory( 42 )
>
> y = x( )
>
> try:
> x.parm1
> print "Failure: x (the manufactured class) has attribute parm1?!"
> except AttributeError:
> print "Success with the manufactured class!"
>
> try:
> y.parm1
> print "Failure: y (the instance) has attribute parm1?!"
> except AttributeError:
> print "Success with the instance!"
>
> assert y.curried( ) == 42, "Currying didn't work?!"
>
>
> ___
> Python-bugs-list mailing list
> Unsubscribe:
> http://mail.python.org/mailman/options/python-bugs-list/jeremy%40alum.mit.edu
>
>
>
>
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
TypeError: decoding Unicode is not supported
later after some small revisions, it comes here: Traceback (most recent call last): File "C:\BitTornado-0.3.15\BitTornado-CVS\btdownloadgui.py", line 2349, in _next savedas = dow.saveAs(choosefile,d.newpath) File "C:\BitTornado-0.3.15\BitTornado-CVS\BitTornado\download_bt1.py", line 411, in saveAs existing = 1 TypeError: decoding Unicode is not supported and i donot know how to handle with it, if len(listdir(file)) > 0: # if it's not empty for x in self.info['files']: if path.exists(path.join(file, x['path'][0])): existing = 1 here is the revision,and formerly i make some revisions on import sys if path.exists(path.join(unicode(file,'utf-8'), unicode(x['path'][0],'utf-8')): and since then the TypeError remains though i have removed that statement. thanks, if anyone can be helpful. jolley - 雅虎免费邮箱-3.5G容量，20M附件___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
UnicodeDecodeError problem when run BitTorrent module
hello guys, i have a problem that when i compile one of bittornado source file
named:btdownloadgui.py and i get such a error message:
Code: [Download]
BitTorrent T-0.3.15 (BitTornado)
OS: win32
Python version: 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit
(Intel)]
wxWindows version: 2.6.3.3
Traceback (most recent call last):
File "C:\BitTornado-0.3.15\BitTornado-CVS\btdownloadgui.py", line 2334, in
_next
savedas = dow.saveAs(choosefile, d.newpath)
File "C:\BitTornado-0.3.15\BitTornado-CVS\BitTornado\download_bt1.py",
line 409, in saveAs
if path.exists(path.join(file, x['path'][0])):
File "C:\Python24\lib\ntpath.py", line 102, in join
path += "\\" + b
UnicodeDecodeError: 'ascii' codec can't decode byte 0xb9 in position 1:
ordinal not in range(128)
of those errors: one is from bittornado source file btdownloadgui.py itself,and
one is from the the bittornado library,also one is from the python library.
weird,isn't it?
later i get something more about bittorrent encodings and
decodings,utf-8,utf-16,ascii,latin.etc.and i try almost all of these decodings
and encodings,such as use decode('utf-8'),or encode('utf-16')etc.and those
doings donot come out effectively.
later i use
Code: [Download]
try:
from sys import getfilesystemencoding
ENCODING = getfilesystemencoding()
except:
from sys import getdefaultencoding
ENCODING = getdefaultencoding()
in the btdowngui.py source file,however the bug remains.
does it means the bittornado library or the python library itself is
misleading?
so help.
thanks if anyone can be useful.
regards,
jolley
-
Mp3疯狂搜-新歌热歌高速下 ___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
difflib.SequenceMatcher fails for larger strings
I'm trying to write a program to test a persons typing speed and show them their mistakes. However I'm getting weird results when looking for the differences in longer strings: import difflib a = '01234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789' # now with a few mistakes b = '012345W7890123456789012W456789012345678901W3456789012345678901234567890W234567890123456789012345W789012345678901234567890123W567890123456W89012345678901234567W90123456789012W4567890123456W890123456789' s = difflib.SequenceMatcher(None, a, b) print s.get_matching_blocks() print s.get_opcodes() Is this a known bug? Would it just take to long to calculate? ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Python 2.5, missing KERNEL32.DLL, Win95B
Hello all, Total newbie: Installed Python 2.5 onto a Win 95 4.00.950B O/S. (BTW, fixed CTL3D32.DLL, it was the wrong one!) I'm getting this error message every time I attempt to start Python: "The PYTHON25.DLL file is linked to missing export KERNEL32.DLL:GetFileAttributesExA." Helup! Many thanks, John. ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
GetFileAttributesExA and Win95
Hi all, Just installed Python 2.5 on my Win95B machine, tried to run it, but immediately got this error message; "The PYTHON25.DLL file is linked to missing export KERNELL32.DLL :GetFileAttributedExA" In FAQ, I noted this has been asked before[1], but I cannot find the solution? Can anyone please help? Perhaps, Martin v. Löwis? Thank you all& Best Regards, John Collins. [1] -Copy of Previous Q&A on this problem- Category: None Group: None >Status: Open Resolution: Fixed Priority: 7 Submitted By: giomach (giomach) Assigned to: Martin v. Löwis (loewis) Summary: GetFileAttributesExA and Win95 Initial Comment: When Python 2.5 is run under Win95 (Windows 4.00.950B), it immediately fails with "The PYTHON25.DLL file is linked to missing export KERNEL32.DLL.GetFileAttributesExA". Python 2.4.3 is fine. Ciarán Ó Duibhín. My e-mail: ciaran at oduibhin.freeserve.co.uk -- >Comment By: giomach (giomach) Date: 2006-10-15 18:46 Message: Logged In: YES user_id=1116705 Thanks, this new installer seems to work under Win95. Vielen Dank, Ciarán Ó Duibhín. -- Comment By: Martin v. Löwis (loewis) Date: 2006-10-15 10:07 Message: Logged In: YES user_id=21627 This should now be fixed in r52339 and r52340. I can't test it on Win95, though, so I created an inofficial, incomplete installer on http://www.dcl.hpi.uni-potsdam.de/home/loewis/python-2.5.13436.msi Please try it out and report here whether it works. -- ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1590744 ] mail message parsing glitch
Bugs item #1590744, was opened at 2006-11-05 04:21 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1590744&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: Mike (mcspang) Assigned to: Barry A. Warsaw (bwarsaw) Summary: mail message parsing glitch Initial Comment: There's something wrong with the handling of line continuation in headers. In the attached mbox the 'Message-id' header is read and stored with a leading space. So message_id = ' <[EMAIL PROTECTED]>' when it's first read. If you write this message out to a new mbox, it is written with the leading space and without the newline. THEN, if you read it in AGAIN, the parser ignores the leading space. One of these steps is buggy, I'm not sure which. It seems to me that the value returned by msg['Message_id'] should not change when the file is written then re-read. In the initial read and final reads above the value differs by a space. -- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2007-03-12 09:51 Message: Logged In: YES user_id=12800 Originator: NO This makes some sense, although it may not be ideal. The "leading space" is really an RFC 2822 continuation line, so that whitespace at the start of the second line is folding whitespace. Technically those two lines should (and do) get collapsed. The question is whether this message should be printed idempotently. In general the email package tries hard to maintain this principle, so I think it's probably a valid bug. However, it doesn't affect the semantics of the message so it's not a high priority fix. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1590744&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1678647 ] Weird behavior Exception with unicode string
Bugs item #1678647, was opened at 2007-03-11 21:20 Message generated for change (Comment added) made by llucax You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1678647&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: Unicode Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Leandro Lucarella (llucax) Assigned to: M.-A. Lemburg (lemburg) Summary: Weird behavior Exception with unicode string Initial Comment: This simple python program: --- raise Exception(u'Muri\u00f3') --- prints: --- Traceback (most recent call last): File "pylog.py", line 1, in ? raise Exception(u'Muri\u00f3') Exception --- While not using an unicode character, seems to work fine (even if using an unicode parameter): -- raise Exception(u'Murio') -- prints: --- Traceback (most recent call last): File "pylog.py", line 1, in ? raise Exception(u'Murio') Exception: Murio --- This seems to break the logging module when calling logging.exception(u'Muri\u00f3'), for example. Tested in Python 2.4.4 and 2.5 (debian). -- >Comment By: Leandro Lucarella (llucax) Date: 2007-03-12 11:03 Message: Logged In: YES user_id=240225 Originator: YES But why the conversion is failing in the first place? Because just plain 7 bits ASCII is expected? -- Comment By: Hye-Shik Chang (perky) Date: 2007-03-12 01:43 Message: Logged In: YES user_id=55188 Originator: NO That's from line 1216-1230 of Python/pythonrun.c as in trunk. It tries PyObject_Str(exception) and skips printing line terminator when it failed. And the behavior came from r8084 (http://svn.python.org/view/python/trunk/Python/pythonrun.c?rev=8084&r1=8070&r2=8084). Hmm. I think it should put a LF even if the conversion failed. (encoding the unicode with "ignore" or "replace" would make some confusion and putting it in PyObject_Repr() makes inconsistency.) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1678647&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1678647 ] Weird behavior Exception with unicode string
Bugs item #1678647, was opened at 2007-03-12 00:20 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1678647&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: Unicode Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Leandro Lucarella (llucax) Assigned to: M.-A. Lemburg (lemburg) Summary: Weird behavior Exception with unicode string Initial Comment: This simple python program: --- raise Exception(u'Muri\u00f3') --- prints: --- Traceback (most recent call last): File "pylog.py", line 1, in ? raise Exception(u'Muri\u00f3') Exception --- While not using an unicode character, seems to work fine (even if using an unicode parameter): -- raise Exception(u'Murio') -- prints: --- Traceback (most recent call last): File "pylog.py", line 1, in ? raise Exception(u'Murio') Exception: Murio --- This seems to break the logging module when calling logging.exception(u'Muri\u00f3'), for example. Tested in Python 2.4.4 and 2.5 (debian). -- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-12 14:14 Message: Logged In: YES user_id=849994 Originator: NO Yes, or more precisely, the unicode string is converted to a byte string using Python's default encoding, which is ASCII per default. -- Comment By: Leandro Lucarella (llucax) Date: 2007-03-12 14:03 Message: Logged In: YES user_id=240225 Originator: YES But why the conversion is failing in the first place? Because just plain 7 bits ASCII is expected? -- Comment By: Hye-Shik Chang (perky) Date: 2007-03-12 04:43 Message: Logged In: YES user_id=55188 Originator: NO That's from line 1216-1230 of Python/pythonrun.c as in trunk. It tries PyObject_Str(exception) and skips printing line terminator when it failed. And the behavior came from r8084 (http://svn.python.org/view/python/trunk/Python/pythonrun.c?rev=8084&r1=8070&r2=8084). Hmm. I think it should put a LF even if the conversion failed. (encoding the unicode with "ignore" or "replace" would make some confusion and putting it in PyObject_Repr() makes inconsistency.) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1678647&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1678380 ] 0.0 and -0.0 identified, with surprising results
Bugs item #1678380, was opened at 2007-03-11 10:16
Message generated for change (Comment added) made by aleax
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1678380&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: Wont Fix
Priority: 5
Private: No
Submitted By: Mark Dickinson (marketdickinson)
Assigned to: Nobody/Anonymous (nobody)
Summary: 0.0 and -0.0 identified, with surprising results
Initial Comment:
The identification of -0.0 and 0.0 in scripts leads to some surprising
results. In particular, code that behaves one way in the interpreter can
behave differently in a script. For example:
Python 2.6a0 (trunk:54183M, Mar 6 2007, 20:16:00)
[GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from math import atan2;
>>> x = -0.
>>> y = 0.
>>> print atan2(y, -1.)
3.14159265359
But:
>>> exec("from math import atan2; x = -0.; y = 0.; print atan2(y, -1.)")
-3.14159265359
A simpler example:
>>> x, y = -0., 0.
>>> x, y
(-0.0, -0.0)
>>> id(x) == id(y)
True
But:
>>> x = -0.
>>> y = 0.
>>> x, y
(-0.0, 0.0)
This occurs both on SuSE Linux 9.3/i686 and on OS X 10.4.8/PowerPC.
--
>Comment By: Alex Martelli (aleax)
Date: 2007-03-12 07:57
Message:
Logged In: YES
user_id=60314
Originator: NO
and yet, peephole.c does specialcase -0 (with a comment and all!-)
avoiding constant-folding optimization for it -- making things work fine in
Python 2.4.x for high enough x -- it's just that peephole.c's efforts are
defeated by a similar optimization applied without specialcase checking in
ast.c in Python 2.5. This is inconsistent: it makes no sense to take SOME
of the precautions needed to avoid an issue but not ALL of them, since this
makes the issue appear anyway, so those precautions that ARE taken are
there for no purpose (except a miniscule slowdown and enlargement of the
interpreter:-). Either we save those few lines of code in peephole.c or
add the few lines to ast.c that I suggest in my patch 1678668 -- the
current situation makes no sense.
--
Comment By: Martin v. Löwis (loewis)
Date: 2007-03-12 02:04
Message:
Logged In: YES
user_id=21627
Originator: NO
I also expressed myself badly. I not only meant that programs should not
rely on +0 and -0 being different things across platforms, but that they
should also not rely on them being either always different or always the
same in a single program. If Python would randomly chose to interpret +0 as
-0, or would do so for every third occurence, I still couldn't see a
problem.
--
Comment By: Alex Martelli (aleax)
Date: 2007-03-11 18:54
Message:
Logged In: YES
user_id=60314
Originator: NO
Oops,sorry, I meant patch 1678668 (copy-and-pasted the wrong ID:-).
Alex
--
Comment By: Alex Martelli (aleax)
Date: 2007-03-11 18:51
Message:
Logged In: YES
user_id=60314
Originator: NO
Also see my patch 1678380 which fixes this bug (and checks for it in a new
unittest).
--
Comment By: Mark Dickinson (marketdickinson)
Date: 2007-03-11 18:15
Message:
Logged In: YES
user_id=703403
Originator: YES
I expressed myself badly. I apologise. This really isn't about +0. and
-0.
being different, or not. I'm perfectly comfortable with the idea that +0.
and -0. may or may not be distinguishable on any given platform.
The surprise is the other way around: two *identical* calls to atan(0.,
-1.)
(or to repr(0.) for that matter) give *different* results, depending
solely
on whether a -0. literal has appeared earlier on in the code unit being
compiled.
So if the first float zero literal encountered in a source file just
happens to be a
-0. rather than a 0., the meaning of str(0.) later on suddenly becomes
"-0.0"
rather than "0.0". I'd like to be able to rely on str(0.) meaning "0.0"
without
having to worry about whether there might be a -0. literal appearing in
some
faraway and otherwise completely irrelevant portion of the file.
--
Comment By: Martin v. Löwis (loewis)
Date: 2007-03-11 15:27
Message:
Logged In: YES
user_id=21627
Originator: NO
marketdickinson, you should ask this question (is this really acceptable)
on python-dev. I find it perfectly acceptable. No program should rely on -0
and +0 being two different things (and thus also not relying on atan2
giving two different results).
[ python-Bugs-1678647 ] Weird behavior Exception with unicode string
Bugs item #1678647, was opened at 2007-03-12 00:20 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1678647&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: Unicode Group: None >Status: Closed >Resolution: Wont Fix Priority: 5 Private: No Submitted By: Leandro Lucarella (llucax) Assigned to: M.-A. Lemburg (lemburg) Summary: Weird behavior Exception with unicode string Initial Comment: This simple python program: --- raise Exception(u'Muri\u00f3') --- prints: --- Traceback (most recent call last): File "pylog.py", line 1, in ? raise Exception(u'Muri\u00f3') Exception --- While not using an unicode character, seems to work fine (even if using an unicode parameter): -- raise Exception(u'Murio') -- prints: --- Traceback (most recent call last): File "pylog.py", line 1, in ? raise Exception(u'Murio') Exception: Murio --- This seems to break the logging module when calling logging.exception(u'Muri\u00f3'), for example. Tested in Python 2.4.4 and 2.5 (debian). -- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-12 15:18 Message: Logged In: YES user_id=849994 Originator: NO I fixed the "prints no newline" problem in rev. 54288. There's nothing sensible we can do about the unicode conversion, so closing as "won't fix". You should always encode or repr() unicode exception arguments. -- Comment By: Georg Brandl (gbrandl) Date: 2007-03-12 14:14 Message: Logged In: YES user_id=849994 Originator: NO Yes, or more precisely, the unicode string is converted to a byte string using Python's default encoding, which is ASCII per default. -- Comment By: Leandro Lucarella (llucax) Date: 2007-03-12 14:03 Message: Logged In: YES user_id=240225 Originator: YES But why the conversion is failing in the first place? Because just plain 7 bits ASCII is expected? -- Comment By: Hye-Shik Chang (perky) Date: 2007-03-12 04:43 Message: Logged In: YES user_id=55188 Originator: NO That's from line 1216-1230 of Python/pythonrun.c as in trunk. It tries PyObject_Str(exception) and skips printing line terminator when it failed. And the behavior came from r8084 (http://svn.python.org/view/python/trunk/Python/pythonrun.c?rev=8084&r1=8070&r2=8084). Hmm. I think it should put a LF even if the conversion failed. (encoding the unicode with "ignore" or "replace" would make some confusion and putting it in PyObject_Repr() makes inconsistency.) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1678647&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1678647 ] Weird behavior Exception with unicode string
Bugs item #1678647, was opened at 2007-03-11 21:20 Message generated for change (Comment added) made by llucax You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1678647&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: Unicode Group: None Status: Closed Resolution: Wont Fix Priority: 5 Private: No Submitted By: Leandro Lucarella (llucax) Assigned to: M.-A. Lemburg (lemburg) Summary: Weird behavior Exception with unicode string Initial Comment: This simple python program: --- raise Exception(u'Muri\u00f3') --- prints: --- Traceback (most recent call last): File "pylog.py", line 1, in ? raise Exception(u'Muri\u00f3') Exception --- While not using an unicode character, seems to work fine (even if using an unicode parameter): -- raise Exception(u'Murio') -- prints: --- Traceback (most recent call last): File "pylog.py", line 1, in ? raise Exception(u'Murio') Exception: Murio --- This seems to break the logging module when calling logging.exception(u'Muri\u00f3'), for example. Tested in Python 2.4.4 and 2.5 (debian). -- >Comment By: Leandro Lucarella (llucax) Date: 2007-03-12 12:39 Message: Logged In: YES user_id=240225 Originator: YES > You should always encode or repr() unicode exception arguments. That's odd... :S At least it's any way to change the default Python encoding? -- Comment By: Georg Brandl (gbrandl) Date: 2007-03-12 12:18 Message: Logged In: YES user_id=849994 Originator: NO I fixed the "prints no newline" problem in rev. 54288. There's nothing sensible we can do about the unicode conversion, so closing as "won't fix". You should always encode or repr() unicode exception arguments. -- Comment By: Georg Brandl (gbrandl) Date: 2007-03-12 11:14 Message: Logged In: YES user_id=849994 Originator: NO Yes, or more precisely, the unicode string is converted to a byte string using Python's default encoding, which is ASCII per default. -- Comment By: Leandro Lucarella (llucax) Date: 2007-03-12 11:03 Message: Logged In: YES user_id=240225 Originator: YES But why the conversion is failing in the first place? Because just plain 7 bits ASCII is expected? -- Comment By: Hye-Shik Chang (perky) Date: 2007-03-12 01:43 Message: Logged In: YES user_id=55188 Originator: NO That's from line 1216-1230 of Python/pythonrun.c as in trunk. It tries PyObject_Str(exception) and skips printing line terminator when it failed. And the behavior came from r8084 (http://svn.python.org/view/python/trunk/Python/pythonrun.c?rev=8084&r1=8070&r2=8084). Hmm. I think it should put a LF even if the conversion failed. (encoding the unicode with "ignore" or "replace" would make some confusion and putting it in PyObject_Repr() makes inconsistency.) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1678647&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-742342 ] Python crashes if recursively reloading modules
Bugs item #742342, was opened at 2003-05-23 10:03 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=742342&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: Python 2.6 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Christian Eder (chris_ce) Assigned to: Nobody/Anonymous (nobody) Summary: Python crashes if recursively reloading modules Initial Comment: If one tries to recursively reload modules, python crashes with a segfault. e.g. if the file "foo.py" looks something like: import foo reload (foo) the python interpreter crashes when reading this file. I have been able to reproduce the problem both with python2.2 and python2.3 under linux. Although recursive reloads are faulty code, this should lead to an exception but not to a segfault of the interpreter. In our case, this bug allows a faulty user script to crash our program. Sorry if this is already a known bug, but I searched in Sorceforge (and also in Google) and did not find something similar. -- >Comment By: Collin Winter (collinwinter) Date: 2007-03-12 12:51 Message: Logged In: YES user_id=1344176 Originator: NO Fixed in r54291 (trunk), r54294 (release25-maint). Thanks for the bug report, Christian! -- Comment By: Christian Eder (chris_ce) Date: 2003-05-24 05:10 Message: Logged In: YES user_id=785436 You're right, there's nothing wrong with recursive imports (we also use them in our sources), but with recursive reloads. As far as I know the import statement reads the module only if it is not registered in sys.modules. If modules are added to sys.modules before they are parsed (as I suppose they are) a recursive import does no harm because the module is read only once. But I think the reload statement re-reads the file unconditionally (is it so ?) and may therefore cause an endless recursion. If the interpreter keeps a graph of files and the relations which file causes a reading of another file (either by importing a file which is not yet in sys.modules or by reloading), situations like recursive reloads could be easily detected as they would introduce cycles to the graph. However this is just an idea, maybe an implementation would cost too much permance. I will research the problem further and notice you if I find some kind of workaround. -- Comment By: Tim Peters (tim_one) Date: 2003-05-23 14:56 Message: Logged In: YES user_id=31435 The default recursion limit is unconditionally defined -- it doesn't vary across platforms. If you can submit a patch, that would help. Note that there's nothing wrong with (indirectly) recursive imports in Python (they're delicate but frequently used anyway), so we can't raise an exception on that. -- Comment By: Christian Eder (chris_ce) Date: 2003-05-23 14:30 Message: Logged In: YES user_id=785436 I tried it on 2 of our development PC's and got the following results on both of them: sys.getrecursionlimit () ===> 1000 python find_recursionlimit.py ===> 2800 Seems a bit strange, doesn't it ? I had expected the sys.recursionlimit to be higher than the actual limit. Anyway, recursive reloads are quite easy to detect, so shouldn't the interpreter detect such statements and raise an appropriate error exception (not resulting in a maximum recursion depth exceeded error) -- Comment By: Jeremy Hylton (jhylton) Date: 2003-05-23 12:01 Message: Logged In: YES user_id=31392 I expect this is a platform-specific problem with the Python recursion limit. Can you report two things? The value returned by sys.getrecursionlimit(), and the last limit reported by Misc/find_recursionlimit.py. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=742342&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1628987 ] inspect trouble when source file changes
Bugs item #1628987, was opened at 2007-01-05 13:43 Message generated for change (Settings changed) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1628987&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: Wont Fix Priority: 5 Private: No Submitted By: phil (philipdumont) Assigned to: Nobody/Anonymous (nobody) Summary: inspect trouble when source file changes Initial Comment: backtrace (relevant outer frames only): File "/path/to/myfile", line 1198, in get_hook_name for frame_record in inspect.stack(): File "/usr/mbench2.2/lib/python2.4/inspect.py", line 819, in stack return getouterframes(sys._getframe(1), context) File "/usr/mbench2.2/lib/python2.4/inspect.py", line 800, in getouterframes framelist.append((frame,) + getframeinfo(frame, context)) File "/usr/mbench2.2/lib/python2.4/inspect.py", line 775, in getframeinfo lines, lnum = findsource(frame) File "/usr/mbench2.2/lib/python2.4/inspect.py", line 437, in findsource if pat.match(lines[lnum]): break IndexError: list index out of range Based on a quick look at the inspect code, I think this happens when you: - Start python and load a module - While it's running, edit the source file for the module (before inspect tries to look into it). - Call a routine in the edited module that will lead to a call to inspect.stack(). During an inspect.stack() call, inspect will open source files to get the source code for the routines on the stack. If the source file that is opened doesn't match the byte compiled code that's being run, there are problems. Inspect caches the files it reads (using the linecache module), so if the file gets cached before it is edited, nothing should go wrong. But if the source file is edited after the module is loaded and before inspect has a chance to cache the source, you're out of luck. Of course, this shouldn't be a problem in production code, but it has bit us more than once in a development environment. Seems like it would be easy to avoid by just comparing the timestamps on the source/object files. If the source file is newer, just behave the same as if it wasn't there. Attached is a stupid little python script that reproduces the problem. -- Comment By: Collin Winter (collinwinter) Date: 2007-03-09 18:18 Message: Logged In: YES user_id=1344176 Originator: NO """ To be able to fix this right, you'd have to know what the timestamp was on whatever file was loaded at the time that import loaded it. I guess import itself would have to stash this away somewhere. """ While I don't see this change being made, you might talk to Brett Cannon about it. He's working on a rewrite of the import machinery in Python and probably knows that system better than most by this point. Unless he/you can come up with something, though, I'm inclined to close the bug because of its provocation difficulty. -- Comment By: phil (philipdumont) Date: 2007-03-09 13:25 Message: Logged In: YES user_id=1364034 Originator: YES What I had in mind was something like changing: def getsourcefile(object): """Return the Python source file an object was defined in, if it exists.""" filename = getfile(object) if string.lower(filename[-4:]) in ['.pyc', '.pyo']: filename = filename[:-4] + '.py' # ...the rest of the function... to def getsourcefile(object): """Return the Python source file an object was defined in, if it exists.""" filename = getfile(object) if string.lower(filename[-4:]) in ['.pyc', '.pyo']: src_filename = filename[:-4] + '.py' try: # if src file has been edited since we loaded the obj file, ignore it if os.stat(filename).st_mtime > os.stat(src_filename).st_mtime: filename = src_filename except OSError: pass # ...the rest of the function... But now that I've tried to implement it, and thought about it a bit more, I see some of the issues with what I thought would be a simple fix: - I originally thought that, if a module is loaded from source (either because the objfile did not exist, or because objfile was older), and the compiled src was successfully written to a new objfile, that inspect.getfile() would return the path to the objfile. I see now that that is not the case; it returns the srcfile. That makes my fix a bit more difficult -- now you have to find out if there is an obj file, and if so, what it's called. And even if you had a handle on both the srcfile and the objfile: - Even if the srcfile's t
[ python-Feature Requests-1673203 ] add identity function
Feature Requests item #1673203, was opened at 2007-03-03 16:21 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1673203&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: paul rubin (phr) Assigned to: Raymond Hettinger (rhettinger) Summary: add identity function Initial Comment: Requested and assigned to Raymond at his suggestion: http://groups.google.com/group/comp.lang.python/msg/603870361743c85c There should be an identify function identity(x)=x. I suggest it also take and ignore an optional second arg: identity(x1,x2)=x1. The second arg can be useful in some generator expressions: foo = (x for x in bar if condition(x) and identity(True, memoize(x)) That allows calling memoize (or some other function) on the selected elements in the genexp, and disposing of the returned value. It's sort of like the const function (K combinator) to go along with the identity function's I combinator. OK, the above is not really in the functional spirit, but it's been useful. There could conceivably be also an actual const function const(k)=partial(identity,k) but I can't remember needing that in Python code. The two-arg identity function (uncurried version of const) is probably enough. -- Comment By: Josiah Carlson (josiahcarlson) Date: 2007-03-12 13:06 Message: Logged In: YES user_id=341410 Originator: NO Not all x line functions should be built into Python. Further, Python's standard syntax offers an infix operator that does the same thing (though in slightly different order as described below, you can reorder with minimal effort). identity(X, Y) -> (Y and False) or X Also, the only use-case that you are provided and that I can imagine, are examples like you provide where one is changing state within a statement (if, elif, while, etc.) or expression (generator, list comprehension, conditional, etc.). -- Comment By: Alexander Belopolsky (belopolsky) Date: 2007-03-05 06:21 Message: Logged In: YES user_id=835142 Originator: NO 1. If this proposal is accepted, it will make sense to deprecate the use of None as an identity function in map: >>> map(None, range(10)) [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] 2. Some other languages have an dyadic identity function that returns the *second* argument. For example, K has : primitive: identity:(:) identity[1;2] 2 The rationale in K is that it is useful in an ammed function that replaces entries of an an array with a result of a dyadic function applied to the old and the supplied value and it is natural to have old value first: @[1 2 3;1;-;20] 1 -18 3 @[1 2 3;1;:;20] 1 20 3 This rationale does not apply to Python, but in the absence of other reasons to choose the order of arguments, Python may as well follow the precedent. Does anyone know a less exotic language that has a dyadic identity? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1673203&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1630844 ] fnmatch.translate undocumented
Bugs item #1630844, was opened at 2007-01-08 20:29 Message generated for change (Comment added) made by sonderblade You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1630844&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: Open Resolution: None Priority: 5 Private: No Submitted By: Gabriel Genellina (gagenellina) Assigned to: Nobody/Anonymous (nobody) Summary: fnmatch.translate undocumented Initial Comment: fnmatch.translate is not documented, but it is menctioned on the module docstring and in __all__, so it appears to be public. -- Comment By: Bj�rn Lindqvist (sonderblade) Date: 2007-03-12 23:46 Message: Logged In: YES user_id=51702 Originator: NO Patch #1679379 should fix it. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1630844&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1667877 ] Install fails with no error
Bugs item #1667877, was opened at 2007-02-24 08:10 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1667877&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: Installation Group: None >Status: Closed Resolution: Wont Fix Priority: 5 Private: No Submitted By: larry (widgeteye) Assigned to: Nobody/Anonymous (nobody) Summary: Install fails with no error Initial Comment: When I built python 2.5 for linux I did the normal: configure make make install Everything went fine til the "make install" part. It dies with no error. just says "install failed" after this: Compiling /usr/local/lib/python2.5/zipfile.py That part built fine but the next part failed. So what I did being the industrious fellow that I am I did: make -n install > out Took the out file and did: sh out That installed python without failure. Now if I do "make install" everything works fine. Weird eh? -- >Comment By: SourceForge Robot (sf-robot) Date: 2007-03-12 19:20 Message: Logged In: YES user_id=1312539 Originator: NO This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). -- Comment By: Martin v. Löwis (loewis) Date: 2007-02-25 22:21 Message: Logged In: YES user_id=21627 Originator: NO Can you reproduce the problem on your system? Can you give instructions on how to reproduce it on another system? If not, I see little chance to resolve this problem. -- Comment By: larry (widgeteye) Date: 2007-02-25 22:11 Message: Logged In: YES user_id=402539 Originator: YES I think you missed the point I was trying to make. When I say "works fine" I mean that after I installed python using the shell script, then I could run "make install" and it would complete the install using make without failure. -- Comment By: larry (widgeteye) Date: 2007-02-25 22:10 Message: Logged In: YES user_id=402539 Originator: YES I think you missed the point I was trying to make. When I say "works fine" I mean that after I installed python using the shell script, then I could run "make install" and it would complete the install using make without failure. -- Comment By: Martin v. Löwis (loewis) Date: 2007-02-25 14:01 Message: Logged In: YES user_id=21627 Originator: NO I'm not finding it weird that the shell script completed. I doubt it "works fine", though. Instead, some command in it failed, but the shell doesn't abort in this case - make would abort. Typically, when byte-compilation fails, it is because you have a file byte-compiled that has a syntax error in it. Scroll through the entire compileall output to see what the actual problem is. Tentatively closing this as "won't fix". -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1667877&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1679498 ] Lib/io.py open uses unset "bs"
Bugs item #1679498, was opened at 2007-03-12 22:28 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=1679498&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 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jim Jewett (jimjjewett) Assigned to: Nobody/Anonymous (nobody) Summary: Lib/io.py open uses unset "bs" Initial Comment: Within the open function, it says """ try: bs = os.fstat(raw.fileno()).st_blksize except (os.error, AttributeError): if bs > 1: buffering = bs """ Since this is the first use of name "bs", I wouldn't expect it to have any value after an Exception. If this is actually correct, it at least deserves a comment. - (second issue) _PyFileIO sets self._writable but doesn't use it (even in writable()) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1679498&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1675511 ] Python still uses broken -xcode option on Solaris/x86
Bugs item #1675511, was opened at 2007-03-07 15:54 Message generated for change (Comment added) made by jlick You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1675511&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Closed Resolution: Accepted Priority: 5 Private: No Submitted By: Carson Gaspar (cgaspar) Assigned to: Nobody/Anonymous (nobody) Summary: Python still uses broken -xcode option on Solaris/x86 Initial Comment: Bug 1561333 was submitted against Python 2.4 with no action, so I'm submitting a new bug against 2.5 in the hopes that someone will read it... text updated with minor corrections. Python 2.5, Solaris x86 10 Update 3, Sun Studio 11 xcode=pic32 option is not supported on Solaris x86 Sun C . Python's ./configure script on Solaris systems sets the compiler flag -xcode=pic32 when any compiler other than gcc is used. Unfortunately, the -xcode flag is only available in the sparc version of Sun C. The x86 version of Sun C does not support the -xcode option at all and generates an error that an illegal option was used. The portable flag supported on both platforms to use independent 32-bit addressing is -KPIC. -- Comment By: James Lick (jlick) Date: 2007-03-13 11:32 Message: Logged In: YES user_id=673069 Originator: NO The patch I posted in the last comment also will apply (with warning) to Python 2.4.4 and builds OK. -- Comment By: Martin v. Löwis (loewis) Date: 2007-03-12 18:52 Message: Logged In: YES user_id=21627 Originator: NO Thanks for the patch. Committed as r54283 and r54284. -- Comment By: James Lick (jlick) Date: 2007-03-12 17:52 Message: Logged In: YES user_id=673069 Originator: NO The patch I posted in the last comment also will apply (with warning) to Python 2.4.4 and builds OK. -- Comment By: James Lick (jlick) Date: 2007-03-12 15:37 Message: Logged In: YES user_id=673069 Originator: NO I've made a patch for configure.in to fix this bug. There are two notes to explain why it was written the way it is: The first problem is to determine which processor type we are using. 'uname -p' was chosen because it returns the most generic response on both SPARC (sparc) and x86/x64 (i386) systems. There is some controversy about why it returns 'i386' even on Pentium or AMD64 systems, but Sun points to the isainfo, isalist, or psrinfo commands to get more specific processor information, so it appears they don't intend to change the behavior. The second choice is how to handle the default case if the result of the above is neither sparc or i386. I chose to use '-xcode=pic32' for sparc only, and '-Kpic' for all other responses. My reasoning is that since -Kpic existed before -xcode=pic32 was implemented that it is the more generic option, even though it and -KPIC are deprecated on sparc. I am therefore making the assumption that any possible new platforms supported by Studio 11 would in some fashion support -Kpic. This patch is a diff against Python 2.5's configure.in file. I've tested it against a Solaris 10 32-bit x86 system and a Solaris 10 64-bit sparc system both with Studio 11 installed. I don't have a 64-bit x86 system to test against. The build is mostly successful on both though there is a problem with the _ctypes module which causes test_ctypes to fail. This is a known problem covered by other bug reports which I believe is unrelated to this patch. I couldn't find the option to upload a file, so here is the patch inline: ---snip--- *** configure.in.old2007-03-11 23:01:16.879612000 -0700 --- configure.in2007-03-11 23:31:48.098734000 -0700 *** *** 1543,1551 then case $ac_sys_system/$ac_sys_release in SunOS*) if test "$GCC" = yes; ! then CCSHARED="-fPIC"; ! else CCSHARED="-xcode=pic32"; ! fi;; hp*|HP*) if test "$GCC" = yes; then CCSHARED="-fPIC"; else CCSHARED="+z"; --- 1543,1553 then case $ac_sys_system/$ac_sys_release in SunOS*) if test "$GCC" = yes; ! then CCSHARED="-fPIC"; ! elif test `uname -p` = sparc; ! then CCSHARED="-xcode=pic32"; ! else CCSHARED="-Kpic"; ! fi;; hp*|HP*) if test "$GCC" = yes; then CCSHARED="-fPIC"; else CCSHARED="+z"; ---snip--- -- Comment By: Martin v. Löwis (loewis) Date: 2007-03-11 03:06 Message: Logged In: YES
[ python-Bugs-1659171 ] Calling tparm from extension lib fails in Python 2.5
Bugs item #1659171, was opened at 2007-02-13 09:27 Message generated for change (Comment added) made by nnorwitz 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? -- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-03-12 21:53 Message: Logged In: YES user_id=33168 Originator: NO I can't help with the time factor, but I can with the access to svn. You can download a snapshot here: http://svn.python.org/snapshots/python25.tar.bz2 There are snapshots for the trunk as well as the active release branch. So if you can get a little free time, it would be great if you could download the tarball and test. Thanks. -- Comment By: Richard B. Kreckel (richyk) Date: 2007-03-12 04:30 Message: Logged In: YES user_id=1718463 Originator: YES Sorry, I cannot do that test anytime soon. (I've not enough time and my company doesn't let me access your SVN.) -- Comment By: Neal Norwitz (nnorwitz) Date: 2007-02-25 14:16 Message: Logged In: YES user_id=33168 Originator: NO Can you test with 2.5 from SVN and confirm your program works in the complete context? -- Comment By: Richard B. Kreckel (richyk) Date: 2007-02-22 04:25 Message: Logged In: YES user_id=1718463 Originator: YES The error message about the undefined init function is a red herring. The example is actually a stripped-down testcase from a much larger Boost.Python module, which of course does have an init function. The point here is the NULL pointer returned by tparm. -- Comment By: Martin v. Löwis (loewis) Date: 2007-02-14 13:24 Message: Logged In: YES user_id=21627 Originator: NO I fail to see the bug. The exception precisely describes the error in your code ImportError: dynamic module does not define init function (inittestlib) Why do you expect any meaningful behavior in the presence of this error? Your shared library isn't an extension module. If you think it is related to #1548092, please try out the subversion trunk, which has fixed this bug. -- Comment By: Richard B. Kreckel (richyk) Date: 2007-02-14 00:52 Message: Logged In: YES user_id=1718463 Originator: YES I suspect that this is a duplicate of Bug [1548092]. Note that, there it is asserted that tparm returns NULL on certain invalid strings. That does not seem to be true. It returns NULL for valid trivial strings, too. -- 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-1675511 ] Python still uses broken -xcode option on Solaris/x86
Bugs item #1675511, was opened at 2007-03-07 08:54 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1675511&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Closed Resolution: Accepted Priority: 5 Private: No Submitted By: Carson Gaspar (cgaspar) Assigned to: Nobody/Anonymous (nobody) Summary: Python still uses broken -xcode option on Solaris/x86 Initial Comment: Bug 1561333 was submitted against Python 2.4 with no action, so I'm submitting a new bug against 2.5 in the hopes that someone will read it... text updated with minor corrections. Python 2.5, Solaris x86 10 Update 3, Sun Studio 11 xcode=pic32 option is not supported on Solaris x86 Sun C . Python's ./configure script on Solaris systems sets the compiler flag -xcode=pic32 when any compiler other than gcc is used. Unfortunately, the -xcode flag is only available in the sparc version of Sun C. The x86 version of Sun C does not support the -xcode option at all and generates an error that an illegal option was used. The portable flag supported on both platforms to use independent 32-bit addressing is -KPIC. -- >Comment By: Martin v. Löwis (loewis) Date: 2007-03-13 06:34 Message: Logged In: YES user_id=21627 Originator: NO I won't apply the patch to the 2.4 branch, as that branch is not actively maintained anymore. -- Comment By: James Lick (jlick) Date: 2007-03-13 04:32 Message: Logged In: YES user_id=673069 Originator: NO The patch I posted in the last comment also will apply (with warning) to Python 2.4.4 and builds OK. -- Comment By: Martin v. Löwis (loewis) Date: 2007-03-12 11:52 Message: Logged In: YES user_id=21627 Originator: NO Thanks for the patch. Committed as r54283 and r54284. -- Comment By: James Lick (jlick) Date: 2007-03-12 10:52 Message: Logged In: YES user_id=673069 Originator: NO The patch I posted in the last comment also will apply (with warning) to Python 2.4.4 and builds OK. -- Comment By: James Lick (jlick) Date: 2007-03-12 08:37 Message: Logged In: YES user_id=673069 Originator: NO I've made a patch for configure.in to fix this bug. There are two notes to explain why it was written the way it is: The first problem is to determine which processor type we are using. 'uname -p' was chosen because it returns the most generic response on both SPARC (sparc) and x86/x64 (i386) systems. There is some controversy about why it returns 'i386' even on Pentium or AMD64 systems, but Sun points to the isainfo, isalist, or psrinfo commands to get more specific processor information, so it appears they don't intend to change the behavior. The second choice is how to handle the default case if the result of the above is neither sparc or i386. I chose to use '-xcode=pic32' for sparc only, and '-Kpic' for all other responses. My reasoning is that since -Kpic existed before -xcode=pic32 was implemented that it is the more generic option, even though it and -KPIC are deprecated on sparc. I am therefore making the assumption that any possible new platforms supported by Studio 11 would in some fashion support -Kpic. This patch is a diff against Python 2.5's configure.in file. I've tested it against a Solaris 10 32-bit x86 system and a Solaris 10 64-bit sparc system both with Studio 11 installed. I don't have a 64-bit x86 system to test against. The build is mostly successful on both though there is a problem with the _ctypes module which causes test_ctypes to fail. This is a known problem covered by other bug reports which I believe is unrelated to this patch. I couldn't find the option to upload a file, so here is the patch inline: ---snip--- *** configure.in.old2007-03-11 23:01:16.879612000 -0700 --- configure.in2007-03-11 23:31:48.098734000 -0700 *** *** 1543,1551 then case $ac_sys_system/$ac_sys_release in SunOS*) if test "$GCC" = yes; ! then CCSHARED="-fPIC"; ! else CCSHARED="-xcode=pic32"; ! fi;; hp*|HP*) if test "$GCC" = yes; then CCSHARED="-fPIC"; else CCSHARED="+z"; --- 1543,1553 then case $ac_sys_system/$ac_sys_release in SunOS*) if test "$GCC" = yes; ! then CCSHARED="-fPIC"; ! elif test `uname -p` = sparc; ! then CCSHARED="-xcode=pic32"; ! else CCSHARED="-Kpic"; ! fi;;
[ python-Bugs-1675511 ] Python still uses broken -xcode option on Solaris/x86
Bugs item #1675511, was opened at 2007-03-07 15:54 Message generated for change (Comment added) made by jlick You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1675511&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Closed Resolution: Accepted Priority: 5 Private: No Submitted By: Carson Gaspar (cgaspar) Assigned to: Nobody/Anonymous (nobody) Summary: Python still uses broken -xcode option on Solaris/x86 Initial Comment: Bug 1561333 was submitted against Python 2.4 with no action, so I'm submitting a new bug against 2.5 in the hopes that someone will read it... text updated with minor corrections. Python 2.5, Solaris x86 10 Update 3, Sun Studio 11 xcode=pic32 option is not supported on Solaris x86 Sun C . Python's ./configure script on Solaris systems sets the compiler flag -xcode=pic32 when any compiler other than gcc is used. Unfortunately, the -xcode flag is only available in the sparc version of Sun C. The x86 version of Sun C does not support the -xcode option at all and generates an error that an illegal option was used. The portable flag supported on both platforms to use independent 32-bit addressing is -KPIC. -- Comment By: James Lick (jlick) Date: 2007-03-13 13:55 Message: Logged In: YES user_id=673069 Originator: NO Sorry, not sure where the duplicate comment came from. That was just an FYI anyways. I'm fine with the fix only coming out in the 2.5 branch. -- Comment By: Martin v. Löwis (loewis) Date: 2007-03-13 13:34 Message: Logged In: YES user_id=21627 Originator: NO I won't apply the patch to the 2.4 branch, as that branch is not actively maintained anymore. -- Comment By: James Lick (jlick) Date: 2007-03-13 11:32 Message: Logged In: YES user_id=673069 Originator: NO The patch I posted in the last comment also will apply (with warning) to Python 2.4.4 and builds OK. -- Comment By: Martin v. Löwis (loewis) Date: 2007-03-12 18:52 Message: Logged In: YES user_id=21627 Originator: NO Thanks for the patch. Committed as r54283 and r54284. -- Comment By: James Lick (jlick) Date: 2007-03-12 17:52 Message: Logged In: YES user_id=673069 Originator: NO The patch I posted in the last comment also will apply (with warning) to Python 2.4.4 and builds OK. -- Comment By: James Lick (jlick) Date: 2007-03-12 15:37 Message: Logged In: YES user_id=673069 Originator: NO I've made a patch for configure.in to fix this bug. There are two notes to explain why it was written the way it is: The first problem is to determine which processor type we are using. 'uname -p' was chosen because it returns the most generic response on both SPARC (sparc) and x86/x64 (i386) systems. There is some controversy about why it returns 'i386' even on Pentium or AMD64 systems, but Sun points to the isainfo, isalist, or psrinfo commands to get more specific processor information, so it appears they don't intend to change the behavior. The second choice is how to handle the default case if the result of the above is neither sparc or i386. I chose to use '-xcode=pic32' for sparc only, and '-Kpic' for all other responses. My reasoning is that since -Kpic existed before -xcode=pic32 was implemented that it is the more generic option, even though it and -KPIC are deprecated on sparc. I am therefore making the assumption that any possible new platforms supported by Studio 11 would in some fashion support -Kpic. This patch is a diff against Python 2.5's configure.in file. I've tested it against a Solaris 10 32-bit x86 system and a Solaris 10 64-bit sparc system both with Studio 11 installed. I don't have a 64-bit x86 system to test against. The build is mostly successful on both though there is a problem with the _ctypes module which causes test_ctypes to fail. This is a known problem covered by other bug reports which I believe is unrelated to this patch. I couldn't find the option to upload a file, so here is the patch inline: ---snip--- *** configure.in.old2007-03-11 23:01:16.879612000 -0700 --- configure.in2007-03-11 23:31:48.098734000 -0700 *** *** 1543,1551 then case $ac_sys_system/$ac_sys_release in SunOS*) if test "$GCC" = yes; ! then CCSHARED="-fPIC"; ! else CCSHARED="-xcode=pic32"; ! fi;; hp*|HP*) if test "$GCC" = yes; then CCSHARED="-fPIC";
[ python-Bugs-1630844 ] fnmatch.translate undocumented
Bugs item #1630844, was opened at 2007-01-08 19:29 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1630844&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: Gabriel Genellina (gagenellina) Assigned to: Nobody/Anonymous (nobody) Summary: fnmatch.translate undocumented Initial Comment: fnmatch.translate is not documented, but it is menctioned on the module docstring and in __all__, so it appears to be public. -- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-13 07:52 Message: Logged In: YES user_id=849994 Originator: NO The patch has been applied, so closing this. Thanks for the report! -- Comment By: Bj�rn Lindqvist (sonderblade) Date: 2007-03-12 22:46 Message: Logged In: YES user_id=51702 Originator: NO Patch #1679379 should fix it. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1630844&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
