On 2011-01-06, Chris Rebert <> wrote:
> On Wed, Jan 5, 2011 at 11:21 PM, Garland Fulton <> wrote:
>> On Wed, Jan 5, 2011 at 7:26 PM, Tim Harig <> wrote:
>>> * *Python 3.1.2 (r312:79147, Oct *9 2010, 00:16:06)
>>> * *[GCC 4.4.4] on linux2
>>> * *Type "help", "copyright", "credits" or "license" for more information.
>>> * *>>> import urllib.request, urllib.parse
>>> * *>>> params = urllib.parse.urlencode({'cht':'lc', 'chtt':'This is | my
>>> * *>>> chart',
Sorry I didn't notice this got accidently wrapped when I pasted it.
>>> params = urllib.parse.urlencode({'cht':'lc', 'chtt':'This is | my chart',
>>> * *... * * * * 'chs':'600x200', 'chxt':'x,y', 'chd':'t:40,20,50,20,100'})
>>> * *>>> chart =
>>> urllib.request.urlopen('https://chart.googleapis.com/chart',
>>> * *... * * * * data = params).read()
>>> * *>>> chartFile = open("chart.png", 'wb')
>>> * *>>> chartFile.write(chart)
>>> * *10782
>>> * *>>> chartFile.close()
>>
>> Hope this isn't to stupid,
>> For the
>> chart = urllib.request.urlopen('https://chart.googleapis.com/chart', data =
>> params).read()
>> Where would I find information on why and what the ).read() part does.
For some reason, posts from from this account don't seem to be making it
through the gateway to usenet so I am only seeing what Mr. Rebert has
replied to. If you have asked anything else, I very well may have missed
it.
> http://docs.python.org/py3k/library/...equest.urlopen
> Specifically: "This function returns a file-like object" (representing
> the stream of data received). Thus, .read() on the file-like object
> returns the actual bytes obtained from the given URL.
Mr. Rebert already answed your question; but, I will expand on that a
little bit. One of the great things about the Python language is that it
uses what is commonly known as "duck typing." That is anything object which
provides the same attributes as another object can be used as though it is
actually the second object. It is kind of like an implicit form of
generics that doesn't require a template or an interface.
The Python standard library makes extensive use of duck typing for file
like objects. Any object that provides the proper method attributes can be
given to functions that expect files even though the object is given might
not be the traditional concept of a file on the filesystem. It might be a
stringIO object, a socket file object, or something new that you have
created that supports the required method attributes.
The semantics and documentation for file like objects have changed a
little for python2 vs. python3:
python2:
http://docs.python.org/library/stdty...l#file-objects
python3:
http://docs.python.org/py3k/library/io.html#io.IOBase
but they still basically work the same way. Much of the Python 3
documentation still refers file objects.
Similar Threads
