[issue44548] ttk Indeterminate Progressbar Not Animating Correctly After `start`
Jim Jewett added the comment: It sounds like the fix is a configuration change already included in the next version, so ... I think that counts as a fix. -- nosy: +Jim.Jewett resolution: -> fixed status: open -> pending ___ Python tracker <https://bugs.python.org/issue44548> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24275] lookdict_* give up too soon
Jim Jewett added the comment: What is the status on this? If you are losing interest, would you like someone else to turn your patch into a pull request? -- ___ Python tracker <https://bugs.python.org/issue24275> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24275] lookdict_* give up too soon
Jim Jewett added the comment: Based on Hristo's timing, it appears to be a clear win. A near-wash for truly string-only dicts that shouldn't be effected; a near-wash for looking up non-(exact-)strings, and a nearly 40% speedup for the target case of looking up but not inserting a non-string or string subclass, then looking up strings thereafter. Additional comments: Barring objections, I will promote from patch review to commit review when I've had a chance to look more closely. I don't have commit privs, but I think some of the others following this issue do. The test looks pretty good enough -- good enough that I wonder if I'm missing something on the parts that seem odd. It would be great if you either cleaned them up or commented to explain why: Why is the first key vx1, which seems, if anything, like a variable? Why not k1 or string_key? Why is the first key built up as vx='x'; vx += '1' instead of just k1="x1"? Using a str subclass in the test is a great idea, and you've created a truly minimal one. It would probably be good to *also* test with a non-string, like 3 or 42.0. I can't imagine this affecting things (unless you missed an eager lookdict demotion somewhere), but it would be good to have that path documented against regression. This seems like a test that could probably be rolled into a bigger testfile for the actual commit. I don't have the name of such an appropriate file at hand right now, but will try to find it on a deeper review. -- ___ Python tracker <https://bugs.python.org/issue24275> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24275] lookdict_* give up too soon
Jim Jewett added the comment: This was originally "can be reopened if a patch is submitted" and Hristo Venev has now done so. Therefore, I am reopening. -- resolution: rejected -> remind stage: -> patch review status: closed -> open versions: +Python 3.10 ___ Python tracker <https://bugs.python.org/issue24275> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41246] IOCP Proactor same socket overlapped callbacks
Change by Jim Jewett : -- stage: patch review -> commit review ___ Python tracker <https://bugs.python.org/issue41246> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13828] Further improve casefold documentation
Jim Jewett added the comment: Unicode probably won't make the correction, because of backwards compatibility. I do support the sentence suggested in Thorsten's most recent reply. Is expanding ligatures the only other normalization it does? Ideally, we should also mention that it shifts to the canonical case, which is usually (but not always) lowercase. I think Cherokee is one that folds to the upper case. On Mon, Aug 24, 2020 at 11:02 AM Thorsten wrote: > > Thorsten added the comment: > > I see. I found the documents. That's an issue. That usage is incorrect. It > is still valid to upper case "ß" to SS since "ẞ" is fairly new as an > official German character, but the other way around is not valid. > > As such the current sentence in documentation also just does not make > sense. > > >"Since it is already lowercase, lower() would do nothing to 'ß'" > > Exactly. Why would it? It is nonsensical to change an already lowercase > character with a lowercase function. > > Suggest to update to: > > "For example, the Unicode standard for German lower case letter 'ß' > prescribes full casefolding to 'ss'. Since it is already lowercase, lower() > would do nothing to 'ß'; casefold() converts it to 'ss'. > In addition to full lowercasing, this function also expands ligatures, for > example, 'fi' becomes 'fi'." > > -- > > ___ > Python tracker > <https://bugs.python.org/issue13828> > ___ > -- ___ Python tracker <https://bugs.python.org/issue13828> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41405] python 3.9.0b5 test
Jim Jewett added the comment: Then I suspect they also exist in even earlier versions, and are actually tied to your development setup. That should still be fixed, but it is probably not in Python's own code. It might be in python's build process, which is still on us. Or it might be in your distribution, or in a dependency like Tk, or in your personal C compiler or setup. Could you look to see what your system's actual passwd file says, and how tcl rounds outside of python, and how many color pairs your curses supports or has? -- versions: +Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue41405> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40841] Provide mimetypes.sniff API as stdlib
Jim Jewett added the comment: There are a zillion reasons a filename could be wrong -- but the standard says to trust the filesystem. So if it sniffs based on contents, it isn't quite following the standard. It is probably still a useful tool, but it won't be the One Right Way, and it isn't even clear that it should replace current heuristics. On Mon, Jul 27, 2020 at 7:22 PM Guido van Rossum wrote: > > Guido van Rossum added the comment: > > Whether the data was retrieved over a network has nothing to do with it. > > There are complementary ways of guessing what data you are working with -- > guess based on the filename extension or sniff based on the contents of the > file (or downloaded data). > > There are a zillion reasons why the filename could be a lie -- e.g. a user > could pick the wrong extension, or rename a file, or a tool could save a > file using the wrong extension or no extension at all. Then again sometimes > the contents of the file might not be enough, e.g. > ``` > foo() // bar > ``` > is both valid Python and valid JavaScript. :-) > > -- > > ___ > Python tracker > <https://bugs.python.org/issue40841> > ___ > -- ___ Python tracker <https://bugs.python.org/issue40841> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41391] Make test_unicodedata pass when running without network
Jim Jewett added the comment: Looks Good To Me -- nosy: +Jim.Jewett ___ Python tracker <https://bugs.python.org/issue41391> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31904] Python should support VxWorks RTOS
Jim Jewett added the comment: Is it safe to say that there is an now intent to support VxWorks within the main tree, with Wind River agreeing to be primary support? And this ticket has become a tracking ticket for the status on getting it there, small PR by small PR plus buildbot? -- nosy: +Jim.Jewett ___ Python tracker <https://bugs.python.org/issue31904> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41407] Tricky behavior of builtin-function map
Jim Jewett added the comment: Why would you raise StopIteration if you didn't want to stop the nearest iteration loop? I agree that the result of your sample code seems strange, but that is because it is strange code. I agree with Steven D'Aprano that changing it would cause more pain than it would remove. Unless it gets a lot more support by the first week of August, I recommend closing this request as rejected. -- nosy: +Jim.Jewett status: open -> pending ___ Python tracker <https://bugs.python.org/issue41407> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18280] Documentation is too personalized
Jim Jewett added the comment: I won't speak of nroff or troff in particular, but many programs had trouble distinguishing the end of a sentence from an honorific abbreviation, such as Mr. Spock or Dr. Seuss. -- nosy: +Jim.Jewett ___ Python tracker <https://bugs.python.org/issue18280> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40841] Provide mimetypes.sniff API as stdlib
Jim Jewett added the comment: The standard itself says that it only applies to content served over http; if the content is retrieved by ftp or from a file system, then you should trust that. I don't notice that in the code you pointed to. So maybe filetype is the right answer if the data isn't coming over the network? For whatwg demonstration code, it is reasonable to assume that, but in python -- at a minimum, you should document the assumption prominently in the docs and docstring. -- nosy: +Jim.Jewett ___ Python tracker <https://bugs.python.org/issue40841> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41409] deque.pop(index) is not supported
Jim Jewett added the comment: It may well have been intentional, as deques should normally be mutated only at the ends. But Raymond did make changes to conform to the ABC, so this should probably be supported too. Go ahead and include docstrings and/or discouraging it, though, except for i=0 and i=-1 -- nosy: +Jim.Jewett ___ Python tracker <https://bugs.python.org/issue41409> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41405] python 3.9.0b5 test
Jim Jewett added the comment: Is this a platform where 3.8 was working? The curses test seems to think you have too many color-pairs defined, and this might well be part of a semi-compatible curses library. I guess I would add some output to the test showing how many (and which) color pairs it thinks there are. The pwd complaint is correct, but seems like it is complaining about the interface between python and your OS. The tkinter problem is really a failure to round a floating point, and I would be surprised if python had made changes there recently. I would be slightly less surprised if something in the compile chain of tk for your system hard-coded a specific rounding format. -- nosy: +Jim.Jewett ___ Python tracker <https://bugs.python.org/issue41405> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41220] add optional make_key argument to lru_cache
Jim Jewett added the comment: Going back to Raymond's analysis, this is useful when at least some of the parameters either do not change the result, or are not hashable. At a minimum, you need to figure out which parameters those are, and whether to drop them or transform them. Is this already sufficiently rare or tricky that a subclass is justified, instead of trying to shoehorn things into a single key method? -- nosy: +Jim.Jewett ___ Python tracker <https://bugs.python.org/issue41220> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41246] IOCP Proactor same socket overlapped callbacks
Jim Jewett added the comment: Looks good to me. I at first worried that the different function names were useful metadata that was getting lost -- but the names were already duplicated in several cases. *If* that is still a concern for the committer, then instead of repeating the code (as current production does), each section should just say newname=origname before registering the static method (as the patch does), and should bind a distinct name for each usage. -- nosy: +Jim.Jewett versions: +Python 3.10 ___ Python tracker <https://bugs.python.org/issue41246> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41217] Obsolete note for default asyncio event loop on Windows
Jim Jewett added the comment: Looks good to me. -- nosy: +Jim.Jewett ___ Python tracker <https://bugs.python.org/issue41217> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41212] Emoji Unicode failing in standard release of Python 3.8.3 / tkinter 8.6.8
Jim Jewett added the comment: @Ben Griffin -- Unicode has defined astral characters for a while, but they were explicitly intended for rare characters, with any living languages intended for the basic plane. It is only the most recent releases of unicode that have broken the "most people won't need this" expectation, so it wasn't unreasonable for languages targeting memory-constrained devices to make astral support at best a compile-time operation. I've seen a draft for an upcoming spec update of an old but still-supported language (extended Gerber, for photoplotting machines) that "handles" this simply by clarifying that their unicode support is limited to characters < 65K. Given that their use of unicode is essentially limited to comments, and there is plenty of hardware that can't be updated ... this is may well be correct. Python itself does the right thing, and tcl can't do the right thing anyhow without font support ... so this may be fixed in less time than it would take to replace Tk/Tcl. If you need a faster workaround, consider a private-use-area and private font. -- nosy: +Jim.Jewett ___ Python tracker <https://bugs.python.org/issue41212> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39542] Cleanup object.h header
Jim Jewett added the comment: Raymond, did you replace the screenshot with a later one showing that things are fixed now? The timestamp suggests it went up at the same time as your comment, but what I see in the .png file is that the two are identical other than addresses. -- nosy: +Jim.Jewett ___ Python tracker <https://bugs.python.org/issue39542> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17180] shutil copy* unsafe on POSIX - they preserve setuid/setgit bits
Jim Jewett added the comment: My current UI shows this as relevant *only* to 3.4 and 3.5. If it really has been fixed in 3.6, and the fix can't be backported, I think the risk of breaking backup programs is enough to argue for doing nothing more than a doc change. Anyone still using 3.4 (or even 3.5) *and* able to install from source is likely to be more upset by unexpected (and possibly silent) breakage of an existing process than new exploits of a 6 year old bug. That said, I'm probably the wrong person to verify which versions are affected, so consider this as only soft support for Release Manager to do so if this continues to languish. -- nosy: +Jim.Jewett ___ Python tracker <https://bugs.python.org/issue17180> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15100] Race conditions in shutil.copy, shutil.copy2 and shutil.copyfile
Jim Jewett added the comment: (Note: I am talking only about the disclosure issue; file corruption would ideally be fixed as far back as possible, though I would be somewhat sympathetic to a "nah, that ain't security, too late" argument.) My current UI shows this as relevant to every release *except* 3.4 and 3.8. If it is really 3.4 only, I think it should be closed -- anyone still using 3.4 *and* able to install from source is likely to be more upset by unexpected (and possibly silent) breakage of an existing process than new exploits of a 6 year old bug. If it really does apply to 3.5-3.7, then it would be good to do the same fix in all (and to match 3.8, which presumably is also affected, and simply wasn't available to check when the Versions were last set). If, for some reason, the *right* fix on 3.8 (or at least 3.7 or 3.6) doesn't apply to earlier 3.x versions, I suggest closing it as won't-fix on those older versions. That said, I'm probably the wrong person to verify which versions are affected, so consider this as only soft support for Release Manager to do so if this continues to languish. -- ___ Python tracker <https://bugs.python.org/issue15100> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34063] binhex REASONABLY_LARGE = 32768 so what is 128000
New submission from Jim Jewett : binhex defines a module-wide constant of REASONABLY_LARGE = 32768 # Minimal amount we pass the rle-coder Later on, in 5 locations it does either ifp.read(128000) or ifp.read_rsrc(128000) It isn't clear why a different constant is used, let alone why a literal is used instead of something like REASONABLY_LARGE. -- assignee: docs@python components: Documentation, Library (Lib) messages: 321193 nosy: Jim.Jewett, docs@python priority: low severity: normal stage: needs patch status: open title: binhex REASONABLY_LARGE = 32768 so what is 128000 type: enhancement versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue34063> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31040] mimetypes.add_type should complain when you give it an undotted ext
Jim Jewett <jimjjew...@gmail.com> added the comment:
Ideally, use .startswith('.') Instead if find, but this is a clear UI fix.
First pull request fixes doc, second fixes code. OK to apply both.
--
nosy: +Jim.Jewett
stage: -> commit review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue31040>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31470] Py_Initialize documentation wrong
New submission from Jim Jewett: Per https://docs.python.org/3/c-api/init.html#initializing-and-finalizing-the-interpreter Py_Initialize() "should be called before using any other Python/C API functions; with the exception of Py_SetProgramName(), Py_SetPythonHome() and Py_SetPath()." (1) I suspect that should be either Py_Initialize() or Py_InitializeEx(). (2) Other functions can also be called first. The ones I notice are: (2a) Py_IsInitialized() wouldn't be useful if you couldn't call it first. (2b) Py_SetStandardStreamEncoding explicitly says it *should* be called before Py_Initialize, if it is called at all. (Probably applies to earlier python versions as well.) -- assignee: docs@python components: Documentation messages: 302179 nosy: Jim.Jewett, docs@python priority: normal severity: normal status: open title: Py_Initialize documentation wrong versions: Python 3.6 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31470> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30963] xxlimited.c XxoObject_Check should be XxoObject_CheckExact
New submission from Jim Jewett: https://github.com/python/cpython/blob/master/Modules/xxlimited.c#L28 #define XxoObject_Check(v) (Py_TYPE(v) == Xxo_Type) assumes that the type cannot be subclassed, but does not say so. Since this is demo code, it would be better to use something like decimal: #define PyDec_CheckExact(v) (Py_TYPE(v) == _Type) #define PyDec_Check(v) PyObject_TypeCheck(v, _Type) I *believe* (but haven't verified) that would be: #define XxoObject_CheckExact(v) (Py_TYPE(v) == _Type) #define XxoObject_Check(v) PyObject_TypeCheck(v, _Type) -- components: Extension Modules messages: 298617 nosy: Jim.Jewett priority: normal severity: normal stage: needs patch status: open title: xxlimited.c XxoObject_Check should be XxoObject_CheckExact type: enhancement versions: Python 3.7 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30963> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30596] Add close() to multiprocessing.Process
Jim Jewett added the comment: Could join be called in a background thread, or even asynchronously? That seems like mixing paradigms, but ... On Jun 12, 2017 3:15 AM, "Antoine Pitrou" <rep...@bugs.python.org> wrote: > > Antoine Pitrou added the comment: > > That's a good question. close() methods on other objects tend to avoid > taking an infinite amount of time :-) But then, Process objects are > different enough that they don't need to follow that rule. > > -- > > ___ > Python tracker <rep...@bugs.python.org> > <http://bugs.python.org/issue30596> > ___ > -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30596> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30596] Add close() to multiprocessing.Process
Jim Jewett added the comment: Then why not just call join as part of the default close method? -- nosy: +Jim.Jewett ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30596> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30594] Refcounting mistake in _ssl.c
Jim Jewett added the comment: Serhiy -- do your last two messages mean that this is now resolved? -- nosy: +Jim.Jewett ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30594> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30593] sqlite3 executescript does not respect isolation_level?
Jim Jewett added the comment: Do you have a test case that could be used to verify a patch? (Or even a full patch?) -- nosy: +Jim.Jewett stage: -> needs patch type: -> behavior ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30593> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28968] xml rpc server fails with connection reset by peer error no 104
Jim Jewett added the comment: When I see a message like that, it normally means there is a firewall getting in my way. -- nosy: +Jim.Jewett ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28968> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28612] str.translate needs a mapping example
Jim Jewett added the comment: https://mail.python.org/pipermail/python-ideas/2016-November/043539.html by Chris Barker points out that a custom object (which doesn't ever store the missing "keys") may be better still... though I'm not sure it is better enough to complicate the docs. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28612> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28612] str.translate needs a mapping example
New submission from Jim Jewett: One commonly needed string transformation is stripping out certain characters (or only keeping certain characters). This is common enough that it might be worth a dedicated method, except, that, as Stephen J. Turnbull wrote in https://mail.python.org/pipermail/python-ideas/2016-November/043501.html """ So really translate with defaultdict is a specialized loop that marries an algorithmic body (which could do things like look up the original script or other character properties to decide on the replacement for the generic case) with a (usually "small") table of exceptions. That seems like inspired design to me. """ Alas, while inspired, it isn't obvious to someone who isn't yet used to the power of python custom classes. The documentation (such as https://docs.python.org/3/library/stdtypes.html?highlight=translate#str.translate ) should include such an example. One possible example would be a defaultdict that says to discard any characters except lower case ASCII lettersI. -- assignee: docs@python components: Documentation keywords: easy messages: 280061 nosy: Jim.Jewett, docs@python priority: normal severity: normal stage: needs patch status: open title: str.translate needs a mapping example type: enhancement versions: Python 3.5, Python 3.6, Python 3.7 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28612> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28286] gzip guessing of mode is ambiguous
Changes by Jim Jewett <jimjjew...@gmail.com>: -- title: gzip guessing of mode is ambiguilous -> gzip guessing of mode is ambiguous ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28286> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27400] Datetime NoneType after calling Py_Finalize and Py_Initialize
Jim Jewett added the comment: Having to (re-)fill the cache once per interpreter seems like a reasonable price to pay. Why is 3.5 not included? Did this not cause problems before the import change, or is it just that this bug is small enough that maybe it isn't worth backporting? -- nosy: +Jim.Jewett ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27400> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27850] Remove 3DES from cipher list (sweet32 CVE-2016-2183)
Jim Jewett added the comment: In general, the rule is that micro versions (such as 3.4.4 to 3.4.5) should not make any changes that are not clearly bug fixes. If users would call the new API (or ABI) differently, it is almost certainly a change that should be reserved for a development release (3.4 to 3.5). That said, the two main reasons for exceptions are security (not an automatic OK, but at least not an automatic NO) and "no one could possibly rely on the old behavior", which covers "this wouldn't even compile on this platform before". -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27850> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27850] Remove 3DES from cipher list (sweet32 CVE-2016-2183)
Jim Jewett added the comment: On Sep 6, 2016 10:55 PM, Donald Stufft added the comment: > In the hypothetical case we don't backport ChaCha20 support and 3DES and AES constructs in TLS are no longer secure... what do you do? Do you just plug your fingers in your ears and hope nobody attacks you? That works fine for an awful lot of uses. For the ones where it doesn't work, people can either upgrade to 3.5 or get support from a reseller like red hat or caconical or ActiveState or ... Providing the support for free isn't *wrong*, but "we don't add new things except to the current release" is a both clear and sensible ... overriding should be rare. Assuming an override should be accepted just because "security" reminds me of the boy who cried wolf. > > Future OpenSSLs don't affect Python 3.4, as Python 3.4 won't be upgraded to them. ... > Well except LibreSSL already supports this just fine, Is switching to a different SSL library without OS vendor support any more reasonable than switching to a newer python without that same support? -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27850> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27850] Remove 3DES from cipher list (sweet32 CVE-2016-2183)
Jim Jewett added the comment: I think a python call is fine to require ... if they don't have the python source they should have a support contract. I assume the advice followed is intermediate, based on the earlier comment about xp and ie? On Aug 26, 2016 9:46 AM, "Christian Heimes" <rep...@bugs.python.org> wrote: > > Christian Heimes added the comment: > > Patch for 3DES and ChaCha20 (#27766). > > For ChaCha the patch does not check CPU cap vector and just follows the > advice from https://wiki.mozilla.org/Security/Server_Side_TLS# > Modern_compatibility > > -- > keywords: +patch > Added file: https://bugs.python.org/file44233/Remove-3DES-from- > and-add-ChaCha20-Poly1305-to-cipher.patch > > ___ > Python tracker <rep...@bugs.python.org> > <https://bugs.python.org/issue27850> > ___ > -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue27850> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25878] CPython on Windows builds with /W3, not /W4
Jim Jewett added the comment: Is there a way to document why certain warnings are being suppressed, in case someone wants to revisit the suppression later? -- nosy: +Jim.Jewett ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue25878> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27425] Tests fail because of git's newline preferences on Windows
Jim Jewett added the comment: I think if the test is ensuring one line-ending type, then there should be another test ensuring the other... but I think it would be best if there were a single test file that had both types of line-endings, just to ensure that the code doesn't cheat by reading only the first line and assuming that the rest of the data is consistent. -- nosy: +Jim.Jewett ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue27425> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27850] Remove 3DES from cipher list (sweet32 CVE-2016-2183)
Jim Jewett added the comment: What does overriding to put it back require? Does it require a re-compile, or can it be done via a config file? Taking it out of the default set sounds reasonable, but requiring a recompile for people who want to retain backwards compatibility strikes me as too much, particularly for a maintenance release. -- nosy: +Jim.Jewett ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue27850> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27021] It is not documented that os.writev() suffer from SC_IOV_MAX
Changes by Jim Jewett <jimjjew...@gmail.com>: -- stage: -> needs patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27021> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27038] Make os.DirEntry exist
Changes by Jim Jewett <jimjjew...@gmail.com>: -- stage: -> needs patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27038> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27032] Remove deprecated html.parser.HTMLParser.unescape()
Jim Jewett added the comment: Looks Good To Me -- nosy: +Jim.Jewett ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27032> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25937] DIfference between utf8 and utf-8 when i define python source code encoding.
Jim Jewett added the comment: Does (did?) the utf8 special case allow for a much faster startup time, by not requiring all of the codecs machinery? -- nosy: +Jim.Jewett ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25937> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26296] colorys rgb_to_hls algorithm error
Jim Jewett added the comment: The modulus fixes it for exact numbers. It doesn't produce exactly the same result with floats, because of rounding. Is that a problem? -- nosy: +Jim.Jewett ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26296> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26312] Raise SystemError on programmical errors in PyArg_Parse*()
Jim Jewett added the comment: It feels a bit odd to say that I've performed a triage review given the three people already involved -- but I did, and I think it is ready to commit. I believe it is a bug fix, but too subtle a bug to justify backporting. The only question is whether there should be a "What's New?" entry for the change. -- nosy: +Jim.Jewett stage: patch review -> commit review ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26312> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26324] sum() incorrect on negative zeros
Jim Jewett added the comment: Even if Ethan's argument about an explicit start value were not convincing, Mark + Raymond would count as authoritative for floats. Anyone can reopen if needed; I just don't want the issue to languish forever if there is at least grudging agreement. -- nosy: +Jim.Jewett resolution: -> not a bug status: open -> closed ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26324> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26204] compiler: ignore constants used as statements (don't emit LOAD_CONST+POP_TOP)
Jim Jewett added the comment: I think the warning was helpful; it just had confusing wording. Instead of: """ >>> def f(): ... False ... :2: SyntaxWarning: ignore constant statement """ perhaps: """ >>> def f(): ... False ... :2: SyntaxWarning: ignoring constant statement """ or even: """ >>> def f(): ... False ... :2: SyntaxWarning: ignoring unused constant 'False' """ -- nosy: +Jim.Jewett ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26204> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26286] dis module: coroutine opcode documentation clarity
New submission from Jim Jewett: https://docs.python.org/3/library/dis.html includes a section describing the various opcodes. Current documentation: """ Coroutine opcodes GET_AWAITABLE Implements TOS = get_awaitable(TOS), where get_awaitable(o) returns o if o is a coroutine object or a generator object with the CO_ITERABLE_COROUTINE flag, or resolves o.__await__. GET_AITER Implements TOS = get_awaitable(TOS.__aiter__()). See GET_AWAITABLE for details about get_awaitable GET_ANEXT Implements PUSH(get_awaitable(TOS.__anext__())). See GET_AWAITABLE for details about get_awaitable BEFORE_ASYNC_WITH Resolves __aenter__ and __aexit__ from the object on top of the stack. Pushes __aexit__ and result of __aenter__() to the stack. SETUP_ASYNC_WITH Creates a new frame object. """ (1) There is a PUSH macro in ceval.c, but no PUSH bytecode. I spent a few minutes trying to figure out what a PUSH command was, and how the GET_ANEXT differed from TOS = get_awaitable(TOS.__anext__()) which would match the bytecodes right above it. After looking at ceval.c, I think GET_ANEXT is the only such bytecode to leave the original TOS in place, but I'm not certain about that. Please be explicit. (Unless they are the same, in which case, please use the same wording.) (2) The coroutine bytecode instructions should have a "New in 3.5" marker, as the GET_YIELD_FROM_ITER does. It might make sense to just place the mark under Coroutine opcodes section header and say it applies to all of them, instead of marking each individual opcode. (3) The GET_AITER and GET_ANEXT descriptions do not show the final period. Opcodes such as INPLACE_LSHIFT also end with a code quote, but still include a (not-marked-as-code) final period. (4) Why does SETUP_ASYNC_WITH talk about frames? Is there actually a python frame involved, or is this another bytecode "block", similar to that used for except and finally? -- assignee: yselivanov components: Documentation messages: 259595 nosy: Jim.Jewett, yselivanov priority: normal severity: normal stage: needs patch status: open title: dis module: coroutine opcode documentation clarity versions: Python 3.5 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26286> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25216] Warnings stacklevel frames to skip
Changes by Jim Jewett <jimjjew...@gmail.com>: -- stage: -> needs patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25216> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25216] Warnings stacklevel frames to skip
New submission from Jim Jewett: warnings.warn(stacklevel=2) is a longstanding idiom. It broke in 3.3 because python itself added some additional infrastructure frames in between; now stacklevel should be 8 or 10 in some releases. issue24305 adds a workaround for 3.5, to ignore internal frames -- defined as those which contain both 'importlib' and '_bootstrap' in filename. I would prefer to see a supported hook, so that either the caller or the program setup could list other modules or packages to ignore when counting frames. That way, I could write mycall(otherlib(foo)) and otherlib could ensure that the warning pointed to mycall, rather than to something internal to otherlib, even if otherlib were refactored to a different stack depth. Ignoring just the import machinery would of course be a good default. -- components: Library (Lib) messages: 251328 nosy: Jim.Jewett priority: normal severity: normal status: open title: Warnings stacklevel frames to skip type: enhancement versions: Python 3.6 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25216> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24294] DeprecationWarnings should be visible by default in the interactive REPL
Jim Jewett added the comment: On windows, when python is started from the command line without a GUI, os.isatty(sys.stdin) raises an error, but os.isatty(sys.stdin.fileno()) returns true. Within IDLE, os.isatty(sys.stdin.fileno()) also raises an error, but os.isatty(0), os.isatty(1), and os.isatty(2) all return true. I'm not sure exactly when you want which warning to show, let alone whether the above tests are relevant, but I'm happy to run some tests if you can tell me what you're looking for. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24294 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24294] DeprecationWarnings should be visible by default in the interactive REPL
Jim Jewett added the comment: Instead of using python directly in a subprocess, try calling a shell command that in turns calls python. (Admittedly, this may look like the pipe scenario...) In theory, you could even drive another python interactively, using a GUI runner, but I'm not sure how much new infrastructure that would add to the test suite, so it might not be worth it. I'm not aware of a list of manual tests (though perhaps there *should* be one...); I would put it under the DeprecationWarning docs, sort of like an example. Others may have better ideas. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24294 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24294] DeprecationWarnings should be visible by default in the interactive REPL
Jim Jewett added the comment: I've changed the stage to test needed. At a minimum, an interactive test should be written and added to the documentation. Better would be an automated test (perhaps via subprocess). The documentation should also be updated; at a minimum, there should be a versionchanged to say when the default changed. Ideally, also some clarification on the intended differences between DeprecationWarning and PendingDeprecationWarning, and whether there are any behavioral differences. -- nosy: +Jim.Jewett stage: - test needed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24294 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24790] Idle: improve stack viewer
Jim Jewett added the comment: Terry: Was removing the public attribute keys OK? -- nosy: +Jim.Jewett ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24790 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16991] Add OrderedDict written in C
Jim Jewett added the comment: Eric I realize that O (1) deletion is hard, and don't see a good way around it without changing the implementation ... I just think that the preserving the current C layout may be forcing an even more complicated solution than neccessary. I am nervous about pushing this to 3.5 because of the complexity. I agree that a simpler solution should (also?) wait for 3.6. The question about dictheaher.h boils down to: if someone asks whether something is a dictview (not even using exact, though that isn't an option), an odictview will say false ... is that really what you want? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16991 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16991] Add OrderedDict written in C
Jim Jewett added the comment: Eric, unless I'm misreading your debugging info, it is the other way around -- something is in the dict, but not in the list that you iterate over. And since the list that you iterate over looks right, I have to wonder if it was something internal-to-configparser (or its various converters and proxies). Perhaps the __root used by the collections.OrderedDict that it uses by default? Can you iterate over it as a dict, instead of as an ordered dict, to find the discrepancy? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16991 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16991] Add OrderedDict written in C
Jim Jewett added the comment: (Just putting my review summary in the main ticket) I'm going to echo the previous comment that maybe trying to emulate the existing dict implementation too carefully just adds complexity. The split-keys implementation shows that there is at least some flexibility to the implementation. Enough that the keys could map to an array offset, rather than directly to the values? A simple array of key/value pairs (hashing only to ensure hashability, but ignoring it otherwise) should be faster for the really small dicts you care about, like keyword dicts. (Admittedly, those timing data are fairly out of date, but I would be surprised if it weren't still true.) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16991 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24275] lookdict_* give up too soon
New submission from Jim Jewett: The specialized lookdict_* variants replace themselves with the generic lookdict as soon as a non-unicode key is looked up. They could reasonably leave the replacement to insertdict (line 819, currently assert rather than a replacement), when a non-unicode key is actually inserted into the dict. While inserts are less common than (all lookups including insert), I see the main advantage as reducing the number of duplications of the replacement logic. -- components: Interpreter Core messages: 243969 nosy: Jim.Jewett priority: normal severity: normal status: open title: lookdict_* give up too soon type: enhancement ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24275 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16991] Add OrderedDict written in C
Jim Jewett added the comment: Should dictobject.h get a bit more changes? In particular, should the following be expanded? #define PyDictKeys_Check(op) (Py_TYPE(op) == PyDictKeys_Type) #define PyDictItems_Check(op) (Py_TYPE(op) == PyDictItems_Type) #define PyDictValues_Check(op) (Py_TYPE(op) == PyDictValues_Type) /* This excludes Values, since they are not sets. */ # define PyDictViewSet_Check(op) \ (PyDictKeys_Check(op) || PyDictItems_Check(op)) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16991 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24274] erroneous comments in dictobject.c
New submission from Jim Jewett: https://hg.python.org/cpython/file/2df7c958974e/Objects/dictobject.c#l451 The comments near lookdict suggest that specialized versions such as lookdict_unicode and lookdict_unicode_nodummy cannot return NULL, as that would indicate an Exception was raised during comparison. They can return NULL, because if the *search* key is not unicode, they replace themselves with the generic lookdict and then return its result, which may be NULL. -- components: Interpreter Core messages: 243968 nosy: Jim.Jewett priority: normal severity: normal status: open title: erroneous comments in dictobject.c type: enhancement ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24274 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16991] Add OrderedDict written in C
Jim Jewett added the comment: Why does generated file Include/opcode.h show up as changed? It looks like pure whitespace, but I wonder if a similar whitespace change might be making something a space too long somewhere. -- nosy: +Jim.Jewett ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16991 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24088] yield expression confusion
Jim Jewett added the comment: OK, then how about Current: When a generator function is called, it returns an iterator known as a generator. That generator then controls the execution of a generator function. The execution starts when one of the generator’s methods is called. Proposed: When a generator function is called, it does not complete its execution immediately. Instead, it keeps its execution frame intact, and returns a special kind of iterator known as a generator. The iteration starts when one of the generator’s methods is called, and the generator executes within the existing generator frame, rather than creating a new one. This still seems to suggest that the generator uses the same frame as the generator function that created it; I was not aware that this was a guarantee. (Reusing the same frame, yes. Reusing that particular frame, no.) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24088 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24088] yield expression confusion
New submission from Jim Jewett: https://docs.python.org/3/reference/expressions.html#yield-expressions Current: When a generator function is called, it returns an iterator known as a generator. That generator then controls the execution of a generator function. The execution starts when one of the generator’s methods is called. At a minimum, that seems to be using generator function in two different ways, but I think there are other problems. Proposed: When a generator function is called, it returns a special kind of iterator known as a generator. The iteration starts when one of the generator’s methods is called. -- assignee: docs@python components: Documentation, asyncio messages: 242289 nosy: Jim.Jewett, docs@python, gvanrossum, haypo, yselivanov priority: normal severity: normal status: open title: yield expression confusion type: enhancement ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24088 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23491] PEP 441 - Improving Python Zip Application Support
Jim Jewett added the comment: I think that instead of application/zip, you want application/zipped-python (or whatever the precise term was). This was one reason to register the MIME type. That said, application/zip is probably not harmful; the worst it should do it hand the archive to a zip program. What is pxzw for, other than amusing mispronunciations? -- nosy: +Jim.Jewett ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23491 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14014] codecs.StreamWriter.reset contract not fulfilled
Jim Jewett added the comment: That sounds like a bug magnet to me; my mental model is that the codec is my output; flushing it will push things out, and resetting it will erase anything pending. I don't care if some implementation detail means that some other object technically owns the buffer. An alternative (inferior, but better than nothing) would be to add an explicit note warning users that reset won't really finish the job, and they have to also get the codec's underlying stream and flush that. (Of course, if the stream is really an abstraction over the real stream ... at what point does the delegation start to work on its own?) On Tue, Jan 13, 2015 at 8:21 PM, Martin Panter rep...@bugs.python.org wrote: Martin Panter added the comment: I don’t think this is appropriate. If you want to flush the underlying stream, then call its flush() method after calling reset(). The docstring only says it flushes the _codec’s_ buffers, not any buffers of the underlying stream, and it should not be the codec’s business to worry about lower level buffers. -- nosy: +vadmium ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14014 ___ -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14014 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16329] mimetypes does not support webm type
Jim Jewett added the comment: I interpreted Issue 15's closure as being about the distinction between Application/webm vs Video/webm, etc. As far as I understand it, the python stdlib doesn't actually care what the major Mime type is, or, frankly, even whether the definition makes sense. We just want Video/webm to be registered. I have created issue 886 on the webm site at https://code.google.com/p/webm/issues/detail?id=886can=4colspec=ID%20Pri%20mstone%20ReleaseBlock%20Type%20Component%20Status%20Owner%20Summary Anyone with more detail (e.g., do we need to define Application/webm as well as Video/webm ... do we care what the definition is ... etc ...) is encouraged to chime in. -- nosy: +Jim.Jewett ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16329 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22766] collections.Counter's in-place operators should return NotImplemented for unsupported types
Jim Jewett added the comment: I wish there were an APIMismatchError superclass to unify (AttributeError, TypeError). But the wart probably isn't enough to justify the surgery. On Thu, Nov 6, 2014 at 8:48 AM, Serhiy Storchaka rep...@bugs.python.org wrote: Serhiy Storchaka added the comment: I've posted to python-list and python-dev. I'll report back here the findings, if any. http://comments.gmane.org/gmane.comp.python.devel/150073 -- nosy: +serhiy.storchaka ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22766 ___ -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22766 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22766] collections.Counter's in-place operators should return NotImplemented for unsupported types
Jim Jewett added the comment: If I know that a Counter (or any class X) can be updated in place, I will be surprised to find out that I'm using a different instance after a successful in-place operation. I would even consider that (replacement of the original instance) a security risk, though it is mitigated by the fact that I don't see how to exploit it without already being able to create arbitrary subclasses. For subclassing to work, the fix is: if not hasattr(other, 'items') or type(self) is not Counter: return NotImplemented That breaks for Counter subclasses on the left hand side -- even a trivial subclass to change the repr would fail unless the _i* methods were all re-implemented, either by the otherwise-trivial Counter subclass or by the right-hand objects. If you start making it work for the obvious cases, you just make the failure conditions more obscure. -- nosy: +Jim.Jewett ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22766 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22001] containers same does not always mean __eq__.
Jim Jewett added the comment: Ah... be the same object or compare equal sounds much better. I don't want same to sound like an informal wording for equal, because getting rid of the confusion over NaN and similar objects is the whole point of the revision. On the other hand, I don't want the language spec to imply that a more careful custom container is non-conforming. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22001 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22000] cross type comparisons clarification
New submission from Jim Jewett: https://docs.python.org/3.5/library/stdtypes.html says Objects of different types, except different numeric types, never compare equal. Despite the location, this seems to strong a statement, because of subclasses and classes which define __eq__. A first attempt at rewording: Existing: Objects of different types, except different numeric types, never compare equal. Furthermore, some types (for example, function objects) support only a degenerate notion of comparison where any two objects of that type are unequal. The , =, and = operators will raise a TypeError exception when comparing a complex number with another built-in numeric type, when the objects are of different types that cannot be compared, or in other cases where there is no defined ordering. Non-identical instances of a class normally compare as non-equal unless the class defines the __eq__() method. Instances of a class cannot be ordered with respect to other instances of the same class, or other types of object, unless the class defines enough of the methods __lt__(), __le__(), __gt__(), and __ge__() (in general, __lt__() and __eq__() are sufficient, if you want the conventional meanings of the comparison operators). The behavior of the is and is not operators cannot be customized; also they can be applied to any two objects and never raise an exception. Two more operations with the same syntactic priority, in and not in, are supported only by sequence types (below). -- The is and is not operators can be applied to any pair of objects, and will never raise an exception. They cannot be customized, as they refer to implementation details. (For example, abc is abc may or may not be true.) Other comparisons refer to an object's meaning, and therefore must be defined by the object's own class. abc == abc is always True, because the str class defines equality that way. The default implementation uses is (object identity) for equality and raises a TypeError for the ordering comparisons. Defining the __eq__ method allows different instances to be equivalent; also defining the __lt__ method allows them to be ordered in the normal way. Some classes will also define __le__, __ne__, __ge__, and __gt__, either for efficiency or to provide unusual behavior. Except for numbers, instances of two different standard classes will be unequal, and will raise a TypeError when compared for ordering. Two more operations with the same syntactic priority, in and not in, are supported only by sequence types (below). -- assignee: docs@python components: Documentation messages: 223353 nosy: Jim.Jewett, docs@python priority: normal severity: normal status: open title: cross type comparisons clarification type: behavior versions: Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22000 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22001] containers same does not always mean __eq__.
New submission from Jim Jewett:
https://docs.python.org/3.5/reference/expressions.html#not-in
Containers are permitted to (and generally do) read same as as is or
__eq__), which can be confusing -- particularly in the section defining __eq__.
Several suggested changes:
The values float('NaN') and Decimal('NaN') are special. The are identical to
themselves, x is x but are not equal to themselves, x != x. Additionally,
comparing any value to a not-a-number value will return False. For example,
both 3 float('NaN') and float('NaN') 3 will return False.
-- (the - they; add a comma; add a final sentence) --
The values float('NaN') and Decimal('NaN') are special. They are identical to
themselves, x is x, but are not equal to themselves, x != x. Additionally,
comparing any value to a not-a-number value will return False. For example,
both 3 float('NaN') and float('NaN') 3 will return False. Note, however,
that containers will normally implement item equality as a is b or a==b, so
that [f]==[f] and f in [f] may be true even when f!=f.
also:
Tuples and lists are compared lexicographically using comparison of
corresponding elements. This means that to compare equal, each element must
compare equal and the two sequences must be of the same type and have the same
length.
-- (re-order; add the NaN workaround) --
Tuples and lists are compared lexicographically using comparison of
corresponding elements. This means that to compare equal, two sequences must be
of the same type and have the same length, and each pair of corresponding
elements must be identical or compare equal. (Sequences can assume that
identical elements are equal, despite odd cases like float('NaN').)
I *think* it is OK to leave that caveat out of the mapping case, because have
the same (key, value) pairs would now refer to the above.
--
assignee: docs@python
components: Documentation
messages: 223362
nosy: Jim.Jewett, docs@python
priority: normal
severity: normal
status: open
title: containers same does not always mean __eq__.
type: enhancement
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22001
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21800] Implement RFC 6855 (IMAP Support for UTF-8) in imaplib.
Changes by Jim Jewett jimjjew...@gmail.com: -- stage: - needs patch type: - enhancement ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21800 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8110] subprocess.py doesn't correctly detect Windows machines
Jim Jewett added the comment: It would be good to have the library work unchanged on both implementations. If subprocess only failed later, it would be less good, as the stdlib would then set an example that doesn't actually succeed. Note that the attached patch (by flox) does NOT implement the discussed or tests on sysm.platform; it instead checks whether _subprocess it importable. Is the assumption of an accelerator module itself too implementation-specific? I'm also not sure that the test in the patch isn't too broad -- is windows the only platform with _subprocess? Because if not, then the new test would mess up logic later in the file, such as that at line 635 in Popen.__init__ -- nosy: +Jim.Jewett ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8110 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8110] subprocess.py doesn't correctly detect Windows machines
Jim Jewett added the comment: (The above concerns -- other than whether it is sufficient to work -- do not apply to the change at https://bitbucket.org/ironpython/ironlanguages/commits/b6bb2a9a7bc5/ ) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8110 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10740] sqlite3 module breaks transactions and potentially corrupts data
Jim Jewett added the comment: On Jun 14, 2014 4:05 AM, Aymeric Augustin preserving the same behavior by default That is a requirement, because of backwards compatibility. providing more control for users who need a different behavior, for instance people who use SQLite as an application file format or as a web application storage backend. Great ... but make sure it is also simpler. It is already *possible* to do what you want with 3rd party code. So if doing it right would still require an arcane recipe, that isn't a gain. At a minimum, the new docs should explain why the current default is not sufficient for an application file or a Web backend, and what to do instead. New code is only justified if it makes the do this instead simpler and more obvious. My personal opinion is still that adding more keywords won't do this, because the old ones will still be there to confuse ... thus my suggestion of a new function. When starting with Python I always thought that code like this is harmles: conn = sqlite3.connect(test.db) data = list(conn.execute(select * from mytable)) Currently it is, but only because sqlite3 module parses the select as DQL and does not lock the database. It will absolutely remain harmless with my proposal, if you don't change your code. However, for that use case I would like to encourage the use of autocommit mode. That's really the semantics you want here. I should NOT need to mess with anything related to commit if I am just selecting. If that means another new function for lockless/read-only/uncommitted-read connections, then so be it. My take is to avoid the problem entirely, and not inflict it to new users, by providing an option to start in autocommit mode and then create transactions only when you want them. But again, if it requires choosing a commit mode for my selects, then it fails to be simple. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10740 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12561] Compiler workaround for wide string constants in Modules/getpath.c (patch)
Jim Jewett added the comment: Following up on Mark Lawrence's comment: http://bugs.python.org/issue12572 is collecting the patches required to compile under HP/UX, and the patch there supersedes those on this issue. Closing. -- nosy: +Jim.Jewett resolution: - duplicate status: open - closed superseder: - HP/UX compiler workarounds ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12561 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21719] Returning Windows file attribute information via os.stat()
Jim Jewett added the comment: Added version 3.5; is 3.4 somehow still correct? Set stage to patch review as there are still comments to deal with, but it looks pretty close to commit review. -- nosy: +Jim.Jewett stage: - patch review versions: +Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21719 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21749] pkgutil ImpLoader does not support frozen modules
Jim Jewett added the comment: As best I can tell, this renames the original get_code to _get_code, and then delegates to it after handling the imp.PY_FROZEN case ... why not just add imp.PY_FROZEN to the if/elif chain in the original method? I also note that the call to self._fix_name doesn't do anything helpful unless it is overridden in a subclass -- was this patch really intended as a recipe for subclasses, that avoided super for backwards compatibility? If it is intended to go into the main branch, then someone has to decide whether it is OK to enhance despite being deprecated. If it is just an example, then it should probably be closed with an appropriate status. I'm guessing not a bug, but that isn't quite right either. -- nosy: +Jim.Jewett ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21749 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21748] glob.glob does not sort its results
Jim Jewett added the comment: I agree with R. David Murray, but it may be worth adding a clarification sentence (or an example with sorted) to the documentation. Changing status to Pending, in hopes that any doc changes would be quick. -- nosy: +Jim.Jewett resolution: - not a bug status: open - pending ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21748 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10740] sqlite3 module breaks transactions and potentially corrupts data
Jim Jewett added the comment: (1) The patch is just to docs, not code, so I'm not entirely sure that I understood it properly. (2) The new semantics are a huge mess to explain. This might be because the old semantics were bad, but the result is the same. I think it would be better to create a different API object. (If I read correctly, you would leave function connect unchanged but also def dbapi_connect.) Then keep this new one as simple as it should be -- which will probably mean leaving out some of the parameters that you deprecate. (3) The existing module documentation does claim to be DB-API 2.0 compliant; you should be explicit in the documentation (including docstring) about which behavior differences affect each of (database correctness/API standards conformance/ease of use). -- nosy: +Jim.Jewett ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10740 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21753] subprocess shell=True on Windows character escaping
New submission from Jim Jewett: Inspired by https://mail.python.org/pipermail/python-dev/2014-June/135029.html and the following thread. Normal Windows behavior: hg status --rev .^1 M mercurial\commands.py ? pysptest.py hg status --rev .^1 abort: unknown revision '.1'! So, ^ is an escape character. See http://www.tomshardware.co.uk/forum/35565-45-when-special-command-line It probably isn't possible to pre-escape commands for every possible command interpreter, but it makes sense to get the standard shells right. In fact, global function list2cmdline already exists (and is apparently specific to the Microsoft compiler), but ... its rules are not the same as those of the default windows shell. (Per the tomshardware link, those rules (for windows) did change a while back.) I propose a similar list2shellcmd function. Based on my own very incomplete information, it would currently look like: def list2shellcmd(seq): Turn the sequence of arguments into a single command line, with escaped characters. if mswindows: line=list2cmdline(seq).replace(^, ^^) else: line= .join(seq) return line but there may well be escapes (such as \) that are appropriate even for posix. Note that related issue http://bugs.python.org/issue7839 proposes a larger cleanup, such as forbidding the problematic functionality entirely. -- components: Library (Lib) messages: 220483 nosy: Jim.Jewett priority: normal severity: normal status: open title: subprocess shell=True on Windows character escaping type: enhancement versions: Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21753 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10740] sqlite3 module breaks transactions and potentially corrupts data
Jim Jewett added the comment: Removing the existing behavior will almost certainly not be accepted, because of backwards compatibility. Adding new functionality is generally acceptable. Doing that through a new keyword that defaults to the old behavior is fairly common, and generally better than an apparently redundant function. But in this particular case, that makes the new signature and documentation such a mess that I believe a separate function would be the lesser of evils. (And that only if it is clear what the problems with the current situation are. e.g., do the problems only trigger when using the database from too many threads, or is a random network delay enough to trigger problems?) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10740 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21667] Clarify status of O(1) indexing semantics of str objects
Jim Jewett added the comment: I think the new wording is an improvement, but keeping the changes minimal left it in an awkward in-between state. Proposal: A string is a sequence of Unicode code points. Strings can include any sequence of code points, including some which are semantically meaningless, or explicitly undefined. Python doesn't have a :c:type:`char` type; a single code point is represented as a string of length ``1``. The built-in function :func:`chr` translates an integer in the range ``U+ - U+10`` to the corresponding length ``1`` string object, and :func:`ord` does the reverse. :meth:`str.encode` provides a concrete representation (as :class:`bytes` in the given text encoding) suitable for transport and communication with non-Python utilities. :meth:`bytes.decode` decodes such byte sequences into text strings. -- nosy: +Jim.Jewett ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21667 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21667] Clarify status of O(1) indexing semantics of str objects
Jim Jewett added the comment: And even my rewrite showed path dependency; a slight further improvement is to re-order encoding ahead of bytes. I also added a paragraph that I hope answers the speed issue. Proposal: A string is a sequence of Unicode code points. Strings can include any sequence of code points, including some which are semantically meaningless, or explicitly undefined. Python doesn't have a :c:type:`char` type; a single code point is represented as a string of length ``1``. The built-in function :func:`chr` translates an integer in the range ``U+ - U+10`` to the corresponding length ``1`` string object, and :func:`ord` does the reverse. :meth:`str.encode` provides a concrete representation (in the given text encoding) as a :class:`bytes` object suitable for transport and communication with non-Python utilities. :meth:`bytes.decode` decodes such byte sequences into text strings. .. impl-detail:: There are no methods exposing the internal representation of code points within a string. While the C-API provides some additional constraints on CPython, other implementations are free to use any representation that treats code points (as opposed to either code units or some normalized form of characters) as the unit of measure. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21667 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6167] Tkinter.Scrollbar: the activate method needs to return a value, and set should take only two args
Jim Jewett added the comment: I'm still not seeing why these changes are sufficiently desirable to justify the code churn. Nor am I seeing test or doc changes that would explain the advantages of the new way, and prevent future regressions. I agree that the changes would make the signatures better for the typical use cases for this particular widget -- but wouldn't they also break the common interface for the set and activate methods across several types of tkinter widget? If so, then instead of changing or restricting the method, it would be better to add examples (and maybe even an explanation) to the documentation (including the docstring). In particular: (1) Why change actrivate's parameter from index to element? I agree that element is a better name for the normal case, but https://docs.python.org/dev/library/tkinter.html#the-index-parameter strongly suggests that index is more consistent with the rest of tkinter, and that there are use cases wehre index is the right name. If that is not true, please say so explicitly, at least in comments. (2) Why change the set method? I understand that a more specific signature is desirable, and I assume that other values would be ignored (or raise an exception), but the set method seems to have an existing API across several widgets -- and that shouldn't be broken lightly. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6167 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19385] dbm.dumb should be consistent when the database is closed
Jim Jewett added the comment:
Did you try 3.5 without the patch, in case the issue is not with his code?
On May 13, 2014 7:23 AM, Serhiy Storchaka rep...@bugs.python.org wrote:
Serhiy Storchaka added the comment:
Claudiu, your benchmark is broken, it measure a no-op.
Correct benchmark:
$ ./python -S -m timeit -n 10 -s import dbm.dumb as dbm;
d=dbm.open('x.dat', 'c') len(d)
3.4: 10 loops, best of 3: 2.56 usec per loop
3.5: 10 loops, best of 3: 4.17 usec per loop
There is 60% regression.
--
status: closed - open
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19385
___
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19385
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6839] zipfile can't extract file
Jim Jewett added the comment: On Fri, May 2, 2014 at 1:14 AM, Adam Polkosnik The problems documented here are related to two cases (both apparently arriving from world of windows): Good! I had thought you had even more! 1. two relative paths with inverted slash in one of them (test\test2.txt vs test/test2.txt) My understanding from earlier -- and I may have been reading too much into some of the comments -- is that the standard defined \filename as an inferior alias for /filename and supported the fix. Notably, if you're extracting on windows with windows conventions, then windows will treat them identically anyhow. If you're extracting a windows file to a unix environment, then \t really should be translated to /t. 2. relative path vs absolute path (windows\temp\test.txt vs c:\windows\temp\test.txt) These really are different, as leaving off the C: should mean current drive, which will often (but not always) be C: This (and differing capitalization) are among the reasons to do the filename fix in a separate method, so that subclasses with more local knowledge can more easily do the right thing. Note that for python 3.4 and newer, pathlib URL: https://docs.python.org/3/library/pathlib.html may be helpful. It would probably even be possible to backport the essential parts as an implementation detail. But I'm not sure if that could be done compatibly with maintenance releases, or how much work it would take. The extraction part seems to be doing a good job at writing the files into sane locations. IMHO, there's no point in trying to replace slashes or otherwise normalize, as this would fix the cases where the presence of an inverted slashes should be noted in debug output. My understanding had been that it was failing to extract entirely. So exactly what is the problem? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6839 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6839] zipfile can't extract file
Jim Jewett added the comment: I'm leaving it as needs patch because it isn't clear exactly what a committer should do. I think the current intent is to make the changes listed in zipfile_???_filename_mismatch_v2.patch (which are not listed as reviewable -- but the changes are indeed sufficiently straightforward that the the files -- if need be -- could be edited by hand as if they were made originally by the committer.) This change is small enough (warning instead of raise) that a test case is probably not strictly required, but it would be helpful. test.zip would presumably be useful data for a test case. There is dispute over whether this would be an enhancement (more generous with what to accept), a bug fix, or a security *regression* because it still allows old vulnerable files to stick around unreplaced (or to hide from a malware scanner), but no longer raises an Exception to get attention. (warnings are often ignored) zlib_forward_slash.patch would also be good (and might even be a security fix, by allowing the new versions to be installed), but is not ready to be committed, as (A) it repeats the logic inline instead of using the newly defined helper method (B) it doesn't have a test case (test1.zip should help when creating one) (C) it has neither a doc change nor an explicit (and dubious) statement that this is just a bug fix and wouldn't need to be listed in the versionchanged. There is also a question of how general the filename correction should be, particularly with respect to windows drives and capitalization. The one in this patch seems to be the minimal change, and is explicitly supported by the zip spec. -- nosy: +Jim.Jewett ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6839 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6839] zipfile can't extract file
Jim Jewett added the comment: Presumably the stacklevel applies to all versions; verifying that it warns about the right code location is important enough to require a test case. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6839 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6839] zipfile can't extract file
Jim Jewett added the comment: On Wed, Apr 30, 2014 at 3:05 PM, Adam Polkosnik wrote: test.zip up there is the test case for this change. Is there any other test case needed? ah; I see the confusion. test.zip is test *data*. When I asked for a test *case*, I meant something that ensures the data will be used to actually run the test automatically. Typically, that would involve adding something to Lib/test/test_zipfile.py. I'm guessing it would be easiest to add a new class inheriting from unittest.TestCase and opening test.zip in the setUp, then using a bunch of assert* methods to verify that the file was read and interpreted correctly. -jJ -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6839 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6839] zipfile can't extract file
Jim Jewett added the comment: On Wed, Apr 30, 2014 at 3:11 PM, Adam Polkosnik I've got some test cases where the zlib_forward_slash.patch doesn't cut it. My recommendation (and I could be convinced otherwise) would be to replace if fname_str != zinfo.orig_filename: raise ... with something more like self.filename_check(fname_str, zinfo.orig_filename) and a default implementation of filename_check that does nothing if they're equal; calls the slash replace (since the standard supports that correction); does nothing else if they're now equal; emits a warning (or prints, in 2.7.6) otherwise. In 2.7.6, you would have to keep the new methods private, but in 3.5, users could override filename_check to handle the windows path normalization, or whatever other problems you have documented. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6839 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21362] concurrent.futures does not validate that max_workers is proper
Jim Jewett added the comment: I confirm the bug. The patch looks good. -- nosy: +Jim.Jewett ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21362 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1599254] mailbox: other programs' messages can vanish without trace
Jim Jewett added the comment: pinging David Watson: What is the status? If I understand correctly, (and I may well not), you have already opened other issues for parts of this, and (only) the final patch is ready for patch (and hopefully) commit review. Is this correct? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1599254 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20974] email module docs say not compatible with current python version
Jim Jewett added the comment: I don't know for sure if the compatibility claims are correct, but the patch looks good. -- stage: - commit review ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20974 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16104] Compileall script: add option to use multiple cores
Jim Jewett added the comment: Trying to put bounds on the disagreements. Does anyone disagree with any of the following: (1) compileall currently runs single-threaded in a single process. (2) This enhancement intends to allow parallelization by process. (3) Users MAY need to express whether they (require/forbid/are expressly apathetic concerning) paralellization. (3A) There is some doubt that this even needs to be user-controlled. (3B) If it is user-controlled, the patch proposes adding a processes parameter to do this. (3C) There have been suggestions of other names (notably workers), but *if* it is user-controlled, the idea of a new parameter is not controversial. (4) Users MAY need to control the degree of parallelization. (4A) If so, setting the value of the new parameter to a positive integer 1 is an acceptable solution. (4B) There is not yet consensus on how to represent Use multi-processing, with the default degree for this system., Do NOT use multiprocessing., or I don't care. (4C) Suggested values have included 1, 0, -1, any negative number, None, and specific strings. The precise mapping between some of these and the three cases of 4B is not agreed. (5) If multiprocessing is explicitly requested, what should happen when it is not available? (5A) Fall back to the current way, without multi-processing. (5B) Fall back to the current way, without multi-processing, but issue a Warning. (5C) Raise an Exception. (ValueError, ImportError, NotImplemented?) (6) Portions of the documentation unrelated to this should be fixed. But ideally, that would be done separately, and it will NOT be a pre-requisite to this patch. --- Another potential value set None (the default) == let the system parallelize as best it can -- as it does in multiprocessing. If the system picks not in parallel at all, that is also OK, and no warning is raised. 0 == Do not parallelize. positive integers == Use that many processes. negative == ValueError Would these uses of 0 and negative be too surprising for someone? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16104 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16104] Compileall script: add option to use multiple cores
Jim Jewett added the comment: ProcessPoolExecutor already defaults to using cpu_count if max_workers is None. Consistency with that might be useful too. (and a default of 1 to mean nothing in parallel is sensible...) -- nosy: +Jim.Jewett ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16104 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19385] dbm.dumb should be consistent when the database is closed
Jim Jewett added the comment: _check_closed sounds like you expect it to be closed, and might even assert that it is closed, except that you want the check run even in release mode and/or it might fail. Since being closed is actually the unexpectedly broken state, I would prefer that you rename it to something else, like _verify_open. -- nosy: +Jim.Jewett ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19385 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19385] dbm.dumb should be consistent when the database is closed
Jim Jewett added the comment: I think the requested timing regression was for the non-broken case. When the database has NOT been closed, and keys() still works, will it be way slower than before? Note that I am not asking you to do that test (though the eventual committer might); the implementation of whichdb leaves me believing that almost anyone who is likely to care will have already followed the docunmentation's recommendation to install another *dbm ahead of dumb. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19385 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
