[issue41638] Error message: sqlite3.ProgrammingError: You did not supply a value for binding # might be improved
Evens Fortuné added the comment: I don't think this is a bug. As I have explained in the answer I have provided on StackOverflow (https://stackoverflow.com/posts/comments/112539410?noredirect=1), it seems that sqlite3 uses by default the qmark parameter substitution style for their query which uses a tuple to provide it with its values. So it makes sense that the error message only does reference the index number since the matching is done on the order where a parameter appear on the SQL query and the same order in the tuple provided. Here @Wolfgang seems to try to use the named parameter substitution style because he is using a dictionary to provide the values to the query. You have to set it globally before doing that (sqlite3.paramstyle = 'named'). So from my point of view there is no bug here. -- nosy: +EvensF ___ Python tracker <https://bugs.python.org/issue41638> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41638] Error message: sqlite3.ProgrammingError: You did not supply a value for binding # might be improved
Evens Fortuné added the comment: Yes we could say that the documentation can be lacking but that doesn't means it's a bug in the code. If you feel that the documentation need to be improved then you should submit a patch to the documentation and not how the code should be changed. If you feel that the error message doesn't give enough information you could modify the source code of that module and submit a patch instead of a workaround. But meanwhile I would suggest that your code should check that all the information is valid before you submit it to the database. It shouldn't be really the responsibility of the database to catch this kind of errors. -- ___ Python tracker <https://bugs.python.org/issue41638> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21228] Missing enumeration of HTTPResponse Objects methods of urllib.request.urlopen's http.client.HTTPResponse?
New submission from Evens Fortuné: In the Python Library documentation, in section "21.6. urllib.request — Extensible library for opening URLs", in the description of the urllib.request.urlopen() function it is writen: - […] For http and https urls, this function returns a http.client.HTTPResponse object which has the following HTTPResponse Objects methods. For ftp, file, and data urls and requests explicity handled by legacy […] - The first sentence seemed to imply that something is supposed to be specified if I understand correctly. Is it me missing something ? -- assignee: docs@python components: Documentation messages: 216254 nosy: EvensF, docs@python priority: normal severity: normal status: open title: Missing enumeration of HTTPResponse Objects methods of urllib.request.urlopen's http.client.HTTPResponse? type: enhancement versions: Python 3.2, Python 3.3, Python 3.4, Python 3.5 ___ Python tracker <http://bugs.python.org/issue21228> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21229] Path used for HTTP PUT request doesn't match the description
New submission from Evens Fortuné:
In the Python Standard Library, at the end of :
- Section "20.7.3. Examples" of "20.7. httplib — HTTP protocol client" (for
Python 2.7.6)
- Section "20.10.3. Examples" of "20.10. http.client — HTTP protocol client"
(for Python 3.2.5)
- Section "21.12.3. Examples" of "21.12. http.client — HTTP protocol client"
(for Python 3.3.5, Python 3.4.0, and Python 3.5a0)
the last example is described this way (change httplib for http.client for
Python 3.2+):
>>> # This creates an HTTP message
>>> # with the content of BODY as the enclosed representation
>>> # for the resource http://localhost:8080/foobar
...
>>> import httplib
>>> BODY = "***filecontents***"
>>> conn = httplib.HTTPConnection("localhost", 8080)
>>> conn.request("PUT", "/file", BODY)
>>> response = conn.getresponse()
>>> print response.status, response.reason
200, OK
Is it possible that the request method should have been called this way:
conn.request("PUT", "/foobar", BODY)
^^
Thank you
--
assignee: docs@python
components: Documentation
messages: 216257
nosy: EvensF, docs@python
priority: normal
severity: normal
status: open
title: Path used for HTTP PUT request doesn't match the description
type: enhancement
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5
___
Python tracker
<http://bugs.python.org/issue21229>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21228] Missing enumeration of HTTPResponse Objects methods of urllib.request.urlopen's http.client.HTTPResponse?
Evens Fortuné added the comment: I forgot to tell that it is in section "20.5. urllib.request — Extensible library for opening URLs" for Python 3.2.5 -- ___ Python tracker <http://bugs.python.org/issue21228> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21228] Missing enumeration of HTTPResponse Objects methods of urllib.request.urlopen's http.client.HTTPResponse?
Evens Fortuné added the comment: I don't quite understand what you are asking me. You need a copy of the document ? You can find an example at this link: https://docs.python.org/3/library/urllib.request.html#urllib.request.urlopen -- ___ Python tracker <http://bugs.python.org/issue21228> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21229] Path used for HTTP PUT request doesn't match the description
Evens Fortuné added the comment: Do you have some documentation on how to do a "docs patch" ? I'm sorry this is the first time I'm reporting a bug. -- ___ Python tracker <http://bugs.python.org/issue21229> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21229] Path used for HTTP PUT request doesn't match the description
Evens Fortuné added the comment: Is it what you asked? -- keywords: +patch Added file: http://bugs.python.org/file34901/issue21229.patch ___ Python tracker <http://bugs.python.org/issue21229> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21228] Missing enumeration of HTTPResponse Objects methods of urllib.request.urlopen's http.client.HTTPResponse?
Changes by Evens Fortuné : Added file: http://bugs.python.org/file34905/urllib.request.rst ___ Python tracker <http://bugs.python.org/issue21228> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21228] Missing enumeration of HTTPResponse Objects methods of urllib.request.urlopen's http.client.HTTPResponse?
Evens Fortuné added the comment: Hi, >From my limited experience reporting documentation issues, I see that it's >better to submit a patch than to only report an issue. So, I've tried to look >into the source code to figure out what was going on. I have attached a patch >that I'm submitting to you for review hoping I doing everything right. What was reported as ambiguous in this issue is the description of the return value of the function urllib.request.urlopen() for http and https URLs. It was mentionned that it should be an http.client.HTTPResponse object but it implied that something may have been different about this object. To understand why I'm may now be able to assert what's being said in that patch, follow me in the source code. It's based on revision c499cc2c4a06. If you don't care about all the walkthrough you can skip to step 9. 1. We want to describe the return value of the urllib.request.urlopen() for http and https URLs 2. The urlopen() function is defined in Lib/urllib/request.py starting on line 138. Its return value is the return value function of the opener.open() method (line 153) * This opener object is defined in one of these locations: * On line 150 as the return value of the module function build_opener() (this return value is cached in the _opener module variable) * On line 152 as the value cached in the _opener module variable * On line 148 still as the return value of the module function build_opener() in the case if you want to access an HTTPS URL and you provide a cafile, capath or cadefault argument * So either way, the opener object come from the build_opener directly or indirectly. 3. The build_opener() function is defined starting on line 505. Its return value (line 539) is an instance of the OpenerDirector class (line 514). The OpenerDirector class is defined starting on line 363. a. Before returning its return value, after some checks (lines 522-530, 535-536), build_opener() calls the OpenerDirector().add_handler() with an instance of some of the classes defined in the default_classes list (line 515-518). What matters to us is the HTTPHandler class and the HTTPSHandler class (line 520). b. The OpenerDirector().add_handler() method (line 375) takes the HTTPHandler class (line 1196) and: * Insert the HTTPHandler.http_open() method in the list stored as the value of OpenerDirector().handle_open['http']. * Insert the HTTPHandler.http_request() method in the list stored as the value of OpenerDirector().process_request['http']. c. For HTTPSHandler (line 1203) is the same thing but : * HTTPSHandler.https_open() for OpenerDirector().handle_open['https'] * HTTPSHandler.https_request() for OpenerDirector().process_request['https'] 4. I remind you that we are looking for the return value of the method open() of an instance of the OpenerDirector class (see point number 2). This method is defined starting on line 437. 5. The OpenDirector.open() method's return value is the response variable (line 463) 6. This variable is defined on lines 461 and 455. a. The loop on lines 458-461 tries to find in his handlers (the OpenerDirector().process_response dictionary) a response processor (a XXX.http_response() method) which isn't defined in HTTPHandler or HTTPSHandler. (a http_response() method is defined in HTTPErrorProcessor [line 564] and in HTTPCookieProcessor [line 1231] but in each of these cases, these classes don't modify the response value) b. So response variable's value is the return value of OpenerDirector()._open(req, data) on line 455. * The req argument is a Request instance (line 440) or something that has the same interface, I guess (line 442). The Request class is defined on line 253. * The data argument is included in the constructor of the Request instance (line 440 and then on line 262) or added to the object provided (line 444). Afterwards, it won't be used directly (OpenerDirector()._open() receives it as an argument but won't use it in its body) 7. OpenerDirector()._open() is defined on line 465. It will call OpenerDirector()._call_chain() up to three times depending on whether a result has been found (lines 468-469, 474-475). * OpenerDirector()._call_chain() is defined on line 426. All it does is calling the handlers registered in the dictionnary provided (the chain argument) until one returns something else than None and returns it. * In our case (retrieving http and http resources): a. The first call (line 466) will return None since HTTPHandler or HTTPSHandler don't have a default_open() method (in fact, no handler defined in this file has a default_open() method) b. The second call will work since HTTPHandler.http_
[issue21228] Missing enumeration of HTTPResponse Objects methods of urllib.request.urlopen's http.client.HTTPResponse?
Evens Fortuné added the comment: Well, there wasn't any indication before that the returned object was implementing the "addinfourl" interface. So I don't think we have lost anything. In what situation this interface is useful ? The following comment (that you had highlighted in your comment) gives the impression that theses methods are there only to provide compatibility with clients using old-styles responses. http://hg.python.org/cpython/file/c499cc2c4a06/Lib/http/client.py#l772 That would imply that newer clients would usually not use these methods. If you want to document this, I think the "addinfourl" interface should then be better described somewhere else where it would include the fact that the HTTPResponse class implements it. Anyway, I don't see the advantage of using a getter method (like geturl()) instead of accessing directly the attribute. For me, this is less pythonic. If you ever have to attach a behaviour to the access of this attribute, a property could then be defined. -- ___ Python tracker <http://bugs.python.org/issue21228> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21228] Missing enumeration of HTTPResponse Objects methods of urllib.request.urlopen's http.client.HTTPResponse?
Evens Fortuné added the comment: To be honest, it may be inspired by what's written a few lines lower, for ftp, files dans data urls even though the return object is not the same as the http(s) urls http://hg.python.org/cpython/file/c499cc2c4a06/Doc/library/urllib.request.rst#l75 -- ___ Python tracker <http://bugs.python.org/issue21228> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21228] Missing enumeration of HTTPResponse Objects methods of urllib.request.urlopen's http.client.HTTPResponse?
Evens Fortuné added the comment: Look, the subject of this issue is to clarify the methods of the urllib.request.urlopen()'s return value for http(s) URLs. Nobody seemed to work on this for 4 months. That's why I tried to submit a patch after looking into the code to try to do my part to help. If you think that my patch is not clear enough and would need to be more precise or maybe even that it is plain wrong, please submit a new patch with your ideas so that we can close eventually this issue. I really didn't think that it would get this complicated… -- ___ Python tracker <http://bugs.python.org/issue21228> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21228] Missing enumeration of HTTPResponse Objects methods of urllib.request.urlopen's http.client.HTTPResponse?
Evens Fortuné added the comment: I'm satisfied with this new patch. -- ___ Python tracker <http://bugs.python.org/issue21228> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
