R. David Murray added the comment:
Gah, I messed up the push. Now I have to backport the doc fix :(
--
___
Python tracker
<http://bugs.python.org/issue7
Changes by R. David Murray :
--
assignee: skip.montanaro -> r.david.murray
status: closed -> open
___
Python tracker
<http://bugs.python.org/issue7198>
___
__
R. David Murray added the comment:
OK, now it's really done (I hope!).
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue7198>
___
David-Sarah Hopwood added the comment:
(For anyone wondering about the hold-up on this bug, I ended up switching to
Ubuntu. Not to worry, I now have Python 3 building in XP under VirtualBox --
which is further than I ever got with my broken Vista install :-/ It seems to
behave identically to
R. David Murray added the comment:
Thanks, Michael! I tweaked the patch slightly: deleted that
test-writing-helper check you had marked with the XXX, and renamed the helper
test methods to _test_XXX. I also didn't wind up applying it to 2.7 because hg
doesn't support merge ma
Changes by R. David Murray :
--
assignee: -> r.david.murray
stage: -> patch review
type: -> behavior
versions: +Python 2.7, Python 3.1, Python 3.2, Python 3.3
___
Python tracker
<http://bugs.python.or
R. David Murray added the comment:
Thanks again, Michael.
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
R. David Murray added the comment:
Michael, in general your approach looks sound and is much easier to read and
comprehend than the original code (which, as the comments say, was never
refined from the original quick and dirty hack). However, rather than
dynamically defining sub-functions
New submission from R. David Murray :
Example:
http://www.python.org/dev/buildbot/all/builders/x86%20FreeBSD%207.2%203.x/builds/1609/steps/test/logs/stdio
==
FAIL: test_source (test.test_collections.TestNamedTuple
R. David Murray added the comment:
I needed an airplane-trip-sized problem to work on on the way back from PyCon
and the sprints, so I tried my hand at "fixing" this. The attached patch is
really just a proof of concept. Because it is so invasive of the email package
machinery I
Changes by R. David Murray :
--
versions: -Python 2.7, Python 3.1, Python 3.2
___
Python tracker
<http://bugs.python.org/issue975330>
___
___
Python-bugs-list m
R. David Murray added the comment:
Yes there is a delay. The cron job that creates the link runs every two
minutes. Not sure why the delay seems to be longer than that, though.
--
nosy: +r.david.murray
___
Python tracker
<http://bugs.python.
R. David Murray added the comment:
I turns out that issue 5803 has a patch that also fixes this bug, and the
algorithm used there is even more efficient than the one you've developed here.
However, it is also not compatible with the email5 version of quoprimime. It
could be adapted,
Changes by R. David Murray :
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
R. David Murray added the comment:
Thanks. Shortened patch by using the fact that os.path.join returns the second
component if it is absolute, as discussed on IRC.
--
nosy: +r.david.murray
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> cl
R. David Murray added the comment:
Made the same change to the usage of os.path.join.
--
nosy: +r.david.murray
resolution: -> accepted
stage: patch review -> committed/rejected
status: open -> closed
type: -> feature request
___
Py
Changes by R. David Murray :
--
resolution: -> accepted
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
David-Sarah Hopwood added the comment:
I wrote:
> The only caveat would be that if you write a partial line to the buffer
> object (or if you set the buffer object to be fully buffered and write to
> it), and then write to the text stream, the buffer wouldn't be flushed before
David-Sarah Hopwood added the comment:
I wrote:
$ python3 -c 'import sys; sys.stdout.write("foo");
sys.stdout.buffer.write(b"bar"); sys.stdout.write("baz\n")'
barfoobaz
Hmm, the behaviour actually would differ here: the proposed implementation
wou
David-Sarah Hopwood added the comment:
Glenn Linderman wrote:
> Presently, a correct application only needs to flush between a sequence of
> writes and a sequence of buffer.writes.
Right. The new requirement would be that a correct app also needs to flush
between a sequence of buffer.
R. David Murray added the comment:
Antoine wrote:
> Do you want to keep track of the specificities of each version of the *BSDs?
Currently regrtest does, but they are currently all set to the same list of
tests. Perhaps a FreeBSD generic that implies all versions, and then if we
ever hav
R. David Murray added the comment:
Thinking about this some more, I now think it is incorrect that an 8bit header
causes getitem to return a Header object. I think instead it should be
returning the stringified version of the header, including the unknown-8bit
encoding. That way
R. David Murray added the comment:
It is reasonably likely that the attached patch will fix this. It also removes
3 seconds of fixed overhead from the test.
--
keywords: +patch
nosy: +r.david.murray
stage: -> patch review
versions: +Python 2.7, Python 3.1, Python 3.3
Added f
R. David Murray added the comment:
I documented that? Where?
It is true that the fact that all headers will be objects when using the email6
API was one reason I did it this way, but in hindsight I don't think it was the
right choice. However, I/we may now be stuck with it, in which
R. David Murray added the comment:
Heh.
OK, so I think we're stuck with it, then. It does mean I don't have to handle
certain other edge cases, and can punt more convenient handling of them into
email6. I'll make the patch for decode_heade
R. David Murray added the comment:
OK, here is the patch.
--
keywords: +patch
Added file: http://bugs.python.org/file21392/decode_Header.patch
___
Python tracker
<http://bugs.python.org/issue11
R. David Murray added the comment:
Theoretically there should be no way to get bytes into that code path. I'm
sure there's a way if you try hard enough (I haven't tried directly assigning a
byte string as a header value, for example), but they would be broken uses of
the AP
R. David Murray added the comment:
That could be, certainly. The code is depending on the mtime having a
resolution of at least one second. Try making the constant 61 instead of 60.
If that doesn't work, try putting the mtime back a lot farther and see if that
makes it work If it p
R. David Murray added the comment:
Hmm. You are right, I wasn't thinking clearly, and I copied that mtime setting
call from another test. Now I have no idea why 61 would work, unless the clock
between your virthost and your smb server is off by a m
R. David Murray added the comment:
Could you print out the mtime values that are being set, and the value of
self._mbox._last_read? Or, rather, print out the result of calls to
os.path.getmtime on the two directories after the mtime is changed
R. David Murray added the comment:
Hmm. 411-61=350. Three seconds difference looks a little odd. But doesn't
explain 60 vs 61 making the difference in the test.
Can you change it back to 60 (or even less) and see what the values look like
when the test fails?
It is interesting
R. David Murray added the comment:
All right, so how about I set the add factor to, say, 5, so that if things are
mostly in sync it will succeed, and otherwise just ignore your failures :)
--
___
Python tracker
<http://bugs.python.org/issue9
Changes by R. David Murray :
--
resolution: -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
R. David Murray added the comment:
Antoine agreed in IRC that this was an acceptable closure.
--
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.org/
David-Sarah Hopwood added the comment:
First a minor correction:
> The new requirement would be that a correct app also needs to flush between a
> sequence of buffer.writes (that end in an incomplete line, or always if
> PYTHONUNBUFFERED or python -u is used), and a sequence of writ
David-Sarah Hopwood added the comment:
I wrote:
> A similar issue arises for stdin: to maintain strict compatibility, every
> read from a TextIOWrapper attached to an input console would have to drain
> the buffer of its buffer object, in case the app has read from it. This is a
>
R. David Murray added the comment:
Are you sure? (see issue 10471). I don't see how -b could do anything in
python2, since bytes and string are the same there (and, indeed, from command
line experimentation it doesn't seem to).
--
nosy: +r.da
R. David Murray added the comment:
rdmurray@hey:~/python/p27>cat temp.py
x = bytes('abc')
print x
print str(x)
rdmurray@hey:~/python/p27>./python -bb temp.py
abc
abc
--
___
Python tracker
<http://bugs.py
R. David Murray added the comment:
Well, I'm not so attached to the unexpected skip list that I want to block this
from getting implemented. So I guess the bottom line is that things that are
unexpected skips now should not be fai
David-Sarah Hopwood added the comment:
Glenn wrote:
> So if flush checks that bit, maybe TextIOWriter could just call buffer.flush,
> and it would be fast if clean and slow if dirty?
Yes. I'll benchmark how much overhead is added by the calls to flush; there's
no point
David-Sarah Hopwood added the comment:
If I understand the bug in the Windows console functions correctly, a limit of
32767 bytes might not always be small enough. The problem is that if two or
more threads are concurrently using any console functions (which all use the
same 64 KiB heap
R. David Murray added the comment:
The general approach of the patch looks good to me. Since formataddr is
designed to be called from user code that is constructing a message, having it
raise for non-ascii in the address is probably OK. However, there should be a
test for that, and I&#
R. David Murray added the comment:
You should check if 'charset' is a string, and call Charset on it only if it is
(a Charset may be passed directly in other email package interfaces, and so
should be supported here as well.
The test doesn't need to cater for the fact that ei
R. David Murray added the comment:
Thanks. Looks good except that it should check isinstance(string) rather than
isinstance(Charset), that way someone can pass a custom class that implements
the Charset API if they want. (Alternatively, the check could be for an
encode_header method
R. David Murray added the comment:
Ah, yes. Header is probably wrong there, I should fix that at some point.
Sorry for the misytpes in my last message (it was late at night for me when I
wrote it :)
As for time, it probably didn't take any more time than it would have to write
it m
Changes by R. David Murray :
--
versions: -Python 2.7, Python 3.1, Python 3.2
___
Python tracker
<http://bugs.python.org/issue1690608>
___
___
Python-bugs-list m
R. David Murray added the comment:
This seems to be causing some issues on the buildbots:
http://www.python.org/dev/buildbot/all/builders/AMD64%20Snow%20Leopard%202%203.x/builds/137
--
nosy: +r.david.murray
status: closed -> open
___
Python trac
Changes by R. David Murray :
--
keywords: -easy
___
Python tracker
<http://bugs.python.org/issue9205>
___
___
Python-bugs-list mailing list
Unsubscribe:
R. David Murray added the comment:
All the references I could find talk about triggering the match without the
proceeding newline. That is, it is not certain that a blank line will precede
the 'From ' header, and the typical quoting rules for mbox format call for any
'From &#
New submission from R. David Murray :
As part of the email6 design, the email-sig came up with the idea of
simplifying the current email API by introducing the concept of "policy
objects". A policy object is an object that hold various parameters and
methods that can be used to c
R. David Murray added the comment:
I have a vague memory of changing some code, in linecache I think, that
involved anonymous names. I might have fixed it by accident.
--
nosy: +r.david.murray
___
Python tracker
<http://bugs.python.org/issue4
R. David Murray added the comment:
I don't know what re is doing with respect to locale, but I do know that the
implementation of string.letters is at least somewhat broken in 2.x. It has no
useful meaning in unicode, which is why it doesn't exist in 3.x.
A standard that talks a
Changes by R. David Murray :
--
nosy: +pitrou
___
Python tracker
<http://bugs.python.org/issue11746>
___
___
Python-bugs-list mailing list
Unsubscribe:
R. David Murray added the comment:
Yeah, as far as I could tell from a brief scan of google hits, locale support
in regex in general is a legacy thing, and the "correct" thing to do is to use
unicode properties. So I'll close this as won't fix. If someone comes along
wi
New submission from David Albert Torpey :
Floats have fromhex() and hex() to round-trip from and to hexadecimal, but
bytes only have fromhex(), so it's hard to reliably round-trip.
--
messages: 132892
nosy: dtorp
priority: normal
severity: normal
status: open
title: bytes.hex()
R. David Murray added the comment:
Actually, this is a duplicate of issue 9951.
--
nosy: +r.david.murray
resolution: invalid -> duplicate
stage: -> committed/rejected
superseder: -> introduce bytes.hex method
___
Python track
R. David Murray added the comment:
Using assertRaises as a context manager is not a hack, and is the correct way
to do this in unittest.
--
nosy: +r.david.murray
status: open -> closed
___
Python tracker
<http://bugs.python.org/issu
R. David Murray added the comment:
For some reason the create patch button isn't working (perhaps because I'm
using a named branch?), so here is a patch representing the current state of
the feature branch.
--
keywords: +patch
Added file: http://bugs.python.org/file21533/po
Changes by R. David Murray :
Removed file: http://bugs.python.org/file21533/policy.patch
___
Python tracker
<http://bugs.python.org/issue11731>
___
___
Python-bugs-list m
R. David Murray added the comment:
Try again with a patch going in the expected direction :)
--
Added file: http://bugs.python.org/file21534/policy.patch
___
Python tracker
<http://bugs.python.org/issue11
R. David Murray added the comment:
Well, it's two years later, but I did look at this during the sprints at PyCon,
though I didn't get as far as posting it then (I only just now rediscovered the
patch on my laptop).
Python3 no longer has a "binary" flag on base64mime.
New submission from R. David Murray :
I discovered the attached failure case in the process of investigating another
issue. The bug (a continuation line with no leading white space) doesn't exist
in 2.7, but in 2.7 the extra whitespace is not preserved (that is, the output
of the new
R. David Murray added the comment:
I'm working on this. It appears to be a bug in the bytes parser, rather than
the generator.
--
___
Python tracker
<http://bugs.python.org/is
R. David Murray added the comment:
Although there's a (different) bug in the generator, too, I think :)
--
___
Python tracker
<http://bugs.python.org/is
R. David Murray added the comment:
No, the need for an encoding parameter for read/write makes it unambiguous that
it is indeed a feature.
--
resolution: -> wont fix
status: open -> closed
___
Python tracker
<http://bugs.python.org/i
R. David Murray added the comment:
The goal of tolerant mode is to accept anything a typical browser would accept.
I suspect that means the tolerant regex should stay, but I don't remember the
details.
As for the strictas far as I know the current module follows 4.01, not 5.
I&
R. David Murray added the comment:
Here is a patch against 3.2, with test. Simple fix, but it took me a while to
track down the critical piece of code.
--
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file21546/parse_8bit_multipart.pa
R. David Murray added the comment:
Ah, it isn't broken, it's just that the default changed. In 2.x, the default
was maxlinelen=78, in 3.x, the default is maxlinelen=None (unlimited), but
generator passes in an override of 78 when formatting output. So you can
specify an explicit
Changes by R. David Murray :
--
assignee: -> r.david.murray
nosy: +r.david.murray
___
Python tracker
<http://bugs.python.org/issue11780>
___
___
Python-
R. David Murray added the comment:
Thanks for the testing.
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Changes by R. David Murray :
--
assignee: -> r.david.murray
nosy: +r.david.murray
___
Python tracker
<http://bugs.python.org/issue11684>
___
___
Python-
Changes by R. David Murray :
--
assignee: -> r.david.murray
nosy: +r.david.murray
___
Python tracker
<http://bugs.python.org/issue11782>
___
___
Python-
R. David Murray added the comment:
Finally got around to committing this; thanks, Torsten. As a reward, I'm going
to make you nosy on a new, related issue I'm about to create. It is, of
course, your option whether you want to work on it :)
By the way, have you submitted a c
New submission from R. David Murray :
The patch for issue 1690608 adds support for unicode in the realname field to
formataddr. To complete the currently-workable internationalization of address
specs, both parseaddr and formataddr should be made IDNA aware. It is probably
a good idea to do
R. David Murray added the comment:
Issue 1690608 addresses part of this issue, and issue 11783 will address the
IDNA part.
>From my point of view those two issues solve this problem from the perspective
>the email package infrastructure and *current* API. In the email6 API I do
&g
New submission from R. David Murray :
Attached is a patch. I'm not sure that I've done everything that needs to be
done on the Windows side, though. Martin?
--
keywords: +patch
nosy: +loewis
Added file: http://bugs.python.org/file21550/build_update_for_test_e
Changes by R. David Murray :
--
assignee: -> r.david.murray
___
Python tracker
<http://bugs.python.org/issue11781>
___
___
Python-bugs-list mailing list
Un
Changes by R. David Murray :
--
nosy: +r.david.murray
___
Python tracker
<http://bugs.python.org/issue11785>
___
___
Python-bugs-list mailing list
Unsubscribe:
R. David Murray added the comment:
It is not clear from the docs what the expected behavior of factory is. It is
certainly the case that the custom classes used by mailbox by default do not
close the file they are passed. So either those classes should close the input
file and factory
Changes by R. David Murray :
--
assignee: docs@python -> r.david.murray
___
Python tracker
<http://bugs.python.org/issue11785>
___
___
Python-bugs-list mai
R. David Murray added the comment:
You have to do an 'encode' to get the wrapped header. __str__ uses
maxlinelen=None.
However, there does seem to be a problem with the line wrapping algorithm
revealed by your example: it is only doing a line break at the ';', not at
R. David Murray added the comment:
Sounds fine to me.
--
___
Python tracker
<http://bugs.python.org/issue7311>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by R. David Murray :
Removed file: http://bugs.python.org/file21554/11767.patch
___
Python tracker
<http://bugs.python.org/issue11767>
___
___
Python-bugs-list m
R. David Murray added the comment:
get_file's promise is that what is returned is a file like object, so it not
having a close() method would be an error. So I don't think you need the
try/except. What I would suggest is to use the 'closing' context manager
around the r
R. David Murray added the comment:
Given your problem report wouldn't the simplest solution be to change the close
method to be:
if hasattr(self, '_file'):
if hasattr(self._file, 'close'):
self._file.close()
del self._file
As for a test, i
R. David Murray added the comment:
I don't understand what you are saying about raising a ValueError on close. f
= open('x'); f.close(); f.close() does not raise any error, as Amaury pointed
out.
So I still don't understand the motivation fo
R. David Murray added the comment:
OK, it looks like the wrapping problem arises when the line contains runs of
blank delimited tokens longer than maxlinelen *and* the line also contains
';'s. The line is then split at the ';' and the remaining overlong pieces are
not sp
R. David Murray added the comment:
Here is a patch containing three test cases that demonstrate three different
failings of the header folding algorithm. I'm working on the fix, but it is
non-trivial.
--
components: +Library (Lib) -None
keywords: +patch
title: email.header.H
Changes by R. David Murray :
Removed file: http://bugs.python.org/file21563/header_folding_tests.patch
___
Python tracker
<http://bugs.python.org/issue11492>
___
___
Pytho
R. David Murray added the comment:
Note that 2.7 fails two of these tests as well, but for different reasons. I'm
not currently planning to fix 2.7, as its behavior at least (a) doesn't lose
non-whitespace information and (b) doesn't exceed the maxheaderlen.
--
A
R. David Murray added the comment:
Ah, that's exactly why I suggested using the 'closing' context manager from
contextlib. That context manager returns the object passed to it, and then
when its __exit__ method is called, calls the close method of that object that
w
Changes by R. David Murray :
Removed file: http://bugs.python.org/file21564/header_folding_tests.patch
___
Python tracker
<http://bugs.python.org/issue11492>
___
___
Pytho
R. David Murray added the comment:
Here is an updated test patch that brings the test coverage of the relevant
code much closer to 100%. There are still three lines and one branch
uncovered, but it appears as though one of the bugs is preventing the test case
that would produce full
R. David Murray added the comment:
To a pythonista, the perl behavior is counter-intuitive :)
That said, the behavior of r'\' *is* somewhat counter-intuitive. See issue
1271 for a fairly thorough exploration of why it is the way it is.
--
nosy: +r.da
R. David Murray added the comment:
I shouldn't have assumed that you knew about contextlib, and should have
mentioned it by name the first time.
The patch looks good to me. Not sure it is necessary to loop through ten fake
mailboxes, but it doesn't hurt, either. (Other potential
R. David Murray added the comment:
Putting in a size limit is reasonable. We did this for fnmatch not that long
ago (issue 7846). That was in fact the inspiration for lru_cache.
--
nosy: +r.david.murray
___
Python tracker
<http://bugs.python.
R. David Murray added the comment:
I believe Torsten is interested, but he can of course speak for himself.
Just to make sure you are aware: Python has a built in idna codec, so this
should be a fairly simple patch.
--
___
Python tracker
<h
R. David Murray added the comment:
Terry, the test is in the other issue, so this time Steffen has provided the
test :).
I'll take a look at both issues, probably next week.
--
___
Python tracker
<http://bugs.python.org/is
R. David Murray added the comment:
Python 2.7 is closed for new features, I afraid. And Berkeley DB is not
included in the Python3 stdlib. It has reverted to being maintained entirely
as a third party package.
--
nosy: +r.david.murray
resolution: -> rejected
stage: -> com
Changes by R. David Murray :
--
resolution: -> duplicate
stage: needs patch -> committed/rejected
status: open -> closed
superseder: -> email.header.Header doesn't fold headers correctly
___
Python tracker
<http://bugs.p
3101 - 3200 of 12936 matches
Mail list logo
