[ python-Bugs-1528802 ] Turkish Character
Bugs item #1528802, was opened at 2006-07-26 10:05
Message generated for change (Comment added) made by ahmetbiskinler
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1528802&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: Python 2.5
Status: Open
Resolution: None
>Priority: 7
Submitted By: Ahmet Bişkinler (ahmetbiskinler)
Assigned to: M.-A. Lemburg (lemburg)
Summary: Turkish Character
Initial Comment:
>>> print "Mayıs".upper()
>>> MAYıS
>>> import locale
>>> locale.setlocale(locale.LC_ALL,'Turkish_Turkey.1254')
>>> print "Mayıs".upper()
>>> MAYıS
>>> print "ğüşiöçı".upper()
>>> ğüşIöçı
MAYıS should be MAYIS
ğüşIöçı should be ĞÜŞİÖÇI
but
>>> "Mayıs".upper()
>>> "MAYIS"
is right
--
>Comment By: Ahmet Bişkinler (ahmetbiskinler)
Date: 2006-08-21 10:55
Message:
Logged In: YES
user_id=1481281
There are still some problems with it. As in the image.
http://img205.imageshack.us/img205/3998/turkishcharpythonyu5.jpg
The upper() works fine(except ı and i uppercase) with IDLE
since upper() doesn't even work.
Another problem is with the ı(dotless) and i(dotted) 's upper.
ı(dotless) should be I (dotless)
i(dotted) should be İ (dotted)
ı = I
i = İ
For more information:
http://www.i18nguy.com/unicode/turkish-i18n.html
--
Comment By: Santiago Gala (sgala)
Date: 2006-08-18 17:37
Message:
Logged In: YES
user_id=178886
Done: Bug #1542677
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-08-17 22:08
Message:
Logged In: YES
user_id=849994
Please submit that as a separate IDLE bug.
--
Comment By: Santiago Gala (sgala)
Date: 2006-08-17 21:58
Message:
Logged In: YES
user_id=178886
Idle from 2.5rc1 (svn today) produces a different result
than console (with my default, utf-8, encoding):
IDLE 1.2c1
>>> print "á"
á
>>> print len("á")
2
>>> print "á".upper()
á
>>> str("á")
'\xc3\xa1'
>>> print u"á"
á
>>> print len(u"á")
2
>>> print u"á".upper()
á
>>> str(u"á")
Traceback (most recent call last):
File "", line 1, in
str(u"á")
UnicodeEncodeError: 'ascii' codec can't encode characters in
position 0-1: ordinal not in range(128)
Again, IDLE 1.1.3 (python 2.4.3) produces a different result:
IDLE 1.1.3
>>> print "á"
á
>>> print len("á")
2
>>> print "á".upper()
á
>>> str("á")
'\xc3\xa1'
>>> print u"á"
á
>>> print len(u"á")
2
>>> print u"á".upper()
á
>>> str(u"á")
'\xc3\x83\xc2\xa1'
>>>
I'd say idle is broken, as it is not able to respect utf-8
for print (or even len) of unicode strings.
OTOH, with some tricks I can manage to get an accented a in
a unicode in idle:
>>> import unicodedata
>>> print unicodedata.lookup("LATIN SMALL LETTER A WITH ACUTE")
á
>>> print len(unicodedata.lookup("LATIN SMALL LETTER A WITH
ACUTE"))
1
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-08-17 18:08
Message:
Logged In: YES
user_id=849994
Using Unicode strings, the OP's example works.
--
Comment By: M.-A. Lemburg (lemburg)
Date: 2006-08-17 18:04
Message:
Logged In: YES
user_id=38388
String upper and lower conversion are locale dependent and
implemented by the underlying libc, whereas Unicode
upper/lower conversion is not and only depends on the
Unicode character database.
OTOH, there are special cases where the standard Unicode
upper/lower mapping is no what you might expect, since the
database only provides a single mapping and is not context
aware.
There's nothing we can do if the libc is broken in some
respect. As for the extended case mapping support in
Unicode: patches are welcome.
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-08-17 18:03
Message:
Logged In: YES
user_id=849994
sgala: it looks like your console sends UTF-8 encoded text.
>>> print "á"
á
print is just printing out a byte string consisting of two
bytes, which your console displays as accent-a.
>>> print len("á")
2
A UTF-8-encoded string containing an accented a has two bytes.
>>> print "á".upper()
á
str.upper() doesn't take locale into account, so the
accented a has no uppercase version defined.
>>> str("á")
'\xc3\xa1'
str() applied to a byte string returns that byte string.
Since return values from functions are printed by the
interactive interpreter using repr() first, you get this
representation (which you could also get from "print
repr('a')".)
>>> print u"á"
á
That's also okay. Python knows the terminal encoding and
properly tr
[ python-Bugs-1543469 ] test_subprocess fails on cygwin
Bugs item #1543469, was opened at 2006-08-20 06:22 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1543469&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: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Miki Tebeka (tebeka) Assigned to: Nobody/Anonymous (nobody) Summary: test_subprocess fails on cygwin Initial Comment: This is RC1. test_subprocess fails. IMO due to the fact that there is a directory called "Python" in the python source directory. The fix should be that sys.executable will return the name with the '.exe' suffix on cygwin. Attached log of running the test. -- >Comment By: Nobody/Anonymous (nobody) Date: 2006-08-21 01:07 Message: Logged In: NO Attached a patch, test_subprocess now passes. -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-20 19:15 Message: Logged In: YES user_id=33168 Cygwin recently changed their behaviour. I have an outstanding hack to fix this. Patches would help get things fixed up. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1543469&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1543801 ] md5 sums are different between Solaris and Windows XP SP1
Bugs item #1543801, was opened at 2006-08-21 10:21
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=1543801&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.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Stefan Sonnenberg (sunmountain)
Assigned to: Nobody/Anonymous (nobody)
Summary: md5 sums are different between Solaris and Windows XP SP1
Initial Comment:
The following program produces
different md5 sums under Solaris and Windows XP,
but sums are equal under the same platform.
#!/opt/ASpy23/bin/python
import sys
import md5
import getopt
import os
import re
try:
opts,args = getopt.getopt(sys.argv[1:],'c:f:h')
except getopt.GetoptError,e:
print 'Parsing command line arguments failed. (%s)'
% str(e)
sys.exit(1)
md5file = None
fname = None
for o,a in opts:
if o in '-c':
if fname is not None:
print '-c and -f are mutually exclusive'
sys.exit(1)
md5file = a
if o in '-f':
if md5file is not None:
print '-c and -f are mutually exclusive'
sys.exit(1)
fname = a
if o in '-h':
print 'Usage: md5 filename. (%s)' % str(e)
sys.exit(1)
if md5file is not None and os.path.isfile(md5file):
try:
lines = open(md5file,'r').readlines()
except IOError,e:
print 'Could not read MD5 sum file %s. (%s)' %
(md5file,str(e))
sys.exit(1)
for line in lines:
line = line[:-1]
try:
res = re.compile('MD5[ |\t]+\((.+)\)[
|\t]+?\=[ |\t]+(.+)').findall(line)[0]
except Exception,e:
print 'Could not parse line. (%s)' % str(e)
sys.exit(1)
if os.path.isfile(res[0]):
try:
f = open(res[0],'r')
except IOError,e:
print 'Could not open file %s. (%s)' %
(res[0],str(e))
sys.exit(1)
sum = md5.new()
try:
sum.update(f.read())
except Exception,e:
print 'Could not update MD5 sum. (%s)'
% str(e)
sys.exit(1)
#print sum.hexdigest(),res[1][2:],res[0],line
if sum.hexdigest() == res[1][2:]:
print 'MD5 sum of file %s is OK' % res[0]
else:
print 'MD5 sum of file %s DIFFERS' % res[0]
f.close()
sum = None
sys.exit(0)
sum = md5.new()
try:
f = open(fname,'r')
except IOError,e:
print 'Could not open %s. (%s)' % ( fname,str(e) )
try:
sum.update(f.read())
except Exception,e:
print 'Could not update md5 sum. (%s)' % str(e)
print 'MD5 (%s) = 0x%s' % (fname,sum.hexdigest())
f.close()
Python version Solaris:
Python 2.3.5 (#1, Feb 9 2005, 14:45:39) [C] on sunos5
Python version Windows XP:
Python 2.3.5 (#62, Feb 9 2005, 16:17:08) [MSC v.1200
32 bit (Intel)] on win32
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1543801&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1543801 ] md5 sums are different between Solaris and Windows XP SP1
Bugs item #1543801, was opened at 2006-08-21 08:21
Message generated for change (Comment added) made by gbrandl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1543801&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.3
>Status: Pending
Resolution: None
Priority: 5
Submitted By: Stefan Sonnenberg (sunmountain)
Assigned to: Nobody/Anonymous (nobody)
Summary: md5 sums are different between Solaris and Windows XP SP1
Initial Comment:
The following program produces
different md5 sums under Solaris and Windows XP,
but sums are equal under the same platform.
#!/opt/ASpy23/bin/python
import sys
import md5
import getopt
import os
import re
try:
opts,args = getopt.getopt(sys.argv[1:],'c:f:h')
except getopt.GetoptError,e:
print 'Parsing command line arguments failed. (%s)'
% str(e)
sys.exit(1)
md5file = None
fname = None
for o,a in opts:
if o in '-c':
if fname is not None:
print '-c and -f are mutually exclusive'
sys.exit(1)
md5file = a
if o in '-f':
if md5file is not None:
print '-c and -f are mutually exclusive'
sys.exit(1)
fname = a
if o in '-h':
print 'Usage: md5 filename. (%s)' % str(e)
sys.exit(1)
if md5file is not None and os.path.isfile(md5file):
try:
lines = open(md5file,'r').readlines()
except IOError,e:
print 'Could not read MD5 sum file %s. (%s)' %
(md5file,str(e))
sys.exit(1)
for line in lines:
line = line[:-1]
try:
res = re.compile('MD5[ |\t]+\((.+)\)[
|\t]+?\=[ |\t]+(.+)').findall(line)[0]
except Exception,e:
print 'Could not parse line. (%s)' % str(e)
sys.exit(1)
if os.path.isfile(res[0]):
try:
f = open(res[0],'r')
except IOError,e:
print 'Could not open file %s. (%s)' %
(res[0],str(e))
sys.exit(1)
sum = md5.new()
try:
sum.update(f.read())
except Exception,e:
print 'Could not update MD5 sum. (%s)'
% str(e)
sys.exit(1)
#print sum.hexdigest(),res[1][2:],res[0],line
if sum.hexdigest() == res[1][2:]:
print 'MD5 sum of file %s is OK' % res[0]
else:
print 'MD5 sum of file %s DIFFERS' % res[0]
f.close()
sum = None
sys.exit(0)
sum = md5.new()
try:
f = open(fname,'r')
except IOError,e:
print 'Could not open %s. (%s)' % ( fname,str(e) )
try:
sum.update(f.read())
except Exception,e:
print 'Could not update md5 sum. (%s)' % str(e)
print 'MD5 (%s) = 0x%s' % (fname,sum.hexdigest())
f.close()
Python version Solaris:
Python 2.3.5 (#1, Feb 9 2005, 14:45:39) [C] on sunos5
Python version Windows XP:
Python 2.3.5 (#62, Feb 9 2005, 16:17:08) [MSC v.1200
32 bit (Intel)] on win32
--
>Comment By: Georg Brandl (gbrandl)
Date: 2006-08-21 09:06
Message:
Logged In: YES
user_id=849994
You're opening files in text mode, which is likely to return
different file contents on Windows and Unix.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1543801&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1543801 ] md5 sums are different between Solaris and Windows XP SP1
Bugs item #1543801, was opened at 2006-08-21 10:21
Message generated for change (Comment added) made by sunmountain
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1543801&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.3
>Status: Open
Resolution: None
Priority: 5
Submitted By: Stefan Sonnenberg (sunmountain)
Assigned to: Nobody/Anonymous (nobody)
Summary: md5 sums are different between Solaris and Windows XP SP1
Initial Comment:
The following program produces
different md5 sums under Solaris and Windows XP,
but sums are equal under the same platform.
#!/opt/ASpy23/bin/python
import sys
import md5
import getopt
import os
import re
try:
opts,args = getopt.getopt(sys.argv[1:],'c:f:h')
except getopt.GetoptError,e:
print 'Parsing command line arguments failed. (%s)'
% str(e)
sys.exit(1)
md5file = None
fname = None
for o,a in opts:
if o in '-c':
if fname is not None:
print '-c and -f are mutually exclusive'
sys.exit(1)
md5file = a
if o in '-f':
if md5file is not None:
print '-c and -f are mutually exclusive'
sys.exit(1)
fname = a
if o in '-h':
print 'Usage: md5 filename. (%s)' % str(e)
sys.exit(1)
if md5file is not None and os.path.isfile(md5file):
try:
lines = open(md5file,'r').readlines()
except IOError,e:
print 'Could not read MD5 sum file %s. (%s)' %
(md5file,str(e))
sys.exit(1)
for line in lines:
line = line[:-1]
try:
res = re.compile('MD5[ |\t]+\((.+)\)[
|\t]+?\=[ |\t]+(.+)').findall(line)[0]
except Exception,e:
print 'Could not parse line. (%s)' % str(e)
sys.exit(1)
if os.path.isfile(res[0]):
try:
f = open(res[0],'r')
except IOError,e:
print 'Could not open file %s. (%s)' %
(res[0],str(e))
sys.exit(1)
sum = md5.new()
try:
sum.update(f.read())
except Exception,e:
print 'Could not update MD5 sum. (%s)'
% str(e)
sys.exit(1)
#print sum.hexdigest(),res[1][2:],res[0],line
if sum.hexdigest() == res[1][2:]:
print 'MD5 sum of file %s is OK' % res[0]
else:
print 'MD5 sum of file %s DIFFERS' % res[0]
f.close()
sum = None
sys.exit(0)
sum = md5.new()
try:
f = open(fname,'r')
except IOError,e:
print 'Could not open %s. (%s)' % ( fname,str(e) )
try:
sum.update(f.read())
except Exception,e:
print 'Could not update md5 sum. (%s)' % str(e)
print 'MD5 (%s) = 0x%s' % (fname,sum.hexdigest())
f.close()
Python version Solaris:
Python 2.3.5 (#1, Feb 9 2005, 14:45:39) [C] on sunos5
Python version Windows XP:
Python 2.3.5 (#62, Feb 9 2005, 16:17:08) [MSC v.1200
32 bit (Intel)] on win32
--
>Comment By: Stefan Sonnenberg (sunmountain)
Date: 2006-08-21 11:06
Message:
Logged In: YES
user_id=1575341
I double checked the behaviour.
With Python the md5 sums differ between Solaris and Windows.
Using external tools for generating md5 sums, these are
always equal, under both systems, as it should be with md5.
I did not try other python versions.
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-08-21 11:06
Message:
Logged In: YES
user_id=849994
You're opening files in text mode, which is likely to return
different file contents on Windows and Unix.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1543801&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1543801 ] md5 sums are different between Solaris and Windows XP SP1
Bugs item #1543801, was opened at 2006-08-21 08:21
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1543801&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.3
>Status: Pending
Resolution: None
Priority: 5
Submitted By: Stefan Sonnenberg (sunmountain)
Assigned to: Nobody/Anonymous (nobody)
Summary: md5 sums are different between Solaris and Windows XP SP1
Initial Comment:
The following program produces
different md5 sums under Solaris and Windows XP,
but sums are equal under the same platform.
#!/opt/ASpy23/bin/python
import sys
import md5
import getopt
import os
import re
try:
opts,args = getopt.getopt(sys.argv[1:],'c:f:h')
except getopt.GetoptError,e:
print 'Parsing command line arguments failed. (%s)'
% str(e)
sys.exit(1)
md5file = None
fname = None
for o,a in opts:
if o in '-c':
if fname is not None:
print '-c and -f are mutually exclusive'
sys.exit(1)
md5file = a
if o in '-f':
if md5file is not None:
print '-c and -f are mutually exclusive'
sys.exit(1)
fname = a
if o in '-h':
print 'Usage: md5 filename. (%s)' % str(e)
sys.exit(1)
if md5file is not None and os.path.isfile(md5file):
try:
lines = open(md5file,'r').readlines()
except IOError,e:
print 'Could not read MD5 sum file %s. (%s)' %
(md5file,str(e))
sys.exit(1)
for line in lines:
line = line[:-1]
try:
res = re.compile('MD5[ |\t]+\((.+)\)[
|\t]+?\=[ |\t]+(.+)').findall(line)[0]
except Exception,e:
print 'Could not parse line. (%s)' % str(e)
sys.exit(1)
if os.path.isfile(res[0]):
try:
f = open(res[0],'r')
except IOError,e:
print 'Could not open file %s. (%s)' %
(res[0],str(e))
sys.exit(1)
sum = md5.new()
try:
sum.update(f.read())
except Exception,e:
print 'Could not update MD5 sum. (%s)'
% str(e)
sys.exit(1)
#print sum.hexdigest(),res[1][2:],res[0],line
if sum.hexdigest() == res[1][2:]:
print 'MD5 sum of file %s is OK' % res[0]
else:
print 'MD5 sum of file %s DIFFERS' % res[0]
f.close()
sum = None
sys.exit(0)
sum = md5.new()
try:
f = open(fname,'r')
except IOError,e:
print 'Could not open %s. (%s)' % ( fname,str(e) )
try:
sum.update(f.read())
except Exception,e:
print 'Could not update md5 sum. (%s)' % str(e)
print 'MD5 (%s) = 0x%s' % (fname,sum.hexdigest())
f.close()
Python version Solaris:
Python 2.3.5 (#1, Feb 9 2005, 14:45:39) [C] on sunos5
Python version Windows XP:
Python 2.3.5 (#62, Feb 9 2005, 16:17:08) [MSC v.1200
32 bit (Intel)] on win32
--
Comment By: Stefan Sonnenberg (sunmountain)
Date: 2006-08-21 09:06
Message:
Logged In: YES
user_id=1575341
I double checked the behaviour.
With Python the md5 sums differ between Solaris and Windows.
Using external tools for generating md5 sums, these are
always equal, under both systems, as it should be with md5.
I did not try other python versions.
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-08-21 09:06
Message:
Logged In: YES
user_id=849994
You're opening files in text mode, which is likely to return
different file contents on Windows and Unix.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1543801&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1543801 ] md5 sums are different between Solaris and Windows XP SP1
Bugs item #1543801, was opened at 2006-08-21 10:21
Message generated for change (Settings changed) made by sunmountain
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1543801&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.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Stefan Sonnenberg (sunmountain)
Assigned to: Nobody/Anonymous (nobody)
Summary: md5 sums are different between Solaris and Windows XP SP1
Initial Comment:
The following program produces
different md5 sums under Solaris and Windows XP,
but sums are equal under the same platform.
#!/opt/ASpy23/bin/python
import sys
import md5
import getopt
import os
import re
try:
opts,args = getopt.getopt(sys.argv[1:],'c:f:h')
except getopt.GetoptError,e:
print 'Parsing command line arguments failed. (%s)'
% str(e)
sys.exit(1)
md5file = None
fname = None
for o,a in opts:
if o in '-c':
if fname is not None:
print '-c and -f are mutually exclusive'
sys.exit(1)
md5file = a
if o in '-f':
if md5file is not None:
print '-c and -f are mutually exclusive'
sys.exit(1)
fname = a
if o in '-h':
print 'Usage: md5 filename. (%s)' % str(e)
sys.exit(1)
if md5file is not None and os.path.isfile(md5file):
try:
lines = open(md5file,'r').readlines()
except IOError,e:
print 'Could not read MD5 sum file %s. (%s)' %
(md5file,str(e))
sys.exit(1)
for line in lines:
line = line[:-1]
try:
res = re.compile('MD5[ |\t]+\((.+)\)[
|\t]+?\=[ |\t]+(.+)').findall(line)[0]
except Exception,e:
print 'Could not parse line. (%s)' % str(e)
sys.exit(1)
if os.path.isfile(res[0]):
try:
f = open(res[0],'r')
except IOError,e:
print 'Could not open file %s. (%s)' %
(res[0],str(e))
sys.exit(1)
sum = md5.new()
try:
sum.update(f.read())
except Exception,e:
print 'Could not update MD5 sum. (%s)'
% str(e)
sys.exit(1)
#print sum.hexdigest(),res[1][2:],res[0],line
if sum.hexdigest() == res[1][2:]:
print 'MD5 sum of file %s is OK' % res[0]
else:
print 'MD5 sum of file %s DIFFERS' % res[0]
f.close()
sum = None
sys.exit(0)
sum = md5.new()
try:
f = open(fname,'r')
except IOError,e:
print 'Could not open %s. (%s)' % ( fname,str(e) )
try:
sum.update(f.read())
except Exception,e:
print 'Could not update md5 sum. (%s)' % str(e)
print 'MD5 (%s) = 0x%s' % (fname,sum.hexdigest())
f.close()
Python version Solaris:
Python 2.3.5 (#1, Feb 9 2005, 14:45:39) [C] on sunos5
Python version Windows XP:
Python 2.3.5 (#62, Feb 9 2005, 16:17:08) [MSC v.1200
32 bit (Intel)] on win32
--
Comment By: Stefan Sonnenberg (sunmountain)
Date: 2006-08-21 11:06
Message:
Logged In: YES
user_id=1575341
I double checked the behaviour.
With Python the md5 sums differ between Solaris and Windows.
Using external tools for generating md5 sums, these are
always equal, under both systems, as it should be with md5.
I did not try other python versions.
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-08-21 11:06
Message:
Logged In: YES
user_id=849994
You're opening files in text mode, which is likely to return
different file contents on Windows and Unix.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1543801&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1528802 ] Turkish Character
Bugs item #1528802, was opened at 2006-07-26 09:05
Message generated for change (Comment added) made by lemburg
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1528802&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: Python 2.5
Status: Open
Resolution: None
>Priority: 5
Submitted By: Ahmet Bişkinler (ahmetbiskinler)
Assigned to: M.-A. Lemburg (lemburg)
Summary: Turkish Character
Initial Comment:
>>> print "Mayıs".upper()
>>> MAYıS
>>> import locale
>>> locale.setlocale(locale.LC_ALL,'Turkish_Turkey.1254')
>>> print "Mayıs".upper()
>>> MAYıS
>>> print "ğüşiöçı".upper()
>>> ğüşIöçı
MAYıS should be MAYIS
ğüşIöçı should be ĞÜŞİÖÇI
but
>>> "Mayıs".upper()
>>> "MAYIS"
is right
--
>Comment By: M.-A. Lemburg (lemburg)
Date: 2006-08-21 12:01
Message:
Logged In: YES
user_id=38388
Could we please get some things straight first:
1. if you're working with IDLE and it doesn't do what you
expect it to, please file an IDLE bug report, not a Python
one; the same it true for any other Python IDE you are using
2. string's .lower() and .upper() method rely 100% on the
platform's C lib implementation of these functions; there's
nothing Python can do about bugs in these implementations
3. if you want reproducable behavior across platforms,
please always use Unicode, *not* 8-bit strings, for text data.
I see that #1 has already been done, so the IDLE specific
discussion should continue there.
#2 is the cause of the problem, then all we can do is point
you to #3.
If #3 fails for some reason, then we should investigate
this. However, be aware that the Unicode database has a
fixed set of case mappings and we currently don't support
extended case mapping which is locale and context sensitive.
Again, patches are welcome.
Please provide your examples using the repr() of the string
or Unicode objects in question. This makes it a lot easier
to test your examples on other platforms.
Thanks.
--
Comment By: Ahmet Bişkinler (ahmetbiskinler)
Date: 2006-08-21 09:55
Message:
Logged In: YES
user_id=1481281
There are still some problems with it. As in the image.
http://img205.imageshack.us/img205/3998/turkishcharpythonyu5.jpg
The upper() works fine(except ı and i uppercase) with IDLE
since upper() doesn't even work.
Another problem is with the ı(dotless) and i(dotted) 's upper.
ı(dotless) should be I (dotless)
i(dotted) should be İ (dotted)
ı = I
i = İ
For more information:
http://www.i18nguy.com/unicode/turkish-i18n.html
--
Comment By: Santiago Gala (sgala)
Date: 2006-08-18 16:37
Message:
Logged In: YES
user_id=178886
Done: Bug #1542677
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-08-17 21:08
Message:
Logged In: YES
user_id=849994
Please submit that as a separate IDLE bug.
--
Comment By: Santiago Gala (sgala)
Date: 2006-08-17 20:58
Message:
Logged In: YES
user_id=178886
Idle from 2.5rc1 (svn today) produces a different result
than console (with my default, utf-8, encoding):
IDLE 1.2c1
>>> print "á"
á
>>> print len("á")
2
>>> print "á".upper()
á
>>> str("á")
'\xc3\xa1'
>>> print u"á"
á
>>> print len(u"á")
2
>>> print u"á".upper()
á
>>> str(u"á")
Traceback (most recent call last):
File "", line 1, in
str(u"á")
UnicodeEncodeError: 'ascii' codec can't encode characters in
position 0-1: ordinal not in range(128)
Again, IDLE 1.1.3 (python 2.4.3) produces a different result:
IDLE 1.1.3
>>> print "á"
á
>>> print len("á")
2
>>> print "á".upper()
á
>>> str("á")
'\xc3\xa1'
>>> print u"á"
á
>>> print len(u"á")
2
>>> print u"á".upper()
á
>>> str(u"á")
'\xc3\x83\xc2\xa1'
>>>
I'd say idle is broken, as it is not able to respect utf-8
for print (or even len) of unicode strings.
OTOH, with some tricks I can manage to get an accented a in
a unicode in idle:
>>> import unicodedata
>>> print unicodedata.lookup("LATIN SMALL LETTER A WITH ACUTE")
á
>>> print len(unicodedata.lookup("LATIN SMALL LETTER A WITH
ACUTE"))
1
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-08-17 17:08
Message:
Logged In: YES
user_id=849994
Using Unicode strings, the OP's example works.
--
Comment By: M.-A. Lemburg (lemburg)
Date: 2006-08-17 17:04
Message:
Logged In: YES
user_id=38388
String upper and lower conversion are locale dependent and
implemented by the underlying libc, whereas Unicode
upper/lower conversion is not and onl
[ python-Bugs-1543303 ] tarfile in mode w|gz adds padding that annoys gunzip
Bugs item #1543303, was opened at 2006-08-20 03:48 Message generated for change (Comment added) made by gustaebel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1543303&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: 8 Submitted By: alexis (asak) Assigned to: Neal Norwitz (nnorwitz) Summary: tarfile in mode w|gz adds padding that annoys gunzip Initial Comment: In mode w|gz tarfile pads the final block with NULs, until its size reaches the bufsize value passed to tarfile.open. This makes gunzip complain about "invalid compressed data" because of CRC and length errors. To reproduce it, put this fragment in a file archive.py import sys import tarfile tar = tarfile.open(mode='w|gz', fileobj=sys.stdout) tar.close() and then: $ python2.5 archive.py | gunzip -c gunzip: stdin: invalid compressed data--crc error gunzip: stdin: invalid compressed data--length error Everything works fine with python 2.3.5 and 2.4.1 on Debian sarge. The padding is added by the following lines in _Stream.close: blocks, remainder = divmod(len(self.buf), self.bufsize) if remainder > 0: self.buf += NUL * (self.bufsize - remainder) They were added in revision 38581, but I'm not sure why - at first sight, "Add tarfile open mode r|*" shouldn't have to change this write path. Removing them makes gunzip happy again, but I have no idea if it breaks something else (test_tarfile doesn't complain). A similar problem happens if you use mode w|bz2 and feed the output to bunzip - it complains about "trailing garbage after EOF ignored". Problems found while running the test suite from the Mercurial SCM. -- Comment By: Lars Gust�bel (gustaebel) Date: 2006-08-21 14:08 Message: Logged In: YES user_id=642936 I just created patch #1543897 that removes the 3 lines of code and adds a test to test_tarfile.py. Thank you for the detailed report. -- Comment By: Georg Brandl (gbrandl) Date: 2006-08-20 16:17 Message: Logged In: YES user_id=849994 This should be resolved before 2.5 final. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1543303&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1544102 ] ctypes unit test fails (test_macholib.py) under MacOS 10.4.7
Bugs item #1544102, was opened at 2006-08-21 13:59
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=1544102&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: Macintosh
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: M. J. Fromberger (njdibfm)
Assigned to: Jack Jansen (jackjansen)
Summary: ctypes unit test fails (test_macholib.py) under MacOS 10.4.7
Initial Comment:
While building 2.5rc1 under MacOS 10.4.7, one of the ctypes module
unit tests fails:
% ./python.exe -V
Python 2.5c1 (r25c1:51426, Aug 21 2006, 11:30:05)
[GCC 4.0.1 (Apple Computer, Inc. build 5341)] on darwin
% uname -a
Darwin chrysophylax 8.7.0 Darwin Kernel Version 8.7.0: Fri May 26
15:20:53 PDT 2006; root:xnu-792.6.76.obj~1/RELEASE_PPC Power
Macintosh powerpc
Output report:
===
===
FAIL: test_find (ctypes.test.test_macholib.MachOTest)
--
Traceback (most recent call last):
File "/usr/local/src/python2.5/Lib/ctypes/test/test_macholib.py", line
55, in test_find
self.failUnless(result.startswith('/usr/lib/libz.1'))
AssertionError
--
Ran 287 tests in 0.933s
FAILED (failures=1)
Traceback (most recent call last):
File "Lib/test/test_ctypes.py", line 12, in
test_main()
File "Lib/test/test_ctypes.py", line 9, in test_main
run_suite(unittest.TestSuite(suites))
File "/usr/local/src/python2.5/Lib/test/test_support.py", line 426, in
run_suite
raise TestFailed(err)
test.test_support.TestFailed: Traceback (most recent call last):
File "/usr/local/src/python2.5/Lib/ctypes/test/test_macholib.py", line
55, in test_find
self.failUnless(result.startswith('/usr/lib/libz.1'))
AssertionError
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1544102&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1544106 ] test_anydbm segmentation fault
Bugs item #1544106, was opened at 2006-08-21 14:02 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=1544106&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: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Clay Spence (cspence) Assigned to: Nobody/Anonymous (nobody) Summary: test_anydbm segmentation fault Initial Comment: After building 2.5rc1 and bfore installing, make test failed for me at test_anydbm: cholla 88% uname -a Linux cholla.sarnoff.com 2.6.9-34.ELsmp #1 SMP Fri Feb 24 16:54:53 EST 2006 i686 i686 i386 GNU/Linux cholla 89% ./python Python 2.5c1 (r25c1:51305, Aug 21 2006, 11:30:37) [GCC 3.4.5 20051201 (Red Hat 3.4.5-2)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> cholla 90% ./python ./Lib/test/test_anydbm.py Segmentation fault cholla 91% I tracked this to Lib/bsddb/__init__.py, line 355, in _openDBEnv(): e.set_lk_detect(db.DB_LOCK_DEFAULT) See the attached pdb text output, if it's useful. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1544106&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1543303 ] tarfile in mode w|gz adds padding that annoys gunzip
Bugs item #1543303, was opened at 2006-08-19 18:48 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1543303&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 8 Submitted By: alexis (asak) Assigned to: Neal Norwitz (nnorwitz) Summary: tarfile in mode w|gz adds padding that annoys gunzip Initial Comment: In mode w|gz tarfile pads the final block with NULs, until its size reaches the bufsize value passed to tarfile.open. This makes gunzip complain about "invalid compressed data" because of CRC and length errors. To reproduce it, put this fragment in a file archive.py import sys import tarfile tar = tarfile.open(mode='w|gz', fileobj=sys.stdout) tar.close() and then: $ python2.5 archive.py | gunzip -c gunzip: stdin: invalid compressed data--crc error gunzip: stdin: invalid compressed data--length error Everything works fine with python 2.3.5 and 2.4.1 on Debian sarge. The padding is added by the following lines in _Stream.close: blocks, remainder = divmod(len(self.buf), self.bufsize) if remainder > 0: self.buf += NUL * (self.bufsize - remainder) They were added in revision 38581, but I'm not sure why - at first sight, "Add tarfile open mode r|*" shouldn't have to change this write path. Removing them makes gunzip happy again, but I have no idea if it breaks something else (test_tarfile doesn't complain). A similar problem happens if you use mode w|bz2 and feed the output to bunzip - it complains about "trailing garbage after EOF ignored". Problems found while running the test suite from the Mercurial SCM. -- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-21 11:49 Message: Logged In: YES user_id=33168 Committed revision 51432. (2.6) 51436 (2.5) -- Comment By: Lars Gust�bel (gustaebel) Date: 2006-08-21 05:08 Message: Logged In: YES user_id=642936 I just created patch #1543897 that removes the 3 lines of code and adds a test to test_tarfile.py. Thank you for the detailed report. -- Comment By: Georg Brandl (gbrandl) Date: 2006-08-20 07:17 Message: Logged In: YES user_id=849994 This should be resolved before 2.5 final. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1543303&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1544102 ] ctypes unit test fails (test_macholib.py) under MacOS 10.4.7
Bugs item #1544102, was opened at 2006-08-21 19:59
Message generated for change (Settings changed) made by jackjansen
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1544102&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: Macintosh
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: M. J. Fromberger (njdibfm)
>Assigned to: Ronald Oussoren (ronaldoussoren)
Summary: ctypes unit test fails (test_macholib.py) under MacOS 10.4.7
Initial Comment:
While building 2.5rc1 under MacOS 10.4.7, one of the ctypes module
unit tests fails:
% ./python.exe -V
Python 2.5c1 (r25c1:51426, Aug 21 2006, 11:30:05)
[GCC 4.0.1 (Apple Computer, Inc. build 5341)] on darwin
% uname -a
Darwin chrysophylax 8.7.0 Darwin Kernel Version 8.7.0: Fri May 26
15:20:53 PDT 2006; root:xnu-792.6.76.obj~1/RELEASE_PPC Power
Macintosh powerpc
Output report:
===
===
FAIL: test_find (ctypes.test.test_macholib.MachOTest)
--
Traceback (most recent call last):
File "/usr/local/src/python2.5/Lib/ctypes/test/test_macholib.py", line
55, in test_find
self.failUnless(result.startswith('/usr/lib/libz.1'))
AssertionError
--
Ran 287 tests in 0.933s
FAILED (failures=1)
Traceback (most recent call last):
File "Lib/test/test_ctypes.py", line 12, in
test_main()
File "Lib/test/test_ctypes.py", line 9, in test_main
run_suite(unittest.TestSuite(suites))
File "/usr/local/src/python2.5/Lib/test/test_support.py", line 426, in
run_suite
raise TestFailed(err)
test.test_support.TestFailed: Traceback (most recent call last):
File "/usr/local/src/python2.5/Lib/ctypes/test/test_macholib.py", line
55, in test_find
self.failUnless(result.startswith('/usr/lib/libz.1'))
AssertionError
--
>Comment By: Jack Jansen (jackjansen)
Date: 2006-08-21 23:10
Message:
Logged In: YES
user_id=45365
Ronald: just guesing that you know more about this than I do...
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1544102&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1544277 ] python compiler support for with stmt
Bugs item #1544277, was opened at 2006-08-21 16:15 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=1544277&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: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Neil Schemenauer (nascheme) Summary: python compiler support for with stmt Initial Comment: With the attached patch, there are no crashes when running the test suite. Still 9 failures test_compile test_contextlib test_dis test_grammar test_inspect test_peepholer test_scope test_trace test_with There are at least 3 that seem to be real issues: test_compile test_contextlib test_with not sure if test_grammar or test_trace are a real problems or not. The attached patch is close but not perfect at fixing the with issue. The problem is that the STORE_FAST for the 'as' target is a LOAD_FAST (incorrectly). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1544277&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1544106 ] test_anydbm segmentation fault
Bugs item #1544106, was opened at 2006-08-21 11:02 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1544106&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: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Clay Spence (cspence) Assigned to: Nobody/Anonymous (nobody) Summary: test_anydbm segmentation fault Initial Comment: After building 2.5rc1 and bfore installing, make test failed for me at test_anydbm: cholla 88% uname -a Linux cholla.sarnoff.com 2.6.9-34.ELsmp #1 SMP Fri Feb 24 16:54:53 EST 2006 i686 i686 i386 GNU/Linux cholla 89% ./python Python 2.5c1 (r25c1:51305, Aug 21 2006, 11:30:37) [GCC 3.4.5 20051201 (Red Hat 3.4.5-2)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> cholla 90% ./python ./Lib/test/test_anydbm.py Segmentation fault cholla 91% I tracked this to Lib/bsddb/__init__.py, line 355, in _openDBEnv(): e.set_lk_detect(db.DB_LOCK_DEFAULT) See the attached pdb text output, if it's useful. -- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-21 16:28 Message: Logged In: YES user_id=33168 I'm guessing this is an old version of berkeley db. What version of bdb are you using? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1544106&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1467080 ] Many functions in socket module are not thread safe
Bugs item #1467080, was opened at 2006-04-09 03:09 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1467080&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: Python 2.4 >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Maxim Sobolev (sobomax) Assigned to: Nobody/Anonymous (nobody) Summary: Many functions in socket module are not thread safe Initial Comment: The socket module make a great effort to be thread-safe, but misses one big point - it uses single per-instance buffer to hold resolved sockaddr_xxx structures. Therefore, on SMP system it is possible that several threads calling functions that perform address resolution in parallel will stomp on each other resulting in incorrect or invalid address to be used in each case. For example, two threads calling sendto() in parallel can result in packets to be sent to incorrect addresses - packets from thread one from time to time will be sent to address requested by thread two and vice versa. Another, smaller issue is that the call to getnameinfo() is not protected with netdb mutex on systems that don't have thread-safe resolver. -- >Comment By: Martin v. Löwis (loewis) Date: 2006-08-22 01:43 Message: Logged In: YES user_id=21627 The latest patch got resubmitted as #1544279. -- Comment By: Maxim Sobolev (sobomax) Date: 2006-04-25 00:31 Message: Logged In: YES user_id=24670 OK, it looks like the only way to get this bug fixed is to reimplement patch to use stack instead of heap, so that here we go. Attached please find new version of the patch which allocates address buffer on stack. -Maxim -- Comment By: Maxim Sobolev (sobomax) Date: 2006-04-18 01:05 Message: Logged In: YES user_id=24670 > The big win is in simplification of the code. What do you call "big simplification"? Several malloc/free calls and appropriate NULL checks? Aside from stack usage issues the big loss here is portability - we either need to use some fixed length buffer with the size sufficient to hold any type of address (ugly!) or use sockaddr_storage, which may not exist on all platforms supported by the python. -Maxim -- Comment By: Martin v. Löwis (loewis) Date: 2006-04-18 00:51 Message: Logged In: YES user_id=21627 The big win is in simplification of the code. Also, we are not talking about 10k here. On Linux, sock_addr_t is 128 bytes. Take a look at set_error: it allocates 100 bytes for an error buffer. Or sock_repr: 512 bytes for a buffer. Or socket_gethostname: 1024 bytes. Or socket_gethostbyname_ex: 16384 bytes. socket_getaddrinfo: 30 bytes. os_init: 100 bytes Or, looking at other modules: symtable.c:check_unoptimized: 300 bytes. Py_GetVersion: 250 bytes. PySys_SetArgv: 2*MAXPATHLEN+1 (on Linux, this is 8193 bytes). I could go on. Don't worry about stack consumption. Or, if you do, analyse the Python source code, and fix the big offenders first. Premature optimization is the root of all evil. -- Comment By: Maxim Sobolev (sobomax) Date: 2006-04-18 00:10 Message: Logged In: YES user_id=24670 > The address space available to each thread typically doesn't > depend on the number of threads. Instead, the stack size is > pre-determined, so it's vice versa: the number of threads > supported depends on that stack-size, which (currently) isn't tunable. Yes, but my point is that on low-end and/or embedded system the system can be configured with as low stack per thread as possible (since with for example 100 threads, every extra 10K of stack per thread means 1M of extra memory, which in the absence of paging needs to be wired down) and if only one thread needs this stack 990K of it will be effectively wasted. And since getaddrinfo()-family already uses heap for its results I don't see any big win in avoiding extra malloc()/free() call. Expecially considering that we are dealing with i/o here, so that system call overhead will be much more than that anyway, even if the program calls those functions heavily. -Maxim -- Comment By: Martin v. Löwis (loewis) Date: 2006-04-17 23:22 Message: Logged In: YES user_id=21627 The argument of "hundreds of threads" is a red herring. The address space available to each thread typically doesn't depend on the number of threads. Instead, the stack size is pre-determined, so it's vice versa: the number of threads supported depends
[ python-Bugs-1544295 ] Fix Lib/test/test___all__.py
Bugs item #1544295, was opened at 2006-08-21 17:12 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=1544295&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: Demos and Tools Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Hasan Diwan (hdiwan650) Assigned to: Nobody/Anonymous (nobody) Summary: Fix Lib/test/test___all__.py Initial Comment: There's a comment saying: # In case _socket fails to build, make this test fail more gracefully # than an AttributeError somewhere deep in CGIHTTPServer. The proposed fix is attached. Applies to revision 51453. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1544295&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1544306 ] checking size of int... configure: error: cannot compute siz
Bugs item #1544306, was opened at 2006-08-21 20:56 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=1544306&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.4 Status: Open Resolution: None Priority: 5 Submitted By: arrecostao (arrecostao) Assigned to: Nobody/Anonymous (nobody) Summary: checking size of int... configure: error: cannot compute siz Initial Comment: Getting multiple error messages when using ./configure # uname -a SunOS cromagnon 5.10 Generic i86pc i386 i86pc # ./configure checking MACHDEP... sunos5 checking EXTRAPLATDIR... checking for --without-gcc... no checking for --with-cxx=... no checking for c++... c++ checking for C++ compiler default output file name... a.out checking whether the C++ compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking how to run the C preprocessor... gcc -E checking for egrep... egrep checking for AIX... no checking for --with-suffix... checking for case-insensitive build directory... no checking LIBRARY... libpython$(VERSION).a checking LINKCC... $(PURIFY) $(CXX) checking for --enable-shared... no checking for --enable-profiling... checking LDLIBRARY... libpython$(VERSION).a checking for ranlib... ranlib checking for ar... ar checking for a BSD-compatible install... ./install-sh -c checking for --with-pydebug... no checking whether gcc accepts -fno-strict-aliasing... yes checking whether gcc accepts -OPT:Olimit=0... no checking whether gcc accepts -Olimit 1500... no checking whether pthreads are available without options... yes checking whether c++ also accepts flags for thread support... no checking for ANSI C header files... no checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... no checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking curses.h usability... yes checking curses.h presence... yes checking for curses.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking grp.h usability... yes checking grp.h presence... yes checking for grp.h... yes checking langinfo.h usability... yes checking langinfo.h presence... yes checking for langinfo.h... yes checking libintl.h usability... yes checking libintl.h presence... yes checking for libintl.h... yes checking ncurses.h usability... no checking ncurses.h presence... no checking for ncurses.h... no checking poll.h usability... yes checking poll.h presence... yes checking for poll.h... yes checking pthread.h usability... yes checking pthread.h presence... yes checking for pthread.h... yes checking stropts.h usability... yes checking stropts.h presence... yes checking for stropts.h... yes checking termios.h usability... yes checking termios.h presence... yes checking for termios.h... yes checking thread.h usability... no checking thread.h presence... yes configure: WARNING: thread.h: present but cannot be compiled configure: WARNING: thread.h: check for missing prerequisite headers? configure: WARNING: thread.h: see the Autoconf documentation configure: WARNING: thread.h: section "Present But Cannot Be Compiled" configure: WARNING: thread.h: proceeding with the preprocessor's result configure: WARNING: thread.h: in the future, the compiler will take precedence configure: WARNING: ## ## configure: WARNING: ## Report this to http://www.python.org/python-bugs ## configure: WARNING: ## ## checking for thread.h... yes checking for unistd.h... (cached) yes checking utime.h usability... yes checking utime.h presence... yes checking for utime.h... yes checking sys/audioio.h usability... yes checking sys/audioio.h presence... yes checking for sys/audioio.h... yes checking sys/bsdtty.h usability... no checking sys/bsdtty.h presence... no checking for sys/bsdtty.h... no checking sys/file.h usability... yes checking sys/file.h presence... yes checking for sys/file.h... yes checking sys/loadavg.h usability... yes checking sys/loadavg.h presence... yes ch
[ python-Bugs-1544306 ] checking size of int... configure: error: cannot compute siz
Bugs item #1544306, was opened at 2006-08-21 20:56 Message generated for change (Comment added) made by arrecostao You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1544306&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.4 Status: Open Resolution: None Priority: 5 Submitted By: arrecostao (arrecostao) Assigned to: Nobody/Anonymous (nobody) Summary: checking size of int... configure: error: cannot compute siz Initial Comment: Getting multiple error messages when using ./configure # uname -a SunOS cromagnon 5.10 Generic i86pc i386 i86pc # ./configure checking MACHDEP... sunos5 checking EXTRAPLATDIR... checking for --without-gcc... no checking for --with-cxx=... no checking for c++... c++ checking for C++ compiler default output file name... a.out checking whether the C++ compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking how to run the C preprocessor... gcc -E checking for egrep... egrep checking for AIX... no checking for --with-suffix... checking for case-insensitive build directory... no checking LIBRARY... libpython$(VERSION).a checking LINKCC... $(PURIFY) $(CXX) checking for --enable-shared... no checking for --enable-profiling... checking LDLIBRARY... libpython$(VERSION).a checking for ranlib... ranlib checking for ar... ar checking for a BSD-compatible install... ./install-sh -c checking for --with-pydebug... no checking whether gcc accepts -fno-strict-aliasing... yes checking whether gcc accepts -OPT:Olimit=0... no checking whether gcc accepts -Olimit 1500... no checking whether pthreads are available without options... yes checking whether c++ also accepts flags for thread support... no checking for ANSI C header files... no checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... no checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking curses.h usability... yes checking curses.h presence... yes checking for curses.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking grp.h usability... yes checking grp.h presence... yes checking for grp.h... yes checking langinfo.h usability... yes checking langinfo.h presence... yes checking for langinfo.h... yes checking libintl.h usability... yes checking libintl.h presence... yes checking for libintl.h... yes checking ncurses.h usability... no checking ncurses.h presence... no checking for ncurses.h... no checking poll.h usability... yes checking poll.h presence... yes checking for poll.h... yes checking pthread.h usability... yes checking pthread.h presence... yes checking for pthread.h... yes checking stropts.h usability... yes checking stropts.h presence... yes checking for stropts.h... yes checking termios.h usability... yes checking termios.h presence... yes checking for termios.h... yes checking thread.h usability... no checking thread.h presence... yes configure: WARNING: thread.h: present but cannot be compiled configure: WARNING: thread.h: check for missing prerequisite headers? configure: WARNING: thread.h: see the Autoconf documentation configure: WARNING: thread.h: section "Present But Cannot Be Compiled" configure: WARNING: thread.h: proceeding with the preprocessor's result configure: WARNING: thread.h: in the future, the compiler will take precedence configure: WARNING: ## ## configure: WARNING: ## Report this to http://www.python.org/python-bugs ## configure: WARNING: ## ## checking for thread.h... yes checking for unistd.h... (cached) yes checking utime.h usability... yes checking utime.h presence... yes checking for utime.h... yes checking sys/audioio.h usability... yes checking sys/audioio.h presence... yes checking for sys/audioio.h... yes checking sys/bsdtty.h usability... no checking sys/bsdtty.h presence... no checking for sys/bsdtty.h... no checking sys/file.h usability... yes checking sys/file.h presence... yes checking for sys/file.h... yes checking sys/loadavg.h usability... yes checking sys/loadavg.h presence... yes checking for sy
[ python-Bugs-1544339 ] _ctypes fails to build on Solaris x86 32-bit (Sun compiler)
Bugs item #1544339, was opened at 2006-08-21 21: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=1544339&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 Submitted By: Case Van Horsen (casevh) Assigned to: Nobody/Anonymous (nobody) Summary: _ctypes fails to build on Solaris x86 32-bit (Sun compiler) Initial Comment: The _ctypes modules fails to compile on Solaris 10 x86 32-bit using the Sun Studio 11 compiler. _ctypes does compile successfully using gcc. The error messages are attached. If needed, I can provide access to the machine. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1544339&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
