[issue24651] Mock.assert* API is in user namespace
Changes by Patrick Westerhoff patrickwesterh...@gmail.com: -- nosy: +poke ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24651 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22183] datetime.timezone methods require datetime object
New submission from Patrick Westerhoff: I’ve noticed that the methods in `datetime.timezone` all require a datetime object (or explicitely `None`) as its parameter or they will raise an exception. The datetime object however is never required for the implementation of the method, so it seems to me like an unnecessary requirement, given that timezone objects are completely independent of datetime objects. For example `timezone.utcoffset` is implemented like this: def utcoffset(self, dt): if isinstance(dt, datetime) or dt is None: return self._offset raise TypeError(utcoffset() argument must be a datetime instance or None) I don’t really understand this requirement and if there isn’t an actual reason for it (if there is, it should be documented somewhere), I’d suggest to remove this requirement completely. For backwards compatibility, the parameter could simply default to `None`. -- components: Library (Lib) messages: 225188 nosy: poke priority: normal severity: normal status: open title: datetime.timezone methods require datetime object type: behavior ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22183 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14373] C implementation of functools.lru_cache
Changes by Patrick Westerhoff patrickwesterh...@gmail.com: -- nosy: +poke ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14373 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20641] Python installer needs elevated rights to install pip
Patrick Westerhoff added the comment: Hey all, yes, I indeed try to install Python into `C:\Program Files\`. I’m doing that on Windows 8.1 64bit with an Administrator account (which doesn’t matter though) with standard UAC (which only asks when applications make changes to the computer settings). This UAC setting means that every access to e.g. `C:\Windows` or `C:\Program Files` will need elevated rights. The MSI cannot be run with real administrator rights but automatically request elevated rights when they need it, so to install, I just execute it and let the installer request elevated rights as it needs to. My installation directory is `C:\Program Files\Development\Python34`. Then, somewhere at the end of the setup bar, a Python console window pops up, saying that it’s installing pip. After its download, I can see some red text flash up and the window disappears (I’ve attached the `pip.log`). The installer then finishes, but the `\Scripts\` directory is missing. As mentioned above, elevated rights are required when installing into `C:\Program Files\`. As you tried to reproduce it while installing to `C:\Python34\` you didn’t get the same problem. In fact, testing it again by installing it there works fine. This however is not really an acceptable solution for me. As suggested in my first message, the launched Python process should have elevated rights itself, but I don’t know if it’s possible to inherit those from the installer. I don’t personally mind if this isn’t a blocker for the Python 3.4 release. I personally can live with installing pip with an elevated command line myself (that’s what I always did :P). But in the long run, we might want to find a real solution for this. -- Added file: http://bugs.python.org/file34184/pip.log ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20641 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20641] Python installer needs elevated rights to install pip
Patrick Westerhoff added the comment: That’s great to hear, thanks a lot :) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20641 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20641] Python installer needs elevated rights to install pip
New submission from Patrick Westerhoff: When installing Python 3.4 with the MSI, you can choose to install pip as part of the setup. With activated UAC on Windows (which is the recommended default), the installer will ask for elevated rights during the setup to copy the files over to the installation directory. However, when the setup then attempts to install pip, the Python interpreter running the `ensurepip` library to install it is *not* run with elevated rights. This obviously results in a permission error when it then tries to copy over pip into the `\Scripts\` install directory. This is similar to the advanced installer option “Compile .py files to byte code”, which has been failing forever because of the same problem. But now, with pip, this is an actual problem. I suggest that you either run the pip install process from within the elevated setup, inheriting the rights—if that’s even possible—or explicitely request elevated rights for it again. -- components: Windows messages: 211360 nosy: poke priority: normal severity: normal status: open title: Python installer needs elevated rights to install pip versions: Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20641 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14133] improved PEP 409 implementation
Patrick Westerhoff patrickwesterh...@gmail.com added the comment: Hey, I just saw the release notes for 3.3 and would like a quick confirmation: This is included in 3.3, right? ^^ -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14133 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14133] improved PEP 409 implementation
Patrick Westerhoff patrickwesterh...@gmail.com added the comment: Alright, thought so but wanted a confirmation anyway – thanks a lot :D -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14133 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14805] Support display of both __cause__ and __context__
Changes by Patrick Westerhoff patrickwesterh...@gmail.com: -- nosy: +poke ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14805 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14133] improved PEP 409 implementation
Changes by Patrick Westerhoff patrickwesterh...@gmail.com: -- nosy: +poke ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14133 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6210] Exception Chaining missing method for suppressing context
Patrick Westerhoff patrickwesterh...@gmail.com added the comment: I have to agree with Georg on that. I think it would make more sense to introduce some internal flag/variable that keeps track of if the cause was explicitely set. So if cause was set (i.e. `from X` syntax is used), then always display it in favor of the context – except that a None-cause causes nothing to display. Regardless of that I’m actually not sure if just changing the way the cause is displayed is a correct way to handle the context. If I explicitely raise an exception in an except-handler, I usually don’t expect that new exception to get the previous exception attached to. In the original example, I want to completely replace the “context” by a new exception without implicitely keeping over the original exception. So even if using `from None` will prevent the context from being displayed (as the explicitely set cause will override it), the `__context__` will probably still be set by the `raise` statement, and I think that shouldn’t happen. Hence the `raise X instead` or `raise as X` idea that simply does not set the context but “destroys” it. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6210 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6210] Exception Chaining missing method for suppressing context
Patrick Westerhoff patrickwesterh...@gmail.com added the comment: Oh, where did that PEP come from? ^^ Also thanks for hinting at python-dev, didn’t realize that there was a discussion going on about this! -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6210 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6210] Exception Chaining missing method for suppressing context
Patrick Westerhoff patrickwesterh...@gmail.com added the comment: Yeah, I would really like that solution, especially as it separates from the `from X` syntax that sets the exception’s cause. Also I would prefer a syntax solution over a class method simply because the exception context is something that is implicitely set by Python with the `raise` statement. So it would make sense to overwrite that behaviour with a syntax construct as well. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6210 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13280] argparse should use the new Formatter class
New submission from Patrick Westerhoff patrickwesterh...@gmail.com: Hey, according to PEP 3101, the new string.Formatter class is supposed to replace the old string formatting with %. At least that is what I was always thinking. Given that argparse is a Python 3.2+ exclusive module, I think it should make use of that new formatting method. Is there any special reason why that is not the case and the old %-formatting is used? It feels a bit weird to have Python 3 code using only string.Formatter and then have a short section where the old formatter is used – especially when that module was introduced with Python 3.2. -- components: Library (Lib) messages: 146516 nosy: poke priority: normal severity: normal status: open title: argparse should use the new Formatter class type: behavior versions: Python 3.2, Python 3.3, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13280 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1673007] urllib2 requests history + HEAD support
Patrick Westerhoff patrickwesterh...@gmail.com added the comment: Senthil, I highly disagree with what you said: The next problem comes when a user has specified both data and method=GET. This becomes an invalid scenario, but a decision has been to taken as what should be given preference? That is incorrect, RFC2616 states that the server should ignore the message body when the request method does not define any semantics for it, but there is nothing that makes the inclusion of a message body along with the GET request method invalid. - As the user has sent data, should the request be considered a POST? No, absolutely not. Sending data via other request methods, like DELETE or PUT, is semantically correct and should be supported completely if we are going to include a way to set the request method. If I set the method to PUT, and include data, I don’t want the library to override that to POST just because I set data. - But user specified it as GET (intentionally or by mistake), so should the data not be used and Request should do only a GET? If I data is included and the request method is explicitely set to GET, make a GET request and include the data in the request body. It might not be a semantically good decision to send data over GET, but it still is not disallowed and as such should be possible (for whatever reasons). - Or should we throw an error? We especially should’t throw an error, as this is not invalid at all. A person would just send data and forget about changing the method to POST. I agree that the library should still default to POST if data is included and the request method was not explicitely set (see also below). 1) should method always have priority or should 'POST' always be used whenever data is passed? If data is passed use POST. No, if data is passed and no special method is set, use POST, otherwise use the method the user specified, because that is what he expects. 2) if the method is e.g. 'GET' and data is passed, should an error be raised? Nope, give data the priority and do POST. (As urllib is currently doing) Don't give data any priority if the method was set explicitely. Otherwise the ability to set a custom method is totally useless, especially with request methods where a message body is semantically useful (i.e. all other than HEAD and GET). 3) should Request.method be private? Not necessarily, it should be public. Depends on the way the method will be set. Looking at the way, the other request parameters are set (especially with the accessors being “deprecated”), it makes sense to leave this public. 4) should the value of Request.method be initialized in the __init__ or can it also be None? My take - It should be initialized to default (GET), instead of None. Initializing it to GET will make the implementation difficult, especially if we want to continue supporting the behaviour of setting the method to POST when data is changed (and the method was not explicitely set). Unless we override the built-in property accessors I don’t think this is possible. 5) if the value of Request.method is always initialized, should we deprecate get_method? This is an interesting question. get_method essentially becomes less useful or it could serve as an arbiter when data and GET is sent and may be used as reliable way to get the Request's method. It should not be deprecated. To my understanding, and this is also why I provided the same patch on the duplicate bug, `get_method` is used by the other libraries to get the used request method. Unless we change the other libraries to determine the method in a different way, deprecating `get_method` won’t get us anywhere. What I tried to respect with the patch, and I think this was also Denver’s intention, is to add this functionality without breaking the current behaviour. That behaviour is that GET is default, and POST is set as default if there is any data. The functionality requires that the request method can be set (and the default behaviour can be overriden) without looking at the data (as explained above). Ideally I would probably like to see the functionality of `get_method` done in another library, which performs the request. I.e. check `request.method` and use that if it’s set, otherwise check `request.data` and choose either POST or GET. But again this would require far too many changes in other libraries for this simple change. And again on the `data` property: I think the name “data” is a bit confusing. Request does not provide any encoding details on that “data”, and it is actually just the request body in its original form. What I usually do in my subclass of Request is to provide a way to encode the data I pass to the constructor (often even with multipart encoding for file streams), while the `request.data` attribute to me still means “request body”. Regarding those questions on the implementation, I agree with Ezio, and as I said
[issue13142] Add support for other HTTP methods in urllib.request
New submission from Patrick Westerhoff patrickwesterh...@gmail.com: Hey, I would like to request the support of other HTTP methods (other than GET and POST) in urllib.request. While it’s actually simple enough to override the Request class to add such a possibility, I think it is far too simple to leave it out of the standard library. I’ve attached a patch that adds the functionality with a simple `method` property. The `get_method` function then simply looks if a custom method was entered, and otherwise falls back to the default behaviour. Thanks a lot! Patrick Westerhoff Btw. Being a Git user, I hope the patch is actually useful ;) -- components: Library (Lib) files: urllib.patch keywords: patch messages: 145283 nosy: poke priority: normal severity: normal status: open title: Add support for other HTTP methods in urllib.request type: feature request versions: Python 3.2, Python 3.3, Python 3.4 Added file: http://bugs.python.org/file23362/urllib.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13142 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13142] Add support for other HTTP methods in urllib.request
Patrick Westerhoff patrickwesterh...@gmail.com added the comment: Oh sorry, I didn’t see that one. :) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13142 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1673007] urllib2 requests history + HEAD support
Changes by Patrick Westerhoff patrickwesterh...@gmail.com: -- nosy: +poke ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1673007 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
