[issue31689] random.choices does not work with negative weights
David Kopec added the comment: It's not a bug, but I agree with Allen that it could use a much more clear error message. I think his proposed ValueError makes a lot more sense than just raising an IndexError as currently occurs. This will help people debug their programs who don't even realize they're accidentally using negative weights to begin with. -- nosy: +davecom versions: +Python 3.7 -Python 3.6 ___ Python tracker <https://bugs.python.org/issue31689> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24255] Replace debuglevel-related logic with logging
R. David Murray added the comment: Conrad: thanks for the effort, but using f-strings with logging is counterproductive. The idea behind logging is that the logged strings are not materialized unless something actually wants to output them. Using fstrings means you are doing all the work of formatting the string regardless of whether or not the string is actually going to get written anywhere. The original patch also retains the debug guards that minimize overhead when debugging is not turned on, which it doesn't look like your patch does. Regardless, what we need at this stage is a github PR, not a patch :) -- ___ Python tracker <https://bugs.python.org/issue24255> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24218] Also support SMTPUTF8 in smtplib's send_message method.
R. David Murray added the comment: Well, posting on a closed issue is generally not the best way :) The current behavior with regards to the SMTPUTF8 flag is correct (it only matters for *addresses*, display names can already be transmitted if they contain non-ascii using non SMTPUTF8 methods). The multiple carriage returns is a bug, and there is an open issue for it, though I'm not finding it at the moment. -- ___ Python tracker <https://bugs.python.org/issue24218> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34277] EmailPolicy not followed
R. David Murray added the comment: Well, it can't fold them and have them fit in the 78 character limit without adding whitespace that isn't in the original headers (unless there's a more subtle bug :) The email package has the possibility of having special behavior based on the name of the header, so if DKIM headers have special rules, there is the possibility of implementing those special rules. Basically, you can implement a parser that recognizes dkim headers and represents what parts can legally be folded using the resulting parse tree. So it may be possible to fix this without changing the refold_source default. It is also possible to specify that encoded words may not be used in a given header (that's a simple toggle), which may be all that is needed here. -- ___ Python tracker <https://bugs.python.org/issue34277> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34277] EmailPolicy not followed
R. David Murray added the comment: You are indeed misunderstanding. The docs say: If False, follow RFC 5322, supporting non-ASCII characters in headers by encoding them as “encoded words”. If True, follow RFC 6532 and use utf-8 encoding for headers. Messages formatted in this way may be passed to SMTP servers that support the SMTPUTF8 extension (RFC 6531). That is, when the flag is False, encoded words may be used, which is what the =?utf-8?q??= constructs are. If it is True, those are *not* used, but instead utf8 character encoding is used, which would look on your terminal like the international characters themselves, not encoded stuff. So, what you are seeing is the DKIM header getting re-encoded using encoded words in order to make it fit in the standard line length for email headers (78 characters max). The fact that that wasn't happening before was actually a bug in the folder that was fixed by the changeset you cite. You can get the behavior you want by setting the policy control 'refold_source' to 'none', or changing max_line_length to some value larger than you expect DKIM headers to be (or to None, which means don't fold). If the standard DKIM headers really are not respecting the standard default email header line length, that is a very sad thing. I think perhaps the default value of refold_source was a poor choice, and we should have gone with none. Changing that could be discussed, but since it changes behavior it may be controversial. -- ___ Python tracker <https://bugs.python.org/issue34277> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34277] EmailPolicy not followed
R. David Murray added the comment: I don't see you asserting utf8=True in your example, so I don't see what it has to do with the utf8 flag, since that is False by default. Maybe you are running up against the default value of refold_header, which is 'long'? -- ___ Python tracker <https://bugs.python.org/issue34277> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34246] Gentoo Refleaks 3.7: test_smtplib has dangling threads
R. David Murray added the comment: That's due to another bug, which will get fixed by #32814, unless you'd like to generate a PR with the this fix in it (fixing the mutable default for smtp_options). -- ___ Python tracker <https://bugs.python.org/issue34246> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34246] Gentoo Refleaks 3.7: test_smtplib has dangling threads
R. David Murray added the comment: That's not the code I thought I merged. I'll have to take a look at what actually got merged. -- ___ Python tracker <https://bugs.python.org/issue34246> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34246] Gentoo Refleaks 3.7: test_smtplib has dangling threads
R. David Murray added the comment: Ah, sorry. we just modernized test_smtplib's __main__ section, and I think we lost the thread cleanup code that used to be run around the test suite. We need to add the thread cleanup decorators. -- nosy: +r.david.murray stage: -> needs patch type: -> behavior versions: +Python 3.6, Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue34246> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32814] smtplib.send_message mishandles 8BITMIME RFC 6152
R. David Murray added the comment: OK, the #32663 test fix I mentioned in the review is merged. -- versions: -Python 3.5 ___ Python tracker <https://bugs.python.org/issue32814> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32663] SMTPUTF8SimTests are not actually being run
R. David Murray added the comment: Thanks, Chason. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue32663> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32663] SMTPUTF8SimTests are not actually being run
R. David Murray added the comment: New changeset cecbe0ade87360cd37cc1389fe33dd92f2cf52ba by R. David Murray (Miss Islington (bot)) in branch '3.6': bpo-32663 Make SMTPUTF8SimTests run (GH-5314) (#8470) https://github.com/python/cpython/commit/cecbe0ade87360cd37cc1389fe33dd92f2cf52ba -- ___ Python tracker <https://bugs.python.org/issue32663> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32663] SMTPUTF8SimTests are not actually being run
R. David Murray added the comment: New changeset 89352b08aad447d046551fa0cd374becd7941c91 by R. David Murray (Miss Islington (bot)) in branch '3.7': bpo-32663 Make SMTPUTF8SimTests run (GH-5314) (#8471) https://github.com/python/cpython/commit/89352b08aad447d046551fa0cd374becd7941c91 -- ___ Python tracker <https://bugs.python.org/issue32663> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33524] non-ascii characters in headers causes TypeError on email.policy.Policy.fold
Change by R. David Murray : -- nosy: +altvod versions: +Python 3.7, Python 3.8 -Python 3.6 ___ Python tracker <https://bugs.python.org/issue33524> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34220] Serialization of email message without header line length limit and a non-ASCII subject fails with TypeError
R. David Murray added the comment: Thanks for the report. This is a duplicate of #33524. -- resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> non-ascii characters in headers causes TypeError on email.policy.Policy.fold ___ Python tracker <https://bugs.python.org/issue34220> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32663] SMTPUTF8SimTests are not actually being run
R. David Murray added the comment: New changeset 48ed88a93bb0bbeaae9a4cfaa533e4edf13bcb51 by R. David Murray (chason) in branch 'master': bpo-32663 Make SMTPUTF8SimTests run (#5314) https://github.com/python/cpython/commit/48ed88a93bb0bbeaae9a4cfaa533e4edf13bcb51 -- nosy: +r.david.murray ___ Python tracker <https://bugs.python.org/issue32663> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34157] NamedTemporaryFile can leave temporary files behind
Change by R. David Murray : -- resolution: duplicate -> stage: resolved -> needs patch status: closed -> open ___ Python tracker <https://bugs.python.org/issue34157> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34157] NamedTemporaryFile can leave temporary files behind
R. David Murray added the comment: Nick, what Jakub is saying is that 'with' hasn't even gotten involved yet: we're still executing the NamedTemporaryFile constructor, so the object hasn't been returned for 'with' to operate on yet. In other words, NamedTemporaryFile.__init__ isn't safe against ctl-C when it calls _mkstemp, which is obvious by inspection since it isn't inside the try/except. -- nosy: +r.david.murray ___ Python tracker <https://bugs.python.org/issue34157> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34155] email.utils.parseaddr mistakenly parse an email
R. David Murray added the comment: Ah, maybe it doesn't handle it completely correctly; that decode looks different now that I look at it in detail. -- ___ Python tracker <https://bugs.python.org/issue34155> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34155] email.utils.parseaddr mistakenly parse an email
R. David Murray added the comment: Oops, I left out a step in that cut and paste. For completeness: >>> x = x[3:] -- ___ Python tracker <https://bugs.python.org/issue34155> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34155] email.utils.parseaddr mistakenly parse an email
R. David Murray added the comment: That does appear to be a bug. Note that the new email API handles it correctly: >>> x = """ ... > From: =?utf-8?Q?z...@redacted.com.cn=E3=82=86=E2=86=91=E3=82=86?= ... =?utf-8?Q?=E3=82=83=E3=82=85=E3=81=87=E3=81=BA=E3=81=BD=E3=81=BC"\=E3?= ... =?utf-8?Q?=81=A9=E3=81=A5=E3=81=A2l=E3=81=A0=E3=81=B0=E3=81=A8=E3=81?= ... =?utf-8?Q?=8FKL=E3=81=84=E3=82=8C=E3=82=8B=E3=82=86>KL=E3=82=89JF?= ... ... """ >>> from email import message_from_string >>> from email.policy import default >>> m = message_from_string(x+'\n\ntest', policy=default) >>> m['from'] '"z...@redacted.com.cnゆ↑ゆ ゃゅぇぺぽぼ\\"� ��づぢlだばと� �KLいれるゆ>KLらJF" ' >>> m['from'].addresses[0].addr_spec 'm...@redacted2.com' >>> m['from'].addresses[0].display_name 'z...@redacted.com.cnゆ↑ゆ ゃゅぇぺぽぼ"\\\udce3 \udc81\udca9づぢlだばと\udce3\udc81 \udc8fKLいれるゆ>KLらJF' I'm not particularly interested myself in fixing parseaddr to handle this case correctly, since it is the legacy API, but if someone else wants to I'll review the patch. -- versions: +Python 3.7, Python 3.8 -Python 3.6 ___ Python tracker <https://bugs.python.org/issue34155> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34138] imaplib RFC 6855 issue
R. David Murray added the comment: Maybe we'll be luck and Maciej will still be interested :) -- nosy: +maciej.szulik ___ Python tracker <https://bugs.python.org/issue34138> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34138] imaplib RFC 6855 issue
R. David Murray added the comment: Would you care to propose a patch? That's likely the only way this is going to get fixed, unfortunately, as currently we have no one on the core team interested in imaplib. Which means it is also going to be hard to come up with someone to do the review (I'm the most likely candidate and have a distinct lack of time currently), but we'll deal with that when we get that far. -- title: RFC 6855 issue -> imaplib RFC 6855 issue ___ Python tracker <https://bugs.python.org/issue34138> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34088] [EASY] sndhdr.what() throws exceptions on unknown files
david awad added the comment: Hey, I saw the issue and spent some time piecing together a PR for it. I've never contributed to Python before but this seemed like a good place to start! I posted these questions on the PR but I'll echo them here as well. - Should we only handle the specific exceptions that are created in these two examples? or is there a cleaner, more pythonic way to handle it? - It doesn't appear that test_sndhdr.py does any testing of bad inputs. Can I add test cases to the test_sndhdr.py file? Thanks! I'm here to learn so if there's anything I missed please feel free to let me know. -- nosy: +davidawad ___ Python tracker <https://bugs.python.org/issue34088> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34088] [EASY] sndhdr.what() throws exceptions on unknown files
Change by david awad : -- keywords: +patch pull_requests: +7854 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue34088> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34104] email.message.get_payload should enforce correct encoding
R. David Murray added the comment: It looks like the virus checkers are not doing robust decoding that the email RFCs recommend, and that thunderbird is. This is obviously a bug in the virus scanners. By default, like thunderbird, the email library does its best to decode attachments. If you want your application to reject such attachments, then in python3 you can check for defects after doing the get_payload, or you can set the policy to 'strict' (that is, raise_on_defect=True) when parsing the email. -- nosy: +r.david.murray resolution: -> out of date stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue34104> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34102] local variable 'parts' referenced before assignment in feedparser in email module
R. David Murray added the comment: This appears to be a bug in pip or the ansible-lint package, similar, and possibly identical, to issue 31361. I believe None is being passed in as the argument to feed_parser.feed, which is an invalid use of that API and so correctly results in an error. -- ___ Python tracker <https://bugs.python.org/issue34102> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34070] Superfluous call to isatty in open() when buffering >= 0
Change by David Herberth : -- keywords: +patch pull_requests: +7742 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue34070> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34070] Superfluous call to isatty in open() when buffering >= 0
New submission from David Herberth :
_iomodule.c:_io_open_impl checks for isatty even if not necessary (when
buffering >= 0).
Code:
https://github.com/python/cpython/blob/c0ee341b29bd7d978b49272a2c0e2dcfa77404d5/Modules/_io/_iomodule.c#L392
{
PyObject *res = _PyObject_CallMethodId(raw, _isatty, NULL);
if (res == NULL)
goto error;
isatty = PyLong_AsLong(res);
Py_DECREF(res);
if (isatty == -1 && PyErr_Occurred())
goto error;
}
if (buffering == 1 || (buffering < 0 && isatty)) {
buffering = -1;
line_buffering = 1;
}
else
line_buffering = 0;
Python Code to reproduce:
with open('foo', 'rb', buffering=0) as f:
f.read()
This generates an error (can be seen with strace):
ioctl(5, TCGETS, 0x7ffef1435b60) = -1 ENOTTY (Inappropriate ioctl for device)
I'll open a PR shortly.
--
components: IO
messages: 321281
nosy: Dav1d
priority: normal
severity: normal
status: open
title: Superfluous call to isatty in open() when buffering >= 0
type: performance
versions: Python 3.6, Python 3.7, Python 3.8
___
Python tracker
<https://bugs.python.org/issue34070>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34025] SMTP EmailPolicy not using the correct line length for RCF 2045 encoded data (is 78, should be 76)
R. David Murray added the comment: The default maximum line length is indeed supposed to be 78 (characters..and I can't now remember whether I implemented it in terms of characters or octets), that's per RFC 5322. What is wrong is that content encoded text is supposed to use a max line length of 76. A "simple" fix would be to hardcode the maximum line length at 76 when doing content encoding. An arguably better fix would be a separate policy control for the encoded text line length. The former can be the bug fix, but it would be nice to have the latter as an enhancement. -- title: SMTP EmailPolicy not setting max_line_length as expected. RCF 2045 states 76 char, Default policy uses 78 -> SMTP EmailPolicy not using the correct line length for RCF 2045 encoded data (is 78, should be 76) ___ Python tracker <https://bugs.python.org/issue34025> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34009] Document Travis CI / Ubuntu 14.04 OpenSSL compatibility issues
David MacIver added the comment: Anthony Sottile has pointed out to me that I'm wrong about the xenial thing, and that actually it does work it's just that you need to get multiple things right in order for it to do so. https://github.com/deadsnakes/travis-ci-python3.7-example is a good example of making it work. -- ___ Python tracker <https://bugs.python.org/issue34009> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34009] Document Travis CI / Ubuntu 14.04 OpenSSL compatibility issues
David MacIver added the comment: > According to > https://github.com/travis-ci/travis-ci/issues/9069#issuecomment-395471575, > setting "dist: xenial" instead (giving Ubuntu 16.04) provides a testing > environment with a new enough OpenSSL for 3.7 to work. No, this doesn't work either. The xenial environment is an experimental feature and doesn't work at all reliably. At the time of this writing setting "dist: xenial" actually puts you into Trusty. Currently the viable ways of making it work on Travis are to either run a custom docker image (which requires you to opt out of their containerized builds and thus makes everything slower), or to build OpenSSL yourself (and making the latter work correctly is a far from straightforward process). -- nosy: +David MacIver ___ Python tracker <https://bugs.python.org/issue34009> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33938] Cross compilation fail for ARM
David added the comment: After using --with-system-ffi and setting the correct LD_LIBRARY_PATH, it worked. Many thanks for the help! -- stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue33938> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33938] Cross compilation fail for ARM
New submission from David : Hi all, I fail on cross compiling Python 2.7.14 for ARM using a self built toolchain. Build host: Linux x86-64 CentOS 7 Target: arm cortex-a9 My steps are compiling python for the host, after that compiling python for the target using the PYTHON_FOR_BUILD flag with the prior built python. Compile settings: cd /home/op/Projekte/Cross_Linux/src/Python-2.7.15 && ./configure --host=arm-cortexa9_neon-linux-gnueabihf ac_cv_file__dev_ptmx=no ac_cv_file__dev_ptc=no ac_cv_have_long_long_format=yes --enable-shared --disable-ipv6 --build=x86_64-pc-linux-gnu PYTHON_FOR_BUILD=/home/op/Projekte/Cross_Linux/hostsrc/../root/bin/python --prefix=/home/op/Projekte/Cross_Linux/src/Python-2.7.15/_install || exit 11 ;\ make -C /home/op/Projekte/Cross_Linux/src/Python-2.7.15 V=1 || exit 12 ;\ make -C /home/op/Projekte/Cross_Linux/src/Python-2.7.15 install V=1 || exit 13 ;\ Last snippet from the build log for the target: building 'ossaudiodev' extension arm-cortexa9_neon-linux-gnueabihf-gcc -fPIC -fno-strict-aliasing -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv -DNDEBUG -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv -I. -IInclude -I/usr/local/include -I/usr/include/python2.7 -c ossaudiodev.c -o build/temp.linux-x86_64-2.7/ossaudiodev.o arm-cortexa9_neon-linux-gnueabihf-gcc: Fehler: nicht erkanntes Kommandozeilenargument in Option »-mtune=generic« arm-cortexa9_neon-linux-gnueabihf-gcc: Anmerkung: gültige Argumente für »-mtune=« sind: arm1020e arm1020t arm1022e arm1026ej-s arm10e arm10tdmi arm1136j-s arm1136jf-s arm1156t2-s arm1156t2f-s arm1176jz-s arm1176jzf-s arm2 arm250 arm3 arm6 arm60 arm600 arm610 arm620 arm7 arm70 arm700 arm700i arm710 arm7100 arm710c arm710t arm720 arm720t arm740t arm7500 arm7500fe arm7d arm7di arm7dm arm7dmi arm7m arm7tdmi arm7tdmi-s arm8 arm810 arm9 arm920 arm920t arm922t arm926ej-s arm940t arm946e-s arm966e-s arm968e-s arm9e arm9tdmi cortex-a12 cortex-a15 cortex-a15.cortex-a7 cortex-a5 cortex-a53 cortex-a57 cortex-a57.cortex-a53 cortex-a7 cortex-a8 cortex-a9 cortex-m0 cortex-m0plus cortex-m1 cortex-m3 cortex-m4 cortex-r4 cortex-r4f cortex-r5 cortex-r7 ep9312 fa526 fa606te fa626 fa626te fa726te fmp626 generic-armv7-a iwmmxt iwmmxt2 marvell-pj4 mpcore mpcorenovfp native strongarm strongarm110 strongarm1100 strongarm1110 xscale arm-cortexa9_neon-linux-gnueabihf-gcc: Fehler: nicht erkanntes Kommandozeilenargument in Option »-mtune=generic« arm-cortexa9_neon-linux-gnueabihf-gcc: Anmerkung: gültige Argumente für »-mtune=« sind: arm1020e arm1020t arm1022e arm1026ej-s arm10e arm10tdmi arm1136j-s arm1136jf-s arm1156t2-s arm1156t2f-s arm1176jz-s arm1176jzf-s arm2 arm250 arm3 arm6 arm60 arm600 arm610 arm620 arm7 arm70 arm700 arm700i arm710 arm7100 arm710c arm710t arm720 arm720t arm740t arm7500 arm7500fe arm7d arm7di arm7dm arm7dmi arm7m arm7tdmi arm7tdmi-s arm8 arm810 arm9 arm920 arm920t arm922t arm926ej-s arm940t arm946e-s arm966e-s arm968e-s arm9e arm9tdmi cortex-a12 cortex-a15 cortex-a15.cortex-a7 cortex-a5 cortex-a53 cortex-a57 cortex-a57.cortex-a53 cortex-a7 cortex-a8 cortex-a9 cortex-m0 cortex-m0plus cortex-m1 cortex-m3 cortex-m4 cortex-r4 cortex-r4f cortex-r5 cortex-r7 ep9312 fa526 fa606te fa626 fa626te fa726te fmp626 generic-armv7-a iwmmxt iwmmxt2 marvell-pj4 mpcore mpcorenovfp native strongarm strongarm110 strongarm1100 strongarm1110 xscale arm-cortexa9_neon-linux-gnueabihf-gcc: Fehler: ossaudiodev.c: Datei oder Verzeichnis nicht gefunden arm-cortexa9_neon-linux-gnueabihf-gcc: Fehler: nicht erkannte Kommandozeilenoption »-m64« arm-cortexa9_neon-linux-gnueabihf-gcc: Fehler: nicht erkannte Kommandozeilenoption »-m64« arm-cortexa9_neon-linux-gnueabihf-gcc: schwerwiegender Fehler: keine Eingabedateien Kompilierung beendet. error: /builddir/build/BUILD/Python-2.7.5/Modules/_ctypes/libffi: No such file or directory make[1]: *** [sharedmods] Fehler 1 I can't get rid of the wrong compiler flags -m64 and -mtune=generic. Target python build log attached. -- components: Cross-Build files: targetpython_build.log messages: 320222 nosy: Alex.Willmer, n0s69z priority: normal severity: normal status: open title: Cross compilation fail for ARM type: compile error versions: Python 2.7 Added file: https://bugs.python.org/file47647/targetpython_build.log ___ Python tracker <https://bugs.python.org/issue33938> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33935] shutil.copyfile throws incorrect SameFileError on Google Drive File Stream
R. David Murray added the comment: OK. Finding a solution for this (other than never raising samefile on such systems and documenting it as a limitation) may be difficult. -- ___ Python tracker <https://bugs.python.org/issue33935> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33935] shutil.copyfile throws incorrect SameFileError on Google Drive File Stream
R. David Murray added the comment: That patch would cause references to the same file on a google drive to report that the files were different. I'd say this is a bug in Google Drive's posix emulation. I'm not sure there's a good answer here, because even if every other element of the stat were equal, that wouldn't mean it was the same file: if you use copystat as well as copyfile the stats would otherwise be equal. I think we should close this as a third party bug. -- nosy: +r.david.murray ___ Python tracker <https://bugs.python.org/issue33935> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33925] builtin_function_or_method compares __self__ by identity instead of equality
R. David Murray added the comment: This is still a duplicate issue, though, you are just arguing for a different resolution of the other one :) -- nosy: +r.david.murray ___ Python tracker <https://bugs.python.org/issue33925> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32500] PySequence_Length() raises TypeError on dict type
R. David Murray added the comment: IIUC that error message came from pypy, not CPython. If you have a reproducer for CPython, you can open a new issue with a request to fix the error message. -- nosy: +r.david.murray ___ Python tracker <https://bugs.python.org/issue32500> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33809] Expose `capture_locals` parameter in `traceback` convenience functions
R. David Murray added the comment: I think we should get one or more of the core devs who were involved in the changes that added that parameter to sign off on whether this is a good idea or not (I have no opinion at the moment). You should be able to find them via git blame and looking at the issues related to the changesets you find. Unless someone who remembers comes along and just adds them to nosy :) -- nosy: +r.david.murray type: -> enhancement versions: -Python 3.5, Python 3.6, Python 3.7 ___ Python tracker <https://bugs.python.org/issue33809> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33896] Document what components make up the filecmp.cmp os.stat signature.
R. David Murray added the comment: I think it might be OK to document what goes in to the signature, but probably in a footnote, as it is somewhat of an implementation detail and could conceivably change. We could then also add a caution about mtime imprecision being a particular risk on some file systems. I wouldn't want to put such a caution in the main doc paragraphs, but in a footnote I think it would be OK. -- resolution: rejected -> stage: resolved -> needs patch status: closed -> open title: filecmp.cmp returns True on files that differ -> Document what components make up the filecmp.cmp os.stat signature. versions: +Python 3.8 -Python 2.7, Python 3.4, Python 3.5 ___ Python tracker <https://bugs.python.org/issue33896> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33896] Document what components make up the filecmp.cmp os.stat signature.
Change by R. David Murray : -- versions: +Python 2.7 ___ Python tracker <https://bugs.python.org/issue33896> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33896] filecmp.cmp returns True on files that differ
R. David Murray added the comment: For your problem, just don't use the default shallow setting :) -- ___ Python tracker <https://bugs.python.org/issue33896> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33896] filecmp.cmp returns True on files that differ
R. David Murray added the comment: I understand your concern, but this is working as designed and documented. Using st_ino would mean you would return true if and only if it was the *same* file. That is not the intent. See issue 27396 for some background discussion. -- nosy: +r.david.murray resolution: -> rejected stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue33896> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28710] Sphinx incompatible markup in the standard library docstrings
R. David Murray added the comment: I would still like to see the legacy tex markup removed from the docstrings, so I think closing this issue is not appropriate, but it's not a big enough deal that I'll push for it if Raymond wants to keep it closed. -- ___ Python tracker <https://bugs.python.org/issue28710> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28710] Sphinx incompatible markup in the standard library docstrings
R. David Murray added the comment: No, it is (somewhat) unique to tex. If you write `word' tex would turn that into a pair of opposing quotes in the typeset document, as opposed to 'word' (the convention in regular text/emails/posts/etc) where you'd just see ascii quotes. tex would render 'word' as a closing quote both before and after word, which looks weird in typeset text. There's no bug here; as you say we aren't interested in making the docstrings parseable as restructured text (at least, I'm not). For me, this is about getting rid of the now-odd-looking tex leftovers and making the ascii styling consistent with the bulk of our docstrings. It's not a big deal, though. -- ___ Python tracker <https://bugs.python.org/issue28710> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28710] Sphinx incompatible markup in the standard library docstrings
R. David Murray added the comment: By the way, in case anyone is curious, I'm pretty sure that markup is left over from the days when tex/latex was what docs were *written* in. -- ___ Python tracker <https://bugs.python.org/issue28710> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28710] Sphinx incompatible markup in the standard library docstrings
R. David Murray added the comment: Right, my opinion is that we shouldn't be putting markup in docstrings. They are (from our point of view) pure text. I don't know if discussion on python-dev is warranted, it seems like a fairly uncontroversial change, since it brings the docstrings in question into compliance with our general practice in the majority of the stdlib. Unless my impression about that is wrong :) I don't have an opinion on multiple versus single PR for this. -- ___ Python tracker <https://bugs.python.org/issue28710> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29750] smtplib doesn't handle unicode passwords
R. David Murray added the comment: I didn't think to look at the standards for the auth mechanisms, I only looked at the smtp standards. So, if the standard says utf-8, then we should use that. But we should still support bytes passwords so that an application could work around issues like the possible ms-exchange one, if they need to. Those could be two separate PRs, though. In fact, they probably should be. As a standards-compliance issue, we would be within our rules to backport the utf-8 standards-compliance fix. -- ___ Python tracker <https://bugs.python.org/issue29750> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33893] Linux terminal shortcuts support in python shell
R. David Murray added the comment: zsh lets you edit multiline shell commands as a unit. If you up-arrow, you get all the lines of the block popped up, with the cursor on the last line. Further arrow keys will navigate within the multiline text block, with an up-arrow from the first line taking you to the next previous shell command, and enter within the block will re-execute the entire modified multiline command. I haven't used IDLE recently enough to remember how that compares to how IDLE works. -- nosy: +r.david.murray ___ Python tracker <https://bugs.python.org/issue33893> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28710] Sphinx incompatible markup in the standard library
R. David Murray added the comment: Thanks for coming back to this. We're accepting PRs via github now, so the next step now would be to make it into a PR. Sometimes things just get forgotten and you have to nudge them to get them moving (see the devguide for guidelines about when it is appropriate to nudge an issue). -- ___ Python tracker <https://bugs.python.org/issue28710> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33890] Pathlib does not compare Windows and MinGW paths as equal
R. David Murray added the comment: Sorry, but these paths are not equal in in any sense that Python by itself can determine. Support for doing this kind of comparison would have to come from MingGW or cygwin, and even if a python library exposed those capabilities, it would be via some new API, because you are effectively asking for a cross-platform comparison of paths. At least, that's my opinion. Regardless, this is a feature request and one with enough implications that we can't handle it in the bug tracker. The way forward with this idea is to discuss the possibility of such an API on the python-ideas mailing list. Maybe you could even get agreement that normal equality could implement it. Regardless, you'll need to be able to discuss the MingGW/cygwin facilities that would allow it to be implemented as a minimum starting point. If those facilities don't exist, there's no hope ;) -- nosy: +r.david.murray resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue33890> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29750] smtplib doesn't handle unicode passwords
R. David Murray added the comment: We must continue to support at least ascii strings, for backward compatibility reasons. We can certainly improve the error messages, but the goal of this issue is to add support for bytes passwords. I lean toward continuing to only support ascii strings, and making it the responsibility of the program to do the encoding to bytes when dealing with non-ascii. However, I'd like to also be able to recommend in the docs what encoding is most likely to work, if someone can find out what encoding Thunderbird uses...however, it occurs to me that it may be using whatever encoding the OS is using (LC_LANG, oem codepage, etc), and that David's experiments worked because the same encoding was used for the same reason when the password was set. I'm not sure how browsers/webmail works in that regard, honestly. That's less important than just adding support for bytes passwords, though. -- ___ Python tracker <https://bugs.python.org/issue29750> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29750] smtplib doesn't handle unicode passwords
david added the comment: I would like to see the second option (allow both, warning on non-ascii) On 17 June 2018 at 21:03, Tal Einat wrote: > > Tal Einat added the comment: > > > And yes, by binary passwords I mean that the module needs to support > being passed a bytes-like object as the password, since clearly there are > servers "in the wild" that support non-ascii passwords and the only way to > be sure one can send the server the correct password is by treating it as a > series of bytes. The library caller will have to be responsible for > picking the correct encoding based on local knowledge. > > Perhaps we should make smtplib accept only bytes, passing on the > responsibility of using an appropriate encoding to its users? This seems > like the most straightforward and transparent choice. It would not be > backwards-compatible, though. > > Alternatively, we could change smtplib to accept passwords as bytes or > strings, but raise an informative exception when given strings with > non-ASCII characters. As now, users could be surprised if they have been > passing passwords as string and hadn't tested their use of smtplib with > non-ASCII passwords. We'd just improve the exception and documentation to > clarify the situation. > > -- > > ___ > Python tracker > <https://bugs.python.org/issue29750> > ___ > -- ___ Python tracker <https://bugs.python.org/issue29750> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33846] Misleading error message in urllib.parse.unquote
R. David Murray added the comment: I thought there was a more general issue for the 'in' operator itself, but perhaps the issue you found was indeed the one I was thinking of. This one certainly seems to be a duplicate of that one ;) If you've a mind to, you could turn the patch in that issue into a PR to move the issue forward. -- resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> urllib.parse.unquote raises incorrect errormessage when string parameter is bytes ___ Python tracker <https://bugs.python.org/issue33846> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33879] Item assignment in tuple mutates list despite throwing error
Change by R. David Murray : -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue33879> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29750] smtplib doesn't handle unicode passwords
david added the comment: Yes, i used thunderbird for both On June 14, 2018 5:14:31 PM GMT+02:00, "R. David Murray" wrote: > >R. David Murray added the comment: > >For the web cases I presume you also set the password using the web >interface, so that doesn't really tell us anything useful. Did you use >thunderbird to access the mailbox that you set up via gmail and/or >sogo? That would make what thunderbird does the interesting question. > >-- > >___ >Python tracker ><https://bugs.python.org/issue29750> >___ -- ___ Python tracker <https://bugs.python.org/issue29750> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29750] smtplib doesn't handle unicode passwords
R. David Murray added the comment: For the web cases I presume you also set the password using the web interface, so that doesn't really tell us anything useful. Did you use thunderbird to access the mailbox that you set up via gmail and/or sogo? That would make what thunderbird does the interesting question. -- ___ Python tracker <https://bugs.python.org/issue29750> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29750] smtplib doesn't handle unicode passwords
david added the comment: Both thunderbird, sogo (web) and gmail (web). On June 14, 2018 3:54:31 PM GMT+02:00, "R. David Murray" wrote: > >R. David Murray added the comment: > >While you are correct that latin1 may be common in this situation, I >think it may still be better to have utf-8 be the default, since that >is the (still emerging? :) standard. However, you are correct to call >for examples: if in the *majority* of the real-world cases it turns out >latin1 is what is used, then we could default to that (or not have a >default, but instead document our observations). > >I don't know how we accumulate enough information to make that >decision, though. Maybe we could look at what other mail programs do? >Thunderbird, etc? David, which mail program(s) did you use that were >able to successfully send that password? > >And yes, by binary passwords I mean that the module needs to support >being passed a bytes-like object as the password, since clearly there >are servers "in the wild" that support non-ascii passwords and the only >way to be sure one can send the server the correct password is by >treating it as a series of bytes. The library caller will have to be >responsible for picking the correct encoding based on local knowledge. > >-- > >___ >Python tracker ><https://bugs.python.org/issue29750> >___ -- ___ Python tracker <https://bugs.python.org/issue29750> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29750] smtplib doesn't handle unicode passwords
R. David Murray added the comment: While you are correct that latin1 may be common in this situation, I think it may still be better to have utf-8 be the default, since that is the (still emerging? :) standard. However, you are correct to call for examples: if in the *majority* of the real-world cases it turns out latin1 is what is used, then we could default to that (or not have a default, but instead document our observations). I don't know how we accumulate enough information to make that decision, though. Maybe we could look at what other mail programs do? Thunderbird, etc? David, which mail program(s) did you use that were able to successfully send that password? And yes, by binary passwords I mean that the module needs to support being passed a bytes-like object as the password, since clearly there are servers "in the wild" that support non-ascii passwords and the only way to be sure one can send the server the correct password is by treating it as a series of bytes. The library caller will have to be responsible for picking the correct encoding based on local knowledge. -- ___ Python tracker <https://bugs.python.org/issue29750> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29750] smtplib doesn't handle unicode passwords
david added the comment: In my case I was doing tests with "contraseña" which is (spanish for password) and it failed On June 14, 2018 8:36:30 AM GMT+02:00, Tal Einat wrote: > >Tal Einat added the comment: > >It would be extremely helpful to have some test cases that actually >work for users but fail with smtplib. So far we have no actual >examples, likely due to these being passwords. > >> Note: it is definitely the case, regardless of what the RFC says, >that binary passwords need to be supported. > >I'm not sure what you mean by "binary". Do you mean 8-bit characters, >a.k.a. bytes? > >> utf-8 should probably be used as the default encoding for string >passwords, rather than ascii. > >It is also possible that the appropriate encoding here is "latin1" >a.k.a. ISO-8859-1 encoding. This specifically includes many >specialized versions of latin characters, e.g. those with German >umlauts as mentioned in the duplicate issue #33741. And it could even >be the very common Windows-1252 encoding: "It is probably the most-used >8-bit character encoding in the world." (Wikipedia) > >-- > >___ >Python tracker ><https://bugs.python.org/issue29750> >___ -- ___ Python tracker <https://bugs.python.org/issue29750> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33846] Misleading error message in urllib.parse.unquote
R. David Murray added the comment: We don't generally do type checks like that. This is a specific case of a general issue with binary operators and mismatched string/bytes types. I thought there was an open issue for it, but I haven't found it yet. -- nosy: +r.david.murray ___ Python tracker <https://bugs.python.org/issue33846> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33844] Writing capital letters with csvwriter.writerow changes the csv file format
R. David Murray added the comment: It doesn't look like this has anything to do with Python. This sounds like a question more appropriate for an Excel help forum. -- nosy: +r.david.murray ___ Python tracker <https://bugs.python.org/issue33844> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33819] Mention "ordered mapping" instead of "ordered dictionary" in email module
R. David Murray added the comment: Message/EmailMessage are intentionally mimicing the full dictionary API, not just the Mapping API (with a couple exceptions and several extensions). But it is important to mention that it is ordered, both for the reason INADA stgtes, and because the text goes on to discuss the handling of duplicate headers and what happens when you add and delete headers. While this turns out to be almost the same as the rules used by a standard python dictionary, that is partially a coincidenceother ordering rules could have been chosen. -- nosy: +r.david.murray resolution: -> not a bug stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue33819> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33835] Too strong side effect?
Change by R. David Murray : -- status: open -> closed ___ Python tracker <https://bugs.python.org/issue33835> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30820] email.contentmanager.raw_data_manager fails to create multipart messages
R. David Murray added the comment: Thanks, Zachery. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue30820> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30820] email.contentmanager.raw_data_manager fails to create multipart messages
R. David Murray added the comment: New changeset bbbc3d99dca41bc95a9402d702f6ab833d3003c7 by R. David Murray (Miss Islington (bot)) in branch '3.6': bpo-30820: Remove incorrect docs for email.contentmanager.raw_data_manager (GH-7631) (#7634) https://github.com/python/cpython/commit/bbbc3d99dca41bc95a9402d702f6ab833d3003c7 -- ___ Python tracker <https://bugs.python.org/issue30820> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30820] email.contentmanager.raw_data_manager fails to create multipart messages
R. David Murray added the comment: New changeset b06fc2d244f95f8a497cbcdc6e2fbeb9b8133ca3 by R. David Murray (Miss Islington (bot)) in branch '3.7': bpo-30820: Remove incorrect docs for email.contentmanager.raw_data_manager (GH-7631) (#7633) https://github.com/python/cpython/commit/b06fc2d244f95f8a497cbcdc6e2fbeb9b8133ca3 -- ___ Python tracker <https://bugs.python.org/issue30820> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30820] email.contentmanager.raw_data_manager fails to create multipart messages
R. David Murray added the comment: New changeset 2c071cebe67f517f191f4074757a79b0f597d886 by R. David Murray (Zackery Spytz) in branch 'master': bpo-30820: Remove incorrect docs for email.contentmanager.raw_data_manager (#7631) https://github.com/python/cpython/commit/2c071cebe67f517f191f4074757a79b0f597d886 -- ___ Python tracker <https://bugs.python.org/issue30820> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29750] smtplib doesn't handle unicode passwords
Change by R. David Murray : -- stage: -> needs patch versions: +Python 3.8 -Python 3.7 ___ Python tracker <https://bugs.python.org/issue29750> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29750] smtplib doesn't handle unicode passwords
R. David Murray added the comment: Note: it is definitely the case, regardless of what the RFC says, that binary passwords need to be supported. utf-8 should probably be used as the default encoding for string passwords, rather than ascii. See also #33741. -- ___ Python tracker <https://bugs.python.org/issue29750> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29750] smtplib doesn't handle unicode passwords
Change by R. David Murray : -- nosy: +JustAnother1, giampaolo.rodola, taleinat ___ Python tracker <https://bugs.python.org/issue29750> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33741] UnicodeEncodeError onsmtplib.login(MAIL_USER, MAIL_PASSWORD)
R. David Murray added the comment: Duplicate of #29750. TLDR: smtplib needs to be fixed to handle binary passwords, and probably to use utf-8 as the default encoding for unicode passwords. -- nosy: +r.david.murray resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> smtplib doesn't handle unicode passwords ___ Python tracker <https://bugs.python.org/issue33741> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33770] base64 throws 'incorrect padding' exception when the issue is NOT with the padding
R. David Murray added the comment: I think that would move it even more into the realm of a bugfix, then, since code that cared about specific binascii exceptions could be looking for that one already. -- ___ Python tracker <https://bugs.python.org/issue33770> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28557] error message for bad raw readinto
Change by R. David Murray : -- nosy: +benjamin.peterson, stutzbach ___ Python tracker <https://bugs.python.org/issue28557> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33806] Cannot re-open an existing telnet session
R. David Murray added the comment: To clarify: don't call open again *on that telnetlib.Telnet object*. You can certainly have more than one open connection using different telnetlib.Telnet instances, though it might be a bit challenging to manage them :) -- ___ Python tracker <https://bugs.python.org/issue33806> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33806] Cannot re-open an existing telnet session
Change by R. David Murray : -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue33806> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33806] Cannot re-open an existing telnet session
R. David Murray added the comment:
telnetlib provides a low level interface to the telnet protocol. The dialog
you mention appears to be transmitted on the telnet connection, so it is
unlikely there is any bug or missing feature in telnetlib that would affect
your problem.
The sentence in the docs you appear to be referring to ("Do not reopen an
already connected instance.") is just telling you that once you have used to
telnetlib to open a connection, don't call open again. It has nothing to say
about a telnet connection made by some other program.
So, you have an application level problem and should seek help on the
python-list mailing list or some other general help forum. Unless you can
identify something *specific* in telnetlib (bug or missing feature) that
prevents you from solving your problem, I don't think there's anything more to
be done here.
(As an aside, have you tried sending /r/n after the a?)
--
nosy: +r.david.murray
___
Python tracker
<https://bugs.python.org/issue33806>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28557] error message for bad raw readinto
Change by David Szotten : -- pull_requests: +7121 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue28557> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22454] Adding the opposite function of shlex.split()
R. David Murray added the comment: I like it, myself, though there is some danger in promoting the idea that this is a "safe" operation. It theoretically should be, but it increases the attack surface slightly if you actually use it (that is, using shell=False is always safer, by at least a small margin). Maybe a mention of that in the docs would be enough, though. -- nosy: +r.david.murray ___ Python tracker <https://bugs.python.org/issue22454> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33687] uu.py calls os.path.chmod which doesn't exist
R. David Murray added the comment: The email module uses it, so I would object to its being removed. It may not be used often (probably only when working with old email archives), but there's no good reason I can see to break something that currently works. -- nosy: +r.david.murray ___ Python tracker <https://bugs.python.org/issue33687> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33774] Document that @lru_cache caches based on exactly how the function arguments are specified
R. David Murray added the comment: Agreed that this should be documented. -- nosy: +r.david.murray, rhettinger stage: -> needs patch title: Improve doc of @lru_cache to avoid misuse and confusion -> Document that @lru_cache caches based on exactly how the function arguments are specified versions: +Python 3.6, Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue33774> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33770] base64 throws 'incorrect padding' exception when the issue is NOT with the padding
R. David Murray added the comment: I agree, but that would be a separate enhancement PR. The email library would use that capability if it existed...currently it adds padding in a loop trying to do the decode if it gets the invalid padding message. Which of course is going to fail for this case. -- ___ Python tracker <https://bugs.python.org/issue33770> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33164] Blake 2 module update
Change by David Carlier : -- keywords: +patch pull_requests: +7043 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue33164> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33772] Fix few dead code paths
Change by David Carlier : -- components: Interpreter Core nosy: David Carlier priority: normal pull_requests: 7042 severity: normal status: open title: Fix few dead code paths versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue33772> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29539] [smtplib] collect response data for all recipients
David Ford (FirefighterBlu3) added the comment: Yes, it is distinctly intended to collect the results for every recipient as in modern MTAs, there's more than just success/fail results. This is to collect data such as queue ID and the MTA's programmatic response for each individual recipient. I have several needs of knowing if the message was immediately relayed, queued for later because of a remote issue, queued because of MTA issue, graylisted or blocked because of milter reasons, or ... any of a list of failure reasons. This data can be collected if there is only one recipient per message, but that is considerably resource expensive. Without this patch, when sending to say 100 recipients, the only response returned to the caller is the very last (100th) result. A 250 then assumes that all 100 were transmitted successfully when in truth, the first 99 could have failed. Yes, I'll make a PR, do the CLA, and add some tests. -- ___ Python tracker <https://bugs.python.org/issue29539> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33770] base64 throws 'incorrect padding' exception even though the string length is a multiple of 4
R. David Murray added the comment: I always assumed that any string composed of valid base64 characters could be decoded to *something* if you added some padding characters, but apparently that was an invalid assumption. I agree that the message is incorrect for this case. -- nosy: +r.david.murray stage: -> needs patch type: -> behavior versions: +Python 2.7, Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue33770> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33527] Invalid child function scope
Change by R. David Murray : -- resolution: -> not a bug stage: test needed -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue33527> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33749] pdb.Pdb constructor stdout override required to disable use_rawinput
Change by R. David Murray : -- superseder: -> can cmd.py's API/docs for the use of an alternate stdin be improved? ___ Python tracker <https://bugs.python.org/issue33749> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33749] pdb.Pdb constructor stdout override required to disable use_rawinput
R. David Murray added the comment: This is a duplicate of 2571 and 10396. As I commented in 10396, if you want to work on an enhancement request (for cmd) that improves the situation, it will be welcome; but as you observed what to do isn't immediately obvious, so discussion before implementation is probably a good idea. I'm going to close this, but feel free to open an enhancement issue with a proposal. -- nosy: +r.david.murray resolution: -> duplicate stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue33749> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33754] f-strings should be part of the Grammar
David Halter added the comment: As I wrote before, I'm not trying to change anything about the f-string behavior. It is a refactoring. If anyone wants to change the behavior, I feel like they should probably write a PEP anyway. I personally don't like that f-strings get parsed multiple times. It just smells bad. Also f-strings are IMO not just strings. They should maybe look like strings for other tools to parse them. But they are more or less statements that get executed. The code in ast.c is not bad. Don't get me wrong. I just think that it's the wrong approach. Regarding the edge cases: I don't think there are that many. In the end the ast output will look similar anyway. All the backslashes, string literals and comments can be checked and rejected in the tokenizer already. -- ___ Python tracker <https://bugs.python.org/issue33754> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33754] f-strings should be part of the Grammar
New submission from David Halter :
Currently f-strings are a bit of a hack. They certainly work very well for
users, but they are implemented in ast.c and therefore not part of the Python
grammar and the tokenizer.
I want to change this. I wrote an alternative implementation of f-strings in
parso (http://parso.readthedocs.io/en/latest/). The idea I have is to modify
the Python grammar slightly
(https://github.com/davidhalter/parso/blob/master/parso/python/grammar37.txt#L149):
fstring: FSTRING_START fstring_content* FSTRING_END
fstring_content: FSTRING_STRING | fstring_expr
fstring_conversion: '!' NAME
fstring_expr: '{' testlist [ fstring_conversion ] [ fstring_format_spec ] '}'
fstring_format_spec: ':' fstring_content*
We would push most of the hard work to the tokenizer. This obviously means that
we have to add a lot of code there. I wrote a tokenizer in Python for parso
here: in
https://github.com/davidhalter/parso/blob/master/parso/python/tokenize.py. It
is definitely working well. The biggest difference to the current tokenizer.c
is that you have to work with stacks and be way more context-sensitive.
There were attempts to change the Grammar of f-strings like
https://www.python.org/dev/peps/pep-0536/. It hasn't caught on, because it
tried to change the semantics of f-strings. The implementation in parso has not
changed the semantics of f-strings.
In a first step I would like to get this working for CPython and not
tokenize.py. Modifying tokenize.py will not be part of my initial work here.
I have discussed this with Łukasz Langa, so if you guys have no objections I
will start working on it. Please let me know if you support this or not.
--
components: Interpreter Core
messages: 318547
nosy: davidhalter
priority: normal
severity: normal
status: open
title: f-strings should be part of the Grammar
type: enhancement
versions: Python 3.8
___
Python tracker
<https://bugs.python.org/issue33754>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29539] [smtplib] collect response data for all recipients
David Ford (FirefighterBlu3) added the comment: 3.7 release candidates are in the queue, any thoughts on this simple enhancement? -- ___ Python tracker <https://bugs.python.org/issue29539> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24085] large memory overhead when pyc is recompiled
R. David Murray added the comment: That's presumably due to the compile-time constant-expression optimization. Have you tried bytes(0x100)? I don't think that gets treated as a constant by the optimizer (but I could be wrong since a bunch of things ahve been added to it lately). -- nosy: +r.david.murray ___ Python tracker <https://bugs.python.org/issue24085> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33721] os.path.exists() ought to return False if pathname contains NUL
R. David Murray added the comment: I seem to recall that this ValueError behavior was discussed at some length and it is the desired behavior. (At some previous point I think everything after the NUL was ignored.) I'm not really sure why it needs to be documented either, NULs are invalid in filenames, aren't they? Or are there some OSes that allow them? -- nosy: +r.david.murray ___ Python tracker <https://bugs.python.org/issue33721> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33690] urlib.parse.urlencode with empty list and doseq=True drops the parameter
Change by R. David Murray : -- resolution: -> not a bug ___ Python tracker <https://bugs.python.org/issue33690> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33690] urlib.parse.urlencode with empty list and doseq=True drops the parameter
R. David Murray added the comment: It would be odd to do that, since blank values are kept by default. -- ___ Python tracker <https://bugs.python.org/issue33690> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29326] Blank lines in ._pth file are not ignored
R. David Murray added the comment: Vladimir, please open a new issue for this feature request. This issue is closed. -- nosy: +r.david.murray ___ Python tracker <https://bugs.python.org/issue29326> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22021] shutil.make_archive() root_dir do not work
R. David Murray added the comment: Sounds reasonable to me. -- ___ Python tracker <https://bugs.python.org/issue22021> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33690] urlib.parse.urlencode with empty list and doseq=True drops the parameter
R. David Murray added the comment: If a sequence as a value means repeated instances of a key with each value from the list, then logically an empty list means no instances of the key, as documented. Blank values aren't really part of the standard (such as it is): the absence of a parameter is supposed to be equivalent to the value being empty. Because of this, you have to pass keep_blank_values=True to parse_qs to retain keys with blank values. I think it is reasonable that you have to take extra action if you want an empty list of values to instead result in a single key with a blank value. So, this is working as designed and desired, I think. -- nosy: +r.david.murray ___ Python tracker <https://bugs.python.org/issue33690> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33667] Mock calls on mutable objects
Change by R. David Murray : -- resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> Python unittest.mock.mock_calls stores references to arguments instead of their values ___ Python tracker <https://bugs.python.org/issue33667> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
