Changes by Brandon Rhodes <bran...@rhodesmill.org>:
--
type: -> enhancement
___
Python tracker <rep...@bugs.python.org>
<http://bugs.pyt
Brandon Rhodes added the comment:
Another important objection against the current text is that it stacks a series
of `and` and `or` operators at the same level of indentation, as though they
naturally evaluate in the order the programmer writes them. In fact, they have
different levels
Changes by Brandon Rhodes <bran...@rhodesmill.org>:
Added file: http://bugs.python.org/file42489/pep8-knuth.patch
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Changes by Brandon Rhodes <bran...@rhodesmill.org>:
Removed file: http://bugs.python.org/file42487/pep8-knuth.patch
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
New submission from Brandon Rhodes:
I am delighted to see that PEP-8 has pivoted to breaking long formulae before,
rather than after, each binary operator! But I would like to pivot the PEP away
from citing my own PyCon Canada talk as the authority on the matter, and toward
citing Knuth
Brandon Rhodes added the comment:
Now that I am back at a full keyboard, I see that my previous response
to @BreamoreBoy about this issue is too short and too cryptic to really
serve as a fair answer to his question. And, with some embarrassment, I
note that my words did not even achieve
New submission from Brandon Rhodes:
There was an old document in the howto folder whose advice was in many cases
flat-out wrong, so Raymond Hettinger performed a wonderful public service by
deleting it back in 2011:
http://hg.python.org/cpython/rev/80ff78425419
Unfortunately it looks like
Changes by Brandon Rhodes bran...@rhodesmill.org:
--
assignee: - docs@python
components: +Documentation
nosy: +docs@python
versions: +Python 3.4
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21956
Brandon Rhodes added the comment:
The question of whether the document ought to be removed is not at issue here.
The document was already deleted, in 2011, by Raymond Hettinger, with the
consent of its author. I told that story merely as background.
The issue here is that the Python web site
Brandon Rhodes added the comment:
I do not find it unreasonable, on a page of Python idioms, the we would call an
example that explicitly says Don't in its title an anti-idiom.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
New submission from Brandon Rhodes:
Content-Disposition is an optional header field. In its absence, the MUA may
use whatever presentation method it deems suitable. — RFC 2183
The email.message.Message class should gain a get_content_disposition() method
with the three possible return values
Brandon Rhodes added the comment:
Thanks — done! http://bugs.python.org/issue21083
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21079
New submission from Brandon Rhodes:
I love properties and think they should be everywhere. But consistency is more
important, so I suspect that EmailMessage.is_attachment should be demoted to a
normal method. Why? Because if it remains a property then I am likely to first
write
New submission from Brandon Rhodes:
Currently, the new wonderful EmailMessage class ignores the encoding specified
in any Header objects that are provided to it.
import email.message, email.header
m = email.message.Message()
m['Subject'] = email.header.Header('Böðvarr'.encode('latin-1
New submission from Brandon Rhodes:
In Python 3, fileinput.input() returns str lines whether the data is
coming from stdin or from a list of files on the command line. But if
input(mode='rb') is specified, then its behavior becomes inconsistent:
lines from stdin are delivered as already-decoded
New submission from Brandon Rhodes:
Most attachments (in my inbox, at least) specify a filename, and thus
have a Content-Disposition header that looks like:
Content-Disposition: attachment; filename=attachment.gz
In fact, this sample header was generated by the new add_attachment()
method
Brandon Rhodes added the comment:
Oh - this also, happily, explains why iter_attachments() is ignoring
all of the attachments on my email: because it internally relies upon
is_attachment to make the decision. So this fix will also make
iter_attachments() usable
Brandon Rhodes added the comment:
Okay, having looked at the source a bit more it would probably make
more sense to use _splitparam() instead of doing the split manually.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21079
Brandon Rhodes added the comment:
Given that methods like get_param() already exist for pulling data out of
the right-hand-side of the ';' in a parameterized email header, would it
be amiss for EmailMessage to also have a method that either returns
everything to the left of the semicolon
Brandon Rhodes added the comment:
Understood. I wonder where in the documentation the ability to get the content
disposition should wind up? I am almost tempted to suggest a
get_content_disposition() method that parallels get_content_type(), mostly to
avoid having to document the asymmetry
Brandon Rhodes added the comment:
I agree that is_attachment supports the most common use-case of people who need
to inspect the content disposition!
But people implementing heavyweight tools and email clients might additionally
need to distinguish between a MIME part whose disposition
New submission from Brandon Rhodes:
Regular expression re.MatchObject objects are sequences.
They contain at least one “group” string, possibly more,
which are integer-indexed starting at zero.
Today, groups can be accessed in one of two ways.
(1) You can call the method match.group(N).
(2
Changes by Brandon Rhodes bran...@rhodesmill.org:
--
versions: +Python 3.4 -Python 3.5
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19536
23 matches
Mail list logo
