[issue10917] PEP 333 link to CGI specification is broken
Georg Brandl ge...@python.org added the comment: Fixed in r88045 (also in PEP ). -- nosy: +georg.brandl resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10917 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10915] Make the PyGILState API compatible with multiple interpreters
Antoine Pitrou pit...@free.fr added the comment: The bulk of use cases is going to be simple callbacks via the same thread that called out of Python in the first place. [...] This is what SWIG effectively does in its generated wrappers for callbacks. Thanks for clarifying. I agree the TLS scheme would help in these cases. There is still the question of what/who updates the TLS mapping; you are proposing a new API call; an alternative is to do the mapping in e.g. PyEval_SaveThread(). The reality is that if you force a change on every single extension module doing callbacks into the interpreter without having the GIL first, you will never see people update their code as they will likely not care about this special use case. And so the whole point of adding the additional APIs will be wasted effort and have achieved nothing. I'm not sure I care. If people don't want to use the new APIs on the basis that they are slightly more complex, then it's their problem. The Python C API tries not to be too cumbersome, but it cannot pretend to be as transparent as a high-level API in a dynamic language. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10915 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10915] Make the PyGILState API compatible with multiple interpreters
Nick Coghlan ncogh...@gmail.com added the comment: There's no point improving the multiple interpreter support if it doesn't help applications that are currently broken because of that lack of support. I believe the patch as currently proposed actually makes things *worse*. With autoTLSkey as a static variable, all subinterpreters will use the same key to point into thread local storage (which is defined process-wide). This means they won't tread on each other's toes: the interpreter that creates a thread owns that thread. So Graham's simple use case *should already work*, as the creation of the thread by the subinterpreter will populate autoTLSkey with a valid thread state, which will then be used by calls back in to the GILState API. Looking at 3.2, there appear to be two ways for an application to get itself into trouble: 1. Hand off an OS level thread from the creating interpreter to a different subinterpreter. As far as I can tell, calling GILState_Ensure in such a thread will still acquire the GIL of the creating interpreter (or something equally nonsensical). I may be misreading that though - this isn't exactly the easiest part of the code base to follow :) 2. Native (non-Python) threads will always have their temporary thread state created in the main interpreter unless the application takes steps to precreate a thread state using a different interpreter. So, a new PyGILState_EnsureEx API may be beneficial regardless in order to help with part 2 of the problem, but I think it should be used solely as a way to override autoInterpreterState. autoTLSkey should be left alone so that a given OS level thread can only be owned by one interpreter at a time. Further, there is no need for any function with access to a valid thread state (i.e. _PyGILState_NoteThreadState, as well as PyGILState_Release if autoTLSkey remains a static variable) to take an interpreter argument. These functions can identify the relevant interpreter from the interp field of the thread state. TL;DR version: - I agree the compatibility between multiple interpreters and the GILState API can be improved - I agree a PyGILState_EnsureEx that takes an interpreter argument should be part of that solution. - I *disagree* with making autoTLSkey interpreter specific, as it seems to me that will make the situation worse rather than better. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10915 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2275] urllib/httplib header capitalization
Éric Araujo mer...@netwok.org added the comment: Title case is not the right thing for all headers: TE, WWW-Authenticate, etc. While we're changing this, why not implement something to return headers in the order recommended in the RFC? (Probably another feature request) -- nosy: +eric.araujo stage: - patch review title: urllib2 header capitalization - urllib/httplib header capitalization versions: +Python 3.3 -Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2275 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10915] Make the PyGILState API compatible with multiple interpreters
Nick Coghlan ncogh...@gmail.com added the comment: Added Mark Hammond to the nosy list, as the original author and implementor of PEP 311 (which added the GILState APIs). Mark, since your PEP deliberately punted on multiple interpreter support, feel free to take yourself off the list again. If you spot any glaring errors in my post above it would be nice to know, though :) -- nosy: +mhammond ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10915 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10918] **kwargs unnecessarily restricted in API
New submission from Adrian Dries adr...@gmail.com: An API such as in, e.g. futures: def submit(self, fn, *args, **kwargs): pass cannot be used thus: submit(foo, 1, 2, fn=bar) I can see two options: either mangle the named parameters: def submit(__self, __fn, *args, **kwargs): pass Or fiddle with *args: def submit(*args, **kwargs): self, fn = args[:2] args = args[2:] -- components: Library (Lib) messages: 126367 nosy: avdd priority: normal severity: normal status: open title: **kwargs unnecessarily restricted in API type: behavior versions: Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10918 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10918] **kwargs unnecessarily restricted in API
Changes by Georg Brandl ge...@python.org: -- assignee: - bquinlan nosy: +bquinlan versions: +Python 3.3 -Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10918 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10919] Environment variables are not expanded in _winreg when using REG_EXPAND_SZ.
New submission from Richard Nienaber rjniena...@gmail.com: According to Microsoft documentation (http://msdn.microsoft.com/en-us/library/ms724884(v=vs.85).aspx) when using the REG_EXPAND_SZ value type, environment variables (e.g. %programfiles%) should be expanded to their values (e.g. 'C:\Program Files'). I've added a test case that reproduces this error. -- components: Library (Lib) files: testcase-24042.py messages: 126368 nosy: rjnienaber priority: normal severity: normal status: open title: Environment variables are not expanded in _winreg when using REG_EXPAND_SZ. versions: Python 2.7 Added file: http://bugs.python.org/file20418/testcase-24042.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10919 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10919] Environment variables are not expanded in _winreg when using REG_EXPAND_SZ.
Brian Curtin cur...@acm.org added the comment: Assigning to myself. Relevant IronPython issue: http://ironpython.codeplex.com/workitem/24042 -- assignee: - brian.curtin components: +Extension Modules, Windows -Library (Lib) nosy: +brian.curtin stage: - needs patch type: - behavior ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10919 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10920] cp65001, PowerShell, Python crash.
New submission from Jean-Michel Fauth wxjmfa...@gmail.com: Just relying a discussion open on comp.lang.python, http://groups.google.com/group/comp.lang.python/browse_thread/thread/771aa9081ad6584c# 1) Windows 7, open PowerShell 2) Change code page to cp65001 3) Launch Python3.1.2 or Python3.2.rc1 - crash Key points: - The fact that Python does not recognize cp65001 is ok. - The Python crash is unexpected. -- components: Windows messages: 126370 nosy: Jean-Michel.Fauth priority: normal severity: normal status: open title: cp65001, PowerShell, Python crash. type: crash versions: Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10920 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10917] PEP 333 link to CGI specification is broken
anatoly techtonik techto...@gmail.com added the comment: w00t -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10917 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2636] Regexp 2.7 (modifications to current re 2.2.2)
Matthew Barnett pyt...@mrabarnett.plus.com added the comment: That line crept in somehow. As it's been there since the 2010-12-24 release and you're the first one to have a problem with it (and you've already fixed it), it looks like a new upload isn't urgently needed (I don't have any other changes to make at present). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2636 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10917] PEP 333 link to CGI specification is broken
Georg Brandl ge...@python.org added the comment: Not sure I understand you... -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10917 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10917] PEP 333 link to CGI specification is broken
anatoly techtonik techto...@gmail.com added the comment: Nevermind. It's just another word for gr8. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10917 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10917] PEP 333 link to CGI specification is broken
Benjamin Peterson benja...@python.org added the comment: Well, that really grates on the eyes. -- nosy: +benjamin.peterson ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10917 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10917] PEP 333 link to CGI specification is broken
Benjamin Peterson benja...@python.org added the comment: 2011/1/16 anatoly techtonik rep...@bugs.python.org: anatoly techtonik techto...@gmail.com added the comment: Nevermind. It's just another word for gr8. Well, it really grates on the eyes. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10917 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10917] PEP 333 link to CGI specification is broken
anatoly techtonik techto...@gmail.com added the comment: No surprises. Core Python community is so old that it is unlikely that people there ever experienced online gameplay. The only online game they've ever installed was probably EVE Online and if they've installed it - that was just because Stackless wiki is not sane enough in describing all awesomeness of this Python flavor. But it is more likely in this situation that they've just watched CCP videos. =) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10917 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10920] cp65001, PowerShell, Python crash.
Changes by Antoine Pitrou pit...@free.fr: -- nosy: +haypo priority: normal - high ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10920 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10920] cp65001, PowerShell, Python crash.
Antoine Pitrou pit...@free.fr added the comment: Probably a legitimate crash (aka deliberate abort), since Python needs an encoding for its standard input/output text streams, and the encoding suggested by the system (cp65001) isn't supported. -- nosy: +pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10920 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10911] cgi: add more tests
Changes by Antoine Pitrou pit...@free.fr: -- type: - feature request versions: +Python 3.3 -Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10911 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10920] cp65001, PowerShell, Python crash.
STINNER Victor victor.stin...@haypocalc.com added the comment: PS D:\jm chcp 65001 Page de codes active : 65001 Please don't do that: it is useless (it doesn't help to display or read more unicode characters) and it breaks Windows console: see issue #1602 (especially msg120414 and msg126303), and maybe also issue #6058. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10920 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10914] Python sub-interpreter test
Amaury Forgeot d'Arc amaur...@gmail.com added the comment: +1 for this kind of tests. But I would not have their source in the official Modules directory. I expect that there will be several tests of this kind, each one with different modules to import, functions to run, global settings to change. IMO the C code should be somewhere in the test directory; later we could use templates to generate source code for similar tests. Is it possible to use distutils to compile this test, and remove it from the Makefile? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10914 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10920] cp65001, PowerShell, Python crash.
STINNER Victor victor.stin...@haypocalc.com added the comment: If the crash is the following message, this issue is a duplicate of #6058. --- PS D:\jm c:\python31\python.exe Fatal Python error: Py_Initialize: can't initialize sys standard streams LookupError: unknown encoding: cp65001 --- It is not a crash: Python has no codec for the code page 65001, that's all. I closed #6058 because cp65001 cannot be set as an alias to utf-8. Anyway, use 65001 as console encoding is not a good idea. I close this issue: see #1602 for more information. -- resolution: - duplicate ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10920 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10914] Python sub-interpreter test
Benjamin Peterson benja...@python.org added the comment: There's already precedent for test modules in Modules/ what with xxmodule.c and _testcapimodule.c. -- nosy: +benjamin.peterson ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10914 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10919] Environment variables are not expanded in _winreg when using REG_EXPAND_SZ.
Richard Nienaber rjniena...@gmail.com added the comment: Further documentation on the RegEnumValue function (used by the _winreg module): http://msdn.microsoft.com/en-us/library/ms724865(v=vs.85).aspx. The documentation doesn't say whether the string is expanded or not on retrieval. Given the current behaviour plus the ExpandEnvironmentStrings function, this seems like a non-issue. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10919 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10914] Python sub-interpreter test
Antoine Pitrou pit...@free.fr added the comment: Is it possible to use distutils to compile this test, and remove it from the Makefile? I'm not aware that distutils is able to compile applications rather than extension modules, but that would certainly be better than a rule in the Makefile, yes. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10914 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10914] Python sub-interpreter test
Amaury Forgeot d'Arc amaur...@gmail.com added the comment: In distutils.command.config, config().try_run(body) is probably what we need. Now, I don't know how to use it... -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10914 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10921] imaplib: Internaldate2tuple crashes, does not handle negative TZ offsets, does not handle DST correctly, and outputs localtime (not UTC)
New submission from Joe Peterson j...@skyrush.com: Internaldate2tuple() is broken in several ways. The last two issues have existed in the code for some time. New issues in Python 3: 1. It crashes with KeyError. This is because the Mon2num dictionary's keys are strings, not bytes objects (note that other strings in imaplib have been updated, but not Mon2num). 2. The sign of the TZ offset (e.g. -0700) is compared to the string '-', not b'-', so the compare is never true, causing a large error when TZ offset is negative. Left over from Python 2.x: 3. DST is not handled correctly. Specifically, when the date is such that its local time form and its UTC form (if both interpreted as local time) are on different sides of a DST changeover, the result will be off by one hour. This is because the check for DST is done after treating the time as local time, even if it is not local time, causing it be tested while sometimes on the wrong side of a DST change. This can be corrected by using calls that keep time in UTC. 4. Related to #3, the result is returned in local time, whereas the documentation states that the result is in UT. The fix for #3 takes care of this one, as well. Here is an example: Run the following two dates, that represent exactly the same time, through Internaldate2tuple: '25 (INTERNALDATE 01-Apr-2000 19:02:23 -0700)' '101 (INTERNALDATE 02-Apr-2000 02:02:23 +)' Once the Mon2num issue is fixed, Python 3 will perform the conversions, but with a 15 hour difference. Python 2 will produce results with a one hour difference. Note that the last two issues (but describing only #4 above) were also addressed in a similar way in an old post I found by Colin Brown in 2004 (http://www.velocityreviews.com/forums/t336162-imaplib-function-bug.html). -- components: Library (Lib) files: imaplib_Internaldate2tuple.patch keywords: patch messages: 126386 nosy: lavajoe priority: normal severity: normal status: open title: imaplib: Internaldate2tuple crashes, does not handle negative TZ offsets, does not handle DST correctly, and outputs localtime (not UTC) versions: Python 3.2 Added file: http://bugs.python.org/file20419/imaplib_Internaldate2tuple.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10921 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10921] imaplib: Internaldate2tuple crashes, does not handle negative TZ offsets, does not handle DST correctly, and outputs localtime (not UTC)
Changes by Joe Peterson j...@skyrush.com: -- type: - crash ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10921 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10921] imaplib: Internaldate2tuple() crashes, does not handle negative TZ offsets, does not handle DST correctly, and outputs localtime (not UTC)
Changes by Joe Peterson j...@skyrush.com: -- title: imaplib: Internaldate2tuple crashes, does not handle negative TZ offsets, does not handle DST correctly, and outputs localtime (not UTC) - imaplib: Internaldate2tuple() crashes, does not handle negative TZ offsets, does not handle DST correctly, and outputs localtime (not UTC) ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10921 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10915] Make the PyGILState API compatible with multiple interpreters
Graham Dumpleton graham.dumple...@gmail.com added the comment: Nick, I think you are making the wrong assumption that an external threads will only ever call into the same interpreter. This is not the case. In mod_wsgi and mod_python there is a pool of external threads that for distinct HTTP requests, delegated to a specific thread, can make calls into different interpreters. This is all fine so long as you ensure that for each thread, it uses a distinct thread state for that thread for each interpreter. In other words, you cant use the same thread state instance across multiple interpreters as it is bound to a specific interpreter. This is because autoInterpreterState is always going to be set to the main interpreter. This means that when the thread is calling into a new sub interpreter it will either inherit via current GIL state API an existing thread state bound to the main interpreter, or if one is created, will still get bound to the main interpreter. As soon as you start using a thread state bound to one interpreter against another, problems start occurring. After thinking about this all some more I believe now what is needed is a mix of the TLS idea for current interpreter state that I am suggesting and in part the extended GIL state functions that Antoine describes. So, the TLS records what interpreter a thread is currently running against so that GIL state APIs work for existing unmodified extension modules. At the same time though, you still need a way of switching what interpreter a thread is running against. For the latter, various of the thread state related functions that exist already could do this automatically. In some cases you will still need the extended function for acquisition that Antoine suggested. Consider a few scenarios of usage. First off, when an external thread calls PyInterpreter_New(), it creates a new thread state object against that new sub interpreter automatically and returns it. With this new systems, it would also automatically update the TLS for the current thread to be that new interpreter also. That way when it calls into Python which then calls back out to code which releases the GIL and then calls back in through PyGILState_Ensure(), with no arguments, it will work. This obviously implies though that PyGILState_Ensure() makes use of the TLS for the interpreter being used and isn't hard wired to the main interpreter like it is now. Second, consider some of the other API functions such as PyThreadState_Swap(). When passing it a non NULL pointer, you are giving it a thread state object which is already bound to an interpreter. It thus can also update the TLS for the interpreter automatically. If you pass it a NULL then it clears the TLS with all functions later that rely on that TLS asserting that it is not NULL when used. Another similar case where TLS can be auto updated is functions which clear/delete an interpreter state and leave GIL unlocked at the end. These also would clear the TLS. So, it is possible that that no new API functions may be needed to manage the TLS for what interpreter is associated with the current thread, as I thought, as existing API functions can do that management themselves transparently. The third and final scenario, and the one where the extended GIL state functions for Ensure is still required, is where code doesn't have the GIL as yet and wants to make a call into sub interpreter rather than the main interpreter, where it already has a pointer to the sub interpreter and nothing more. In this case the new PyGILState_EnsureEx() function is used, with the sub interpreter being passed as argument. The beauty of existing API functions of PyThreadState_Swap() etc managing the TLS for the interpreter is that the only code that needs to change is the embedded systems which are creating and using multiple interpreters in the first place. In other words, mod_wsgi would need to change, with it simply replacing all the equivalent stuff it already has for doing what PyGILState_??? functions do now but against sub interpreters. If I am right, all extension modules that don't really care about whether sub interpreters are being used should work without modification. Oh, and I also think you probably don't need PyGILState_ReleaseEx() if all made TLS aware, just the single PyGILState_EnsureEx() is needed. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10915 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10921] imaplib: Internaldate2tuple() crashes, does not handle negative TZ offsets, does not handle DST correctly
Joe Peterson j...@skyrush.com added the comment: Regarding problem #4, it actually appears that returning local time is the right thing to do, since it matches the behavior of Time2Internaldate(). Returning UTC, as the doc states, would potentially break IMAP append() that can include an internaldate possibly returned from Internaldate2tuple() in typical usage (like when copying messages). In this case, the doc is wrong on Internaldate2tuple(). I have attached a new patch to both the code and doc that replaces the old patch. I now return localtime rather than gmtime, but other than that, the DST fix remains the same and now handles the cases near DST changes correctly. Ultimately, it might be desirable to be able always stay in UTC, so perhaps adding UTC variants of both Internaldate2tuple() and Time2Internaldate() (and a UTC option to append()) would be a good enhancement for later. -- assignee: - docs@python components: +Documentation nosy: +docs@python title: imaplib: Internaldate2tuple() crashes, does not handle negative TZ offsets, does not handle DST correctly, and outputs localtime (not UTC) - imaplib: Internaldate2tuple() crashes, does not handle negative TZ offsets, does not handle DST correctly Added file: http://bugs.python.org/file20420/imaplib_Internaldate2tuple.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10921 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10921] imaplib: Internaldate2tuple() crashes, does not handle negative TZ offsets, does not handle DST correctly
Changes by Joe Peterson j...@skyrush.com: Removed file: http://bugs.python.org/file20419/imaplib_Internaldate2tuple.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10921 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10921] imaplib: Internaldate2tuple() crashes, does not handle negative TZ offsets, does not handle DST correctly
Changes by Joe Peterson j...@skyrush.com: -- components: -Documentation ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10921 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10921] imaplib: Internaldate2tuple() crashes, does not handle negative TZ offsets, does not handle DST correctly
Changes by Joe Peterson j...@skyrush.com: -- components: +Documentation ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10921 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10922] Unexpected exception when calling function_proxy.__class__.__call__(function_proxy)
New submission from Daniel Neuhäuser dasdas...@googlemail.com: Upon trying to create a proxy I stumbled upon this exception: Traceback (most recent call last): File foo.py, line 11, in module p.__class__.__call__(p) SystemError: PyEval_EvalCodeEx: NULL globals Investigating further led me to this code which reproduces the exception: class Proxy(object): def __init__(self, proxied): self.proxied = proxied @property def __class__(self): return self.proxied.__class__ def __call__(self): return self.proxied.__call__() p = Proxy(lambda: 1) p.__class__.__call__(p) I understand that `p.__class__.__call__()` expects an argument of a different type however this is not obvious from the exception itself. PyPy on the other hand raises this exception: Traceback (most recent call last): File app_main.py, line 53, in run_toplevel File foo.py, line 11, in module p.__class__.__call__(p) TypeError: 'function' object expected, got 'Proxy' instead Which explains the issue and is expected (at least by me) and apparently Jython raises an exception at least similar to PyPy's. -- components: Interpreter Core messages: 126389 nosy: DasIch priority: normal severity: normal status: open title: Unexpected exception when calling function_proxy.__class__.__call__(function_proxy) type: behavior versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10922 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10923] Python 2.7 hangs on Unicode+threading
New submission from Piotr Maślanka piotr.masla...@henrietta.com.pl:
Python 2.7.1(x86 MSI), binary downloaded from python.org, hangs quite reliably.
Code:
with open(threadspecific, 'ab') as x:
txt = unicode(str_or_unicode_parameter).encode('utf8')
x.write(txt+'\r\n')
However, it doesn't hang if I insert a print statement between with and txt,
with anything. Previous testing determined that it hangs on encode().
Aforementioned code is executed in a threading environment, and it hangs in
thread that is spawned by master thread. Interpreter is left with an open file.
Same behaviour is repeatable on Python 2.5.1.
--
components: None
messages: 126390
nosy: henrietta
priority: normal
severity: normal
status: open
title: Python 2.7 hangs on Unicode+threading
versions: Python 2.7
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10923
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10922] Unexpected exception when calling function_proxy.__class__.__call__(function_proxy)
Andreas Stührk andy-pyt...@hammerhartes.de added the comment: I think this is a duplicate of issue #9756: `methoddescr_call()` checks whether the given argument is acceptable as self argument and does so using `PyObject_IsInstance()`. As the class in the given code returns the type of the proxied object for the `__class__` attribute, that check will return true. As a quick fix, the attached patch (against release27-maint branch) will raise a TypeError as expected by the OP, but the real issue is much broader. -- keywords: +patch nosy: +Trundle Added file: http://bugs.python.org/file20421/check_is_func.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10922 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10923] Python 2.7 hangs on Unicode+threading
Piotr Maślanka piotr.masla...@henrietta.com.pl added the comment:
I runned it over again with code:
print 'Acquiring lock'
self.loglock.acquire()
print 'Attempting to convert'
if type(text) == unicode: text = text.encode('utf8', errors='strict')
print 'Opening '+threadspecific
with open(threadspecific, 'ab') as x: x.write(text+'\r\n')
print 'Closing '+threadspecific
self.loglock.release()
print 'Releasing lock'
It behaves erratically, sometimes working and yielding:
Acquiring lock
Acquiring lock
Attempting to convert
Opening threadspecific_master
Closing threadspecific_master
Releasing lock
Attempting to convert
Opening threadspecific_slave
Closing threadspecific_slave
Releasing lock
And sometimes hanging with:
Acquiring lock
Attempting to convert
Acquiring lock
Looks like a particularly nasty race condition. It gives off no exceptions.
Platform is Windows 7 x64, running with admin privileges.
--
type: - crash
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10923
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10924] Adding salt and Modular Crypt Format to crypt library.
New submission from Sean Reifschneider j...@tummy.com:
Over the years I've written the same code over and over to create a random salt
string of 2 characters. Worse, the Modular Crypt Format is difficult to find
documentation on, so creating stronger hashed passwords is difficult to get
right.
To that end, I'm proposing the addition of a mksalt() method which will
generate a salt, and several METHOD_* values to select which hashing method to
use.
I also figure there will need to be a methods() call that figures out what
methods are available in the library crypt() and return a list of the available
ones.
If we have a way to generate a salt, then I figure we could drop the salt
argument of crypt.crypt(), and if not specified to generate one. So to hash a
password you could do: crypt.crypt('password').
I figure that the best way to accomplish this is to implement this all in
Python and move the existing C crypt module to _crypt.
A patch accomplishing this is attached. Please review.
Attached is a patch to accomplish this.
--
components: Library (Lib)
files: python-underscore_crypt.patch
keywords: easy, needs review, patch
messages: 126393
nosy: jafo
priority: normal
severity: normal
stage: patch review
status: open
title: Adding salt and Modular Crypt Format to crypt library.
type: feature request
versions: Python 3.3
Added file: http://bugs.python.org/file20422/python-underscore_crypt.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10924
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
