New submission from Freek Dijkstra :
Summary:
multiprocessing.Pool contains a bug when the script is invoked with pdb.
Steps to reproduce:
Consider the following script:
```
from multiprocessing import Pool
def f(x):
return x*x
if __name__ == '__main__':
with Po
Change by Freek Dijkstra :
--
nosy: +macfreek
___
Python tracker
<https://bugs.python.org/issue9625>
___
___
Python-bugs-list mailing list
Unsubscribe:
Freek Dijkstra added the comment:
I don't think that this issue27227 and issue9625 are the same (although they
may have the same root cause, and I would be in favour of fixing both issues).
At least, I think the unit test are distinct:
This issue27227 is that argparse does not acc
Freek Dijkstra added the comment:
@r.david.murray
Quote from issue20083:
"You can also help me to remember to commit 11783 after the final release of
3.4.0."
Ping!
--
nosy: +macfreek
versions: +Python 3.5 -Python 3.4
___
Python trac
Freek Dijkstra added the comment:
> we want our message to get delivered regardless of whether or not smtputf8 is
> available.
This is not possible if the user specifies an (sender or recipient) email
address with non-ASCII characters and the first-hop mail system does not
support SM
Freek Dijkstra added the comment:
Since smtplib.quoteaddr() uses email.utils.parseaddr(), and the patch for issue
11783 fixes email.utils.parseaddr(), that patch will hopefully solve this issue
as well (though a test case wouldn't hurt for sure).
What I had not realised is that hostname
Freek Dijkstra added the comment:
Are you sure that issue 8489 is a duplicate? While both concern RFC 6531, the
patch for 8489 only seems to add test to check how smtplib.SMTP.login() handles
a username with non-ASCII characters. This issue concerns the
smtplib.SMTP.rcpt() (and indirectly
Freek Dijkstra added the comment:
Great to hear that a patch already exists (sorry I couldn't find in in the
tracker).
Feel free to close this issue as duplicate of issue 11783.
(As for the u"string", I wanted to distinguish it from b'string'. I don't use
Freek Dijkstra added the comment:
This issue deals with international domain names in email addresses (the part
behind the "@"). See issue 20084 for the issue that deals with the part before
the "@".
--
___
Python tracker
<
New submission from Freek Dijkstra:
smtplib has no support for non-ASCII user names in the From to To mail address.
The following two calls fail:
server.rcpt(u"όνομα@example.com"):
File smtplib.py, line 332, in send
s = s.encode("ascii")
UnicodeEncodeError: '
New submission from Freek Dijkstra:
smtplib has limited support for non-ASCII domain names in the From to To mail
address. It only works for punycode-encoded domain names, submitted as unicode
string (e.g. server.rcpt(u"u...@xn--e1afmkfd.ru").
The following two calls fail:
server.r
Freek Dijkstra added the comment:
Peter, first of all, thanks for your library. I didn't mention that before, but
should have.
I'm in favour of a pragmatic approach. I've only come across NATing for RFC
1918 and RFC 6598 addresses. While it can technically be done for other
Freek Dijkstra added the comment:
A bit odd questions: What is the is_private() function intended to accomplish?
I have been wondering what is_private() means, and how users of the library are
going to use this function. I've actually failed to come up with any sensible
use-case wit
Freek Dijkstra added the comment:
Edit: could you rephrase?
--
___
Python tracker
<http://bugs.python.org/issue17400>
___
___
Python-bugs-list mailing list
Unsub
Freek Dijkstra added the comment:
I don't understand your remark "I think it would be pretty surprising for
ipaddress to return True if it's not a network operator running the query."
--
___
Python tracker
<http://bug
Freek Dijkstra added the comment:
I was about to make the same suggestion as the OP.
Most users think of "private IP" addresses as NATed IP addresses. I think the
technical term is "forwardable, but not globally unique". Thus, the method of
least surprise would be that i
Freek Dijkstra added the comment:
I can confirm that both the problem exists and the patch works on Python 2.6
and 3.1. I love to see it committed.
--
nosy: +macfreek
___
Python tracker
<http://bugs.python.org/issue5
Freek Dijkstra added the comment:
If it would help to separate things, let me know, and I split this up in three
separate bug reports.
(For the record, knowing these limitations, I could work around it in my code,
so they are low priority for me; I just think that it will benefit other users
New submission from Freek Dijkstra :
I came across three limitation in the multiprocessing module that were not
handled correctly.
Attached is a file that reproduces the errors in minimal code. I tested them
with Python 2.6.5 and 3.1.2.
Expected result:
multiprocessing.Pool's promises
19 matches
Mail list logo
