[issue5088] optparse: inconsistent default value for append actions
Andrew McNabb added the comment:
I think that optparse is doing the right thing here. I think that your code
example should be changed to:
import optparse
parser = optparse.OptionParser()
parser.add_option("-o", "--option", action = "append")
options, args = parser.parse_args()
if not options.option:
options.option = ['a']
print options
Think of the default as the initial list, and each time the -o option is
specified, an item is appended to that initial list.
--
nosy: +amcnabb
___
Python tracker
<http://bugs.python.org/issue5088>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7953] RawIOBase.read fails with an AttributeError
New submission from Andrew McNabb : I was trying to open stdin in binary mode and ran the following: >>> RawIOBase(sys.stdin.fileno()).read() Traceback (most recent call last): File "", line 1, in AttributeError: 'RawIOBase' object has no attribute 'readinto' >>> I would expect read() to read data instead of crashing. -- components: IO messages: 99484 nosy: amcnabb severity: normal status: open title: RawIOBase.read fails with an AttributeError type: behavior versions: Python 3.1 ___ Python tracker <http://bugs.python.org/issue7953> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7954] detach method has no docstring
Andrew McNabb added the comment: Oops. I had run "pydoc" instead of "pydoc3", so I was getting the 2.6 version of the io docstrings instead of the 3.1 version. By the way, it took about an hour to find out how to get Python 3 to treat stdin as bytes instead of unicode. Now that I know what I was looking for, the documentation for the io library seems fine. However, since Python 3 uptake is still a little slow, it's really hard to search for good information out there. Would it be possible to some tutorial-style information to the io library documentation? Stuff like switching stdin and stdout to bytes mode seem like they will be common problems, and it's a bit overwhelming to sort through 14 pages of documentation. I think for most readers, it would be helpful to start with a brief tutorial before lunging into the hierarchy of abstract classes. Overall, the documentation is great; it's detailed and complete. If there's one weakness, it's the overview. Thanks. -- ___ Python tracker <http://bugs.python.org/issue7954> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7955] TextIOWrapper Buffering Inconsistent Between _io and _pyio
New submission from Andrew McNabb :
The following snippet behaves differently in the C IO implementation than in
the Python IO implementation:
import sys
sys.stdout.write('unicode ')
sys.stdout.buffer.write(b'bytes ')
To test this, I have created two scripts, testpyio.py (using _pyio) and
testio.py (using _io). The output is as follows:
% python3 testpyio.py
unicode bytes
% python3 testio.py
bytes unicode
%
In my opinion, the behavior exhibited by _pyio is more correct. It appears
that to get the C implementation to print the lines in the correct order, there
must be a flush in between the statements. This extra flush would create a lot
of overhead.
I am attaching the two test scripts.
The C implementation prints the output in the correct order if each write ends
with a newline.
--
components: IO
files: testpyio.py
messages: 99496
nosy: amcnabb
severity: normal
status: open
title: TextIOWrapper Buffering Inconsistent Between _io and _pyio
type: behavior
versions: Python 3.1
Added file: http://bugs.python.org/file16248/testpyio.py
___
Python tracker
<http://bugs.python.org/issue7955>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7955] TextIOWrapper Buffering Inconsistent Between _io and _pyio
Andrew McNabb added the comment: This seems like a common need (particularly for stdout and stderr), and setting `stdout._CHUNK_SIZE = 1` is relying on an implementation detail. 1) Can the documentation for TextIOWrapper be updated to clearly describe this extra buffering (how often buffer.write is called, etc.)? 2) Can there be a flush-like method, say write_to_buffer() to force a buffer.write() without the overhead of a flush? -- status: closed -> open ___ Python tracker <http://bugs.python.org/issue7955> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7955] TextIOWrapper Buffering Inconsistent Between _io and _pyio
Andrew McNabb added the comment: I would imagine that this would come up in most programs that read data from a pipe or from a socket (which are binary data) and then output to stdout or stderr. I ran across the problem in my first non-trivial port to Python 3, and it seems like a common case to me. But having the weird behavior documented is the most important thing. -- ___ Python tracker <http://bugs.python.org/issue7955> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5315] signal handler never gets called
Andrew McNabb added the comment: I'm seeing something very similar to this. In my case, I have a single-threaded program, and select fails to be interrupted by SIGCHLD. I'm still tracking down more details, so I'll report back if I find more information. -- nosy: +amcnabb ___ Python tracker <http://bugs.python.org/issue5315> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5315] signal handler never gets called
Andrew McNabb added the comment: Sorry for the noise. It turns out that my problem was unrelated. -- ___ Python tracker <http://bugs.python.org/issue5315> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8127] Add link to PortingPythonToPy3k to What's New documentation
New submission from Andrew McNabb : The What's New documentation for Python 3.0 and 3.1 have sections called "Porting to Python 3.0". It would be great to add a link to the Python wiki page about porting Python to Python 3: http://wiki.python.org/moin/PortingPythonToPy3k -- assignee: georg.brandl components: Documentation messages: 100956 nosy: amcnabb, georg.brandl severity: normal status: open title: Add link to PortingPythonToPy3k to What's New documentation versions: Python 3.1 ___ Python tracker <http://bugs.python.org/issue8127> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8127] Add link to PortingPythonToPy3k to What's New documentation
Andrew McNabb added the comment: What advice in particular do you consider bad? I would be happy to submit some changes to the wiki page for anything that's wrong. I think it would be great to have a reviewed version in the documentation directly, but I think the world needs a little more experience with Python 3 before it could be done well. In the meantime, I think it's important to get the discussion moving towards finding a set of best practices. Raising the visibility of the wiki page seems like a great way to encourage participation and to get things moving forward. Right now, there's no sense of best practices in porting to Python 3, and it's leaving people with the impression that it's too hard and not worth it. -- ___ Python tracker <http://bugs.python.org/issue8127> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8127] Add link to PortingPythonToPy3k to What's New documentation
Andrew McNabb added the comment: By the way, I just noticed your notes on the wiki page and added a response/question. It seems that the advice that you consider bad is the official porting story (upgrade to 2.6 and use 2to3). I agree that it's easier and better to not drop support for 2.4 and 2.5, but this seems to be officially discouraged. The current content on the What's New page only talks about upgrading to 2.6 and using 2to3. In any case, most of the current content on the wiki page is about supporting Python 2 and Python 3 simultaneously. I think this is actually better than the official documentation. -- ___ Python tracker <http://bugs.python.org/issue8127> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8127] Add link to PortingPythonToPy3k to What's New documentation
Andrew McNabb added the comment: Thanks for your advice. I just signed up for the python-porting list, and I'll start a discussion there. I'm trying to improve the wiki page to address your concerns. There are multiple valid approaches to take, and I'm trying to make the page show this. I'll remove the inline notes for now (since they clutter things), and I'll try to incorporate your changes. I apologize in advance if I make any mistakes. -- ___ Python tracker <http://bugs.python.org/issue8127> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13881] Stream encoder for zlib_codec doesn't use the incremental encoder
New submission from Andrew McNabb :
The stream encoder for the zlib_codec doesn't use the incremental encoder, so
it has limited usefulness in practice. This is easiest to show with an example.
Here is the behavior with the stream encoder:
>>> filelike = io.BytesIO()
>>> wrapped = codecs.getwriter('zlib_codec')(filelike)
>>> wrapped.write(b'hello')
>>> filelike.getvalue()
b'x\x9c\xab\x00\x00\x00y\x00y'
>>> wrapped.write(b'x')
>>> filelike.getvalue()
b'x\x9c\xab\x00\x00\x00y\x00yx\x9c\xab\x00\x00\x00y\x00y'
>>>
However, this is the behavior of the incremental encoder:
>>> ienc = codecs.getincrementalencoder('zlib_codec')()
>>> ienc.encode(b'x')
b'x\x9c'
>>> ienc.encode(b'x', final=True)
b'\xab\xa8\x00\x00\x01j\x00\xf1'
>>>
The stream encoder is apparently encoding each write as an individual block,
but the incremental encoder buffers until it gets a block that's large enough
to be meaningfully compressed.
Fixing this may require addressing a separate issue with stream encoders.
Unlike with the GzipFile module, closing a stream encoder closes the underlying
file. If this underlying file is a BytesIO, then closing makes it free its
buffer, making it impossible to get at the completed file.
--
components: IO
messages: 152029
nosy: amcnabb
priority: normal
severity: normal
status: open
title: Stream encoder for zlib_codec doesn't use the incremental encoder
type: behavior
versions: Python 3.2
___
Python tracker
<http://bugs.python.org/issue13881>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13881] Stream encoder for zlib_codec doesn't use the incremental encoder
Andrew McNabb added the comment: It looks like encodings/zlib_codec.py defines a custom IncrementalEncoder and IncrementalDecoder, but its StreamWriter and StreamReader rely on the standard implementation of codecs.StreamWriter and codecs.StreamReader. One solution might be to have zlib_codec.StreamWriter inherit from zlib_codec.IncrementalEncoder instead of from zlib_encoder.Codec. I'm not familiar enough with the codecs library to know whether this is the best approach. Unfortunately, there are 120 codec files in the encodings directory, and it's unclear how many of them would need to be modified. Based on the number of them that implement StreamWriter as "class StreamWriter(Codec,codecs.StreamWriter)", it looks like it might be a lot of them. Was each of these 120 files hand-written? -- ___ Python tracker <http://bugs.python.org/issue13881> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14702] os.makedirs breaks under autofs directories
New submission from Andrew McNabb :
When a os.makedirs is used under an autofs directory, it crashes. For example,
on my machine, `os.makedirs('/net/prodigy/tmp')` crashes with the following
traceback:
Traceback (most recent call last):
...
File "/usr/lib64/python2.7/os.py", line 157, in makedirs
mkdir(name, mode)
OSError: [Errno 13] Permission denied: '/net/prodigy/tmp'
In this case, '/net' is an autofs directory that automatically mounts the
"prodigy" directory by connecting to a host called "prodigy" using NFS. The
problem seems to be related to the fact that the "/net/prodigy" directory does
not actually exist until it is first accessed.
I tried running `mkdir -p /net/prodigy/tmp`, and it succeeds even though the
"/net/prodigy" directory did not exist before the "mkdir" command was run.
I'm not sure exactly how `mkdir -p` is implemented, but one potential
workaround for Python's makedirs would be to add the following at the top of
the function:
os.stat(name)
This stat call really only needs to be run the first time makedirs is called
(it does not need to be used for each recursive call).
--
components: Library (Lib)
messages: 159728
nosy: amcnabb
priority: normal
severity: normal
status: open
title: os.makedirs breaks under autofs directories
versions: Python 2.7
___
Python tracker
<http://bugs.python.org/issue14702>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14702] os.makedirs breaks under autofs directories
Andrew McNabb added the comment: > Andrew, are you still with us? I'm here, but it's been a busy few weeks. I'll see if I can spend some time on this today. -- ___ Python tracker <http://bugs.python.org/issue14702> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14702] os.makedirs breaks under autofs directories
Andrew McNabb added the comment:
Some interesting information. If I do `os.mkdir('/net/prodigy/tmp')`, it gives
"OSError: [Errno 13] Permission denied: '/net/prodigy/tmp'". However, if I
instead do `os.mkdir('/net/prodigy/tmp/hi')`, it succeeds. (Note that I'm being
careful to start from a fresh unmounted state in both cases).
I will post straces in a few minutes.
--
___
Python tracker
<http://bugs.python.org/issue14702>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14702] os.makedirs breaks under autofs directories
Changes by Andrew McNabb : Added file: http://bugs.python.org/file25611/mkdir-p.out ___ Python tracker <http://bugs.python.org/issue14702> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14702] os.makedirs breaks under autofs directories
Changes by Andrew McNabb : Added file: http://bugs.python.org/file25612/makedirs.out ___ Python tracker <http://bugs.python.org/issue14702> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14702] os.makedirs breaks under autofs directories
Andrew McNabb added the comment: This isn't fixed. All of the examples I've given were with a 3.3.0 kernel. Doing a stat would be a fix. -- status: closed -> open ___ Python tracker <http://bugs.python.org/issue14702> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14702] os.makedirs breaks under autofs directories
Andrew McNabb added the comment:
Hmm. Maybe there's a difference between doing stat('/net/prodigy') vs.
stat('/net/prodigy/tmp'). Just a guess, but maybe the former can succeed before
the mount completes, but the latter has to wait for the mount to complete.
--
___
Python tracker
<http://bugs.python.org/issue14702>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14702] os.makedirs breaks under autofs directories
Andrew McNabb added the comment: By the way, if my hunch about the difference in stat of '/net/prodigy' vs. '/net/prodigy/tmp' is correct, then this would explain why makedirs on deeper directories work. Specifically, one of the shallower stat calls would force the mount to complete before proceeding to the next deeper level. -- ___ Python tracker <http://bugs.python.org/issue14702> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14702] os.makedirs breaks under autofs directories
Andrew McNabb added the comment: I see no evidence that this is a bug in Linux, and I think it's ridiculous to close it when a trivial one-line fix is available. I won't reopen it because it's obvious no one wants to address this. :( -- ___ Python tracker <http://bugs.python.org/issue14702> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14702] os.makedirs breaks under autofs directories
Andrew McNabb added the comment: I posted a bug report with the kernel here: https://bugzilla.kernel.org/show_bug.cgi?id=43262 -- ___ Python tracker <http://bugs.python.org/issue14702> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14702] os.makedirs breaks under autofs directories
Andrew McNabb added the comment:
> Which one-line fix do you propose?
Doing a stat("/net/prodigy/tmp") before mkdir("/net/prodigy/tmp") is an
extremely simple workaround.
Of course, I would love to see clear documentation of how the kernel is defined
to behave in this situation. It would certainly be intuitive for
mkdir("/net/prodigy/tmp") to force a mount of "/net/prodigy", but defined
behavior isn't always intuitive. :)
--
___
Python tracker
<http://bugs.python.org/issue14702>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14702] os.makedirs breaks under autofs directories
Andrew McNabb added the comment: > Maybe I'm confused, but the presence of "/net/prodigy" is *not* > the issue here, and what gets mounted is *not* "/net/prodigy", > but "/net/prodigy/tmp" (do "mount" to confirm or dispute). No, /net/prodigy is the mountpoint in this case: amcnabb@sage:~ :) mount |grep prodigy prodigy:/ on /net/prodigy type nfs4 ([redacted]) -- ___ Python tracker <http://bugs.python.org/issue14702> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)
Changes by Andrew McNabb : -- nosy: +amcnabb ___ Python tracker <http://bugs.python.org/issue9334> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1180] Option to ignore or substitute ~/.pydistutils.cfg
Andrew McNabb added the comment: The --no-user-cfg option works for me in Python 2.7, but it does not seem to be in Python 3.2 or 3.3: error: option --no-user-cfg not recognized Am I doing something wrong, or was this feature only added to Python 2.7? -- nosy: +amcnabb ___ Python tracker <http://bugs.python.org/issue1180> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4606] Passing 'None' if argtype is set to POINTER(...) doesn't always result in NULL
Andrew McNabb added the comment: I ran into this problem, too. It took me a long time to track down the segfaults. It's really bad to pass in None and have the system pick some random address instead of 0. I looked at the attached patch, and it seems to me the only alternative approach would be to use PyLong_FromLong instead of PyInt_FromLong. However, since ConvParam already handles None appropriately, I think the fix in patch_ctypes_none_arg.diff really is the best way to do it. This patch is a one-line fix (plus tests and documentation), and it fixes a bug which crashes the interpreter. The patch seems very straightforward, and there is no way that code could depend on the current behavior. I'm not sure if my patch review counts for much, but there you have it. :) It would be great if this patch could be applied quickly and added to the maintenance branch for 2.6. Thanks. -- nosy: +amcnabb type: behavior -> crash ___ Python tracker <http://bugs.python.org/issue4606> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4606] Passing 'None' if argtype is set to POINTER(...) doesn't always result in NULL
Andrew McNabb added the comment: On Thu, Jul 30, 2009 at 07:14:56PM +, Thomas Heller wrote: > > Thanks for bringing my attention to this problem again, and for the review. I'm just glad to help. > The problem is that the patch changes the behaviour of the > 'POINTER(...).from_param' methods, so I'm unsure if it can be applied > to 2.6 (or even 2.5). Opinions? Hmm. So you're saying that someone could be calling from_param() and expecting to see 0 instead of None. Am I understanding correctly? I suppose that could happen on either 32-bit or 64-bit systems (because from_param returns 0 for both). I can't personally think of a situation where someone would rely on that, but maybe it's something to ask about on python-dev. I just looked at ConvParam in a little more detail, and it seems that the problem is caused because setting pa->value.i to 0 only works for the lower-order bits. Apparently the higher order bits in pa->value are non-zero when ConvParam is called. Would it be possible to zero-out pa->value at the top of ConvParam (i.e., putting "bzero(&(pa->value), sizeof(pa->value)" or something at the top of ConvParam)? Am I missing something about what's in pa before ConvParam is called? > The patch is missing a 'Py_INCREF(value)' before the 'return value;', > but this is a minor point. Thanks for pointing that out. I'm still getting familiar with reference counting in the Python API. -- ___ Python tracker <http://bugs.python.org/issue4606> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6999] TypeError in pathfix.py
New submission from Andrew McNabb : Tools/scripts/pathfix.py crashes with a TypeError: Traceback (most recent call last): File "Tools/scripts/pathfix.py", line 149, in main() File "Tools/scripts/pathfix.py", line 54, in main if recursedown(arg): bad = 1 File "Tools/scripts/pathfix.py", line 82, in recursedown elif ispython(name): File "Tools/scripts/pathfix.py", line 64, in ispython return ispythonprog.match(name) >= 0 TypeError: unorderable types: NoneType() >= int() It looks like an easy fix would be to change line 64 from: return ispythonprog.match(name) >= 0 to: return bool(ispythonprog.match(name)) After making this change, I got another crash, this time due to a UnicodeDecodeError. Apparently, the file (Demo/distutils/test2to3/setup.py) has a character encoded in ISO-8859. Since pathfix.py is only concerned with ASCII text in the first line of a file, it seems that it should probably operate on bytes instead of unicode strings. By the way, it's a little odd (but not technically invalid) that the format string on line 146 is: '#! %s\n'. I would normally expect to see no whitespace: '#!%s\n'. Anyway, I'm attaching a patch that fixes addresses all of the above issues and which seems to make pathfix.py work for all files in the Python 3.1.1 source tree. -- components: Demos and Tools files: python-3.1.1-pathfix.patch keywords: patch messages: 93134 nosy: amcnabb severity: normal status: open title: TypeError in pathfix.py type: crash versions: Python 3.1 Added file: http://bugs.python.org/file14975/python-3.1.1-pathfix.patch ___ Python tracker <http://bugs.python.org/issue6999> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6999] TypeError in pathfix.py
Changes by Andrew McNabb : -- type: crash -> behavior ___ Python tracker <http://bugs.python.org/issue6999> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4359] at runtime, distutils uses buildtime files
Andrew McNabb added the comment: I've noticed this, too, and I agree with Toshio's observations. Tarek, do you have any opinions? -- nosy: +amcnabb ___ Python tracker <http://bugs.python.org/issue4359> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14191] argparse doesn't allow optionals within positionals
Changes by Andrew McNabb : -- nosy: +amcnabb ___ Python tracker <http://bugs.python.org/issue14191> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15258] argparse documentation: Improve optparse section regarding allow_interspersed_args
Changes by Andrew McNabb : -- nosy: +amcnabb ___ Python tracker <http://bugs.python.org/issue15258> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
