[issue39847] EnterNonRecursiveMutex on win32 can hang for 49.7 days: use GetTickCount64() rather than GetTickCount()
Change by And Clover : -- pull_requests: +18309 pull_request: https://github.com/python/cpython/pull/18959 ___ Python tracker <https://bugs.python.org/issue39847> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39847] EnterNonRecursiveMutex on win32 can hang for 49.7 days: use GetTickCount64() rather than GetTickCount()
Change by And Clover : -- keywords: +patch pull_requests: +18136 stage: -> patch review pull_request: https://github.com/python/cpython/pull/18780 ___ Python tracker <https://bugs.python.org/issue39847> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39847] EnterNonRecursiveMutex on win32 can hang for 49.7 days: use GetTickCount64() rather than GetTickCount()
And Clover added the comment: Yep, should be straightforward to fix (though not to test, as fifty-day test cases tend to be frowned upon...) -- ___ Python tracker <https://bugs.python.org/issue39847> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39847] EnterNonRecursiveMutex on win32 can hang for 49.7 days
New submission from And Clover : Since bpo-15038, waiting to acquire locks/events/etc from _thread/threading on Windows can fail to return long past the requested timeout. Cause: https://github.com/python/cpython/blob/3.8/Python/thread_nt.h#L85 using 32-bit GetTickCount/DWORD, which will overflow at around 49.7 days of uptime. If the WaitForSingleObjectEx call in PyCOND_TIMEDWAIT returns later than the 'target' time, and the tick count overflows in that gap, 'milliseconds' will become very large (up to another 49.7 days) and the next PyCOND_TIMEDWAIT will be stuck for a long time. Where we've seen it is where it's most likely to happen: when the machine is hibernated during the WaitForSingleObjectEx call. I believe the TickCount continues to increase during hibernation so there is a much bigger gap between 'target' and 'now' for the overflow to happen in. Simplest fix is probably to switch to GetTickCount64/ULONGLONG. We should be able to get away with using this now we no longer support WinXP. -- components: Library (Lib), Windows messages: 363346 nosy: aclover, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: EnterNonRecursiveMutex on win32 can hang for 49.7 days type: behavior versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue39847> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23434] support encoded filename in Content-Disposition for HTTP in cgi.FieldStorage
And Clover added the comment: > Are you saying there is no (http) RFC compliant way to fix this Sadly, yes. And though RFCs aren't always a fair representation of real-world use, RFC 7578 is informative as well as normative: at present nothing produces "filename*=" in multipart/form-data. -- ___ Python tracker <https://bugs.python.org/issue23434> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23434] support encoded filename in Content-Disposition for HTTP in cgi.FieldStorage
And Clover added the comment: HTTP generally isn't an RFC 822-family standard. Its headers look a lot like it, but they have their own defined syntax that differs in niggling little details. Using mail parsing code for HTTP isn't usually the right thing. HTTP has always used its own syntax definitions for the headers on the main request/response entities, but it has traditionally partially deferred to RFC 822-family specs for the definitions of structured entity bodies. This is moot, however, as the reality of what browsers support has rarely coincided with those specs. Nowadays HTML5.2 explicitly defers to RFC 7578 for definition of multipart/form-data headers. (This RFC is a replacement for the vague and broken RFC 2388.) As is to be expected for an HTML5-related spec, RFC 7578 shrugs and documents existing browser behaviour [section 4.2]: - some browsers do UTF-8 - some browsers do data mangling (IE's %-encoding sadness) - some browsers might do something else but it explicitly rules out the solution proposed here: "The encoding method described in [RFC5987], which would add a 'filename*' parameter to the Content-Disposition header field, MUST NOT be used." The introductions of both RFC 5987 and RFC 6266 explicitly exclude multipart/form-data headers from their remit. So in summary: - we shouldn't do anything - the situation with submitted filenames will continue to be broken for everyone indefinitely -- nosy: +aclover ___ Python tracker <https://bugs.python.org/issue23434> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22107] tempfile module misinterprets access denied error on Windows
And Clover added the comment: Attempting to answer the question "did this open call fail because the path was a directory" by implication from "do we think we ought to be able to write a file to this directory" is IMO doomed. There's no reliable way to determine whether one should be able to write to a location, short of trying to write to it. There isn't in general and there especially isn't on Windows, for the reasons discussed by Eryk and more. I believe Billy's patch is an improvement over what we have, in as much as it's specifically checking for the condition we care about to work around a shortcoming of Windows error reporting. I would further remove the use of os.access, which does nothing useful (it reflects the read-only file attribute, which no-one uses, and which doesn't exist for directories anyway). Yes, there is a race condition if the directory goes away between use and check, but it seems vanishingly unlikely this could happen by accident, and it could only happen on purpose if an attacker can guess the random filenames in which case they already have worse attacks than just making mkstemp fail. In general failure is a much better outcome than hanging for hours on end. We may be overthinking this. Maybe it is OK to treat all permission errors as maybe-file-exists errors, like issue 18849 originally did, and just retry without trying to pick apart the entrails. ...just not quite as many as 2147483647 times. Given how unlikely an accidental filename clash is in the first place, I'm thinking a more realistic number of retries might be something like, 2. `os.TMP_MAX` probably isn't a good choice in any case, as it indicates the number of names C's tmpnam() can come up with, which (a) is unrelated to the number of names _RandomNameSequence can come up with and (b) we have no particular reason to try to completely exhaust anyway. -- nosy: +aclover ___ Python tracker <https://bugs.python.org/issue22107> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20770] Inform caller of smtplib STARTTLS failures
And Clover added the comment: This is CVE-2016-0772 and appears to have been fixed properly with an exception here: https://hg.python.org/cpython/rev/d590114c2394 (py3) https://hg.python.org/cpython/rev/b3ce713fb9be (py2) -- resolution: -> fixed status: open -> closed ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue20770> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16679] Add advice about non-ASCII wsgiref PATH_INFO
Andrew Clover added the comment: > Why only PATH_INFO is encoded in such a manner, but QUERY_STRING is passed > without any changes and does not requires any latin-1 to utf-8 recodings? Laziness: QUERY_STRING should be pure-ASCII, making any such transcoding a no-op. In principle a user agent *can* submit non-ASCII characters in a query string without %-encoding them, but it's not standards-conformant and most browsers don't usually do it (exception: apparently curl as above), so it's not worth adding a layer of hopefully-fixing-but-potentially-mangling to this variable to support a situation that shouldn't arise for normal requests. PATH_INFO only requires special handling because of the sad, sad historical artefact of the CGI spec requiring it to have URL-decoding applied to it at the gateway, thus making the non-ASCII characters pop out of the percentage woodwork. @Graham can you share more about how those test results were generated and displayed? The Gunicorn results are about what I would expect - the double-decoding of PATH_INFO is arguably undesirable when curl submits raw bytes, but ultimately that's an unspecified situation so I don't really case. The output from Apache, on the other hand, is odd - something appears to have mangled the results at the reporting stage as not only is there double-decoding but also some double-backslashes. It looks like the strings have been put through ascii(repr()) or something? -- nosy: +Andrew Clover ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue16679> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20770] Inform caller of smtplib STARTTLS failures
New submission from And Clover: When an SMTP server responds to the STARTTLS command with an error, the smtplib.SMTP.starttls() method does not raise an exception, as it would if TLS negotiation itself failed. Consequently naïve callers of the function may assume that a TLS connection has actually been established and continue to send sensitive mail through the interface. In reality starttls() returns a tuple of response code and message from which the fail state can be detected, but this is not documented and no caller code I've met does anything with it. Either: 1. Treat it as a doc bug for 3.4. The return value should be documented and callers warned that they need to check that value[0]==220 before assuming they have negotiated TLS. Or, 2. starttls() should raise SMTPResponseException for responses other than 220 in a future Python version, especially if moving towards validate-by-default. Possibly only raise an exception if the SSLContext.verify_mode is REQUIRED? -- components: Library (Lib) messages: 212192 nosy: aclover priority: normal severity: normal status: open title: Inform caller of smtplib STARTTLS failures type: behavior versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20770 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20770] Inform caller of smtplib STARTTLS failures
And Clover added the comment: This could potentially be considered a security issue as it would allow a MitM attacker to sabotage the STARTTLS and get the rest of the content in the clear. I don't personally consider it too serious as I doubt anyone is (a) relying on the security of this for lowly mail and (b) has the rest of the context stuff set up to validate the TLS connection properly anyhow, but there's an argument for sec bug. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20770 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9022] TypeError in wsgiref.handlers when using CGIHandler
And Clover added the comment: (This issue should be closed; it is superseded by the fix for 10155 in Python 3.2.) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9022 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10155] Add fixups for encoding problems to wsgiref
And Clover added the comment: (belated close-fixed) -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10155 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16679] Wrong URL path decoding
And Clover added the comment: WSGI's usage of ISO-8859-1 for all HTTP-byte-originated strings is very much deliberate; we needed a way to preserve the original input bytes whilst still using unicode strings, and at the time surrogateescape was not available. The result is counter-intuitive but at least it is finally consistent; the expectation is that most web authors will be using some kind of web framework or input-reading library that will hide away the unpleasant details. See http://mail.python.org/pipermail/web-sig/2007-December/thread.html#3002 and http://mail.python.org/pipermail/web-sig/2010-July/thread.html#4473 for the background discussion. In any case we cannot assume a path is UTF-8 - not every URI is known to have come from an IRI so RFC 3987 does not necessarily apply. UTF-8-with-Latin1-fallback is also undesirable in itself as it adds ambiguity - an ISO-8859-1 byte sequence that by coincidence happens to be a valid UTF-8 byte sequence will get mangled. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16679 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2193] Cookie Colon Name Bug
And Clover a...@doxdesk.com added the comment: @carsten.klein: there is no such thing as an “original RFC”. The RFCs that have been produced on the subject of cookies, 2109 and 2965, were drawn up long after user-agents implemented cookies. Their attempts to clean up the warts of cookies and implement new features have completely failed. Their strictures are not obeyed by user agents; they are irrelevant and should not be used as the basis for any server-side cookie implementation. The nearest to an original standard for cookies is the Netscape cookie-spec (see eg http://curl.haxx.se/rfc/cookie_spec.html), which is far too woolly to really count as a real specification, but which allows all but `;`, `,` and space, and in practice browsers do typically allow all characters that do not already serve as delimiters. Python should be liberal in what it accepts. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2193 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10155] Add fixups for encoding problems to wsgiref
And Clover a...@doxdesk.com added the comment: No, not specifically. My patch is conservative about what variables it recodes, yours more liberal, but it's difficult to say which is the better approach, or what PEP requires. If you're happy with the current patch, go ahead, let's have it for 3.2; I don't foresee significant problems with it. It's unlikely anyone is going to be re-using the SSL_ or REDIRECT_ variable names for something other than what Apache uses them for. There might be some confusion from IIS users over what encoding REMOTE_USER should be in, but I can't see any consistent resolution for that issue, and we'll certainly be in a better position than we are now. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10155 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10490] mimetypes read_windows_registry fails for non-ASCII keys
Changes by And Clover a...@doxdesk.com: -- type: - behavior ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10490 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10490] mimetypes read_windows_registry fails for non-ASCII keys
New submission from And Clover a...@doxdesk.com: The `enum_types` function in `MimeTypes.read_windows_registry` tries to `.encode` the results of `EnumKey`, assuming it to be a Unicode string. However, `_winreg.EnumKey` in Python 2.x actually returns a byte string (straight from the ANSI version of the registry interface). Consequently, if there is a MIME type registered with a non-ASCII character in its name (invalid, but not unheard of), initialising `MimeTypes` will raise a `UnicodeDecodeError`. This is not caught (it is only expecting a `UnicodeEncodeError`), so it bombs out whatever module indirectly caused `mimetypes.init()` to be called. This attempt to `.encode` the `ctype` should simply be removed. -- components: Library (Lib) files: mimetypes-patch2-2.7.patch keywords: patch messages: 121929 nosy: aclover priority: normal severity: normal status: open title: mimetypes read_windows_registry fails for non-ASCII keys versions: Python 2.7 Added file: http://bugs.python.org/file19745/mimetypes-patch2-2.7.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10490 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10490] mimetypes read_windows_registry fails for non-ASCII keys
Changes by And Clover a...@doxdesk.com: Removed file: http://bugs.python.org/file19745/mimetypes-patch2-2.7.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10490 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10490] mimetypes read_windows_registry fails for non-ASCII keys
Changes by And Clover a...@doxdesk.com: Added file: http://bugs.python.org/file19746/mimetypes-patch2-2.7.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10490 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10155] Add fixups for encoding problems to wsgiref
And Clover a...@doxdesk.com added the comment: Thanks. Some of those additions in _needs_transcode are potentially controversial, though. I'm not wholly sure it's the right thing to transcode these. Some of them may not actually come from the request, eg `REMOTE_USER` may be filled in by IIS's Windows authentication using a native-Unicode string from the Windows user database. Is it the right thing to turn it into UTF-8-bytes-in-Unicode for consistency with Apache? Maybe. (At least for most of the other new envvars there will never see a non-ASCII character. Or in `REMOTE_IDENT`'s case never be used for anything.) The case with the REDIRECT_HTTP_ and SSL_ envvars is an interesting one. Whilst transcoding them at some point will very probably be what applications need to do if they want to actually use them, is it within CGIHandler's remit to change Apache mod-specific variables that are not specified by CGI or WSGI? (There might, after all, be lots of these to catch for other mods and servers, and it's *conceivable* that somebody might be re-using one of these names to set in the environment for some other purpose, in which case transcoding would be adding an unexpected mangling. We can't in the general case expect users to know to avoid envvar names are used as non-standard extensions in all servers.) REDIRECT_HTTP_ at least comes from the HTTP request, so I guess the consistency is good there. (But then I think the only header that actually may contain non-ASCII is REDIRECT_URL, which replaces the unescaped SCRIPT_NAME and PATH_INFO; that one isn't caught at the moment.) -- versions: -Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10155 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10155] Add fixups for encoding problems to wsgiref
Changes by And Clover a...@doxdesk.com: Removed file: http://bugs.python.org/file19303/wsgiref-patches-3.2a3.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10155 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10155] Add fixups for encoding problems to wsgiref
And Clover a...@doxdesk.com added the comment: Ah, sorry, submitted wrong patch against 3.2, disregard. Here's the 'proper' version (the functionality isn't changed, just the former patch had an unused and-Falsed out clause for reading environb, which in the end I decided not to use as the surrogateescape approach already covers it just as well for values). @Éric: yes. Actually the whole patch is pretty much new functionality, which should not be considered for a 2.7.x bugfix release. I've submitted a patch against 2.7 for completeness and for the use of a separately-maintained post-2.7 wsgiref, but unless there is ever a Python 2.8 it should never hit stdlib. The status quo wrt Unicode in environ is broken and inconsistent, which an accepted PEP would finally clear up. But there may be webapps deployed that rely on their particular server's current inconsistent environ, and those shouldn't be broken by a bugfix 2.7 or 3.1 release. -- versions: -Python 3.1 Added file: http://bugs.python.org/file19348/wsgiref-patches-3.2a3.proper.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10155 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2193] Cookie Colon Name Bug
And Clover a...@doxdesk.com added the comment: The various attempts by RFCs to codify HTTP cookies are useless and bear no resemblance to what browsers actually do. In the real world, every byte in the range 0x20-0x7E is allowed, except for the semicolon, the equals (in names), and in Opera, in some places, the double-quote. Many browsers even allow most of the control codes! The question of non-ASCII Unicode characters is tricky, but none of them cause a token break. Contrary to RFC2109 and its successors, no browser takes any notice of quoted-string cookies or backslash-escaping, so the effort Cookie.py puts into producing an encoded string and 'parsing' input cookies is completely wasted. It should do what everyone else does: split on semicolon, left-strip the whitespace, split each cookie on first equals. (In reality cookie names and values have no inherent encoding scheme, so if you want to include out-of-band characters like semicolon, control characters or non-ASCII characters you have to use an ad-hoc encoding scheme, often URL-encoding.) -- nosy: +aclover ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2193 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9022] TypeError in wsgiref.handlers when using CGIHandler
And Clover a...@doxdesk.com added the comment: Yes, CGIHandler is broken in 3.0-3.1; wsgiref in general has been in limbo until the whole issue of py3k-WSGI is sorted. This seems to be happening now in PEP . Attached patch to make CGIHandler use the byte interfaces for stdin/stdout, which allows the write calls to work and provides byte streams to the WSGI application as required by PEP . -- keywords: +patch nosy: +aclover Added file: http://bugs.python.org/file19299/issue9022.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9022 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10155] Add fixups for encoding problems to wsgiref
New submission from And Clover a...@doxdesk.com: Currently wsgiref's CGIHandler makes a WSGI environ from the CGI environ without changes. Unfortunately the CGI environ is wrong in a number of common circumstances: - on Windows, the native environ is Unicode, and different servers choose different decodings for HTTP bytes to store in the environ (most notably for PATH_INFO); - on Windows with Python 2.x, os.environ is read from the Unicode native environ using the ANSI encoding, which will lose/mangle non-ASCII characters; - on Posix with Python 3.x, os.environ is read from a native bytes environ using the filesystemencoding which is probably not ISO-8859-1. - on IIS, PATH_INFO inappropriately includes SCRIPT_NAME unless a hidden, rarely-used, and problematic config option is applied. Previously, it was not clear in PEP 333 what was supposed to happen with headers and encodings, especially under Python 3. PEP clears this up. These patches add fixups to wsgiref to try to generate the nearest to a 'correct' environ as per PEP as possible for the current platform and server software. They also fix simple_server to use the correct encoding for PATH_INFO, and include the fix for issue 9022, correspondingly updating the simple_server demo app and tests to conform to PEP 's expectation that headers will be ISO-8859-1-decoded Unicode strings. The test_bytes_validation test is removed: as I understand it, it's no long allowed to use byte string headers/status. -- components: Library (Lib) files: wsgiref-patches-3.2a3.patch keywords: patch messages: 119220 nosy: aclover priority: normal severity: normal status: open title: Add fixups for encoding problems to wsgiref type: behavior versions: Python 2.7, Python 3.2 Added file: http://bugs.python.org/file19303/wsgiref-patches-3.2a3.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10155 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10155] Add fixups for encoding problems to wsgiref
And Clover a...@doxdesk.com added the comment: (patch for Python 2.x, for what it's worth) -- Added file: http://bugs.python.org/file19304/wsgiref-patches-2.7.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10155 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10155] Add fixups for encoding problems to wsgiref
And Clover a...@doxdesk.com added the comment: (same again for branch PJ Eby's wsgiref svn: same as previous 2.7 patch aside from the line numbers) -- Added file: http://bugs.python.org/file19309/wsgiref-patches-eby2692.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10155 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10162] mimetypes read_windows_registry should tolerate permissions errors
New submission from And Clover a...@doxdesk.com: It is relatively common to have keys in the HKEY_CLASSES_ROOT MIME database that are not readable to all users, typically written by third-party applications. (My WinXP test box has a dozen, for apps like Flash, Silverlight and Java.) Currently, initialising mimetypes causes Python to try to read them all, and if the user running Python doesn't have permission to read a key (in particular, if the user is a low-privilege daemon user such as IUSR_...), the script that caused mimetypes to be called will error out. This patch moves the try-block around the call to OpenKey as well as QueryValueEx, allowing the key to be skipped if unreadable. -- components: Library (Lib) files: mimetypes-patch-3.2a3.patch keywords: patch messages: 119252 nosy: aclover priority: normal severity: normal status: open title: mimetypes read_windows_registry should tolerate permissions errors type: feature request versions: Python 2.7, Python 3.2 Added file: http://bugs.python.org/file19314/mimetypes-patch-3.2a3.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10162 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10162] mimetypes read_windows_registry should tolerate permissions errors
And Clover a...@doxdesk.com added the comment: (same against 2.7 branch) -- Added file: http://bugs.python.org/file19315/mimetypes-patch-2.7.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10162 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue691291] codecs.open(filename, 'U', 'UTF-16') corrupts text
And Clover a...@doxdesk.com added the comment: The problem is that codecs.open() forces binary mode on the underlying file object, and this defeats the U mode. Actually the problem is it doesn't defeat it! The function is documented to force binary, but it actually only does mode = mode + 'b', which can leave you with a mode of 'rUb'. This mode should be invalid but in practice the 'U' wins out, and causes the expected problems for UTF-16 and some East Asian codecs. Until such time as text/universal mode is supported at the overlying decoded stream level, I suggest that 'U' should be .replace()d out of the mode as well as 'b' being added, as the documentation would imply. -- nosy: +aclover ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue691291 ___ ___ 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
And Clover [EMAIL PROTECTED] added the comment: I would like to see something along the general lines of bmiller's patch for dict views in a 3.x release... there are probably other iterators that could do with chattier reprs also. (Range, on the other hand, is fine as it is.) It's not just at the interactive prompt that good reprs are useful, it's also in debugging: debug-prints in scripts in general, web application error pages that dump variable information, error detail logging to a database for inspection long after the ability to inspect the value has passed, and so on. I think it's better to put the feature in repr than require all these things - everything that might want to display values helpfully - to implement detection and prettification for specific iterators. Sure, you can apply list() if you know in advance you're going to need to, but for beginners and debuggers getting the information out there without having to ask for it is a real win. I certainly remember how pleasantly surprised I was when learning Python 1.something and finding it just told me what I wanted to know without having to ask for it - in contrast to previous tedious languages that only ever said 'object' or '[Array]'... I can't really think of any advantage to having repr keep that information hidden. -- nosy: +aclover ___ 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
