[issue2610] string representation of range and dictionary views
Brad Miller <[EMAIL PROTECTED]> added the comment: On Tue, Jun 17, 2008 at 12:23 AM, Martin v. Löwis <[EMAIL PROTECTED]> wrote: > > Martin v. Löwis <[EMAIL PROTECTED]> added the comment: > > After reviewing this again, I'm skeptical that this is a good idea. It > doesn't achieve its original purpose (anymore), as it only changes > tp_str for range objects (although it does change tp_repr for dict views > - why this inconsistency?). > The reason for the inconsistency is that there was a strong argument that the tp_repr for range already returned something useful that people could take advantage of in their code. The same was not the case for the dict views. I do not understand why you think that having the interpreter display when x.keys() is called is not an improvement over Maybe it is just because I spend a lot more time in the interactive interpreter that I see this as a big improvement. So if, as Raymond Hettinger suggests, the interpreter is the right place to make this change I'd still be happy to provide a patch if someone could give me a pointer for where to start looking. Brad > So I'm -0 on the patch, meaning that I won't commit it, but won't object > to anybody else committing it, either. > > Technically, in dictview_repr, the first call to PyUnicode_Concat isn't > checked for exceptions. > > ___ > Python tracker <[EMAIL PROTECTED]> > <http://bugs.python.org/issue2610> > ___ > ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2610> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1513695] new turtle module
Changes by Brad Miller <[EMAIL PROTECTED]>: -- nosy: +bmiller _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1513695> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1513695] new turtle module
Brad Miller <[EMAIL PROTECTED]> added the comment: I have xturtle 0.95a0 running under Python 3.0. Mostly the 2to3 program just worked for everything except in three places: 1. in __forward methods I had to change: fromClass.__dict__[method] = d[method]to setattr(fromClass,method,d[method]) 2. in getmethparlist The line: if type(ob)==types.MethodType: does not evaluate to true even when ob is a method. In 3.0 it seems that ob always evaluates to a function. 3. in the _pointlist method I changed cl = self.cv.coords(item) to cl = list(self.cv.coords(item)) There is probably a more elegant way to use the results from the coords call than converting to a list, but I'm confused. The canvas coords function now returns an itertools.imap object. This confuses me because the documentation on python.org does not mention the imap function in the itertools module documentation. So I'm not sure if imap is going away or is just missing documentation. I would like to propose two additional features that I have added to my copy of xturtle and have used extensively in my classes: 1. exitOnClick() --- This function simply hides the call to mainloop() from beginners. It makes life much easier for beginning programers to run xturtle from IDLE. 2. setWorldCoordinates(llx,lly,ulx,uly) This maps a given set of real world coordinates to window coordinates and allows programmers to run the turtle using real world coordinates. Again for beginning programmers this makes it easy for them to use the turtle to graph functions, make bar charts, etc. without needing to scale everything themselves. _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1513695> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2610] string representation of range
New submission from Brad Miller <[EMAIL PROTECTED]>: I use Python in my CS1 and CS2 curriculum and I have a question. As I've been using the Python 3.0 alphas one of the things that I am bothered by is that I cannot see the sequence produced by range without introducing students to the list() function. I typically introduce range on day 1 of class and show students what it produces without making a big deal out of the fact that it creates a list. They all accept this and things work out nicely when I introduce lists for real in a week or two. My question is why couldn't the __str__ method for the range object be more friendly and show a representation of the sequence? I understand why __repr__ should return range(0,10) for an object created using range(10) but couldn't print(range(10)) produce [0, 1, 2, ... 9] The ... could even be used if the sequence were excessively long. I have attached a patch, which follows the suggestion from Guido on how to format the string so it is not confused with a list. This is my first attempt at patching any part of the C code for Python. Please let me know what should be changed and If I've missed something. In particular I wonder whether I should be nesting any calls to PyNumber functions or whether temporary variables should be used to avoid leaking memory? In addition I get the following warning on the line where I install the range_str function in the PyRange_Type array. Objects/rangeobject.c:357: warning: initialization from incompatible pointer type Brad -- components: Interpreter Core files: range_str.patch keywords: patch messages: 65316 nosy: bmiller severity: normal status: open title: string representation of range type: feature request versions: Python 3.0 Added file: http://bugs.python.org/file1/range_str.patch __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2610> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2610] string representation of range
Brad Miller <[EMAIL PROTECTED]> added the comment: Thanks for all of the help. Using range_item certainly simplified my job. Although I more than made up for it with all of the decref and error checking calls. One side effect of using range_item is that str(range(...)) is now subject to the same errors as indexing into really big range: for example: x = range(100) x[1] File "", line 1, in OverflowError: Python int too large to convert to C ssize_t In a world where ints and long ints have been unified the existence of this error seems like a bug. I think the right thing would be to fix range_item and range_length so they do not use Py_ssize_t for the length of the range. But I may be in over my head on that guess. I also discovered that range_item does not work with negative indices. I have been poking around the tests and added some simple tests to the test_range.py class as well. I assume I should submit a patch for that as well? I have attached a new patch for rangeobject.c Brad Added file: http://bugs.python.org/file10003/range_str_2.patch __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2610> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2610] string representation of range
Brad Miller <[EMAIL PROTECTED]> added the comment: Here is a new patch file. This one contains the modifications to rangeobject.c as well as test_range.py I think this is everything. If there is something else I need to do please let me know. I looked to see if there was any documentation I could or should change for this but did not find any. Thanks again for your help. Added file: http://bugs.python.org/file10006/range_str_comb.patch __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2610> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2610] string representation of range
Brad Miller <[EMAIL PROTECTED]> added the comment: The patch does not change the behavior of repr. It modifies the behavior of str. I agree that learning list/tuple sooner is better, but students who have never written a line of code before can only absorb so much information, this little patch allows them to print(range(100,0,-1)) and get a much better intuition about what is happening. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2610> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2610] string representation of range
Brad Miller <[EMAIL PROTECTED]> added the comment: Our use of range in the first few classes is exactly for iteration purposes, but I do not like students to have to have too many mysteries. So I always have liked to show that range(10) simply produces a sequence of integers. In Python 3.0 range returns a mysterious iteration object. No thanks. My proposal was to provide a more user friendly implementation of the str method for this new range object that would allow the user to see the sequence. I like Python because it is so easy to start up a shell and poke around and see what things are. I have no problem, introducing list(range(10)) in week 3 when I start talking about lists, and I like list comprehensions of that purpose too. Again, what I do not like is that things that used to be very easy for students to get a conceptual handle on are now more difficult in 3.0. - range is one example the dict_keys and dict_values objects are another example. dict_keys et. al. are much easier to deal with since I've already covered lists and the list() function by the time I get there. BTW, I think we must have very different teaching styles as I would never introduce something as mysterious as list(_) on the first day of class. I'd be happy to continue our discussion of teaching philosophy but I doubt that this is the right forum. Brad __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2610> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2610] string representation of range
Brad Miller <[EMAIL PROTECTED]> added the comment: Clearly neither Alexander nor I are going to get the other to come around to our point of view. Thats fine, I think we can disagree here, and I can adapt and change my class either way. My question is how does this get resolved. When I posted this idea to python-dev Guido suggested an approach. Nobody else expressed an opinion so after waiting a few days I took Guido's suggestion and implemented a patch. Now there are objections. Other than some mild frustration at having invested a fair amount of time in producing my first python patch, I am also in the middle of editing a textbook that will come out this fall. my intention is to have this book be 3.0 compatible. So it would be nice for me to have some clarity on the direction this will go. Thanks, Brad __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2610> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2610] string representation of range
Brad Miller <[EMAIL PROTECTED]> added the comment:
> I would suggest considering a custom displayhook approach. You can
> write a custom displayhook that will print range(..), {}.keys(),
> {}.values() etc in a student-friendly way. I believe a module
> installing such display hook can be included in the standard library.
> In addition to iterable's display problem such a hook can limit the
> amount of output when displaying long lists, insert smart line breaks
> etc. For a textbook, you can instruct the readers to download your
> code and import a custom module before trying the examples. This is
> likely to make your textbook more future-proof because you will be
> able to update your displayhook code as python changes.
That is an interesting idea! I just hacked together a quick prototype.
I'll discuss this with my co-author. Its a fine line between using
'real'
Python and providing an appropriate level of help for the beginner. We
have tried to minimize the number of additional modules and
dependencies, so
if there was a hook like this as part of the standard library that would
be
great.
Brad
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2610>
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2610] string representation of range
Brad Miller <[EMAIL PROTECTED]> added the comment: Based on the discussion on python-dev I've worked up a patch and tests for repr of dict_items, dict_keys, and dict_values. I've also modified the patch and test for str of the range object. (If there was a way to get the str(range(10)) to automatically display in the interactive shell that would be ideal. I assume one combined patch for all of this is OK since its been part of the same discussion. Brad Added file: http://bugs.python.org/file10049/dv_range.patch __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2610> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2610] string representation of range and dictionary views
Brad Miller <[EMAIL PROTECTED]> added the comment:
On Apr 17, 2008, at 4:26 PM, Amaury Forgeot d'Arc wrote:
>
> Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
>
> Some review of dv_range.patch:
>
> - repr(d.keys()) depends on the internal ordering of items, their hash
> values, the insertion order... the test seems fragile.
> Or you may rely on the fact that ints are their own hash values, so a
> small dict containing small keys will appear ordered. I suggest
> something like {6: 1.2, 1: 'A', 7: 42, 4: None}
I wondered about that, but my assumption was that the hash function
for strings and ints was equally unlikely to change. I can go with
all ints if that is really a safer assumption.
>
>
> - empty dicts or empty ranges will display:
>
>
> Isn't there a better repr? At least this should appear in the tests.
I'm not sure how to represent that better.
-- These seem misleading
-- I'm not sure that is better than
and empty may not mean anything to non-english speakers
I'll be happy to add the test for the empty case after once I know
what it should look like.
>
>
> --
> nosy: +amaury.forgeotdarc
>
> __
> Tracker <[EMAIL PROTECTED]>
> <http://bugs.python.org/issue2610>
> __
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2610>
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2610] string representation of range and dictionary views
Brad Miller <[EMAIL PROTECTED]> added the comment: Is there any chance this patch will make it into the latest alpha?? Brad __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2610> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2610] string representation of range and dictionary views
Brad Miller <[EMAIL PROTECTED]> added the comment: On May 7, 2008, at 1:55 PM, Martin v. Löwis wrote: Thanks for the very clear answer. This being my first attempt at contributing to the Python core, I am looking for some sort of clarity on the future of this patch. It feels like some sort of consensus was reached and now the patch has been lingering without additional comment for several weeks. I have some sense of urgency in knowing the future as the final opportunity to include these changes in my introduction to CS book is looming on the horizon. Thanks, Brad > __ > Tracker <[EMAIL PROTECTED]> > <http://bugs.python.org/issue2610> > __ __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2610> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4275] socketserver example code not correctly ported to py3k
Brad Miller <[EMAIL PROTECTED]> added the comment:
I found a similar problem in the Demo/sockets/unixclient.py code.
from socket import *
FILE = 'unix-socket'
s = socket(AF_UNIX, SOCK_STREAM)
s.connect(FILE)
s.send('Hello, world')
data = s.recv(1024)
s.close()
print('Received', repr(data))
Produces the following error message:
Traceback (most recent call last):
File "unixclient.py", line 9, in
s.send('Hello, world')
TypeError: send() argument 1 must be string or buffer, not str
My question is around whether the examples are wrong and 'Hello, World'
should simply be wrapped with bytearray('Hello, World','utf8') or
whether the underlying socket implementation is wrong. Judging by the
error message above it looks like the implementation is catching just
this kind of error and the example should be changed. But, this must
break backward compatibility all over the place. And since the bug has
release blocker it makes me think the socket implementation should be
changed.
--
nosy: +bmiller
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue4275>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4275] socketserver example code not correctly ported to py3k
Brad Miller <[EMAIL PROTECTED]> added the comment: After looking at the socket documentation pointed to from another issue it looks like the right solution is to convert to a byte array. I've attached a patch with fixes for all the examples in socketserver.rst there were several other problems that I think were unrelated to Python 3.0 that I cleaned up in the process. -- keywords: +patch Added file: http://bugs.python.org/file11964/socketserverdoc.patch ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4275> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4275] socketserver example code not correctly ported to py3k
Brad Miller <[EMAIL PROTECTED]> added the comment:
For the example in unixclient.py using b'Hello World' works fine. But for
the example in the socketserver documentation the strings to convert come
from argv[1:]
On Sat, Nov 8, 2008 at 5:48 AM, STINNER Victor <[EMAIL PROTECTED]>wrote:
>
> STINNER Victor <[EMAIL PROTECTED]> added the comment:
>
> Why not using bytes() instead of bytearray()? Eg. replace
> s.send('Hello, world') by s.send(b'Hello, world').
>
> --
> nosy: +haypo
>
> ___
> Python tracker <[EMAIL PROTECTED]>
> <http://bugs.python.org/issue4275>
> ___
>
Added file: http://bugs.python.org/file11966/unnamed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue4275>
___For the example in unixclient.py using b'Hello World' works fine.
But for the example in the socketserver documentation the strings to
convert come from argv[1:]On Sat, Nov 8, 2008
at 5:48 AM, STINNER Victor <mailto:[EMAIL
PROTECTED]">[EMAIL PROTECTED]> wrote:
STINNER Victor <mailto:[EMAIL PROTECTED]">[EMAIL PROTECTED]>
added the comment:
Why not using bytes() instead of bytearray()? Eg. replace
s.send('Hello, world') by s.send(b'Hello, world').
--
nosy: +haypo
___
Python tracker <mailto:[EMAIL PROTECTED]">[EMAIL
PROTECTED]>
<http://bugs.python.org/issue4275";
target="_blank">http://bugs.python.org/issue4275>
___
-- Brad
MillerAssistant Professor, Computer ScienceLuther College
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4275] socketserver example code not correctly ported to py3k
Brad Miller <[EMAIL PROTECTED]> added the comment: Here's a combined patch that fixes: Doc/library/socketserver.rst examples tested and working Demo/sockets/udpecho.py Demo/sockets/unixclient.py Added file: http://bugs.python.org/file11967/socketpatches.patch ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4275> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5276] IDLE startup file .Idle.py not documented
Brad Miller added the comment: Here's a simple patch that documents the different startup files. It is missing a good use case for .Idle.py but I'd be happy to add that if someone can give me one. -- keywords: +patch message_count: 1.0 -> 2.0 nosy: +bmiller nosy_count: 2.0 -> 3.0 Added file: http://bugs.python.org/file13296/idlestartdoc.patch ___ Python tracker <http://bugs.python.org/issue5276> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2610] string representation of range and dictionary views
Brad Miller added the comment: Just to restart the discussion on the original issue since I see that the latest 3.1 has solved the problem with dict_keys, dict_values, etc al objects. Many thanks! A suggestion was made by Alexander to create a custom displayhook that could be included in the standard library. From the research I've done it looks like a solution for range would be something like the following: import sys def eduhook(o): if o is None: return if isinstance(o,range): print(list(o)) else: print(repr(o)) sys.displayhook = eduhook Now if 5233/5234 were approved I could tell my students to setup an environment variable PYTHONSTARTUP that points to a file that imports a module containing the above code. (or I could just tell them to import said module each time.) The above hook appears to work fine. Is there anything obvious I'm missing? If this is along the right track then I could extend it to support other custom display ideas that my fellow educators have in mind. Thanks, Brad -- message_count: 30.0 -> 31.0 ___ Python tracker <http://bugs.python.org/issue2610> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2704] IDLE: Patch to make PyShell behave more like a Terminal interface
Brad Miller added the comment: I hand applied the patch because I hoped it would fix the problem of the cursor going all the way to the left of the >>> in the Python shell when you press home or ctrl-a. The patch as it is does not solve this problem on the Mac. I've uploaded the patch as a unified diff to make it easier for others who might want to give it a try. The patch does a great job of scrolling through the history at the current prompt. This is a great improvement! Thanks. -- nosy: +bmiller Added file: http://bugs.python.org/file13306/PyShell.patch ___ Python tracker <http://bugs.python.org/issue2704> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5232] Setting font from preference dialog in IDLE on OS X broken
Brad Miller added the comment:
I get the same problem when I try to change the key set. This is on on
intel build using Tk 8.5, and the latest 3.1 source checked out with
bzr.
I too changed the order of /Library/Frameworks and
/System/Library/Frameworks in setup.py
A simple fix for me was to add the line
root.instance_dict = {}
in macosxsupport.py That does not seem to have any other ill effects.
--
nosy: +bmiller
___
Python tracker
<http://bugs.python.org/issue5232>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4773] HTTPMessage not documented and has inconsistent API across 2.6/3.0
Changes by Brad Miller : -- nosy: +bmiller ___ Python tracker <http://bugs.python.org/issue4773> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4773] HTTPMessage not documented and has inconsistent API across 2.6/3.0
Brad Miller added the comment:
On Thu, Mar 26, 2009 at 4:29 PM, Barry A. Warsaw wrote:
>
> Barry A. Warsaw added the comment:
>
> I propose that you only document the getitem header access API. I.e.
> the thing that info() gives you can be used to access the message
> headers via message['content-type']. That's an API common to both
> rfc822.Messages (the ultimate base class of mimetools.Message) and
> email.message.Message.
>
As I've found myself in the awkward position of having to explain the new
3.0 api to my students I've thought about this and have some
ideas/questions.
I'm also willing to help with the documentation or any enhancements.
Traceback (most recent call last):
File "", line 1, in
TypeError: 'addinfourl' object is unsubscriptable
I wish I new what an addinfourl object was.
'Fri, 27 Mar 2009 00:41:34 GMT'
'Fri, 27 Mar 2009 00:41:34 GMT'
['Date', 'Server', 'Last-Modified', 'ETag', 'Accept-Ranges',
'Content-Length', 'Connection', 'Content-Type']
Using x.headers over x.info() makes the most sense to me, but I don't know
that I can give any good rationale. Which would we want to document?
'text/html; charset=ISO-8859-1'
I guess technically this is correct since the charset is part of the
Content-Type header in HTTP but it does make life difficult for what I think
will be a pretty common use case in this new urllib: read from the url (as
bytes) and then decode them into a string using the appropriate character
set.
As you follow this road, you have the confusing option of these three calls:
'iso-8859-1'
>>> x.headers.get_charsets()
['iso-8859-1']
I think it should be a bug that get_charset() does not return anything in
this case. It is not at all clear why get_content_charset() and
get_charset() should have different behavior.
Brad
>
> --
> nosy: +barry
>
> ___
> Python tracker
> <http://bugs.python.org/issue4773>
> ___
>
--
Added file: http://bugs.python.org/file13430/unnamed
___
Python tracker
<http://bugs.python.org/issue4773>
___On Thu, Mar 26, 2009 at 4:29 PM, Barry A.
Warsaw <mailto:rep...@bugs.python.org";>rep...@bugs.python.org>
wrote:
Barry A. Warsaw <mailto:ba...@python.org";>ba...@python.org>
added the comment:
I propose that you only document the getitem header access API. Â I.e.
the thing that info() gives you can be used to access the message
headers via message['content-type']. Â That's an API common to
both
rfc822.Messages (the ultimate base class of mimetools.Message) and
email.message.Message.As I've found
myself in the awkward position of having to explain the new 3.0 api to my
students I've thought about this and have some ideas/questions.
I'm also willing to help with the documentation or any
enhancements.>>> x =
urllib.request.urlopen('http://knuth.luther.edu/python/test.html";>http://knuth.luther.edu/python/test.html')
>>> x['Date']Traceback (most recent call
last):Â Â File "<stdin>", line 1, in
<module>TypeError: 'addinfourl' object is
unsubscriptable
I wish I new what an addinfourl object
was.>>> http://x.info";>x.info()['Date']'Fri, 27 Mar
2009 00:41:34 GMT'
>>> x.headers['Date']'Fri, 27
Mar 2009 00:41:34 GMT'>>>
x.headers.keys()['Date', 'Server',
'Last-Modified', 'ETag', 'Accept-Ranges',
'Content-Length', 'Connection', 'Content-Type']
Using x.headers over http://x.info";>x.info()
 makes the most sense to me, but I don't know that I can give any good
rationale. Â Which would we want to document?
>>>
x.headers['Content-Type']'text/html;
charset=ISO-8859-1'I guess technically this is
correct since the charset is part of the Content-Type header in HTTP but it
does make life difficult for what I think will be a pretty common use case in
this new urllib: Â read from the url (as bytes) and then decode them into a
string using the appropriate character set.
As you follow this road, you have the confusing
option of these three calls:>>>
x.headers.get_charset()>>>
x.headers.get_content_charset()
'iso-8859-1'>>>
x.headers.get_charsets()['iso-8859-1']I
think it should be a bug that get_charset() does not return anything in this
case. Â It is not at all clear why get_content_charset() and get_charset()
should have different behavior.
BradÂ
--
nosy: +barry
___
Python tracker <mailto:rep...@bugs.python.org";>rep...@bugs.python.org>
<http://bugs.python.org/issue4773";
target="_blank">http://bugs.python.org/issue4773>
___
-- Brad
MillerAssistant Professor, Computer ScienceLuther College
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
