[issue33008] urllib.request.parse_http_list incorrectly strips backslashes
New submission from W. Trevor King <wk...@tremily.us>: Python currently strips backslashes from inside quoted strings: $ echo 'a="b\"c",d=e' | python3 -c 'from sys import stdin; from urllib.request import parse_http_list; print(parse_http_list(stdin.read()))' ['a="b"c"', 'd=e'] It should be printing: ['a="b\"c"', 'd=e'] The bug is this continue [1], which should be removed. This was not a problem with the original implementation [2]. It was introduced in [3] as a fix for #735248 with explicit tests asserting the broken behavior [3]. Stripping backslashes from the insides of quoted strings is not appropriate, because it breaks explicit unquoting with email.utils.unquote [4]: import email.utils import urllib.request list = r'"b\\"c"' entry = urllib.request.parse_http_list(list)[0] entry # '"b\\"c"', should be '"b"c"' email.utils.unquote(entry) # 'b"c', should be 'b\\"c' I'm happy to file patches against the various branches if that would help, but as a one-line removal (plus adjusting the tests), it might be easier if a maintainer files the patches. [1]: https://github.com/python/cpython/blob/v3.7.0b2/Lib/urllib/request.py#L1420 [2]: https://github.com/python/cpython/commit/6d7e47b8ea1b8cf82927dacc364689b8eeb8708b#diff-33f7983ed1a69d290366fe426880581cR777 [3]: https://github.com/python/cpython/commit/e1b13d20199f79ffd3407bbb14cc09b1b8fd70d2#diff-230a8abfedeaa9ae447490df08172b15R52 [4]: https://docs.python.org/3.5/library/email.util.html#email.utils.unquote -- components: Library (Lib) messages: 313308 nosy: labrat priority: normal severity: normal status: open title: urllib.request.parse_http_list incorrectly strips backslashes versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33008> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33003] urllib: Document parse_http_list
New submission from W. Trevor King <wk...@tremily.us>: Python has had a parse_http_list helper since urllib2 landed in 6d7e47b8ea (EXPERIMENTAL, 2000-01-20). With Python3 it was moved into urllib.request, and the implementation hasn't changed since (at least as of 4c19b9573, 2018-03-05). External projects depend on the currently undocumented function [1,2], so it would be nice to have some user-facing documentation for it. If that sounds appealing, I'm happy to work up a pull request. [1]: https://github.com/requests/requests/blob/v2.18.4/requests/compat.py#L42 [2]: https://github.com/requests/requests/blob/v2.18.4/requests/compat.py#L58 -- assignee: docs@python components: Documentation messages: 313294 nosy: docs@python, labrat priority: normal severity: normal status: open title: urllib: Document parse_http_list type: enhancement versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33003> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26080] "abandonned" -> "abandoned" in PEP 510's https://hg.python.org/peps/rev/b463c740990c
New submission from W. Trevor King: In the recently-landed [1], There was also the Unladen Swallow project, but it was abandonned in 2011. Should have used “abandoned” instead of “abandonned”. [1]: https://hg.python.org/peps/rev/b463c740990c changeset: 6155:b463c740990c user: Victor Stinner <victor.stinner< at >gmail.com> date: Sun Jan 10 14:58:17 2016 +0100 summary: PEP 510: rationale for static optimize vs JIT compiler http://permalink.gmane.org/gmane.comp.python.cvs/114604 -- assignee: docs@python components: Documentation messages: 257974 nosy: docs@python, labrat priority: normal severity: normal status: open title: "abandonned" -> "abandoned" in PEP 510's https://hg.python.org/peps/rev/b463c740990c type: enhancement ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26080> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: [python] Re: GitHub's ³pull request² is proprietary lock-in
On Sun, Jan 03, 2016 at 04:31:55AM -0500, Random832 wrote: > But there is no command to create a "pull request", nowhere for such > a thing to exist in the repository, etc. There is this [1]. > Also if someone puts through a github pull request and then their > patch is accepted, my understanding is that the pull request has to > be "closed" through a github online interface and merely merging the > patch through the git command line will not update the status on the > pull request. This is incorrect. GitHub will automatically mark PRs as “Merged” when their tip commit lands in the target branch. I haven't looked up docs for when this landed (if it was even announced), but next to GitHub's “Merge pull request” button there's currently an “or view command line instructions” link which sketches out some command-line Git to accomplish the same thing. But I agree that it's nice to keep the discussion around pull requests somewhere portable. Cheers, Trevor [1]: http://git-scm.com/docs/git-request-pull -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature -- https://mail.python.org/mailman/listinfo/python-list
[issue25852] smtplib's SMTP.connect() should store the server name in ._host for .starttls()
New submission from W. Trevor King: With the current tip, starttls uses ._host when calling wrap_socket [1], but ._host is only setup in SMTP.__init__ [2]. Before #22921 [3] starttls would ignore ._host when SNI wasn't available locally. But as far as I can tell, starttls has never used _host when connection happens via an explicit connect() call. This leads to errors like [4]: >>> smtp = smtplib.SMTP() >>> smtp.connect(host="smtp.gmail.com", port=587) >>> smtp.ehlo() >>> smtp.starttls() File "smtp_test.py", line 10, in smtp.starttls() File "/usr/lib/python3.4/smtplib.py", line 676, in starttls server_hostname=server_hostname) File "/usr/lib/python3.4/ssl.py", line 344, in wrap_socket _context=self) File "/usr/lib/python3.4/ssl.py", line 540, in __init__ self.do_handshake() File "/usr/lib/python3.4/ssl.py", line 767, in do_handshake self._sslobj.do_handshake() ssl.SSLError: [SSL: TLSV1_ALERT_DECODE_ERROR] tlsv1 alert decode error (_ssl.c:598) I think a better approach would be to move the ._host set into .connect (patch attached). It would still happen in SMTP(host=…) because [5], but would also allow starttls when users use SMTP() and then call connect(host=…) explicitly. I've formatted the patch with Git, but its simple enough that it should be easy to apply in Mercurial. Still, let me know if I can make applying it easier by rerolling the patch. [1]: https://hg.python.org/cpython/file/323c10701e5d/Lib/smtplib.py#l766 [2]: https://hg.python.org/cpython/file/323c10701e5d/Lib/smtplib.py#l244 [3]: http://bugs.python.org/issue22921 [4]: http://stackoverflow.com/questions/23616803/smtplib-smtp-starttls-fails-with-tlsv1-alert-decode-error [5]: https://hg.python.org/cpython/file/323c10701e5d/Lib/smtplib.py#l251 -- components: Library (Lib) files: 0001-smtplib-Set-SMTP._host-in-.connect.patch keywords: patch messages: 256299 nosy: labrat priority: normal severity: normal status: open title: smtplib's SMTP.connect() should store the server name in ._host for .starttls() type: behavior versions: Python 3.3, Python 3.4, Python 3.5 Added file: http://bugs.python.org/file41291/0001-smtplib-Set-SMTP._host-in-.connect.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25852> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22684] message.as_bytes() produces recursion depth exceeded
W. Trevor King added the comment:
Here's an example from the notmuch list. You can trigger the exception in
Python 3.4 with:
import email.policy
import mailbox
mbox = mailbox.mbox('msg.mbox', factory=None, create=False)
message = mbox[0]
message.as_bytes(policy=email.policy.SMTP)
Traceback (most recent call last):
File stdin, line 1, in module
File /home/wking/src/notmuch/ssoma_mda.py, line 319, in deliver
message_bytes = message.as_bytes(policy=_email_policy.SMTP)
File /usr/lib64/python3.4/email/message.py, line 179, in as_bytes
g.flatten(self, unixfrom=unixfrom)
File /usr/lib64/python3.4/email/generator.py, line 112, in flatten
self._write(msg)
File /usr/lib64/python3.4/email/generator.py, line 192, in _write
self._write_headers(msg)
…
File /usr/lib64/python3.4/email/_header_value_parser.py, line 195, in
genexpr
return ''.join(str(x) for x in self)
RuntimeError: maximum recursion depth exceeded while getting the str of an
object
Interestingly, it serializes fine using the default policy:
message.as_bytes()
b'Return-Path: …-\n'
--
nosy: +labrat
Added file: http://bugs.python.org/file37143/msg.mbox
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22684
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22684] message.as_bytes() produces recursion depth exceeded
W. Trevor King added the comment:
The troublesome header formatting is:
import email.policy
email.policy.SMTP.fold_binary('Cc',
'notmuch\n\tpublic-public-notmuch-gxuj+Tv9EO5zyzON3hdc1g-wOFGN7rlS/M9smdsby/k...@plane.gmane.org,\n\tpublic-notmuch-gxuj+tv9eo5zyzon3hd...@plane.gmane.org,\n\tRainer
M Krug public-r.m.krug-re5jqeeqqe8avxtiumw...@plane.gmane.org,\n\tJeremy
Nickurak\n\tpublic-public-not-much-kexSNQTsIoD754YsiR0rpA-wOFGN7rlS/M9smdsby/k...@plane.gmane.org')
Traceback (most recent call last):
…
RuntimeError: maximum recursion depth exceeded while getting the str of an
object
Trimming that down a bit, a minimal trigger seems to be:
email.policy.SMTP.fold_binary('Cc',
'a\n\ta,\n\ta')
Traceback…
Where removing much of anything gives a working fold.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22684
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22684] message.as_bytes() produces recursion depth exceeded
W. Trevor King added the comment: In email._header_value_parser._Folded.append_if_fits, if I shift: if token.has_fws: ws = token.pop_leading_fws() if ws is not None: self.stickyspace += str(ws) stickyspace_len += len(ws) token._fold(self) return True to: if token.has_fws: ws = token.pop_leading_fws() if ws is not None: self.stickyspace += str(ws) stickyspace_len += len(ws) token._fold(self) return True I can avoid the recursion. The problem seems to be that the a …aaa token/part contains folding white space, but doesn't *start* with folding whitespace. Maybe the folding should try to split on existing FWS, instead of just trying to pop leading FWS? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22684 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: parametized unittest
On Sat, Jan 11, 2014 at 08:00:05PM -0800, CraftyTech wrote: I'm finding it hard to use unittest in a for loop. Perhaps something like: for val in range(25): self.assertEqual(val,5,not equal) The loop will break after the first failure. Anyone have a good approach for this? please advise. If Python 3.4 is an option, you can stick to the standard library and use subtests [1]. Cheers, Trevor [1]: http://docs.python.org/3.4/library/unittest.html#distinguishing-test-iterations-using-subtests -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature -- https://mail.python.org/mailman/listinfo/python-list
[issue19226] distutils/command/upload.py show response gives: TypeError: sequence item 1: expected str instance, bytes found
New submission from W. Trevor King:
Avoid:
Traceback (most recent call last):
File setup.py, line 61, in module
'html2text (=3.0.1)',
File /.../python3.2/distutils/core.py, line 148, in setup
dist.run_commands()
File /.../python3.2/distutils/dist.py, line 917, in run_commands
self.run_command(cmd)
File /.../python3.2/distutils/dist.py, line 936, in run_command
cmd_obj.run()
File /.../python3.2/distutils/command/upload.py, line 66, in run
self.upload_file(command, pyversion, filename)
File /.../python3.2/distutils/command/upload.py, line 201, in
upload_file
msg = '\n'.join(('-' * 75, r.read(), '-' * 75))
TypeError: sequence item 1: expected str instance, bytes found
by converting the bytes returned by HTTPResponse.read [1] to a string
before joinging it with other strings. HTTPResponse.headers supports
the Message interface [2], so we can use get_param to extract the
charset [3], falling back on ISO-8859-1 [4].
[1]:
http://docs.python.org/3/library/http.client.html#http.client.HTTPResponse.read
[2]: http://docs.python.org/3/library/http.client.html#httpmessage-objects
[3]:
http://docs.python.org/3/library/email.message.html#email.message.Message.get_param
[4]: http://tools.ietf.org/html/rfc2616#section-3.7.1
--
assignee: eric.araujo
components: Distutils
files: show-response-string.patch
keywords: patch
messages: 199489
nosy: eric.araujo, labrat, tarek
priority: normal
severity: normal
status: open
title: distutils/command/upload.py show response gives: TypeError: sequence
item 1: expected str instance, bytes found
versions: Python 3.2, Python 3.3, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file32045/show-response-string.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19226
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19226] distutils/command/upload.py show response gives: TypeError: sequence item 1: expected str instance, bytes found
W. Trevor King added the comment: On Fri, Oct 11, 2013 at 05:21:15PM +, Ned Deily wrote: This problem has been reported previously as Issue17354, a duplicate of Issue12853 which is still open at the moment. Ah, I searched for a fwe possible subject lines, but didn't hit those :p. I thought that if it wasn't fixed in the master branch it must not have an associated issue… I like my patch better than Issue17354's, because PyPI servers may not always use UTF-8. I'll ping Issue12853 about the patches, because either one would fix Issue12853, and it's currently needs patch. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19226 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12853] global name 'r' is not defined in upload.py
W. Trevor King added the comment: I just posted a patch fixing this in the current master branch [1]. Ned Deily pointed out that my Issue19226 duplicated an earlier Issue17354, which also has a patch fixing this problem. Merging either one of these patches should close this issue. I like my patch's generic charset handling better, but for PyPI uploads either one would work fine. I've looked through the Mercurial logs, but it looks like this r *has* been around since 34794 (Implement the Distutils 'upload' subcommand (upload package to PyPI), 2005-03-21), so I don't know where the global name 'r' is not defined message came from. -- nosy: +labrat ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12853 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: [python] email 8bit encoding
On Sun, Jul 28, 2013 at 04:41:27PM -0700, ru...@yahoo.com wrote: How, using Python-3.3's email module, do I flatten (I think that's the right term) a Message object to get utf-8 encoded body with the headers: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit when the message payload was set to a python (unicode) string? I asked about this a while back [1], but never got a response. My current best-guess is here [2]. My fallback flattening works for everything except the 8-bit encoded messages using the UTF-16 charset, but it's pretty ugly. Let me know if you figure out something cleaner :). Cheers, Trevor [1]: http://thread.gmane.org/gmane.comp.python.general/725425 [2]: https://github.com/wking/rss2email/blob/master/rss2email/email.py#L226 -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature -- http://mail.python.org/mailman/listinfo/python-list
Mailman forwarding (was: Don't feed the troll...)
On Sat, Jun 15, 2013 at 01:07:29PM -0400, D'Arcy J.M. Cain wrote: On Sat, 15 Jun 2013 18:41:41 +0200 Chris “Kwpolska” Warrick wrote: On Sat, Jun 15, 2013 at 5:40 PM, Steven D'Aprano wrote: In the name of all that's good and decent in the world, why on earth would you do that when replying to a mailing list??? They're already getting a reply. Sending them TWO identical replies is just rude. Mailman is intelligent enough not to send a second copy in that case. This message was sent with a CC, and you got only one copy. Actually, no. Mailman is not your MTA. It only gets the email sent to the mailing list. Your MTA sends the other one directly so Steve is correct. He gets two copies. If his client doesn't suppress the duplicate then he will be presented with both. Mailman can (optionally) assume that addresses listed in To, CC, … fields received an out-of-band copies, and not mail them an additional copy [1]. Cheers, Trevor [1]: http://www.gnu.org/software/mailman/mailman-member/node21.html -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature -- http://mail.python.org/mailman/listinfo/python-list
CC etiquette for mailing lists (was: Don't feed the troll...)
On Sun, Jun 16, 2013 at 12:51:04AM +, Steven D'Aprano wrote: On Sun, 16 Jun 2013 09:09:37 +1000, Chris Angelico wrote: Mailman is the software that runs python-list@python.org, so this *is* applicable to everyone who reads the mailing list (including myself). The fact that there's other mailing list software isn't significant; I'm not making an argument about CCing the sender on specifically this list, I'm making a general observations about list etiquette in general. For some lists [1], the convention *is* to CC interested parties (which presumably includes the person who's message you are replying to). In the case of Mailman-hosted lists, it would seem to be more considerate to CC folks (since they can opt-out via Mailman), while folks who only follow the list via occasionally reading Gmane [2] will probably appreciate the direct ping. I'm not saying that this should be the convention for python-list@, I'm just saying that it's not immediately obvious what the conventions are for a particular list [3], and there are valid arguments going both ways. What seems more obvious (to me), is that it's polite to adjust the subject line if your response if far enough off-topic that the original subject no longer applies ;). Cheers, Trevor [1]: http://git.kernel.org/cgit/git/git.git/tree/MaintNotes?h=todo#n10 [2]: http://news.gmane.org/gmane.comp.python.general [3]: Unless you tell new subscribers what the conventions are. For example, the git@ list emails [1] to new list subscribers. -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature -- http://mail.python.org/mailman/listinfo/python-list
Flatten an email Message with a non-ASCII body using 8bit CTE
Hello list!
I'm trying to figure out how to flatten a MIMEText message to bytes
using an 8bit Content-Transfer-Encoding in Python 3.3. Here's what
I've tried so far:
# -*- encoding: utf-8 -*-
import email.encoders
from email.charset import Charset
from email.generator import BytesGenerator
from email.mime.text import MIMEText
import sys
body = 'Ζεύς'
encoding = 'utf-8'
charset = Charset(encoding)
charset.body_encoding = email.encoders.encode_7or8bit
message = MIMEText(body, 'plain', encoding)
del message['Content-Transfer-Encoding']
message.set_payload(body, charset)
try:
BytesGenerator(sys.stdout.buffer).flatten(message)
except UnicodeEncodeError as e:
print('error with string input:')
print(e)
message = MIMEText(body, 'plain', encoding)
del message['Content-Transfer-Encoding']
message.set_payload(body.encode(encoding), charset)
try:
BytesGenerator(sys.stdout.buffer).flatten(message)
except TypeError as e:
print('error with byte input:')
print(e)
The `del m[…]; m.set_payload()` bits work around #16324 [1] and should
be orthogonal to the encoding issues. It's possible that #12553 is
trying to address this issue [2,3], but that issue's comments are a
bit vague, so I'm not sure.
The problem with the string payload is that
email.generator.BytesGenerator.write is getting the Unicode string
payload unencoded and trying to encode it as ASCII. It may be
possible to work around this by encoding the payload so that anything
that doesn't encode (using the body charset) to a 7bit value is
replaced with a surrogate escape, but I'm not sure how to do that.
The problem with the byte payload is that _has_surrogates (used in
email.generator.Generator._handle_text and
BytesGenerator._handle_text) chokes on byte input:
TypeError: can't use a string pattern on a bytes-like object
For UTF-8, you can get away with:
message.as_string().encode(message.get_charset().get_output_charset())
because the headers are encoded into 7 bits, so re-encoding them with
UTF-8 is a no-op. However, if the body charset is UTF-16-LE or any
other encoding that remaps 7bit characters, this hack breaks down.
Thoughts?
Trevor
[1]: http://bugs.python.org/issue16324
[2]: http://bugs.python.org/issue12553
[3]: http://bugs.python.org/issue12552#msg140294
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
signature.asc
Description: OpenPGP digital signature
--
http://mail.python.org/mailman/listinfo/python-list
[issue9253] argparse: optional subparsers
W. Trevor King added the comment: Since [1] it seems like subparsers *are* optional by default. At least I get “error: too few arguments” for version 70740 of Lib/argparse.py, but no error for version 70741. It looks like this may be an unintentional side effect, since I see no mention of subparsers in #10424. [1]: http://hg.python.org/cpython/rev/cab204a79e09 -- nosy: +labrat Added file: http://bugs.python.org/file28778/check.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9253 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9640] Improved doctest REPORT_*DIFFs with ELLIPSIS and/or NORMALIZE_WHITESPACE
New submission from W. Trevor King wk...@drexel.edu: I had been struggling to find the failure-causing mismatch in a doctest with lots of output. REPORT_UDIFF gave lots of false mismatches because I was also using NORMALIZE_WHITESPACE. Looking through the doctest.py source, I saw a comment suggesting a nicer diff in the similar REPORT_*DIFF and ELLIPSIS situation. So I went ahead and implemented one. I'm not super happy with the cleanliness of the implementation, but it ended up being a bit trickier than I'd initially expected. -- components: Library (Lib) messages: 114340 nosy: labrat priority: normal severity: normal status: open title: Improved doctest REPORT_*DIFFs with ELLIPSIS and/or NORMALIZE_WHITESPACE type: feature request versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9640 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9640] Improved doctest REPORT_*DIFFs with ELLIPSIS and/or NORMALIZE_WHITESPACE
W. Trevor King wk...@drexel.edu added the comment: Here's my patch, or pull from my Mercurial repository http://www.physics.drexel.edu/~wking/code/hg/hgwebdir.cgi/python/rev/6638df20c1a4 -- keywords: +patch Added file: http://bugs.python.org/file18575/doctest_diff.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9640 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5752] xml.dom.minidom does not escape CR, LF and TAB characters within attribute values
W. Trevor King wk...@drexel.edu added the comment:
And while we're at it, we should also
.replace('', 'amp;').replace('', quot;).replace('', 'lt;')
which would have to go at the beginning to avoid double-escaping the ''.
We could use xml.sax.saxutils.escape to do all the escaping rather than
chaining replaces:
data = escape(data, {'':'quot;', '\r':'#xD;', '\n':'#xA;', '\t':'#x9;'})
which also escapes '' (not strictly required for attribute values, but
shouldn't be harmful either).
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5752
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5752] xml.dom.minidom does not escape CR, LF and TAB characters within attribute values
W. Trevor King wk...@drexel.edu added the comment: As a workaround until the patch gets included, you can import this monkey patch module. -- nosy: +labrat Added file: http://bugs.python.org/file18325/minidom.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5752 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6612] 'import site' fails when called from an unlinked directory
W. Trevor King wk...@drexel.edu added the comment: I just fixed it myself ;). As I said before, not really a big deal, but it was an easy fix. I've attached a patch, or you can merge my hg branch f python-trunk at http://www.physics.drexel.edu/~wking/code/hg/hgwebdir.cgi/python/ -- keywords: +patch versions: +Python 2.6, Python 2.7 Added file: http://bugs.python.org/file18264/issue6612.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6612 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6612] 'import site' fails when called from an unlinked directory
New submission from W. Trevor King wk...@drexel.edu:
I don't imagine this comes up very often, but:
$ mkdir /tmp/a; cd /tmp/a; rmdir /tmp/a; python -c 'import site';
rmdir: removing directory, /tmp/a
'import site' failed; use -v for traceback
Traceback (most recent call last):
File string, line 1, in module
File /home/wking/lib/python/site.py, line 73, in module
__boot()
File /home/wking/lib/python/site.py, line 33, in __boot
imp.load_module('site',stream,path,descr)
File /usr/lib/python2.5/site.py, line 408, in module
main()
File /usr/lib/python2.5/site.py, line 392, in main
paths_in_sys = removeduppaths()
File /usr/lib/python2.5/site.py, line 96, in removeduppaths
dir, dircase = makepath(dir)
File /usr/lib/python2.5/site.py, line 72, in makepath
dir = os.path.abspath(os.path.join(*paths))
File /usr/lib/python2.5/posixpath.py, line 403, in abspath
path = join(os.getcwd(), path)
OSError: [Errno 2] No such file or directory
--
messages: 91129
nosy: labrat
severity: normal
status: open
title: 'import site' fails when called from an unlinked directory
versions: Python 2.5
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6612
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
