Re: [Python-Dev] buildbot
Brian Warner wrote: This makes it much easier to implement things like the Force Build button, and allows the same status-retrieving API to be used by all the different status-delivery modules: web, IRC, email, PB. Certainly: I can easily believe that this is easier from a development point of view. I can also accept that this is the only way if you want to trigger things through the Web (such as the Force Build interface). However, this interface was the first thing I turned off, because there is too much potential for abuse. The slaves are (in our case) donated resources, sometimes in machines that also serve other purposes. The donors need to know what precisely will run on their machines, and when precisely that will happen, so Force build is disabled. The reason I want static pages is for security concerns. It is not easy whether buildbot can be trusted to have no security flaws, which might allow people to start new processes on the master, or (perhaps worse) on any of the slaves. I know I could limit the Twisted webserver to localhost using firewalling/iptables (and I will need to if there is no other option); just having it generate static pages would have been more convenient. BTW, the same security concern applies to the IRC listener and the slave listeners: how do I know that nobody can take over my infrastructure using carefully-crafted messages? I could study the entire protocol stack to convince myself, but I would prefer if there was an easy answer, like: this is the set of operations callable through twisted, and these are the preconditions for calling them. For the IRC, this is easy to see (just inspect all command_ procedures), but what about the slaves port? It's not the greatest solution, but it might let you add more Builders without making the display unworkably complex. Thanks! so far, we only have 8 lanes, which is still managable. If size increases, I come back to these ideas. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Logging enhancements
Shane: Vinay Sajip wrote: I'd be interested in your approach to solve this. To be compatible with an external tool like logrotate, all a daemon needs to do is close and reopen log files at about the same time log rotation happens. To handle this use case, I suggest the logging module needs a function named reopen(), which daemons can call upon receipt of a signal. The reopen function will find all handlers with open files and ask them to reopen. FWIW, such an operation is generally useless on a Windows system, as a file can not be renamed while it is in use. zope-dev went through this discussion recently, and in the interests of still allowing an external tool (similar to logrotate) to have the rotation logic instead of Python or Zope, we came up with a slightly different scheme for Windows; when requested, Zope will temporarily close the file and rename it to the original name + .last (ignoring any errors.) It then reopens the original name. In most cases, this will leave a .last file around which can be processed by an external tool, but is also safe in the face of failure. IMO, we should consider implementing something like the above; it is still preferable to have a standard solution for Windows, even if different than other platforms, rather than requiring everyone to solve this problem themselves. I'd even suggest sticking with the name 'reopen()' is still OK, noting the differences in the documentation, but that is a secondary issue. Cheers, Mark ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] buildbot
On Tue, Jan 10, 2006 at 09:15:56AM +0100, Martin v. Löwis wrote: [...] I know I could limit the Twisted webserver to localhost using firewalling/iptables (and I will need to if there is no other option); just having it generate static pages would have been more convenient. For this part at least, it's easier than that; you can pass interface='127.0.0.1' to the relevant listenTCP or TCPServer call, so that it will only bind that port to localhost. -Andrew. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New PEP: Using ssize_t as the index type
Martin v. Löwis wrote: Armin Rigo wrote: This would do the right thing for = 2.4, using ints everywhere; and the Python.h version 2.5 would detect the #define and assume it's a 2.5-compatible module, so it would override the #define with the real thing *and* turn on the ssize_t interpretation of the '#' format character. This would be very similar to the PY_SIZE_T_CLEAN approach, except that it would also help to detect spelling mistakes. From an implementation point of view, the real challenge is to give PyArg_ParseTuple a different meaning; I do this be #defining it to PyArg_ParseTupleSsize_t (to preserve binary compatibility for the original interpretation of ParseTuple). Putting additional flags arguments in the entire code is also quite hackish. I still don't like the idea of a magic #define that changes the behavior of '#include Python.h', but I admit I don't find any better solution. I suppose I'll just blame C. More precisely, the printf style of function calling, and varargs functions. ISO C is pretty type safe, but with varargs functions, you lose that completely. I still hope I can write a C parser some day that does ParseTuple/BuildValue checking. At least gcc does check the parameter types and generates warnings for wrong vararg parameters passed to printf() et al. We definitely need a clean solution for this. Otherwise, authors who want to support more than just the latest Python release will run into deep trouble. Note that the branch also has other changes of output parameter types which will cause problems in extensions (not only extensions implementing the sequence protocol as the PEP suggests, but also ones using it as well as extensions implementing or using the buffer protocol and the slicing protocol). These are not as easily avoidable as the PyArg_ParseTuple() problem which could be dealt with by a a new parser marker for ssize_t lengths (with the '#' marker casting the argument to an int). I don't see a good solution for these other than introducing a set of new APIs (and maybe doing some macro magic as Martin did for PyArg_ParseTuple()). Due to the fact that changes in the types of output parameters require changes in the extension variable type layout itself, they introduce a large number of type changes in the extension and make writing backwards compatible extensions harder than necessary. Furthermore, all extensions for Python 2.4 would have to be ported to the new Python API and porting is not going to be a simple recompile, but will require C skills. We'd also have to make sure that old extensions don't just import with a warning, since the change will introduce buffer overflows and seg faults in extensions that are not aware of the change. Martin, please add the above points to the PEP. I'd also like to see it published, because it's hard to track a PEP in the mailing Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 10 2006) Python/Zope Consulting and Support ...http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r41972 - python/branches/ssize_t/Objects/funcobject.c
Martin v. Löwis [EMAIL PROTECTED] writes: Well, you know that LOAD_CONST only supports 2**31 constants, so truncation to int is currently safe (I hope that the compiler detects cases where somebody tries to create more than 2**16 constants). Easy enough to check: eval(repr(range(10))) (It works). Cheers, mwh -- Q: What are 1000 lawyers at the bottom of the ocean? A: A good start. (A lawyer told me this joke.) -- Michael Ströder, comp.lang.python ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] test_curses
Georg Brandl [EMAIL PROTECTED] writes: Michael Hudson wrote: Georg Brandl [EMAIL PROTECTED] writes: The call to curses.setupterm() leaves my terminal in a bad state. Hmm. The reset program outputs: Erase set to delete. Kill set to control-U (^U). Interrupt set to control-C (^C). It always says that :) (unless you've messed with stty, I guess) Well, when I do a reset without meddling with the terminal, it says nothing, at least on my box. Oh. Maybe I'm out of date. And, there's more: Ctrl+D doesn't work, Ctrl+C doesn't work. Right, so it definitely sounds like the terminal is in raw mode. Doesn't the setupterm() have to be paired with something like shutdownterm()? Not as far as my memory of curses goes. From the man page: The setupterm routine reads in the terminfo database, initializing the terminfo structures, but does not set up the output virtualization structures used by curses. What platform are you on? Linux 2.6, ncurses 5.5, TERM=xterm. Well, this still has the faint whiff of impossibility about it. Are you sure it's setupterm() that's doing the damage? Can you reproduce interactively? Cheers, mwh -- You can remove divmod() when I'm dead. Before then, it stays. I'm sure all will agree that's a reasonable compromise. -- Tim Peters negotiating on python-dev ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] sudo security hole w/ potential Python connection
Got this from a Google alert overnight. It's not really a Python problem (it's a sudo problem), but it's probably not a bad idea to understand the implications. SUDO Python Environment Cleaning Privilege Escalation ... Secunia - UK ... This can be exploited by a user with sudo access to a python script to gain access to an interactive python prompt via the PYTHONINSPECT environment variable ... http://secunia.com/advisories/18358/ Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python-Dev Digest, Vol 30, Issue 32
please stop email upto further request. thanking youSend instant messages to your online friends http://in.messenger.yahoo.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Tkinter
Hello, I would like to know if Tkinter is being developed/maintained. It appears the latest book on Tkinter by John E. Grayson published in 2000 is the only book resource on Tkinter. The publisher suggested that QtPy (http://www.riverbankcomputing.co.uk/pyqt/) and wxPython ( http://www.wxpython.org/ ) have replaced Tkinter. Could you provide an update on Tkinter Joseph ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Tkinter
On 1/10/06, Aahz [EMAIL PROTECTED] wrote: On Tue, Jan 10, 2006, Rodrigues, Joseph wrote: I would like to know if Tkinter is being developed/maintained. It appears the latest book on Tkinter by John E. Grayson published in 2000 is the only book resource on Tkinter. This message is not appropriate for python-dev. Please use comp.lang.python (or python-list). But for sure, Tkinter is still being maintained by the Python developers (mainly MvL I believe). If it appears stagnant that's probably because Tcl/Tk itself isn't changing much. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Buildbot-devel] Re: buildbot
I have security concerns as well, but not in buildbot itself. My project is restricted even withinz the company I work for so I need the buildbot web server to only be available to certain people. HTTPS access would be nice too. TwistedWeb doesn't seem to have support for either HTTPS or authentication so I've been forced to hide it by putting it on a non-standard port. Very weak. Actually twisted-web provides pretty good support for both SSL and password-based authentication, but my own web skills are too weak to really figure out how to take advantage of them. I've been hoping to address this in the web status page cleanup item on the TODO list, but other bugs and features keep getting in the way. There are a couple of examples of setting up an HTTPS website in the twisted docs, in case you're interested. I think the changes would only have to go into Waterfall.setup, probably just replacing the internet.TCPServer() call to something involving SSL. The authentication stuff is called guard, and I think it would involve inserting an additional password-checking resource between the top-level server.Site and the primary html.StatusResource object. But, as I said, my twisted-web-foo is not strong, so I could be completely wrong about this. cheers, -Brian ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] sudo security hole w/ potential Python connection
Methinks anyone using sudo to allow non-root-users to execute specific scripts without giving them full root perms is relying on security by obscurity at this point. (Ditto for setuid Python scripts BTW.) --Guido On 1/10/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Got this from a Google alert overnight. It's not really a Python problem (it's a sudo problem), but it's probably not a bad idea to understand the implications. SUDO Python Environment Cleaning Privilege Escalation ... Secunia - UK ... This can be exploited by a user with sudo access to a python script to gain access to an interactive python prompt via the PYTHONINSPECT environment variable ... http://secunia.com/advisories/18358/ Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PyThreadState_Delete vs PyThreadState_DeleteCurrent
Hi, I started hitting Py_FatalError(Invalid thread state for this thread) in pystate.c when a thread bootstraps since my upgrade to Python 2.4.2 (was using 2.4.1 previously). I'm embedding Python in C++, using multiple interpreters and threads. I think the problem is that PyThreadState_Delete (which is used when I destroy thread states and interpreters) is not making the same clean up that PyThreadState_DeleteCurrent is doing: if (autoTLSkey PyThread_get_key_value(autoTLSkey) == tstate) PyThread_delete_key_value(autoTLSkey); If a thread id is reused (and this often happens), and the previous thread used PyThreadState_Delete instead of PyThreadState_DeleteCurrent, an old and invalid value for autoTLSkey is stored, and that is triggering the Py_FatalError. Thanks. -- Gabriel Becedillas Developer CORE SECURITY TECHNOLOGIES Florida 141 - 2º cuerpo - 7º piso C1005AAC Buenos Aires - Argentina Tel/Fax: (54 11) 5032-CORE (2673) http://www.corest.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] test_curses
Michael Hudson wrote: Georg Brandl [EMAIL PROTECTED] writes: Michael Hudson wrote: Georg Brandl [EMAIL PROTECTED] writes: The call to curses.setupterm() leaves my terminal in a bad state. Hmm. The reset program outputs: Erase set to delete. Kill set to control-U (^U). Interrupt set to control-C (^C). It always says that :) (unless you've messed with stty, I guess) Well, when I do a reset without meddling with the terminal, it says nothing, at least on my box. Oh. Maybe I'm out of date. And, there's more: Ctrl+D doesn't work, Ctrl+C doesn't work. Right, so it definitely sounds like the terminal is in raw mode. Doesn't the setupterm() have to be paired with something like shutdownterm()? Not as far as my memory of curses goes. From the man page: The setupterm routine reads in the terminfo database, initializing the terminfo structures, but does not set up the output virtualization structures used by curses. What platform are you on? Linux 2.6, ncurses 5.5, TERM=xterm. Well, this still has the faint whiff of impossibility about it. Are you sure it's setupterm() that's doing the damage? Can you reproduce interactively? Yep. Alone, the setupterm call [curses.setupterm(sys.__stdout__.fileno())] does nothing remarkable, but when it is done inside of curses.initscr() / curses.endwin() the terminal is not restored properly. If setupterm() is to be tested, I think it should be executed before initscr(). regards, Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Py_ssize_t output parameters (Was: [Python-checkins] r41971 ...)
M.-A. Lemburg wrote: I don't believe the change is major. It only affects a few extensions, and for these, it is only a minor change. A single line of changing will be enough. This is true for all the changes related to parameters passed by value. It is not true for output parameters. For these, the change will propagate into the extension and make quite a few changes necessary (for the same reason you have to change so many variables to Py_ssize_t). For the output parameter, just the variable receiving the value needs to be changed, and you are done. We should make it possible to have a simple recompile of old extensions continue to work with Python 2.5 (albeit without them supporting 64-bit indexes) and without introducing segfaults or buffer overflows that way. I cannot see how this could reasonably achieved for arbitrary extension modules. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] r42003 - python/trunk/Lib/test/outstanding_bugs.pypython/trunk/Lib/test/outstanding_crashes.py
time to synchronize your activities a bit ? Author: neal.norwitz Date: Tue Jan 10 08:49:41 2006 New Revision: 42000 Added: python/trunk/Lib/test/crashers/ python/trunk/Lib/test/crashers/README python/trunk/Lib/test/crashers/coerce.py python/trunk/Lib/test/crashers/weakref_in_del.py python/trunk/Lib/test/crashers/xml_parsers.py Log: As I threatened on python-dev, add a directory which contains all known bugs which cause the interpreter to crash. I'm sure we can find a few more. Many missing bugs deal with variations on unchecked infinite recursion (like coerce.py). Author: georg.brandl Date: Tue Jan 10 20:29:24 2006 New Revision: 42003 Added: python/trunk/Lib/test/outstanding_crashes.py Modified: python/trunk/Lib/test/outstanding_bugs.py Log: Add outstanding_crashes.py with tests for crashes. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] buildbot
Andrew Bennetts wrote: For this part at least, it's easier than that; you can pass interface='127.0.0.1' to the relevant listenTCP or TCPServer call, so that it will only bind that port to localhost. Thanks for the suggestion! works fine for me. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New PEP: Using ssize_t as the index type
M.-A. Lemburg wrote: I don't see a good solution for these other than introducing a set of new APIs (and maybe doing some macro magic as Martin did for PyArg_ParseTuple()). Due to the fact that changes in the types of output parameters require changes in the extension variable type layout itself, they introduce a large number of type changes in the extension and make writing backwards compatible extensions harder than necessary. That's not true. It is very easy to write extensions that receive such values and are still backwards-compatible. Suppose you had int pos; PyObject *k, *v; PyDict_Next(dict, pos, k, v); You just change this to /* beginning of file */ #ifdef Py_HEX_VERSION 2.5 typedef int Py_ssize_t; #endif /* later */ Py_ssize_t pos; PyObject *k, *v; PyDict_Next(dict, pos, k, v); That's it! Furthermore, all extensions for Python 2.4 would have to be ported to the new Python API and porting is not going to be a simple recompile, but will require C skills. Not all extensions. Only those that call functions that expect int* output parameters - which is fairly uncommon. Martin, please add the above points to the PEP. I'd also like to see it published, because it's hard to track a PEP in the mailing It's very difficult to get a PEP number assigned. I wrote [EMAIL PROTECTED] with no response. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Tkinter
On 1/10/06, Fredrik Lundh [EMAIL PROTECTED] wrote: Guido van Rossum wrote: But for sure, Tkinter is still being maintained by the Python developers (mainly MvL I believe). If it appears stagnant that's probably because Tcl/Tk itself isn't changing much. afaict, Tcl/Tk 8.5 isn't moving quite as fast as Python 2.5, but they're probably a lot closer to a release than the Perl 6 guys... http://www.tcl.tk/software/tcltk/8.5.html Well to compare to Perl 6 you should really look at the progress of Tcl/Tk 9.0, which sounds like it's never going to happen. So Perl 6 still wins. :-) -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Tkinter
Fredrik Lundh wrote: But for sure, Tkinter is still being maintained by the Python developers (mainly MvL I believe). If it appears stagnant that's probably because Tcl/Tk itself isn't changing much. afaict, Tcl/Tk 8.5 isn't moving quite as fast as Python 2.5, but they're probably a lot closer to a release than the Perl 6 guys... http://www.tcl.tk/software/tcltk/8.5.html My maintenance focuses on integrating user contributions, plus looking for the latest Tcl release when doing a Windows build. So new options to existing widgets, or entire new widgets don't get automatically wrapper classes in Tkinter. Instead, users wanting to make use of such features are expected to contribute a patch. I usually catch up with such patches before the next major release, atleast if the patches are straight-forward. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Include ctypes into core Python?
I would like to suggest to include ctypes into core Python, starting with the 2.5 release. ctypes is nearing the 1.0 release, and works on Windows, OS X, linux, possibly other platforms (provided that the processor is supported by libffi), and just recently even on Windows CE. ctypes does not depend on a libfii library installed on the system, instead the libfii source code is compiled into the extension module. libffi is copyright Red Hat, Inc, and released under a MIT style license. Up-to date docs for ctypes still have to be written, but I assume that the 2.5 release timeframe leaves enough time for that. Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Tkinter
On 1/10/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Guido Well to compare to Perl 6 you should really look at the progress Guido of Tcl/Tk 9.0, which sounds like it's never going to happen. So Guido Perl 6 still wins. :-) So the grand race is between Tcl/Tk 9.0, Perl 6 and Python 3? Maybe you, Larry and whoever the Tcl/Tk master is these days (still Ousterhout?) could agree to release all three on the same day. wink Or we could have another bake-off and pie-throwing contest. :-) -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Include ctypes into core Python?
On 1/10/06, Thomas Heller [EMAIL PROTECTED] wrote: I would like to suggest to include ctypes into core Python, starting with the 2.5 release. On the one hand I agree that this is a useful module, popular, mature etc. On the other hand it breaks one of the most fundamental Python guidelines: if you get a core dump (segfault etc.) it's a bug in Python or in a 3rd party extension, not in *your* Python code. An exception would have to be made for any code that uses ctypes, as it is usually trivial to cause core dumps with ctypes (I'd venture it's hard to avoid them ;-). I don't expect this to count against including ctypes; but I do want it to be dealt with somehow! -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Tkinter
[EMAIL PROTECTED] wrote] ...and whoever the Tcl/Tk master is these days (still Ousterhout?)... That's Jeff Hobbs. He sits behind me. I'll see if I can pester him to give some Tcl/Tk and _tkinter thoughts. Cheers, Trent -- Trent Mick [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Tkinter
Thanks for your reply. (I won't bug you on this with lots of email) but I would really like a comment or two on the other python GUIs viz. wxPython and QtPy. Would you say wxPython and QtPy are competing with TKinter or vice versa? Why wxPyton and/or QtPy when TKinter is alive and well? Why am I asking about this? I am working with an application that my agency started with TKinter and is investigating if we should stay with it or consider the others and have not been able to get the kind of direction anywhere. In addition, we purchased the John E. Grayson book but realized it is from 2000 and is wondering what is missing that has been developed in TKinter since 2000? Why has the book become so dated with no updates? This led me to consider that TKinter may be on its way out and we need to consider the other GUI toolkits. I am glad for you response and understand if you cannot dwell too long on this topic. Sincerely Joseph -Original Message- From: Martin v. Löwis [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 10, 2006 3:38 PM To: Fredrik Lundh Cc: python-dev@python.org; Rodrigues, Joseph Subject: Re: [Python-Dev] Tkinter Fredrik Lundh wrote: But for sure, Tkinter is still being maintained by the Python developers (mainly MvL I believe). If it appears stagnant that's probably because Tcl/Tk itself isn't changing much. afaict, Tcl/Tk 8.5 isn't moving quite as fast as Python 2.5, but they're probably a lot closer to a release than the Perl 6 guys... http://www.tcl.tk/software/tcltk/8.5.html My maintenance focuses on integrating user contributions, plus looking for the latest Tcl release when doing a Windows build. So new options to existing widgets, or entire new widgets don't get automatically wrapper classes in Tkinter. Instead, users wanting to make use of such features are expected to contribute a patch. I usually catch up with such patches before the next major release, atleast if the patches are straight-forward. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New PEP: Using ssize_t as the index type
Martin v. Löwis wrote: M.-A. Lemburg wrote: I don't see a good solution for these other than introducing a set of new APIs (and maybe doing some macro magic as Martin did for PyArg_ParseTuple()). Due to the fact that changes in the types of output parameters require changes in the extension variable type layout itself, they introduce a large number of type changes in the extension and make writing backwards compatible extensions harder than necessary. That's not true. It is very easy to write extensions that receive such values and are still backwards-compatible. Suppose you had int pos; PyObject *k, *v; PyDict_Next(dict, pos, k, v); You just change this to /* beginning of file */ #ifdef Py_HEX_VERSION 2.5 typedef int Py_ssize_t; #endif /* later */ Py_ssize_t pos; PyObject *k, *v; PyDict_Next(dict, pos, k, v); That's it! If it were this easy, I wouldn't have objections. But it's not. The variables you use with these APIs tend to propagate through the extension, you use them in other calls, make assignments, etc. If you implement extension types, you end up having to convert all the length related struct variables to Py_ssize_t. If you're writing against 3rd party APIs which don't use ssize_t or size_t, you have to convert Py_ssize_t to int where necessary. All this is fine, but it's also a lot of work which can be made easier. Recompiling an extension is well within range of many Python users, manually checking, fixing and porting it to the new API is certainly not. Furthermore, all extensions for Python 2.4 would have to be ported to the new Python API and porting is not going to be a simple recompile, but will require C skills. Not all extensions. Only those that call functions that expect int* output parameters - which is fairly uncommon. The set of functions that will require Py_ssize_t is getting larger in your branch which is why I started this discussion. In the first checkin you only had the rarely used slice APIs converted. In the meantime the buffer APIs, the Unicode APIs and others have been added to the list. These APIs are used a lot more often than the slice APIs. I'm not saying that it's a bad idea to adjust these to Py_ssize_t, it's just the backwards incompatible way this is done which bothers me. Martin, please add the above points to the PEP. I'd also like to see it published, because it's hard to track a PEP in the mailing It's very difficult to get a PEP number assigned. I wrote [EMAIL PROTECTED] with no response. Would it be possible to host the PEP in the python.org wiki or maybe in the sandbox on svn.python.org ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 10 2006) Python/Zope Consulting and Support ...http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Py_ssize_t output parameters (Was: [Python-checkins] r41971 ...)
M.-A. Lemburg wrote: ... and then the type change of that variable propagates throughout the extension. That depends on the usage of the code. If the variable is passed by value, no further changes are necessary. If a pointer to the variable is passed, you could replace it with Py_ssize_t x64; int x; foo(x64); x = x64; Then use x as you did with the original code. You basically end up having to convert the whole extension to Py_ssize_t. That is not necessary. Can you give in example of a module where you think it is necessary? Don't get me wrong: I don't mind doing this for the eGenix extensions, but I'm worried about the gazillion other useful extensions out there which probably won't get upgraded in time to be used with Python 2.5. I agree that it is not acceptable to require immediate whole-sale updates of every modules. However, I do believe that the number of modules that need any change at all is small, and that those modules can be modified with minimal effort to get them working again, backwards-compatible (i.e. with the only exception that they would fail if indices run above 2**31). I think all it takes is a set of new APIs for functions that use Py_ssize_t as output parameter and which are mapped to the regular API names if and only if the extension #defines PY_SSIZE_T_CLEAN (or some other capability flag). That is not enough. You also need to deal with the function pointers that change. Also, others have rejected/expressed dislike of the PY_SIZE_T_CLEAN macro already, so they would probably dislike further hackishness in that direction. Anyway, I have installed the PEP onsite, and added an Open Issues section, recording your comments. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Tkinter
Rodrigues, Joseph wrote: Would you say wxPython and QtPy are competing with TKinter or vice versa? No. I never say that software competes. I don't even say that products compete. People may compete, or perhaps companies, but not things. Why wxPyton and/or QtPy when TKinter is alive and well? Because they have their user communities. Why am I asking about this? Not sure :-) I am working with an application that my agency started with TKinter and is investigating if we should stay with it or consider the others and have not been able to get the kind of direction anywhere. In addition, we purchased the John E. Grayson book but realized it is from 2000 and is wondering what is missing that has been developed in TKinter since 2000? Not much - code in that book should continue to work just fine. Why has the book become so dated with no updates? You would have to ask John Grayson for that. This led me to consider that TKinter may be on its way out and we need to consider the other GUI toolkits. Well, this is certainly off-topic for python-dev. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New PEP: Using ssize_t as the index type
M.-A. Lemburg wrote: If it were this easy, I wouldn't have objections. But it's not. It is so easy. Can you should me an example where it isn't? The variables you use with these APIs tend to propagate through the extension, you use them in other calls, make assignments, etc. They only propage if you make them. You don't have to, if you don't want to. If you implement extension types, you end up having to convert all the length related struct variables to Py_ssize_t. Only if you want to. If not, the module will work (nearly) unmodified. Of course, it will be limited to 32-bit indices. All this is fine, but it's also a lot of work which can be made easier. Recompiling an extension is well within range of many Python users, manually checking, fixing and porting it to the new API is certainly not. Sure. However, most users will compile it on 32-bit systems. If they find they cannot get it to work on a 64-bit system, they should ask the author for help, or just use it in 32-bit mode (as 64-bit mode won't gain them anything, anyway). The set of functions that will require Py_ssize_t is getting larger in your branch which is why I started this discussion. How so? I did not add a single function that has int* output values, AFAICT. I am talking about the entirety of these functions, and claim that they are rarely used (including the Unicode and buffer APIs). Would it be possible to host the PEP in the python.org wiki or maybe in the sandbox on svn.python.org ? I pinged the PEP editors again, and they assigned the PEP number. Hosting it in a Wiki would be besides the point of the PEP process. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New PEP: Using ssize_t as the index type
[Martin v. Löwis] ... I am talking about the entirety of these functions, and claim that they are rarely used (including the Unicode and buffer APIs). This reminded me that I still owe you a reply about s# and t# format codes. It occurred to me that I've never used them, and probably never will, so I really don't care how they work: I'm only really worried about widespread ugliness, meaning wide enough that it touches me ;-) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Include ctypes into core Python?
Guido van Rossum wrote: On 1/10/06, Thomas Heller [EMAIL PROTECTED] wrote: I would like to suggest to include ctypes into core Python, starting with the 2.5 release. On the one hand I agree that this is a useful module, popular, mature etc. On the other hand it breaks one of the most fundamental Python guidelines: if you get a core dump (segfault etc.) it's a bug in Python or in a 3rd party extension, not in *your* Python code. An exception would have to be made for any code that uses ctypes, as it is usually trivial to cause core dumps with ctypes (I'd venture it's hard to avoid them ;-). I don't expect this to count against including ctypes; but I do want it to be dealt with somehow! As was pointed out on c.l.py, the `dl` module suffers the exact same problem (I don't know myself, as I've never used it). There are no warnings about this in the `dl` module documentation. I can't see how it would be possible to guarantee that such a module could not cause crashes. I'm of the opinion that having a big red warning at the top of the module documentation that this is a contributed module, and incorrect use could cause segmentation faults/crashes, etc would be sufficient. Tim Delaney ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Include ctypes into core Python?
Delaney, Timothy (Tim) wrote: Guido van Rossum wrote: On 1/10/06, Thomas Heller [EMAIL PROTECTED] wrote: I would like to suggest to include ctypes into core Python, starting with the 2.5 release. On the one hand I agree that this is a useful module, popular, mature etc. On the other hand it breaks one of the most fundamental Python guidelines: if you get a core dump (segfault etc.) it's a bug in Python or in a 3rd party extension, not in *your* Python code. An exception would have to be made for any code that uses ctypes, as it is usually trivial to cause core dumps with ctypes (I'd venture it's hard to avoid them ;-). I don't expect this to count against including ctypes; but I do want it to be dealt with somehow! As was pointed out on c.l.py, the `dl` module suffers the exact same problem (I don't know myself, as I've never used it). There are no warnings about this in the `dl` module documentation. I can't see how it would be possible to guarantee that such a module could not cause crashes. I'm of the opinion that having a big red warning at the top of the module documentation that this is a contributed module, and incorrect use could cause segmentation faults/crashes, etc would be sufficient. +1. A warning for dl might not be the worst thing. Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Include ctypes into core Python?
On 1/10/06, Delaney, Timothy (Tim) [EMAIL PROTECTED] wrote: Guido van Rossum wrote: On 1/10/06, Thomas Heller [EMAIL PROTECTED] wrote: I would like to suggest to include ctypes into core Python, starting with the 2.5 release. On the one hand I agree that this is a useful module, popular, mature etc. On the other hand it breaks one of the most fundamental Python guidelines: if you get a core dump (segfault etc.) it's a bug in Python or in a 3rd party extension, not in *your* Python code. An exception would have to be made for any code that uses ctypes, as it is usually trivial to cause core dumps with ctypes (I'd venture it's hard to avoid them ;-). I don't expect this to count against including ctypes; but I do want it to be dealt with somehow! As was pointed out on c.l.py, the `dl` module suffers the exact same problem (I don't know myself, as I've never used it). There are no warnings about this in the `dl` module documentation. Good point. I think there should be such warnings though. I can't see how it would be possible to guarantee that such a module could not cause crashes. And I'm not asking for that. I'm of the opinion that having a big red warning at the top of the module documentation that this is a contributed module, and incorrect use could cause segmentation faults/crashes, etc would be sufficient. Works for me. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Include ctypes into core Python?
Guido van Rossum wrote: As was pointed out on c.l.py, the `dl` module suffers the exact same problem (I don't know myself, as I've never used it). There are no warnings about this in the `dl` module documentation. Good point. I think there should be such warnings though. Added documentation patch 1402224: http://sourceforge.net/tracker/index.php?func=detailaid=1402224group_i d=5470atid=305470 May need a little more work on the wording. I can't see how it would be possible to guarantee that such a module could not cause crashes. And I'm not asking for that. I'm of the opinion that having a big red warning at the top of the module documentation that this is a contributed module, and incorrect use could cause segmentation faults/crashes, etc would be sufficient. Works for me. Sounds like we agree on everything :) Maybe I should start channelling ... wink. Tim Delaney ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Include ctypes into core Python?
On Tue, Jan 10, 2006 at 01:14:13PM -0800, Guido van Rossum wrote: On the other hand it breaks one of the most fundamental Python guidelines: if you get a core dump (segfault etc.) it's a bug in Python or in a 3rd party extension, not in *your* Python code. An exception would have to be made for any code that uses ctypes, as it is usually trivial to cause core dumps with ctypes (I'd venture it's hard to avoid them ;-). Aside from 'dl', what was also pointed out in c.l.py was the crashability of Python in general, even from pure Python code: centurion:~ python . Segmentation fault [...] sys.setrecursionlimit(130) f = lambda f:f(f) f(f) Segmentation fault There's more, all from Python itself. And sure, well, don't do that then is a perfectly valid response to most of these harebrained tricks, but it does put a lie to the 'uncrashable python' idea :) Not-for-or-against-including-ctypes-anyway'ly y'rs, -- Thomas Wouters [EMAIL PROTECTED] Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Include ctypes into core Python?
On 1/10/06, Thomas Wouters [EMAIL PROTECTED] wrote: Aside from 'dl', what was also pointed out in c.l.py was the crashability of Python in general, even from pure Python code: centurion:~ python . Segmentation fault This I think ought to be fixed; it's just (I presume) the parser stumbling over extremely invalid input. [...] sys.setrecursionlimit(130) f = lambda f:f(f) f(f) Segmentation fault OK, point taken. There's more, all from Python itself. And sure, well, don't do that then is a perfectly valid response to most of these harebrained tricks, but it does put a lie to the 'uncrashable python' idea :) I'm not saying it's uncrashable. I'm saying that if you crash it, it's a bug unless proven harebrained. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Include ctypes into core Python?
Tim I'm of the opinion that having a big red warning at the top of the Tim module documentation ... Do we have semantic markup to support that? ducks Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] building a module catalogue with buildbot
I've been playing with automatic module discovery in an attempt to figure out how complete the library reference really is. I've created a simple script that tweaks the path to get rid of site-package stuff, and then scans the path for python modules and extensions, and writes the result to a text file. By combining module lists from different sources, you can trivially generate all sorts of custom module indexes (e.g. modules available on typical linux machines, modules not available in 2.5 on windows, etc). For some examples etc, see: http://effbot.org/lib/index-24.html http://effbot.org/lib/index-23.html http://effbot.org/lib/index-win32.html http://online.effbot.org/2006_01_01_archive.htm#20060110 http://online.effbot.org/2006_01_01_archive.htm#module-count Most importantly, this makes it easy to track down missing reference pages, and generate stubs for pages that should exist. My initial thought was that we could ask alpha testers to run this script on their alpha builds, and report back, but it just struck me that the buildbot already builds stuff on a couple of interesting platforms. Can buildbot deal with custom test/validation scripts, and collect the output somewhere ? /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Include ctypes into core Python?
[Guido] I'm not saying it's uncrashable. I'm saying that if you crash it, it's a bug unless proven harebrained. +1 QOTW ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] [PATCH] Fix dictionary subclass semantics when used as global dictionaries
There is an inconsistancy in the way that dictionary subclasses behave when they are used as as namespaces in execs. Basically, while python 2.4 permits the usage of dictionary subclasses for local environments, it still bypasses the subclass functions and uses the C API for global environments. The attached patch (and unittest!) addresses this issue. I'm pretty sure we keep the fast path in this. -- Crutcher Dunnavant [EMAIL PROTECTED] monket.samedi-studios.com dictsubclassexec.patch Description: Binary data ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Include ctypes into core Python?
Thomas Wouters [EMAIL PROTECTED] wrote: centurion:~ python . Segmentation fault [...] sys.setrecursionlimit(130) f = lambda f:f(f) f(f) Segmentation fault There's more, all from Python itself. And sure, well, don't do that then is a perfectly valid response to most of these harebrained tricks, but it does put a lie to the 'uncrashable python' idea :) Many of the segfaulting Python issues are platform specific. On a platform with a sane malloc, you get a MemoryError for the recursion. On a platform which doesn't see the current path as a readable file, you get Access is denied. on the redirection attempt. As always, I'm sure that reasonable patches which work around such segfaulting cases will be acceptable, though remember that it may not be clear how to work around them. - Josiah ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Include ctypes into core Python?
On Tue, Jan 10, 2006 at 03:57:28PM -0800, Josiah Carlson wrote: As always, I'm sure that reasonable patches which work around such segfaulting cases will be acceptable, though remember that it may not be clear how to work around them. Sorry, I missed the point I was aiming at, I guess. I wasn't aiming for fixable bugs; I see these things as, with great effort, holding up your foot at an awkward angle so that it ends up right at the business end of your primed and lit medieval cannon. We can jump through hoops to stop those particular examples, but I'd rather spend time and effort to fix *real* bugs instead. I was just showing that if you want to crash Python, you need neither 'ctypes' nor 'dl'. I do agree a warning is suitable to both of those modules, though if anyone wants to nitpick, similar modules might be added to marshal and cPickle (and pickle, too!), when feeding invalid input. Those modules are more in the awkward-foot-angle terrain for me, though. -- Thomas Wouters [EMAIL PROTECTED] Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Hello
Sorry, sent a patch without an intro. My name is Crutcher Dunnavant I'm working on a doctorate in computer science (in modeling language practises). Before I got my master's degree, I used to work for Red Hat in North Carolina as an OS developer, and I now work in the San Fransisco Bay Area as a system analyst. -- Crutcher Dunnavant [EMAIL PROTECTED] monket.samedi-studios.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [PATCH] Fix dictionary subclass semantics when used as global dictionaries
On Tue, Jan 10, 2006, Crutcher Dunnavant wrote: There is an inconsistancy in the way that dictionary subclasses behave when they are used as as namespaces in execs. Basically, while python 2.4 permits the usage of dictionary subclasses for local environments, it still bypasses the subclass functions and uses the C API for global environments. The attached patch (and unittest!) addresses this issue. Please submit the patch to SourceForge and report back with the SF ID. -- Aahz ([EMAIL PROTECTED]) * http://www.pythoncraft.com/ 19. A language that doesn't affect the way you think about programming, is not worth knowing. --Alan Perlis ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [PATCH] Fix dictionary subclass semantics when used as global dictionaries
1402289 On 1/10/06, Aahz [EMAIL PROTECTED] wrote: On Tue, Jan 10, 2006, Crutcher Dunnavant wrote: There is an inconsistancy in the way that dictionary subclasses behave when they are used as as namespaces in execs. Basically, while python 2.4 permits the usage of dictionary subclasses for local environments, it still bypasses the subclass functions and uses the C API for global environments. The attached patch (and unittest!) addresses this issue. Please submit the patch to SourceForge and report back with the SF ID. -- Aahz ([EMAIL PROTECTED]) * http://www.pythoncraft.com/ 19. A language that doesn't affect the way you think about programming, is not worth knowing. --Alan Perlis -- Crutcher Dunnavant [EMAIL PROTECTED] monket.samedi-studios.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [PATCH] Fix dictionary subclass semantics when used as global dictionaries
This is the unittest that checks it. On trunk, the global and fall
through cases will fail, but they pass with the patch.
import unittest
from test import test_support
class DictSubclass(dict):
get_notify_func = None
def __getitem__(self, key):
if self.get_notify_func:
self.get_notify_func(key)
return dict.__getitem__(self, key)
set_notify_func = None
def __setitem__(self, key, value):
if self.set_notify_func:
self.set_notify_func(key)
return dict.__setitem__(self, key, value)
del_notify_func = None
def __delitem__(self, key):
if self.del_notify_func:
self.del_notify_func(key)
return dict.__delitem__(self, key)
class DictSubclassExecTest(unittest.TestCase):
def test_subclassexec_setlocal(self):
d = DictSubclass()
l = []
d.set_notify_func = l.append
exec a = 1 in d
d.set_notify_func = None
self.assert_(d['a'] == 1)
self.assert_('a' in l)
def test_subclassexec_getlocal(self):
d = DictSubclass()
l = []
d.get_notify_func = l.append
exec a = 1; a in d
d.get_notify_func = None
self.assert_(d['a'] == 1)
self.assert_('a' in l)
def test_subclassexec_dellocal(self):
d = DictSubclass()
l = []
d.del_notify_func = l.append
exec a = 1; del a in d
d.del_notify_func = None
self.assert_(not d.has_key('a'))
self.assert_('a' in l)
def test_subclassexec_setglobal(self):
d = DictSubclass()
l = []
d.set_notify_func = l.append
exec a = 1\ndef foo():\n\tglobal a\n\tpass in d
d.set_notify_func = None
self.assert_(d['a'] == 1)
self.assert_('a' in l)
def test_subclassexec_getglobal(self):
d = DictSubclass()
l = []
d.get_notify_func = l.append
exec a = 1; a\ndef foo():\n\tglobal a\n\tpass in d
d.get_notify_func = None
self.assert_(d['a'] == 1)
self.assert_('a' in l)
def test_subclassexec_delglobal(self):
d = DictSubclass()
l = []
d.del_notify_func = l.append
exec a = 1; del a\ndef foo():\n\tglobal a\n\tpass in d
d.del_notify_func = None
self.assert_(not d.has_key('a'))
self.assert_('a' in l)
def test_subclassexec_getfallthrough(self):
ld = DictSubclass()
ll = []
ld.get_notify_func = ll.append
gd = DictSubclass()
gl = []
gd.get_notify_func = gl.append
gd['a'] = 1
exec 'b = a' in gd, ld
gd.del_notify_func = None
ld.del_notify_func = None
self.assert_(ld['b'] == 1)
self.assert_('a' in ll)
self.assert_('a' in gl)
def test_main():
test_support.run_unittest(
DictSubclassExecTest,
)
if __name__ == __main__:
test_main()
On 1/10/06, Crutcher Dunnavant [EMAIL PROTECTED] wrote:
1402289
On 1/10/06, Aahz [EMAIL PROTECTED] wrote:
On Tue, Jan 10, 2006, Crutcher Dunnavant wrote:
There is an inconsistancy in the way that dictionary subclasses behave
when they are used as as namespaces in execs.
Basically, while python 2.4 permits the usage of dictionary subclasses
for local environments, it still bypasses the subclass functions and
uses the C API for global environments. The attached patch (and
unittest!) addresses this issue.
Please submit the patch to SourceForge and report back with the SF ID.
--
Aahz ([EMAIL PROTECTED]) * http://www.pythoncraft.com/
19. A language that doesn't affect the way you think about programming,
is not worth knowing. --Alan Perlis
--
Crutcher Dunnavant [EMAIL PROTECTED]
monket.samedi-studios.com
--
Crutcher Dunnavant [EMAIL PROTECTED]
monket.samedi-studios.com
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] building a module catalogue with buildbot
[Fredrik Lundh wrote] Can buildbot deal with custom test/validation scripts, and collect the output somewhere ? Yes, it should be able to. However, it might change the part of the the master.cfg file that defines the build steps from being trivial (probably something like: building_python_factory = factory.GNUAutoconf( s(SVN, svnurl=http://svn.python.org/projects/python/trunk;), test=[make, test], ) ) to something a little less trivial. The standard GNUAutoconf class would have to be subclassed to add that extra step (make check_for_missing_docs?). That probably would be fairly straightforward. Neil and Martin would probably know better. I don't have access to the buildbot setup. Trent -- Trent Mick [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ConfigParser to save with order
[Guido] I think it's moot unless you also preserve comments. Ideally would be something that prserved everything (ordering, blank lines, comments etc.) from how it was read in. Modifying a value should keep its position. Adding a value should add it to the end of the section it's in (unless there are cases where ordering is important to the semantics -- are there?). [Facundo Batista] We can rewrite ConfigParser to store everything and write it back in the exact order it took it, with new values at the end of each section (or where the user inserted it), but it'll took a big rewrite of the module: right now it's using dictionaries and should use lists to achieve that behaviour. It's not at all that complicated. Simply running through the original file when writing gets you the original order and comments. This is simple to do (a simple example is in the SpamBayes source code in the OptionsClass.py module). Remember that there has been a lot of discussion about how ConfigParser should work in the past; for example (ignoring c.l.p): http://mail.python.org/pipermail/python-dev/2004-October/049454.html http://mail.python.org/pipermail/python-dev/2004-October/049527.html http://aspn.activestate.com/ASPN/Mail/Message/python-dev/1483518 =Tony.Meyer ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Include ctypes into core Python?
On 11-jan-2006, at 0:57, Josiah Carlson wrote: On a platform which doesn't see the current path as a readable file, you get Access is denied. on the redirection attempt. On my osx box using python 2.4.2: $ cat . cat: stdin: Is a directory $ python . Bus error And finally: $ python -c 'execfile(.)' Traceback (most recent call last): File string, line 1, in ? IOError: [Errno 21] Is a directory: '.' It seems there is a bug somewhere. Annoyingly 'gdb -tty=. python' doesn't crash. Ronald As always, I'm sure that reasonable patches which work around such segfaulting cases will be acceptable, though remember that it may not be clear how to work around them. - Josiah ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/ ronaldoussoren%40mac.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Include ctypes into core Python?
Guido van Rossum [EMAIL PROTECTED] writes: On 1/10/06, Delaney, Timothy (Tim) [EMAIL PROTECTED] wrote: Guido van Rossum wrote: On 1/10/06, Thomas Heller [EMAIL PROTECTED] wrote: I would like to suggest to include ctypes into core Python, starting with the 2.5 release. On the one hand I agree that this is a useful module, popular, mature etc. On the other hand it breaks one of the most fundamental Python guidelines: if you get a core dump (segfault etc.) it's a bug in Python or in a 3rd party extension, not in *your* Python code. An exception would have to be made for any code that uses ctypes, as it is usually trivial to cause core dumps with ctypes (I'd venture it's hard to avoid them ;-). I don't expect this to count against including ctypes; but I do want it to be dealt with somehow! As was pointed out on c.l.py, the `dl` module suffers the exact same problem (I don't know myself, as I've never used it). There are no warnings about this in the `dl` module documentation. Good point. I think there should be such warnings though. I can't see how it would be possible to guarantee that such a module could not cause crashes. And I'm not asking for that. I'm of the opinion that having a big red warning at the top of the module documentation that this is a contributed module, and incorrect use could cause segmentation faults/crashes, etc would be sufficient. Works for me. Another possibility would be to emit a warning when the module (dl or ctypes, if included) is imported. warnings.warn(Incorrect usage of this module may crash Python, RuntimeWarning, stacklevel=2) Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Include ctypes into core Python?
Won't ctypes completely replace dl? dl provides only a small subset of the functionality of ctypes and is very restricted in the set of argument types allowed. Neil ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Include ctypes into core Python?
On 1/10/06, Thomas Wouters [EMAIL PROTECTED] wrote: centurion:~ python . Segmentation fault I fixed that in Oct in head and 2.4 branch. Although Skip filed a bug since Py_FatalError() is called which generates a core dump in debug builds at least. http://python.org/sf/1353504 I'm not sure what else can be done except perhaps just print to stderr and exit() rather than abort(). sys.setrecursionlimit(130) f = lambda f:f(f) f(f) Segmentation fault Added as Lib/test/crashers/recursive_call.py I'm sure there are many more similar to this one though. There's more, all from Python itself. We should at least try to clearly document limitations such as these. That's why I added the crashers directory. Maybe we can even find volunteers to fix these. n ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
