[ python-Bugs-1371247 ] locale.windows_locale
Bugs item #1371247, was opened at 2005-12-01 22:50 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1371247&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: Platform-specific >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Greg Hazel (ghazel) Assigned to: Nobody/Anonymous (nobody) Summary: locale.windows_locale Initial Comment: from locale.py: # # this maps windows language identifiers (as used on Windows 95 and # earlier) to locale strings. # # NOTE: this mapping is incomplete. If your language is missing, please # submit a bug report to Python bug manager, which you can find via: # http://www.python.org/dev/ # Make sure you include the missing language identifier and the suggested # locale code. # The complete mapping table can be found here: http://www.dx21.com/SCRIPTING/VBSCRIPT/LCID.ASP -- >Comment By: Georg Brandl (birkenfeld) Date: 2006-01-20 10:08 Message: Logged In: YES user_id=1188172 Thanks, fixed in rev 42100, 42101. -- Comment By: Peter van Kampen (pterk) Date: 2006-01-14 23:40 Message: Logged In: YES user_id=174455 See patch 1406159: http://sourceforge.net/tracker/index.php?func=detail&aid=1406159&group_id=5470&atid=305470 -- Comment By: Greg Hazel (ghazel) Date: 2005-12-01 23:30 Message: Logged In: YES user_id=731668 I believe there's a small typo in that page. Spanish 1034 says hex 0x0C0A when hex(1034) is 0x040A The rest seems correct (hex and int values match). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1371247&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-04 02:53
Message generated for change (Comment added) made by birkenfeld
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: Closed
>Resolution: Fixed
Priority: 7
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
--
>Comment By: Georg Brandl (birkenfeld)
Date: 2006-01-20 10:15
Message:
Logged In: YES
user_id=1188172
Documented as a Windows bug in revisions 42102,42103.
--
Comment By: Peter van Kampen (pterk)
Date: 2006-01-16 04:24
Message:
Logged In: YES
user_id=174455
I have done some additional research on this.
It appears the bug is in ftell of the windows c-library and
it seems to be a 'known problem'. See:
http://www.mathworks.com/access/helpdesk/help/techdoc/ref/ftell.html
More here:
http://www.cygwin.com/faq/faq.api.html
http://gnuwin32.sourceforge.net/compile.html (search for
ftell in both cases)
Also see:
http://sourceforge.net/tracker/index.php?func=detail&aid=1381717&group_id=5470&atid=105470
So even though the file isn't opened with 'rt' I gather from
Tim Peter's remark about 't' on windows that the default is
't' anyway unless you really try.
So this example is *exactly* what the matlab-people found.
That is nice to know I guess but it doesn't really help to
solve the problem.
It seems to me there are three solutions.
1. ftell could be fixed for unix-files on windows.* Not very
likely to happen soon.
2. Python could special-case this for this specific
scenario. Way beyond my capabilities and probably too much
hassle in any case especially since the 'fix' is so easy
(just open with 'rb').
3. Leave it as is but document it. I have submitted a
(doc-)patch 1407021
(http://sourceforge.net/tracker/index.php?func=detail&aid=1407021&group_id=5470&atid=305470)
for the library reference (libstdtypes.tex) that reads:
Please note that tell() can return illegal values (after an
fgets()) on Windows when reading files with UNIX-style
line-endings. Use 'rb'-mode to circumvent this
problem.
* MS provides this note in the compatibility section of the
c-runtime libraries: "Note: In this version of Visual C++,
UNIX compatibility information has been removed from the
function descriptions."
In case your wondering what 'this version' is: VS.NET and VS
6.0. Apperantly there were no other 'previous versions'.
--
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-1349106 ] email.Generators does not separates headers with "\r\n"
Bugs item #1349106, was opened at 2005-11-05 16:50 Message generated for change (Comment added) made by manlioperillo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1349106&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: None Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: Manlio Perillo (manlioperillo) Assigned to: Barry A. Warsaw (bwarsaw) Summary: email.Generators does not separates headers with "\r\n" Initial Comment: Regards. The email.Generator module does not separates headers with "\r\n". Manlio Perillo -- >Comment By: Manlio Perillo (manlioperillo) Date: 2006-01-20 10:05 Message: Logged In: YES user_id=1054957 But the generator does not output in native line endings! On Windows: >>> from email.Message import Message >>> msg = Message() >>> msg["From"] = "me" >>> msg["To"] = "you" >>> print repr(msg.as_string()) 'From: me\nTo: you\n\n' -- Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-01-17 23:47 Message: Logged In: YES user_id=12800 I hear what you're saying, but so far, it has been more convenient for developers when the generator outputs native line endings. I can see a case for a flag or other switch on the Generator instance to force RFC 2822 line endings. I would suggest joining the email-sig and posting a request there so the issue can be discussed as an RFE. -- Comment By: Manlio Perillo (manlioperillo) Date: 2006-01-17 16:26 Message: Logged In: YES user_id=1054957 I do not agree here (but I'm not an expert). First - the documentation says: """The email package attempts to be as RFC-compliant as possible, supporting in addition to RFC 2822, such MIME-related RFCs as RFC 2045, RFC 2046, RFC 2047, and RFC 2231. """ But, as I can see, the generated email does not conform to RFC 2822. Second - I use email package as a "filter". read raw email text, do some processing, generate raw email text. Really, I don't understand why generated headers don't are separed by '\r\n' and one must rely on an external tool for the right conversion. Thanks. -- Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-01-17 12:54 Message: Logged In: YES user_id=12800 The module that speaks the wire protocol should do the conversion. IMO, there's no other way to guarantee that you're RFC compliant. You could be getting your data from the email package, but you could be getting it from anywhere else, and /that/ source may not be RFC line ended either. Since you can't change every possible source of data for NNTP or SMTP, your network interface must guarantee conformance. -- Comment By: Manlio Perillo (manlioperillo) Date: 2006-01-17 09:20 Message: Logged In: YES user_id=1054957 Ok, thanks. But what if I don't use the smtplib module? I discovered the bug because I have written a small NNTP server with twisted, using email module for parsing... -- Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-01-17 05:35 Message: Logged In: YES user_id=12800 Correct; this is by design. If you're worried about protocols such as RFC 2821 requiring \r\n line endings, don't. The smtplib module automatically ensures proper line endings for the on-the-wire communication. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1349106&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 20:53
Message generated for change (Comment added) made by tim_one
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: Closed
Resolution: Fixed
Priority: 7
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
--
>Comment By: Tim Peters (tim_one)
Date: 2006-01-20 10:35
Message:
Logged In: YES
user_id=31435
Well, it's not a Windows bug. Platforms are allowed to
insist on just about any restrictions they like for text
files, and it's on the user's head if they open a non-text
file in text mode. The C standard leaves all behavior
undefined in such cases. Text files on Windows have \r\n
line ends, and Windows isn't required to do anything in
particular if a file with even one \n line end is opened in
text mode. It so happens that a lot of things work the same
way they work on Linux anyway, but not all.
--
Comment By: Georg Brandl (birkenfeld)
Date: 2006-01-20 04:15
Message:
Logged In: YES
user_id=1188172
Documented as a Windows bug in revisions 42102,42103.
--
Comment By: Peter van Kampen (pterk)
Date: 2006-01-15 22:24
Message:
Logged In: YES
user_id=174455
I have done some additional research on this.
It appears the bug is in ftell of the windows c-library and
it seems to be a 'known problem'. See:
http://www.mathworks.com/access/helpdesk/help/techdoc/ref/ftell.html
More here:
http://www.cygwin.com/faq/faq.api.html
http://gnuwin32.sourceforge.net/compile.html (search for
ftell in both cases)
Also see:
http://sourceforge.net/tracker/index.php?func=detail&aid=1381717&group_id=5470&atid=105470
So even though the file isn't opened with 'rt' I gather from
Tim Peter's remark about 't' on windows that the default is
't' anyway unless you really try.
So this example is *exactly* what the matlab-people found.
That is nice to know I guess but it doesn't really help to
solve the problem.
It seems to me there are three solutions.
1. ftell could be fixed for unix-files on windows.* Not very
likely to happen soon.
2. Python could special-case this for this specific
scenario. Way beyond my capabilities and probably too much
hassle in any case especially since the 'fix' is so easy
(just open with 'rb').
3. Leave it as is but document it. I have submitted a
(doc-)patch 1407021
(http://sourceforge.net/tracker/index.php?func=detail&aid=1407021&group_id=5470&atid=305470)
for the library reference (libstdtypes.tex) that reads:
Please note that tell() can return illegal values (after an
fgets()) on Windows when reading files with UNIX-style
line-endings. Use 'rb'-mode to circumvent this
problem.
* MS provides this note in the compatibility section of the
c-runtime libraries: "Note: In this version of Visual C++,
UNIX compatibility information has been removed from the
function descriptions."
In case your wondering what 'this version' is: VS.NET and VS
6.0. Apperantly there were no other 'previous versions'.
[ python-Bugs-1396471 ] file.tell() returns illegal value on Windows
Bugs item #1396471, was opened at 2006-01-04 02:53
Message generated for change (Comment added) made by birkenfeld
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: Closed
Resolution: Fixed
Priority: 7
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
--
>Comment By: Georg Brandl (birkenfeld)
Date: 2006-01-20 18:04
Message:
Logged In: YES
user_id=1188172
Acknowledged. I didn't use the word "bug" in the note anyway.
--
Comment By: Tim Peters (tim_one)
Date: 2006-01-20 16:35
Message:
Logged In: YES
user_id=31435
Well, it's not a Windows bug. Platforms are allowed to
insist on just about any restrictions they like for text
files, and it's on the user's head if they open a non-text
file in text mode. The C standard leaves all behavior
undefined in such cases. Text files on Windows have \r\n
line ends, and Windows isn't required to do anything in
particular if a file with even one \n line end is opened in
text mode. It so happens that a lot of things work the same
way they work on Linux anyway, but not all.
--
Comment By: Georg Brandl (birkenfeld)
Date: 2006-01-20 10:15
Message:
Logged In: YES
user_id=1188172
Documented as a Windows bug in revisions 42102,42103.
--
Comment By: Peter van Kampen (pterk)
Date: 2006-01-16 04:24
Message:
Logged In: YES
user_id=174455
I have done some additional research on this.
It appears the bug is in ftell of the windows c-library and
it seems to be a 'known problem'. See:
http://www.mathworks.com/access/helpdesk/help/techdoc/ref/ftell.html
More here:
http://www.cygwin.com/faq/faq.api.html
http://gnuwin32.sourceforge.net/compile.html (search for
ftell in both cases)
Also see:
http://sourceforge.net/tracker/index.php?func=detail&aid=1381717&group_id=5470&atid=105470
So even though the file isn't opened with 'rt' I gather from
Tim Peter's remark about 't' on windows that the default is
't' anyway unless you really try.
So this example is *exactly* what the matlab-people found.
That is nice to know I guess but it doesn't really help to
solve the problem.
It seems to me there are three solutions.
1. ftell could be fixed for unix-files on windows.* Not very
likely to happen soon.
2. Python could special-case this for this specific
scenario. Way beyond my capabilities and probably too much
hassle in any case especially since the 'fix' is so easy
(just open with 'rb').
3. Leave it as is but document it. I have submitted a
(doc-)patch 1407021
(http://sourceforge.net/tracker/index.php?func=detail&aid=1407021&group_id=5470&atid=305470)
for the library reference (libstdtypes.tex) that reads:
Please note that tell() can return illegal values (after an
fgets()) on Windows when reading files with UNIX-style
line-endings. Use 'rb'-mode to circumvent this
problem.
* MS provides this note in the compatibility section of the
c-runtime libraries: "Note: In this
[ python-Bugs-1163367 ] correct/clarify documentation for super
Bugs item #1163367, was opened at 2005-03-15 00:39 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163367&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Steven Bethard (bediviere) Assigned to: Nobody/Anonymous (nobody) Summary: correct/clarify documentation for super Initial Comment: The current documentation for super is confusing. For instance, it says that it returns "the superclass of type" which is incorrect; it actually returns the next type in type's MRO. Well, to be truthful, it doesn't even do that; it returns a proxy object which makes that type's attributes available, but that's just another reason to fix the documentation. I suggest changing the wording to something like: """super(type[, object-or-type]) Return an object that exposes the attributes available through the type's superclasses, without exposing the attributes of the type itself. Attributes will be looked up using the normal resolution order, omitting the first class in the MRO (that is, the type itself). If the second argument is present, it should either be an instance of object, in which case isinstance(object-or-type, type) must be true, or it should be an instance of type, in which case issubclass(object-or-type, type) must be true. The typical use for this form of super is to call a cooperative superclass method: class C(B): def meth(self, arg): super(C, self).meth(arg) If the second argument to super is omitted, the super object returned will not expose any attributes directly. However, attributes will be accessible whenever the descriptor machinery is invoked, e.g. though explicit invocation of __get__. Note that super is undefined for implicit lookups using statements or operators such as "super(C, self)[name]". These must be spelled out with their explicit lookup, e.g. "super(C, self).__getitem__(name)". New in version 2.2. """ It's not perfect and I welcome suggestions for re-wording, but I think it's substantially more accurate about what super actually does. It also moves the "second argument omitted" situation to the end, since this is a vastly more uncommon use case. -- >Comment By: Georg Brandl (birkenfeld) Date: 2006-01-20 18:06 Message: Logged In: YES user_id=1188172 See also Bug #973579 (which I closed as duplicate) for alternative wording. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163367&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-16 00:43 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=973579&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None >Status: Closed >Resolution: Duplicate 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: Georg Brandl (birkenfeld) Date: 2006-01-20 18:07 Message: Logged In: YES user_id=1188172 #1163367 suggests a more complete new wording. Closing as duplicate. -- Comment By: David MacQuigg (macquigg) Date: 2004-07-21 17: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 18: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 16: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-1163367 ] correct/clarify documentation for super
Bugs item #1163367, was opened at 2005-03-15 00:39 Message generated for change (Settings changed) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163367&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Steven Bethard (bediviere) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: correct/clarify documentation for super Initial Comment: The current documentation for super is confusing. For instance, it says that it returns "the superclass of type" which is incorrect; it actually returns the next type in type's MRO. Well, to be truthful, it doesn't even do that; it returns a proxy object which makes that type's attributes available, but that's just another reason to fix the documentation. I suggest changing the wording to something like: """super(type[, object-or-type]) Return an object that exposes the attributes available through the type's superclasses, without exposing the attributes of the type itself. Attributes will be looked up using the normal resolution order, omitting the first class in the MRO (that is, the type itself). If the second argument is present, it should either be an instance of object, in which case isinstance(object-or-type, type) must be true, or it should be an instance of type, in which case issubclass(object-or-type, type) must be true. The typical use for this form of super is to call a cooperative superclass method: class C(B): def meth(self, arg): super(C, self).meth(arg) If the second argument to super is omitted, the super object returned will not expose any attributes directly. However, attributes will be accessible whenever the descriptor machinery is invoked, e.g. though explicit invocation of __get__. Note that super is undefined for implicit lookups using statements or operators such as "super(C, self)[name]". These must be spelled out with their explicit lookup, e.g. "super(C, self).__getitem__(name)". New in version 2.2. """ It's not perfect and I welcome suggestions for re-wording, but I think it's substantially more accurate about what super actually does. It also moves the "second argument omitted" situation to the end, since this is a vastly more uncommon use case. -- Comment By: Georg Brandl (birkenfeld) Date: 2006-01-20 18:06 Message: Logged In: YES user_id=1188172 See also Bug #973579 (which I closed as duplicate) for alternative wording. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163367&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1407902 ] urlparse does not know about sftp: urls
Bugs item #1407902, was opened at 2006-01-17 04:47
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1407902&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: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Stuart Bishop (zenzen)
Assigned to: Nobody/Anonymous (nobody)
Summary: urlparse does not know about sftp: urls
Initial Comment:
>>> from urlparse import urlparse
>>> urlparse('sftp://example.com//absolute/path')
('sftp', '', '//example.com//absolute/path', '', '', '')
>>> urlparse('sftp://example.com/relative/path')
('sftp', '', '//example.com/relative/path', '', '', '')
netloc should be populated in both cases
--
>Comment By: Georg Brandl (birkenfeld)
Date: 2006-01-20 18:24
Message:
Logged In: YES
user_id=1188172
Thanks for the report.
Committed revisions 42108, 42109 (2.4).
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1407902&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1411097 ] urllib2.urlopen() hangs due to use of socket._fileobject?
Bugs item #1411097, was opened at 2006-01-20 20: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=1411097&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: None
Status: Open
Resolution: None
Priority: 5
Submitted By: John J Lee (jjlee)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib2.urlopen() hangs due to use of socket._fileobject?
Initial Comment:
To reproduce:
import urllib2
print urllib2.urlopen("http://66.117.37.13/";).read()
The attached patch "fixes" the hang, but that patch is
not acceptable because it also removes the .readline()
and .readlines() methods on the response object
returned by urllib2.urlopen().
The patch seems to demonstrate that the problem is
caused by the (ab)use of socket._fileobject in
urllib2.AbstractHTTPHandler (I believe this hack was
introduced when urllib2 switched to using
httplib.HTTPConnection).
Not sure yet what the actual problem is...
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1411097&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1338995 ] CVS webbrowser.py (1.40) bugs
Bugs item #1338995, was opened at 2005-10-27 01:08
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1338995&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Greg Couch (gregcouch)
Assigned to: Nobody/Anonymous (nobody)
Summary: CVS webbrowser.py (1.40) bugs
Initial Comment:
There are two calls to _safequote that are only made on
darwin, aka, Mac OS X. That function is missing.
And the UnixBrowser is missing an & in the "simpler
command" and thus causes python to hang until the
browser is exited (if it wasn't running already).
--
>Comment By: Georg Brandl (birkenfeld)
Date: 2006-01-20 22:05
Message:
Logged In: YES
user_id=1188172
Another try to fix it in 42121. I added a special case for
OSX browsers wrt local URLs. Skip, can you test?
--
Comment By: Greg Couch (gregcouch)
Date: 2005-12-07 01:13
Message:
Logged In: YES
user_id=131838
And I agree it is desirable, but it didn't work reliably in
2.4 nor any earlier version, and it isn't documented to work.
The urllib.urlopen example you gave fails miserably with
Windows files names, i.e., given "C:\WINDOWS\system.ini" it
tries to interpret the C as a scheme. You need to use
urllib's pathname2url function and pass the result to
urlopen. If webbrowser.open is fixed, then maybe there will
be some pressure to fix urlopen as well.
You just have been lucky or unlucky depending on how you
view it.
--
Comment By: Skip Montanaro (montanaro)
Date: 2005-12-07 00:38
Message:
Logged In: YES
user_id=44345
All I'm saying is that if this form
webbrowser.open("/tmp/foo.html")
was supported in Python 2.4, possibly by recognizing the bare
path and silently pretending the programmer wrote
webbrowser.open("file://localhost/tmp/foo.html")
then it ought to do the same in 2.5 unless you intend to break
existing applications. How hard can it be to recognize that
the first character of the "url" is "/" and prepend "file://localhost/"
before passing it along to the user's chosen browser?
I suggest compatibility with urllib.urlopen is desirable:
>>> f = urllib.urlopen("/etc/hosts")
>>> f.read()
"##\n# Host Database\n# \n# Note that this file is consulted when the
system is running in single-user\n# mode. At other times this information is
handled by lookupd. By default,\n# lookupd gets information from NetInfo,
so this file will not be consulted\n# unless you have changed lookupd's
configuration.\n#\n# localhost is used to configure the loopback interface\n#
when the system is booting. Do not change this
entry.\n##\n127.0.0.1\tlocalhost
montanaro.dyndns.org\n255.255.255.255\tbroadcasthost\n"
Skip
--
Comment By: Greg Couch (gregcouch)
Date: 2005-12-06 23:27
Message:
Logged In: YES
user_id=131838
And you seem to have scanned my previous post and missed
where I discussed all of the problems with
webbrowser.open(path). I should have been more explicit
that those were problems with the all versions of the
webbrowser module. It is browser-dependent whether or not
opening a path works at all. I have had to work around that
"problem" for years (starting with grail in 1997 and carried
over to the webbroswer module in 2001). Any cross-platform
developer, that tests their code, already has a workaround
in place.
If the webbrowser documentation agreed with you, then I
would agree with you as well. Although I feel we are
already violently agreeing. "Fix" the documentation and
I'll "fix" the code.
--
Comment By: Skip Montanaro (montanaro)
Date: 2005-12-06 22:57
Message:
Logged In: YES
user_id=44345
You're missing the point. It works in Python 2.4 and
doesn't on CVS HEAD. I've already had to modify one
application. Maybe the old webbrowser module
used to prepend a "file://localhost/" to filenames
that were missing schemes. All I know is it used to
work and now it doesn't As is, 2.5 is likely to
break some applications that rely on the behavior in
2.4.
--
Comment By: Greg Couch (gregcouch)
Date: 2005-12-06 22:21
Message:
Logged In: YES
user_id=131838
Then file a bug report with whoever makes your web browser.
It's not Python's webbrowser module's fault that the
browser doesn't accept filesystem paths. The webbrowser
module is only documented to work with URLs, so any code
that depends on pa
[ python-Feature Requests-1353344 ] python.desktop
Feature Requests item #1353344, was opened at 2005-11-10 19:22 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1353344&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Installation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Björn Lindqvist (sonderblade) Assigned to: Nobody/Anonymous (nobody) Summary: python.desktop Initial Comment: I would very much like a /usr/share/applications/python.desktop file so that Python can be started from the Program-menu in Linux, just like you can from the Start-menu in Windows. I think it would be very neat and good for beginners. -- >Comment By: Georg Brandl (birkenfeld) Date: 2006-01-20 22:52 Message: Logged In: YES user_id=1188172 It seems that the new Python website will feature a new icon. Perhaps that could be added to the distribution as the default Python icon. -- Comment By: Björn Lindqvist (sonderblade) Date: 2006-01-09 18:52 Message: Logged In: YES user_id=51702 In trunk there are PC/py.ico, PC/pyc.ico, PC/pycon.ico. I guess they would all work as icons, but I choose pycon.ico because that is the icon used on windows. I also wonder if the desktop file can be applied soon? It seems pretty trivial and uncontroversial to me. -- Comment By: Georg Brandl (birkenfeld) Date: 2005-11-17 14:43 Message: Logged In: YES user_id=1188172 I added German translation. Regarding the icon: I do not like that very much. Isn't there another Python icon available in the standard sizes? -- Comment By: Björn Lindqvist (sonderblade) Date: 2005-11-16 19:16 Message: Logged In: YES user_id=51702 I have attached a .desktop file and an icon. python.desktop goes into /usr/share/applications and pycon.png into /usr/share/pixmaps. It's only translated to Swedish because I don't know other languages to well. -- Comment By: Martin v. Löwis (loewis) Date: 2005-11-13 23:41 Message: Logged In: YES user_id=21627 Would you be willing to provide one? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1353344&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1378679 ] urllib2.HTTPBasicAuthHandler fails on non-default port
Bugs item #1378679, was opened at 2005-12-12 12:50 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1378679&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: Fixed Priority: 5 Submitted By: Mikhail Gusarov (gusarov) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2.HTTPBasicAuthHandler fails on non-default port Initial Comment: HTTPBasicAuthHandler (or, more precise, AbstractBasicAuthHandler) does not work when non- default port is in use: passwords added to it just not being passed back in answer to the 401 error code. Default port works fine. I tracked the problem with it to the HTTPPasswordMgr. find_user_password: it accepts 'authuri' and reduce it using reduce_uri(). AbstractBasicAuthHandler passes as 'authuri' parameter just hostname, in form 'myhost:myport' and this cause reduce_uri() to parse it as URI with schema 'myhost' and netloc 'myport', which is obviously wrong. Passing to the reduce_uri() hostname in form 'myhost' works fine. I placed the the program demonstrating the bug to the attach: it throws HTTPError in my case. Of course change the host, port, user and password to the reflecting your setup. given should be protected by the basic authentication. -- >Comment By: Georg Brandl (birkenfeld) Date: 2006-01-20 23:01 Message: Logged In: YES user_id=1188172 Fixed in rev. 42130 in 2.4 branch. Already fixed in HEAD. -- Comment By: Mikhail Gusarov (gusarov) Date: 2005-12-12 13:10 Message: Logged In: YES user_id=501458 Problem was fixed by changing user, pw = self.passwd.find_user_password(realm, host) to the user, pw = self.passwd.find_user_password(realm, req. get_full_url()) in the problem function -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1378679&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1339007 ] shelve.Shelf.__del__ throws exceptions
Bugs item #1339007, was opened at 2005-10-27 01:30
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1339007&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: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Geoffrey T. Dairiki (dairiki)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: shelve.Shelf.__del__ throws exceptions
Initial Comment:
Python calls an object's __del__ method, even if the
objects __init__ method was unsuccessful (i.e. __init__
terminated via exception.)
Because of this, if there is an error while attempting
to open a Shelf, the destructor is still called, even
though the Shelf is not fully constructed. The code in
shelve.Shelf does not check for this possibility, and
therefor triggers an AttributeError.
Here is an example script which should reproduce the error.
===Begin test.pyl
import shelve
try:
shelf = shelve.open('non-existant-file', flag='r')
except:
pass
===End test.py=
For me, the above script produces the message:
Exception exceptions.AttributeError: "DbfilenameShelf
instance has no attribute 'writeback'" in ignored
I can reproduce this using either Python 2.4.1 or
2.3.5. I took a quick look at the current CVS version
of shelve.py, and it appears to suffer the same problem.
--
>Comment By: Georg Brandl (birkenfeld)
Date: 2006-01-20 23:10
Message:
Logged In: YES
user_id=1188172
Is this a bug? As exceptions in __del__ are ignored, this
should do no harm.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1339007&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1409455 ] email.Message.set_payload followed by bad result get_payload
Bugs item #1409455, was opened at 2006-01-18 14:09 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1409455&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: Mark Sapiro (msapiro) Assigned to: Barry A. Warsaw (bwarsaw) Summary: email.Message.set_payload followed by bad result get_payload Initial Comment: Under certain circumstances, in particular when charset is 'iso-8859-1', where msg is an email.Message() instance, msg.set_payload(text, charset) 'apparently' encodes the text as quoted-printable and adds a Content-Transfer-Encoding: quoted-printable header to msg. I say 'apparently' because if one prints msg or creates a Generator instance and writes msg to a file, the message is printed/written as a correct, quoted-printable encoded message, but text = msg._payload or text = msg.get_payload() gives the original text, not quoted-printable encoded, and text = msg.get_payload(decode=True) gives a quoted-printable decoding of the original text which is munged if the original text included '=' in some ways. This is causing problems in Mailman which are currently worked around by flagging if the payload was set by set_payload() and not subsequently 'decoding' in that case, but it would be better if set_payload()/get_payload() worked properly. A script is attached which illustrates the problem. -- >Comment By: Mark Sapiro (msapiro) Date: 2006-01-20 15:19 Message: Logged In: YES user_id=1123998 I've looked at the email library and I see the problem. msg.set_payload() never QP encodes msg._payload. When the message is stringified or flattened by a generator, the generator's _handle_text() method does the encoding and it is msg._charset that signals the need to do this. Thus when the message object is ultimately converted to a suitable external form, the body is QP encoded, but internally it never is. Thus, subsequent msg.get_payload() calls return unexpected results. It appears (from minimal testing) that when a text message is parsed into an email.Message.Message instance, _charset is None even if there is a character set specification in a Content-Type: header. I have attached a patch (Message.py.patch.txt) which may fix the problem. It has only been tested against the already attached example.py so it is really untested. Also, it only addresses the quoted-printable case. I haven't even thought about whether there might be a similar problem involving base64. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1409455&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-902075 ] urllib2 should be more robust for sloppy proxy URLs
Bugs item #902075, was opened at 2004-02-22 11:05 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=902075&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 should be more robust for sloppy proxy URLs Initial Comment: passing an URL like "foo.bar.baz" instead of "http://foo.bar.baz"; results in a stacktrace: File "/usr/lib/python2.3/urllib2.py", line 326, in open '_open', req) File "/usr/lib/python2.3/urllib2.py", line 306, in _call_chain result = func(*args) File "/usr/lib/python2.3/urllib2.py", line 491, in lambda r, proxy=url, type=type, meth=self.proxy_open: \ File "/usr/lib/python2.3/urllib2.py", line 498, in proxy_open if '@' in host: TypeError: iterable argument required This could be fixed by calling urlparse.urlparse on the proxy url, either in the calling code or in the library code, which I would prefer to make it more robust about sloppy URLs passed in the http_proxy environment variable. -- >Comment By: Georg Brandl (birkenfeld) Date: 2006-01-21 08:22 Message: Logged In: YES user_id=1188172 I committed a fix (similar to the patch) in rev. 42133 to the HEAD. I'm not sure whether to backport. -- Comment By: Andrew Bennetts (spiv) Date: 2006-01-17 04:04 Message: Logged In: YES user_id=50945 I think test cases would help the patch at http://bugs.debian.org/233305 get applied. -- Comment By: Chris Lawrence (lordsutch) Date: 2004-03-24 22:51 Message: Logged In: YES user_id=6757 I've put together a patch, which can be found at http://bugs.debian.org/233305; it isn't perfect (ideally the entire routine should be rewritten, as it's processing environment data that could be from the "wild"), but it avoids the traceback. -- Comment By: Matthias Klose (doko) Date: 2004-02-22 11:19 Message: Logged In: YES user_id=60903 Ok, I see, PEP42 ... -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=902075&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
