[ python-Bugs-1381476 ] csv.reader endless loop
Bugs item #1381476, was opened at 2005-12-15 11:04
Message generated for change (Comment added) made by wwwingman
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1381476&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Christian Harms (wwwingman)
Assigned to: Andrew McNamara (andrewmcnamara)
Summary: csv.reader endless loop
Initial Comment:
Hi,
the csv.reader produce a endless loop, ifan parsing
Error is in the last line of the CSV-File. If you put
an "\r" in the last line, cvs.Error is raised and
StopIteration will lost.
import csv, StringIO
fp = StringIO.StringIO("line1\nline2\rerror")
reader = csv.reader(fp)
while 1:
try:
print reader.next()
except csv.Error:
print "Error"
except StopIteration:
break
Die Problem is in python 2.3 AND python 2.4. Other
version are not checked.
--
>Comment By: Christian Harms (wwwingman)
Date: 2006-01-03 08:56
Message:
Logged In: YES
user_id=1405594
>birkenfeld: csv.Error would imply a StopIteration/break ...
No, this Error says only: "Can not parse THIS line ...".
This exception is used for reading buggy
outlook-Export-CSV-Files und trying to read some lines (not
all). And if the error is in the last line, the
StopIteration will be forgotten and the Error will be
produced in a endless-loop.
input = StringIO.StringIO("1.\rerror\n2.ok\n3.\rerr")
#insert my while-loop
#Output:
>Error
>2.ok
>Error
>Error
...
--
Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-12-17 17:02
Message:
Logged In: YES
user_id=1188172
Let the expert judge.
--
Comment By: Thomas Lee (krumms)
Date: 2005-12-17 16:56
Message:
Logged In: YES
user_id=315535
Actually, the problem may not be a problem with the csv
module at all, it may be a misinterpretation of the API on
the submitters part.
Is there any time a non-fatal csv.Error would/could be
raised? Seems to me that a csv.Error would imply a
StopIteration/break ...
--
Comment By: Thomas Lee (krumms)
Date: 2005-12-17 15:17
Message:
Logged In: YES
user_id=315535
I think this may be fixed in subversion:
[EMAIL PROTECTED]:~/work/python$ svn info
Path: .
URL: http://svn.python.org/projects/python/trunk
Repository UUID: 6015fed2-1504-0410-9fe1-9d1591cc4771
Revision: 41731
Node Kind: directory
Schedule: normal
Last Changed Author: fredrik.lundh
Last Changed Rev: 41729
Last Changed Date: 2005-12-17 18:33:21 +1000 (Sat, 17 Dec 2005)
Properties Last Updated: 2005-12-17 21:44:46 +1000 (Sat, 17
Dec 2005)
[EMAIL PROTECTED]:~/work/python$ python -V
Python 2.4.2
[EMAIL PROTECTED]:~/work/python$ python Sandbox/csv_reader_test.py
['line1']
ERROR: newline inside string
[EMAIL PROTECTED]:~/work/python$ ./python -V
Python 2.5a0
[EMAIL PROTECTED]:~/work/python$ ./python Sandbox/csv_reader_test.py
['line1']
ERROR: new-line character seen in unquoted field - do you
need to open the file in universal-newline mode?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1381476&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1390608 ] split() breaks no-break spaces
Bugs item #1390608, was opened at 2005-12-26 16:03
Message generated for change (Comment added) made by doerwalter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1390608&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
Submitted By: MvR (maxim_razin)
Assigned to: M.-A. Lemburg (lemburg)
Summary: split() breaks no-break spaces
Initial Comment:
string.split(), str.split() and unicode.split() without
parameters break strings by the No-break space (U+00A0)
character. This character is specially intended not to
be a split border.
>>> u"Hello\u00A0world".split()
[u'Hello', u'world']
--
>Comment By: Walter Dörwald (doerwalter)
Date: 2006-01-03 11:33
Message:
Logged In: YES
user_id=89016
Seems I confused strip() with split(). I *did* try that work
around, and it did what I expected: It *didn't* split on
U+00A0 ;)
If we want to fix this discrepancy, we could add methods
stripchars(), (as a synonym for strip()) and stripstring(),
as well as splitchars() and splitstring() (as a synonym for
split()).
--
Comment By: M.-A. Lemburg (lemburg)
Date: 2006-01-02 12:13
Message:
Logged In: YES
user_id=38388
Oops. You're right, Sjoerd.
Still, you could achieve the splitting by using a
re-expression that is build from the set of characters
fetched from the Unicode database and then using the
.split() method of the re object.
--
Comment By: Sjoerd Mullender (sjoerd)
Date: 2006-01-02 11:48
Message:
Logged In: YES
user_id=43607
Walter and MAL, did you actually try that work around? It
doesn't work:
>>> import sys, unicodedata
>>> spaces = u"".join(unichr(c) for c in xrange(0,
sys.maxunicode) if unicodedata.category(unichr(c))=="Zs" and
c != 160)
>>> foo = u"Hello\u00A0world"
>>> foo.split(spaces)
[u'Hello\xa0world']
That's because split() takes the whole separator argument as
separator, not any of the characters in it.
--
Comment By: M.-A. Lemburg (lemburg)
Date: 2005-12-30 14:06
Message:
Logged In: YES
user_id=38388
Maxim, you are right that \xA0 is a non-break space.
However, like the others already mentioned, the .split()
method defaults to breaking a string on whitespace
characters, not breakable whitespace characters. The intent
is not a typographical one, but originates from the desire
to quickly tokenize a string.
If you'd rather like to see a different set of whitespace
characters used, you can pass such a template string to the
.split() method (Walter gave an example).
Closing this as "Won't fix".
--
Comment By: Walter Dörwald (doerwalter)
Date: 2005-12-30 13:35
Message:
Logged In: YES
user_id=89016
What's wrong with the following?
import sys, unicodedata
spaces = u"".join(unichr(c) for c in xrange(0,
sys.maxunicode) if unicodedata.category(unichr(c))=="Zs" and
c != 160)
foo.split(spaces)
--
Comment By: Hye-Shik Chang (perky)
Date: 2005-12-30 01:30
Message:
Logged In: YES
user_id=55188
Python documentation says that it splits in "whitespace
characters" not "breaking characters". So, current
behavior is correct according to the documentation. And
even rationale among string methods are heavily depends on
ctype functions on libc. Therefore, we can't serve special
treatment for the NBSP.
However, I feel the need for the splitting function that
awares what character is breaking or not. How about to add
it as unicodedata.split()?
--
Comment By: Fredrik Lundh (effbot)
Date: 2005-12-29 21:42
Message:
Logged In: YES
user_id=38376
split isn't a word-wrapping split, so I'm not sure that's
the right place to fix this. ("no-break space" is white-
space, according to the Unicode standard, and split breaks
on whitespace).
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1390608&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1390608 ] split() breaks no-break spaces
Bugs item #1390608, was opened at 2005-12-26 16:03
Message generated for change (Comment added) made by lemburg
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1390608&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
Submitted By: MvR (maxim_razin)
Assigned to: M.-A. Lemburg (lemburg)
Summary: split() breaks no-break spaces
Initial Comment:
string.split(), str.split() and unicode.split() without
parameters break strings by the No-break space (U+00A0)
character. This character is specially intended not to
be a split border.
>>> u"Hello\u00A0world".split()
[u'Hello', u'world']
--
>Comment By: M.-A. Lemburg (lemburg)
Date: 2006-01-03 12:07
Message:
Logged In: YES
user_id=38388
No.
These things are application scope details and should thus
be implemented in the application rather than as method on
an object.
The methods always work on whitespace and that's clearly
defined.
--
Comment By: Walter Dörwald (doerwalter)
Date: 2006-01-03 11:33
Message:
Logged In: YES
user_id=89016
Seems I confused strip() with split(). I *did* try that work
around, and it did what I expected: It *didn't* split on
U+00A0 ;)
If we want to fix this discrepancy, we could add methods
stripchars(), (as a synonym for strip()) and stripstring(),
as well as splitchars() and splitstring() (as a synonym for
split()).
--
Comment By: M.-A. Lemburg (lemburg)
Date: 2006-01-02 12:13
Message:
Logged In: YES
user_id=38388
Oops. You're right, Sjoerd.
Still, you could achieve the splitting by using a
re-expression that is build from the set of characters
fetched from the Unicode database and then using the
.split() method of the re object.
--
Comment By: Sjoerd Mullender (sjoerd)
Date: 2006-01-02 11:48
Message:
Logged In: YES
user_id=43607
Walter and MAL, did you actually try that work around? It
doesn't work:
>>> import sys, unicodedata
>>> spaces = u"".join(unichr(c) for c in xrange(0,
sys.maxunicode) if unicodedata.category(unichr(c))=="Zs" and
c != 160)
>>> foo = u"Hello\u00A0world"
>>> foo.split(spaces)
[u'Hello\xa0world']
That's because split() takes the whole separator argument as
separator, not any of the characters in it.
--
Comment By: M.-A. Lemburg (lemburg)
Date: 2005-12-30 14:06
Message:
Logged In: YES
user_id=38388
Maxim, you are right that \xA0 is a non-break space.
However, like the others already mentioned, the .split()
method defaults to breaking a string on whitespace
characters, not breakable whitespace characters. The intent
is not a typographical one, but originates from the desire
to quickly tokenize a string.
If you'd rather like to see a different set of whitespace
characters used, you can pass such a template string to the
.split() method (Walter gave an example).
Closing this as "Won't fix".
--
Comment By: Walter Dörwald (doerwalter)
Date: 2005-12-30 13:35
Message:
Logged In: YES
user_id=89016
What's wrong with the following?
import sys, unicodedata
spaces = u"".join(unichr(c) for c in xrange(0,
sys.maxunicode) if unicodedata.category(unichr(c))=="Zs" and
c != 160)
foo.split(spaces)
--
Comment By: Hye-Shik Chang (perky)
Date: 2005-12-30 01:30
Message:
Logged In: YES
user_id=55188
Python documentation says that it splits in "whitespace
characters" not "breaking characters". So, current
behavior is correct according to the documentation. And
even rationale among string methods are heavily depends on
ctype functions on libc. Therefore, we can't serve special
treatment for the NBSP.
However, I feel the need for the splitting function that
awares what character is breaking or not. How about to add
it as unicodedata.split()?
--
Comment By: Fredrik Lundh (effbot)
Date: 2005-12-29 21:42
Message:
Logged In: YES
user_id=38376
split isn't a word-wrapping split, so I'm not sure that's
the right place to fix this. ("no-break space" is white-
space, according to the Unicode standard, and split breaks
on whitespace).
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1390608&group_id=5470
___
Python-bugs-list mailing list
Uns
[ python-Bugs-1395926 ] make fails trying to run svnversion
Bugs item #1395926, was opened at 2006-01-03 12:30 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=1395926&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: M.-A. Lemburg (lemburg) Assigned to: Barry A. Warsaw (bwarsaw) Summary: make fails trying to run svnversion Initial Comment: If you run make in a directory that has an .svn subdir, make fails if there's no usable subversion installation on the PATH: if test -d ./.svn; then \ svnversion . >buildno; \ elif test -f buildno; then \ expr `cat buildno` + 1 >buildno1; \ mv -f buildno1 buildno; \ else echo 1 >buildno; fi /bin/sh: svnversion: command not found The above test should probably also check for the availability of svnversion. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1395926&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1396030 ] TimedRotatingFileHandler at midnight rolls over at 01:00
Bugs item #1396030, was opened at 2006-01-03 14:26 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=1396030&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Andrew Waters (awaters) Assigned to: Nobody/Anonymous (nobody) Summary: TimedRotatingFileHandler at midnight rolls over at 01:00 Initial Comment: Using TimedRotatingFileHandler with interval set to midnight rolls the log over at 1:00am rather than midnight. (LocalTime = GMT). This is because the calculation of seconds until midnight is incorrect (it behaves as if there are 24 hours, 59 minutes and 59 seconds in the day). It also means that should a program stop between midnight and 1:00am and restart it fails to roll over the log as the log over time is set to 1:00am the next day. Occurs on Linux (FC3), Windows XP (SP2). Bug occurs (2.4.2 and currently exists in most recent 2.5 SVN code). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1396030&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1395926 ] make fails trying to run svnversion
Bugs item #1395926, was opened at 2006-01-03 06:30 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1395926&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: Fixed Priority: 5 Submitted By: M.-A. Lemburg (lemburg) Assigned to: Barry A. Warsaw (bwarsaw) Summary: make fails trying to run svnversion Initial Comment: If you run make in a directory that has an .svn subdir, make fails if there's no usable subversion installation on the PATH: if test -d ./.svn; then \ svnversion . >buildno; \ elif test -f buildno; then \ expr `cat buildno` + 1 >buildno1; \ mv -f buildno1 buildno; \ else echo 1 >buildno; fi /bin/sh: svnversion: command not found The above test should probably also check for the availability of svnversion. -- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-01-03 09:31 Message: Logged In: YES user_id=12800 r41907 -- added a test for svnversion command on $PATH -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1395926&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1396040 ] TimedRotatingFileHandler does not recover from open error
Bugs item #1396040, was opened at 2006-01-03 14:38 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=1396040&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Andrew Waters (awaters) Assigned to: Nobody/Anonymous (nobody) Summary: TimedRotatingFileHandler does not recover from open error Initial Comment: When doing a rollover TimedRotatingFileHandler doRollover does not recover if there is an open error. This is because when the rollover function fails at the open (e.g. too many files open) and is called again at the next attempt to write to the log doRollover attempts to rename (the now no longer existing) original file which raises an exception. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1396040&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1303434 ] Please include pdb with windows distribution
Feature Requests item #1303434, was opened at 2005-09-24 19:30 Message generated for change (Comment added) made by lylefile You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1303434&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: None Status: Open Resolution: None Priority: 5 Submitted By: Lyle Thompson (lylefile) Assigned to: Nobody/Anonymous (nobody) Summary: Please include pdb with windows distribution Initial Comment: Checking out the source files and rebuilding is not guaranteed to build a program database (pdb) file that represents the distribution python DLL. This may be due to a differences in the windows version or visual studio service pack on my system vs the one used to build the distribution, but tracking it down can be very time consuming. Including the pdb in the distribution should be trivial and avoid this problem entirely. Although I can fix the problem for future releases of our product, I am also supporting previous releases that included the standard DLL included in the distribution. -- >Comment By: Lyle Thompson (lylefile) Date: 2006-01-03 19:06 Message: Logged In: YES user_id=1351115 A PDB file is required for debugging crash dumps from complex pythonic programs. This ability is absolutely critical for commercial programs using python. Technically, the crashes only happen within pyds or dlls, but it is often very vitally important to be able to find out what python code was being interpreted at the time. Unfortunately, I've even seen "pure" python crash in one of the supplied pyd's. Of course, the pdb file should be in a separate download, as few users require the ability to reverse engineer crash dumps. -- Comment By: Martin v. Löwis (loewis) Date: 2005-12-28 00:12 Message: Logged In: YES user_id=21627 Update: distribution in a separate zipfile would be possible, provided that a patch to the build process (in Tools/msi/msi.py) would be contributed. -- Comment By: Martin v. Löwis (loewis) Date: 2005-09-27 20:03 Message: Logged In: YES user_id=21627 Including the PDB files in the MSI is probably not acceptable to the majority of the users. python24.pdb is 3.5MiB in size, so the MSI file to download would grow considerably. Why do you need the PDB file in the first place? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1303434&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1396258 ] KeyboardInterrupt prevents return to Windows console
Bugs item #1396258, was opened at 2006-01-03 13:04 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1396258&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: Threads Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Vernon Cole (kf7xm) Assigned to: Nobody/Anonymous (nobody) Summary: KeyboardInterrupt prevents return to Windows console Initial Comment: Environment: Python 2.4, Windows 2000 Professional, windows command prompt. Python is using a join(), waiting for threads to finish, when a KeyboardInterrupt occurs. (A KeyboardInterrupt handler is defined for the main thread.) The handler appears to work as expected, but control is never returned to Windows, leaving the console window unusable. Directions to reproduce bug: 1) run the attached program from a console prompt like: c:\mydir> threadingSample.py 2) when the program suggests, hit -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1396258&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1303434 ] Please include pdb with windows distribution
Feature Requests item #1303434, was opened at 2005-09-24 21:30 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1303434&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: None Status: Open Resolution: None Priority: 5 Submitted By: Lyle Thompson (lylefile) Assigned to: Nobody/Anonymous (nobody) Summary: Please include pdb with windows distribution Initial Comment: Checking out the source files and rebuilding is not guaranteed to build a program database (pdb) file that represents the distribution python DLL. This may be due to a differences in the windows version or visual studio service pack on my system vs the one used to build the distribution, but tracking it down can be very time consuming. Including the pdb in the distribution should be trivial and avoid this problem entirely. Although I can fix the problem for future releases of our product, I am also supporting previous releases that included the standard DLL included in the distribution. -- >Comment By: Martin v. Löwis (loewis) Date: 2006-01-03 23:01 Message: Logged In: YES user_id=21627 Just in case I wasn't clear in my last message: patches in that direction are appreciate; without a contributed patch, nothing will happen. -- Comment By: Lyle Thompson (lylefile) Date: 2006-01-03 20:06 Message: Logged In: YES user_id=1351115 A PDB file is required for debugging crash dumps from complex pythonic programs. This ability is absolutely critical for commercial programs using python. Technically, the crashes only happen within pyds or dlls, but it is often very vitally important to be able to find out what python code was being interpreted at the time. Unfortunately, I've even seen "pure" python crash in one of the supplied pyd's. Of course, the pdb file should be in a separate download, as few users require the ability to reverse engineer crash dumps. -- Comment By: Martin v. Löwis (loewis) Date: 2005-12-28 01:12 Message: Logged In: YES user_id=21627 Update: distribution in a separate zipfile would be possible, provided that a patch to the build process (in Tools/msi/msi.py) would be contributed. -- Comment By: Martin v. Löwis (loewis) Date: 2005-09-27 22:03 Message: Logged In: YES user_id=21627 Including the PDB files in the MSI is probably not acceptable to the majority of the users. python24.pdb is 3.5MiB in size, so the MSI file to download would grow considerably. Why do you need the PDB file in the first place? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1303434&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1396471 ] file.tell() returns illegal value on Windows
Bugs item #1396471, was opened at 2006-01-03 17:53
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=1396471&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 Goddard (tom_goddard)
Assigned to: Nobody/Anonymous (nobody)
Summary: file.tell() returns illegal value on Windows
Initial Comment:
The file tell() method returns an illegal value that causes an exception
when passed to seek(). This happens on Windows when a file that
contains unix-style newlines '\n' is opened and read in text mode 'r'.
Below is code that produces the problem on Windows 2.4.2 in an IDLE
shell.
The bug does not occur when using mode 'rU' or 'rb'. But I expect
correct behaviour with mode 'r'. My understanding is that 'rU'
translates line endings to '\n' in the returned string while mode 'r' still
correctly reads the lines using readline(), recognizing all 3 common
endline conventions, but does not translate (ie includes \n\r or \r or \n
in returned string).
The error in the tell() return value depends on how long the file is.
Changing the 'more\n'*10 line in the example code will cause different
incorrect return values.
Previous bug reports have mentioned problems with tell/seek when
using file iterators, the file.next() method and the "for line in file:"
construct. This bug is different and just involves readline() and tell()
with mode 'r'.
Example code tellbug.py follows:
wf = open('testdata', 'wb')
wf.write('01234\n56789\n'+ 'more\n'*10)
wf.close()
f = open('testdata', 'r')
f.readline()
t = f.tell()
print t
f.seek(t)
---
Running gives:
>>> execfile('tellbug.py')
-5
Traceback (most recent call last):
File "", line 1, in -toplevel-
execfile('tellbug.py')
File "tellbug.py", line 9, in -toplevel-
f.seek(t)
IOError: [Errno 22] Invalid argument
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1396471&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1396543 ] urlparse is confused by /
Bugs item #1396543, was opened at 2006-01-04 04:57
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=1396543&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: John Hansen (johnhansen)
Assigned to: Nobody/Anonymous (nobody)
Summary: urlparse is confused by /
Initial Comment:
If the parameter field of a URL contains a '/', urlparse does not enter date
in the parameter field, but leaves it attached to the path.
The simplified example is:
>>> urlparse.urlparse("http://f/adi;s=a;c=b/";)
('http', 'f', '/adi;s=a;c=b/', '', '', '')
>>> urlparse.urlparse("http://f/adi;s=a;c=b";)
('http', 'f', '/adi', 's=a;c=b', '', '')
The realworld case was:
>>> urlparse.urlparse("http://ad.doubleclick.net/adi/
N3691.VibrantMedia/B1733031.2;sz=160x600;click=http%3A/
adforce.adtech.de/adlink%7C82%7C59111%7C1%7C168%7CAdId%
3D1023327%3BBnId%3D4%3Bitime%3D335264036%3Bku%3D12900%
3Bkey%3Dcomputing%2Bbetanews%5Fgeneral%3Blink%3D")
(''http'', 'ad.doubleclick.net/adi/N3691.VibrantMedia/
B1733031.2;sz=160x600;click=http%3A/adforce.adtech.de/adlink%
7C82%7C59111%7C1%7C168%7CAdId%3D1023327%3BBnId%3D4%3Bitime
%3D335264036%3Bku%3D12900%3Bkey%3Dcomputing%2Bbetanews%
5Fgeneral%3Blink%3D', '', '', '')
What's odd is that the code specifically says to do this:
def _splitparams(url):
if '/' in url:
i = url.find(';', url.rfind('/'))
if i < 0:
return url, ''
Is there a reason for the rfind?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1396543&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1396543 ] urlparse is confused by /
Bugs item #1396543, was opened at 2006-01-04 04:57
Message generated for change (Comment added) made by johnhansen
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1396543&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: John Hansen (johnhansen)
Assigned to: Nobody/Anonymous (nobody)
Summary: urlparse is confused by /
Initial Comment:
If the parameter field of a URL contains a '/', urlparse does not enter date
in the parameter field, but leaves it attached to the path.
The simplified example is:
>>> urlparse.urlparse("http://f/adi;s=a;c=b/";)
('http', 'f', '/adi;s=a;c=b/', '', '', '')
>>> urlparse.urlparse("http://f/adi;s=a;c=b";)
('http', 'f', '/adi', 's=a;c=b', '', '')
The realworld case was:
>>> urlparse.urlparse("http://ad.doubleclick.net/adi/
N3691.VibrantMedia/B1733031.2;sz=160x600;click=http%3A/
adforce.adtech.de/adlink%7C82%7C59111%7C1%7C168%7CAdId%
3D1023327%3BBnId%3D4%3Bitime%3D335264036%3Bku%3D12900%
3Bkey%3Dcomputing%2Bbetanews%5Fgeneral%3Blink%3D")
(''http'', 'ad.doubleclick.net/adi/N3691.VibrantMedia/
B1733031.2;sz=160x600;click=http%3A/adforce.adtech.de/adlink%
7C82%7C59111%7C1%7C168%7CAdId%3D1023327%3BBnId%3D4%3Bitime
%3D335264036%3Bku%3D12900%3Bkey%3Dcomputing%2Bbetanews%
5Fgeneral%3Blink%3D', '', '', '')
What's odd is that the code specifically says to do this:
def _splitparams(url):
if '/' in url:
i = url.find(';', url.rfind('/'))
if i < 0:
return url, ''
Is there a reason for the rfind?
--
>Comment By: John Hansen (johnhansen)
Date: 2006-01-04 05:00
Message:
Logged In: YES
user_id=1418831
The first line should have read:
If the parameter field of a URL contains a '/', urlparse does not enter it
into the parameter field, but leaves it attached to the path.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1396543&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
