[issue6741] Garbage collector release method
New submission from Lev : WinCRT debug detects several memory leaks after calling py_Initialize (); py_Finalize(); functions. Most of them are garbage collector visible python's objects. I suggest to create "release" method in garbage collector which will distruct all objects in GC list without reference count checking, and call this method at the end of py_Finalize () function. I think, that it will help to avoid memory leaks after calling py_Finalize() function. -- components: Interpreter Core messages: 91772 nosy: gardster severity: normal status: open title: Garbage collector release method type: feature request versions: Python 2.6 ___ Python tracker <http://bugs.python.org/issue6741> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6741] Garbage collector release method
Lev added the comment: I,m trying to develop this patch now, but I'm facing the challenge (wrong ref_count or list corruption in dict objects). If I can solve it, I publish patch here. -- ___ Python tracker <http://bugs.python.org/issue6741> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46336] Sixth element of tuple from __reduce__(), inconsistency between pickle and copy
New submission from Lev Bishop : As discussed in discord thread https://discuss.python.org/t/sixth-element-of-tuple-from-reduce-inconsistency-between-pickle-and-copy/12902 where guido suggested to open this issue. Both the pickle and copy modules of the standard library make use of a class’s __reduce__() method for customizing their pickle/copy process. They seem to have a consistent view of the first 5 elements of the returned tuple: (func, args, state, listiter, dictiter) but the 6th element seems different. For pickle it’s state_setter , a callable with signature state_setter(obj, state)->None , but for copy it’s deepcopy with signature deepcopy(arg: T, memo) -> T . This seems to be unintentional, since the pickle documentation states: > As we shall see, pickle does not use directly the methods described > above. In fact, these methods are part of the copy protocol which > implements the __reduce__() special method. The copy protocol provides > a unified interface for retrieving the data necessary for pickling > and copying objects It seems like in order to make a class definition for __reduce__() returning all 6 elements, then the __reduce__() would have to do something very awkward like examining its call stack in order to determine if it is being called in pickle or copy context in order to return an appropriate callable? (Naively providing the same callable in both contexts would cause errors for one or the other). I attach a test file which defines two classes making use of a __reduce__() returning a 6 element tuple. One class Pickleable can be duplicated via pickling, but not deepcopied. The converse is true for the Copyable class. Other than the 6th element of the tuple returned from __reduce__() the classes are identical. Guido dug into the history and found that: > it looks like these are independent developments: > the 6th arg for deepcopy was added 6 years ago via Issue 26167: Improve > copy.copy speed for built-in types (list/set/dict) - Python tracker > the 6th arg for pickle was adde 3 years ago via Issue 35900: Add pickler hook > for the user to customize the serialization of user defined functions and > types. - Python tracker > I’m guessing the folks doing the latter weren’t aware that deepcopy already > uses the 6th arg. Sorting this out will be painful. -- components: Library (Lib) files: reduce.py messages: 410256 nosy: lev.bishop priority: normal severity: normal status: open title: Sixth element of tuple from __reduce__(), inconsistency between pickle and copy type: behavior Added file: https://bugs.python.org/file50554/reduce.py ___ Python tracker <https://bugs.python.org/issue46336> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2200] find_executable fails to find .bat files on win32
Lev Shamardin added the comment: My use case was compiling PyQt4 resources and Qt Designer .ui files from setup script using pyrcc4 and pyuic4 commands. On windows pyrcc4 is actually a pyrcc4.bat file (at least it was at the time of the original bug submission - haven't checked current status), and find_exe could not find it. -- ___ Python tracker <http://bugs.python.org/issue2200> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2200] find_executable fails to find .bat files on win32
New submission from Lev Shamardin: distutils.spawn.find_executable appends '.exe' suffix on win32 and os2 platforms. This is incorrect behavior, since it prevents finding .bat, .cmd and other similar files. Ether all extensions from the %PATHEXT% must be checked or filenames both with appended suffix and without appending suffix must be checked. -- components: Distutils messages: 63092 nosy: abbot severity: major status: open title: find_executable fails to find .bat files on win32 type: behavior versions: Python 2.5 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2200> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2200] find_executable fails to find .bat files on win32
Lev Shamardin added the comment: Here is my vision of this patch. I don't think that it is necessary to fall back to 'com/exe/bat' if PATHEXT is not set, since it must be set on any correctly configured Win32 platform. -- keywords: +patch Added file: http://bugs.python.org/file9584/spawn.patch __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2200> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2200] find_executable fails to find .bat files on win32
Lev Shamardin added the comment: I can't see this issue on the 'open issues' list nor in the search results. Is something wrong? __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2200> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43869] Fix documentation of epoch/time.time
New submission from Ofek Lev : The descriptions for the following: - https://docs.python.org/3/library/time.html#epoch - https://docs.python.org/3/library/time.html#time.time indicate that it is platform dependent. However, that is likely untrue. See the brief discussion here: https://github.com/DataDog/integrations-core/pull/6692#discussion_r427469097 -- assignee: docs@python components: Documentation messages: 391214 nosy: Ofekmeister, docs@python, p-ganssle priority: normal severity: normal status: open title: Fix documentation of epoch/time.time type: enhancement versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue43869> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33240] shutil.rmtree fails if inner folder is open in Windows Explorer
Ofek Lev added the comment: > For convenience, a handler that retries unlink() and rmdir() could be > distributed with shutil. For ease of use, it could be enabled by default on > Windows. Any update on that? I just spent a bunch of time debugging this on Windows. -- nosy: +Ofekmeister ___ Python tracker <https://bugs.python.org/issue33240> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42965] Optional callable raises TypeError
New submission from Ofek Lev : https://docs.python.org/3.9/library/typing.html#callable ``` Python 3.9.1 (default, Jan 12 2021, 16:45:25) [GCC 8.3.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> from typing import Optional >>> from collections.abc import Callable >>> >>> Hasher = Optional[Callable[[bytes], bytes]] Traceback (most recent call last): File "", line 1, in File "/usr/local/lib/python3.9/typing.py", line 262, in inner return func(*args, **kwds) File "/usr/local/lib/python3.9/typing.py", line 339, in __getitem__ return self._getitem(self, parameters) File "/usr/local/lib/python3.9/typing.py", line 463, in Optional return Union[arg, type(None)] File "/usr/local/lib/python3.9/typing.py", line 262, in inner return func(*args, **kwds) File "/usr/local/lib/python3.9/typing.py", line 339, in __getitem__ return self._getitem(self, parameters) File "/usr/local/lib/python3.9/typing.py", line 451, in Union parameters = _remove_dups_flatten(parameters) File "/usr/local/lib/python3.9/typing.py", line 231, in _remove_dups_flatten return tuple(_deduplicate(params)) File "/usr/local/lib/python3.9/typing.py", line 205, in _deduplicate all_params = set(params) TypeError: unhashable type: 'list' >>> >>> from typing import Tuple >>> Hasher = Optional[Callable[Tuple[bytes], bytes]] >>> ``` Tuple type for arguments makes it work -- components: Library (Lib) messages: 385246 nosy: Ofekmeister priority: normal severity: normal status: open title: Optional callable raises TypeError type: behavior versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue42965> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42965] Optional callable raises TypeError
Ofek Lev added the comment: I'm using the deprecated typing.Callable instead now and that works -- ___ Python tracker <https://bugs.python.org/issue42965> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42965] Optional callable raises TypeError
Ofek Lev added the comment: Ah I see, thanks! -- resolution: -> fixed stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue42965> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18617] AIA chasing for missing intermediate certificates on TLS connections
Ofek Lev added the comment: Any update on this? -- nosy: +Ofekmeister ___ Python tracker <https://bugs.python.org/issue18617> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30783] Spawned subprocesses don't respect environment
New submission from Ofek Lev:
The following example shows that we are indeed changing PATH, but the
subprocess does not acknowledge it in Windows 7 x64. Also note this works in
Linux (Ubuntu 16.04).
-
import os
import subprocess
from contextlib import contextmanager
from tempfile import TemporaryDirectory
def get_python_path():
return subprocess.check_output(
['python', '-c', 'import sys;print(sys.executable)']
).decode().strip()
@contextmanager
def temp_chdir(cwd=None):
with TemporaryDirectory() as d:
origin = cwd or os.getcwd()
os.chdir(d)
try:
yield d
finally:
os.chdir(origin)
def create_venv(d, pypath=None):
command = ['virtualenv', d]
if pypath:
command.extend(['-p', pypath])
subprocess.call(command)
@contextmanager
def venv(d):
if os.path.exists(os.path.join(d, 'bin')): # no cov
venv_exe_dir = os.path.join(d, 'bin')
elif os.path.exists(os.path.join(d, 'Scripts')):
venv_exe_dir = os.path.join(d, 'Scripts')
else:
raise OSError('Unable to locate executables directory.')
old_path = os.environ['PATH']
os.environ['PATH'] = '{}{}{}'.format(venv_exe_dir, os.pathsep, old_path)
yield
os.environ['PATH'] = old_path
def test_venv():
with temp_chdir() as d:
d = os.path.join(d, 'test_env')
create_venv(d)
global_python = get_python_path()
print('PATH', os.environ['PATH'][:140])
with venv(d):
print('PATH', os.environ['PATH'][:140])
venv_python = get_python_path()
assert global_python != venv_python
assert global_python == get_python_path()
--
components: Windows
messages: 296986
nosy: Ofekmeister, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Spawned subprocesses don't respect environment
type: behavior
versions: Python 3.6
___
Python tracker
<http://bugs.python.org/issue30783>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30783] Spawned subprocesses don't respect environment
Ofek Lev added the comment: Fixed with shell=True -- ___ Python tracker <http://bugs.python.org/issue30783> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20849] add exist_ok to shutil.copytree
Changes by Ofek Lev : -- pull_requests: +3020 ___ Python tracker <http://bugs.python.org/issue20849> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36258] Incorrect docstring of the ssl module
New submission from Ofek Lev : The docstring refers to the function `fetch_server_certificate` that no longer exists. Context from https://github.com/python/cpython/pull/12168#issuecomment-469488585: """ In the commit on 8/28/2007, the ssl.py module was first added and it contained the fetch_server_certificate() function. That function was removed with commit r57680 on 8/30/2007. The function get_server_certificate() was added in commit r58164 on 9/18/2007. ... Additionally, there are more than just 2 functions now, so it seems to me that the entire module docstring should be reviewed and updated to reflect the current state of the module or else it should be removed since it hasn't been kept in sync. """ -- assignee: docs@python components: Documentation messages: 337639 nosy: Ofekmeister, cheryl.sabella, docs@python priority: normal severity: normal status: open title: Incorrect docstring of the ssl module type: behavior versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue36258> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33245] Unable to send CTRL_BREAK_EVENT
New submission from Ofek Lev : Vault (https://github.com/hashicorp/vault) requires the use of signals to trigger certain output https://www.vaultproject.io/docs/internals/telemetry.html. The required signal isn't sent on py2.7: >>> import os >>> import signal >>> import psutil >>> p = psutil.Process([p.info for p in psutil.process_iter(attrs=['pid', >>> 'name']) if 'vault' in p.info['name']][0]['pid']) >>> p.exe() 'C:\\Users\\Ofek\\Desktop\\vault.exe' >>> p.pid 15536 >>> os.kill(p.pid, signal.CTRL_BREAK_EVENT) Traceback (most recent call last): File "", line 1, in WindowsError: [Error 87] The parameter is incorrect Interestingly, on py3.6 that code works but instead produces this: OSError: [WinError 87] The parameter is incorrect The above exception was the direct cause of the following exception: Traceback (most recent call last): File "", line 1, in SystemError: returned a result with an error set -- components: Windows messages: 315108 nosy: Ofekmeister, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Unable to send CTRL_BREAK_EVENT type: behavior versions: Python 2.7 ___ Python tracker <https://bugs.python.org/issue33245> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33841] lock not released in threading.Condition
New submission from Lev Maximov : In `Condition.wait()` the `waiter` lock gets acquired twice, but is released only once (both in timeout and no timeout cases). Is it intentional? -- components: Library (Lib) messages: 319365 nosy: lev.maximov priority: normal severity: normal status: open title: lock not released in threading.Condition type: behavior versions: Python 3.6 ___ Python tracker <https://bugs.python.org/issue33841> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21507] memory used by frozenset created from set differs from that of frozenset created from other iterable
New submission from Lev Givon: Not sure if this is indicative of a bug, but I noticed that a frozenset created from a set seems to occupy a different amount of memory than a frozenset created from some other iterable. I observed this behavior with Python 2.7.5 and with Python 3.4.0 on Ubuntu 14.04 x86_64: >>> from sys import getsizeof >>> x = range(100) >>> s = set(x) >>> f0 = frozenset(x) >>> f1 = frozenset(s) >>> getsizeof(s) 8424 >>> getsizeof(f0) 8424 >>> getsizeof(f1) 4328 >>> f0==f1 True Original question on StackOverflow available at https://stackoverflow.com/questions/23618259/memory-occupied-by-set-vs-frozenset-in-python-2-7 -- messages: 218524 nosy: lebedov priority: normal severity: normal status: open title: memory used by frozenset created from set differs from that of frozenset created from other iterable type: resource usage versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4 ___ Python tracker <http://bugs.python.org/issue21507> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5673] Add timeout option to subprocess.Popen
Changes by Lev Shamardin : -- nosy: +abbot ___ Python tracker <http://bugs.python.org/issue5673> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26844] Wrong error message during import
Lev Maximov added the comment: Nevermind. It's not urgent but should definitely be fixed some day. Yes, __qualname__ might be a good idea. -- ___ Python tracker <http://bugs.python.org/issue26844> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26844] Wrong error message during import
New submission from Lev Maximov: Error message was supposedly copy-pasted without change. Makes it pretty unintuinive to debug. Fix attached. -- components: Library (Lib) files: error.diff keywords: patch messages: 264157 nosy: Lev Maximov priority: normal severity: normal status: open title: Wrong error message during import type: enhancement versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file42584/error.diff ___ Python tracker <http://bugs.python.org/issue26844> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8800] add threading.RWLock
Ofek Lev added the comment: What is the status of the patch? -- nosy: +Ofekmeister ___ Python tracker <http://bugs.python.org/issue8800> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28553] int.to_bytes docs logic error
New submission from Ofek Lev: https://docs.python.org/3/library/stdtypes.html#int.to_bytes To convert an int to the exact number of bytes required, the docs recommend "x.to_bytes((x.bit_length() // 8) + 1, ...)". This is incorrect when length is a multiple of 8, e.g. 296. The correct way is "x.to_bytes((x.bit_length() + 7) // 8, ...)". -- assignee: docs@python components: Documentation messages: 279641 nosy: Ofekmeister, docs@python priority: normal severity: normal status: open title: int.to_bytes docs logic error type: enhancement versions: Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7 ___ Python tracker <http://bugs.python.org/issue28553> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28696] imap from ThreadPool hangs by an exception in a generator function
New submission from Lev Veshnyakov:
It's only in imap, in map it's ok. The following code explains the issue:
from multiprocessing.pool import ThreadPool
pool = ThreadPool(10)
def gen():
yield 1 + '1' # here is an error
try:
next((pool.imap(str, gen(
except:
# Will be catched using pool.map normally, but using pool.imap will be not.
# Instead it hangs. This is the same for ThreadPool and Pool.
print('this will not be printed because thread is hanging')
--
components: Library (Lib)
files: test.py
messages: 280833
nosy: lev-veshnyakov
priority: normal
severity: normal
status: open
title: imap from ThreadPool hangs by an exception in a generator function
type: behavior
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file45486/test.py
___
Python tracker
<http://bugs.python.org/issue28696>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28696] imap from ThreadPool hangs by an exception in a generator function
Lev Veshnyakov added the comment: Ubuntu 14.04 LTS, 3.13.0-83-generic, x86_64 -- ___ Python tracker <http://bugs.python.org/issue28696> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28696] imap from ThreadPool hangs by an exception in a generator function
Lev Veshnyakov added the comment: So, I've checked twice, it's presented by me on python 3.4.3, and not by 3.5.2. So I will go deaper -- ___ Python tracker <http://bugs.python.org/issue28696> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28696] imap from ThreadPool hangs by an exception in a generator function
Lev Veshnyakov added the comment: I've reproduced it on 2 different machines: - on a MacBook in Docker (debian:jessie, python 3.4.2) - on another desktop (Ubuntu 14.04.1, 3.16.0-77-generic, x86_64, python 3.4.3) -- ___ Python tracker <http://bugs.python.org/issue28696> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28696] imap from ThreadPool hangs by an exception in a generator function
Lev Veshnyakov added the comment:
It's hanging in a while loop in _handle_workers,
/usr/lib/python3.4/multiprocessingpool.py:365.
I can't figure out what is the reason.
@staticmethod
def _handle_workers(pool):
thread = threading.current_thread()
# Keep maintaining workers until the cache gets drained, unless the pool
# is terminated.
while thread._state == RUN or (pool._cache and thread._state != TERMINATE):
pool._maintain_pool()
time.sleep(0.1)
# send sentinel to stop workers
pool._taskqueue.put(None)
util.debug('worker handler exiting')
--
___
Python tracker
<http://bugs.python.org/issue28696>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28696] imap from ThreadPool hangs by an exception in a generator function
Lev Veshnyakov added the comment: Yes, I'm free to move to 3.5, now I'm seeing isn't there any problems in 3.5 according to this issue. -- ___ Python tracker <http://bugs.python.org/issue28696> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28699] Imap from ThreadPool behaves unexpectedly
New submission from Lev Veshnyakov: Consider the following code: from multiprocessing.pool import ThreadPool pool = ThreadPool(10) def gen(): yield 1 + '1' # here is an error print(list(pool.imap(str, gen( # prints [] print(list(pool.map(str, gen( # raises TypeError The difference is, that the line with imap prints an empty list, while the line with map raises an exception, as expected. Change the above snippet of code, adding additional yield statement: from multiprocessing.pool import ThreadPool pool = ThreadPool(10) def gen(): yield 1 yield 1 + '1' # here is an error print(list(pool.imap(str, gen( # raises TypeError print(list(pool.map(str, gen( # also would raise TypeError So now both map and imap will raise the exception, as expected. Therefore I suppose the behavior of imap showed in the first case is wrong. -- components: Library (Lib) messages: 280872 nosy: lev-veshnyakov priority: normal severity: normal status: open title: Imap from ThreadPool behaves unexpectedly type: behavior versions: Python 3.5 ___ Python tracker <http://bugs.python.org/issue28699> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28699] Imap from ThreadPool behaves unexpectedly
Changes by Lev Veshnyakov : -- nosy: +davin ___ Python tracker <http://bugs.python.org/issue28699> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
