[issue35837] smtpd PureProxy breaks on mail_options keyword argument
New submission from Sjoerd :
According to https://python.readthedocs.io/en/stable/whatsnew/3.5.html:
The SMTPServer class now advertises the 8BITMIME extension (RFC 6152) if
decode_data has been set True. If the client specifies BODY=8BITMIME on the
MAIL command, it is passed to SMTPServer.process_message() via the mail_options
keyword. (Contributed by Milan Oberkirch and R. David Murray in bpo-21795.)
This means that process_message gets a mail_options kwarg. However, the smtpd
PureProxy and MailmanProxy don't take keyword arguments, which results in an
exception.
One way to trigger this is to run a debug mailserver and send a mail to it:
$ python3 -m smtpd -n
error: uncaptured python exception, closing channel <__main__.SMTPChannel
connected ('::1', 52007, 0, 0) at 0x10e7eddd8> (:process_message() got an unexpected keyword argument
'mail_options'
[/usr/local/Cellar/python/3.7.2_1/Frameworks/Python.framework/Versions/3.7/lib/python3.7/asyncore.py|read|83]
[/usr/local/Cellar/python/3.7.2_1/Frameworks/Python.framework/Versions/3.7/lib/python3.7/asyncore.py|handle_read_event|422]
[/usr/local/Cellar/python/3.7.2_1/Frameworks/Python.framework/Versions/3.7/lib/python3.7/asynchat.py|handle_read|171]
[/usr/local/Cellar/python/3.7.2_1/Frameworks/Python.framework/Versions/3.7/lib/python3.7/smtpd.py|found_terminator|386])
--
components: Library (Lib)
messages: 334424
nosy: Sjoerder, giampaolo.rodola, r.david.murray
priority: normal
severity: normal
status: open
title: smtpd PureProxy breaks on mail_options keyword argument
versions: Python 3.6, Python 3.7, Python 3.8
___
Python tracker
<https://bugs.python.org/issue35837>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35837] smtpd PureProxy breaks on mail_options keyword argument
Change by Sjoerd : -- nosy: +samuelcolvin ___ Python tracker <https://bugs.python.org/issue35837> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19012] liburl2: bad proxy configuration throws "getaddrinfo" error
New submission from Sjoerd:
I'm sorry for providing very little information, but I don't have the system at
hand anymore. Therefore I will try to reproduce what I know, hoping that you
recognise the problem. If not, I will get back to the system and try to obtain
the necessary information.
Calling liburl2.openurl('http://www.google.com') gave me an getaddrinfo error.
Therefore, I checked my DNS configuration, which seemed okay and I issued a
socket.getaddrinfo('www.google.com'), which correctly returned an IP address.
Finally, I found out that I had an old, non-existing (?) proxy configuration in
the Windows registry (that indeed turned up when calling liburl2.getproxies()).
Removing the proxy configuration from my Windows registry solved the problem.
Is it preliminary to conclude that the getaddrinfo error may actually mean
several things (not only a simple getaddrinfo problem)? If so, I suggest that
the error message be broadened ("DNS lookup or proxy problem"), because it took
me several hours to find the proxy problem.
--
components: Library (Lib)
messages: 197629
nosy: SjoerdOptLand
priority: normal
severity: normal
status: open
title: liburl2: bad proxy configuration throws "getaddrinfo" error
type: behavior
versions: Python 2.7
___
Python tracker
<http://bugs.python.org/issue19012>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19012] liburl2: bad proxy configuration throws "getaddrinfo" error
Sjoerd added the comment: That happens when citing things from the top of my head... it is not liburl2 but urllib2 that I used, excuse me. (And urlopen instead of openurl...) From http://docs.python.org/2/library/urllib2.html it seems to be a Standard Library module to me, am I mistaken? If so, how do I find the urllib2 maintainers? -- ___ Python tracker <http://bugs.python.org/issue19012> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6425] imaplib.IMAP4.fetch() is missing documentation for message_set parameter
New submission from Sjoerd : The message_set parameter imaplib.IMAP4.fetch(message_set, message_parts) is not a set or list, but a comma-separated string, it seems. This could use some documentation. -- assignee: georg.brandl components: Documentation messages: 90165 nosy: Sjoerder, georg.brandl severity: normal status: open title: imaplib.IMAP4.fetch() is missing documentation for message_set parameter versions: Python 2.6 ___ Python tracker <http://bugs.python.org/issue6425> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6426] imaplib.IMAP4 "command illegal in this state" is unhelpful error message
New submission from Sjoerd : If you do not IMAP4.select(), you get the following error: imaplib.error: command SEARCH illegal in state AUTH. This does not inform the user that he has to do IMAP4.select(). Better would be: imaplib.error: command SEARCH illegal in state AUTH, allowed in state SELECTED. See also: http://mail.python.org/pipermail/patches/2006-December/021308.html -- components: Library (Lib) messages: 90166 nosy: Sjoerder severity: normal status: open title: imaplib.IMAP4 "command illegal in this state" is unhelpful error message type: behavior versions: Python 2.5 ___ Python tracker <http://bugs.python.org/issue6426> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6425] imaplib.IMAP4.fetch() is missing documentation for message_set parameter
Sjoerd added the comment: Thanks, I missed that. I only read the documentation for the methods. -- ___ Python tracker <http://bugs.python.org/issue6425> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6426] imaplib.IMAP4 "command illegal in this state" is unhelpful error message
Sjoerd added the comment: See http://bugs.python.org/issue1605192 -- ___ Python tracker <http://bugs.python.org/issue6426> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3216] errors in msilib documentation
New submission from Sjoerd Mullender <[EMAIL PROTECTED]>: There are several errors in the msilib documentation. I'm sure I haven't found them all, but here are some: - add_data is documented to have two arguments. In reality it has three. - Execute on a View object is documented to have an optional argument. In reality it has a single required argument whose value may be None. - When I click on any of the references to Microsoft documentation, I get a page in Japanese. This is possibly more due to Microsoft than anything else (the links do contain en-us so it is a tad surprising). - There is extremely little information on how to actually use the module. -- assignee: georg.brandl components: Documentation messages: 68831 nosy: georg.brandl, sjoerd severity: normal status: open title: errors in msilib documentation versions: Python 2.5 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3216> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3216] errors in msilib documentation
Sjoerd Mullender <[EMAIL PROTECTED]> added the comment: Today the links to Microsoft documentation go to English language pages, so that part of the bug report can be skipped. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3216> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7966] mhlib uses deprecated module
Sjoerd Mullender added the comment: What's difficult about just doing: import mhlib ? That's all it takes to get the warning. -- ___ Python tracker <http://bugs.python.org/issue7966> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7966] mhlib does not emit deprecation warning
Sjoerd Mullender added the comment: mhlib is not officially deprecated, if I may believe PEP 4. Therefore I do not agree with the change that was made to this bug report. As far as I am concerned, the bug remains that mhlib uses a deprecated module. -- ___ Python tracker <http://bugs.python.org/issue7966> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8090] PEP 4 should say something about the standard library
New submission from Sjoerd Mullender : When a module or feature is deprecated, all uses of the deprecated module/feature should be removed from the non-deprecated part of the distribution (and, I would argue, also from the other deprecated modules). I think PEP 4 should say something to this effect. I suggest adding a sentence to the section "Procedure for declaring a module deprecated", something like: "The proposal MUST include patches to remove any use of the deprecated module from the standard library." -- assignee: georg.brandl components: Documentation messages: 100671 nosy: georg.brandl, sjoerd severity: normal status: open title: PEP 4 should say something about the standard library ___ Python tracker <http://bugs.python.org/issue8090> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8090] PEP 4 should say something about the standard library
Sjoerd Mullender added the comment: It was discussed on python-dev. It was suggested to submit a bug report on PEP 4. See http://mail.python.org/pipermail/python-dev/2010-February/097772.html. -- ___ Python tracker <http://bugs.python.org/issue8090> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4591] uid/gid problem in os.chown
New submission from Sjoerd Mullender <[EMAIL PROTECTED]>:
On Fedora 8 and 10 using Python 2.5.1 and 2.5.2 (64 bit):
$ grep nfsnobody /etc/passwd
nfsnobody:x:4294967294:4294967294:Anonymous NFS
User:/var/lib/nfs:/sbin/nologin
So the UID of nfsnobody is 4294967294 (-2 if viewed as signed 32-bit int).
>>> import pwd, os
>>> print pwd.getpwnam('nfsnobody').pw_uid
4294967294
>>> os.chown('some file', pwd.getpwnam('nfsnobody').pw_uid,
pwd.getpwnam('nfsnobody').pw_gid)
Traceback (most recent call last):
File "", line 1, in
OverflowError: signed integer is greater than maximum
The reason for this error is that os.chown uses the "i" format to
convert the second and third arguments. But the valued do not fit in a
32-bit signed integer. uid_t and gid_t are defined as unsigned
quantities on this system.
The bug does not occur on 32 bit Fedora since there the uid and gid of
nfsnobody are 65534.
--
components: Library (Lib)
messages: 77301
nosy: sjoerd
severity: normal
status: open
title: uid/gid problem in os.chown
type: behavior
versions: Python 2.5
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue4591>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4591] uid/gid problem in os.chown
Sjoerd Mullender <[EMAIL PROTECTED]> added the comment: I'm sure you meant 2^32-2 ;-). The "fix" to use long doesn't seem right to me either. unsigned int is a better match with uid_t and gid_t. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4591> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17142] test_any calls all() instead of any()
New submission from Sjoerd Langkemper: In test_builtin.py, on the fourth in the test_any() function: self.assertRaises(RuntimeError, all, TestFailingIter()) I think this should be: self.assertRaises(RuntimeError, any, TestFailingIter()) -- components: Tests messages: 181524 nosy: sjoerder priority: normal severity: normal status: open title: test_any calls all() instead of any() type: enhancement versions: Python 3.3 ___ Python tracker <http://bugs.python.org/issue17142> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2245] aifc cannot handle unrecognised chunk type "CHAN"
Sjoerd Mullender added the comment: I wrote the module 16 years ago, but haven't done anything with AIFF files for probably at least 10, so I can't really comment on the merits of the two solutions (delete _skiplist or add CHAN to _skiplist). I'm fine with either. However, the proposed patch leaves an `else: pass' which should be removed if the patch is adopted. -- ___ Python tracker <http://bugs.python.org/issue2245> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12618] py_compile cannot create files in current directory
Sjoerd de Vries added the comment:
Hi Éric,
There you go, adapted from http://effbot.org/librarybook/py-compile.htm :
# File: py-compile-example-1.py
import py_compile
# explicitly compile this module
py_compile.compile("py-compile-example-1.py","py-compile-example-1.pyc")
Also, I tested and this bug is present neither on 3.1 nor on 2.x
cheers
Sjoerd
--
___
Python tracker
<http://bugs.python.org/issue12618>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12618] py_compile cannot create files in current directory
New submission from Sjoerd de Vries : When you specify cfile to be in the current directory, an error occurs (line 133). I have fixed the file, see attached -- components: Library (Lib) files: py_compile.py messages: 140940 nosy: sjdv1982 priority: normal severity: normal status: open title: py_compile cannot create files in current directory type: behavior versions: Python 3.2 Added file: http://bugs.python.org/file22722/py_compile.py ___ Python tracker <http://bugs.python.org/issue12618> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12618] py_compile cannot create files in current directory
Sjoerd de Vries added the comment: The attached file just works. You can diff with trunk, or wherever python devs store the latest version. -- ___ Python tracker <http://bugs.python.org/issue12618> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12618] py_compile cannot create files in current directory
Sjoerd de Vries added the comment: Makes no sense to me: since I don't have the trunk version, I can only diff -c against 3.2 release. Doing a diff against trunk is 1 sec of work for you. But I am just being a helpful user; so if a diff is what you want, here it is. No trouble for me, since I am on Linux. Not a very nice policy to any helpful Windows users, though: they won't have diff installed and they would waste an hour or so on this. -- keywords: +patch Added file: http://bugs.python.org/file22724/py_compile.diff ___ Python tracker <http://bugs.python.org/issue12618> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12618] py_compile cannot create files in current directory
Sjoerd de Vries added the comment: Good to hear that the patch is helpful. Again, I am just trying to be a helpful user, making a (very very little) contribution to make Python better. I am not a Python dev at all: Python is already awesome enough for me, no desire to change it :-) I just want to say that a "we only accept patches" policy is not being very nice to similar helpful users on Windows, who don't have diff or Mercurial but who did manage to fix a file themselves. I did indicate "Python 3.2" in the bug report, maybe something went wrong. -- ___ Python tracker <http://bugs.python.org/issue12618> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25537] Call `isinstance` instead of `issubclass` during exception handling
New submission from Sjoerd Job Postmus: Currently Python2.7 calls `PyObject_IsSubclass` during exception handling. This allows some virtual-base-class machinery to make Python believe a certain class should match an exception while it in reality does not. However, this does not necessarily give one really enough granularity when dealing with base libraries which are not as granular in raising exceptions as one would like (the Python base library before PEP3151 comes to mind). Currently I used the trick of calling `isinstance(sys.exc_info()[1], cls)` in the `__subclasscheck__`, which is sort-of a great work-around.[*]. This method is great for sort-of emulating PEP3151 in Python2.7, and similar work can be done for other libraries: making the exception classes appear more granular based on properties of the instance of the exception. My belief is that by calling the `isinstance` during exception handling, one can use virtual base classes (or should I say virtual base instances) to their fullest potential in writing cleaner code. I think this is important because exception-handling is already a place where messy code is likely to occur, and we need all the support we can get in making it just a tad less messy.[**] Note: Python3.5 calls `PyType_IsSubtype`, which has #12029 open for a change towards `PyObject_IsSubclass`. As soon as (or before) that's implemented, I'd like to propose a similar change for Python3.5+: call `PyObject_IsInstance` when the raised exception is an instance. [*] See https://github.com/sjoerdjob/exhacktion/ for how I use the described hack to somewhat emulate PEP3151 in Python2.7. [**] One question that comes to mind is: why not just write a wrapper around the offending library. (1): If it's the base library, almost nobody is going to bother. (2): even if it's not the base library, the wrapper will likely be even more function calls, which may cost performance in both the good and the bad cases, instead of just the bad cases. -- components: Interpreter Core messages: 253946 nosy: sjoerdjob priority: normal severity: normal status: open title: Call `isinstance` instead of `issubclass` during exception handling type: enhancement versions: Python 2.7, Python 3.5, Python 3.6 ___ Python tracker <http://bugs.python.org/issue25537> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
