[ python-Bugs-1450019 ] Build of readline fails
Bugs item #1450019, was opened at 2006-03-14 16:23 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1450019&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.3 >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Sydney Weidman (weidmans) >Assigned to: Neal Norwitz (nnorwitz) Summary: Build of readline fails Initial Comment: I was attempting to compile Python-2.3.5 under Fedora Core 4: Python 2.3.5 (#14, Mar 14 2006, 17:57:17) [GCC 4.0.2 20051125 (Red Hat 4.0.2-8)] on linux2 and needed it to have readline support No matter how I compiled it, the readline module was never built, and of course readline functionality did not work. I tried ./configure --with-readline=/usr and a couple of other configure options that I thought would help, but nothing worked. Finally, I tried: make Modules/readline which gave the error: gcc -pthread -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I./Include -L/home/sweidman/Applications/Python-2.3.5 Modules/readline.c -o Modules/readline Modules/readline.c:96: error: static declaration of âhistory_lengthâ follows non-static declaration /usr/include/readline/history.h:242: error: previous declaration of âhistory_lengthâ was here make: *** [Modules/readline] Error 1 So without knowing what I was really doing, I commented out the definition of history_length at Modules/readline.c:96 After making that change, Python-2.3.5 compiled and ran fine with readline support working; i.e. "import readline" gave no errors and the arrow keys bring back the last command. So is this a bug or a quirk on my platform or something else I'm doing wrong? Thanks for the great software!! -- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-15 00:08 Message: Logged In: YES user_id=33168 Python 2.3 isn't supported any longer. In the current version, it looks like history_length was renamed to prepend an underscore (ie, the name became: _history_length). This was presumably to fix the same problem. The name also changed in write_history_file(), set_history_length(), and get_history_length(). It's not so much anything you are doing wrong, just a compatability problem, since FC4 is quite a bit newer than Python 2.3. If you upgrade to Python 2.4, you shouldn't have the problem, or you can run with your local modification. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1450019&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1450212 ] int() and isdigit() accept non-digit numbers when using unic
Bugs item #1450212, was opened at 2006-03-15 09:05 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=1450212&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.4 Status: Open Resolution: None Priority: 5 Submitted By: Pierre-Frédéric Caillaud (peufeu) Assigned to: Nobody/Anonymous (nobody) Summary: int() and isdigit() accept non-digit numbers when using unic Initial Comment: I had a very surprising bug this morning, in a python script which extract numeric information from human entered text. The problem is the following : many UNICODE characters, in UNICODE strings, are considered to be digits. For instance, the character "²" (does it appear on your screen ? it's u'\xb2'). The output of the following command is pretty interesting : print ''.join([x for x in map( unichr, xrange( 65536 )) if x.isdigit()]) Then, int() will happily parse the string : int( u"٥٦٧٨٩۰۱۲" ) 56789012 (I really hope this bug system supports unicode). However, I can't do a=٥٦٧٨٩۰۱۲ for instance. Philosophically, Python is right, these characters are probably all digits, and it's pretty cool to be able to parse numbers written in ARABIC-INDIC DIGITs or something, as unicodedata.name says). However, from a practical point of view, I guess most parsing done with python isn't on OCR'd cuneiform stone tablets, but rather modern computer documents... Whenever a surface (in m²) was near a phone number in my human entered text, the "²" would be absorbed as a part of the phone number, because u"²".isdigit() is True. Then bullshit phone numbers would appear on the website. Any number followed by a little footnote number will get the footnote number embedded... I had to replace all the .isdigit() with a re.compile( ur"^\d+$" ). match(). Interestingly, for re, even in unicode, \d is 0-9 and nothing else. At least, it would be normal for int() to raise an exception when fed this type of data. Please. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1450212&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1450212 ] int() and isdigit() accept non-digit unicode numbers
Bugs item #1450212, was opened at 2006-03-15 09:05 Message generated for change (Settings changed) made by peufeu You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1450212&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.4 Status: Open Resolution: None Priority: 5 Submitted By: Pierre-Frédéric Caillaud (peufeu) Assigned to: Nobody/Anonymous (nobody) >Summary: int() and isdigit() accept non-digit unicode numbers Initial Comment: I had a very surprising bug this morning, in a python script which extract numeric information from human entered text. The problem is the following : many UNICODE characters, in UNICODE strings, are considered to be digits. For instance, the character "²" (does it appear on your screen ? it's u'\xb2'). The output of the following command is pretty interesting : print ''.join([x for x in map( unichr, xrange( 65536 )) if x.isdigit()]) Then, int() will happily parse the string : int( u"٥٦٧٨٩۰۱۲" ) 56789012 (I really hope this bug system supports unicode). However, I can't do a=٥٦٧٨٩۰۱۲ for instance. Philosophically, Python is right, these characters are probably all digits, and it's pretty cool to be able to parse numbers written in ARABIC-INDIC DIGITs or something, as unicodedata.name says). However, from a practical point of view, I guess most parsing done with python isn't on OCR'd cuneiform stone tablets, but rather modern computer documents... Whenever a surface (in m²) was near a phone number in my human entered text, the "²" would be absorbed as a part of the phone number, because u"²".isdigit() is True. Then bullshit phone numbers would appear on the website. Any number followed by a little footnote number will get the footnote number embedded... I had to replace all the .isdigit() with a re.compile( ur"^\d+$" ). match(). Interestingly, for re, even in unicode, \d is 0-9 and nothing else. At least, it would be normal for int() to raise an exception when fed this type of data. Please. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1450212&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1450212 ] int() and isdigit() accept non-digit unicode numbers
Bugs item #1450212, was opened at 2006-03-15 10:05 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1450212&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.4 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Peufeu (peufeu) Assigned to: Nobody/Anonymous (nobody) Summary: int() and isdigit() accept non-digit unicode numbers Initial Comment: I had a very surprising bug this morning, in a python script which extract numeric information from human entered text. The problem is the following : many UNICODE characters, in UNICODE strings, are considered to be digits. For instance, the character "²" (does it appear on your screen ? it's u'\xb2'). The output of the following command is pretty interesting : print ''.join([x for x in map( unichr, xrange( 65536 )) if x.isdigit()]) Then, int() will happily parse the string : int( u"٥٦٧٨٩۰۱۲" ) 56789012 (I really hope this bug system supports unicode). However, I can't do a=٥٦٧٨٩۰۱۲ for instance. Philosophically, Python is right, these characters are probably all digits, and it's pretty cool to be able to parse numbers written in ARABIC-INDIC DIGITs or something, as unicodedata.name says). However, from a practical point of view, I guess most parsing done with python isn't on OCR'd cuneiform stone tablets, but rather modern computer documents... Whenever a surface (in m²) was near a phone number in my human entered text, the "²" would be absorbed as a part of the phone number, because u"²".isdigit() is True. Then bullshit phone numbers would appear on the website. Any number followed by a little footnote number will get the footnote number embedded... I had to replace all the .isdigit() with a re.compile( ur"^\d+$" ). match(). Interestingly, for re, even in unicode, \d is 0-9 and nothing else. At least, it would be normal for int() to raise an exception when fed this type of data. Please. -- >Comment By: M.-A. Lemburg (lemburg) Date: 2006-03-15 11:42 Message: Logged In: YES user_id=38388 Python is following the Unicode standard in this respect. If you want to make sure that only a subset of numbers is parsed, I'd suggest that you write a little helper function that implements the RE check and then lets int() do its work. Rejecting as "invalid". -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1450212&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1450212 ] int() and isdigit() accept non-digit unicode numbers
Bugs item #1450212, was opened at 2006-03-15 18:05
Message generated for change (Comment added) made by perky
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1450212&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.4
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Peufeu (peufeu)
Assigned to: Nobody/Anonymous (nobody)
Summary: int() and isdigit() accept non-digit unicode numbers
Initial Comment:
I had a very surprising bug this morning, in a python script which
extract numeric information from human entered text.
The problem is the following : many UNICODE characters, in
UNICODE strings, are considered to be digits. For instance, the
character "²" (does it appear on your screen ? it's u'\xb2').
The output of the following command is pretty interesting :
print ''.join([x for x in map( unichr, xrange( 65536 )) if x.isdigit()])
Then, int() will happily parse the string :
int( u"٥٦٧٨٩۰۱۲" )
56789012
(I really hope this bug system supports unicode).
However, I can't do a=٥٦٧٨٩۰۱۲ for instance.
Philosophically, Python is right, these characters are probably all
digits, and it's pretty cool to be able to parse numbers written in
ARABIC-INDIC DIGITs or something, as unicodedata.name says).
However, from a practical point of view, I guess most parsing done
with python isn't on OCR'd cuneiform stone tablets, but rather
modern computer documents...
Whenever a surface (in m²) was near a phone number in my human
entered text, the "²" would be absorbed as a part of the phone
number, because u"²".isdigit() is True. Then bullshit phone numbers
would appear on the website.
Any number followed by a little footnote number will get the
footnote number embedded...
I had to replace all the .isdigit() with a re.compile( ur"^\d+$" ).
match(). Interestingly, for re, even in unicode, \d is 0-9 and nothing
else.
At least, it would be normal for int() to raise an exception when fed
this type of data. Please.
--
>Comment By: Hye-Shik Chang (perky)
Date: 2006-03-15 21:18
Message:
Logged In: YES
user_id=55188
In the mean time, it can be simply regarded as unicode
conforming.
But a minor issue came up to my mind:
I think the name, `isdigit', is quite similar to ISO C's
equivalent. But they don't behave same; ISO C and POSIX
SUSv3 specifies isdigit() is true only for 0 1 2 3 4 5 6 7 8
9. So, isdigit() of C doesn't return true for any of
unicode characters > ord('9'). I just fear that the
inconsistency might cause some confusion.
--
Comment By: M.-A. Lemburg (lemburg)
Date: 2006-03-15 19:42
Message:
Logged In: YES
user_id=38388
Python is following the Unicode standard in this respect.
If you want to make sure that only a subset of numbers is
parsed, I'd suggest that you write a little helper function
that implements the RE check and then lets int() do its work.
Rejecting as "invalid".
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1450212&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1450212 ] int() and isdigit() accept non-digit unicode numbers
Bugs item #1450212, was opened at 2006-03-15 10:05
Message generated for change (Comment added) made by lemburg
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1450212&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.4
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Peufeu (peufeu)
Assigned to: Nobody/Anonymous (nobody)
Summary: int() and isdigit() accept non-digit unicode numbers
Initial Comment:
I had a very surprising bug this morning, in a python script which
extract numeric information from human entered text.
The problem is the following : many UNICODE characters, in
UNICODE strings, are considered to be digits. For instance, the
character "²" (does it appear on your screen ? it's u'\xb2').
The output of the following command is pretty interesting :
print ''.join([x for x in map( unichr, xrange( 65536 )) if x.isdigit()])
Then, int() will happily parse the string :
int( u"٥٦٧٨٩۰۱۲" )
56789012
(I really hope this bug system supports unicode).
However, I can't do a=٥٦٧٨٩۰۱۲ for instance.
Philosophically, Python is right, these characters are probably all
digits, and it's pretty cool to be able to parse numbers written in
ARABIC-INDIC DIGITs or something, as unicodedata.name says).
However, from a practical point of view, I guess most parsing done
with python isn't on OCR'd cuneiform stone tablets, but rather
modern computer documents...
Whenever a surface (in m²) was near a phone number in my human
entered text, the "²" would be absorbed as a part of the phone
number, because u"²".isdigit() is True. Then bullshit phone numbers
would appear on the website.
Any number followed by a little footnote number will get the
footnote number embedded...
I had to replace all the .isdigit() with a re.compile( ur"^\d+$" ).
match(). Interestingly, for re, even in unicode, \d is 0-9 and nothing
else.
At least, it would be normal for int() to raise an exception when fed
this type of data. Please.
--
>Comment By: M.-A. Lemburg (lemburg)
Date: 2006-03-15 13:32
Message:
Logged In: YES
user_id=38388
I can see your point, but if we were to follow that scheme,
we'd have to introduce a whole new set of APIs for Unicode
character testing.
Note that the comparison to C standards is flawed in this
respect:
Unicode APIs would have to be compared to the wide character
APIs, e.g. iswdigit() which do behave (more or less) like
isdigit() does in Python for Unicode characters.
Furthermore, the isXYZ() and iswXYZ() APIs in C are locale
aware (and so are the Python functions for strings), whereas
the Python Unicode implementation deliberately is not.
So in summary, you can't really compare the C functions to
the Python functions.
--
Comment By: Hye-Shik Chang (perky)
Date: 2006-03-15 13:18
Message:
Logged In: YES
user_id=55188
In the mean time, it can be simply regarded as unicode
conforming.
But a minor issue came up to my mind:
I think the name, `isdigit', is quite similar to ISO C's
equivalent. But they don't behave same; ISO C and POSIX
SUSv3 specifies isdigit() is true only for 0 1 2 3 4 5 6 7 8
9. So, isdigit() of C doesn't return true for any of
unicode characters > ord('9'). I just fear that the
inconsistency might cause some confusion.
--
Comment By: M.-A. Lemburg (lemburg)
Date: 2006-03-15 11:42
Message:
Logged In: YES
user_id=38388
Python is following the Unicode standard in this respect.
If you want to make sure that only a subset of numbers is
parsed, I'd suggest that you write a little helper function
that implements the RE check and then lets int() do its work.
Rejecting as "invalid".
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1450212&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1450212 ] int() and isdigit() accept non-digit unicode numbers
Bugs item #1450212, was opened at 2006-03-15 09:05
Message generated for change (Comment added) made by peufeu
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1450212&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.4
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Peufeu (peufeu)
Assigned to: Nobody/Anonymous (nobody)
Summary: int() and isdigit() accept non-digit unicode numbers
Initial Comment:
I had a very surprising bug this morning, in a python script which
extract numeric information from human entered text.
The problem is the following : many UNICODE characters, in
UNICODE strings, are considered to be digits. For instance, the
character "²" (does it appear on your screen ? it's u'\xb2').
The output of the following command is pretty interesting :
print ''.join([x for x in map( unichr, xrange( 65536 )) if x.isdigit()])
Then, int() will happily parse the string :
int( u"٥٦٧٨٩۰۱۲" )
56789012
(I really hope this bug system supports unicode).
However, I can't do a=٥٦٧٨٩۰۱۲ for instance.
Philosophically, Python is right, these characters are probably all
digits, and it's pretty cool to be able to parse numbers written in
ARABIC-INDIC DIGITs or something, as unicodedata.name says).
However, from a practical point of view, I guess most parsing done
with python isn't on OCR'd cuneiform stone tablets, but rather
modern computer documents...
Whenever a surface (in m²) was near a phone number in my human
entered text, the "²" would be absorbed as a part of the phone
number, because u"²".isdigit() is True. Then bullshit phone numbers
would appear on the website.
Any number followed by a little footnote number will get the
footnote number embedded...
I had to replace all the .isdigit() with a re.compile( ur"^\d+$" ).
match(). Interestingly, for re, even in unicode, \d is 0-9 and nothing
else.
At least, it would be normal for int() to raise an exception when fed
this type of data. Please.
--
>Comment By: Peufeu (peufeu)
Date: 2006-03-15 13:05
Message:
Logged In: YES
user_id=587274
It certainly is confusing, and it bit me ;)
That .isdigit() is unicode-conformant is understandable (but a hint should
be added to the docs IMHO). I with there was a .isasciidigit() function on
the unicode string, because using a helper is ugly.
However int() accepting all these characters and happily parsing them
worries me a bit more. Is it really supposed to do this ?
--
Comment By: M.-A. Lemburg (lemburg)
Date: 2006-03-15 12:32
Message:
Logged In: YES
user_id=38388
I can see your point, but if we were to follow that scheme,
we'd have to introduce a whole new set of APIs for Unicode
character testing.
Note that the comparison to C standards is flawed in this
respect:
Unicode APIs would have to be compared to the wide character
APIs, e.g. iswdigit() which do behave (more or less) like
isdigit() does in Python for Unicode characters.
Furthermore, the isXYZ() and iswXYZ() APIs in C are locale
aware (and so are the Python functions for strings), whereas
the Python Unicode implementation deliberately is not.
So in summary, you can't really compare the C functions to
the Python functions.
--
Comment By: Hye-Shik Chang (perky)
Date: 2006-03-15 12:18
Message:
Logged In: YES
user_id=55188
In the mean time, it can be simply regarded as unicode
conforming.
But a minor issue came up to my mind:
I think the name, `isdigit', is quite similar to ISO C's
equivalent. But they don't behave same; ISO C and POSIX
SUSv3 specifies isdigit() is true only for 0 1 2 3 4 5 6 7 8
9. So, isdigit() of C doesn't return true for any of
unicode characters > ord('9'). I just fear that the
inconsistency might cause some confusion.
--
Comment By: M.-A. Lemburg (lemburg)
Date: 2006-03-15 10:42
Message:
Logged In: YES
user_id=38388
Python is following the Unicode standard in this respect.
If you want to make sure that only a subset of numbers is
parsed, I'd suggest that you write a little helper function
that implements the RE check and then lets int() do its work.
Rejecting as "invalid".
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1450212&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1450456 ] windows python truncates files when reading them
Bugs item #1450456, was opened at 2006-03-15 10:17
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=1450456&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: Windows
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: tom berger (object)
Assigned to: Nobody/Anonymous (nobody)
Summary: windows python truncates files when reading them
Initial Comment:
when using python for windows, opening a file and
calling read() on the file object returns only some of
the file (about 1K). i am expecting read to return the
entire contents of the file (and this is what i get
when i run the same code on cygwin and linux).
to reproduce:
prepare a sufficiently large file myfile.xxx (say > 100K)
source = open('myfile.xxx', 'r')
dest = open('copy_myfile.xxx', 'w')
dest.write(source.read())
source.close()
dest.close()
myfile.xxx and copy_myfile.xxx should be identical, and
they are if you run this on most python distributions.
when running the version installed from the .msi
installer on python.org the copy is truncated (as part
of reading, i'm pretty sure).
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1450456&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1450456 ] windows python truncates files when reading them
Bugs item #1450456, was opened at 2006-03-15 15:17
Message generated for change (Comment added) made by gbrandl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1450456&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: Windows
Group: Python 2.4
>Status: Pending
>Resolution: Invalid
Priority: 5
Submitted By: tom berger (object)
Assigned to: Nobody/Anonymous (nobody)
Summary: windows python truncates files when reading them
Initial Comment:
when using python for windows, opening a file and
calling read() on the file object returns only some of
the file (about 1K). i am expecting read to return the
entire contents of the file (and this is what i get
when i run the same code on cygwin and linux).
to reproduce:
prepare a sufficiently large file myfile.xxx (say > 100K)
source = open('myfile.xxx', 'r')
dest = open('copy_myfile.xxx', 'w')
dest.write(source.read())
source.close()
dest.close()
myfile.xxx and copy_myfile.xxx should be identical, and
they are if you run this on most python distributions.
when running the version installed from the .msi
installer on python.org the copy is truncated (as part
of reading, i'm pretty sure).
--
>Comment By: Georg Brandl (gbrandl)
Date: 2006-03-15 15:22
Message:
Logged In: YES
user_id=849994
I'm guessing here, but the only conclusion is that you are
reading a binary file. Since Windows makes a difference
between text and binary files, you must read the file with
mode 'rb', or Windows will stop at the first chr(26) ==
Ctrl+Z == EOF.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1450456&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1450456 ] windows python truncates files when reading them
Bugs item #1450456, was opened at 2006-03-15 10:17
Message generated for change (Comment added) made by object
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1450456&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: Windows
Group: Python 2.4
>Status: Deleted
Resolution: Invalid
Priority: 5
Submitted By: tom berger (object)
Assigned to: Nobody/Anonymous (nobody)
Summary: windows python truncates files when reading them
Initial Comment:
when using python for windows, opening a file and
calling read() on the file object returns only some of
the file (about 1K). i am expecting read to return the
entire contents of the file (and this is what i get
when i run the same code on cygwin and linux).
to reproduce:
prepare a sufficiently large file myfile.xxx (say > 100K)
source = open('myfile.xxx', 'r')
dest = open('copy_myfile.xxx', 'w')
dest.write(source.read())
source.close()
dest.close()
myfile.xxx and copy_myfile.xxx should be identical, and
they are if you run this on most python distributions.
when running the version installed from the .msi
installer on python.org the copy is truncated (as part
of reading, i'm pretty sure).
--
>Comment By: tom berger (object)
Date: 2006-03-15 10:36
Message:
Logged In: YES
user_id=110577
yes, of course.
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-03-15 10:22
Message:
Logged In: YES
user_id=849994
I'm guessing here, but the only conclusion is that you are
reading a binary file. Since Windows makes a difference
between text and binary files, you must read the file with
mode 'rb', or Windows will stop at the first chr(26) ==
Ctrl+Z == EOF.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1450456&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1450807 ] Python build fails for gcc 4.x from Gnu
Bugs item #1450807, was opened at 2006-03-15 16:36
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=1450807&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: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: John W. Grove (johnwgrove)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python build fails for gcc 4.x from Gnu
Initial Comment:
The configure script for Python 4.2.2 add the compiler
flags -Wno-long-double and -no-cpp-precomp when using
the Gnu gcc compiler on Darwin. This causes the build
to fail when using versions of GCC build directly from
Gnu source (for example gcc-4.0.2 and gcc-4.1). These
options are only available when using the "native" gcc
compilers supplied with the Darwin OS. In particular I
am using OS X 8.5.0. There is a simple correction to
this problem that involves using autoconf tests for the
appropriateness of these options before adding them to
the BASECFLAGS environment variable. In particular the
following works:
Replace the line
BASECFLAGS="$BASECFLAGS -Wno-long-double
-no-cpp-precomp -mno-fused-madd"
at or near line 3165 under the Darwin case in configure.in
with the following test
AC_LANG_SAVE
AC_LANG_C
ac_save_cc="$CC"
for arg in -Wno-long-double -no-cpp-precomp
-mno-fused-madd ; do
CC="$ac_save_cc $arg"
AC_COMPILE_IFELSE([
AC_LANG_SOURCE([[
#include
#include
int main(int argc,char**argv)
{
return 0;
}
]])],[BASECFLAGS="$BASECFLAGS $arg"],[])
done
CC="$ac_save_cc"
AC_LANG_RESTORE
in other words test to see if the option works with the
chosen compiler before adding it blindly to BASECFLAGS.
I am attaching this version of configure.in for your
convenience. I tested my build of Python-2.4.2 on both
Linux and Darwin using the apple version of gcc 3.3 as
well as Gnu versions gcc 4.0.2 and 4.1 that I built
from source. The build and install worked properly and
the python executable was runable in all cases. I did
not perform more extensive regression tests, but I
believe this change has no effect for compilations
using previously support configurations, and only
applies for new currently unsupported compilers.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1450807&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
