[issue32474] argparse nargs should support string wrapped integers too
R. David Murray <rdmur...@bitdance.com> added the comment: Why? What's the motivation for supporting this? There's no reason that I can think of, so I'm curious what your use case is. -- nosy: +r.david.murray ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32474> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32462] mimetypes.guess_type() returns incorrectly formatted type
R. David Murray <rdmur...@bitdance.com> added the comment: You can get the same "bad" behavior on a posix system by having a mimetypes file with an incorrect entry in it. That would be a system misconfiguration, as is your Windows registry case, and is outside of Python's control. I suppose we could make it clearer (ie: in that intro paragraph) that the system files are read by default (that is, the built-in tables are only *defaults* unless you specify otherwise). It is unfortunately true that the mime types in the Windows registry are less reliable than those on unix systems. This has nothing to do with the mimetypes module itself, though ;) I wonder if we should have made the default to be loading windows registry as non-strict, but that ship has sailed, I think. Checking for at least minimal validity (xxx/yyy) would at least make things a little better on Windows, so I wouldn't object to adding that. To summarize, my suggestion would be to add a note to the intro paragraph that system files/registry are read by default and override the built-in tables, and add a minimal sanity check on the mime type values read. Adding .sql to the strict list is a separate issue, and would not change the behavior here (unless I'm missing something, which is possible). There are issues around adding even a minimal validity check, though: do we backport that? Do we silently ignore strings in the wrong format? Do we "fix" a backslash to be a slash? Do we issue a warning for any problems we find? These questions should be discussed if we decide to go this route. -- nosy: +r.david.murray ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32462> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32448] subscriptable
R. David Murray <rdmur...@bitdance.com> added the comment: Well, in that case having 'organizer' in the error message wouldn't help you untangle your code ;) -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32448> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32452] Brackets and Parentheses used in an ambiguous way
R. David Murray <rdmur...@bitdance.com> added the comment: "round brackets" would require just as much thought (if not more...it's not a thing at all in American typographical language) for an American to understand as the unadorned bracket does for the rest of you, so the best compromise is "parenthesis instead of square brackets", since parenthesis is used elsewhere in the docs. -- nosy: +r.david.murray ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32452> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32451] python -m venv activation issue when using cygwin on windows
R. David Murray <rdmur...@bitdance.com> added the comment: cygwin in not currently fully supported (there are people working on it, though). Can you determine if this is a bug in cygwin's bash support, or something else? It certainly works with bash shell on unix. I would presume that from cygwin one would want the posix way to work, and that it should be possible. -- nosy: +erik.bray, r.david.murray ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32451> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32449] MappingView must inherit from Collection instead of Sized
R. David Murray <rdmur...@bitdance.com> added the comment: Well, it would be a backward compatibility problem at a minimum. Obviously things were designed this way. Have you found out why? Is there a consensus on python-ideas that this should be changed? If so, please link to the thread. -- nosy: +r.david.murray ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32449> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32448] subscriptable
R. David Murray <rdmur...@bitdance.com> added the comment: At the point at which that error is raised, Python doesn't know the name of the attribute, nor is attribute access the only place where that particular error report is triggered (it's in a generic subscript-this-object call). So I doubt doing this would be practical. As for Foo.organizer.blah[0], it has to be blah that is None, since '.organizer' is an attribute access and not a subscript operation. The more difficult case is something like getattr(someobject, somevar)[0], where you can't tell what somevar contains just from the traceback. Which is why some value-added systems also dump the locals from the frame in the traceback. -- nosy: +r.david.murray ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32448> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15873] datetime: add ability to parse RFC 3339 dates and times
R. David Murray <rdmur...@bitdance.com> added the comment: Correct, a new feature should always get a what's new entry. You could submit a PR for it :) -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue15873> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32444] python -m venv symlink dependency on how python binary is called is not documented
R. David Murray <rdmur...@bitdance.com> added the comment: Actually, I'm going to reopen this as a doc issue because this behavior is not discussed by the docs that I can see, and it is important to know about when creating a venv. -- assignee: -> docs@python components: +Documentation -Library (Lib) nosy: +docs@python resolution: not a bug -> stage: resolved -> needs patch status: closed -> open title: python -m venv has incongruous behavor creating binaries -> python -m venv symlink dependency on how python binary is called is not documented ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32444> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32444] python -m venv has incongruous behavor creating binaries
R. David Murray <rdmur...@bitdance.com> added the comment: This is a feature that actually supports your use case, as well as the use cases of those who *don't* want to strap the python version: you get what you ask for. If you call venv with 'python3', you get a venv that will use your new python if you upgrade your python, but if you call it with python3.x, you will get a venv that will *not* upgrade, which is exactly what you want for your use case. -- nosy: +r.david.murray resolution: -> not a bug stage: -> resolved status: open -> closed versions: +Python 3.7 -Python 3.5 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32444> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32420] LookupError : unknown encoding : [0x7FF092395AD0] ANOMALY
R. David Murray <rdmur...@bitdance.com> added the comment: Well, it's not obvious that it has anything to do with CPython itself. You should probably work with the community responsible for tensorflow, whatever that is, and if they find a bug in CPython you can come back here with a report. Given the error message it looks like an invalid value is being passed to CPython as the system encoding, so most likely the bug is in tensorflow and/or your environment. -- nosy: +r.david.murray ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32420> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32424] Rename copy() to __copy__() in xml.etree.ElementTree.Element Python implementation
R. David Murray <rdmur...@bitdance.com> added the comment: Yes, that's why I said "from our point of view" :) I know there is usually a fork in the practical sense, but we want to make it as easy as practical to sync that fork, which includes not breaking things in the python versions without good reason. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32424> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32424] Rename copy() to __copy__() in xml.etree.ElementTree.Element Python implementation
R. David Murray <rdmur...@bitdance.com> added the comment: Paul Ganssle: Even if Andrew were not suggesting adding copy to the C implementation (I have no opinion on that currently), it would still be correct to maintain backward compatibility in the python version in the standard library. We do not consider the standard library to be CPython specific, even though parts of it are. There is no "fork" involved in other projects using it, from our point of view. Quite the opposite, where possible. We have given commit rights to developers from other python implementations specifically so they can contribute things that improve compatibility in the standard library and standard library test suite for those other python implementations. -- nosy: +r.david.murray ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32424> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32431] Two bytes objects of zero length don't compare equal
R. David Murray <rdmur...@bitdance.com> added the comment: I think what Py_SIZE "means" depends on the object type in the general case, not just this one, so documenting that it is mucking with the internal representation is probably the way to go. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32431> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32431] Two bytes objects of zero length don't compare equal
R. David Murray <rdmur...@bitdance.com> added the comment: My suspicion is that this behavior/code is left over from when the code was handling strings in python2, where strings were always null terminated and so the equal-bytes test would always pass. I don't think this is appropriate for bytes objects, so I think the compare logic should be fixed. But I don't deal with the C code much, so I'd like an opinion from a core dev who does. -- nosy: +r.david.murray ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32431> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31639] http.server and SimpleHTTPServer hang after a few requests
R. David Murray <rdmur...@bitdance.com> added the comment: I don't think the PR as it stands is a good idea. These classes are designed to be composable, so it should be up to the library user whether or not to use threads. However it would be perfectly reasonable to choose to use threads in the 'test' function and thus the cli. Which fact should then be documented, and chromium can even be mentioned as one of the motivations for using threads in the cli server. -- nosy: +r.david.murray ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31639> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32419] Add unittest support for pyc projects
R. David Murray <rdmur...@bitdance.com> added the comment: There may be now, but I don't think there was when unittest was written. Also, if someone decided to use namespace packages for tests for some reason, the current check would also probably fail, so it may be worth looking for (or creating if needed) a standard way to check via importlib. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32419> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32419] Add unittest support for pyc projects
R. David Murray <rdmur...@bitdance.com> added the comment: Éric: in python3 if no .py is found but a .pyc is found where the .py is expected, it will be imported and run. This supports sourceless package distributions, which is something we only sorta-support :) The change looks simple enough that it might be worth doing, but I'll leave that to the unittest maintainers. If accepted there should be comments as to why a .pyc is being checked for. -- nosy: +r.david.murray ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32419> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32412] help() of bitwise operators should mention sets as well
R. David Murray <rdmur...@bitdance.com> added the comment:
Which help are you talking about? The Operator Precedence table that you get
if you do, eg: help('&')? I don't think it would be appropriate to mention
specialized uses of the operators there, although perhaps we could add a
general note about operator overloading in the intro paragraph and use set as
the example. Looking at help('BITWISE'), we could add 'when the arguments are
numbers' after the precedence table, but since that section is called 'bitwise'
I don't think we even want to mention set there. Did you have other sections
in mind?
--
nosy: +r.david.murray
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32412>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32407] lib2to3 doesn't work when zipped
R. David Murray <rdmur...@bitdance.com> added the comment: Funny, you are already nosy on that issue. Does this one have a different goal, or did you just forget about that one? -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32407> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32407] lib2to3 doesn't work when zipped
R. David Murray <rdmur...@bitdance.com> added the comment: Duplicate of issue 24960. -- nosy: +r.david.murray resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> Can't use lib2to3 with embeddable zip file. ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32407> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32405] clr: AttributeError: 'module' object has no attribute 'AddReference'
R. David Murray <rdmur...@bitdance.com> added the comment: Whatever clr is, it doesn't look like it is part of the Python standard library. Please contact the clr community for support on this package, or post to the python-list mailing list. -- nosy: +r.david.murray resolution: -> third party stage: -> resolved status: open -> closed ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32405> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32398] OSX C++ linking workaround in distutils breaks other packages
R. David Murray <rdmur...@bitdance.com> added the comment: I doubt we can make the change this way for backward compatibility reasons. That doesn't mean the situation can't be improved, though. -- components: +macOS nosy: +ned.deily, ronaldoussoren ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32398> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32398] GDAL compilation error
R. David Murray <rdmur...@bitdance.com> added the comment: Please describe the problem and your proposed solution in more detail and in terms of CPython, so that it can be discussed by the relevant experts. GDAL is a third party product and only relevant as an example, so it would also be good to come up with a better title for the issues ;) -- nosy: +r.david.murray ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32398> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32323] urllib.parse.urlsplit() must not lowercase() IPv6 scope value
R. David Murray <rdmur...@bitdance.com> added the comment: I don't think a zone id in that form is actually valid in a URI, but I agree that not messing with whatever is there is probably the best policy as long as we aren't directly supporting whatever *is* valid. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32323> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32306] Clarify map API in concurrent.futures
David Lukeš <dafydd.lu...@gmail.com> added the comment: Perfect, thanks! -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32306> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32389] urllib3 wrong computation of 'Content-Length' for file upload
R. David Murray <rdmur...@bitdance.com> added the comment: Yes, this would appear to be both 3rd party and a support request rather than a bug report. Gianguido: please work with the urllib3 community, or post to the python-list mailing list. If you identify an actual bug in Python itself, you can come back here to report it. -- nosy: +r.david.murray resolution: -> third party stage: -> resolved status: open -> closed ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32389> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32384] Generator tests is broken in non-CPython implementation
Change by R. David Murray <rdmur...@bitdance.com>: -- nosy: +yselivanov type: enhancement -> behavior ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32384> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32381] Python 3.6 cannot reopen .pyc file with non-ASCII path
Change by R. David Murray <rdmur...@bitdance.com>: -- keywords: +3.6regression ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32381> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32306] Clarify map API in concurrent.futures
David Lukeš <dafydd.lu...@gmail.com> added the comment:
Yes, sorry for not being quite clear the first time around :)
I eventually found out about Pool.imap (see item 3 on list in OP) and indeed it
fits my use case very nicely, but my point was that the documentation is
somewhat misleading with respect to the semantics of built-in `map()` in Python
3.
Specifically, I would argue that it is unexpected for a function which claims
to be "Equivalent to map(func, *iterables)" to require allocating a list the
length of the shortest iterable.
Maybe a code example will make this clearer for potential newcomers to the
discussion -- this is what I would expect to happen (= the behavior of built-in
`map()` itself), yielding values from the iterable is interleaved with calls to
the mapped function:
```
>>> def gen():
... for i in range(3):
... print("yielding", i)
... yield i
...
>>> def add1(i):
... print("adding 1 to", i)
... return i + 1
...
>>> list(map(add1, gen()))
yielding 0
adding 1 to 0
yielding 1
adding 1 to 1
yielding 2
adding 1 to 2
[1, 2, 3]
```
This is what happens instead with `concurrent.futures.Executor.map()`:
```
>>> def my_map(fn, iterable):
... lst = list(iterable)
... for i in lst:
... yield fn(i)
...
>>> list(my_map(add1, gen()))
yielding 0
yielding 1
yielding 2
adding 1 to 0
adding 1 to 1
adding 1 to 2
[1, 2, 3]
```
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32306>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32306] Clarify map API in concurrent.futures
David Lukeš <dafydd.lu...@gmail.com> added the comment: Hi Antoine, Thanks for the response! :) I think the problem lies in the line immediately preceding the code you've posted: ``` fs = [self.submit(fn, *args) for args in zip(*iterables)] ``` In other words, all the jobs are first submitted and their futures stored in a list, which is then iterated over. This approach obviously breaks down when there is a great number of jobs, or when it's part of a pipeline meant for processing jobs continuously as they come. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32306> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32268] quopri.decode(): string argument expected, got 'bytes'
R. David Murray <rdmur...@bitdance.com> added the comment: Yes, if that protocol existed the errors would be clearer. But it doesn't, for historical reasons, and that is unlikely to change. You are welcome to submit an enhancement request to make quopri accept string as an argument when decoding. But when encoding, it must produce bytes, because "ASCII" is a *byte* encoding, not a unicode encoding (unicode is ascii compatible, but it is neither ascii nor bytes). You might have to write the PR yourself, I'm not sure if anyone else will be interested (but some of the people on the core-mentorship mailing list might be). StringIO is specifically designed to only operate on strings. If you want to decode the bytes you feed it, you have to do that. This is an intentional design. Further discussion of ways to improve the situation should move to the python-idea mailing list. There's really nothing to do here from a bug tracker perspective, unless you want to open an enhancement request as mentioned above. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32268> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32268] quopri.decode(): string argument expected, got 'bytes'
R. David Murray <rdmur...@bitdance.com> added the comment: That's type checking. Not type checking is to call the method that writes the data, expecting the object to handle the bytes it is passed, and then that object raises an error to indicate that it cannot. There is no protocol that can be checked for. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32268> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32376] Unusable syntax error reported when Python keyword in a f-string
R. David Murray <rdmur...@bitdance.com> added the comment: The existing issue is #29051. -- nosy: +r.david.murray resolution: -> duplicate stage: needs patch -> resolved status: open -> closed superseder: -> Improve error reporting involving f-strings (PEP 498) ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32376> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32361] global / nonlocal interference : is this a bug, a feature or a design hole ?
R. David Murray <rdmur...@bitdance.com> added the comment: Hmm. I suppose that could be clarified in the docs. I would find it very counter-intuitive for the grandparent 'a' to be accessible, which is probably why I did not consider that an issue. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32361> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32361] global / nonlocal interference : is this a bug, a feature or a design hole ?
R. David Murray <rdmur...@bitdance.com> added the comment: When I said "the only thing keeping this issue open" is the message, I should acknowledge that you mentioned clarifying the documentation, but as I pointed out the documentation is already clear: it says nonlocal does not access variables in the global scope, and in your example 'a' is a variable in the global scope, because it is declared to be one. We generally don't update PEPs after they are accepted and implemented; after that point the documentation is the real reference since the implementation may actually be different in detail than the PEP due to later enhancements. The PEP is still useful as an historical document. (There are exceptions to that, but that is the general rule.) -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32361> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32361] global / nonlocal interference : is this a bug, a feature or a design hole ?
R. David Murray <rdmur...@bitdance.com> added the comment: Right, it was indeed "designed that way" in the sense that nolocal was only ever intended to access variables from the surrounding local scope, *not* the global scope. If you put a variable name in the global scope, nonlocal was not intended to be able to access it (it is then a global variable, not a local variable). So the only question that keeps this issue open is can the error message be improved for the case where a global declaration affects the variable name in question (the message is clear when there is no variable with that name in the outer function at all). Any change to this design would be an enhancement request and discussion of it should start on the python-ideas mailing list. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32361> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32361] global / nonlocal interference : is this a bug, a feature or a design hole ?
R. David Murray <rdmur...@bitdance.com> added the comment: What is happening here is that what nonlocal does is give the function containing the nonlocal statement access to the "cell" in the parent function that holds the local variable of that function. When you use a global statement, the name instead refers to a global variable, and there is no local cell created for that variable name. Thus you get "no binding [cell] for nonlocal 'a' found". That is literally correct from the compiler's point of view. I agree that this message is mysterious unless you understand how python scoping works at a fairly detailed level, and thus it would be nice if the error message could be improved. The code generating the message may not know that there's a global statement for that name in effect, though, so it might not be trivial to improve it. Would it be possible for nonlocal to effectively "chain", and turn the references in the inner function into global references? In theory the answer would be yes, but in practice it might be distinctly non-trivial, and would probably be a PEP level change to the language. It is currently documented that nonlocal does not look in to the global namespace (https://docs.python.org/3/reference/simple_stmts.html#nonlocal): "The nonlocal statement causes the listed identifiers to refer to previously bound variables in the nearest enclosing scope excluding globals.) -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32361> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32366] suggestion:html.escape(s, quote=True) escape \n to
R. David Murray <rdmur...@bitdance.com> added the comment: The point of html.escape is to sanitize a string that contains html such that *it does not get interpreted as html*. So adding html markup would go against its purpose. Further, including in an attribute value (which is the purpose of quote=True) would make no sense and serve no purpose that I can see. Clearly you have a use case in mind, but you did not describe it. I would recommend posting to the python-list mailing list for advice on the best way to accomplish your use case. -- components: +Library (Lib) -XML nosy: +r.david.murray resolution: -> rejected stage: -> resolved status: open -> closed ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32366> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32361] global / nonlocal interference : is this a bug, a feature or a design hole ?
Change by R. David Murray <rdmur...@bitdance.com>: -- nosy: +r.david.murray ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32361> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32276] there is no way to make tempfile reproducible (i.e. seed the used RNG)
R. David Murray <rdmur...@bitdance.com> added the comment: IMO it is better to have an API that can be used when, for example, writing tests, than to monkey patch. On the other hand, I've never had an occasion when I cared about the names of tempfiles (or directories) in my test code, and it is hard to imagine a circumstance when being able to reproduce the sequence of tempfile names chosen would matter for debugging...especially since which filenames are actually chosen from the randomly generated sequence can depend on other activity on the system. So I concur with the rejection. I wouldn't object to some sort of API that allowed one to control the filename generation without worrying that later changes to the module would break ones code, but that isn't actually the use case here, so no one has actually asked for this feature ;) -- nosy: +r.david.murray resolution: fixed -> rejected ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32276> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32264] move pygetopt.h into internal/
David Bolen <db3l@gmail.com> added the comment: After some further testing, it does not appear to be configure related but something environmental (maybe MACOSX_DEPLOYMENT_TARGET) - using the same configure options manually as build-installer seems ok. For what it's worth, since there do appear to be duplicate definitions in pygetopt.h and getopt.c, adding "extern" to the declarations in pygetopt.h appears to resolve the issue. It looks like that was lost with the removal of PyAPI_DATA. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32264> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32264] move pygetopt.h into internal/
David Bolen <db3l@gmail.com> added the comment: This commit appears to have broken OSX installer builds using the build-installer.py script (as in the last two attempts on the bolen-dmg-3.x builder), confirmed with a bisection from the first failing worker build (covering the range 02a0a19..3327a2d) It fails during the main python compilation with: ld: multiple definitions of symbol __PyOS_optarg libpython3.7m.a(getopt.o) definition of __PyOS_optarg in section (__DATA,__data) libpython3.7m.a(main.o) definition of __PyOS_optarg in section (__DATA,__common) ld: multiple definitions of symbol __PyOS_opterr (repeated for the various __PyOS__opt* symbols. It doesn't seem to be a problem with a simple manual configure/make build (probably why the regular OSX workers aren't failing). So best guess at the moment is it's related to one of the extra configure options used by the build-installer script. I'm not sure which of the commit or build process needs correction, although reverting this at least temporarily would resolve the immediate issue. -- nosy: +db3l, ned.deily, ronaldoussoren ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32264> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32340] ValueError: time data 'N/A' does not match format '%Y%m%d'
R. David Murray <rdmur...@bitdance.com> added the comment: This is not a bug in python. If it is your code contact the pyhon-list mailing for help. If you got whatsapp_xtract from somewhere else, contact that community with your questions. -- nosy: +r.david.murray resolution: -> third party stage: -> resolved status: open -> closed ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32340> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32330] Email parser creates a message object that can't be flattened
R. David Murray <rdmur...@bitdance.com> added the comment: I do wonder where you are using the string version of messages :) I actually thought I'd already done this (errors=replace), but obviously not. I don't have time now to work on a patch for this, and the patch in the other issue hasn't be updated to reflect the review I did :( -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32330> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32330] Email parser creates a message object that can't be flattened
R. David Murray <rdmur...@bitdance.com> added the comment: What would you like to see happen in that situation? Should we use errors=replace like we do for headers? (That seems reasonable to me.) Note that it can be re-serialized as binary. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32330> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32323] urllib.parse.urlsplit() must not lowercase() IPv6 scope value
R. David Murray <rdmur...@bitdance.com> added the comment: In quick search the only RFC reference to this I found was https://tools.ietf.org/id/draft-sweet-uri-zoneid-01.html, which doesn't match what you are requesting (not that urlsplit's current behavior matches that either). Do you have RFC references? -- nosy: +r.david.murray ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32323> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32307] Bad assumption on thread stack size makes python crash with musl libc
R. David Murray <rdmur...@bitdance.com> added the comment: I think we need people who do a lot of work at the C level to evaluate this, so I've added a couple to the nosy list :) -- nosy: +serhiy.storchaka, vstinner ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32307> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32307] Bad assumption on thread stack size makes python crash with musl libc
R. David Murray <rdmur...@bitdance.com> added the comment: Well, from our point of view it isn't a bad assumption, it's that muslc needs to be added to the list of exceptions. (I know almost nothing about this...I assume there is some reason we can't determine the stack size programatically?) Would you care to propose a PR? -- nosy: +r.david.murray ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32307> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32300] print(os.environ.keys()) should only print the keys
R. David Murray <rdmur...@bitdance.com> added the comment: Agreed about the other classes if we change this. Your solution looks reasonable to me. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32300> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32306] Clarify map API in concurrent.futures
New submission from David Lukeš <dafydd.lu...@gmail.com>:
The docstring for `concurrent.futures.Executor.map` starts by stating that it
is "Equivalent to map(func, *iterables)". In the case of Python 3, I would
argue this is true only superficially: with `map`, the user expects
memory-efficient processing, i.e. that the entire resulting collection will not
be held in memory at once unless s/he requests so e.g. with `list(map(...))`.
(In Python 2, the expectations are different of course.) On the other hand,
while `Executor.map` superficially returns a generator, which seems to align
with this expectation, what happens behind the scenes is that the call blocks
until all results are computed and only then starts yielding them. In other
words, they have to be stored in memory all at once at some point.
The lower-level multiprocessing module also describes
`multiprocessing.pool.Pool.map` as "A parallel equivalent of the map() built-in
function", but at least it immediately goes on to add that "It blocks until the
result is ready.", which is a clear indication that all of the results will
have to be stored somewhere before being yielded.
I can think of several ways the situation could be improved, listed here from
most conservative to most progressive:
1. Add "It blocks until the result is ready." to the docstring of
`Executor.map` as well, preferably somewhere at the beginning.
2. Reword the docstrings of both `Executor.map` and `Pool.map` so that they
don't describe the functions as "equivalent" to built-in `map`, which raises
the wrong expectations. ("Similar to map(...), but blocks until all results are
collected and only then yields them.")
3. I would argue that the function that can be described as semantically
equivalent to `map` is actually `Pool.imap`, which yields results as they're
being computed. It would be really nice if this could be added to the
higher-level `futures` API, along with `Pool.imap_unordered`. `Executor.map`
simply doesn't work for very long streams of data.
4. Maybe instead of adding `imap` and `imap_unordered` methods to `Executor`,
it would be a good idea to change the signature of `Executor.map(func,
*iterables, timeout=None, chunksize=1)` to `Executor.map(func, *iterables,
timeout=None, chunksize=1, block=True, ordered=True)`, in order to keep the API
simple with good defaults while providing flexibility via keyword arguments.
5. I would go so far as to say that for me personally, the `block` argument to
the version of `Executor.map` proposed in #4 above should be `False` by
default, because that would make it behave most like built-in `map`, which is
the least suprising behavior. But I've observed that for smaller work loads,
`imap` tends to be slower than `map`, so I understand it might be a tradeoff
between performance and semantics. Still, in a higher-level API meant for
non-experts, I think semantics should be emphasized.
If the latter options seem much too radical, please consider at least something
along the lines of #1 above, I think it would help people correct their
expectations when they first encounter the API :)
--
components: Library (Lib)
messages: 308221
nosy: David Lukeš
priority: normal
severity: normal
status: open
title: Clarify map API in concurrent.futures
type: enhancement
versions: Python 3.8
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32306>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32300] print(os.environ.keys()) should only print the keys
Change by R. David Murray <rdmur...@bitdance.com>: -- nosy: +csabella ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32300> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32300] print(os.environ.keys()) should only print the keys
R. David Murray <rdmur...@bitdance.com> added the comment: This is a consequence of the repr used by KeysView, which it inherits from MappingView. I agree that the result is surprising, but there may not be a generic fix. It's not entirely clear what KeysView should do here, but presumably we could at least add a repr to environ's use of it that would produce something useful. Note that a workaround when doing something like a travis debug is to print os.environ._data.keys(), which will print the bytes versions of the keys. I wouldn't recommend depending on that continuing to, though ;) -- nosy: +r.david.murray, rhettinger, vstinner -csabella type: behavior -> versions: -Python 3.6 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32300> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32298] Email.quopriprime over-encodes characters
R. David Murray <rdmur...@bitdance.com> added the comment: And of course tools can grep for "f...@bar.com": you can't use encoded words in an address, only in the display name. However, it occurs to me that in fact the restriction applies only to phrases, so one could use a less restrictive character set in an unstructured header such as the Subject, and that would indeed be nice. The old header folder (python 2.7 and python 3.x compat32 policy) can't do it, because they don't know anything about the syntax of the headers they fold, they just use a bunch of heuristics. The new policies in python3, however, use a smarter folder from _header_value_parser, and that *does* have access to the full parse tree for the header, and so could make smart decisions about which character set to use for the encoded word encoding. If you'd like to try your hand at a PR implementing this idea, I'll be happy to provide advice and do a review. It's not going to be anywhere near as simple as the one line change you proposed here, though :) -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32298> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32298] Email.quopriprime over-encodes characters
R. David Murray <rdmur...@bitdance.com> added the comment: >From RFC 2047: (3) As a replacement for a 'word' entity within a 'phrase', for example, one that precedes an address in a From, To, or Cc header. The ABNF definition for 'phrase' from RFC 822 thus becomes: phrase = 1*( encoded-word / word ) In this case the set of characters that may be used in a "Q"-encoded 'encoded-word' is restricted to: . An 'encoded-word' that appears within a 'phrase' MUST be separated from any adjacent 'word', 'text' or 'special' by 'linear-white-space'. The reason for this is that things like '@' are syntactically significant in headers and so must be encoded. -- nosy: +r.david.murray resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32298> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32268] quopri.decode(): string argument expected, got 'bytes'
R. David Murray <rdmur...@bitdance.com> added the comment: We generally don't do advance type checking (look before you leap) in Python. This allows a type the programmer hadn't planned for to be used as long as it "quacks like" the expected type (this is called duck typing). So the error was produced exactly where it should be and exactly as it should be: it was produced by the StringIO object you provided, when quopri tried to write the binary output that it produces to the object you handed it. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32268> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32288] Inconsistent behavior with slice assignment?
R. David Murray <rdmur...@bitdance.com> added the comment: It actually makes sense that a slice assignment with a different length replacement list with a step of 1 works but any other step doesn't. Logically you can see that you can cut out a chunk and replace it with a different sized chunk, but you can't do that if the step is not abs(1). So a doc tweak may be appropriate. And it is surprising that -1 doesn't work (but why would you ever use it? :), so that might be a buglet. For a numpy array, I imagine the rules are different, so an error there on stride 1 is not that surprising either, though *perhaps* there is room for improvement on the numpy side. (In other words, the stride 1 python behavior is "correct" from a python language perspective.) And yes, it would be much easier to discuss these separate issues in separate issues. Now you know for next time :) -- nosy: +r.david.murray ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32288> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32287] Import of _pyio module failed on cygwin
Change by R. David Murray <rdmur...@bitdance.com>: -- nosy: +erik.bray ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32287> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32268] quopri.decode(): string argument expected, got 'bytes'
R. David Murray <rdmur...@bitdance.com> added the comment: Right, this is not a bug, it is working as documented. You could submit an enhancement request, but I'm surprised to find that anyone is actually using that module :) We unfortunately have multiple implementations of quoted printable handling in the stdlib. You might be interested in the functions in the binascii module, which do accept unicode input when doing decoding. -- nosy: +r.david.murray resolution: -> not a bug stage: -> resolved status: open -> closed type: -> behavior ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32268> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32267] strptime misparses offsets with microsecond format
Change by R. David Murray <rdmur...@bitdance.com>: -- nosy: +belopolsky ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32267> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32259] Misleading "not iterable" Error Message when generator return a "simple" type, and a tuple is expected
R. David Murray <rdmur...@bitdance.com> added the comment: I shouldn't have searched the docs for 'unpackable', I should have searched for 'unpack'. Doing that reveals that the term 'unpack' is used for other concepts, whereas the term 'iterable' is precise. So I think it would unacceptably lower the precision of the error message to add that word. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32259> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32259] Misleading "not iterable" Error Message when generator return a "simple" type, and a tuple is expected
R. David Murray <rdmur...@bitdance.com> added the comment: > How about "[TYPE] object is not iterable/unpackable" I just grepped the docs, and the term 'unpackable' does not appear anywhere in them. I don't think this would be an improvement. As for the earlier suggestion of adding "expected tuple" does not work, because it is not a tuple being expected, it is an iterable, and saying "expected iterable" would be redundant with saying "is not iterable". What about "TypeError: expected iterable but found "? That's parallel to some other type error messages we already generate. Would that be any clearer? (I'm not sure it would be, it says the same thing.) -- nosy: +r.david.murray ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32259> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32255] csv.writer converts None to '""\n' when it is first line, otherwise '\n'
R. David Murray <rdmur...@bitdance.com> added the comment: The second case is indeed the bug, as can be seen by running the examples against python2.7. It looks like this was probably broken by 7901b48a1f89 from issue 23171. -- components: +Library (Lib) -IO nosy: +r.david.murray stage: patch review -> needs patch versions: -Python 2.7, Python 3.4, Python 3.5, Python 3.8 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32255> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32255] csv.writer converts None to '""\n' when it is first line, otherwise '\n'
R. David Murray <rdmur...@bitdance.com> added the comment: Serhiy, since it was your patch that probably introduced this bug, can you take a look? Obviously it isn't a very high priority bug, since no one has reported a problem (even this issue isn't reporting the change in behavior as a *problem* :) -- nosy: +serhiy.storchaka ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32255> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22589] mimetypes uses image/x-ms-bmp as the type for bmp files
R. David Murray <rdmur...@bitdance.com> added the comment: Thanks, nitishch. As I said, I'm not going to backport this unless someone advances an argument in favor that discusses the possible backward compatibility issue. (I'm not sure there are any significant ones, but someone needs to research it and present the results.) -- resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: +Python 3.7 -Python 2.7 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue22589> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22589] mimetypes uses image/x-ms-bmp as the type for bmp files
R. David Murray <rdmur...@bitdance.com> added the comment: New changeset ede157331b4f9e550334900b3b4de1c8590688de by R. David Murray (Nitish Chandra) in branch 'master': bpo-22589 Changed MIME type of .bmp to "image/bmp" (#4756) https://github.com/python/cpython/commit/ede157331b4f9e550334900b3b4de1c8590688de -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue22589> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32212] few discrepancy between source and docs in logging
R. David Murray <rdmur...@bitdance.com> added the comment: It does matter, though, because in Python you can specify a positional argument as if it were a keyword argument if you use the name from the source rather than the documented name. We have made other doc corrections along these lines. We've even done it for C functions where you can't specify the argument as if it were a keyword argument, though that is considerably more rare. That's a different question from the question of whether typing/linters should care, though. Arguably they should recommend specifying them as positionals. -- status: pending -> open ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32212> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32229] Simplify hiding developer warnings in user facing applications
R. David Murray <rdmur...@bitdance.com> added the comment: Ah, OK, that makes more sense. I don't run into warnings other than DeprecationWarnings in practice, so I tend to forget about them :) I think specifying warnings filters is pretty inscrutable, in general. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32229> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32229] Simplify hiding developer warnings in user facing applications
R. David Murray <rdmur...@bitdance.com> added the comment: I haven't been following that discussion, and isolated from that that discussion the title of this issue and this proposal make no sense to me. Warnings are off by default, so you don't need to hide them. In what context does this get used? If this is going to be used to implement turning warnings on for the main application, why isn't it named "show_warnings"? -- nosy: +r.david.murray ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32229> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32215] sqlite3 400x-600x slower depending on formatting of an UPDATE statement in a string
R. David Murray <rdmur...@bitdance.com> added the comment: It disappears for me running it on linux with the blank added. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32215> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22589] mimetypes uses image/x-ms-bmp as the type for bmp files
R. David Murray <rdmur...@bitdance.com> added the comment: That's the basis, but its a bit more complicated than that (NEWS item, putting bpo-22589 in the issue title, the question of signing a CLA, though a CLA doesn't really matter for this kind of change IMO). If you can't do it one of our core-mentorship volunteers will take care of it, I'm sure. -- keywords: +easy ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue22589> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22589] mimetypes uses image/x-ms-bmp as the type for bmp files
R. David Murray <rdmur...@bitdance.com> added the comment: If image/bmp is now[*] the official IANA type, mimetypes should use that. However, because this is a change with possible backward compatibility issues, it should probably only go into 3.7, but I'm open to arguments about that. [*] The mimetypes module is very old and nobody specifically maintains it; we depend on user reports for updates to it, and obviously this one was overlooked. Care to prepare a PR? -- nosy: +r.david.murray ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue22589> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27240] 'UnstructuredTokenList' object has no attribute '_fold_as_ew'
R. David Murray <rdmur...@bitdance.com> added the comment: Huh, I thought I had closed it. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue27240> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32217] freeze.py fails to work.
R. David Murray <rdmur...@bitdance.com> added the comment: Does the 3.6.0 freeze fail under 3.6.0, or the 3.6.3 freeze fail under 3.6.3? If not, there's no bug to report. -- nosy: +r.david.murray ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32217> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32215] sqlite3 400x-600x slower depending on formatting of an UPDATE statement in a string
Change by R. David Murray <rdmur...@bitdance.com>: -- versions: +Python 3.7 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32215> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32215] sqlite3 400x-600x slower depending on formatting of an UPDATE statement in a string
R. David Murray <rdmur...@bitdance.com> added the comment: ...using the *same* sqlite version... -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32215> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32215] sqlite3 400x-600x slower depending on formatting of an UPDATE statement in a string
R. David Murray <rdmur...@bitdance.com> added the comment: I can confirm that there is a difference on linux as well, using the sqlite version for both 2.7 and 3.7: rdmurray@pydev:~/python/p27[2.7]>./python sqlite3_27_36_performance_bug.py First step: 3.22849011421 Second step: 3.2167429924 rdmurray@pydev:~/python/p37[master]>./python ../p27/sqlite3_27_36_performance_bug.py First step: 3.2722721099853516 Second step: 4.094221353530884 (I changed time.clock() to time.time()). -- nosy: +r.david.murray ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32215> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32213] assertRaises and subTest context managers cannot be nested
Change by R. David Murray <rdmur...@bitdance.com>: -- resolution: -> not a bug ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32213> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32213] assertRaises and subTest context managers cannot be nested
R. David Murray <rdmur...@bitdance.com> added the comment: Yes, that's an easy mistake to make. I avoided it by only running one of the tests cases at a time, and I'll admit I had to think about it for a while to understand what was going on in your first case. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32213> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32213] assertRaises and subTest context managers cannot be nested
R. David Murray <rdmur...@bitdance.com> added the comment: To be pedantic, are not macros, they are context managers :) Your first case is not something I would have thought of coding. In the to_raise=True case, the subTest is failing because an exception is raised inside its scope. In the to_raise=False case, the subTest scope has already ended before the assertRaises scope completes and raises its error because no exception was raised. That is, there is no subTest in effect to be reported when that failure occurs. In your second case, when to_raise is False, no exception is raised, so the assertRaises correctly fails, and the subtest reports that to_raise is False. When to_raise is true, the exception is raised, the assertRaises passes and so does the subtest. In other words, I can't reproduce the problem you cite for the second case. Looking at what you pasted, it looks like you confused a test_assert_outer report with a test_report_inner report. So, as far as I can see, there's nothing broken here, everything is working according to the documentation :) -- nosy: +r.david.murray ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32213> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32212] few discrepancy between source and docs in logging
Change by R. David Murray <rdmur...@bitdance.com>: -- stage: -> needs patch versions: +Python 3.7 -Python 3.4, Python 3.5 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32212> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32212] few discrepancy between source and docs in logging
R. David Murray <rdmur...@bitdance.com> added the comment: Ah. I'm guessing Vinay will probably want to fix the docs, then, since that's less disruptive backward compatibility wise. -- nosy: +vinay.sajip ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32212> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32212] few discrepancy between source and docs in logging
R. David Murray <rdmur...@bitdance.com> added the comment: I don't understand what the bug is that you are reporting here. Can you clarify? mypy isn't part of the stdlib, so an explanation in terms of what's in the stdlib would be helpful. -- nosy: +r.david.murray ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32212> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32182] Infinite recursion in email.message.as_string()
R. David Murray <rdmur...@bitdance.com> added the comment: I checked, and your example works correctly with the patch applied. I've committed the PR. Let me know if you find any other issues (there are several open issues with exactly how headers are wrapped, but I don't think there are any open where serialization fails completely.) -- resolution: -> fixed stage: -> resolved status: open -> closed type: crash -> behavior versions: +Python 3.7 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32182> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31831] EmailMessage.add_attachment(filename="long or spécial") crashes or produces invalid output
R. David Murray <rdmur...@bitdance.com> added the comment: The PR has been committed. -- resolution: -> fixed stage: -> resolved status: open -> closed type: crash -> behavior versions: -Python 3.4, Python 3.5 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31831> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30788] email.policy.SMTP.fold() issue for long filenames with spaces
R. David Murray <rdmur...@bitdance.com> added the comment: The PR has been committed. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: -Python 3.5 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue30788> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27240] 'UnstructuredTokenList' object has no attribute '_fold_as_ew'
R. David Murray <rdmur...@bitdance.com> added the comment: New changeset a87ba60fe56ae2ebe80ab9ada6d280a6a1f3d552 by R. David Murray (Miss Islington (bot)) in branch '3.6': bpo-27240 Rewrite the email header folding algorithm. (GH-3488) (#4693) https://github.com/python/cpython/commit/a87ba60fe56ae2ebe80ab9ada6d280a6a1f3d552 -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue27240> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27240] 'UnstructuredTokenList' object has no attribute '_fold_as_ew'
R. David Murray <rdmur...@bitdance.com> added the comment: New changeset 85d5c18c9d83a1d54eecc4c2ad4dce63194107c6 by R. David Murray in branch 'master': bpo-27240 Rewrite the email header folding algorithm. (#3488) https://github.com/python/cpython/commit/85d5c18c9d83a1d54eecc4c2ad4dce63194107c6 -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue27240> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32174] nonASCII punctuation characters can not display in python363.chm.
R. David Murray <rdmur...@bitdance.com> added the comment: The doc source files do not contain smart quotes, and as far as I know, sphinx does produce correct utf-8. Recently there was a bug where incorrect smart quotes were leaking out of the internationalization of the docs, so this might be a problem that is already fixed. On the other hand, there might be something broken about the chm production process. I have no idea who would be the right person to investigate that, since I think Steve just spins the wheel on existing tools to get them generated :) On the gripping hand, could there be something broken about your local charset configuration? Does anyone else see this problem? -- nosy: +r.david.murray ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32174> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32172] Add length counter for iterables
R. David Murray <rdmur...@bitdance.com> added the comment: Guido specifically rejected __len__ for iterators when the iteration protocol was designed. This has become a FREQ in recent times (Frequently Rejected Enhancement Request :) The rationale, as I understand it, is that an iterator object should always evaluate to True in a boolean context, but I don't know why. There is also a consistency argument: since not all iterators *can* have a len, then none should, because if some did and some didn't you couldn't use iterators interchangeably in code the way you can now. In other words, you can't make __len__ part of the iterator protocol, so iterators don't have a __len__. -- nosy: +r.david.murray ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32172> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32168] Mutable instance variables don't get new references with args.
R. David Murray <rdmur...@bitdance.com> added the comment: For the record: https://docs.python.org/3/faq/programming.html#id13 -- nosy: +r.david.murray ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32168> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32182] Infinite recursion in email.message.as_string()
R. David Murray <rdmur...@bitdance.com> added the comment: It is gh-3488 if you want to try it out. Feedback welcome. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32182> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32182] Infinite recursion in email.message.as_string()
R. David Murray <rdmur...@bitdance.com> added the comment: This is almost certainly either a duplicate or will be fixed by a PR I have pending, that I don't have time to look for right now, that rewrites the folder. I'll try to get to merging that PR soonish, but it might not happen before the holidays ;) -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32182> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32144] email.policy.SMTP and SMTPUTF8 doesn't honor linesep's value
R. David Murray <rdmur...@bitdance.com> added the comment: A note would be too heavy handed. And get_content is a different function from get_payload, so there is no change in behavior, there is a new API with a more consistent behavior. Basically, Python programs in general use \n line endings internally, and email was an exception to that rule (and is no longer, in the new API). (There's a now closed issue about this somewhere in the tracker.) -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32144> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32142] heapq.heappop - documentation misleading or doesn't work
R. David Murray <rdmur...@bitdance.com> added the comment: I would suggested following the statement "To create a heap, use a list initialized to [], or you can transform a populated list into a heap via function heapify()." with "Any mutation of the list thereafter must maintain the heap invariant in order for the list to remain a heap." -- nosy: +r.david.murray ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32142> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32117] Tuple unpacking in return and yield statements
David Cuthbert <da...@kanga.org> added the comment: Oops, I wasn't looking broadly enough. This is also used in the augmented assignment statements syntax, e.g. a += 1, 2, 3 -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32117> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32117] Tuple unpacking in return and yield statements
David Cuthbert <da...@kanga.org> added the comment: Hm... that leaves the only production for expression_list as: subscription ::= primary "[" expression_list "]" And I'm not sure that this shouldn't also be replaced by starred_list. It's not accepted today, though: In [6]: a[1,*(4, 5, 6)] File "", line 1 a[1,*(4, 5, 6)] ^ SyntaxError: invalid syntax I will ask about this again on python-dev@ -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32117> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32117] Tuple unpacking in return and yield statements
David Cuthbert <da...@kanga.org> added the comment: CLA processed, and BDFL has assented on python-dev. Serhiy, thoughts on next steps? -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32117> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32159] Remove tools for CVS and Subversion
R. David Murray <rdmur...@bitdance.com> added the comment: I think Serhiy's point is that it doesn't matter whether or not it is used by a tool, it is useful for humans. I don't know if it is used by the tracker; Ezio worked on that code, I think. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32159> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32144] email.policy.SMTP and SMTPUTF8 doesn't honor linesep's value
R. David Murray <rdmur...@bitdance.com> added the comment: OK, I should have used the term the docs actually use: "serialization". get_content() is, I hope, clearly not serialization, while as_string() is. Does that make it make more sense? Do you see a way to improve the docs in this regard? -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32144> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
