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
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
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
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
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
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
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
<ht
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/issue34
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 pa
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/issue32
R. David Murray added the comment:
Thanks, Chason.
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
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
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
Change by R. David Murray :
--
nosy: +altvod
versions: +Python 3.7, Python 3.8 -Python 3.6
___
Python tracker
<https://bugs.python.org/issue33524>
___
___
Pytho
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
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
Change by R. David Murray :
--
resolution: duplicate ->
stage: resolved -> needs patch
status: closed -> open
___
Python tracker
<https://bugs.python.or
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
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/issue34
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.or
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=8
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/issue34
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
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
Change by david awad :
--
keywords: +patch
pull_requests: +7854
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue34088>
___
___
Python-
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
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
Change by David Herberth :
--
keywords: +patch
pull_requests: +7742
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue34070>
___
___
Py
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 *
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
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
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, th
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/i
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
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/issue33
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
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/issue33
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
<ht
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
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
Change by R. David Murray :
--
versions: +Python 2.7
___
Python tracker
<https://bugs.python.org/issue33896>
___
___
Python-bugs-list mailing list
Unsubscribe:
R. David Murray added the comment:
For your problem, just don't use the default shallow setting :)
--
___
Python tracker
<https://bugs.python.org/issue33
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 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
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
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/issue28
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
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
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
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
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
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
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
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
Change by R. David Murray :
--
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
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 reall
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
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 stil
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
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 cas
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
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/issue33
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
Change by R. David Murray :
--
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue33835>
___
___
Python-bugs-list mailing list
Unsubscrib
R. David Murray added the comment:
Thanks, Zachery.
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
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
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
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
Change by R. David Murray :
--
stage: -> needs patch
versions: +Python 3.8 -Python 3.7
___
Python tracker
<https://bugs.python.org/issue29750>
___
___
Python-
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
Change by R. David Murray :
--
nosy: +JustAnother1, giampaolo.rodola, taleinat
___
Python tracker
<https://bugs.python.org/issue29750>
___
___
Python-bugs-list m
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 -&g
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
<ht
Change by R. David Murray :
--
nosy: +benjamin.peterson, stutzbach
___
Python tracker
<https://bugs.python.org/issue28557>
___
___
Python-bugs-list mailin
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
Change by R. David Murray :
--
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
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
Change by David Szotten :
--
pull_requests: +7121
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue28557>
___
___
Python-bugs-list mai
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, b
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
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 arg
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
Change by David Carlier :
--
keywords: +patch
pull_requests: +7043
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue33164>
___
___
Py
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.
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
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
Change by R. David Murray :
--
resolution: -> not a bug
stage: test needed -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
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/issu
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
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
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
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/issue29
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
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
Change by R. David Murray :
--
resolution: -> not a bug
___
Python tracker
<https://bugs.python.org/issue33690>
___
___
Python-bugs-list mailing list
Un
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/issue33
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/issue29
R. David Murray added the comment:
Sounds reasonable to me.
--
___
Python tracker
<https://bugs.python.org/issue22021>
___
___
Python-bugs-list mailin
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
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://
701 - 800 of 12771 matches
Mail list logo
