[ python-Bugs-1072404 ] Bugs in _csv module - lineterminator
Bugs item #1072404, was opened at 2004-11-24 12:00
Message generated for change (Comment added) made by fresh
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1072404&group_id=5470
Category: Python Library
Group: None
>Status: Open
>Resolution: None
>Priority: 1
Submitted By: Chris Withers (fresh)
Assigned to: Andrew McNamara (andrewmcnamara)
Summary: Bugs in _csv module - lineterminator
Initial Comment:
On trying to parse a '\r' terminated csv generated on a
Mac, I get a "newline inside string" error from the csv
module.
Two things sprung to mind having read:
http://cvs.sourceforge.net/viewcvs.py/python/python/dist/src/Modules/_csv.c?rev=1.15&view=markup
...for a bit.
1. The Dialect's lineterminator doesn't appear to be
used when parsing a CSV. This feels like a bug to be,
'cos I could specify the terminator if
Reader_iternext(ReaderObj *self) used it :-S
2. The processing in Reader_iternext(ReaderObj *self)
assumes that a '\r' will be followed by '\0' for Macs,
'\n' for windows, and anything else is an error.
but:
>>> c = open('var\data\metadata.csv').read()
>>> c[:100]
'BENEFIT,,Subjects relating to all benefits,AB
\rBENEFIT,PARTNERDIED,Bereavement
Should I be expecting to see a '\0' there?
Anyway, the real bug seems to be the reader's ignorance
of the lineterminator. However, even if my analysis is
off the mark, the problem still exists :-S
cheers,
Chris
--
>Comment By: Chris Withers (fresh)
Date: 2005-01-18 11:25
Message:
Logged In: YES
user_id=24723
I don't think its fair to close this as a rejection.
The documentation implies that you can control what line
terminator this module uses, which currently isn't the case.
I'm not saying this is a high priority issue, just that it
shouldn't be rejected in case some day someone (maybe even
me ;-) wants to haev a goat fixing it...
--
Comment By: Andrew McNamara (andrewmcnamara)
Date: 2005-01-13 04:14
Message:
Logged In: YES
user_id=698599
The reader expects to be supplied an iterator that returns lines - in this
case, the file iterator has not recognised \r as end-of-line and has read the
whole file in and yielded that as a "line". If you use universal-newline mode
on your source file, you should have more luck.
--
Comment By: Skip Montanaro (montanaro)
Date: 2004-11-25 04:23
Message:
Logged In: YES
user_id=44345
This is a known problem. See the April archives of the csv
mailing list:
http://manatee.mojam.com/pipermail/csv/2004-April/thread.html
Solutions are welcome. I suspect any solution will involve
either
discarding PyIter_Next altogether or further subdividing what it
returns.
A couple things to note in the way of workarounds:
1. Reader_iternext() defers to PyIter_Next() to grab the
next line,
so there's really no opportunity to interject the
lineterminator into
the operation with the current code. This means reading from
StringIO objects that use \r lineterminators will always fail.
2. If you have a real file as input and open it in universal
newline
mode you will get the correct behavior.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1072404&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1072404 ] Bugs in _csv module - lineterminator
Bugs item #1072404, was opened at 2004-11-24 23:00
Message generated for change (Comment added) made by andrewmcnamara
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1072404&group_id=5470
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 1
Submitted By: Chris Withers (fresh)
Assigned to: Andrew McNamara (andrewmcnamara)
Summary: Bugs in _csv module - lineterminator
Initial Comment:
On trying to parse a '\r' terminated csv generated on a
Mac, I get a "newline inside string" error from the csv
module.
Two things sprung to mind having read:
http://cvs.sourceforge.net/viewcvs.py/python/python/dist/src/Modules/_csv.c?rev=1.15&view=markup
...for a bit.
1. The Dialect's lineterminator doesn't appear to be
used when parsing a CSV. This feels like a bug to be,
'cos I could specify the terminator if
Reader_iternext(ReaderObj *self) used it :-S
2. The processing in Reader_iternext(ReaderObj *self)
assumes that a '\r' will be followed by '\0' for Macs,
'\n' for windows, and anything else is an error.
but:
>>> c = open('var\data\metadata.csv').read()
>>> c[:100]
'BENEFIT,,Subjects relating to all benefits,AB
\rBENEFIT,PARTNERDIED,Bereavement
Should I be expecting to see a '\0' there?
Anyway, the real bug seems to be the reader's ignorance
of the lineterminator. However, even if my analysis is
off the mark, the problem still exists :-S
cheers,
Chris
--
>Comment By: Andrew McNamara (andrewmcnamara)
Date: 2005-01-18 23:11
Message:
Logged In: YES
user_id=698599
This cannot be fixed with the current interface - the line splitting is being
done by the file iterator, and it only supports \r and \n. As I said, you'll
get
better results with universal newline mode.
The parser in Python 2.5 (the CVS HEAD) has been improved somewhat,
but it's still not possible to use anything other than \r and \n for
end-of-line.
The documentation has been updated to reflect this fact.
--
Comment By: Chris Withers (fresh)
Date: 2005-01-18 22:25
Message:
Logged In: YES
user_id=24723
I don't think its fair to close this as a rejection.
The documentation implies that you can control what line
terminator this module uses, which currently isn't the case.
I'm not saying this is a high priority issue, just that it
shouldn't be rejected in case some day someone (maybe even
me ;-) wants to haev a goat fixing it...
--
Comment By: Andrew McNamara (andrewmcnamara)
Date: 2005-01-13 15:14
Message:
Logged In: YES
user_id=698599
The reader expects to be supplied an iterator that returns lines - in this
case, the file iterator has not recognised \r as end-of-line and has read the
whole file in and yielded that as a "line". If you use universal-newline mode
on your source file, you should have more luck.
--
Comment By: Skip Montanaro (montanaro)
Date: 2004-11-25 15:23
Message:
Logged In: YES
user_id=44345
This is a known problem. See the April archives of the csv
mailing list:
http://manatee.mojam.com/pipermail/csv/2004-April/thread.html
Solutions are welcome. I suspect any solution will involve
either
discarding PyIter_Next altogether or further subdividing what it
returns.
A couple things to note in the way of workarounds:
1. Reader_iternext() defers to PyIter_Next() to grab the
next line,
so there's really no opportunity to interject the
lineterminator into
the operation with the current code. This means reading from
StringIO objects that use \r lineterminators will always fail.
2. If you have a real file as input and open it in universal
newline
mode you will get the correct behavior.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1072404&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1104608 ] Wrong expression with \w+?
Bugs item #1104608, was opened at 2005-01-18 17:49
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=1104608&group_id=5470
Category: Regular Expressions
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: rengel (engel_re)
Assigned to: Gustavo Niemeyer (niemeyer)
Summary: Wrong expression with \w+?
Initial Comment:
str = 'match the url www.junit.org with following regex'
regex = re.compile('(www\.\w+?\.\w+?)')
print regex.sub('\1', str)
# It produces
match the url www.junit.org
with following regex
# It should produce
match the url www.junit.org
with following regex
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1104608&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1104608 ] Wrong expression with \w+?
Bugs item #1104608, was opened at 2005-01-18 17:49
Message generated for change (Comment added) made by effbot
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1104608&group_id=5470
Category: Regular Expressions
Group: Python 2.4
>Status: Deleted
>Resolution: Wont Fix
Priority: 5
Submitted By: rengel (engel_re)
Assigned to: Gustavo Niemeyer (niemeyer)
Summary: Wrong expression with \w+?
Initial Comment:
str = 'match the url www.junit.org with following regex'
regex = re.compile('(www\.\w+?\.\w+?)')
print regex.sub('\1', str)
# It produces
match the url www.junit.org
with following regex
# It should produce
match the url www.junit.org
with following regex
--
>Comment By: Fredrik Lundh (effbot)
Date: 2005-01-18 18:23
Message:
Logged In: YES
user_id=38376
No, it shouldn't. "+?" means the shortest possible match
that's one character or more. If you want the longest
possible match, get rid of the "?".
(in this case, I'd use "(www[.\w]*)")
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1104608&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1104608 ] Wrong expression with \w+?
Bugs item #1104608, was opened at 2005-01-18 16:49
Message generated for change (Comment added) made by niemeyer
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1104608&group_id=5470
Category: Regular Expressions
Group: Python 2.4
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: rengel (engel_re)
Assigned to: Gustavo Niemeyer (niemeyer)
Summary: Wrong expression with \w+?
Initial Comment:
str = 'match the url www.junit.org with following regex'
regex = re.compile('(www\.\w+?\.\w+?)')
print regex.sub('\1', str)
# It produces
match the url www.junit.org
with following regex
# It should produce
match the url www.junit.org
with following regex
--
>Comment By: Gustavo Niemeyer (niemeyer)
Date: 2005-01-18 17:25
Message:
Logged In: YES
user_id=7887
There's nothing wrong with this result. You asked for a non-greedy match
(you've used '\w+?', not '\w+'), and SRE gave you the minimum possible
match.
--
Comment By: Fredrik Lundh (effbot)
Date: 2005-01-18 17:23
Message:
Logged In: YES
user_id=38376
No, it shouldn't. "+?" means the shortest possible match
that's one character or more. If you want the longest
possible match, get rid of the "?".
(in this case, I'd use "(www[.\w]*)")
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1104608&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1100368 ] Wrong "type()" syntax in docs
Bugs item #1100368, was opened at 2005-01-11 14:03 Message generated for change (Comment added) made by cjwhrh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1100368&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Facundo Batista (facundobatista) Assigned to: Nobody/Anonymous (nobody) Summary: Wrong "type()" syntax in docs Initial Comment: >From the current docs: type(object): Return the type of an object. The return value is a type object. >From the interpreter: >>> help(type) Help on class type in module __builtin__: class type(object) | type(object) -> the object's type | type(name, bases, dict) -> a new type In the documentation is missing the second syntax form. -- Comment By: Colin J. Williams (cjwhrh) Date: 2005-01-18 17:03 Message: Logged In: YES user_id=285587 The accuracy of the above depends partly on the context. Within a function or method which has "type" as a parameter the type function described above is no longer accessible. Colin W. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1100368&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1104923 ] Bug in String rstrip method
Bugs item #1104923, was opened at 2005-01-18 17:58
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=1104923&group_id=5470
Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Rick Coupland (rcouplan)
Assigned to: Nobody/Anonymous (nobody)
Summary: Bug in String rstrip method
Initial Comment:
There appears to be a data sensitive bug in the string rstrip
method as demonstrated by the following code:
>>> "ecigrcal.fle".rstrip(".fle")
'ecigrca'
As you can see, it is striping an extra character.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1104923&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1104923 ] Bug in String rstrip method
Bugs item #1104923, was opened at 2005-01-18 19:58
Message generated for change (Comment added) made by dsm001
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1104923&group_id=5470
Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Rick Coupland (rcouplan)
Assigned to: Nobody/Anonymous (nobody)
Summary: Bug in String rstrip method
Initial Comment:
There appears to be a data sensitive bug in the string rstrip
method as demonstrated by the following code:
>>> "ecigrcal.fle".rstrip(".fle")
'ecigrca'
As you can see, it is striping an extra character.
--
Comment By: DSM (dsm001)
Date: 2005-01-18 20:51
Message:
Logged In: YES
user_id=1175690
I don't think this is a bug. The documentation for the
rstrip method reads:
rstrip(...)
S.rstrip([chars]) -> string or unicode
Return a copy of the string S with trailing whitespace
removed.
If chars is given and not None, remove characters in
chars instead.
When you pass the method ".rle", you're telling it to treat
the four characters ".", "r", "l", and "e" as trailing
whitespace and remove them from the right side of the
string. That's why it removes the extra "l".
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1104923&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1104923 ] Bug in String rstrip method
Bugs item #1104923, was opened at 2005-01-18 19:58
Message generated for change (Comment added) made by tim_one
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1104923&group_id=5470
Category: Python Library
>Group: Not a Bug
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Rick Coupland (rcouplan)
Assigned to: Nobody/Anonymous (nobody)
Summary: Bug in String rstrip method
Initial Comment:
There appears to be a data sensitive bug in the string rstrip
method as demonstrated by the following code:
>>> "ecigrcal.fle".rstrip(".fle")
'ecigrca'
As you can see, it is striping an extra character.
--
>Comment By: Tim Peters (tim_one)
Date: 2005-01-18 20:56
Message:
Logged In: YES
user_id=31435
Yes, dsm001 is right. The argument is treated as a _set_ of
characters to be stripped, not as a literal string. This is a
natural generalization of .rstrip() without any characters,
which chops off all whitespace characters (no matter how
many there, and no matter what order they appear in).
Passing an argument just changes the set of characters it
deletes.
--
Comment By: DSM (dsm001)
Date: 2005-01-18 20:51
Message:
Logged In: YES
user_id=1175690
I don't think this is a bug. The documentation for the
rstrip method reads:
rstrip(...)
S.rstrip([chars]) -> string or unicode
Return a copy of the string S with trailing whitespace
removed.
If chars is given and not None, remove characters in
chars instead.
When you pass the method ".rle", you're telling it to treat
the four characters ".", "r", "l", and "e" as trailing
whitespace and remove them from the right side of the
string. That's why it removes the extra "l".
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1104923&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-900580 ] IDLE docs broken on OSX
Bugs item #900580, was opened at 2004-02-19 14:59 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=900580&group_id=5470 Category: IDLE Group: Python 2.3 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Jonathan Brandmeyer (jbrandmeyer) Assigned to: Kurt B. Kaiser (kbk) Summary: IDLE docs broken on OSX Initial Comment: Under Apple's OSX operating system, the variable sys.platform is named'darwin'. In at least one place, idle makes a test to see if thecurrent platform is MS Windows by checking for the substring 'win' insys.platform, which leads to incorrect behavior on the Mac. In particular, in lib/python2.3/idlelib/EditorWindow.py, member function EditorWindow.python_docs() behaves incorrectly on OS X. I believe that if the test for MS Windows is completely removed that you will get correct behavior on all platforms, based on my reading of the webbrowser module source. Please change that function to the following (near line 313): >>>def python_docs(self, event=None): >>>webbrowser.open(self.help_url) >>>return "break" -- >Comment By: Kurt B. Kaiser (kbk) Date: 2005-01-18 23:25 Message: Logged In: YES user_id=149084 Backported to 2.3.5 -- Comment By: Kurt B. Kaiser (kbk) Date: 2004-07-15 00:01 Message: Logged In: YES user_id=149084 EditorWindow.py 1.60 configHelpSourceEdit.py 1.7 Backport candidate. Please test on Mac. -- Comment By: Jonathan Brandmeyer (jbrandmeyer) Date: 2004-03-02 14:06 Message: Logged In: YES user_id=676765 There are a series of changes related to the one I mentioned before. In addition, Safari requires the full URI to local files when started via the webbrowser module (or via several other methods) even though it automatically prepends that string when entered in the address bar. So, I have an additional patch that makes appropriate modifications for file:/// prefixed paths. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=900580&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1102649 ] pickle files should be opened in binary mode
Bugs item #1102649, was opened at 2005-01-14 16:58 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1102649&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: John Machin (sjmachin) Assigned to: Nobody/Anonymous (nobody) Summary: pickle files should be opened in binary mode Initial Comment: pickle (and cPickle): At _each_ mention of the pickle file, the docs should say that it should be opened with 'wb' or 'rb' mode as appropriate, so that a pickle written on one OS can be read reliably on another. The example code at the end of the section should be updated to use the 'b' flag. -- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-01-19 00:06 Message: Logged In: YES user_id=3066 Is this true in all cases? Shouldn't files containing text pickles (protocol 0) be opened in text mode? (A problem, given that all protocols should be readable without prior knowledge of the protocol used to write the pickle.) -- Comment By: Irmen de Jong (irmen) Date: 2005-01-16 10:07 Message: Logged In: YES user_id=129426 Can't the pickle code just freopen() the file itself, using binary mode? Or is this against Python's rule "explicit is better than implicit" -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1102649&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1102649 ] pickle files should be opened in binary mode
Bugs item #1102649, was opened at 2005-01-14 16:58 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1102649&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: John Machin (sjmachin) Assigned to: Nobody/Anonymous (nobody) Summary: pickle files should be opened in binary mode Initial Comment: pickle (and cPickle): At _each_ mention of the pickle file, the docs should say that it should be opened with 'wb' or 'rb' mode as appropriate, so that a pickle written on one OS can be read reliably on another. The example code at the end of the section should be updated to use the 'b' flag. -- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-01-19 00:09 Message: Logged In: YES user_id=3066 In response to irmin's comment: freopen() is only an option for real file objects; pickles are often stored or read from other sources. These other sources are usually binary to begin with, fortunately, though this issue probably deserves some real coverage in the documentation either way. -- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-01-19 00:06 Message: Logged In: YES user_id=3066 Is this true in all cases? Shouldn't files containing text pickles (protocol 0) be opened in text mode? (A problem, given that all protocols should be readable without prior knowledge of the protocol used to write the pickle.) -- Comment By: Irmen de Jong (irmen) Date: 2005-01-16 10:07 Message: Logged In: YES user_id=129426 Can't the pickle code just freopen() the file itself, using binary mode? Or is this against Python's rule "explicit is better than implicit" -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1102649&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-853800 ] No documentation for zipimport module
Bugs item #853800, was opened at 2003-12-03 22:35 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=853800&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Tony Meyer (anadelonbrin) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: No documentation for zipimport module Initial Comment: It doesn't appear that the zipimport module is documented in Python 2.3.2, apart from a note in the "what's new in Python 2.3" section. It should really be in the list of all standard modules. Presumably the help(zipimport) contents could form the basis of this documentation. I'd be willing to put a patch together for this if someone gives me clear guidelines about what should be there. -- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-01-19 01:04 Message: Logged In: YES user_id=3066 Committed modified patch for the trunk, release24-maint, and release23-maint branches. -- Comment By: Tony Meyer (anadelonbrin) Date: 2004-02-16 21:44 Message: Logged In: YES user_id=552329 New version with correct PEP references. -- Comment By: Tony Meyer (anadelonbrin) Date: 2004-02-16 19:56 Message: Logged In: YES user_id=552329 Well, it's been two months (setting up latex2html on cygwin isn't easy! ), but here's something. Attached is a draft module doc for zipimport, and a diff to add it to the library (I wasn't really sure where it belonged, so this diff might be no good it's only one line, anyway). The documentation is a combination of the docstrings, stuff from the PEP, and stuff from the "what's new in 2.3" page. Hope it's ok. -- Comment By: Just van Rossum (jvr) Date: 2003-12-07 12:55 Message: Logged In: YES user_id=92689 The doc strings should indeed be a good start. See also http:// python.org/peps/pep-0273.html and http://python.org/peps/pep- 0302.html for way more details than neccesary for the docs. Feel free to concact me off line if you have more questions; your offer is most welcome! -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=853800&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1103926 ] email.base64MIME.header_encode vs RFC 1522
Bugs item #1103926, was opened at 2005-01-17 09:45 Message generated for change (Settings changed) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1103926&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Ucho (ucho) >Assigned to: Barry A. Warsaw (bwarsaw) Summary: email.base64MIME.header_encode vs RFC 1522 Initial Comment: i have a question about email.base64MIME.header_encode. It returns something like: =?iso-8859-2?b?. Shouldn't it be "B" instead "b" ? RFC 1522 says it can be only "Q" or "B" -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1103926&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1093173 ] distutils/tests not installed
Bugs item #1093173, was opened at 2004-12-30 04:43 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1093173&group_id=5470 Category: Python Library Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Armin Rigo (arigo) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: distutils/tests not installed Initial Comment: The new subdirectory distutils/tests is not copied to the installation location by a 'make install'. This causes test_distutils to crash when run from an installed path (as opposed to from a CVS check-out). I could propose a patch (Makefile.pre.in) given some bash syntax learning efforts -- for example, distutils/tests shouldn't be installed if we want a no-test installation. This raises the question about why distutils/tests isn't actually called test/distutils... -- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-01-19 01:25 Message: Logged In: YES user_id=3066 Committed the patch on the trunk and release24-maint branch (Makefile.pre.in revisions 1.150, 1.148.2.1.) Yes, distutils.tests should have been distutils.test for consistency; sorry. Habits die hard, though, and we use "tests" at work. -- Comment By: Armin Rigo (arigo) Date: 2005-01-09 09:03 Message: Logged In: YES user_id=4771 Attachment was corrupted?? Second try... -- Comment By: Armin Rigo (arigo) Date: 2005-01-09 08:55 Message: Logged In: YES user_id=4771 Patch attached. -- Comment By: Armin Rigo (arigo) Date: 2005-01-09 08:53 Message: Logged In: YES user_id=4771 Patch attached. -- Comment By: Martin v. Löwis (loewis) Date: 2004-12-30 09:11 Message: Logged In: YES user_id=21627 Please do try to come up with a patch. I'm not sure I understand the no-test business - there is no no-test installation AFAICT; adding it to LIBSUBDIRS might be sufficient. The Windows installer has the notion of no-test installs; it did always package distutils/tests, but now also conditionalizes installation on the selection of the testsuite. As for choice of location of the tests: both bsddb and email have their own test directories, both because they contain a large number of tests, and because they are both packaged independently of Python. The same could be said about distutils. As for the choice of name: it is called "test" in all other cases, only "tests" for distutils. This is unfortunate, but changing directories in CVS does more harm than good. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1093173&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1097834 ] urllib2 doesn't handle urls without a scheme
Bugs item #1097834, was opened at 2005-01-07 07:49 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1097834&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 doesn't handle urls without a scheme Initial Comment: Unlike urllib, urllib2 does not handle "/path/to/file" style urls (without a scheme) as "file:" urls. I'm not sure whether this is a bug per se, but if this behaviour is by design then urllib2 should get a pathname2url() method that changes a pathname to a "file:"-prefixed url. urllib.pathname2url() does not prefix the url, but that's fine because urllib.urlopen() treats urls without schemes as file: urls. -- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-01-19 01:33 Message: Logged In: YES user_id=3066 There's no such thing as a URL without a scheme, regardless of what browsers do. The best thing to do is to determine the "base" to which a relative URL reference (whcih can have the scheme omitted) should be resolved, and join the base and relative URL reference using urlparse.urljoin(base, rel). Closing as "not a bug". urllib.pathname2url() is a problem in it's own right; it doesn't behave consistently across Windows and Unix. On Windows, pathname2url() returns too many slashes, or it returns too few on Unix. I've been using helper functions that hide that difference. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1097834&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-839709 ] Windows non-MS compiler doc updates
Bugs item #839709, was opened at 2003-11-10 21:47 Message generated for change (Settings changed) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=839709&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Mike Brown (mike_j_brown) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Windows non-MS compiler doc updates Initial Comment: Documents affected: http://www.python.org/doc/2.3.2/inst/tweak-flags.html sec. 6.2.2 http://www.python.org/doc/2.3.1/inst/tweak-flags.html sec. 6.2.2 http://www.python.org/doc/2.3/inst/tweak-flags.html sec. 6.2.2 http://www.python.org/doc/2.2.3/inst/non-ms- compilers.html sec. 3.1.2 http://www.python.org/doc/2.2.2/inst/non-ms- compilers.html sec. 3.1.2 http://www.python.org/doc/2.2.1/inst/non-ms- compilers.html sec. 3.1.2 http://www.python.org/doc/2.2/inst/non-ms- compilers.html sec. 3.1.2 http://www.python.org/doc/2.1.3/inst/non-ms- compilers.html sec. 3.1.2 http://www.python.org/doc/2.1.2/inst/non-ms- compilers.html sec. 3.1.2 http://www.python.org/doc/2.1.1/inst/non-ms- compilers.html sec. 3.1.2 http://www.python.org/doc/2.1/inst/tweak-flags.html sec. 3.1.2 1. Filenames in the examples are way out of date. It is also not clear to the reader that python23.dll is located in %SystemRoot%\System32. I suggest that you change the pexports command line example to pexports \Windows\System32\python23.dll > python23.def In the Python 2.2 docs, use python22.dll and python22.def. In the Python 2.1 docs, use python21.dll and python21.def. 2. It's not clear to the reader where dlltool is. dlltool can also output directly to the right directory. I suggest that you change the dlltool command line example to \cygwin\bin\dlltool --dllname python23.dll --def python23.def --output-lib \Python23\Libs\libpython23.a In the Python 2.2 docs, use python22.dll, python22.def, and libpython22.a. In the Python 2.1 docs, use python21.dll, python21.def and libpython21.a. 3. Another filename out of date. I suggest that you change "The resulting library has to be placed in the same directory as python20.lib." to "The resulting library has to be placed in the same directory as python23.lib." In the Python 2.2 docs, use python22.lib. In the Python 2.1 docs, use python21.lib. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=839709&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-973579 ] Doc error on super(cls,self)
Bugs item #973579, was opened at 2004-06-15 18:43 Message generated for change (Settings changed) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=973579&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: David MacQuigg (macquigg) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Doc error on super(cls,self) Initial Comment: In both the Library Reference, section 2.1, and in the Python 2.2 Quick Reference, page 19, the explanation for this function is: super( type[, object-or-type]) Returns the superclass of type. ... This is misleading. I could not get this function to work right until I realized that it is searching the entire MRO, not just the superclasses of 'type'. See comp.lang.python 6/11/04, same subject as above, for further discussion and an example. I think a better explanation would be: super(cls,self).m(arg) Calls method 'm' from a class in the MRO (Method Resolution Order) of 'self'. The selected class is the first one which is above 'cls' in the MRO and which contains 'm'. The 'super' built-in function actually returns not a class, but a 'super' object. This object can be saved, like a bound method, and later used to do a new search of the MRO for a different method to be applied to the saved instance. -- Comment By: David MacQuigg (macquigg) Date: 2004-07-21 11:20 Message: Logged In: YES user_id=676422 While waiting for the perfect solution, would it be possible to have links to this item at the places in the documentation where the corrections should be made (Library Reference 2.1, Quick Reference page 19)? It could save an hour of experimentation for each new user of this feature. -- Comment By: David MacQuigg (macquigg) Date: 2004-06-21 12:23 Message: Logged In: YES user_id=676422 I like the example, but the new explanation still leaves the impression that super() returns a class ( or something that acts like a class). This is what made super() so difficult to figure out the first time I tried it. The 'super' object returned by the function appears to be a collection of references, one to the 'self' instance, and one to each of the classes in the MRO of self above 'cls'. The reason it can't be just a class is that a given super object needs to retrieve a different class each time it is used, depending on what method is provided. The only thing lacking in the example is motivation for why we need super(B,self).meth(arg) instead of just calling C.meth (self,arg). I have a longer example and some motivation on page 16 in my OOP chapter at http://ece.arizona.edu/~edatools/Python/PythonOOP.doc but that may be too long if what we need here is a "man page" explanation. -- Comment By: Jim Jewett (jimjjewett) Date: 2004-06-21 10:50 Message: Logged In: YES user_id=764593 Would an expanded example also help? I'm not sure I like my own wording yet, but ... I propose it as a straw man. """super returns the next parent class[1] class A(object): pass class B(A): def meth(self, arg): super(B, self).meth(arg) class C(A): pass class D(B, C): pass d=D() d.meth() In this case, the super(B, self) call will actually return a reference to class C. Class C is not a parent of class B, but it is the next parent for this particular instance d of class B. [1] Actually, a super class mimicing the parent class. """ -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=973579&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1064535 ] IDLE doesn't start again when saving empty key set
Bugs item #1064535, was opened at 2004-11-11 10:06 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1064535&group_id=5470 Category: IDLE Group: Python 2.4 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Hernan Martinez Foffani (hfoffani) Assigned to: Kurt B. Kaiser (kbk) Summary: IDLE doesn't start again when saving empty key set Initial Comment: To reproduce: - Start IDLE - Go to Options/Configure IDLE/Keys - Click in "Save as New..." *without selecting anything before* - Enter any name in the textbox. - Ok/Apply/Ok - Close IDLE. IDLE doesn't start again. Workaround: - delete the user's .idlerc/config-main.cfg file Python 2.3.4 Windows 2000 pro Spanish version. -- >Comment By: Kurt B. Kaiser (kbk) Date: 2005-01-19 02:21 Message: Logged In: YES user_id=149084 Backported to 2.3.5 -- Comment By: Kurt B. Kaiser (kbk) Date: 2004-11-16 16:33 Message: Logged In: YES user_id=149084 configDialog.py 1.60 -- Comment By: Hernan Martinez Foffani (hfoffani) Date: 2004-11-11 10:41 Message: Logged In: YES user_id=112690 The same behaviour is happening if you select a key from the list before saving. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1064535&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1008998 ] vertical bar typeset horizontal in docs
Bugs item #1008998, was opened at 2004-08-13 18:30
Message generated for change (Comment added) made by fdrake
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1008998&group_id=5470
Category: Documentation
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Alan (aisaac0)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: vertical bar typeset horizontal in docs
Initial Comment:
I noticed a bug in the PDF version of the Python 2.3 docs.
The PDF production tries to typeset the vertical bar
'|' in textmode. An example of this problem is the
documentation for set union, which looks like s--t instead
of s|t.
To typeset the vertical bar either
i. use $|$
ii. use \texttt{|}
or
iii. change the encoding
--
>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2005-01-19 02:24
Message:
Logged In: YES
user_id=3066
Fixed in Doc/lib/libsets.tex revisions 1.16, 1.15.4.1,
1.11.16.4.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1008998&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
