Petri Lehtinen added the comment:
The 3.x patch looks good to me.
What comes to the 2.7 patch, there's at least the problem with fmtparam in the
csv module (should be **fmtparams instead of [, fmtparam]). And that's were I
stopped reviewing, so there may also be other errors.
Petri Lehtinen added the comment:
os.utime() uses the same notation:
os.utime(path[, times, *, ns=(atime_ns, mtime_ns)])
--
nosy: +petri.lehtinen
title: os.utimensat's method description uses wrong notation -> Descriptions of
os.utime() and os.utimensat() use wrong
Petri Lehtinen added the comment:
I found two more: P_NOWAITO and _exit. Attached an updated patch.
--
Added file: http://bugs.python.org/file25662/issue14862_v2.patch
___
Python tracker
<http://bugs.python.org/issue14
Petri Lehtinen added the comment:
I verified from the source that it should be **fmtparams also in 2.7. Make sure
you change the description texts, too, to s/fmtparam/fmtparams/.
--
nosy: +petri.lehtinen
___
Python tracker
<http://bugs.python.
Petri Lehtinen added the comment:
Fixed in default and 3.2 branches, which are quite similar. Thanks for the
patch!
Closing now. Feel free to reopen if you want to provide a patch for the 2.7
branch, too.
--
resolution: -> fixed
status: open -> closed
versions: +Python 3.2,
Petri Lehtinen added the comment:
Ben,
As I've said, I think that we should go for the documented behavior with the
addition of not allowing braces inside the format string (with the exception of
format_spec).
So AFAICS, index_string would become
index_string ::= +
> Anyway
Petri Lehtinen added the comment:
Nobody's really sure whether it's safe to remove, so let it be there. Leaving
it can be justified by symmetry with _get_kwargs. Closing.
--
resolution: -> wont fix
stage: -> committed/rejected
status
Petri Lehtinen added the comment:
Still waiting for the info about whether this can be done at run-time.
--
status: open -> pending
___
Python tracker
<http://bugs.python.org/issu
Petri Lehtinen added the comment:
Both patches LGTM.
--
nosy: +petri.lehtinen
___
Python tracker
<http://bugs.python.org/issue13934>
___
___
Python-bugs-list m
Changes by Petri Lehtinen :
--
nosy: +petri.lehtinen
___
Python tracker
<http://bugs.python.org/issue11685>
___
___
Python-bugs-list mailing list
Unsubscribe:
Petri Lehtinen added the comment:
Ben Wolfson wrote:
> Maybe, but the last time it went to python-dev (in December) there
> was little discussion at all, and the patches that exist now worked
> on the codebase as it existed then.
Maybe it's pointless to bring it up on python-de
Petri Lehtinen added the comment:
Ok. Closing as wontfix then.
--
resolution: -> wont fix
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Petri Lehtinen added the comment:
poq: I see you have submitted a few other patches to the tracker, too. For us
to be able to use your patches, you should sign the PSF Contributor Agreement
as described here: http://www.python.org/psf/contrib
Changes by Petri Lehtinen :
--
title: fdopen not listed in __all__ of os.py -> os.__all__ is missing some names
___
Python tracker
<http://bugs.python.org/issu
Changes by Petri Lehtinen :
--
resolution: -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Changes by Petri Lehtinen :
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue14863>
___
___
Python-bugs-list
Petri Lehtinen added the comment:
I added some comments on rietveld. These are only nit-picking about style and
mostly reflect my personal taste, not show stoppers in any case.
--
___
Python tracker
<http://bugs.python.org/issue12
Petri Lehtinen added the comment:
No SQL library that I know of provides a way to escape table names. The quoting
functions are always meant to escape string parameters. This is true for
sqlite3_mprintf(), too (the %q and %Q options).
If you build table names from user input, your database
Changes by Petri Lehtinen :
--
nosy: +petri.lehtinen
___
Python tracker
<http://bugs.python.org/issue9544>
___
___
Python-bugs-list mailing list
Unsubscribe:
Petri Lehtinen added the comment:
Can this be closed?
--
nosy: +petri.lehtinen
___
Python tracker
<http://bugs.python.org/issue12354>
___
___
Python-bugs-list m
Changes by Petri Lehtinen :
--
status: open -> pending
___
Python tracker
<http://bugs.python.org/issue12354>
___
___
Python-bugs-list mailing list
Unsubscri
Changes by Petri Lehtinen :
--
nosy: -petri.lehtinen
___
Python tracker
<http://bugs.python.org/issue12354>
___
___
Python-bugs-list mailing list
Unsubscribe:
Petri Lehtinen added the comment:
I see one obvious issue with the patch: The ConversionErrors it creates are
passed the struct.error or TypeError instance as a parameter. The first
argument of these exceptions would be better, i.e.
try:
...
except struct.error as e:
raise
New submission from Petri Lehtinen :
In the description of section 16.2.2. Lock objects:
If an attempt is made to release an unlocked lock, a RuntimeError
will be raised.
In the description of Lock.release():
When invoked on an unlocked lock, a ThreadError is raised.
Apparently
Changes by Petri Lehtinen :
--
versions: +Python 3.2, Python 3.3
___
Python tracker
<http://bugs.python.org/issue15017>
___
___
Python-bugs-list mailing list
Unsub
Petri Lehtinen added the comment:
The docs of 2.7 and 3.2 still first say that RuntimeError is raised, and then
that a ThreadError is raised:
...
If an attempt is made to release an unlocked lock, a RuntimeError
will be raised.
...
Lock.release()
...
When invoked on
Petri Lehtinen added the comment:
Attached a patch against 3.2. It reflects the facts that pack_fstring and
pack_fopaque are the same methd, and pack_string, pack_opaque and pack_bytes
are the same method.
--
versions: +Python 3.2, Python 3.3 -Python 3.1
Changes by Petri Lehtinen :
Added file: http://bugs.python.org/file25849/issue9544.patch
___
Python tracker
<http://bugs.python.org/issue9544>
___
___
Python-bugs-list m
New submission from Petri Lehtinen :
test_mbox is an mbox mailbox with a few messages in it.
>>> import mailbox
>>> inbox = mailbox.mbox('test_mbox')
>>> inbox.lock()
>>> inbox.popitem()
(0, )
>>> inbox.flush()
>>> inbox.unl
Petri Lehtinen added the comment:
Actually, you don't even need to unlock() and lock() the mailbox before the
second popitem() and flush().
--
___
Python tracker
<http://bugs.python.org/is
Petri Lehtinen added the comment:
The fix seems to be very simple:
diff --git a/Lib/mailbox.py b/Lib/mailbox.py
index a677729..2be4c83 100644
--- a/Lib/mailbox.py
+++ b/Lib/mailbox.py
@@ -675,6 +675,7 @@ class _singlefileMailbox(Mailbox):
new_file.write(buffer
Petri Lehtinen added the comment:
For example, Django uses time independent comparison to compare signatures of
signed cookies. A signed cookie consists of a plain-text value followed by a
signature.
An attacker wants to construct a cookie that has a malformed value and a valid
signature
Petri Lehtinen added the comment:
As I suspected, all single-file mailboxes(mbox, MMDF, Babyl) have this issue.
Attached a patch with tests.
--
keywords: +patch
Added file: http://bugs.python.org/file26017/issue15036.patch
___
Python tracker
<h
Changes by Petri Lehtinen :
--
resolution: -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Petri Lehtinen added the comment:
Yes, this is what I tried to say. It's hard for me to find a good
wording, so what would you suggest?
I also noticed now that there's a typo in the commit messages. But
those cannot be fixed anymore.
--
Petri Lehtinen added the comment:
Perfect, fixed.
--
___
Python tracker
<http://bugs.python.org/issue15036>
___
___
Python-bugs-list mailing list
Unsubscribe:
Petri Lehtinen added the comment:
This is actually not true. When calling add(), mbox (and MMDF and Babyl) append
the message to the file without rewriting it.
It's the following flush() call that rewrites the whole mailbox contents. I
think this could be changed to work correctly b
Changes by Petri Lehtinen :
--
nosy: +petri.lehtinen
___
Python tracker
<http://bugs.python.org/issue1590744>
___
___
Python-bugs-list mailing list
Unsubscribe:
Petri Lehtinen added the comment:
Can this be closed?
--
nosy: +petri.lehtinen
___
Python tracker
<http://bugs.python.org/issue7360>
___
___
Python-bugs-list m
Changes by Petri Lehtinen :
--
nosy: +petri.lehtinen
___
Python tracker
<http://bugs.python.org/issue5346>
___
___
Python-bugs-list mailing list
Unsubscribe:
Petri Lehtinen added the comment:
Every program that accesses mailboxes in the system-wide mail spool directory
needs to have write access to it. This is because dot-locking is achieved by
creating additional files to that directory, and it must be used (in addition
to fcntl() locking) to
New submission from Petri Lehtinen :
http://docs.python.org/devguide/triaging.html#components
The undocumented components are:
- None
- Cross-Build
- email
--
components: Devguide
messages: 163321
nosy: ezio.melotti, petri.lehtinen
priority: normal
severity: normal
status: open
title
New submission from Petri Lehtinen :
This seems like a common feature request. Many people suffer from the fact that
upon flush, the contents of single-file mailboxes are written into a new file
which is then renamed over the old file.
For example: #1599254, #5346, #7359, #7360, #9559,
The
Changes by Petri Lehtinen :
--
components: +email
nosy: +barry, r.david.murray
___
Python tracker
<http://bugs.python.org/issue15122>
___
___
Python-bugs-list m
Changes by Petri Lehtinen :
--
nosy: +petri.lehtinen
versions: +Python 3.4 -Python 3.3
___
Python tracker
<http://bugs.python.org/issue13698>
___
___
Python-bug
Petri Lehtinen added the comment:
I actually already researched mutt 1.5.21 (on Ubuntu), and it seems to
overwrite the file in-place. At least the inode number doesn't change when I
append and/or delete files from an mbox file and sa
Petri Lehtinen added the comment:
Now I also tested rmail (the Emacs email client). It seems to write-and-rename,
at least the inode number changes. It seems to even use the mboxo format
nowadays (used to use Babyl).
--
___
Python tracker
<h
Petri Lehtinen added the comment:
Alpine (the successor of pine) also seems to overwrite in-place, just like mutt.
--
___
Python tracker
<http://bugs.python.org/issue15
Petri Lehtinen added the comment:
I looked at the source code of mutt to see how it rewrites mbox files. It does
roughly this:
1. Block some signals.
2. Lock the mbox file (with dotlock, fcntl and flock).
3. Create a temporary file in /tmp.
4. Write messages to the temporary file, from the
Petri Lehtinen added the comment:
I'm a little concerned about backwards compatibility. Someone might get upset
if extra >'s start appearing in the messages when they read the mailbox
contents with an application that uses the mboxo format.
A little analysis on the possible cor
Petri Lehtinen added the comment:
It seems to me that "^From " is the correct way to match the start of each
message. This is also what the qmail manual page (linked in the previous
message) says. So closing as invalid.
--
nosy: +petri.lehtinen
resolution: -> invali
Petri Lehtinen added the comment:
Actually, you're right. Sorry for overlooking the RFC. But that said, the RFC
itself refers to the same manpage as a reference that's "mostly authoritative
for those variations that are otherwise only documented in anecdotal form". So
Petri Lehtinen added the comment:
The default mode for reading mbox files should also be modified a bit to
maximize the support fordifferent implementations. See #11728.
I think we should still use the mboxo format by default when writing, and the
"default" format of RFC 4155 wh
Petri Lehtinen added the comment:
endolith wrote:
> > - If the mailbox is written using the mboxrd format and read using
> > - the mboxo format, lines that were meant to start with ">From "
> > - are changed to ">>>From ". This is a new type
Petri Lehtinen added the comment:
It seems to me that there are three separate issues here:
1) Concurrent access to a single-file mailbox will discard some messages even
if locking is correctly used. This is demonstrated by mailbox-test.patch, which
despite its age applies on top of 3.2 and
Petri Lehtinen added the comment:
I created #15122 for adding an option to rewrite the contents of single-file
mailboxes in-place. Closing this issue as wontfix.
--
resolution: -> wont fix
stage: -> committed/rejected
status: open -> closed
superseder: -> Add an opti
Petri Lehtinen added the comment:
Attached a patch. It copies the mode of the original mailbox file to the new
file on flush().
--
components: +email
keywords: +patch
nosy: +barry, r.david.murray
stage: test needed -> patch review
versions: +Python 3.3 -Python 3.1
Added file: h
Petri Lehtinen added the comment:
Attached a patch that doesn't rewrite+rename if messages have only been added.
In this case, flush() only syncs the mailbox file to make sure all changes have
been written to disk.
David & Barry: what do you think about including this on bugfix
Petri Lehtinen added the comment:
This happens because you modify the list while iterating over it, which makes
the loop not work as you expect. Essentially, when you remove the item that's
currently being pointed to, the loop skips over the next item.
An idiomatic way to remove items f
Petri Lehtinen added the comment:
Fixed. I removed the extra newlines.
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/
Petri Lehtinen added the comment:
See #15122 for always modifying single-file mailboxes in-place.
--
___
Python tracker
<http://bugs.python.org/issue9
Petri Lehtinen added the comment:
I had exactly the same error on 3.3b1 when running the test suite with
randomized order.
--
nosy: +petri.lehtinen
___
Python tracker
<http://bugs.python.org/issue13
Petri Lehtinen added the comment:
The _pre_mailbox_hook may be called twice, like this:
babyl = mailbox.Babyl('new_file')
babyl.add('foo\n')
babyl.remove(0)
babyl.add('bar\n')
This only affects Babyl, that writes the mailbox header in _pre_mailbox_hook.
The mail
Changes by Petri Lehtinen :
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.o
Petri Lehtinen added the comment:
I cannot reproduce this on 3.2 or 2.7. My mailboxes always have an ending
newline if the last message also has it. Only if the last message doesn't end
in a newline, there's no newline in the end of the mbox. Furthermore, if a
message doesn&#x
Petri Lehtinen added the comment:
Fixed.
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.o
Petri Lehtinen added the comment:
Since there's no empty line between the content of mail 2 and the "From " line
of mail 3, the body of mail 2 isn't really terminated by a newline. Reading the
message confirms this:
>>> import mailbox
>>> mbox = mailbo
Petri Lehtinen added the comment:
I'm afraid that's not enough details to do any fixing. I would need a concrete
way to reproduce the issue.
--
status: open -> pending
___
Python tracker
<http://bugs.pytho
Petri Lehtinen added the comment:
Hi and thanks for the report. It seems that this is a bug in
email.generator.Generator, as it fails to mangle "From " lines in the MIME
preamble (after the headers, before the first "--Boundary..." line).
--
components:
Petri Lehtinen added the comment:
This might be the only way to fix #1599254, see
http://bugs.python.org/issue1599254#msg30590. If another program is waiting on
the fcntl lock (and doesn't use dotlocking), as soon as mailbox.py closes the
original file (to replace it with a new file
Petri Lehtinen added the comment:
Some thoughts on doing "clever tricks" to enhance mbox parsing:
http://www.jwz.org/doc/content-length.html
--
___
Python tracker
<http://bugs.python.o
New submission from Petri Lehtinen :
The _handle_text function of BytesGenerator writes the payload straight through
if there surrogateescape sequences are present, and skips the "From " mangling.
--
components: email
messages: 164641
nosy: barry, petri.lehtinen, r.da
Petri Lehtinen added the comment:
Attached a test case that fails.
--
keywords: +patch
Added file: http://bugs.python.org/file26258/issue115249_test.patch
___
Python tracker
<http://bugs.python.org/issue15
Petri Lehtinen added the comment:
Well, by appending newmail to the mailbox, you effectively break the
next-to-last message by not inserting a newline after it. This can also be
achieved by adding a message that doesn't end in a newline to the mbox (using
the mailbox module).
The rea
Petri Lehtinen added the comment:
My 4) actually meant that it should always return []. This is what it currently
does, so it could be spelled out clearly in the code.
IIRC, getallmatchingheaders() cannot be emulated one-to-one using get_all(),
because it handles continuation lines
Petri Lehtinen added the comment:
The CGIHTTPRequestHandler fix and test would be the best thing to start with,
though, as it's not related to the eventual fate of getallmatchingheaders().
--
stage: -> needs patch
___
Python tracke
Petri Lehtinen added the comment:
MDAs blindly write their message to the end of the user's mail spool file. So,
if there's no newline at the end, the mailbox gets corrupted (the new message
is "joined" with the previous one).
I tested with Postfix, but this probably hap
Petri Lehtinen added the comment:
Thanks. The news entry should probably say 'From ' instead of 'From'.
--
___
Python tracker
<http://bug
Petri Lehtinen added the comment:
Thinking about this again, I guess the original design rationale was not to
prepare for crashes, but for the ease of implementation. It's not generally
possible to rewrite the mailbox fully in-place, because the messages are not
loaded into memory. I
Petri Lehtinen added the comment:
This happens because of a bug in Babyl._install_message(). When adding a
message from file, the "*** EOOH ***" line is written also after the second set
of headers.
--
nosy: +petri.lehtinen
___
Pyth
Changes by Petri Lehtinen :
--
resolution: -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Changes by Petri Lehtinen :
--
versions: +Python 2.7
___
Python tracker
<http://bugs.python.org/issue11062>
___
___
Python-bugs-list mailing list
Unsubscribe:
Petri Lehtinen added the comment:
Yeah. Enabling the Babyl tests discovered yet another bug on a code path that
wasn't excercised at all. I'll fix it.
--
assignee: -> petri.lehtinen
resolution: fixed ->
___
Python tracker
<htt
Petri Lehtinen added the comment:
Tests are now passing on Windows, too. Closing.
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/i
Petri Lehtinen added the comment:
Any reason why this hasn't been backported to 3.2 or 2.7?
--
nosy: +petri.lehtinen
___
Python tracker
<http://bugs.python.org/i
Petri Lehtinen added the comment:
No reply in two years, closing.
--
nosy: +petri.lehtinen
resolution: -> invalid
status: open -> closed
___
Python tracker
<http://bugs.python.org/
Petri Lehtinen added the comment:
Sounds like a bug to me.
It's not too straightforward to fix, though. The order of MIME types is lost
because they are stored as keys of a dict. AFAICS, it wouldn't help to use
OrderedDict and checking for the wildcard type first if its index
Changes by Petri Lehtinen :
--
keywords: -easy
___
Python tracker
<http://bugs.python.org/issue14977>
___
___
Python-bugs-list mailing list
Unsubscribe:
Petri Lehtinen added the comment:
The encode() and decode() functions also expect binary file objects.
Attached a patch that changes documentation and docstrings. Removed the
mentions of readline(), because read() is called on input instead, if the
binascii module is available. Also removed
Petri Lehtinen added the comment:
+ print(c.fetchone())
I don't think this line should be added because it's not there after the first
select.
--
nosy: +petri.lehtinen
___
Python tracker
<http://bugs.python.o
Petri Lehtinen added the comment:
Fixed, thanks for the patch.
--
nosy: +petri.lehtinen
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Petri Lehtinen added the comment:
Using the word "scalar" sounds wrong to me. Are strings really considered
scalars in Python? At least RFC 4627 doesn't talk about scalars.
+Since the RFC permits RFC-compliant parsers to accept input texts that are not
+RFC-compliant
Petri Lehtinen added the comment:
I think skipping preceding whitespace in raw_decode() wouldn't hurt, but
skipping following whitespace would be wrong.
David: Any examples of how this could break backwards compatibility?
--
nosy: +petri.leh
Petri Lehtinen added the comment:
The strict flag sounds good to me, too. I don't think it should be called
"strict" though, as that would imply that we comply with RFC 4627 strictly
(which is not true without passing allow_nan=False for dump() or passing a
parse_constant fu
Petri Lehtinen added the comment:
The patch looks good to me and seems to fix my test case. I find the email code
somewhat complicated, so I'll let David decide whether it's the correct fix :)
--
stage: needs patch -> patch review
___
P
Petri Lehtinen added the comment:
Attaching two patches.
Patch 1 changes the common message template in mailbox tests to end in a
newline. If this wasn't done, more or less all common mailbox tests would have
to be special cased for mbox.
Patch 2 adds a single blank line after each me
Changes by Petri Lehtinen :
--
keywords: +needs review
stage: -> patch review
Added file:
http://bugs.python.org/file26999/issue15222_v1_0002_insert_blank_after_each_message_in_mbox.patch
___
Python tracker
<http://bugs.python.org/issu
Petri Lehtinen added the comment:
It seems to me that when ensure_ascii is False, the return value will be a
unicode instance if and only if there's a unicode object anywhere in the input.
>>> json.dumps({'foo': 'bar'}, ensure_ascii=False)
'{"
Petri Lehtinen added the comment:
Chris: Thanks for the patch. I'm not sure register_dialect()'s signature is
good like that, though. Hynek, what do you think?
--
stage: -> patch review
___
Python tracker
<http://bugs.pytho
Petri Lehtinen added the comment:
I don't think the test changes are needed, because both dump() and dumps() use
JSONEncoder internally, and all current indent testing is done using dumps()
anyway.
More important would be to update the documentation of indent for JSONEncoder
to match th
401 - 500 of 601 matches
Mail list logo
