Changes by David W. Lambert :
--
nosy: +LambertDW
___
Python tracker
<http://bugs.python.org/issue5142>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by David W. Lambert :
--
nosy: +LambertDW
___
Python tracker
<http://bugs.python.org/issue5157>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from David W. Lambert :
Allow logger object log message creation methods using ''.format method.
have:
logger_object.info('%s','lazy is better')
logger_object.debug('{0!s}'.format('wasted effort'))
want:
logger_object.
New submission from David W. Lambert :
help function is not current, then again, neither is my python3.
Possibly sequencemethods[12] are eradicated.
$ p3
Python 3.0rc1+ (py3k, Nov 5 2008, 14:44:46)
[GCC 3.4.6 20060404 (Red Hat 3.4.6-3)] on linux2
Type "help", "copyright
David W. Lambert added the comment:
"x |= x>>4"
Are you (Ray) sure you didn't mean
"x ^= x>>4"?
--
nosy: +LambertDW
___
Python track
David W. Lambert added the comment:
I run my shells with low priority so I can sneak around and kill them.
___
Python tracker
<http://bugs.python.org/issue5032>
___
___
Changes by David W. Lambert :
--
nosy: +LambertDW
___
Python tracker
<http://bugs.python.org/issue5229>
___
___
Python-bugs-list mailing list
Unsubscribe:
David W. Lambert added the comment:
'{d}{s}{f}'.format(3, 'foo', 3.14)
is possibly unclear,
but is shorter than
'{#d}{#s}{#f}'.format(...)
--
nosy: +LambertDW
___
Python tracker
<
David W. Lambert added the comment:
I am net yet fluent in format method. I meant
":" where "#" appeared.
Anyway, I think you need the colon.
If from
print('{0:9}'.format(33))
you make the argument number implicit and remove the colon you'd get
prin
David W. Lambert added the comment:
Answering first question msg81873.
Without colon separator, this might be considered confusing:
>>> (
... '{d}{s}{f}{f}'.format(3, 'foo', 3.14, 2.72),
... '{d}{s}{f}{f}'.format(d=3, s='foo', f=3
Changes by David W. Lambert :
--
nosy: +LambertDW
___
Python tracker
<http://bugs.python.org/issue5247>
___
___
Python-bugs-list mailing list
Unsubscribe:
R. David Murray added the comment:
Parsing and newlines have nothing to do with this bug, actually. I don't think
your foldfix post-processing is going to do what you want in the general case.
The source of the bug here is in the folding algorithm in _header_value_parser.
It has chec
Change by William (David) Wilcox :
--
components: Library (Lib)
nosy: wdwilcox
priority: normal
severity: normal
status: open
title: Missing stub for logging attribute manager
type: enhancement
versions: Python 3.10
___
Python tracker
<ht
Change by William (David) Wilcox :
--
resolution: -> rejected
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
New submission from David Alvarez Lombardi :
I frequently find myself doing the following for lists, sets, and dicts.
passes = [x for x in seq if cond(x)]
fails = [x for x in seq if not cond(x)]
The proposed function would behave similarly to `filter`, but it would return a
tuple
New submission from David Alvarez Lombardi :
As of now the best way to filter a str is to convert to list, filter, then join
back to a str. I think a a string comprehension would be very useful for this.
So to get only ascii_lower case chars given this string,
s = "a1b2c3d4&quo
R. David Murray added the comment:
Since python is doing the right thing here, I don't see a particularly good
reason to put a hack into the stdlib to fix the failure of third party software
to adhere to standards. (On the output side. We do follow Postel's rule on
input and t
R. David Murray added the comment:
As far as I know the only resources are the context manager docs and the source
code. The stdlib content manager can serve as a model. I have to admit that
it was long enough ago that I wrote that code that I'd have to re-read the docs
and code myse
R. David Murray added the comment:
Yes, that's the real question. That's what needs to be fixed, otherwise we'll
just keep finding new bugs. For example, try calling iter_parts() on that
message. It isn't pretty :)
--
__
R. David Murray added the comment:
Actually, I'm wrong. The body of a part can be a string, and that's what's
going to happen with a malformed body of something claiming to be a multipart.
The problem is that there is code that doesn't guard against this possibility.
R. David Murray added the comment:
I can't tell tell for sure if this behavior is intentional or not from a quick
glance at the code (though like you I wouldn't think it would be).
That's part of the legacy api, at this point. The new api will just use utf8:
from email
R. David Murray added the comment:
How are you encountering this error? The following program runs without
exception for me on master:
from email import message_from_binary_file
from email.policy import SMTP
msg = message_from_binary_file(open('mail.eml', 'rb'), po
R. David Murray added the comment:
Ah, yes, the problem is more subtle than I thought.
The design here is that we should be starting with the largest lexical unit,
seeing if that fits on the current line, or a line by itself, and if so, using
that, and if not, move down to the next smaller
R. David Murray added the comment:
This bug report starts with "a malicious user with direct access to
`smtplib.SMTP(..., local_hostname, ..)", which is a senseless supposition.
Anyone with "access to" the SMTP object could just as well be talking directly
to th
R. David Murray added the comment:
s/header injection/command injection/
--
___
Python tracker
<https://bugs.python.org/issue43124>
___
___
Python-bugs-list m
R. David Murray added the comment:
There is definitely a problem here, though I see a different problem when I run
it (AttributeError: 'Group' object has no attribute 'local_part', presumably
because of the ':' not getting escaped correctly). I believe it appli
R. David Murray added the comment:
Forget what I said about my different error, I made a mistake running the test
script.
Interesting. If it is related to the length of the name, then the problem is
most likely in the folding algorithm, specifically in what happens when the
"display
R. David Murray added the comment:
Yes, compat32 uses a different parser and folder (the legacy ones), that have a
lot of small bugs relative to the RFCs (which is why I rewrote it).
--
___
Python tracker
<https://bugs.python.org/issue44
R. David Murray added the comment:
My apologies, I did not think about the possibility of an English issue. I was
reacting to the "security report speak", which I find often makes a security
issue sound worse than it is :) Thank you for reporting this problem, and I do
think we
R. David Murray added the comment:
Having looked at the cited part of the RFC (but not tried to analyze it in
detail), I think you are correct. I've also glanced at your PR, and I think
your approach is correct in broad outline, but I haven't looked at the details.
For full mess
R. David Murray added the comment:
I suspect maxheaderlen=0 works because it causes the original lines to be
re-emitted without any folding or other processing. Without that, lines longer
than the default max_line_length get refolded.
Can you provide an example of an input message that
R. David Murray added the comment:
That file appears to be a binary file? By itself it isn't enough to reproduce
the problem. Can you provide a complete script as well as the email message
you are parsing that demonstrates the problem?
By "looks like any other eml file", ar
R. David Murray added the comment:
Mentioning ids would be pretty much redundant with mentioning pickle. If it is
pickled its id is going to change. I think Davin was suggesting that while the
use of serialization is documented, it is not documented *consistently*.
Everywhere
R. David Murray added the comment:
I'm pretty sure this is a duplicate report and that we worked on a fix, but I
don't know if it got committed because I can't find the issue...
(To be clear, the problem here is the lack of whitespace at the start of the
folded par
R. David Murray added the comment:
In this case the docs are correct and the code has a bug. The intent was that
if the message passed in to BytesGenerator has a policy, that policy should be
followed. If it is not being followed, that's a bug in BytesGenerator. The
tricky part of c
R. David Murray added the comment:
Your backward compatibility argument is persuasive. As you say, that means the
BytesGenerate docs would need to be updated to note that that parameter is the
exception to the rule for backward compatibility reasons. (If it is the only
exception I have to
R. David Murray added the comment:
This is a duplicate of #44637.
--
resolution: -> duplicate
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Change by R. David Murray :
--
nosy: +thehesiod
title: Quoting issue on header Reply-To -> Quoting issue on header Reply-To and
other address headers
___
Python tracker
<https://bugs.python.org/issu
R. David Murray added the comment:
Yeah, I think there may be a general issue with getting header defects
reflected somehow in message.defects, but that's a separate issue :)
--
___
Python tracker
<https://bugs.python.org/is
David K. Hess added the comment:
Hi, I'm the author of the commit that's been fingered. Some comments about the
behavior being reported
First, as pointed out by @xtreak, indeed the mimetypes module uses mimetypes
files present on the platform to add to the built in list of mim
David K. Hess added the comment:
The documentation you quoted does read to me as compatible? The database it is
referring to is the one hardcoded in the module – not the one assembled from
that and the host OS. But, maybe this is just the vagaries of language and
perspective at play.
Anyway
R. David Murray added the comment:
More tests are always good :)
The "correct" solution here (as far as I remember, its has been a while since
I've had time to even looked at the _header_value_parser code) would be to add
a new 'invalid-msg-id' token, and
R. David Murray added the comment:
I haven't looked at this in detail, but here are my general thoughts: I think
it would be reasonable to expect that the module would function even if the
file permissions are screwed up, similar to how unix commands that try to read
.netrc will (t
R. David Murray added the comment:
Actually, the success path there should also check that value is empty, and if
it is not register a defect for that as well.
--
___
Python tracker
<https://bugs.python.org/issue38
R. David Murray added the comment:
The docs currently say "The returned object is a file-like object whose _file
attribute is either an io.BytesIO or io.StringIO object (depending on whether
binary or text mode was specified) or a true file object, depending on whether
rollover() has
R. David Murray added the comment:
Thanks for the report. Can you provide an example that reproduces the problem?
Per the RFC, lines may be broken before whitespace in certain places in certain
headers, but that does not make the whitespace go away. Only the crlf sequence
is removed
R. David Murray added the comment:
That header is *completely* non-RFC compliant. If gmail generated that header
there is something very wrong in google-land :(
The RFC compliant formatting for that header looks like this:
Content-Disposition: attachment;
filename*=utf-8''Schulb
R. David Murray added the comment:
Yes, google should fix their bug. However, the python email package tries very
hard to interpret even RFC-non-compliant emails when there is a way to do so.
As I said, the package already tries to interpret headers such as google is
generating, it's
R. David Murray added the comment:
And you are right that this is a very common bug in email programs. So common
that I suspect the RFC folks will eventually have to accept it as a de-facto
standard. So we do need to support it in the python email library
R. David Murray added the comment:
The example you want to look at is get_unstructured. That shows both lookback
and modification of the parse tree to handle the whitespace between encoded
words.
--
___
Python tracker
<https://bugs.python.
R. David Murray added the comment:
In general your solution looks good, just a few naming comments and an
additional test request.
--
___
Python tracker
<https://bugs.python.org/issue39
R. David Murray added the comment:
The problem is that you are starting with different inputs. unicode strings
and bytes are different things, and so parsing them can produce different
results. The fact of that matter is that email messages are defined to be
bytes, so parsing a unicode
R. David Murray added the comment:
All of which isn't to discount that you might have a found a bug, by the way,
if you want to investigate further :)
--
___
Python tracker
<https://bugs.python.org/is
R. David Murray added the comment:
Hmm. Yes, \r\n should be disallowed in the arguments to Address. I thought it
already was, so that's a bug. That bug produces the other apparent bug as
well: because the X: was treated as a separate line, the previous header did
not need double q
R. David Murray added the comment:
One more tweak to the test and we'll be good to go.
--
___
Python tracker
<https://bugs.python.org/issue39040>
___
___
R. David Murray added the comment:
Ideally this should be exposed by extending the content manager. Instantiating
MIME classes is part of the old API, not the new. The code in the PR may well
be correct, but class should be hidden from the normal user (of the new API).
I'm not sure
R. David Murray added the comment:
I don't see the change to the test in the PR. Did you miss a push or is github
doing something wonky with the review? (I haven't used github review in a
while and I had forgetten how hard it
R. David Murray added the comment:
Thanks for the ping. Whether or not Serhiy's patch fixed the original problem,
the algorithm rewrite has happened so this issue is no longer relevant in any
case.
--
stage: test needed -> resolved
status: open -
R. David Murray added the comment:
Are you saying there is no (http) RFC compliant way to fix this, or no way to
fix it with the email library parsers? If the latter, the library is pretty
flexible and for internal stdlib use it would probably be permissible to
directly call methods in the
R. David Murray added the comment:
Since you parsed it as a string it is not really legitimate to serialize it as
bytes. (That will work if the input message only contains ascii, but not if it
contains unicode). You'll get the same error if you replace the garbage with
the "
R. David Murray added the comment:
AFAIR it can only be done using the roundup command line on the server.
--
nosy: +ezio.melotti
___
Python tracker
<https://bugs.python.org/issue39
R. David Murray added the comment:
Thanks for the PR, but I've noted an issue on the review. In any case we
should agree on what goes in the repr here in this issue before actually
implementing anything.
--
___
Python tracker
&
R. David Murray added the comment:
Please open a new issue for this question.
--
___
Python tracker
<https://bugs.python.org/issue10740>
___
___
Python-bug
R. David Murray added the comment:
If we can get an actual reproducer using message_as_bytes I'd feel more
comfortable with the fix. I worry that there is some other bug this is
exposing that should be fixed instead.
--
___
Python tr
R. David Murray added the comment:
message_from_bytes
--
___
Python tracker
<https://bugs.python.org/issue39384>
___
___
Python-bugs-list mailing list
Unsub
R. David Murray added the comment:
I think you are saying that you want the charset in the encoded filename to be
GBK rather than utf-8? utf-8 should certainly display correctly in your email
client, though, so if it is not there is something else going wrong.
As far as the 3 tuple not
R. David Murray added the comment:
Actually, given that the contentmanager does accept a charset parameter for
text content, it does seem reasonable to treat this as a bug. But as I said
fixing it may not be trivial.
--
___
Python tracker
R. David Murray added the comment:
The legacy API appears to be using an RFC-incorrect (but common) encoded-word
encoding, while the new API is using the RFC-compliant MIME-parameter encoding
(% encoding). Which email client are you using
R. David Murray added the comment:
Since Outlook is one of the mailers that generates the non-RFC-compliant
headers, it doesn't surprise me all that much that it can't interpret the RFC
compliant headers correctly.
I'm not sure there is anything we can do here.
I suppose som
R. David Murray added the comment:
This is not actually a duplicate of 11783. Rereading (parts of) that issue, we
decided we currently have no good way to do automatic conversion between
unicode and internationalized domains, so the user of the library has to do it
themselves. This means
R. David Murray added the comment:
I don't object to this patch, but that sure looks like a broken system.
--
___
Python tracker
<https://bugs.python.org/is
R. David Murray added the comment:
I actually agree: if most (by market share) MUAs handle the RFC-incorrect
parameter encoding style, and a significant portion does not handle the RFC
correct style, then we should support the de-facto standard rather than the
official standard as the
R. David Murray added the comment:
You are welcome to open a doc-enhancement issue for the global docs. For the
other, as noted already if you want to advocate for a change to this behavior
you need to start on python-ideas, but I don't think you will get any traction.
Another pos
R. David Murray added the comment:
Thanks for the PR. I've made some review comments.
--
___
Python tracker
<https://bugs.python.org/issue39073>
___
___
R. David Murray added the comment:
My guess is that it isn't so much that __bool__ is special, as that the
evaluation of values in a boolean context is special. What you have to do to
make a mock behave "correctly" in the face that I'm not sure (I haven't
inves
R. David Murray added the comment:
New changeset 614f17211c5fc0e5b828be1d3320661d1038fe8f by Ashwin Ramaswami in
branch 'master':
bpo-39073: validate Address parts to disallow CRLF (#19007)
https://github.com/python/cpython/commit/614f17211c5fc0e5b828be1d332066
R. David Murray added the comment:
Thanks!
--
___
Python tracker
<https://bugs.python.org/issue39073>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by R. David Murray :
--
stage: patch review -> backport needed
___
Python tracker
<https://bugs.python.org/issue39073>
___
___
Python-bugs-list mai
David K. Hess added the comment:
I’m not sure I can shed any light on this particular bug, but I would say that
based on my dealings with this module, it is definitely not thread-safe. That
means that if you are going to have multiple threads accessing it
simultaneously, you really should
R. David Murray added the comment:
Yeah, that looks like a bug in the old API. If you try the new API, it does
the right thing. To do that, import email.policy and make your
message_as_string call:
email.message_from_string(raw, policy=email.policy.default)
Note, however, that you
R. David Murray added the comment:
As far as I know you currently still have to specify the policy. It was, yes,
intended that 'default' become the actual default. I could have sworn there
was an open issue for doing this, but I can't find it. I remember having a
co
R. David Murray added the comment:
The PR looks good to me, but I describe the change differently. I'm not sure
how I missed this in the original implementation, since I obviously checked it
for the 8bit case. Too long ago to rem
R. David Murray added the comment:
New changeset 6f2f475d5a2cd7675dce844f3af436ba919ef92b by Arkadiusz Hiler in
branch 'master':
bpo-40597: email: Use CTE if lines are longer than max_line_length consistently
(gh-20038)
https://github.com/python/cpyt
R. David Murray added the comment:
Thanks, Arkadiusz.
--
resolution: -> fixed
stage: patch review -> backport needed
versions: -Python 3.5, Python 3.6, Python 3.7
___
Python tracker
<https://bugs.python.org/i
R. David Murray added the comment:
New changeset c1f1ddf30a595c2bfa3c06e54fb03fa212cd28b5 by Miss Islington (bot)
in branch '3.8':
bpo-40597: email: Use CTE if lines are longer than max_line_length consistently
(gh-20038) (gh-20084)
https://github.com/python/cpyt
Change by R. David Murray :
--
stage: backport needed -> resolved
___
Python tracker
<https://bugs.python.org/issue40597>
___
___
Python-bugs-list mai
R. David Murray added the comment:
Yep, you've found another in a category of bugs that have shown up in the
parser: places where there is a missing check for there being any value at all
before checking character [0].
In this case, the fix should be to add
if not obs_local
R. David Murray added the comment:
After thinking about it some more, I think given that when there is no
non-ascii mbox will happily treat *anything* as valid on the "From " line, that
we should consider blowing up on non-ascii t
R. David Murray added the comment:
This has nothing to do with python other than the fact that you are using it to
capture stdout. You have to figure out how to get the output you want to be
what shows up on stdout, python has no knowledge of what commands you put in
your shell script, and
R. David Murray added the comment:
The return value is correct. Interpreted as an email address, 'randomstring'
is a local mailbox.
--
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Pyt
R. David Murray added the comment:
New changeset 21017ed904f734be9f195ae1274eb81426a9e776 by Abhilash Raj in
branch 'master':
bpo-39040: Fix parsing of email mime headers with whitespace between
encoded-words. (gh-17620)
https://github.com/python/cpyt
R. David Murray added the comment:
If you use the 'sendmail' function for sending, then it is entirely your
responsibility to turn the email into "wire format". Unicode is not wire
format, but if you give sendmail a string that only has ascii in it it nicely
converts
R. David Murray added the comment:
I'm short of time, if someone could approve Mark's PR and merge it it would be
great. There wasn't supposed to be any behavior change other than the one
documented in #40597.
--
___
Python
R. David Murray added the comment:
The as_strings docs say:
"Flattening the message may trigger changes to the Message if defaults need to
be filled in to complete the transformation to a string (for example, MIME
boundaries may be generated or modified)."
So, while this is ind
David K. Hess added the comment:
@michael-lazar a documentation change seems the path of least resistance given
the complicated history of this module. +1 from me.
--
___
Python tracker
<https://bugs.python.org/issue38
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:
The fix looks good to me. Don't know how I made that mistake, and obviously I
didn't write a test for it...
--
___
Python tracker
<https://bugs.python.o
R. David Murray added the comment:
It's not really an abuse. It is, however, buggy. It should be being applied
*only* when the header contains unstructured text. Unfortunately I made the
choice to treat any header that doesn't have a specific parser as unstructured,
and that w
R. David Murray added the comment:
Yes for the registry changes. I thought we had fixed the bug that was causing
message-id to get encoded, but maybe it still exists in 3.7? I don't remember
when we fixed it (and I may be remembering wrong!)
As for X- "unstructured header
R. David Murray added the comment:
The problem with that archive is that it is not in proper mbox format. It
contains the following line (5689):
From here I was hoping to run something like “dbus-send –system
–dest=Test.Me –print-reply /Japan Japan.Reset.Test string:”Hello””
You will
4501 - 4600 of 12944 matches
Mail list logo
