[issue12756] datetime.datetime.utcnow should return a UTC timestamp
R. David Murray added the comment: Note also that datetime.now() gives you a naive datetime. From an API consistency standpoint I think it makes sense that datetime.utcnow() gives a naive datetime. It would actually be confusing (IMO) for it to return an aware datetime. I can see why you might disagree, but backward compatibility wins in this case regardless. -- ___ Python tracker <https://bugs.python.org/issue12756> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46392] MessageIDHeader is too strict for message-id
R. David Murray added the comment: Note that the parser does attempt to accept obsolete syntax (registering defects for it), so if there is a bug in the implementation of the obsolete syntax handling it should be fixed. And yes, there have been other bugs with whitespace handling in the parser, unfortunately. Examples would be most helpful, even if you don't write unit tests. Most of the tests, by the way, are in test__header_value_parser (search for message_id). There aren't very many, so more would be good. -- ___ Python tracker <https://bugs.python.org/issue46392> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46392] MessageIDHeader is too strict for message-id
R. David Murray added the comment: The general idea is that the string version of the header should contain all of the original information, but the parsed elements (the things returned by special header attributes) will contain the valid data, if any. So if the string version of the header is being truncated or transformed (other than whitespace changes during re-folding), that is a bug. Your examples involve comment fields, and I'm afraid that my development of the parser stopped before I did very much with comments. Therefore I am not surprised that comments are handled incorrectly :( :( They aren't very common in the wild, as far as I was able to tell. which is why they were my last priority. -- ___ Python tracker <https://bugs.python.org/issue46392> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43333] utf8 in BytesGenerator
R. David Murray added the comment: Yeah, I think we need a complete example here. Note that in the general case there is no such thing as an RFC-valid email in unicode (which is what python strings are), though with utf8=True and an email involving only text you might get away with it. I assume you've tried policy=policy.default.clone(utf=True) when creating the email? It will probably help to encode the 'text' to utf8 and use message_from_bytes to read it, but that may not be your only problem. It depends on exactly what is in the message and how the message gets recorded in your XML whether this is even going to work in the general case. The xml conversion may have already lost information, but hopefully not. -- ___ Python tracker <https://bugs.python.org/issue4> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17505] [doc] email.header.Header.__unicode__ does not decode header
R. David Murray added the comment: The policy is named 'default' because it was intended to become the default two feature releases after the new email code became non-provisional (first: deprecate not specifying an explicit policy, next release make default the default policy and make the deprecation only cover compat32). However, for various reasons that switchover did not happen (one big factor being my reduced time spent doing python development). It can happen any time someone steps forward to guide it through the release process. -- ___ Python tracker <https://bugs.python.org/issue17505> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12537] mailbox's _become_message is very fragile
R. David Murray added the comment: That is the first step, yes. In addition to that we need to have the various explain_to methods delete the special attributes that aren't valid for the new Message subtype. -- ___ Python tracker <http://bugs.python.org/issue12537> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12953] Function calls missing from profiler output
R. David Murray added the comment: I wonder if it has something to do with range returning a special type? range and len are very different things under the hood. -- nosy: +r.david.murray ___ Python tracker <http://bugs.python.org/issue12953> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12537] mailbox's _become_message is very fragile
R. David Murray added the comment: Unfortunately I don't think there is any way except going through each subclass to see what special attributes it creates. -- ___ Python tracker <http://bugs.python.org/issue12537> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1170] shlex have problems with parsing unicode
R. David Murray added the comment: Ezio, I don't see any indication in this ticket that this bug was actually *fixed* in 3.x. Unicode doesn't cause immediate errors in 3.x, but it isn't recognized as wordchars, etc. Am I missing something? -- ___ Python tracker <http://bugs.python.org/issue1170> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11686] Update of some email/ __all__ lists
R. David Murray added the comment: Why? The bug hasn't been fixed yet. -- assignee: -> r.david.murray stage: -> patch review status: closed -> open versions: +Python 3.2 ___ Python tracker <http://bugs.python.org/issue11686> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11780] email.encoders are broken
R. David Murray added the comment: I may have, but I'd prefer to check before closing the issue. (I'm deep in another project right now, but I'll review all these open bugs this fall some time). -- status: closed -> open ___ Python tracker <http://bugs.python.org/issue11780> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13010] devguide doc: ./python.exe on OS X
R. David Murray added the comment: It is python.exe on OS/X, which I've always found most odd. The reason is that the OS/X filesystem is case insensitive by default, and there is a directory named 'Python'. -- nosy: +r.david.murray ___ Python tracker <http://bugs.python.org/issue13010> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2193] Cookie Colon Name Bug
R. David Murray added the comment: I'm flat out right now on other projects. But if no one else gets around to doing a final review and commit I should be able to get to it by the end of October. If I don't, please ping me by posting here again. -- ___ Python tracker <http://bugs.python.org/issue2193> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13050] RLock support the context manager protocol but this is not documented
Changes by R. David Murray : -- assignee: docs@python components: Documentation nosy: docs@python, r.david.murray priority: normal severity: normal status: open title: RLock support the context manager protocol but this is not documented ___ Python tracker <http://bugs.python.org/issue13050> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13060] make round() floating-point errors less hurtful
R. David Murray added the comment: Note that a C accelerator for Decimal is in the works. -- nosy: +mark.dickinson, r.david.murray ___ Python tracker <http://bugs.python.org/issue13060> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13060] make round() floating-point errors less hurtful
R. David Murray added the comment: It seems to me that saying "floating point" and "mathematically correct" in the same breath is...optimistic :) But that's why I added Mark to nosy, he knows far more about this stuff than I do. As far as I know the accelerator is feature complete at this point. I think the goal is to ship it with 3.3, but I'm not sure where we are at in the process of making that a reality. -- nosy: +skrah ___ Python tracker <http://bugs.python.org/issue13060> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3232] Wrong str->bytes conversion in Lib/encodings/idna.py
R. David Murray added the comment: +1. decode_idna is likely to be useful to the email package. -- ___ Python tracker <http://bugs.python.org/issue3232> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13076] Bad links to 'time' in datetime documentation
Changes by R. David Murray : -- stage: -> needs patch versions: -Python 2.6, Python 3.1, Python 3.4 ___ Python tracker <http://bugs.python.org/issue13076> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13077] Unclear behavior of daemon threads on main thread exit
R. David Murray added the comment:
It seems clear enough to me that when a process terminates ("the entire Python
program exits") then all of its threads must terminate. That's part of the
definition of threads, to my understanding.
I think the confusion arises from the use of the word "deamon", which has been
discussed as a bad thing elsewhere in this tracker. A unix user would expect a
"daemon" to keep running in the background, whereas here it is exactly the
opposite. See issue 5906 for example, where in the context of Multiprocessing
it becomes even more confusing. Perhaps a similar note that 'daemon' does not
mean what it does in unix would be a good idea.
--
nosy: +r.david.murray
stage: -> patch review
versions: -Python 2.6, Python 3.1, Python 3.4
___
Python tracker
<http://bugs.python.org/issue13077>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13080] test_email fails in refleak mode
Changes by R. David Murray : -- assignee: -> r.david.murray ___ Python tracker <http://bugs.python.org/issue13080> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4147] xml.dom.minidom toprettyxml: omit whitespace for text-only elements
R. David Murray added the comment: This looks correct to me, and it tested out fine on the test suite (and the provided test failed without the provided fix), so I committed it. I have a small concern that the change in output might be a bit radical for a bug fix release, but it does seem to me that this is clearly a bug. If people think it shouldn't go in the bug fix releases let me know and I'll back it out. Thanks for the patch, Dan. -- nosy: +r.david.murray stage: test needed -> committed/rejected status: open -> closed type: feature request -> behavior versions: +Python 2.7, Python 3.3 ___ Python tracker <http://bugs.python.org/issue4147> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4147] xml.dom.minidom toprettyxml: omit whitespace for text-only elements
R. David Murray added the comment: Heh, you happened to post your patch at a time when I wanted something to do as a break from something I didn't want to do...and I *thought* I understood the problem, after reading the various links. But clearly I didn't. We don't have someone who has stepped forward to be xml maintainer, so I just went ahead and committed it. I should find time to look at your new patch some time today, or perhaps Ezio will have time. (Clearly minidom doesn't have enough tests.) -- ___ Python tracker <http://bugs.python.org/issue4147> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13094] setattr misbehaves when used with lambdas inside for loop
R. David Murray added the comment: Sorry. It is intended behavior. The lambda 'each' is bound to the local 'each', and by the time the lambda's execute, the value of 'each' is 'baz'. I'm going to turn this into a doc bug, because while I'm pretty sure this is documented *somewhere*, I don't see it in the programming FAQ, and it should be there. -- assignee: -> docs@python components: +Documentation -None nosy: +docs@python, r.david.murray stage: -> needs patch type: -> behavior versions: +Python 3.2, Python 3.3 ___ Python tracker <http://bugs.python.org/issue13094> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13094] Need Programming FAQ entry for the behavior of closures
Changes by R. David Murray : -- title: setattr misbehaves when used with lambdas inside for loop -> Need Programming FAQ entry for the behavior of closures ___ Python tracker <http://bugs.python.org/issue13094> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13050] RLock support the context manager protocol but this is not documented
R. David Murray added the comment: Hmm. But what I did was look up the RLock section of the manual to answer the question "does this support the context manager protocol", and the answer appeared to be no. In a reference manual I would expect all the important features of an object to be described in that object's documentation, or linked to therefrom. -- ___ Python tracker <http://bugs.python.org/issue13050> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13171] Bug in tempfile module
R. David Murray added the comment: I wonder if it is a bug in Windows? Have you tried similar experiments with regular files? tempfile is really just about *where* the files are located (and what happens when they are closed), not about their fundamental nature as OS file objects. (I could be wrong about that on Windows of course, I'm more familiar with Linux.) -- nosy: +r.david.murray ___ Python tracker <http://bugs.python.org/issue13171> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13163] `port` and `host` are confused in `_get_socket
R. David Murray added the comment: Well, your patch is a little *too* simple: it doesn't change the function prototype to match :) This is a cosmetic issue rather than a bug, but it would still be nice to fix it. Or maybe a documentation issue in the sense that Python code is (usually) self documenting :) -- priority: normal -> low ___ Python tracker <http://bugs.python.org/issue13163> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1757072] Zipfile robustness
R. David Murray added the comment: "This issue" is currently a collection point for specific "allow this in lax mode" issues. Do you have one or more specific cases in point that you'd like to talk about? (Note that the 'garbage after end of file' bug has already been fixed.) -- ___ Python tracker <http://bugs.python.org/issue1757072> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7322] Socket timeout can cause file-like readline() method to lose data
R. David Murray added the comment: This patch has caused a non-trivial regression between 3.2 and 3.2.1. The scenario in which I observed it is poplib. I create a POP3 connection with a timeout. At one point in its processing, poplib is reading lines until it gets a line '.\r\n', at which point the transaction is complete and it returns data to the caller. If the pop server fails to terminate the transaction, we get a timeout on the read. However, the POP server may still be alive, it may just have failed to close the transaction (servers have been observed in the wild that do this[*]). Before this patch, one could catch the socket.timeout and recover from the failed transaction (loosing the transaction data, but that's OK because the transaction was incomplete...it would be better to get the partial transaction, but that's a poplib issue, not a socket issue). One could then continue processing, sending new transactions to the POP server and getting responses. After the patch, once the socket error is raised t here is no way to continue poplib processing short of tearing down the connection and rebuilding it, and restarting the POP processing from the beginning. Now, this is clearly an abnormal situation (a POP server randomly not completing its transactions), but it was observed in the wild, and does represent a regression. I think that Antoine's idea of making readline functional despite timeouts was the better approach. Also note that Antoine's change to the makefile documentation is wrong with this patch in place, since a timeout invalidates the makefile rather than just "leaving the internal buffers in an inconsistent state". Backing out this patch would probably be better than leaving it in place, if a better fix can't be found. [*] The regression was detected testing against a test POP server designed to exhibit defective behaviors that have been observed over the years by the maintainers of the test server. I can't point to specific existing servers that exhibit the broken behavior, but it did happen in the past and no doubt someone will write a buggy POP server that has the same broken behavior some time in the future as well. -- nosy: +r.david.murray resolution: fixed -> stage: committed/rejected -> status: closed -> open ___ Python tracker <http://bugs.python.org/issue7322> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7322] Socket timeout can cause file-like readline() method to lose data
R. David Murray added the comment: I don't think it is optimistic. The poplib transaction pattern is: send a command, get a response. If the response is not properly terminated, throw it away. Send a new command, get a response. There's no ambiguity there. In addition, this is a common tcp client-server model, so I think it applies more widely than just poplib. Please note that the timeout is *not* because the socket data transmission has timed out and data was lost in transit. There are no partially filled readline buffers in this scenario. The timeout is because the client is waiting for a *line* of data that the server never sends. Again, this is likely to be a common failure mode in tcp client/server applications, and to my mind is exactly what the timeout parameter to the constructor is most useful for. -- ___ Python tracker <http://bugs.python.org/issue7322> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13236] unittest needs more flush calls
R. David Murray added the comment: How can a lack of flushes lose output? Delay it maybe, but unless your file class is broken I don't see how data would be lost. -- nosy: +r.david.murray versions: -Python 2.6 ___ Python tracker <http://bugs.python.org/issue13236> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7322] Socket timeout can cause file-like readline() method to lose data
R. David Murray added the comment: Your suggestion sounds good to me. I still think that it is a common failure mode in a client server transaction for the server to fail to send a (complete) line that the client is expecting, and vice versa, requiring a timeout, but not necessarily a "restart from scratch". Often the client/server protocol has a useful checkpoint to restart from short of start from scratch. In the case of many protocols, that would be "client issues a new command". -- ___ Python tracker <http://bugs.python.org/issue7322> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13254] maildir.items() broken
R. David Murray added the comment: I'm assigning this to myself so I don't lose it, but if someone wants to work on a patch please do. It'll be a bit before I can look at it. -- assignee: -> r.david.murray priority: normal -> high stage: -> needs patch ___ Python tracker <http://bugs.python.org/issue13254> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13254] maildir.items() broken
R. David Murray added the comment: Since this is a regression I'm upping the priority further to release blocker, so that we don't put out another release with the regression still in it. -- nosy: +benjamin.peterson, georg.brandl priority: high -> release blocker ___ Python tracker <http://bugs.python.org/issue13254> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13351] Strange time complexity when creating nested lists
R. David Murray added the comment: In the case of 'lists' an object is being allocated each time through the inner loop. In the case of simple_lists, no such allocation is being done. Your timing issues are probably related to the memory allocation behavior of your system. -- nosy: +r.david.murray ___ Python tracker <http://bugs.python.org/issue13351> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13284] email.utils.formatdate function does not handle timezones correctly.
R. David Murray added the comment: Unless I misunderstand your concerns, this is a duplicate of issue 665194. -- nosy: +r.david.murray resolution: -> duplicate status: open -> closed superseder: -> datetime-RFC2822 roundtripping ___ Python tracker <http://bugs.python.org/issue13284> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13284] email.utils.formatdate function does not handle timezones correctly.
R. David Murray added the comment: formatdate doesn't know anything about datetimes, so it doesn't make any sense to me to say that it doesn't notice changes in tzinfo. That's why the fix for issue 665194 introduces a new method for formatting datetimes. -- ___ Python tracker <http://bugs.python.org/issue13284> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11937] Interix support
R. David Murray added the comment: Just a note that buildbot does work behind a firewall (mine are set up that way). The client calls out to the master. A really restrictive corporate firewall may need outbound holes punched, but there are no inbound connections to the client. -- nosy: +r.david.murray ___ Python tracker <http://bugs.python.org/issue11937> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4147] xml.dom.minidom toprettyxml: omit whitespace for text-only elements
R. David Murray added the comment: Yeah, I just haven't found time to do the revert yet (my first naive attempt using hg commands failed and I haven't found time to figure it out or do the reverse-patch method). -- ___ Python tracker <http://bugs.python.org/issue4147> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13434] time.xmlrpc.com dead
R. David Murray added the comment: We've had problems with this service going away for a while before. I think the test was marked skip for at least a year before someone (it might have been me) noticed that it was back and reactivated it. There's a ticket in here somewhere for it. -- nosy: +r.david.murray ___ Python tracker <http://bugs.python.org/issue13434> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13456] Providing a custom HTTPResponse class to HTTPConnection
New submission from R. David Murray : The doc string for HTTPConnection.getresponse mentions (in broken English) that the instance's response_class attribute determines what class gets instantiated for a response. The docs do not mention this attribute, nor any other way to control what class is used. Since this attribute already exists and is mentioned in the doc string, can we consider this a doc error and just document it? -- assignee: docs@python components: Documentation messages: 148136 nosy: docs@python, orsenthil, r.david.murray priority: normal severity: normal status: open title: Providing a custom HTTPResponse class to HTTPConnection versions: Python 3.2, Python 3.3 ___ Python tracker <http://bugs.python.org/issue13456> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13460] urllib methods should demand unicode, instead demand str
R. David Murray added the comment: I suspect you want to be using Python3, then. Although it is nowhere near as simple as that...even with Python3 you still sometimes have to deal with the fact that the wire protocol is bytes. -- nosy: +r.david.murray resolution: -> out of date status: open -> closed ___ Python tracker <http://bugs.python.org/issue13460> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13464] HTTPResponse is missing an implementation of readinto
New submission from R. David Murray : HTTPResponse subclasses RawIOBase, but does not provide an implementation of readinto, only read. This means that it is not conforming to the IO spec, and so it cannot be wrapped in a BufferedIOBase when using the C version of io. -- components: Library (Lib) keywords: easy messages: 148199 nosy: orsenthil, pitrou, r.david.murray priority: normal severity: normal status: open title: HTTPResponse is missing an implementation of readinto type: behavior versions: Python 3.2, Python 3.3 ___ Python tracker <http://bugs.python.org/issue13464> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13480] range exits loop without action when start is higher than end
R. David Murray added the comment: Nope. If you want to count backward, use a negative step. Not doing anything if end is lower than start allows code to take advantage of "don't care" edge cases, just like 'abc'[4:] returning the empty string does. Range is often used in 'for' loops, so having the loop not execute if the computed end is less than the computed start is an intentional and important feature. -- nosy: +r.david.murray resolution: -> invalid stage: -> committed/rejected status: open -> closed ___ Python tracker <http://bugs.python.org/issue13480> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13460] urllib methods should demand unicode, instead demand str
R. David Murray added the comment: Well, most of the point of Python3 is that the string type *is* unicode, which is what I meant by saying that you probably wanted Python3 in order to solve your concern :) There are still a few bugs to work out in the wire-protocol/unicode interface in Python3, but it is a *lot* cleaner than it was in Python2. -- ___ Python tracker <http://bugs.python.org/issue13460> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6135] subprocess seems to use local encoding and give no choice
R. David Murray added the comment: If you decide this is only a doc bug, please see also related issue 12832. -- nosy: +r.david.murray ___ Python tracker <http://bugs.python.org/issue6135> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13498] os.makedirs exist_ok documentation is incorrect, as is some of the behavior
New submission from R. David Murray : The documentation for os.makedirs says: If the target directory with the same mode as specified already exists, raises an OSError exception if exist_ok is False, otherwise no exception is raised. This is not correct. If the file exists but the mode is different than that specified (or defaulted) after applying the umask, then an error is raised regardless of the value of exist_ok. The above wording also implies that if the directory exists but has a different mode, that the mode will be changed. Again, this is not what the code does. It's not clear how useful this raise behavior is, but reading the original issue that added this option it is clearly intentional. The documented behavior does seem useful, but if it actually reset the mode that would be a fairly significant behavior change, and would not be a good idea if the user had not specified a mode. However, at the very least exists_ok should not raise if no mode was specified in the call. The error message raised is also wrong in this case, since it says that the error is that the file already exists when we've said that that is OK. A custom error message for this case would be better. -- assignee: docs@python components: Documentation, Library (Lib) keywords: easy messages: 148564 nosy: docs@python, r.david.murray priority: normal severity: normal stage: needs patch status: open title: os.makedirs exist_ok documentation is incorrect, as is some of the behavior type: behavior versions: Python 3.2, Python 3.3 ___ Python tracker <http://bugs.python.org/issue13498> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13502] Documentation for Event.wait return value is either wrong or incomplete
New submission from R. David Murray : The documentation for Event.wait says: This method returns the internal flag on exit, so it will always return True except if a timeout is given and the operation times out. In fact, however, if the thread that sets the flag immediately clears it, wait will return False. Antoine looking at the code says that this appears to be intentional, and that would make sense since originally wait returned no value. My use case is one thread waiting on another to complete a work loop. Normally the worker thread goes to sleep after clearing the flag, but sometimes it immediately starts a new work loop. In either case I want the monitoring loop to take an action when the work loop completes, and raise an error if the wait times out. It looked to me like Event.wait would work in the scenario. -- assignee: docs@python components: Documentation messages: 148604 nosy: docs@python, pitrou, r.david.murray, tim_one priority: normal severity: normal stage: needs patch status: open title: Documentation for Event.wait return value is either wrong or incomplete type: behavior versions: Python 2.7, Python 3.2, Python 3.3 ___ Python tracker <http://bugs.python.org/issue13502> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13502] Documentation for Event.wait return value is either wrong or incomplete
R. David Murray added the comment: Thinking about it, if the flag's state if the wait does not expire is not guaranteed to be True, then what I really need is some way to know, when the wait call completes, whether or not it terminated because of a timeout or not. I can always query the value of the flag separately if its value can in any case be changed by another thread. I am perhaps using the wrong tool, I'll have to look at the docs further. -- ___ Python tracker <http://bugs.python.org/issue13502> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13502] Event.wait sometimes returns False even when no timeout has occurred
R. David Murray added the comment: Changing the title and component to reflect Antoine's new understanding :) -- components: +Library (Lib) -Documentation title: Documentation for Event.wait return value is either wrong or incomplete -> Event.wait sometimes returns False even when no timeout has occurred ___ Python tracker <http://bugs.python.org/issue13502> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1685453] email package should work better with unicode
R. David Murray added the comment: That particular problem will get fixed in the next version of the email package (hopefully in Python3.3), but that isn't ready yet. -- ___ Python tracker <http://bugs.python.org/issue1685453> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13538] Docstring of str() and/or behavior
R. David Murray added the comment: I agree with you that this is inconsistent. However, having str raise an error is pretty much a non-starter as a suggestion. str always falls back to the repr; in general str(obj) should always return some value, otherwise the assumptions of a *lot* of Python code would be broken. Personally I'm not at all sure why str takes encoding and errors arguments (I never use them). I'd rather there be only one way to do that, decode. In other words, why do we have special case support for byte strings in the str conversion function? But I don't think that can be changed either, so I think we are stuck with documenting the existing situation better. Do you want to propose a doc patch? -- assignee: -> docs@python components: +Documentation -Interpreter Core nosy: +docs@python, r.david.murray versions: +Python 3.3 ___ Python tracker <http://bugs.python.org/issue13538> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13538] Docstring of str() and/or behavior
R. David Murray added the comment: A diff would be great. We try to use warnings sparingly, and I don't think this is a case that warrants it. Possibly a .. note is worthwhile, perhaps with an example for the bytes case, but even that may be too much. I also wouldn't use the wording "is totally different from what you would expect", since by now I do expect it :). How about something like "the result will not be the decoded version of the bytes, but instead will be the repr of the object", with a cross link to repr. -- ___ Python tracker <http://bugs.python.org/issue13538> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13543] shlex with string ending in space gives "ValueError: No closing quotation"
R. David Murray added the comment:
Why do you consider this to be a bug? You set posix=False and
whitespace_split=True, so it seems to me that according to the documented rules
the " inside the word ("a is as documented not recognized as a quote character.
If you use either posix=True or whitespace_split=False the string parses
without error. (Since I have no idea what standard non-posix mode is based on,
I have no idea whether or not this is in fact correct behavior, though.)
--
nosy: +r.david.murray
___
Python tracker
<http://bugs.python.org/issue13543>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13502] Documentation for Event.wait return value is either wrong or incomplete
R. David Murray added the comment: On Wed, 07 Dec 2011 18:45:27 +, wrote: > ___ > diff --git a/Doc/library/threading.rst b/Doc/library/threading.rst > --- a/Doc/library/threading.rst > +++ b/Doc/library/threading.rst > @@ -804,8 +804,9 @@ >floating point number specifying a timeout for the operation in seconds >(or fractions thereof). > > - This method returns the internal flag on exit, so it will always return > - ``True`` except if a timeout is given and the operation times out. > + This method returns true if and only if the internal flag has been set > to > + true by another thread, so it will always return ``True`` except if a > + timeout is given and the operation times out. This seems to imply that if the current thread previously set the event, the wait will return False, which is contradicted by the 'so' statement (which appears to be correct). --David -- ___ Python tracker <http://bugs.python.org/issue13502> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1757072] Zipfile robustness
R. David Murray added the comment: I'm pretty sure that what you are reporting has been fixed by the 'garbage' fix I mentioned (which might better be called the 'more flexible handling of comments' patch). Though not in 2.5 (or 2.6) since they are no longer in maintenance. If you could confirm this by testing against 2.7 or 3.2, that would be great. -- ___ Python tracker <http://bugs.python.org/issue1757072> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13502] Documentation for Event.wait return value is either wrong or incomplete
R. David Murray added the comment: "set to True, either before the wait call or after the wait starts" -- ___ Python tracker <http://bugs.python.org/issue13502> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13543] shlex with string ending in space gives "ValueError: No closing quotation"
R. David Murray added the comment: And just for your information, as far as I know *no one* knows what standard (or model) non-posix mode shlex is based on. -- ___ Python tracker <http://bugs.python.org/issue13543> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1757072] Zipfile robustness
R. David Murray added the comment: Here's the patch: http://hg.python.org/cpython/rev/cc3255a707c7/ I thought I remembered getting it in to 2.7.2, but my memory is evidently wrong. It has been applied, but is not yet in the released version of 2.7. -- ___ Python tracker <http://bugs.python.org/issue1757072> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13502] Documentation for Event.wait return value is either wrong or incomplete
R. David Murray added the comment: LGTM. -- ___ Python tracker <http://bugs.python.org/issue13502> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13580] Pre-linkage of CPython >=2.6 binary on Linux too fat (libssl, libcrypto)
R. David Murray added the comment: So isn't this saying that this is a problem with the distribution packaging and not with CPython itself? -- nosy: +barry, r.david.murray ___ Python tracker <http://bugs.python.org/issue13580> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11867] Make test_mailbox deterministic
R. David Murray added the comment: Probably because I'm a threading/multiprocessing neophyte :) (Though I just learned a bunch about programming with threads recently...) -- ___ Python tracker <http://bugs.python.org/issue11867> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13643] 'ascii' is a bad filesystem default encoding
R. David Murray added the comment: I'm not sure why having a locale set to C or something invalid should be considered a Python bug. You have to handle un-decodable filenames no matter what you do, since things aren't always encoded in utf-8 on non-OSX unix even when that is the system locale. It's just something you have to live with. -- nosy: +r.david.murray ___ Python tracker <http://bugs.python.org/issue13643> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13643] 'ascii' is a bad filesystem default encoding
R. David Murray added the comment: > But currently everything handling filenames as unicode on > nix needs to worry about surrogates (that can't be encoded > as ascii) already, or it will still be passing values that > can't be interpreted by other processes as you highlighed > earlier. Making utf-8 names come out correctly rather than > as surrogates doesn't seem like it increases the burden. And that is *exactly* the problem. You can't assume that those other programs are expecting utf-8 on unix. The only thing you have to go by is the locale. So that's what we use. And as Haypo pointed out, unless you manipulate it file system stuff gets turned back into the same bytes when it exits Python, so pre-existing stuff should work fine. Now, if posix (or a given unix platform, like OS X did) would say "utf-8 is the standard filesystem and program interchange encoding", we could change Python. Short of that, it is our experience that using anything other than locale leads to more problems than using locale does. -- ___ Python tracker <http://bugs.python.org/issue13643> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13643] 'ascii' is a bad filesystem default encoding
R. David Murray added the comment: > _My_ locale is set properly. The problem is all the other > people in the world who do not have their locale set to match > their files on disk; telling them each to fix it is tedious. > But perhaps the OS is the best place to address that, when the > incorrect locale is just accidental not unavoidable. I fixed my locale back before my OS fully supported doing so. It was painful, but it was *so* worth it. There were many tools that just worked better after I did that, and several tools that I had to convince to use utf-8 through non-standard means. So I think Python is doing the right thing by using the locale (the Standard Way), and that getting the OS vendors and/or the users to fix their locale settings is indeed the right place to fix this. -- ___ Python tracker <http://bugs.python.org/issue13643> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8828] Atomic function to rename a file
R. David Murray added the comment: What is the motivation for providing a new function? -- ___ Python tracker <http://bugs.python.org/issue8828> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8828] Atomic function to rename a file
R. David Murray added the comment: Ah, I see, people may be depending on rename on Windows not overwriting. I suppose a new function (and eventually deprecating the old?) would be the most straightforward way forward, though I dislike the necessity :) An alternative might be a flag on rename: overwrite=['always', 'os_default'], with a warning and a switch of the default in a subsequent release. That's ugly too, of course. The existing per-platform variation in behavior of rename gives us a mess to deal with. -- ___ Python tracker <http://bugs.python.org/issue8828> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8828] Atomic function to rename a file
R. David Murray added the comment: I'm good with None/True, but that would imply that for posix rename we'll need to implement the overwrite=False option...which would be a nice thing (the shell mv command has -i for that). I think a warning would be good, because a unix programmer will assume rename will work the same on windows as it does on posix, and vice versa for a windows programmer. I suppose the fact that we haven't gotten many (any?) complaints about it means it isn't that common a problem, though, so I don't feel strongly about it. -- ___ Python tracker <http://bugs.python.org/issue8828> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8828] Atomic function to rename a file
R. David Murray added the comment: Ah, you are right about the race of course. So yes, I agree with your proposal. It's a weird API, but probably the best we can do. -- ___ Python tracker <http://bugs.python.org/issue8828> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8828] Atomic function to rename a file
R. David Murray added the comment: So maybe my warning idea isn't such a bad idea :) As a unix programmer, I was very surprised to read in this thread that Windows doesn't overwrite the file on rename. As a unix programmer, I don't check for errors on a rename, because I expect it to just work. I'd like the windows rename call to stop throwing errors if the file exists, it breaks my programs if they run on windows. (Actually, very few of my programs ever get run on Windows, but you get the idea.) Thus, the only possible course is to maintain backward compatibility, and allow the programmers who care to specify the desired behavior. Since one of the important aspects of 'rename' in unix programmers' minds is that it is atomic, a race condition is not acceptable, therefore overwrite=False is not an acceptable option for os.rename. -- ___ Python tracker <http://bugs.python.org/issue8828> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13693] email.Header.Header incorrect/non-smart on international charset address fields
R. David Murray added the comment:
Actually, no, the local part cannot be in anything other than ascii (see RFC
5335, which desires to address this problem among others). Also, an encoded
word cannot occur inside quotation marks. If you correct those two bugs, you
can generate an RFC-valid address using Header.append.
There is a project underway to make all of this header parsing and formatting
stuff work better: see the http://pypi.python.org/pypi/email.
By the way, this is easier already in python 3.2. There you can do:
>>> formataddr(('Nameß', 'weofij@fjeio'))
'=?utf-8?b?TmFtZcOf?= '
--
nosy: +r.david.murray
resolution: -> invalid
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue13693>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10839] email module should not allow some header field repetitions
R. David Murray added the comment: Regardless of what anybody thinks about the design, it is what it is and can't be changed for backward compatibility reasons. The best we can do is reject creating duplicate headers for headers that may only appear once. That feature has already been coded in the new version of the email package (see http://pypi.python.org/pypi/email), but has not yet been committed to the trunk, which is why this issue is still open. -- ___ Python tracker <http://bugs.python.org/issue10839> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1467619] Header.decode_header eats up spaces
R. David Murray added the comment: Antoine, I marked this for Python 3.3 only because there is no good way to fix it in 2.7/3.2. (If someone comes up with a way I'll be happy to review it, though!) -- versions: -Python 2.7, Python 3.2 ___ Python tracker <http://bugs.python.org/issue1467619> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1079] decode_header does not follow RFC 2047
R. David Murray added the comment: The RFC isn't at all vague about encoded words not separated by white space. That isn't allowed by the BNF. As you say, though, they occur in the wild and should be parsed correctly. In your other point I think you mean "immediately followed by a )", right? Yes, that is allowed and no, we don't currently parse that correctly. Adding the RFC tests would be great (patches gladly accepted). Fixes for ones we fail would be great, too, but at the very least we can mark them as expected failures. I don't usually like adding tests that we expect to fail, but in the case of externally defined tests such as the RFC examples I think it is worthwhile, so that we can check in a complete test set. -- ___ Python tracker <http://bugs.python.org/issue1079> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13698] Mailbox module should support other mbox formats in addition to mboxo
R. David Murray added the comment: Well, supporting the other variants would be good (I'll review any proposed patches), but I think the default will have to stay mboxo for backward compatibility reasons (unless the consensus is to go through the warning/deprecation cycle to change it). As a new feature, this could only go into 3.3 or later. -- nosy: +r.david.murray stage: -> needs patch title: Mailbox module should not use mboxo format -> Mailbox module should support other mbox formats in addition to mboxo type: behavior -> enhancement versions: -Python 2.7 ___ Python tracker <http://bugs.python.org/issue13698> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13700] imaplib.IMAP4.authenticate authobject fails with PLAIN mechanism
R. David Murray added the comment: The first argument to authenticate must be bytes. This is not well documented. It might also be a bug, since I'm not sure anyone has done a thorough audit of what should be bytes and what should be string in imaplib. 3.1 no longer gets bug fixes, so I'm removing it from versions. Likewise I remove 3.4 since that applies only to changes that will *not* be put in 3.3 for some reason. -- assignee: -> docs@python components: +Documentation nosy: +docs@python, r.david.murray versions: -Python 3.1, Python 3.4 ___ Python tracker <http://bugs.python.org/issue13700> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13700] imaplib.IMAP4.authenticate authobject fails with PLAIN mechanism
R. David Murray added the comment: Gah, I was looking at the wrong source code when I wrote that. A string first argument is indeed valid. I'm not sure where the problem is coming from since the internal CRAM_MD5 returns a string and that seems to work... -- ___ Python tracker <http://bugs.python.org/issue13700> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13700] imaplib.IMAP4.authenticate authobject fails with PLAIN mechanism
R. David Murray added the comment: Bytes definitely. We hashed that out a while ago. My point is that CRAM_MD5 login calls authenticate, and its authenticator returns a string, just like your example does. So it ought to be going through the same code path. I haven't followed the logic in detail, though, so there must be some difference...I'm pretty sure the MD5 login has a test now (but not 100% sure...) -- ___ Python tracker <http://bugs.python.org/issue13700> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1079] decode_header does not follow RFC 2047
R. David Murray added the comment: Well, a caution that tweaking the regex can have unexpected consequences as past issues have proven (but by all means go for it), and a note that the parsing strategy is going to change completely in email6 (see http://pypi.python.org/email and http://hg.python.org/features/email6). I think your tests should pass on that branch; I'll be interested to try it when I get some time. (Note: I'm removing 3.1 from versions since it doesn't get bug fixes any more.) Also, I'm not sure the (non-essential) change to consolidate like-charset encoded words is appropriate for a bug fix. It's hard to see how it would break anything, but why take the risk if it isn't needed to fix the bug. -- versions: -Python 3.1 ___ Python tracker <http://bugs.python.org/issue1079> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1079] decode_header does not follow RFC 2047
R. David Murray added the comment: Gah, that's what I get for not reading carefully (or looking at the patch first). Your test change is fine, of course. -- ___ Python tracker <http://bugs.python.org/issue1079> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13700] imaplib.IMAP4.authenticate authobject fails with PLAIN mechanism
R. David Murray added the comment: Would you be interested in providing a patch that includes tests? I think Antoine set up a test framework for testing the login as part of issue 4471. -- ___ Python tracker <http://bugs.python.org/issue13700> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13711] html.parser.HTMLParser doesn't parse tags in comments in scripts correctly
R. David Murray added the comment: The content of a script tag is CDATA. Why would you expect it to be parsed? -- nosy: +ezio.melotti, r.david.murray ___ Python tracker <http://bugs.python.org/issue13711> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13711] html.parser.HTMLParser doesn't parse tags in comments in scripts correctly
R. David Murray added the comment: I believe this was fixed recently as part of issue 670664. Ezio will know for sure. -- ___ Python tracker <http://bugs.python.org/issue13711> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12148] Clarify "or-ing together" doctest option flags
R. David Murray added the comment: I think adding the word 'bitwise' in front of "or'ed" and linking it to that section would be sufficient. -- nosy: +r.david.murray versions: +Python 3.2, Python 3.3 ___ Python tracker <http://bugs.python.org/issue12148> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8898] The email package should defer to the codecs module for all aliases
R. David Murray added the comment: euc_jp and euc_kr seem to be backward (that is, codecs translates them to the _ version, instead of translating the _ version to the - version). I worry that there might be other deviations from the standard email names. I would suggest we pull the list of preferred MIME names from the IANA charset registry and make a test out of them in the email package. If changing the name returned by codecs is determined to not be acceptable, then those entries will need to remain in the charset module ALIASES table and the codecs-check logic adjusted accordingly. Unfortunately the IANA registry does not list MIME names for all of the charsets in common use, and the canonical names are not always the ones commonly used in email. Hopefully the codecs registry is using the most common name for those, and hopefully if there are differences it won't break any user code, since any reasonable email code should be coping with the aliases in any case. Ezio, if you want to steal this one from me, that's fine by me. -- ___ Python tracker <http://bugs.python.org/issue8898> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8898] The email package should defer to the codecs module for all aliases
R. David Murray added the comment: Hmm. Must have misread. Looks like all the common charsets do have MIME entries in the IANA table. -- ___ Python tracker <http://bugs.python.org/issue8898> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8898] The email package should defer to the codecs module for all aliases
R. David Murray added the comment: On second thought the resolution order ought to be swapped anyway: if the user has added an ALIAS, they are going to want that used, not the one from codecs. -- ___ Python tracker <http://bugs.python.org/issue8898> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12147] smtplib.send_message does not implement corectly rfc 2822
R. David Murray added the comment: Thanks for the patch. Adding support for this is a good idea. There could be a question about whether this constitutes a bug fix or a feature; I'll canvass some other devs and see if we have a consensus on it. It may take me a bit to find time to do a detailed review, but in broad outline the patch looks sensible and has all the requisite parts (thanks!). -- nosy: +r.david.murray stage: -> patch review ___ Python tracker <http://bugs.python.org/issue12147> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12147] smtplib.send_message does not implement corectly rfc 2822
Changes by R. David Murray : -- assignee: -> r.david.murray ___ Python tracker <http://bugs.python.org/issue12147> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12152] Parser/asdl_c.py relies on mercurial repository revision
R. David Murray added the comment: asdl_c.py should not be run during a non-checkout build, since the files it builds should already have been (re)built and checked in by the time a release is rolled. IIUC The release building script is supposed to ensure the timestamps of the files are such that it won't be called. What source are you doing the non-checkout build from? -- nosy: +r.david.murray ___ Python tracker <http://bugs.python.org/issue12152> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12151] test_logging fails sometimes
R. David Murray added the comment: Here's another (unrelated?) failure: http://www.python.org/dev/buildbot/all/builders/x86%20Gentoo%203.x/builds/173/steps/test/logs/stdio [ 43/355] test_logging Traceback (most recent call last): File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/socketserver.py", line 582, in process_request_thread self.finish_request(request, client_address) File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/socketserver.py", line 323, in finish_request self.RequestHandlerClass(request, client_address, self) File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/socketserver.py", line 641, in __init__ self.finish() File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/socketserver.py", line 713, in finish self.socket.sendto(self.wfile.getvalue(), self.client_address) socket.error: [Errno 9] Bad file descriptor test test_logging failed -- multiple errors occurred; run in verbose mode for details -- nosy: +r.david.murray ___ Python tracker <http://bugs.python.org/issue12151> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8898] The email package should defer to the codecs module for all aliases
R. David Murray added the comment: Well, it turns out that back when I opened this issue I misunderstood what the ALIASES table was used for. it *is* used before doing a codecs lookup, but it is also used to convert whatever charset name the programmer specifies into the standard MIME name for the codec when generating emails. Clearly the email module needs to base its transformation on the IANA table. I think the ideal would be to have a program that pulls the IANA table and generates the ALIASES table. On the other hand, codecs should already have all of those aliases (this theoretical program could be used to ensure that), so another alternative is to use codecs to look up the "python canonical" name for the charset, and have the email ALIASES table just map the ones where that isn't the preferred MIME name into the MIME name. -- ___ Python tracker <http://bugs.python.org/issue8898> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12152] Parser/asdl_c.py relies on mercurial repository revision
R. David Murray added the comment: And like Benjamin said, it should be enough to touch those two files. You don't have to actually build a release tarball. -- ___ Python tracker <http://bugs.python.org/issue12152> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12074] regrtest: display the current number of failures
R. David Murray added the comment: How about instead changing [1/4], [2/4] etc to be [1/4/0], [2/4/0], etc? -- nosy: +r.david.murray ___ Python tracker <http://bugs.python.org/issue12074> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12162] Documentation about re \number
R. David Murray added the comment: Read the description of strings and raw strings at the top of the re documentation for the answer to your question about \\. It would probably be better if the example regular expression was written r'(.+) \1' instead of as a bare expression as it is now. -- nosy: +r.david.murray ___ Python tracker <http://bugs.python.org/issue12162> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12163] str.count
R. David Murray added the comment: For background on a similar issue, see #11828, especially msg133532. -- nosy: +r.david.murray ___ Python tracker <http://bugs.python.org/issue12163> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11512] adding test suite for cgitb
Changes by R. David Murray : -- nosy: +r.david.murray ___ Python tracker <http://bugs.python.org/issue11512> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12168] SysLogHandler incorrectly appents \000 to messages
R. David Murray added the comment: While I agree that it should ideally be possible to actually control this behavior as indicated by the comment, any syslog handler that does not sanitize the messages it receives is broken. -- nosy: +r.david.murray ___ Python tracker <http://bugs.python.org/issue12168> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12168] SysLogHandler incorrectly appents \000 to messages
R. David Murray added the comment: s/handler/receiver/ -- ___ Python tracker <http://bugs.python.org/issue12168> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12057] HZ codec has no test
R. David Murray added the comment: Looks good to me. And I meant documenting the process for adding a directory. -- ___ Python tracker <http://bugs.python.org/issue12057> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
