[issue5824] SocketServer.DatagramRequestHandler Broken under Linux
New submission from Jim Dennis answr...@gmail.com: .../lib/python2.*/SocketServer.py in class DatagramRequestHandler contains the following comment: # XXX Regrettably, I cannot get this working on Linux; # s.recvfrom() doesn't return a meaningful client address. This is a poor way to document the limitation. Someone writing code and carefully adhering to the documentation will be presented with an exception that stems from this and forced to read source code for the standard libraries to understand why it's not behaving as documented. In Issue1767511 it was recommended that the finish() method only call sendto() if wfile.getvalue() returns a meaningful value. (The bug here is that this returns None under Linux and the default handler calls sendto on it anyway). Perhaps it would be better to raise an exception with a clear error message (Not supported on this platform) and to update the standard documentation to clarify the need to over-ride the .finish() method if one does NOT want a response automatically sent back. (The fact that finish() does a sendto() seems like a poor default for a UNIX domain socket --- for use with the UnixDatagramServer class --- in any event. That leads to a loop in .server_forever() where the instance is reading its own response). In fact the whole question of whether the DatagramRequestHandler should be used with a UnixDatagramServer is reasonable. If it's a nonsensical combination then perhaps some sort of check could be implemented to raise an exception ... or at least a sensible alternative should be added to the standard documentation. Example: #!/usr/bin/env python import SocketServer usock = '/var/tmp/pong' class PongHandler(SocketServer.DatagramRequestHandler): '''Play ping pong over datagram sockets ''' def handle(self): '''Respond to any request with Pong ''' pass def finish(self): '''Necessary under Linux to prevent: Exception: File /usr/lib/python2.5/SocketServer.py, line 588, in finish self.socket.sendto(self.wfile.getvalue(), self.client_address) TypeError: argument must be string or read-only character buffer, not ''' if self.wfile.getvalue(): SocketServer.DatagramRequestHandler.finish(self) if __name__ == '__main__': SocketServer.UnixDatagramServer(usock, PongHandler).serve_forever() ... and testing this with: #!/usr/bin/env python import socket USOCK = /var/tmp/pong if __name__ == '__main__': sock = socket.socket(socket.AF_UNIX, socket.SOCK_DGRAM) sock.sendto(Ping, USOCK) -- components: Library (Lib) messages: 86380 nosy: jimd severity: normal status: open title: SocketServer.DatagramRequestHandler Broken under Linux type: behavior versions: Python 2.4, Python 2.5, Python 2.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5824 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5824] SocketServer.DatagramRequestHandler Broken under Linux
Jim Dennis answr...@gmail.com added the comment: Addendum: What I said about the default sendto() in finish() causing a loop in server_forever() was wrong. I'd seen that behavior in an experimental variation of the code. The exceptions raised (and deficiencies in documentation) are the issue. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5824 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1109963] bdist_wininst ignores build_lib from build command
Mark Hammond mhamm...@users.sourceforge.net added the comment: So it looks like I broke the ability to override --build-lib :( Without testing, I think you might also need to handle the cross-compile case - the version may be the same, but the platform different. I know distutils is a PITA so might make this difficult, but it might be better that we only set build_lib if the user didn't - ie, trust the user knows what they are doing if they specify that option, even in these 'mismatched version/platform' cases. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1109963 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5819] Add PYTHONPREFIXES environment variable
Larry Hastings la...@hastings.org added the comment: Thanks for your battle-tested feedback, Mr. Bicking! I reply inline. The biggest problem is that the environmental variable is inherited by subprocesses. [...] Another problem is that scripts aren't really sticky with respect to the environment. [...] These are real-world problems I encountered with workingenv, and virtualenv has resolved them very reliably by instead using sys.executable to select the environment. Excellent points. PYTHONPREFIXES is not a virtualization cure-all; for a complete solution you clearly need an executable file for folks to hang their hat on. However: wouldn't PYTHONPREFIXES greatly simplify virtualenv? All you should need is an executable and a sitecustomize module. Your executable would set PYTHONPREFIXES as makes sense and run Python. Your usercustomize would: * set sys.executable, * set sys.prefix (and maybe sys.exec_prefix), * *unset* PYTHONPREFIXES, and * run the user's real sitecustomize if present. If this works reliably it would obviate most of the work virtualenv currently has to do. In fact I just tried this. A two-line shell script for python3, a twenty-line sitecustomize.py, installed lib/python3.1/config/Makefile and include/python3.1 in my virtualized environment, and I was able to install HeapDict for python3 using its setup.py. (PyPI lies, though; HeapDict doesn't work unmodified in python3. It calls callable(). But once I fixed that it ran fine.) So it passes a smoke-test at least. Also, it's hard to mix and match environments in this system. How so? I thought this proposal made it far easier to mix and match environments. PYTHONPREFIXES is a stack; push and pop environments as you like. Also with respect to the patch, for consistency there needs to be changes to distutils to make use of this variable. PYTHONUSERBASE included changes so that you can install based on that variable. Good call. I found it infuriating that setuptools didn't (still doesn't iirc) understand PYTHONUSERBASE, and would complain that the --prefix directory doesn't support .pth files. If this patch goes further I'll fix up distutils. Thanks again for your feedback! -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5819 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4111] Add DTrace probes
Robert Kern robert.k...@gmail.com added the comment: Is there any interest in my expanding the list of probes? Ruby has quite a few more than function-entry and function-return, to give some examples of what is possible: http://dev.joyent.com/projects/ruby-dtrace/wiki/Ruby+DTrace+probes+and+arguments I think that adding probes that correspond to PyTrace_LINE and PyTrace_EXCEPTION would be straightforward and worthwhile. PyTrace_C_* may also be worthwhile, but you can probably accomplish similar things with the normal pid probes if you know the C function names (although something like printing the name of a raised exception will probably require a dedicated probe). Adding probes to replicate what the LLTRACE configuration option did, but dynamically, might be interesting. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4111 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4111] Add DTrace probes
Jesús Cea Avión j...@jcea.es added the comment: Is there any interest in my expanding the list of probes? Definitively!!!. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4111 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1794] Hot keys must work in any keyboard layout
Guilherme Polo ggp...@gmail.com added the comment:
That bug report is talking about gtk and modifiers affecting bindings
(in the first comments at least), or maybe it even talks about your
problem but it is so long that I would ask to include the relevant parts
here.
Nevertheless, after reading your comments I came to the conclusion that
doing what you want is very unlikely to happen. To bind something in Tk
you have to a specify a string like Control-x, but to do what you
want, it would have to change to:
import Tkinter
def test(event):
if event.keysym_num == ord('x') and event.state 4:
print Ctrl-x!
root = Tkinter.Tk()
root.bind('KeyPress', test)
root.mainloop()
Maybe you can test this and verify if it works like you wanted. But I
really don't see IDLE changing to work like that.
--
components: +IDLE -Tkinter
nosy: +gpolo
type: - feature request
versions: -Python 2.5
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1794
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5825] Patch to add remove method to tempfile.NamedTemporaryFile
New submission from Miki Tebeka miki.teb...@gmail.com: Adding remove method to NamedTemporaryFile will reduce the need to import os.unlink when creating a NamedTemporaryFile with delete=False. -- components: Library (Lib) files: tempfile.diff keywords: patch messages: 86387 nosy: tebeka severity: normal status: open title: Patch to add remove method to tempfile.NamedTemporaryFile type: feature request versions: Python 2.7 Added file: http://bugs.python.org/file13752/tempfile.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5825 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5826] new unittest function listed as assertIsNotNot() instead of assertIsNotNone()
New submission from Mike Rooney mroo...@gmail.com: On http://docs.python.org/dev/py3k/whatsnew/3.1.html under unittest changes, you will find the last new function listed is assertIsNotNot() instead of assertIsNotNone() -- assignee: georg.brandl components: Documentation messages: 86388 nosy: georg.brandl, mrooney severity: normal status: open title: new unittest function listed as assertIsNotNot() instead of assertIsNotNone() versions: Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5826 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4111] Add DTrace probes
Skip Montanaro s...@pobox.com added the comment: Robert Is there any interest in my expanding the list of probes? Yes. Jeff Garrett (a guy I work with) added some more DTrace probes to a 2.4 source tree at work. I mentioned them in an earlier message. I'll check with him at work tomorrow and see about making sure they can be released. I think it's important to get Sun and Apple in sync as well. Maybe more important than adding new probes. (Though if the Python community drives the creation of new probes perhaps both will pick them up.) Skip -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4111 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3613] base64.encodestring does not actually accept strings
Matt Giuca matt.gi...@gmail.com added the comment: I've attached a patch which renames encodestring to encodebytes (keeping encodestring around as an alias). Updated test and documentation. I also renamed decodestring to decodebytes, because it also refuses to accept a string (only a bytes). I have an alternative suggestion, which I'll post in a separate comment (in a minute). -- Added file: http://bugs.python.org/file13753/encodestring_rename.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3613 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3613] base64.encodestring does not actually accept strings
Matt Giuca matt.gi...@gmail.com added the comment: Now, base64.encodestring and decodestring seem a bit weird because the Base64 encoded string is also required to be a bytes. It seems to me that once something is Base64-encoded, it's considered to be ASCII text, not just some byte string, and therefore it should be a str, not a bytes. (For example, they end with a '\n'. That's something which strings do, not bytes). Hence, base64.encodestring (which should be encodebytes) should take a bytes and return a str. base64.decodestring should take a str (required to be ASCII-only) and return a bytes. I've attached an alternative patch, encodebytes_new_types.patch (which, unlike my other patch, doesn't rename decodestring to decodebytes). This patch: - Renames encodestring to encodebytes. - Changes the output of encodebytes to return an ASCII str*, not a bytes. - Changes the input of decodestring to accept an ASCII str, not a bytes. * An ASCII str is a Unicode string with only ASCII characters. This isn't a proper patch (it breaks a lot of other code which I haven't bothered to fix). I'm just submitting it as an idea, in case this is something we want to do. Most likely not, due to the breakage. Also we have the same problem for the non-legacy functions, b64encode and b64decode, etc, so the problem is more widespread than just these two functions. -- Added file: http://bugs.python.org/file13754/encodebytes_new_types.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3613 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4111] Add DTrace probes
Robert Kern robert.k...@gmail.com added the comment: We could probably merge Apple's and Sun's probes without too much trouble. Apple simply extended function-entry to include the argcount in addition to Sun's (filename, funcname, lineno) arguments. We could use Apple's probe while retaining compatibility with Sun-oriented DTrace scripts already in existence. The two different function-returns are a bit of a problem. I recommend starting with Sun's argument list because there are already a number of quite useful scripts that use it in the DTraceToolkit. We could extend Sun's argument list to add the *object pointer, but I don't actually know of a use case. I haven't seen a script in the wild that uses it. It seems like it would be tricky to write something in a DTrace script that could make much use of it besides printing out the address. Maybe you could navigate your way down to the type name, but that might be unreliable. I suggest adding the *object pointer argument only if we can devise a use case or if one of the Apple folks pop up with one. I don't feel too bad making Apple devs modify a single character from their internal scripts if they don't make them public. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4111 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3565] array documentation, method names not 3.0 compliant
Matt Giuca matt.gi...@gmail.com added the comment: OK since the patches I submitted are now eight months old, I just did an update and re-applied them. I am submitting new patch files which don't change anything, but are patches against revision 71822 (should be much easier to apply). I'd still like to see doc+bytesmethods.patch applied (since it fixes method names which make no sense at all in Python 3.0 context), but since it's getting a bit late for that, I'll be happy for the doc-only patch to be accepted (which merely corrects the documentation which is still using Python 2.x terminology). -- Added file: http://bugs.python.org/file13755/doc-only.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3565 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3565] array documentation, method names not 3.0 compliant
Matt Giuca matt.gi...@gmail.com added the comment: Full method renaming patch. -- Added file: http://bugs.python.org/file13756/doc+bytesmethods.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3565 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5827] os.path.normpath doesn't preserve unicode
New submission from Matt Giuca matt.gi...@gmail.com: In the Python 2.x branch, os.path.normpath will sometimes return a str even if given a unicode. This is not an issue in the Python 3.0 branch. This happens specifically when it throws away all string data and constructs its own: os.path.normpath(u'') '.' os.path.normpath(u'.') '.' os.path.normpath(u'/') '/' This is a problem if working with code which expects all strings to be unicode strings (sometimes, functions raise exceptions if given a str, when expecting a unicode). I have attached patches (with test cases) for posixpath and ntpath which correctly preserve the unicode-ness of the input string, such that the new behaviour is: os.path.normpath(u'') u'.' os.path.normpath(u'.') u'.' os.path.normpath(u'/') u'/' I tried it on os2emxpath and plat-riscos/riscospath (the other two OS-specific path modules), and it already worked fine for them. Therefore, this patch fixes all necessary OS-specific versions of os.path. -- components: Library (Lib), Unicode files: normpath.patch keywords: patch messages: 86395 nosy: mgiuca severity: normal status: open title: os.path.normpath doesn't preserve unicode versions: Python 2.6, Python 2.7 Added file: http://bugs.python.org/file13757/normpath.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5827 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5827] os.path.normpath doesn't preserve unicode
Changes by Matt Giuca matt.gi...@gmail.com: -- type: - behavior ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5827 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4111] Add DTrace probes
Robert Kern robert.k...@gmail.com added the comment: James McIlree from Apple has informed me on dtrace-discuss that ustack helpers cannot currently be built on OS X. Bummer. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4111 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3565] array documentation, method names not 3.0 compliant
Martin v. Löwis mar...@v.loewis.de added the comment: I think this patch is unacceptable for Python 3.1. It is an incompatible change (removing a method), one would have to deprecate the method to be removed first. I also agree with Benjamin that a wider-audience approval of the deprecation would be required. I, myself, remain opposed to this change. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3565 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3565] array documentation, method names not 3.0 compliant
Matt Giuca matt.gi...@gmail.com added the comment: I agree with that -- too big a change to make now. But can we please get the documentation patch accepted? It's been waiting here for eight months with corrections to clearly-incorrect documentation. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3565 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
