[issue7834] socket.connect() no longer works with AF_BLUETOOTH L2CAP sockets
Yaniv Aknin added the comment: I wouldn't mind producing the patch, if Mathew is OK with this. -- nosy: +Yaniv.Aknin ___ Python tracker <http://bugs.python.org/issue7834> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7834] socket.connect() no longer works with AF_BLUETOOTH L2CAP sockets
Yaniv Aknin added the comment: I've zero experience with programming bluetooth (to be honest, I only tackled this bug because I'm learning how to contribute to Python and it seemed ultra-easy), so I'm not an authoritative source on whether such a 'loopback' test is possible. On #bluez in freenode I was told that generally no, there is no 'localhost' for BT sockets, and that a while ago there was a bluetooth emulation tool called 'hciemu' which is no longer maintained. I'm attaching the patch (it's just a oneliner), it passes regression though obviously isn't really tested by it... I suggest Mathew will try the patch out and see if it helps; we can decide how to proceed from there. -- keywords: +patch Added file: http://bugs.python.org/file16799/zero_l2cap_addr_struct.diff ___ Python tracker <http://bugs.python.org/issue7834> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6610] Subprocess descriptor debacle
Yaniv Aknin added the comment: It seems to me that subprocess is protected against this flaw. Python 2.x has a pure-Python implementation of the child logic (which is susceptible to an unrelated issue). Python 3.x has a C implementation which falls back to pure-Python if the former is not available. Both implementations test explicitly that they're not closing standard file descriptors after the dup2() call in the child. It is my understanding that test is sufficient, I couldn't reproduce the bug in Python, and thus I think this issue should be closed. All that said, there was no coverage in subprocess' test for this particular case (spawning a coprocess when the standard fds closed). I'm attaching a patch which adds a testcase to cover it. -- keywords: +patch nosy: +Yaniv.Aknin Added file: http://bugs.python.org/file16801/test_subprocess_with_standard_fds_closed.diff ___ Python tracker <http://bugs.python.org/issue6610> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2824] zipfile to handle duplicate files in archive
Yaniv Aknin added the comment: This affect 3.x as well. Regardless of the exact version this will come out in, I think the only proper solution is one with which we eventually, maybe in two versions' time, end up with a behaviour that raises an exception upon double insertion. Also, we should leave some switch to allow double insertions (as someone may /want/ to create a peculiar file). If we agree that's a worthy end goal, let's see what deprecation path we take to get there. I feel PEP4/PEP5 cover more significant changes to the language/stdlib than this, but in their spirit I propose the following concrete solution: For the nearest possible version let's issue a DeprecationWarning when adding dual files and provide a global switch that will change the DeprecationWarning into raising a relevant exception instead. For the version after that, let's remove the DeprecationWarning warning altogether and choose one of these behaviours: (a) a global switch that will raise by default (b) a switch in ZipFile's __init__() that will raise by default (c) a switch in ZipFile's write() that will raise by default I vote for (c), but I think the delta between the options is small. If this is agreeable with the audience, I'll be happy to produce a patch against 2.7 and 3.2 that will provide the chosen behaviour, as well as change tests and documentation accordingly. I realize that time is of the essence if we want this included in 2.7, and I'll be happy to do the work in a timely manner, so if you're interested kindly let me know what you feel while the iron's hot. Either way, I'll be happy to see it in any future version. Regarding the behaviour brtzsnr observed, I think it's a separate bug. I'll try to reproduce this behaviour, and open a separate ticket if I manage to do so. blah. Small bug, many words! -- nosy: +Yaniv.Aknin versions: +Python 3.2 ___ Python tracker <http://bugs.python.org/issue2824> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7978] SocketServer doesn't handle syscall interruption
Yaniv Aknin added the comment:
First, let me cast my vote in favour of leaving select() itself alone, it's
excessive to fix this issue with changing select().
Second, while exarkun's comments are accurate, I understand where pitrou is
coming from. EINTR is not a pathological case, but it's not commonplace,
either. I believe that on modern Unices (I tried Linux and OpenSolaris), the
default handler for SIGCHLD will restart interrupted calls. By default, SIGUSR1
and most sane others, will kill the process anyway. So I can understand the
purity of the argument that if a process sets a signal handler, it might just
as well set SA_RESTART and be done with it.
That said, Imagine I write a forking server with SocketServer which sets a
signal handler for SIGCHLD, and I don't set SA_RESTART because I don't think I
need to. I believe this is a valid real-world scenario where (a) I don't expect
an EINTER-related exception to be raised from SocketServer, (b) SocketServer
can actually do something about it, and (c) I doubt the old EINTR behaviour is
relied upon by anyone (now I'm /certain/ someone relying on this will
pop-up...). I think its a safer bet on behalf of SocketServer (and subprocess,
etc) to use something like untilConcludes.
If we agree so far, I believe that an implementation of untilConcludes *should*
be added to stdlib ("signal.restartable_call", anyone?). If people agree, I'd
be happy to produce the patch (trunk+py3k, doc+test). Other than SocketServer
and subprocess, anything else that should use "untilConcludes"?
Finally, to answer pitrou's second question, I'm pretty sure untilConcludes as
presented will not hurt other signal handlers. The interrupt handler will be
executed before returning to untilConcludes' loop and manually restarting the
call, so KeyboardInterrupt (or anything else signalistic) will behave as
expected.
I'm attaching a toy 3.x program to play with select() and EINTR, I used it in
writing this comment. Gee, it even has an OptionParser CLI to save you some
commenting-out.
--
nosy: +Yaniv.Aknin
Added file: http://bugs.python.org/file16813/eintr_safety.py
___
Python tracker
<http://bugs.python.org/issue7978>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7978] SocketServer doesn't handle syscall interruption
Yaniv Aknin added the comment: pitrou, re. test code: I actually started with the test code, so that part is done. I opted to use a forked SocketServer rather than threads. I'm not an expert on the low-level details of a multi-threaded process receiving threads, but it seems to me like there's a chicken and egg issue here: suppose we have threadA (blocking on select()) and threadB (managing the test and doing something like os.kill(os.getpid(), SIGFOO). I think by definition the thread running when the signal is received is threadB (since it sent the signal), and I'm not sure threadA will be interrupted properly that way (threads are sneaky, now aren't they). So I cleaned up test_socketserver.py a bit, split it to a base test case and concrete test cases, and added a separate test case which uses os.fork() rather than threads and tests that way. The attached patch is against recent py3k and includes both neologix's patch (adapted to py3k) and the added test code. If this looks good, I'll easily backport it to 2.x/trunk. spiv, re. handling timeout in select: You're very right, and I'm not sure how we should handle it if we want to take the "untilConcludes" code that is currently shared between subprocess.py and socketserver.py and move it outside. For subprocess' and socketserver's specific cases, the naive implementation which doesn't handle timeouts is OK, because they don't use the timeout parameter anyway. Moving it outside warrants more discussion. Remember this isn't just about select() - it's a general user-space-restarter for any of the myriad of "slow" system calls that might be interrupted. There is some tension between elegance and even feasibility of correct implementation vs. the wrapper hiding functionality of some of these system calls. You could argue that if the user of the wrapper is unhappy about the lost functionality, they can make their own wrapper. Unless we can reach a resolution quickly, my gut feeling is that the current patch should be applied as-is and this issue be closed. A new issue along the lines of "Extract duplicate interruption-restart code to a relevant module and review stdlib for unprotected select() calls" should be opened instead. Your thoughts? -- Added file: http://bugs.python.org/file16841/socketserver_eintr_py3k.diff ___ Python tracker <http://bugs.python.org/issue7978> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2824] zipfile to handle duplicate files in archive
Yaniv Aknin added the comment: Attached is the addition of the 'low_level' parameter to ZipFile. Included are the parameter, a global switch controlling whether the parameter will raise an Exception or trigger a DeprecationWarning (the latter, for now), updated tests and updated documents. I didn't run test_zipfile64, I can't say for sure it works but I have no reason to believe it doesn't. Changes are against py3k; let me know what you think, I'll backport to trunk. -- keywords: +patch Added file: http://bugs.python.org/file16843/low_level_zipfile.diff ___ Python tracker <http://bugs.python.org/issue2824> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6457] subprocess.Popen.communicate can lose data from output/error streams when broken input pipe occures
Yaniv Aknin added the comment: I've updated the sample code to run with Python 3 and tested on Ubuntu 9.10 with and without setting subprocess._has_poll = False. As expected, when using poll() the sample runs correctly. When not using poll() the sample breaks (sometimes no data, sometimes some data; oddly, it seems the 'some data' variant appears only when I strace the process, probably because it slows things down). I suggest this be committed against 3.2 as well, but I don't know how these things are usually done; should I produce a separate patch which ports the latest patch currently posted in this thead against py3k? Or will this be done by whomever applies the patch? -- nosy: +Yaniv.Aknin versions: +Python 3.2 ___ Python tracker <http://bugs.python.org/issue6457> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8538] Add ConfigureAction to argparse
Changes by Yaniv Aknin : -- nosy: +Yaniv.Aknin ___ Python tracker <http://bugs.python.org/issue8538> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7978] SocketServer doesn't handle syscall interruption
Changes by Yaniv Aknin : Removed file: http://bugs.python.org/file16841/socketserver_eintr_py3k.diff ___ Python tracker <http://bugs.python.org/issue7978> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7978] SocketServer doesn't handle syscall interruption
Yaniv Aknin added the comment: While bda's usecase is indeed fixed is recent versions, I want to point out the issue still exists in a recent py3k checkout. I've updated my patch to apply cleanly against recent py3k (and made less structural changes to test_socketserver.py; I still think it has an archaic unittest structure but I want this patch to remain relevant a bit longer, maybe fix the structure at a later time). Again, I argue that resolving the general case (a generic untilConcludes to be exposed in stdlib) is hard and that we have a patch review worthy (IMO) solution at hand. Let's apply it (and possibly open a separate ticket for the generic case, if that's deemed interesting). -- Added file: http://bugs.python.org/file17314/socketserver_eintr_py3k_updated.diff ___ Python tracker <http://bugs.python.org/issue7978> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8538] Add ConfigureAction to argparse
Yaniv Aknin added the comment: I'm looking into making a patch from this for py3k, and have the following observations: 1. I agree with merwok, at the moment the monolithic ConfigureAction is a bit excessive for most uses (other than maybe emulating ./Configure...). I vote we split it to FlagAction and ConfigureAction. 2. I don't think this should be added as an argparse builtin/registered action (like action='store' or action='count'), but rather as a ready-made user-action in a separate namespace (from argparse.actions import FlagAction) Given feedback that these two decisions seem sane, I'd be happy to produce a patch against recent py3k. -- ___ Python tracker <http://bugs.python.org/issue8538> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4106] multiprocessing occasionally spits out exception during shutdown
Yaniv Aknin added the comment:
Ugh. Not 100% sure it's related, but I've been getting a similar traceback when
running pip's test suite (python setup.py test) on OSX 10.6.8 with Python 2.7.2.
Traceback (most recent call last):
File
"/usr/local/Cellar/python/2.7.2/Frameworks/Python.framework/Versions/2.7/lib/python2.7/atexit.py",
line 24, in _run_exitfuncs
func(*targs, **kargs)
File
"/usr/local/Cellar/python/2.7.2/Frameworks/Python.framework/Versions/2.7/lib/python2.7/multiprocessing/util.py",
line 284, in _exit_function
info('process shutting down')
TypeError: 'NoneType' object is not callable
Obviously it's not the exact same bug as fixed here, but Googling the traceback
led me here and I do think it's the same genre of bug, i.e., multiprocessing's
use of forking leads to issues when atexit is called (wasn't sure whether to
open it here or #9207). Also, see
https://groups.google.com/forum/#!topic/nose-users/fnJ-kAUbYHQ, it seems other
users of the nose testsuite ran into this.
I'm afraid I won't have time to look much further into this (the reason I'm
running pip's testsuite is that I'm already trying to make a contribution to
pip...), but I thought it's best to at least mention it somewhere.
--
nosy: +Yaniv.Aknin
___
Python tracker
<http://bugs.python.org/issue4106>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3445] Ignore missing attributes in functools.update_wrapper
Yaniv Aknin added the comment: Shouldn't this be fixed in 2.7 as well? It's a bug, it's in the wild, and it's causing people to do ugly (and maybe not 100% reliable) things like https://code.djangoproject.com/browser/django/trunk/django/utils/decorators.py#L68 -- nosy: +Yaniv.Aknin ___ Python tracker <http://bugs.python.org/issue3445> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8538] Add FlagAction to argparse
Change by Yaniv Aknin : -- nosy: -Yaniv.Aknin ___ Python tracker <https://bugs.python.org/issue8538> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6610] Subprocess descriptor debacle
Yaniv Aknin added the comment: I think if the test is conducted without closing stderr, it will only check that stdin/stdout are handled correctly (you could assume that if one handled stdin/stdout correctly, they did the same with stderr). However, since I've used a context manager (_NoStandardFds) to handle the closing/restoration of the standard fds, I think the benefit (fuller test coverage) outweighs the cost (potentially harder debugging if there's a problem with the test); if I'm not mistaken, the context manager should restore your fds before the default exception handler writes to stdout (at least in the parent and the child prior to exec()). n.b.: I've also created a Rietveld issue for this patch: http://codereview.appspot.com/1227041/show -- ___ Python tracker <http://bugs.python.org/issue6610> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8749] Cruft in object.c: PyObject_GenericGetAttr
New submission from Yaniv Aknin :
While reading the source I saw that recent py3k has this in Objects/object.c
(reasonably recent trunk has it as well):
#if 0 /* XXX this is not quite _PyType_Lookup anymore */
/* Inline _PyType_Lookup */
{ ... removed ...
}
#else
descr = _PyType_Lookup(tp, name);
#endif
This was commented out (on trunk, I assumed on py3k it was for the same reason)
by amaury.forgeotdarc on revision 59943, when a patch to the real
_PyType_Lookup was applied.
I think it can be safely removed.
--
components: Interpreter Core
messages: 105967
nosy: Yaniv.Aknin
priority: normal
severity: normal
status: open
title: Cruft in object.c: PyObject_GenericGetAttr
versions: Python 2.7, Python 3.2
___
Python tracker
<http://bugs.python.org/issue8749>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8749] Cruft in object.c: PyObject_GenericGetAttr
Yaniv Aknin added the comment: Oops, of course I meant r59944, off by one. :) -- ___ Python tracker <http://bugs.python.org/issue8749> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8874] py3k documentation mentions deprecated opcode LOAD_LOCALS
New submission from Yaniv Aknin : The documentation of the dis module mentions LOAD_LOCALS, which used to exist in Python 2.x and I believe was removed from py3k (doesn't appear in recent Include/opcode.h). The exact offending section is: http://docs.python.org/py3k/library/dis.html#opcode-LOAD_LOCALS I think it should just be edited out. -- assignee: d...@python components: Documentation messages: 106869 nosy: Yaniv.Aknin, d...@python priority: normal severity: normal status: open title: py3k documentation mentions deprecated opcode LOAD_LOCALS versions: Python 3.1, Python 3.2, Python 3.3 ___ Python tracker <http://bugs.python.org/issue8874> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
