From noreply at sourceforge.net Tue Jun 1 00:38:13 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jun 1 00:38:47 2004 Subject: [Patches] [ python-Patches-963318 ] New module cookielib Message-ID: Patches item #963318, was opened at 2004-05-31 01:39 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=963318&group_id=5470 Category: Library (Lib) Group: Python 2.4 >Status: Closed Resolution: Accepted Priority: 5 Submitted By: John J Lee (jjlee) Assigned to: Nobody/Anonymous (nobody) Summary: New module cookielib Initial Comment: cookielib itself is here: http://codespeak.net/svn/user/jjlee/wwwsearch/ClientCookie/branch/python-2.4_candidate/ All I'm uploading here are patches to the various other files in Python that are affected. Remaining issues: -The .unverifiable and .origin_req_host attributes I've added to urllib2.Request are a bit ugly (yet another bit of HTTP-specific state). But I guess it's too late to start having subclasses for specific protocol schemes. -Implementation wart: ._now attributes. -test_urllib2.py depends on test_cookielib.py. What's the right way to fix this? -Thread synchronization needs checking by someone with more of a clue about this: I have great confidence that it IS currently broken, since I've never tested it. -Update magic string in LWPCookieJar, if Gisle agrees (I'm waiting for a reply). ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-06-01 06:38 Message: Logged In: YES user_id=21627 Thanks, committed as 1.2. Please create new patches in the future if you wish to make further changes. If you find they get no attention, give them priority 6 and assign them to me. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2004-06-01 01:21 Message: Logged In: YES user_id=261020 Here's a fix for the noisy unit tests. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-05-31 20:23 Message: Logged In: YES user_id=21627 Thanks for the patch. Applied as lib.tex 1.226 libcookie.tex 1.12 libcookielib.tex 1.1 liburllib2.tex 1.18 whatsnew24.tex 1.49 _LWPCookieJar.py 1.1 _MozillaCookieJar.py 1.1 cookielib.py 1.1 urllib2.py 1.67 test_cookielib.py 1.1 test_urllib2.py 1.13 NEWS 1.978 ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2004-05-31 19:09 Message: Logged In: YES user_id=261020 OK, done. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2004-05-31 16:20 Message: Logged In: YES user_id=261020 Martin, in case you are just about to apply this: I've finally stopped dithering about the first 'remaining issue' above (unverifiable and origin_req_host), and am just about to update liburllib2.tex.patch, urllib2.py.patch and test_urllib2.py.patch (and cookielib itself). ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2004-05-31 13:07 Message: Logged In: YES user_id=261020 The files that should be copied from the subversion repository are: _LWPCookieJar.py _MozillaCookieJar.py cookielib.py test/test_cookielib.py ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=963318&group_id=5470 From ouvizfgmqnczp at hotmail.com Tue Jun 1 01:41:30 2004 From: ouvizfgmqnczp at hotmail.com (Грихнова Альбина) Date: Tue Jun 1 00:45:07 2004 Subject: [Patches] information Message-ID: <200406010445.i514j2mG091780@mxzilla2.xs4all.nl> An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20040601/33106569/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: bludgeon.GIF Type: image/gif Size: 15392 bytes Desc: not available Url : http://mail.python.org/pipermail/patches/attachments/20040601/33106569/bludgeon.gif From noreply at sourceforge.net Tue Jun 1 02:50:18 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jun 1 02:50:25 2004 Subject: [Patches] [ python-Patches-957122 ] Improved hash for tuples Message-ID: Patches item #957122, was opened at 2004-05-19 18:06 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=957122&group_id=5470 Category: Core (C code) Group: Python 2.4 >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Yitz Gale (ygale) Assigned to: Nobody/Anonymous (nobody) Summary: Improved hash for tuples Initial Comment: See bug #942952. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-06-01 01:50 Message: Logged In: YES user_id=80475 Thanks for the patch. In the end, I adopted a minor (cheaper) variation of Tim's proposal. It gets the job done without having to trying to achieve encryption grade hashing. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=957122&group_id=5470 From noreply at sourceforge.net Tue Jun 1 09:46:27 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jun 1 09:46:34 2004 Subject: [Patches] [ python-Patches-962502 ] East Asian Width support for Unicode Message-ID: Patches item #962502, was opened at 2004-05-29 07:59 Message generated for change (Comment added) made by perky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=962502&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Hye-Shik Chang (perky) Assigned to: Nobody/Anonymous (nobody) Summary: East Asian Width support for Unicode Initial Comment: As David Goodger's inspiration, I thought that it would be great if we have some unicode methods that manipulates East Asian Width (http://www.unicode.org/reports/tr11/tr11-13.html#UCD). The attached patch implements rough first-time idea. >>> u'1'.iswide() False >>> u'\uac00'.iswide() True >>> u'\ud55c\uae00'.iswide() True >>> u'\ud55c\uae00'.width() 4 >>> u'ab\ud55c\uae00'.width() 6 >>> u'ab\ud55c\uae00'.iswide() False ---------------------------------------------------------------------- >Comment By: Hye-Shik Chang (perky) Date: 2004-06-01 22:46 Message: Logged In: YES user_id=55188 Okay. In fact I don't care of Unicode 4.0. I'm fine with 3.2. I uploaded new patch sticking Unicode revision on 3.2. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-06-01 06:07 Message: Logged In: YES user_id=21627 Updating to the Unicode 4.0 database is risky. It will break IDNA, which specifies that IDN must use the 3.2 version of the unicode database. It would be ok if you could arrange to provide both versions of the database. Ideally, the database would only store the deltas from 4.0 to 3.2, so we don't get any increase in space for cases where the data didn't change between Unicode versions. It might be reasonable to leave that issue alone for this patch, and proceed with the 3.2 version of EastAsianWidth. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=962502&group_id=5470 From noreply at sourceforge.net Tue Jun 1 11:41:33 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jun 1 11:41:49 2004 Subject: [Patches] [ python-Patches-957033 ] Allow compilation of C/C++ Python extensions without MSVC Message-ID: Patches item #957033, was opened at 2004-05-19 22:37 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=957033&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Connelly (connelly) Assigned to: Nobody/Anonymous (nobody) Summary: Allow compilation of C/C++ Python extensions without MSVC Initial Comment: This page describes how to compile C/C++ Python extensions with Mingw: http://sebsauvage.net/python/mingw.html This process works. However, you need to patch Python to get the 'python setup.py install' step to work correctly. This is the second step in installing a Python extension. The first step: 'python setup.py build -cmingw32' works fine. The second step: 'python setup.py install' fails with the following error: "error: Python was built with version 6 of Visual Studio, and extensions need to be built with the same version of the compiler, but it isn't installed." This statement is factually untrue. Python uses .pyd files to run Python extensions, which are actually .dll files, and are compatible across different compilers and compiler versions. So open \Python\Lib\distutils\msvccompiler.py and remove the warning (it's around line 211). Or apply the patch: --- msvccompiler.bak Thu Dec 4 09:38:22 2003 +++ msvccompiler.py Wed May 19 13:15:34 2004 @@ -208,11 +208,10 @@ self.__root = r"Software\Microsoft\Devstudio" self.__paths = self.get_msvc_paths("path") - if len (self.__paths) == 0: - raise DistutilsPlatformError, - ("Python was built with version %s of Visual Studio, " - "and extensions need to be built with the same " - "version of the compiler, but it isn't installed." % self.__version) + # Note: Extensions CAN be built with Mingw32. + # See http://sebsauvage.net/python/mingw.html. + # The .pyd files created are DLLs, and these are compatible across + # different compilers and compiler versions. self.cc = self.find_exe("cl.exe") self.linker = self.find_exe("link.exe") ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2004-06-01 17:41 Message: Logged In: YES user_id=11105 This is not a bug. The 'install' command internally runs the 'build' command, and this command misses the -cmingw32 flag. Basically, you have two options to build and install the extension: - call 'python setup.py build -cmingw32 install' - create/edit your distutils configuration file setup.cfg. Add this section (untested, but you get the idea): [build_ext] compiler=mingw32 See distutils docs for more details - the latter way is the recommended one. Does this help? ---------------------------------------------------------------------- Comment By: Connelly (connelly) Date: 2004-05-19 22:41 Message: Logged In: YES user_id=1039782 Here's the upload. ---------------------------------------------------------------------- Comment By: Connelly (connelly) Date: 2004-05-19 22:40 Message: Logged In: YES user_id=1039782 BTW: You can test this out with the extension module myspell-python, available at: http://www.zgoda.biz/dnld/myspell-python-1.0- minimal.tar.gz Follow the directions at http://sebsauvage.net/python/mingw.html. You'll encounter an error. Patch msvccompiler.py and try again; now it works. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=957033&group_id=5470 From ksadler_uk at correios.com.br Tue Jun 1 11:46:45 2004 From: ksadler_uk at correios.com.br (Keith Sadler) Date: Tue Jun 1 11:48:07 2004 Subject: [Patches] =?iso-8859-1?q?Buy_V=EDagra_and_many_other_medicines_h?= =?iso-8859-1?q?ere=2E?= Message-ID: <0a4101c447ef$0dfbe392$55909d95@nspkor.co.kr> An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20040601/2fdb8a86/attachment.html From noreply at sourceforge.net Tue Jun 1 12:33:26 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jun 1 12:33:59 2004 Subject: [Patches] [ python-Patches-957398 ] Public Generator Object/Type Message-ID: Patches item #957398, was opened at 2004-05-20 15:59 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=957398&group_id=5470 Category: Core (C code) Group: Python 2.4 >Status: Closed >Resolution: Accepted Priority: 6 Submitted By: James William Pye (jwpye) Assigned to: Martin v. L?wis (loewis) Summary: Public Generator Object/Type Initial Comment: Here the patches/files for public generator object/type. removal patch for ceval.c ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-06-01 18:33 Message: Logged In: YES user_id=21627 Thanks for the patch. Applied as Makefile.pre.in 1.143 concrete.tex 1.40 ceval.h 2.51 genobject.h 2.1 NEWS 1.981 genobject.c 1.1 ceval.c 2.397 ---------------------------------------------------------------------- Comment By: James William Pye (jwpye) Date: 2004-05-31 21:39 Message: Logged In: YES user_id=1044177 Externalize the generator type so that it can be easily accessed/referenced by extension mod authors and embedders.. http://mail.python.org/pipermail/python-dev/2004-May/044742.html I would use it, as an embedder, in my postgresql extension: http://gborg.postgresql.org/project/postgrespy/projdisplay.php Currently, I compile a little generator and snag the type(this is the same thing as from types import GeneratorType, I suppose), and will do so if I don't have direct access. I also access parts of the generator, currently using getattr, but if I had access to it, I would do it directly. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-05-31 20:30 Message: Logged In: YES user_id=21627 What is the purpose of this patch? ---------------------------------------------------------------------- Comment By: James William Pye (jwpye) Date: 2004-05-20 18:09 Message: Logged In: YES user_id=1044177 Ok, got it to compile, and tried out a simple generator; seems to be fine.. Probably should have asked first, but I'm assuming(yay) that it was desired to draw it inline with *object.[ch] organization protocol.. Only gotcha appears to be that genobject.c, of course, references eval_frame, so I just wrapped a call to it in eval.c with a non-static function(PyEval_EvaluateFrame()), this is probably not be what python-dev would like.. I mostly did it like this to get it to compile.(probably a bad idea, and should probably reference it directly. no need for an extra layer of function call overhead...) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=957398&group_id=5470 From noreply at sourceforge.net Tue Jun 1 12:56:04 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jun 1 12:56:11 2004 Subject: [Patches] [ python-Patches-959534 ] Arrange 64bits detection for ReliantUnix Message-ID: Patches item #959534, was opened at 2004-05-24 18:13 Message generated for change (Comment added) made by jfclere You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=959534&group_id=5470 Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Jean-frederic Clere (jfclere) Assigned to: Nobody/Anonymous (nobody) Summary: Arrange 64bits detection for ReliantUnix Initial Comment: When compiling python on ReliantUnix (5.43) the compilation fails with unresolved externals like fstatvfs64, lseek64 etc Those routines belong to 5.45. The patch detects the missing lseek64() and suppress lfs support (use_lfs=no). ---------------------------------------------------------------------- >Comment By: Jean-frederic Clere (jfclere) Date: 2004-06-01 18:56 Message: Logged In: YES user_id=92497 Oops... That is better to check for SINIX-* before trying the link. I have more to submit because the dynamic linking needs additional libc. For example in setup.py +++ exts.append( Extension('_hotshot', ['_hotshot.c'], libraries=['c']) ) +++ ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-05-31 20:27 Message: Logged In: YES user_id=21627 Why do you check for SINIX after the link test fails? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=959534&group_id=5470 From noreply at sourceforge.net Tue Jun 1 13:28:47 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jun 1 13:28:59 2004 Subject: [Patches] [ python-Patches-764217 ] Fix for tkFont.Font(name=...) Message-ID: Patches item #764217, was opened at 2003-07-01 14:14 Message generated for change (Comment added) made by reowen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=764217&group_id=5470 Category: Tkinter Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Russell Owen (reowen) Assigned to: Martin v. L?wis (loewis) Summary: Fix for tkFont.Font(name=...) Initial Comment: tkFont.Font(name=xxx) crashes if a font by the specified name already exists. This is a problem for several reasons, the main one being that it makes life really tough if you want to creat a new tkFont.Font object for a given Tcl named font. This simple fix handles the problem. I've also included a new method __eq__ so that two tkFont.Font objects that point to the same Tcl named font compare as equal. I felt this is important because the fix makes it easier to have multiple such tkFont.Font objects. ---------------------------------------------------------------------- >Comment By: Russell Owen (reowen) Date: 2004-06-01 10:28 Message: Logged In: YES user_id=431773 Just a tickle, hoping this can get into Python 2.4 ---------------------------------------------------------------------- Comment By: Russell Owen (reowen) Date: 2003-12-11 15:22 Message: Logged In: YES user_id=431773 Here is another try that addresses the issues raisd by Martin Loewis. It adds a new argument to Font.__init__: exists. If False (the default) then the old behavior occurs unchanged (including an error is raised if the font already exists). If True, the font must already exist. This follows the dictum "explicit is better than implicit". There is an another issue: what do do about Font's __del__? The existing behavior was for Font.__del__ to delete the associated tk named font. This causes trouble if more than one tkFont.Font object points to the same tk named font object. Even in the existing system it could also cause trouble if the user was doing a mixture of tk and Tkinter programming. I see two solutions: - Simple (what I did): do not delete tk named fonts (ditch Font.__del__). This makes it safe to mix tk an Tkinter programming. The only down side is increased memory use for any existing program that creates many tk named fonts and then deletes them. I can't imagine this is a serious issue. - Fancy: keep a dictionary of each Font object (by font name) as it is created. If a new Font pointing to an existing tk named font is wanted, return the existing Font object. Then the old Font.__del__ is as safe as it ever was. ---------------------------------------------------------------------- Comment By: Russell Owen (reowen) Date: 2003-09-22 10:05 Message: Logged In: YES user_id=431773 Here is a proposed approach to handle the exists problem. Supply a new argument to Font: exists. If False, the existing behavior is used; if True, existence is checked and the font configured (if any config info supplied). This makes it trivial to write "nameToFont" (it also makes it unnecessary, but I really think it is desirable). The issue of how to make nameToFont a method of tk objects remains. I'd love to import tkFont (font objects should be more visible) but obviously permission is needed for such a step. Anyway, what do you think? Is it permissable to add the "exists" argument to Font.__init__? ---------------------------------------------------------------------- Comment By: Russell Owen (reowen) Date: 2003-09-22 09:43 Message: Logged In: YES user_id=431773 I'm quite willing to do more work on this. I agree with the criticisms (though I'm curious how name conflicts are presently handled for widgets when the name argument is used). I think the best solution for getting a font from a font name is "nameToFont". This matches the existing "nameToWdg". (I'd also like to add a "nameToVar" or "nameToVariable", so one standard mechanism handles everything, but I digress). Unfortunately, tkFont is an add-on package. I'm not sure how tk.nameToFont can be written, given that normally a tk object won't automatically have any idea about fonts. Do you have any suggestion for handling this? Could we just start importing tkFont as a standard part of Tkinter? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-09-20 04:01 Message: Logged In: YES user_id=21627 reowen, are you willing to revise the patch in this direction? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-07-13 08:57 Message: Logged In: YES user_id=21627 While the bug might be worth fixing, I think the approach taken is wrong. With the patch, it will invoke "font names" for all new tkFont objects, which might be a significant overhead. To really preserve current behaviour, it should continue to 'font create', and fall back to 'font configure' in case of an exception. Actually, it is not clear what the right behaviour is in the first place. 'font configure' would change the settings of the existing font. If the name clash is by coincidence, it would be better to raise an exception instead of silently modifying the existing font. In the face of ambiguity, refuse the temptation to guess. So to really fix this, tkFont.forName (or tkFont.existing) should be provided. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-13 08:32 Message: Logged In: YES user_id=80475 The first part of the patch appears reasonable. For the second part, it's a bit late for an API change. Martin, is this bugfix okay for Py2.3? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=764217&group_id=5470 From noreply at sourceforge.net Tue Jun 1 13:44:30 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jun 1 13:44:42 2004 Subject: [Patches] [ python-Patches-876130 ] add C API to datetime module Message-ID: Patches item #876130, was opened at 2004-01-13 08:20 Message generated for change (Comment added) made by atuining You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=876130&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Anthony Tuininga (atuining) Assigned to: Tim Peters (tim_one) Summary: add C API to datetime module Initial Comment: The datetime module does not have a C API which means that modules written in C cannot take advantage of the datetime module without incurring significant overhead. These patches supply this lack and are based on the C API exported by the mxDateTime module and the cStringIO module and enhanced as suggested by Guido. ---------------------------------------------------------------------- >Comment By: Anthony Tuininga (atuining) Date: 2004-06-01 11:44 Message: Logged In: YES user_id=619560 Sure. What's the chance of it being reviewed prior to the release of Python 2.4 a1? I just saw the preannouncement today -- it is scheduled for the end of this month, I believe. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-05-31 21:12 Message: Logged In: YES user_id=31435 Assigned to me for the next review. Can't do it immediately, but will do my best to free up some time for it "soon". ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-05-26 13:39 Message: Logged In: YES user_id=619560 I would agree with your assessment of the issue regarding the TimeFromTicks() API and find it quite reasonable. Either implement both at the C and Python levels or not at all. Since there is no consensus on this, none it is. :-) Did you have a chance to review the actual code? The changes are fairly minimal but you might have questions about readability, names, etc. It would be great if this could be included in an upcoming 2.4 alpha/beta so that I can provide support in cx_Oracle for the next release. Thanks for your time. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-05-26 13:32 Message: Logged In: YES user_id=31435 Under the belief that the *intent* of this patch is to add a C API to Python's datetime module, it should stick to exposing C ways to spell what Python programmers can already do from Python using datetime. Since nothing like TimeFromTicks() exists in the Python datetime API, it simply doesn't make sense to invent one available only from C. It *may* make sense to invent one in a DB API wrapper around datetime, but I view that as out of scope for this patch. I would not add TimeFromTicks() to the Python datetime API either, because the docs are ambiguous. The sample implementation Marc-Andre posted here uses localtime() to resolve the ambiguity in the docs, but that has to be a wrong choice for some time-of-day apps. For example, there's apparently no portable way to spell "noon" using TimeFromTicks(): the value you get back depends on which time zone localtime() happens to use at the time it's called. If people want time-of-day from a POSIX timestamp, it remains easy to get it from what datetime already supplies, but to do so you have to be explicit about whether you want UTC or local time interpretation. Both are easily spelled already, and it's a Good Thing that you need to be explicit if you want to do such a thing. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-05-26 13:25 Message: Logged In: YES user_id=38388 Tim, please review. Thanks. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-05-26 13:22 Message: Logged In: YES user_id=38388 Thanks, but I don't have time to review it. As for the TimeFromTicks() API: I can understand that you don't feel like implementing it, but hey, I won't use datetime either. The only reason I'm trying to push full support of the DB API specs is that Guido et al. wanted to see a note in the DB API that datetime also provides a usable interface to do date/time interfacing. I'm not very interested in datetime myself, since I'll continue to use mxDateTime, so the situation for me is somewhat similar to yours: investing time into something that I myself will probably not use much (I will add support to mxODBC for those who like to use datetime instead of mxDateTime, but won't use it myself). Feel free to check in your changes. Thanks. ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-05-26 10:30 Message: Logged In: YES user_id=619560 Attached are the modified patches based on your suggestions. I have tested them with my own module cx_Oracle and they appear to work correctly. Any further suggestions would be appreciated. I would like to see this included for Python 2.4 if at all possible. Please let me know what I need to do (if anything) to get this to happen. As for the TimeFromTicks() routine, Oracle has absolutely no use for a "time-only" data type and does not support it. It clearly does not have broad support so I really have no desire to implement it since I will never use it myself. If you consider it important, you could add it yourself or we could wait until someone else who requires it for their implementation of the DB API requires it. I'm not trying to be rude or trying to denigrate the DB API, simply trying to be practical. Please let me know if this is offensive in any way. Thanks. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-05-19 02:28 Message: Logged In: YES user_id=38388 >From the DB API specs: TimeFromTicks(ticks) This function constructs an object holding a time value from the given ticks value (number of seconds since the epoch; see the documentation of the standard Python time module for details). The reason for this having this API is to be able to construct an object suitable for passing to the database given a Unix ticks value. Since the ticks value contains both a date and a time part and most databases have a special column type for time value, we need two constructor APIs, one to extract just the date part and one for the time part. Here's the mxDateTime implementation for reference: def TimeFromTicks(ticks, # Locals: DateTimeDelta=DateTimeDelta,localtime=_time.localtime): """ TimeFromTicks(ticks) Constructs a DateTimeDelta instance pointing to the local time indicated by the given ticks value. The date part is ignored. """ return apply(DateTimeDelta, (0,) + localtime(ticks)[3:6]) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-05-03 11:46 Message: Logged In: YES user_id=31435 I don't understand what TimeFromTicks() is supposed to do. Seconds-from-the-epoch is a point in time, not a time-of- day. If some DB API requires guessing some transformation from seconds-from-the-epoch to time-of-day, that's fine, but it doesn't belong in Python's datetime module. The datetime module should certainly have a method to construct a datetime.datetime from a seconds-from-the- epoch argument -- seconds-from-the-epoch is a way of specifying a datetime.datetime. Given that, if the intent is to throw away the datetime.date portion of the datetime.datetime object, retaining only the datetime.time portion, then that's trivially accomplished by invoking dt.time () (where dt is the datetime.datetime object). Do any databases really store time-of-day as a seconds-from- the-epoch value? Google's top hit on TimeFromTicks() today happens to be a msg from Anthony saying that Oracle does not. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-05-03 11:24 Message: Logged In: YES user_id=38388 Macro: I don't know whether you need the macro or not (you probably do for the type checks). In any case, you can do without relying on Python providing you this information via the build process, since only datetimemodule.c is using the header file while Python is being built. TimeFromTicks(): I' ve stated my point. I don't think there's anything to add - I'm tired of fighting for these things... one of the reasons I stopped actively discussing things on python-dev. IMHO, a product that's aimed at developers should make things easy for the developer and try to avoid code duplication if possible. The API is needed in order to support database interfaces that use Unix ticks as basis for date/time, so if you don't add it to the module, the ten or twenty module authors out there will have to duplicate that piece of work in their implementation. Transition: This was already discussed on the db-api list. We love freedom of choice. Nothing to add. ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-05-03 10:48 Message: Logged In: YES user_id=619560 About the Py_BUILD_CORE issue: You are suggesting that I define this in datetimemodule.c just prior to the include of datetime.h? Or are you suggesting some other macro? I am not sure about the comment about "not needing a macro in the first place" since there are two groups that will be importing datetime.h: the first being the datetime module itself and the second being the DB API modules. The macro is definitely required to distinguish between the two -- unless I am missing something? On the TimeFromTicks() issue: You obviously consider it important that the three methods be available at the C level for DB API module authors to use directly. My objection is simply a reiteration of an objection raised by Tim Peters. I think you'll have to argue that one with him. :-) I'll provide my implementations for cx_Oracle as part of the patches and then you can fight it out and I'll stay out of it. :-) As for the transition period, I assumed that with the introduction of a standard datetime module, that it would become the suggested implementation for database interfaace modules. That said, I don't really have any authority to say anything on this front so I'll leave that to you and others to decide. :-) ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-05-03 09:26 Message: Logged In: YES user_id=38388 About the Py_BUILD_CORE issue: Sorry, I didn't know that Python does not define this macro for core modules. Nevertheless, looking at the datetime module code I don't really understand why you would need such a macro in the first place. Since the datetime module is the only code including the datetime.h header file it should be easy to add a macro definition just before importing datetime.h. On the TimeFromTicks() issue: The whole point of this discussion is to make the datetime module easily usable for authors of database modules. Since the DB API specifies that the module will need to export the three functions, two of which are available through the datetime module already, I don't really see your point in not wanting to add it. BTW, you are wrong in the assumption that the DB API spec will move away from a generic API for date/time objects. The DB API has always been defined in terms of interfaces and does not force a certain set of tools onto the developer. The datetime module will become one possible choice for DB API authors, others will want to stick to mxDateTime, use strings, ticks integers or more specific objects for interfacing. That won't change, so there is no "transition period". ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-05-03 08:40 Message: Logged In: YES user_id=619560 I spent some time getting the two include files merged together, only to discover that Py_BUILD_CORE is __NOT__ defined when building modules, only when building stuff linked directly into the core interpreter. Perhaps this ought to be defined when building the modules with setup.py? At any rate, I cannot proceed along the route suggested without this problem being resolved. On the DateFromTicks(), TimestampFromTicks(), TimeFromTicks() issue, I'm not sure that there is much benefit to including a C API for this since if the datetime module becomes the standard method for managing datetime objects, there is no point in having the DB API modules provide something that the datetime module already provides, right? During the transition period the few lines of code needed can be posted. If you disagree I can certainly provide the few lines as part of the patch but I suspect you will find resistance to having this included by Tim Peters, the maintainer (I believe) of the datetime module. Feel free to correct me... :-) ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-04-26 10:19 Message: Logged In: YES user_id=38388 Sorry for not getting back to you earlier: I didn't see you last message. 1-4) Python defines a macro during the Python build process that is not defined when compiling extensions: Py_BUILD_CORE You can use that macro to compile things differently for core things vs. extensions. 5) Fair enough; I don't see a point in creating a new numbering for each and every module. Please just use 1, 2, 3, 4, ... 6) Hope this makes sense :-) ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-04-26 09:35 Message: Logged In: YES user_id=619560 Any chance to look at this? Any hope of this being included in Python 2.4? I know a number of people (including Guido) who would appreciate that.... :-) ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-04-05 16:04 Message: Logged In: YES user_id=619560 I am back at work after finishing my move so I think I can finally devote a little more time to this issue. 1-4) The main reason for datetimeapi.h as opposed to simply modifying datetime.h was that the internal build needs to define things __differently__ from an external build of a module and there doesn't appear to be any way of fixing that -- so if you know a way I think I can manage to create a reasonable patch; otherwise, I'm out of my depth! 5) Guido was suggesting that a new PyIMPORT macro be made available which would verify that the magic number defined in the header file actually matches the magic number exported by the built module; this is simply a developer protection scheme which should eliminate really stupid uses; you can ask him about this or I can e-mail you part of the thread that brought this up 6) Makes sense. I'd like to get the questions above resolved first before proceeding any further, though. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-03-25 11:23 Message: Logged In: YES user_id=38388 Thanks for the comments... 1) Please put *all* the code for the C API into datetimeapi.h. I don't like your current mix of putting some things into datetime.h and others into datetimeapi.h (e.g. the PyDateTime_CAPI definition). 2) Since it's the only API missing if you want to use datetime objects in database interfacing, please add it. 3) dito. 4) Yes, the header file is the right place. Have a look at unicodeobject.h for what I have in mind (or mxDateTime.h for that matter). 5) Why add yet another magic number ? Isn't the Python API number enough ? 6) Since you don't provide a doc patch, please put comments into the header file. There can never be enough documentation and developers tend to look at the code rather than the docs ;-) ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-03-25 11:08 Message: Logged In: YES user_id=619560 Sorry for the delay. Things here have been quite busy recently both at work and at home. Let me see if I can answer your questions. 1) are you suggesting comments that include the macro names in datetimeapi.h similar to what I put in the comments below? Or something else? See modified datetimeapi.h for more info. 2) TimeFromTicks() is a very DB API specific routine. In chatting with others about the datetime module, they were not keen on adding such a beast. I guess there will have to be some discussion about whether datetimeapi.h is also a sort of half implementation for a C module implementing the DB API. I was intending to do this in my cx_Oracle module but not in datetimeapi.h. Could you clarify? 3) I could add C APIS for the three DB API ticks interfaces but I was simply intending to do that in cx_Oracle. Again, see #2. I can do it either way. :-) 4) I have added limited documentation in datetimeapi.h but is that really the right place for it? Is it even remotely close to what is needed? I'm not sure what is needed here exactly. 5) the API magic number is simply an arbitrary number which is stored in datetime.h and need not be understood by the implementor. For your information I simply took the name "datetime", converted each letter to its ordinal value in the alphabet, modded by 16 and used that hex character -- does that make any sense? This can be changed to whatever makes sense, though. 6) Whether or not datetimeapi.h should be sufficient for a developer or whether he should look at documentation in the usual locations (html pages, for example) I'll leave up to the Python development team. Let me know how I can assist. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-03-25 10:35 Message: Logged In: YES user_id=38388 Anthony, have you had a chance to look at the comments ? ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-02-26 08:06 Message: Logged In: YES user_id=619560 Oops! It looks like my own misunderstanding of SourceForge and how it works is to blame. :-( I'll take a look at this and get back to you as soon as possible -- ignore my previous comment. ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-02-26 08:03 Message: Logged In: YES user_id=619560 You haven't yet responded to my previous comments -- it looks like SourceForge put them __after__ your comments so it is quite understandable why you didn't notice them. If you can give me the answers to those questions or provide additional questions that I need to answer, then I think we can make progress again. I was waiting for __you__ :-) ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-02-25 16:08 Message: Logged In: YES user_id=38388 Any progress on this ? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-01-28 04:49 Message: Logged In: YES user_id=38388 Thanks for the clarification. I had forgotten about the macros -- I'd suggest that you document them in the datetimeapi.h include file to not cause the same confusion on the developer side (the trick to achieve adoption is to make things easy on the developer). As for TimeFromTicks(): This should be rather straight forward to implement: you take the time part of the ticks timestamp and create a time object from it. This is the way the DB API constructor works. Could you add C APIs for the three DB API ticks interface methods ? Other things that are missing: * documentation of the way the CAPI object can be used in datetimeapi.h * documentation of the various CAPI entries * documentation of the API magic number (there should be some scheme for this) I think that datetimeapi.h should be enough for a developer to read in order to use the interface. ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-01-26 14:02 Message: Logged In: YES user_id=619560 I didn't think any additional API would be necessary for extracting date time information since the following macros are available: PyDateTime_GET_YEAR(o) PyDateTime_GET_MONTH(o) PyDateTime_GET_DAY(o) PyDateTime_DATE_GET_HOUR(o) PyDateTime_DATE_GET_MINUTE(o) PyDateTime_DATE_GET_SECOND(o) PyDateTime_DATE_GET_MICROSECOND(o) PyDateTime_TIME_GET_HOUR(o) PyDateTime_TIME_GET_MINUTE(o) PyDateTime_TIME_GET_SECOND(o) PyDateTime_TIME_GET_MICROSECOND(o) Were you thinking of something else that is needed? As for interfacing at the C level for converting from Unix ticks, the following method is already available and could simply be used as a drop in replacement for DateFromTicks() and TimestampFromTicks() from the DB API document. DateFromTicks() --> datetime.date.fromtimestamp() TimestampFromTicks() --> datetime.datetime.fromtimestamp() TimeFromTicks() is not already exposed but discussions with Tim Peters already suggested that would not happen since the concept is rather strange. You'll have to discuss that with him if you disagree! :-) Any comments? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-01-26 13:46 Message: Logged In: YES user_id=38388 This is a good start. However, you should add more APIs for extracting date/time information to the C API. mxDateTime.h from egenix-mx-base can provide a good basis for this. If you want to make the datetime module usable for database interfacing at C level, you'll also have to add interfaces for Unix ticks conversion, since these are often used by database C level interfaces. ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-01-26 11:36 Message: Logged In: YES user_id=619560 I have no objection to providing patches for doc and test. A quick look at _testcapimodule.c doesn't provide any obvious ideas as to how to patch it. I looked for cStringIO which has a C API already and found nothing in there at all. The documentation also simply says "see the source for the information you require". Any suggestions as to how to proceed? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-01-25 20:17 Message: Logged In: YES user_id=31435 Marc-Andre, can you review this? I think you have more experience building C APIs for modules than anyone else (while I don't have any). There's certainly no objection to giving datetime a C API, and Guido already said he doesn't want to rely on that Martin changed datetime to be built as part of the core (in 2.3 on Windows, datetime.pyd was a distinct DLL; in CVS, datetime is compiled into the core DLL now). Anthony, you probably need to add doc and test patches. _testcapimodule.c holds tests of things you can only get at from C. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=876130&group_id=5470 From noreply at sourceforge.net Tue Jun 1 13:53:25 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jun 1 13:53:35 2004 Subject: [Patches] [ python-Patches-876130 ] add C API to datetime module Message-ID: Patches item #876130, was opened at 2004-01-13 10:20 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=876130&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Anthony Tuininga (atuining) Assigned to: Tim Peters (tim_one) Summary: add C API to datetime module Initial Comment: The datetime module does not have a C API which means that modules written in C cannot take advantage of the datetime module without incurring significant overhead. These patches supply this lack and are based on the C API exported by the mxDateTime module and the cStringIO module and enhanced as suggested by Guido. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2004-06-01 13:53 Message: Logged In: YES user_id=31435 I intend to do it this week, but have no time today or tomorrow. ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-06-01 13:44 Message: Logged In: YES user_id=619560 Sure. What's the chance of it being reviewed prior to the release of Python 2.4 a1? I just saw the preannouncement today -- it is scheduled for the end of this month, I believe. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-05-31 23:12 Message: Logged In: YES user_id=31435 Assigned to me for the next review. Can't do it immediately, but will do my best to free up some time for it "soon". ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-05-26 15:39 Message: Logged In: YES user_id=619560 I would agree with your assessment of the issue regarding the TimeFromTicks() API and find it quite reasonable. Either implement both at the C and Python levels or not at all. Since there is no consensus on this, none it is. :-) Did you have a chance to review the actual code? The changes are fairly minimal but you might have questions about readability, names, etc. It would be great if this could be included in an upcoming 2.4 alpha/beta so that I can provide support in cx_Oracle for the next release. Thanks for your time. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-05-26 15:32 Message: Logged In: YES user_id=31435 Under the belief that the *intent* of this patch is to add a C API to Python's datetime module, it should stick to exposing C ways to spell what Python programmers can already do from Python using datetime. Since nothing like TimeFromTicks() exists in the Python datetime API, it simply doesn't make sense to invent one available only from C. It *may* make sense to invent one in a DB API wrapper around datetime, but I view that as out of scope for this patch. I would not add TimeFromTicks() to the Python datetime API either, because the docs are ambiguous. The sample implementation Marc-Andre posted here uses localtime() to resolve the ambiguity in the docs, but that has to be a wrong choice for some time-of-day apps. For example, there's apparently no portable way to spell "noon" using TimeFromTicks(): the value you get back depends on which time zone localtime() happens to use at the time it's called. If people want time-of-day from a POSIX timestamp, it remains easy to get it from what datetime already supplies, but to do so you have to be explicit about whether you want UTC or local time interpretation. Both are easily spelled already, and it's a Good Thing that you need to be explicit if you want to do such a thing. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-05-26 15:25 Message: Logged In: YES user_id=38388 Tim, please review. Thanks. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-05-26 15:22 Message: Logged In: YES user_id=38388 Thanks, but I don't have time to review it. As for the TimeFromTicks() API: I can understand that you don't feel like implementing it, but hey, I won't use datetime either. The only reason I'm trying to push full support of the DB API specs is that Guido et al. wanted to see a note in the DB API that datetime also provides a usable interface to do date/time interfacing. I'm not very interested in datetime myself, since I'll continue to use mxDateTime, so the situation for me is somewhat similar to yours: investing time into something that I myself will probably not use much (I will add support to mxODBC for those who like to use datetime instead of mxDateTime, but won't use it myself). Feel free to check in your changes. Thanks. ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-05-26 12:30 Message: Logged In: YES user_id=619560 Attached are the modified patches based on your suggestions. I have tested them with my own module cx_Oracle and they appear to work correctly. Any further suggestions would be appreciated. I would like to see this included for Python 2.4 if at all possible. Please let me know what I need to do (if anything) to get this to happen. As for the TimeFromTicks() routine, Oracle has absolutely no use for a "time-only" data type and does not support it. It clearly does not have broad support so I really have no desire to implement it since I will never use it myself. If you consider it important, you could add it yourself or we could wait until someone else who requires it for their implementation of the DB API requires it. I'm not trying to be rude or trying to denigrate the DB API, simply trying to be practical. Please let me know if this is offensive in any way. Thanks. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-05-19 04:28 Message: Logged In: YES user_id=38388 >From the DB API specs: TimeFromTicks(ticks) This function constructs an object holding a time value from the given ticks value (number of seconds since the epoch; see the documentation of the standard Python time module for details). The reason for this having this API is to be able to construct an object suitable for passing to the database given a Unix ticks value. Since the ticks value contains both a date and a time part and most databases have a special column type for time value, we need two constructor APIs, one to extract just the date part and one for the time part. Here's the mxDateTime implementation for reference: def TimeFromTicks(ticks, # Locals: DateTimeDelta=DateTimeDelta,localtime=_time.localtime): """ TimeFromTicks(ticks) Constructs a DateTimeDelta instance pointing to the local time indicated by the given ticks value. The date part is ignored. """ return apply(DateTimeDelta, (0,) + localtime(ticks)[3:6]) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-05-03 13:46 Message: Logged In: YES user_id=31435 I don't understand what TimeFromTicks() is supposed to do. Seconds-from-the-epoch is a point in time, not a time-of- day. If some DB API requires guessing some transformation from seconds-from-the-epoch to time-of-day, that's fine, but it doesn't belong in Python's datetime module. The datetime module should certainly have a method to construct a datetime.datetime from a seconds-from-the- epoch argument -- seconds-from-the-epoch is a way of specifying a datetime.datetime. Given that, if the intent is to throw away the datetime.date portion of the datetime.datetime object, retaining only the datetime.time portion, then that's trivially accomplished by invoking dt.time () (where dt is the datetime.datetime object). Do any databases really store time-of-day as a seconds-from- the-epoch value? Google's top hit on TimeFromTicks() today happens to be a msg from Anthony saying that Oracle does not. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-05-03 13:24 Message: Logged In: YES user_id=38388 Macro: I don't know whether you need the macro or not (you probably do for the type checks). In any case, you can do without relying on Python providing you this information via the build process, since only datetimemodule.c is using the header file while Python is being built. TimeFromTicks(): I' ve stated my point. I don't think there's anything to add - I'm tired of fighting for these things... one of the reasons I stopped actively discussing things on python-dev. IMHO, a product that's aimed at developers should make things easy for the developer and try to avoid code duplication if possible. The API is needed in order to support database interfaces that use Unix ticks as basis for date/time, so if you don't add it to the module, the ten or twenty module authors out there will have to duplicate that piece of work in their implementation. Transition: This was already discussed on the db-api list. We love freedom of choice. Nothing to add. ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-05-03 12:48 Message: Logged In: YES user_id=619560 About the Py_BUILD_CORE issue: You are suggesting that I define this in datetimemodule.c just prior to the include of datetime.h? Or are you suggesting some other macro? I am not sure about the comment about "not needing a macro in the first place" since there are two groups that will be importing datetime.h: the first being the datetime module itself and the second being the DB API modules. The macro is definitely required to distinguish between the two -- unless I am missing something? On the TimeFromTicks() issue: You obviously consider it important that the three methods be available at the C level for DB API module authors to use directly. My objection is simply a reiteration of an objection raised by Tim Peters. I think you'll have to argue that one with him. :-) I'll provide my implementations for cx_Oracle as part of the patches and then you can fight it out and I'll stay out of it. :-) As for the transition period, I assumed that with the introduction of a standard datetime module, that it would become the suggested implementation for database interfaace modules. That said, I don't really have any authority to say anything on this front so I'll leave that to you and others to decide. :-) ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-05-03 11:26 Message: Logged In: YES user_id=38388 About the Py_BUILD_CORE issue: Sorry, I didn't know that Python does not define this macro for core modules. Nevertheless, looking at the datetime module code I don't really understand why you would need such a macro in the first place. Since the datetime module is the only code including the datetime.h header file it should be easy to add a macro definition just before importing datetime.h. On the TimeFromTicks() issue: The whole point of this discussion is to make the datetime module easily usable for authors of database modules. Since the DB API specifies that the module will need to export the three functions, two of which are available through the datetime module already, I don't really see your point in not wanting to add it. BTW, you are wrong in the assumption that the DB API spec will move away from a generic API for date/time objects. The DB API has always been defined in terms of interfaces and does not force a certain set of tools onto the developer. The datetime module will become one possible choice for DB API authors, others will want to stick to mxDateTime, use strings, ticks integers or more specific objects for interfacing. That won't change, so there is no "transition period". ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-05-03 10:40 Message: Logged In: YES user_id=619560 I spent some time getting the two include files merged together, only to discover that Py_BUILD_CORE is __NOT__ defined when building modules, only when building stuff linked directly into the core interpreter. Perhaps this ought to be defined when building the modules with setup.py? At any rate, I cannot proceed along the route suggested without this problem being resolved. On the DateFromTicks(), TimestampFromTicks(), TimeFromTicks() issue, I'm not sure that there is much benefit to including a C API for this since if the datetime module becomes the standard method for managing datetime objects, there is no point in having the DB API modules provide something that the datetime module already provides, right? During the transition period the few lines of code needed can be posted. If you disagree I can certainly provide the few lines as part of the patch but I suspect you will find resistance to having this included by Tim Peters, the maintainer (I believe) of the datetime module. Feel free to correct me... :-) ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-04-26 12:19 Message: Logged In: YES user_id=38388 Sorry for not getting back to you earlier: I didn't see you last message. 1-4) Python defines a macro during the Python build process that is not defined when compiling extensions: Py_BUILD_CORE You can use that macro to compile things differently for core things vs. extensions. 5) Fair enough; I don't see a point in creating a new numbering for each and every module. Please just use 1, 2, 3, 4, ... 6) Hope this makes sense :-) ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-04-26 11:35 Message: Logged In: YES user_id=619560 Any chance to look at this? Any hope of this being included in Python 2.4? I know a number of people (including Guido) who would appreciate that.... :-) ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-04-05 18:04 Message: Logged In: YES user_id=619560 I am back at work after finishing my move so I think I can finally devote a little more time to this issue. 1-4) The main reason for datetimeapi.h as opposed to simply modifying datetime.h was that the internal build needs to define things __differently__ from an external build of a module and there doesn't appear to be any way of fixing that -- so if you know a way I think I can manage to create a reasonable patch; otherwise, I'm out of my depth! 5) Guido was suggesting that a new PyIMPORT macro be made available which would verify that the magic number defined in the header file actually matches the magic number exported by the built module; this is simply a developer protection scheme which should eliminate really stupid uses; you can ask him about this or I can e-mail you part of the thread that brought this up 6) Makes sense. I'd like to get the questions above resolved first before proceeding any further, though. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-03-25 13:23 Message: Logged In: YES user_id=38388 Thanks for the comments... 1) Please put *all* the code for the C API into datetimeapi.h. I don't like your current mix of putting some things into datetime.h and others into datetimeapi.h (e.g. the PyDateTime_CAPI definition). 2) Since it's the only API missing if you want to use datetime objects in database interfacing, please add it. 3) dito. 4) Yes, the header file is the right place. Have a look at unicodeobject.h for what I have in mind (or mxDateTime.h for that matter). 5) Why add yet another magic number ? Isn't the Python API number enough ? 6) Since you don't provide a doc patch, please put comments into the header file. There can never be enough documentation and developers tend to look at the code rather than the docs ;-) ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-03-25 13:08 Message: Logged In: YES user_id=619560 Sorry for the delay. Things here have been quite busy recently both at work and at home. Let me see if I can answer your questions. 1) are you suggesting comments that include the macro names in datetimeapi.h similar to what I put in the comments below? Or something else? See modified datetimeapi.h for more info. 2) TimeFromTicks() is a very DB API specific routine. In chatting with others about the datetime module, they were not keen on adding such a beast. I guess there will have to be some discussion about whether datetimeapi.h is also a sort of half implementation for a C module implementing the DB API. I was intending to do this in my cx_Oracle module but not in datetimeapi.h. Could you clarify? 3) I could add C APIS for the three DB API ticks interfaces but I was simply intending to do that in cx_Oracle. Again, see #2. I can do it either way. :-) 4) I have added limited documentation in datetimeapi.h but is that really the right place for it? Is it even remotely close to what is needed? I'm not sure what is needed here exactly. 5) the API magic number is simply an arbitrary number which is stored in datetime.h and need not be understood by the implementor. For your information I simply took the name "datetime", converted each letter to its ordinal value in the alphabet, modded by 16 and used that hex character -- does that make any sense? This can be changed to whatever makes sense, though. 6) Whether or not datetimeapi.h should be sufficient for a developer or whether he should look at documentation in the usual locations (html pages, for example) I'll leave up to the Python development team. Let me know how I can assist. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-03-25 12:35 Message: Logged In: YES user_id=38388 Anthony, have you had a chance to look at the comments ? ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-02-26 10:06 Message: Logged In: YES user_id=619560 Oops! It looks like my own misunderstanding of SourceForge and how it works is to blame. :-( I'll take a look at this and get back to you as soon as possible -- ignore my previous comment. ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-02-26 10:03 Message: Logged In: YES user_id=619560 You haven't yet responded to my previous comments -- it looks like SourceForge put them __after__ your comments so it is quite understandable why you didn't notice them. If you can give me the answers to those questions or provide additional questions that I need to answer, then I think we can make progress again. I was waiting for __you__ :-) ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-02-25 18:08 Message: Logged In: YES user_id=38388 Any progress on this ? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-01-28 06:49 Message: Logged In: YES user_id=38388 Thanks for the clarification. I had forgotten about the macros -- I'd suggest that you document them in the datetimeapi.h include file to not cause the same confusion on the developer side (the trick to achieve adoption is to make things easy on the developer). As for TimeFromTicks(): This should be rather straight forward to implement: you take the time part of the ticks timestamp and create a time object from it. This is the way the DB API constructor works. Could you add C APIs for the three DB API ticks interface methods ? Other things that are missing: * documentation of the way the CAPI object can be used in datetimeapi.h * documentation of the various CAPI entries * documentation of the API magic number (there should be some scheme for this) I think that datetimeapi.h should be enough for a developer to read in order to use the interface. ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-01-26 16:02 Message: Logged In: YES user_id=619560 I didn't think any additional API would be necessary for extracting date time information since the following macros are available: PyDateTime_GET_YEAR(o) PyDateTime_GET_MONTH(o) PyDateTime_GET_DAY(o) PyDateTime_DATE_GET_HOUR(o) PyDateTime_DATE_GET_MINUTE(o) PyDateTime_DATE_GET_SECOND(o) PyDateTime_DATE_GET_MICROSECOND(o) PyDateTime_TIME_GET_HOUR(o) PyDateTime_TIME_GET_MINUTE(o) PyDateTime_TIME_GET_SECOND(o) PyDateTime_TIME_GET_MICROSECOND(o) Were you thinking of something else that is needed? As for interfacing at the C level for converting from Unix ticks, the following method is already available and could simply be used as a drop in replacement for DateFromTicks() and TimestampFromTicks() from the DB API document. DateFromTicks() --> datetime.date.fromtimestamp() TimestampFromTicks() --> datetime.datetime.fromtimestamp() TimeFromTicks() is not already exposed but discussions with Tim Peters already suggested that would not happen since the concept is rather strange. You'll have to discuss that with him if you disagree! :-) Any comments? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-01-26 15:46 Message: Logged In: YES user_id=38388 This is a good start. However, you should add more APIs for extracting date/time information to the C API. mxDateTime.h from egenix-mx-base can provide a good basis for this. If you want to make the datetime module usable for database interfacing at C level, you'll also have to add interfaces for Unix ticks conversion, since these are often used by database C level interfaces. ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-01-26 13:36 Message: Logged In: YES user_id=619560 I have no objection to providing patches for doc and test. A quick look at _testcapimodule.c doesn't provide any obvious ideas as to how to patch it. I looked for cStringIO which has a C API already and found nothing in there at all. The documentation also simply says "see the source for the information you require". Any suggestions as to how to proceed? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-01-25 22:17 Message: Logged In: YES user_id=31435 Marc-Andre, can you review this? I think you have more experience building C APIs for modules than anyone else (while I don't have any). There's certainly no objection to giving datetime a C API, and Guido already said he doesn't want to rely on that Martin changed datetime to be built as part of the core (in 2.3 on Windows, datetime.pyd was a distinct DLL; in CVS, datetime is compiled into the core DLL now). Anthony, you probably need to add doc and test patches. _testcapimodule.c holds tests of things you can only get at from C. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=876130&group_id=5470 From noreply at sourceforge.net Tue Jun 1 18:17:11 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jun 1 18:17:19 2004 Subject: [Patches] [ python-Patches-959534 ] Arrange 64bits detection for ReliantUnix Message-ID: Patches item #959534, was opened at 2004-05-24 18:13 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=959534&group_id=5470 Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Jean-frederic Clere (jfclere) Assigned to: Nobody/Anonymous (nobody) Summary: Arrange 64bits detection for ReliantUnix Initial Comment: When compiling python on ReliantUnix (5.43) the compilation fails with unresolved externals like fstatvfs64, lseek64 etc Those routines belong to 5.45. The patch detects the missing lseek64() and suppress lfs support (use_lfs=no). ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-06-02 00:17 Message: Logged In: YES user_id=21627 Hmm. Why are you checking for Sinix at all? If the test fails, isn't it likely that LFS doesn't work on the platform? ---------------------------------------------------------------------- Comment By: Jean-frederic Clere (jfclere) Date: 2004-06-01 18:56 Message: Logged In: YES user_id=92497 Oops... That is better to check for SINIX-* before trying the link. I have more to submit because the dynamic linking needs additional libc. For example in setup.py +++ exts.append( Extension('_hotshot', ['_hotshot.c'], libraries=['c']) ) +++ ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-05-31 20:27 Message: Logged In: YES user_id=21627 Why do you check for SINIX after the link test fails? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=959534&group_id=5470 From noreply at sourceforge.net Wed Jun 2 06:08:15 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jun 2 06:08:47 2004 Subject: [Patches] [ python-Patches-954115 ] Fix os.stat handling of UNC roots Message-ID: Patches item #954115, was opened at 2004-05-14 19:57 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=954115&group_id=5470 Category: Core (C code) Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 6 Submitted By: Greg Chapman (glchapman) Assigned to: Martin v. L?wis (loewis) Summary: Fix os.stat handling of UNC roots Initial Comment: This is a patch for the bug described at: www.python.org/sf/513572 The patch adds two new routines to posixmodule.c: IsUNCRootA and IsUNCRootW which test if a supplied path matches the pattern for a UNC root directory. These routines are called by posix_do_stat in two different places: 1) when testing if a path with a trailing slash is a drive root and 2) to see if a path without a trailing slash is a UNC root. The first of these is the real bug fix; it allows UNC roots to be specified as "//server/share/" rather than "//server/share//". The second was added because it is easy to forget to add the trailing slash to "//server/share", but stats of UNC roots without the trailing slash will fail. However, I think this is an optional addition. I'm not sure what to do about tests, since existing shares will obviously vary from system to system, and it seems to me that the test suite should not temporarily add a share just to test this feature. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-06-02 12:08 Message: Logged In: YES user_id=21627 Thanks for the patch. Applied as posixmodule.c 2.318 2.300.8.10 NEWS 1.982 1.831.4.113 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=954115&group_id=5470 From noreply at sourceforge.net Wed Jun 2 08:29:41 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jun 2 08:29:47 2004 Subject: [Patches] [ python-Patches-962502 ] East Asian Width support for Unicode Message-ID: Patches item #962502, was opened at 2004-05-29 00:59 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=962502&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Hye-Shik Chang (perky) >Assigned to: Hye-Shik Chang (perky) Summary: East Asian Width support for Unicode Initial Comment: As David Goodger's inspiration, I thought that it would be great if we have some unicode methods that manipulates East Asian Width (http://www.unicode.org/reports/tr11/tr11-13.html#UCD). The attached patch implements rough first-time idea. >>> u'1'.iswide() False >>> u'\uac00'.iswide() True >>> u'\ud55c\uae00'.iswide() True >>> u'\ud55c\uae00'.width() 4 >>> u'ab\ud55c\uae00'.width() 6 >>> u'ab\ud55c\uae00'.iswide() False ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-06-02 14:29 Message: Logged In: YES user_id=21627 The patch is fine, please apply. Make sure you add appropriate documentation and test cases. You might consider moving flags at the end of the struct, so that no padding is added for UCS-4 builds. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-06-01 15:46 Message: Logged In: YES user_id=55188 Okay. In fact I don't care of Unicode 4.0. I'm fine with 3.2. I uploaded new patch sticking Unicode revision on 3.2. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-05-31 23:07 Message: Logged In: YES user_id=21627 Updating to the Unicode 4.0 database is risky. It will break IDNA, which specifies that IDN must use the 3.2 version of the unicode database. It would be ok if you could arrange to provide both versions of the database. Ideally, the database would only store the deltas from 4.0 to 3.2, so we don't get any increase in space for cases where the data didn't change between Unicode versions. It might be reasonable to leave that issue alone for this patch, and proceed with the 3.2 version of EastAsianWidth. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=962502&group_id=5470 From noreply at sourceforge.net Wed Jun 2 09:57:00 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jun 2 09:57:05 2004 Subject: [Patches] [ python-Patches-965036 ] Fix for #777597 - socketmodule.c connection handling incorec Message-ID: Patches item #965036, was opened at 2004-06-02 15:57 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=965036&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Troels Walsted Hansen (troels) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for #777597 - socketmodule.c connection handling incorec Initial Comment: I took Garth Bushell's inlined code from http://python.org/sf/777597 and produced a patch per nnorwitz's request in the bug comments. The patch is for Python 2.3.4. I created the patch as a starting point for a fix. I don't believe that this patch is the correct fix for the problem, so it should definitely not be applied in the current form. One major problem is that Garth removed the writefds fd_set, which means that the code will detect "connection refused" and "timeout" events, but not "connection established". The code also needs compliation and runtime testing (maybe even a regression test to cover this common WinSock programming error?). I hope to submit a fixed and tested patch soon. I'll upload it here when it is ready. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=965036&group_id=5470 From noreply at sourceforge.net Wed Jun 2 12:59:54 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jun 2 12:59:57 2004 Subject: [Patches] [ python-Patches-965175 ] improve markupbase.py error reporting Message-ID: Patches item #965175, was opened at 2004-06-02 12:59 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=965175&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: No Spam (not4spam) Assigned to: Nobody/Anonymous (nobody) Summary: improve markupbase.py error reporting Initial Comment: This is just a minor nit, but in "_scan_name" in "markupbase.py" if it cannot find a name token, it just reports "expected name token" without any identifying information. This can be easily improved by changing the line (379) from, self.error("expected name token") to, self.error("expected name token at '%s'" % rawdata[declstartpos:declstartpos+20]) which will show 20 characters of text where the error occured. Perhaps this can be changed in version 2.4? Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=965175&group_id=5470 From noreply at sourceforge.net Wed Jun 2 13:00:09 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jun 2 13:00:15 2004 Subject: [Patches] [ python-Patches-962502 ] East Asian Width support for Unicode Message-ID: Patches item #962502, was opened at 2004-05-29 07:59 Message generated for change (Comment added) made by perky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=962502&group_id=5470 Category: Core (C code) Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Hye-Shik Chang (perky) Assigned to: Hye-Shik Chang (perky) Summary: East Asian Width support for Unicode Initial Comment: As David Goodger's inspiration, I thought that it would be great if we have some unicode methods that manipulates East Asian Width (http://www.unicode.org/reports/tr11/tr11-13.html#UCD). The attached patch implements rough first-time idea. >>> u'1'.iswide() False >>> u'\uac00'.iswide() True >>> u'\ud55c\uae00'.iswide() True >>> u'\ud55c\uae00'.width() 4 >>> u'ab\ud55c\uae00'.width() 6 >>> u'ab\ud55c\uae00'.iswide() False ---------------------------------------------------------------------- >Comment By: Hye-Shik Chang (perky) Date: 2004-06-03 02:00 Message: Logged In: YES user_id=55188 I just checked in. Thanks for the review! Doc/api/concrete.tex 1.42 Doc/lib/libstdtypes.tex 1.154 Include/unicodeobject.h 2.43 Lib/test/test_unicode.py 1.88 Misc/NEWS 1.983 1.984 Modules/unicodedata_db.h 1.10 Modules/unicodename_db.h 1.7 Objects/unicodectype.c 2.15 Objects/unicodeobject.c 2.212 Objects/unicodetype_db.h 1.8 Tools/unicode/makeunicodedata.py 1.18 ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-06-02 21:29 Message: Logged In: YES user_id=21627 The patch is fine, please apply. Make sure you add appropriate documentation and test cases. You might consider moving flags at the end of the struct, so that no padding is added for UCS-4 builds. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-06-01 22:46 Message: Logged In: YES user_id=55188 Okay. In fact I don't care of Unicode 4.0. I'm fine with 3.2. I uploaded new patch sticking Unicode revision on 3.2. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-06-01 06:07 Message: Logged In: YES user_id=21627 Updating to the Unicode 4.0 database is risky. It will break IDNA, which specifies that IDN must use the 3.2 version of the unicode database. It would be ok if you could arrange to provide both versions of the database. Ideally, the database would only store the deltas from 4.0 to 3.2, so we don't get any increase in space for cases where the data didn't change between Unicode versions. It might be reasonable to leave that issue alone for this patch, and proceed with the 3.2 version of EastAsianWidth. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=962502&group_id=5470 From noreply at sourceforge.net Wed Jun 2 14:20:18 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jun 2 14:20:21 2004 Subject: [Patches] [ python-Patches-965192 ] improve markupbase.py error reporting Message-ID: Patches item #965192, was opened at 2004-06-02 14:20 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=965192&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: No Spam (not4spam) Assigned to: Nobody/Anonymous (nobody) Summary: improve markupbase.py error reporting Initial Comment: This is just a minor nit, but in "_scan_name" in "markupbase.py" if it cannot find a name token, it just reports "expected name token" without any identifying information. This can be easily improved by changing the line (379) from, self.error("expected name token") to, self.error("expected name token at '%s'" % rawdata[declstartpos:declstartpos+20]) which will show 20 characters of text where the error occured. Perhaps this can be changed in version 2.4? Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=965192&group_id=5470 From noreply at sourceforge.net Wed Jun 2 17:11:04 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jun 2 17:11:12 2004 Subject: [Patches] [ python-Patches-641685 ] Use .dylib for shared objects on MacOS X Message-ID: Patches item #641685, was opened at 2002-11-21 07:12 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=641685&group_id=5470 Category: Build Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Ronald Oussoren (ronaldoussoren) Assigned to: Jack Jansen (jackjansen) Summary: Use .dylib for shared objects on MacOS X Initial Comment: This patch enables python to recognize .dylib as a valid shared library extension on MacOS X/Darwin. Python will also use .dylib as the extension for native-code python modules; .so files are still recognized for backward compatibility. The reason for writing this patch was that setup.py failes to recognize the existince of openssl because there is only a shared library with suffix .dylib. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2004-06-02 23:11 Message: Logged In: YES user_id=45365 Closing this: the main part of the patch was recognizing .dylib as an allowed extension for shared libraries in distutils. The other part of the patch (using .dylib for Python extension modules in stead of .so) has been overtaken by real world events: Apple now lists .so as the extension used by "various unix packages" (read: Apache and Python:-) for dynamically loaded extensions. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-12 03:35 Message: Logged In: YES user_id=33168 Jack, what should be done for this patch? ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-12-03 19:33 Message: Logged In: YES user_id=11375 Reassigning to Jack. (It doesn't look like find_library_file in setup.jaguar.py is actually used, so maybe you could just delete it.) ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-11-27 14:48 Message: Logged In: YES user_id=11375 I've checked in my setup.py patch, and the Lib/distutils/extension.py portion of Ronald's patch. Is the rest of Ronald's patch OK? Should I check that in, too? Jack reports that there's also a duplicate find_library_file in Mac/OSX/setup.jaguar.py. ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2002-11-27 10:27 Message: Logged In: YES user_id=580910 I don't have checkin priviliges for the Python CVS repository, so feel free to checkin my patches if they are correct. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2002-11-26 23:29 Message: Logged In: YES user_id=45365 I think that if we keep .so as an allowed extension for dynamically loaded modules we're okay for both 2.3a0 and 2.2.X. Unless I misunderstand how compatibility between micro-releases is suppoosed to work, should it be forward compatible too? I.e. if 2.2.3 would create dynamic modules with .dylib they won't be useable in 2.2.2. If that is a problem then I think we should keep .so as the default and allow .dylib (for 2.2.X, for 2.3 we should do the right thing). ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-11-26 18:28 Message: Logged In: YES user_id=11375 Noted; updated version of the patch attached that uses os.path.dirname. I'll check it in after testing it on the Mac. Thanks! ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-11-26 17:11 Message: Logged In: YES user_id=21627 Andrew, that part is fine, please check it in. There is on pitfall, though: if one of the std_dirs is a prefix of one of the paths, and the library is found in that path, the function will return the wrong result. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-11-26 16:37 Message: Logged In: YES user_id=11375 I can't pronounce on the rest of Ronald's patch, but the patch to distutils/extension.py seems obviously correct and should be committed in any case. Ronald, do you have CVS access or should I check it in? ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2002-11-25 09:00 Message: Logged In: YES user_id=580910 Somehow I didn't upload the patch when I created this thread. Here it is. ---------------------------------------------------------------------- Comment By: Dan Wolfe (dkwolfe) Date: 2002-11-24 08:16 Message: Logged In: YES user_id=80173 I previously assumed that OS X was capable of linking against .so file. This turns out not to be the case (thanks Ronald for making me a believer!) and Ronald's original patch would have also fixed the problem. I tested both Ronald's and akuchling patches together, along with a minor modification to unixcompiler.py to remove the two dylib blocks from the find_library_file function (no longer needed with Ronald's patches) under 10.2.2, and everything works fine in a framework and regular Unix build. Only thing to worry about is that the modules in the lib-dynload directory now have a .dylib suffix. The readme should probably be updated to tell the user they need to manually remove these files. Also, the test_socket_ssl.py is not run unless a -u network is made part of the test cmd line. ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2002-11-22 22:20 Message: Logged In: YES user_id=580910 Please keep in mind that the .so suffix is not a valid shared-library suffix on MacOS X: The linker will not check for 'libfoo.so' if you link with '-lfoo'. It might therefore be prudent to look for the .dylib before looking for a .so (if you want to look for a .so at all). ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-11-22 14:36 Message: Logged In: YES user_id=11375 I've tried my patch now, and with it SSL support is automatically built on MacOS X. Whether or not this fixes the bug, though, I think this patch should be applied to cut down on some code duplication. If someone else can make a quick sanity-check on the patch in case of silly errors, I'll check it in. (Is it a bugfix candidate? Not sure, but I'm leaning toward "yes".) I've also revised the patch to make its behaviour completely compatible with the unpatched version of find_library_file; bug-in-waiting pointed out by Dan Wolfe. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-11-21 21:43 Message: Logged In: YES user_id=11375 I've attached a copy of my still-untested patch that fixes the code duplication in setup.py. I'll try to test it this evening. ---------------------------------------------------------------------- Comment By: Dan Wolfe (dkwolfe) Date: 2002-11-21 20:19 Message: Logged In: YES user_id=80173 There's a problem regarding Ronald's SSL patches - they make setup assume that every shared library is a .dylib rather than either a .so or .dylib, which breaks compatibility.... After some late night investigation, I found that the source of the problem is distutils. We previously had a problem under Mac OS X where it wasn't finding the .dylib libraries for libz and other similar .dylib libraries - both user and system installed. Someone came up with a patch and this can be found in /distutils/unixcompiler.py around line 278 in the function find_library_file. Basically, it just adds another check to look for .dylib if it can't find the .so file. The unixcompiler.py file inherits from the ccompiler.py file which has a stub routine for this function. For the longest time I thought the function in unixcompiler.py was being called and was pulling my hair out trying to figure out why it wasn't being finding the ssl library since it only looked for .a and .so files... It turns out that setup.py also implements a function by the SAME name, but with different parameters and instead of returning a true/false to indicate whether the library exists, it returns the pathname to the library. This function, unfortunately, was NOT previously modify to support dylibs and as a result only .a and .so files would be searched for. Below is a diff that fixes the problem simply by adding another check for a dylib file and returning the results if it exists. lobo% diff -u /Users/lobo/Desktop/Python-2.2.2/setupold.py /Users/lobo/Desktop/Python-2.2.2/setup.py --- /Users/lobo/Desktop/Python-2.2.2/setupold.py Wed Oct 9 17:59:16 2002 +++ /Users/lobo/Desktop/Python-2.2.2/setup.py Thu Nov 21 09:12:43 2002 @@ -44,6 +44,10 @@ filename = compiler.library_filename(libname, lib_type='shared') result = find_file(filename, std_dirs, paths) if result is not None: return result + + filename = compiler.library_filename(libname, lib_type='dylib') + result = find_file(filename, std_dirs, paths) + if result is not None: return result filename = compiler.library_filename(libname, lib_type='static') result = find_file(filename, std_dirs, paths) I've minimally tested it using the normal non framework installed and it appears to function correctly. Enjoy. (sorry about not uploading a patch but SF crashes IE and Chimera doesn't allow a attachement....) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=641685&group_id=5470 From noreply at sourceforge.net Wed Jun 2 17:17:20 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jun 2 17:17:25 2004 Subject: [Patches] [ python-Patches-869555 ] Building on Mac OS X 10.1 Message-ID: Patches item #869555, was opened at 2004-01-02 21:36 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=869555&group_id=5470 Category: Macintosh Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Ronald Oussoren (ronaldoussoren) Assigned to: Jack Jansen (jackjansen) Summary: Building on Mac OS X 10.1 Initial Comment: This patch contains two changes to allow building on MacOS X 10.1 1) A change to macosmodule.c that only enables the code using 'CGMainDisplayID' on MacOS X 10.2 and later, the function is not available on 10.1 2) Some conditional code in Mac/OSX/Makefile that chooses pbxbuild or xcodebuild depending on which one is on the system (prefering xcodebuild). I have barely tested these changes, they seem to work well enough on 10.1. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2004-06-02 23:17 Message: Logged In: YES user_id=45365 Ronald, I applied the Makefile portion of the patch. The macosmodule.c part I had already solved (but it was still sitting on my disk only) in a different way. Do you still have easy access to 10.1? If so: could you check that the 2.3 branch (and the 2.4 trunk) now builds on 10.1? If not: let me know and I'll try. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=869555&group_id=5470 From noreply at sourceforge.net Wed Jun 2 17:27:43 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jun 2 17:27:49 2004 Subject: [Patches] [ python-Patches-869555 ] Building on Mac OS X 10.1 Message-ID: Patches item #869555, was opened at 2004-01-02 21:36 Message generated for change (Comment added) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=869555&group_id=5470 Category: Macintosh Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Ronald Oussoren (ronaldoussoren) Assigned to: Jack Jansen (jackjansen) Summary: Building on Mac OS X 10.1 Initial Comment: This patch contains two changes to allow building on MacOS X 10.1 1) A change to macosmodule.c that only enables the code using 'CGMainDisplayID' on MacOS X 10.2 and later, the function is not available on 10.1 2) Some conditional code in Mac/OSX/Makefile that chooses pbxbuild or xcodebuild depending on which one is on the system (prefering xcodebuild). I have barely tested these changes, they seem to work well enough on 10.1. ---------------------------------------------------------------------- >Comment By: Ronald Oussoren (ronaldoussoren) Date: 2004-06-02 23:27 Message: Logged In: YES user_id=580910 No, I erased my 10.1 partition to be able to test on 10.2. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2004-06-02 23:17 Message: Logged In: YES user_id=45365 Ronald, I applied the Makefile portion of the patch. The macosmodule.c part I had already solved (but it was still sitting on my disk only) in a different way. Do you still have easy access to 10.1? If so: could you check that the 2.3 branch (and the 2.4 trunk) now builds on 10.1? If not: let me know and I'll try. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=869555&group_id=5470 From noreply at sourceforge.net Wed Jun 2 18:21:17 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jun 2 18:21:25 2004 Subject: [Patches] [ python-Patches-965036 ] Fix for #777597 - socketmodule.c connection handling incorec Message-ID: Patches item #965036, was opened at 2004-06-02 15:57 Message generated for change (Comment added) made by troels You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=965036&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Troels Walsted Hansen (troels) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for #777597 - socketmodule.c connection handling incorec Initial Comment: I took Garth Bushell's inlined code from http://python.org/sf/777597 and produced a patch per nnorwitz's request in the bug comments. The patch is for Python 2.3.4. I created the patch as a starting point for a fix. I don't believe that this patch is the correct fix for the problem, so it should definitely not be applied in the current form. One major problem is that Garth removed the writefds fd_set, which means that the code will detect "connection refused" and "timeout" events, but not "connection established". The code also needs compliation and runtime testing (maybe even a regression test to cover this common WinSock programming error?). I hope to submit a fixed and tested patch soon. I'll upload it here when it is ready. ---------------------------------------------------------------------- >Comment By: Troels Walsted Hansen (troels) Date: 2004-06-03 00:21 Message: Logged In: YES user_id=32863 OK... As promised, here is the regression test. The test passes on Linux and fails on Windows XP with Python 2.3.4 with the error below. I'd appreciate any comments on the test. FAIL: testTCPConnectionRefused (__main__.TCPConnectionRefusedTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "Lib\test\test_socket.py", line 752, in testTCPConnectionRefused self.failUnlessEqual(exc_type, socket.error) File "C:\Program Files\Python23\lib\unittest.py", line 302, in failUnlessEqual raise self.failureException, AssertionError: != ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=965036&group_id=5470 From noreply at sourceforge.net Wed Jun 2 18:41:39 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jun 2 18:43:17 2004 Subject: [Patches] [ python-Patches-548197 ] Adds cookie support to urllib2.py Message-ID: Patches item #548197, was opened at 2002-04-24 17:31 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=548197&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jeff Pitman (bruthasj) Assigned to: Jeremy Hylton (jhylton) Summary: Adds cookie support to urllib2.py Initial Comment: Problem Whenever urllib2 encounters a complex sequence of redirects and authentication schemes it is extremely difficult to "inject" Cookie headers to each request. Solution Make a small change to AbstractHTTPHandler that will detect on a host-by-host basis if there are any stored cookies. This is done by using a Dict that is initialized on import of urllib2. Therefore the Dict of Hosts is available throughout multiple instances of request objects and multiple urlopens on those objects. Upon detection, it will send the Cookies along with the other request headers to the host. If there isn't any, it just skips it. The next thing is to collect the Cookies when we get the "reply" from the host. All of this is done within AbstractHTTPHandler -- no other modifications required. Test I can login into http://mantisbt.sf.net/ which requires the browser to maintain a set of cookies during the session. Future * Maybe use external files to store and control storage of cookies * Better API in Cookie module so we don't have to do the string.split hack * Better API in urllib2 for Cookies (or just make it transparent? or both?) ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2004-06-02 23:41 Message: Logged In: YES user_id=261020 This should be closed, since it's obsoleted by the new module cookielib (patch 963318). ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-12-09 20:50 Message: Logged In: YES user_id=261020 I just noticed the thread on c.l.py about this, rather late... a day before that thread started (great minds think alike, apparently), I released the first version of this: http://wwwsearch.sourceforge.net/ClientCookie I intend eventually to get it into a fit state for inclusion in Python. It's certainly not there yet, but it does work, and is integrated with urllib2. ---------------------------------------------------------------------- Comment By: Moshe Zadka (moshez) Date: 2002-06-11 12:22 Message: Logged In: YES user_id=11645 You're giving no control at all to the Python user over cookies. Additionally, doing it on a per-import basis is wrong: what if there are two non-co-operating modules each using urllib2 for their own purposes?. I suggest writing a Cookie mixin which people can mixin to their classes when they create a manager, which will keep a list of cookies and so on. Thanks. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-30 19:20 Message: Logged In: YES user_id=80475 I think this looks good. Please resubmit patch using the latest version of urllib2.py and using string methods instead of the (about to be deprecated) string module. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=548197&group_id=5470 From noreply at sourceforge.net Thu Jun 3 00:57:30 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jun 3 00:57:37 2004 Subject: [Patches] [ python-Patches-921793 ] Rewrite of site.py Message-ID: Patches item #921793, was opened at 2004-03-23 07:05 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=921793&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 3 Submitted By: Brett Cannon (bcannon) Assigned to: Nobody/Anonymous (nobody) Summary: Rewrite of site.py Initial Comment: Brought to you by the PyCon core sprint, I rewrote Lib/site.py to clean it up and modernize it. The biggest change is putting all the code into appropriate functions and defining a main() function that gets executed at import. Cleans up the code and allows others to run the functions after import in case they want the functionality. Also modernized it by using sets and universal newlines. A new test suite is also being included in this tracker item. You can partially run it against the original site.py, but some tests will fail since they call new functions. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2004-06-02 21:57 Message: Logged In: YES user_id=357491 Thanks to Raymond, I have worked out a single bug in my code (left out an import that only shows up under Windows) and fixed some bad tests. Unless someone finds some bugs in this in a week or so I will check this in. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-05-31 16:39 Message: Logged In: YES user_id=357491 Re-generated the diff for site.py; turned out it didn't apply cleanly. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-03-23 09:44 Message: Logged In: YES user_id=357491 OK, now the test passes. Problem test was not matching what the code did by creating a normalized, absolute path of what was in sys.path . ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-03-23 09:37 Message: Logged In: YES user_id=357491 Just discovered one of the regression tests fails if you run all the tests with regrtest.py. Trying to fix now since it is a bug in the test. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=921793&group_id=5470 From noreply at sourceforge.net Thu Jun 3 03:07:05 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jun 3 03:07:14 2004 Subject: [Patches] [ python-Patches-959534 ] Arrange 64bits detection for ReliantUnix Message-ID: Patches item #959534, was opened at 2004-05-24 18:13 Message generated for change (Comment added) made by jfclere You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=959534&group_id=5470 Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Jean-frederic Clere (jfclere) Assigned to: Nobody/Anonymous (nobody) Summary: Arrange 64bits detection for ReliantUnix Initial Comment: When compiling python on ReliantUnix (5.43) the compilation fails with unresolved externals like fstatvfs64, lseek64 etc Those routines belong to 5.45. The patch detects the missing lseek64() and suppress lfs support (use_lfs=no). ---------------------------------------------------------------------- >Comment By: Jean-frederic Clere (jfclere) Date: 2004-06-03 09:07 Message: Logged In: YES user_id=92497 Checking for Sinix is need because the SINIX unistd.h redefines lseek() into lseek64() when LFS is required (via _FILE_OFFSET_BITS and/or _LFS64_LARGEFILE). Checking for LFS via AC_TRY_LINK for most platforms means more tests. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-06-02 00:17 Message: Logged In: YES user_id=21627 Hmm. Why are you checking for Sinix at all? If the test fails, isn't it likely that LFS doesn't work on the platform? ---------------------------------------------------------------------- Comment By: Jean-frederic Clere (jfclere) Date: 2004-06-01 18:56 Message: Logged In: YES user_id=92497 Oops... That is better to check for SINIX-* before trying the link. I have more to submit because the dynamic linking needs additional libc. For example in setup.py +++ exts.append( Extension('_hotshot', ['_hotshot.c'], libraries=['c']) ) +++ ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-05-31 20:27 Message: Logged In: YES user_id=21627 Why do you check for SINIX after the link test fails? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=959534&group_id=5470 From noreply at sourceforge.net Thu Jun 3 05:19:09 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jun 3 05:21:52 2004 Subject: [Patches] [ python-Patches-957240 ] Patch for feature request 491033 Message-ID: Patches item #957240, was opened at 2004-05-20 08:23 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=957240&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 6 Submitted By: Josiah Carlson (josiahcarlson) Assigned to: Martin v. L?wis (loewis) Summary: Patch for feature request 491033 Initial Comment: The attached patch is to offer the functionality desired by feature request: python.org/sf/491033 On machines that use standard IEEE floating point doubles, the 'infinity' needs only to be 1e16 due to the limited precision of floating point. 1e309 is used for convenience sake, and will continue to be a precision infinity until 1024 bits of precision in floating point values is available. At such point in time where 1e309 is available in hardware, it will still sufficient due to the practical limitations of counting. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-06-03 11:19 Message: Logged In: YES user_id=21627 Thanks for the patch. Applied as libasyncore.tex 1.15 asyncore.py 1.51 NEWS 1.986 ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-05-31 22:36 Message: Logged In: YES user_id=341410 The attached patch includes both a documentation patch, as well as a modified loop patch to explicitly match the documentation. The patches are concatenated and in standard context diff format (as per the Python patch submission guidelines, sorry about the previous unified diff). The test suite does not seem to contain tests for asyncore. It does contain a test for asynchat, which will be unaffected by this patch. One thing to note: the use of 'count = count - 1' rather than 'count -= 1' is to remove potential bugs in the case where a mutable number-like object with a modifying __isub__ method were to be passed by a user. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-05-31 20:32 Message: Logged In: YES user_id=21627 This patch lacks changes to the documentation and the test suite. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-05-20 08:26 Message: Logged In: YES user_id=341410 Sorry about that, I generated the patch by hand and got the ordering messed up. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=957240&group_id=5470 From noreply at sourceforge.net Thu Jun 3 05:25:12 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jun 3 05:25:29 2004 Subject: [Patches] [ python-Patches-929192 ] Improvements to Bluetooth support Message-ID: Patches item #929192, was opened at 2004-04-04 13:44 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=929192&group_id=5470 Category: Modules Group: Python 2.4 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Paul Clifford (pclifford) Assigned to: Martin v. L?wis (loewis) Summary: Improvements to Bluetooth support Initial Comment: This patch changes the address format used for Bluetooth addresses from a tuple of six numbers into a string of the form "XX:XX:XX:XX:XX:XX", as is more commonly seen elsewhere. I've also extended makesockaddr so that it returns a Python object of the type expected by bind, connect, etc, when given a Bluetooth address struct. A full summary of the changes to socketmodule.c: * Added setbdaddr and makebdaddr (conditional on the definition of USE_BLUETOOTH), which work a bit like setipaddr and makeipaddr. * Extended makesockaddr to understand Bluetooth addresses, and added a proto argument to distinguish between the protocols. * Changed getsockaddr to expect the Bluetooth addresses as a string, not a six element tuple. * Changed the BDADDR_ANY and BDADDR_LOCAL constants to strings. * Reformatted some of the Bluetooth code to be more consistent with PEP 7. I have only tested this patch under Linux, but I've tried to follow the changes introduced by patch #888148 so it should also work under FreeBSD. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-06-03 11:25 Message: Logged In: YES user_id=21627 Thanks for the patch. Applied as socketmodule.c 1.290. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=929192&group_id=5470 From noreply at sourceforge.net Thu Jun 3 08:08:04 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jun 3 08:08:10 2004 Subject: [Patches] [ python-Patches-774665 ] making Python LC_NUMERIC agnostic Message-ID: Patches item #774665, was opened at 2003-07-20 20:39 Message generated for change (Comment added) made by gustavo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=774665&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gustavo J. A. M. Carneiro (gustavo) Assigned to: Nobody/Anonymous (nobody) Summary: making Python LC_NUMERIC agnostic Initial Comment: This patch offers conversion string<->float conversion functions that are locale agnostic. This way, Python will be able to run perfectly even when LC_NUMERIC is set to something other than C. It happens frequently when using external modules that these modules change LC_NUMERIC without python knowing about it. It will never stop happening, unfortunately, so it is best to make python not depend on LC_NUMERIC being always set to 'C'. ---------------------------------------------------------------------- >Comment By: Gustavo J. A. M. Carneiro (gustavo) Date: 2004-06-03 13:08 Message: Logged In: YES user_id=908 Any chance this can get into Python 2.4? ---------------------------------------------------------------------- Comment By: Gustavo J. A. M. Carneiro (gustavo) Date: 2003-09-16 22:47 Message: Logged In: YES user_id=908 Used James Henstridge's cleaned up code, and cleaned it up a bit more. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-07-22 20:49 Message: Logged In: YES user_id=21627 I don't think the problem can be solved once and forall. In fact, I'm certain that the glib code is incorrect on some systems. For example, has it been tested on VMS, with its three different floatin point formats? I don't know whether linking with glib is a good idea. I'd happily accept a patch that supports glibc only, or one that tries for fall back to C++ std::locale on systems that support linking C++ code into C applications. Since the bug report was triggered through gtk problems, I expect that these can all be solved by linking with glib - using glib on a gtk installation should work fine. ---------------------------------------------------------------------- Comment By: Gustavo J. A. M. Carneiro (gustavo) Date: 2003-07-22 17:26 Message: Logged In: YES user_id=908 If neither glib nor glibc are available, are we still allowed to change LC_NUMERIC at will? I want to get rid of this problem once and for all. The next step is to change LC_NUMERIC to the correct locale value (or better, not change it to 'C'). Anyway, are you sure it's a good idea to link to glib? Is it a good idea to make the python interpreter depend on glib? Perhaps it is a bigger library than you think... ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-07-21 22:52 Message: Logged In: YES user_id=21627 On some systems, the desired behaviour just is not implementable. On such systems, we should not try to implement it by replacing the standard library. Instead, we should just give in and not implement the feature. People using such systems should convince their system vendors to provide the proper API, or find out whether proper API already exists. ---------------------------------------------------------------------- Comment By: Gustavo J. A. M. Carneiro (gustavo) Date: 2003-07-21 11:06 Message: Logged In: YES user_id=908 I have to incorporate glib code, otherwise what happens if glib is not installed? It is my intention that the current behaviour *never* be preserved. Well, that's not exactly an accurate statement. What I mean is that str() and float() should keep the current C-locale behaviour. However, underneath these python functions we could have LC_NUMERIC set something other than 'C'. This is vital for some modules, like GTK+, that depend on LC_NUMERIC to be set the locale dependent value, otherwise it behaves different from what the user expects. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-07-20 22:25 Message: Logged In: YES user_id=21627 I recommend that you do not incorporate the code of glib, but rather arrange to link with glib (perhaps only if activated by --with-glib). If no guaranteed-C-locale strtod is available, the current behaviour should be preserved. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=774665&group_id=5470 From noreply at sourceforge.net Thu Jun 3 14:13:32 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jun 3 14:13:42 2004 Subject: [Patches] [ python-Patches-959534 ] Arrange 64bits detection for ReliantUnix Message-ID: Patches item #959534, was opened at 2004-05-24 18:13 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=959534&group_id=5470 Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Jean-frederic Clere (jfclere) Assigned to: Nobody/Anonymous (nobody) Summary: Arrange 64bits detection for ReliantUnix Initial Comment: When compiling python on ReliantUnix (5.43) the compilation fails with unresolved externals like fstatvfs64, lseek64 etc Those routines belong to 5.45. The patch detects the missing lseek64() and suppress lfs support (use_lfs=no). ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-06-03 20:13 Message: Logged In: YES user_id=21627 Performing checks on all platforms is not a problem; the time that configure needs is not critical. If the test were run on all systems, would there be any negative functional effects? ---------------------------------------------------------------------- Comment By: Jean-frederic Clere (jfclere) Date: 2004-06-03 09:07 Message: Logged In: YES user_id=92497 Checking for Sinix is need because the SINIX unistd.h redefines lseek() into lseek64() when LFS is required (via _FILE_OFFSET_BITS and/or _LFS64_LARGEFILE). Checking for LFS via AC_TRY_LINK for most platforms means more tests. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-06-02 00:17 Message: Logged In: YES user_id=21627 Hmm. Why are you checking for Sinix at all? If the test fails, isn't it likely that LFS doesn't work on the platform? ---------------------------------------------------------------------- Comment By: Jean-frederic Clere (jfclere) Date: 2004-06-01 18:56 Message: Logged In: YES user_id=92497 Oops... That is better to check for SINIX-* before trying the link. I have more to submit because the dynamic linking needs additional libc. For example in setup.py +++ exts.append( Extension('_hotshot', ['_hotshot.c'], libraries=['c']) ) +++ ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-05-31 20:27 Message: Logged In: YES user_id=21627 Why do you check for SINIX after the link test fails? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=959534&group_id=5470 From noreply at sourceforge.net Thu Jun 3 14:17:10 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jun 3 14:17:19 2004 Subject: [Patches] [ python-Patches-774665 ] making Python LC_NUMERIC agnostic Message-ID: Patches item #774665, was opened at 2003-07-20 21:39 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=774665&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None >Priority: 7 Submitted By: Gustavo J. A. M. Carneiro (gustavo) >Assigned to: Martin v. L?wis (loewis) Summary: making Python LC_NUMERIC agnostic Initial Comment: This patch offers conversion string<->float conversion functions that are locale agnostic. This way, Python will be able to run perfectly even when LC_NUMERIC is set to something other than C. It happens frequently when using external modules that these modules change LC_NUMERIC without python knowing about it. It will never stop happening, unfortunately, so it is best to make python not depend on LC_NUMERIC being always set to 'C'. ---------------------------------------------------------------------- Comment By: Gustavo J. A. M. Carneiro (gustavo) Date: 2004-06-03 14:08 Message: Logged In: YES user_id=908 Any chance this can get into Python 2.4? ---------------------------------------------------------------------- Comment By: Gustavo J. A. M. Carneiro (gustavo) Date: 2003-09-16 23:47 Message: Logged In: YES user_id=908 Used James Henstridge's cleaned up code, and cleaned it up a bit more. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-07-22 21:49 Message: Logged In: YES user_id=21627 I don't think the problem can be solved once and forall. In fact, I'm certain that the glib code is incorrect on some systems. For example, has it been tested on VMS, with its three different floatin point formats? I don't know whether linking with glib is a good idea. I'd happily accept a patch that supports glibc only, or one that tries for fall back to C++ std::locale on systems that support linking C++ code into C applications. Since the bug report was triggered through gtk problems, I expect that these can all be solved by linking with glib - using glib on a gtk installation should work fine. ---------------------------------------------------------------------- Comment By: Gustavo J. A. M. Carneiro (gustavo) Date: 2003-07-22 18:26 Message: Logged In: YES user_id=908 If neither glib nor glibc are available, are we still allowed to change LC_NUMERIC at will? I want to get rid of this problem once and for all. The next step is to change LC_NUMERIC to the correct locale value (or better, not change it to 'C'). Anyway, are you sure it's a good idea to link to glib? Is it a good idea to make the python interpreter depend on glib? Perhaps it is a bigger library than you think... ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-07-21 23:52 Message: Logged In: YES user_id=21627 On some systems, the desired behaviour just is not implementable. On such systems, we should not try to implement it by replacing the standard library. Instead, we should just give in and not implement the feature. People using such systems should convince their system vendors to provide the proper API, or find out whether proper API already exists. ---------------------------------------------------------------------- Comment By: Gustavo J. A. M. Carneiro (gustavo) Date: 2003-07-21 12:06 Message: Logged In: YES user_id=908 I have to incorporate glib code, otherwise what happens if glib is not installed? It is my intention that the current behaviour *never* be preserved. Well, that's not exactly an accurate statement. What I mean is that str() and float() should keep the current C-locale behaviour. However, underneath these python functions we could have LC_NUMERIC set something other than 'C'. This is vital for some modules, like GTK+, that depend on LC_NUMERIC to be set the locale dependent value, otherwise it behaves different from what the user expects. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-07-20 23:25 Message: Logged In: YES user_id=21627 I recommend that you do not incorporate the code of glib, but rather arrange to link with glib (perhaps only if activated by --with-glib). If no guaranteed-C-locale strtod is available, the current behaviour should be preserved. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=774665&group_id=5470 From noreply at sourceforge.net Thu Jun 3 18:05:49 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jun 3 18:10:59 2004 Subject: [Patches] [ python-Patches-965192 ] improve markupbase.py error reporting Message-ID: Patches item #965192, was opened at 2004-06-02 19:20 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=965192&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: No Spam (not4spam) Assigned to: Nobody/Anonymous (nobody) Summary: improve markupbase.py error reporting Initial Comment: This is just a minor nit, but in "_scan_name" in "markupbase.py" if it cannot find a name token, it just reports "expected name token" without any identifying information. This can be easily improved by changing the line (379) from, self.error("expected name token") to, self.error("expected name token at '%s'" % rawdata[declstartpos:declstartpos+20]) which will show 20 characters of text where the error occured. Perhaps this can be changed in version 2.4? Thanks. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2004-06-03 23:05 Message: Logged In: YES user_id=261020 This is a duplicate of patch 965175 and should be closed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=965192&group_id=5470 From noreply at sourceforge.net Thu Jun 3 21:15:54 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jun 3 21:16:55 2004 Subject: [Patches] [ python-Patches-965192 ] improve markupbase.py error reporting Message-ID: Patches item #965192, was opened at 2004-06-02 14:20 Message generated for change (Settings changed) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=965192&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: No Spam (not4spam) Assigned to: Nobody/Anonymous (nobody) Summary: improve markupbase.py error reporting Initial Comment: This is just a minor nit, but in "_scan_name" in "markupbase.py" if it cannot find a name token, it just reports "expected name token" without any identifying information. This can be easily improved by changing the line (379) from, self.error("expected name token") to, self.error("expected name token at '%s'" % rawdata[declstartpos:declstartpos+20]) which will show 20 characters of text where the error occured. Perhaps this can be changed in version 2.4? Thanks. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2004-06-03 18:05 Message: Logged In: YES user_id=261020 This is a duplicate of patch 965175 and should be closed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=965192&group_id=5470 From Mollie at exalumnos.com Thu Jun 3 23:46:06 2004 From: Mollie at exalumnos.com (Kate Oakley) Date: Thu Jun 3 22:55:29 2004 Subject: [Patches] Se'xy and very yo.ung models! blob Message-ID: <86271201536.98583@Mollie@exalumnos.com> Hi dear l0Iitas site lover. We want present you 2nd issue of l0Iita magazine. Announcement! We are happy to announce that we finnaly have our second edition ready for you! This time you'll get plenty of surprises. As well as new sets and stories featuring our old girls, we also have lots of new charming l0Iitas ready to pose and to play with you. New live chats 100% avaible. 100% exclusive of photos. Successive days. Yes, time goes by and with every successive day we shoot more and more frank with their every new set. Don't waste your chance to see beauty in the very prime of life. Enjoy our new magazine here: http://www.atomicpulse.info/issue2/?mycenae From noreply at sourceforge.net Fri Jun 4 02:30:37 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jun 4 02:31:25 2004 Subject: [Patches] [ python-Patches-961387 ] Make IDLE's paragraph reformatting width configurable Message-ID: Patches item #961387, was opened at 2004-05-27 02:39 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=961387&group_id=5470 Category: IDLE Group: Python 2.4 >Status: Closed Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Kurt B. Kaiser (kbk) Summary: Make IDLE's paragraph reformatting width configurable Initial Comment: The current reformatting width is hardcoded at 70. This patch makes that option configurable. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-06-04 01:30 Message: Logged In: YES user_id=80475 Going ahead with the patch. Feel free to revert or adjust in any way you see fit. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=961387&group_id=5470 From noreply at sourceforge.net Fri Jun 4 08:58:32 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jun 4 08:58:35 2004 Subject: [Patches] [ python-Patches-966493 ] Cleanup generator/eval_frame exposure Message-ID: Patches item #966493, was opened at 2004-06-04 05:58 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=966493&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: James William Pye (jwpye) Assigned to: Nobody/Anonymous (nobody) Summary: Cleanup generator/eval_frame exposure Initial Comment: Hopefully get this cleanup in before 2.4.. . Include genobject.h in Python.h to save embedders an AC check to identify its existance(allowing a simple #ifndef Py_GENOBJECT_H) . Follow up my own recommendation to just reference eval_frame directly by exposing it(change references in ceval.c and genobject.c accordingly). . Update headers accordingly; reference frameobject in genobject.h and ceval.h as struct _frame * like others do to avoid including frameobject.h Rename PyEval_EvaluateFrame to PyEval_EvalFrame to be consistent with PyEval_EvalCode[Ex] in eval.h. Hopefully it isnt too late to change this before 2.4, sorry for not having it in the first patch.. :-( Changes files: genobject.c genobject.h ceval.c ceval.h Python.h ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=966493&group_id=5470 From noreply at sourceforge.net Fri Jun 4 09:15:40 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jun 4 09:15:51 2004 Subject: [Patches] [ python-Patches-774665 ] making Python LC_NUMERIC agnostic Message-ID: Patches item #774665, was opened at 2003-07-20 21:39 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=774665&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 7 Submitted By: Gustavo J. A. M. Carneiro (gustavo) Assigned to: Martin v. L?wis (loewis) Summary: making Python LC_NUMERIC agnostic Initial Comment: This patch offers conversion string<->float conversion functions that are locale agnostic. This way, Python will be able to run perfectly even when LC_NUMERIC is set to something other than C. It happens frequently when using external modules that these modules change LC_NUMERIC without python knowing about it. It will never stop happening, unfortunately, so it is best to make python not depend on LC_NUMERIC being always set to 'C'. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-06-04 15:15 Message: Logged In: YES user_id=21627 The patch breaks test_coercion, if run as python Lib/test/regrtest.py test__locale test_coercion This is because the behaviour of the %f formatter changes: >>> import locale >>> locale.setlocale(locale.LC_ALL,"de_DE") 'de_DE' >>> '%.1f' % 3.4 '3,4' ---------------------------------------------------------------------- Comment By: Gustavo J. A. M. Carneiro (gustavo) Date: 2004-06-03 14:08 Message: Logged In: YES user_id=908 Any chance this can get into Python 2.4? ---------------------------------------------------------------------- Comment By: Gustavo J. A. M. Carneiro (gustavo) Date: 2003-09-16 23:47 Message: Logged In: YES user_id=908 Used James Henstridge's cleaned up code, and cleaned it up a bit more. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-07-22 21:49 Message: Logged In: YES user_id=21627 I don't think the problem can be solved once and forall. In fact, I'm certain that the glib code is incorrect on some systems. For example, has it been tested on VMS, with its three different floatin point formats? I don't know whether linking with glib is a good idea. I'd happily accept a patch that supports glibc only, or one that tries for fall back to C++ std::locale on systems that support linking C++ code into C applications. Since the bug report was triggered through gtk problems, I expect that these can all be solved by linking with glib - using glib on a gtk installation should work fine. ---------------------------------------------------------------------- Comment By: Gustavo J. A. M. Carneiro (gustavo) Date: 2003-07-22 18:26 Message: Logged In: YES user_id=908 If neither glib nor glibc are available, are we still allowed to change LC_NUMERIC at will? I want to get rid of this problem once and for all. The next step is to change LC_NUMERIC to the correct locale value (or better, not change it to 'C'). Anyway, are you sure it's a good idea to link to glib? Is it a good idea to make the python interpreter depend on glib? Perhaps it is a bigger library than you think... ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-07-21 23:52 Message: Logged In: YES user_id=21627 On some systems, the desired behaviour just is not implementable. On such systems, we should not try to implement it by replacing the standard library. Instead, we should just give in and not implement the feature. People using such systems should convince their system vendors to provide the proper API, or find out whether proper API already exists. ---------------------------------------------------------------------- Comment By: Gustavo J. A. M. Carneiro (gustavo) Date: 2003-07-21 12:06 Message: Logged In: YES user_id=908 I have to incorporate glib code, otherwise what happens if glib is not installed? It is my intention that the current behaviour *never* be preserved. Well, that's not exactly an accurate statement. What I mean is that str() and float() should keep the current C-locale behaviour. However, underneath these python functions we could have LC_NUMERIC set something other than 'C'. This is vital for some modules, like GTK+, that depend on LC_NUMERIC to be set the locale dependent value, otherwise it behaves different from what the user expects. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-07-20 23:25 Message: Logged In: YES user_id=21627 I recommend that you do not incorporate the code of glib, but rather arrange to link with glib (perhaps only if activated by --with-glib). If no guaranteed-C-locale strtod is available, the current behaviour should be preserved. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=774665&group_id=5470 From rgosssj at tep.co.uk Fri Jun 4 09:29:31 2004 From: rgosssj at tep.co.uk (Rosalinda D. Goss) Date: Fri Jun 4 09:29:45 2004 Subject: [Patches] Powerful weightloss now available for you. Message-ID: <863601c44a37$b9aaea77$f6f778a4@ppa.sk> Hello, I have a special_offer for you... WANT TO LOSE WEIGHT? The most powerful weightloss is now available without prescription. All natural Adipren720 100% Money Back Guarant?e! - Lose up to 19% Total Body Weight. - Up to 300% more Weight Loss while dieting. - Loss of 20-35% abdominal Fat. - Reduction of 40-70% overall Fat under skin. - Increase metabolic rate by 76.9% without Exercise. - Boost your Confidence level and Self Esteem. - Burns calorized fat. - Suppresses appetite for sugar. Get the facts about all-natural Adipren720 ---- system information ---- meet Traditional text implement Distinguishing servers Localized There values reflection programming many your its wildly aspects Other function ja Scenario implies source note internationalized needs work defined belonging following It Transition Existing MIME important set back publications lang form lang From noreply at sourceforge.net Fri Jun 4 09:48:35 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jun 4 09:48:58 2004 Subject: [Patches] [ python-Patches-774665 ] making Python LC_NUMERIC agnostic Message-ID: Patches item #774665, was opened at 2003-07-20 20:39 Message generated for change (Comment added) made by gustavo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=774665&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 7 Submitted By: Gustavo J. A. M. Carneiro (gustavo) Assigned to: Martin v. L?wis (loewis) Summary: making Python LC_NUMERIC agnostic Initial Comment: This patch offers conversion string<->float conversion functions that are locale agnostic. This way, Python will be able to run perfectly even when LC_NUMERIC is set to something other than C. It happens frequently when using external modules that these modules change LC_NUMERIC without python knowing about it. It will never stop happening, unfortunately, so it is best to make python not depend on LC_NUMERIC being always set to 'C'. ---------------------------------------------------------------------- >Comment By: Gustavo J. A. M. Carneiro (gustavo) Date: 2004-06-04 14:48 Message: Logged In: YES user_id=908 test_coertion doesn't fail for me. But I believe you. I forgot to update formatfloat in Objects/stringobject.c. I'll work on this over the weekend... ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-06-04 14:15 Message: Logged In: YES user_id=21627 The patch breaks test_coercion, if run as python Lib/test/regrtest.py test__locale test_coercion This is because the behaviour of the %f formatter changes: >>> import locale >>> locale.setlocale(locale.LC_ALL,"de_DE") 'de_DE' >>> '%.1f' % 3.4 '3,4' ---------------------------------------------------------------------- Comment By: Gustavo J. A. M. Carneiro (gustavo) Date: 2004-06-03 13:08 Message: Logged In: YES user_id=908 Any chance this can get into Python 2.4? ---------------------------------------------------------------------- Comment By: Gustavo J. A. M. Carneiro (gustavo) Date: 2003-09-16 22:47 Message: Logged In: YES user_id=908 Used James Henstridge's cleaned up code, and cleaned it up a bit more. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-07-22 20:49 Message: Logged In: YES user_id=21627 I don't think the problem can be solved once and forall. In fact, I'm certain that the glib code is incorrect on some systems. For example, has it been tested on VMS, with its three different floatin point formats? I don't know whether linking with glib is a good idea. I'd happily accept a patch that supports glibc only, or one that tries for fall back to C++ std::locale on systems that support linking C++ code into C applications. Since the bug report was triggered through gtk problems, I expect that these can all be solved by linking with glib - using glib on a gtk installation should work fine. ---------------------------------------------------------------------- Comment By: Gustavo J. A. M. Carneiro (gustavo) Date: 2003-07-22 17:26 Message: Logged In: YES user_id=908 If neither glib nor glibc are available, are we still allowed to change LC_NUMERIC at will? I want to get rid of this problem once and for all. The next step is to change LC_NUMERIC to the correct locale value (or better, not change it to 'C'). Anyway, are you sure it's a good idea to link to glib? Is it a good idea to make the python interpreter depend on glib? Perhaps it is a bigger library than you think... ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-07-21 22:52 Message: Logged In: YES user_id=21627 On some systems, the desired behaviour just is not implementable. On such systems, we should not try to implement it by replacing the standard library. Instead, we should just give in and not implement the feature. People using such systems should convince their system vendors to provide the proper API, or find out whether proper API already exists. ---------------------------------------------------------------------- Comment By: Gustavo J. A. M. Carneiro (gustavo) Date: 2003-07-21 11:06 Message: Logged In: YES user_id=908 I have to incorporate glib code, otherwise what happens if glib is not installed? It is my intention that the current behaviour *never* be preserved. Well, that's not exactly an accurate statement. What I mean is that str() and float() should keep the current C-locale behaviour. However, underneath these python functions we could have LC_NUMERIC set something other than 'C'. This is vital for some modules, like GTK+, that depend on LC_NUMERIC to be set the locale dependent value, otherwise it behaves different from what the user expects. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-07-20 22:25 Message: Logged In: YES user_id=21627 I recommend that you do not incorporate the code of glib, but rather arrange to link with glib (perhaps only if activated by --with-glib). If no guaranteed-C-locale strtod is available, the current behaviour should be preserved. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=774665&group_id=5470 From noreply at sourceforge.net Fri Jun 4 09:56:27 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jun 4 09:56:31 2004 Subject: [Patches] [ python-Patches-926209 ] Patch to setup.py to run on x86_64 Linux Message-ID: Patches item #926209, was opened at 2004-03-30 21:46 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=926209&group_id=5470 Category: Build Group: Python 2.4 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Christopher Petrilli (petrilli) Assigned to: Martin v. L?wis (loewis) Summary: Patch to setup.py to run on x86_64 Linux Initial Comment: Bug ID#924333 Python doesn't auto-detect things correctly because of differing library locations on x86_64 Linux distributions (/usr/lib64). This patch just adds that to the setup.py file. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-06-04 15:56 Message: Logged In: YES user_id=21627 I have committed the part that adds lib64 as setup.py 1.188 NEWS 1.989 I'm uncertain what the other chunk meant; if it is still needed, please submit it as a *context* diff in a separate patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=926209&group_id=5470 From oubbtycgid at hotmail.com Fri Jun 4 11:17:27 2004 From: oubbtycgid at hotmail.com (Безпортошная Р .) Date: Fri Jun 4 10:18:33 2004 Subject: [Patches] re[15] Message-ID: <200406041418.i54EIPll099176@mxzilla7.xs4all.nl> An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20040604/d9058cda/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: everywhere.GIF Type: image/gif Size: 13853 bytes Desc: not available Url : http://mail.python.org/pipermail/patches/attachments/20040604/d9058cda/everywhere-0001.gif From v7ewze at ya.com Fri Jun 4 21:15:55 2004 From: v7ewze at ya.com (Sheree Gaines) Date: Sat Jun 5 02:18:05 2004 Subject: [Patches] instant degree entranceway Message-ID: An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20040605/bd2a7d0e/attachment.html From noreply at sourceforge.net Sat Jun 5 09:15:34 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jun 5 09:15:38 2004 Subject: [Patches] [ python-Patches-967057 ] Fix to minor spelling error in exception in int_subtype_new Message-ID: Patches item #967057, was opened at 2004-06-05 13:15 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=967057&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Aaron Brady (insomnike) Assigned to: Nobody/Anonymous (nobody) Summary: Fix to minor spelling error in exception in int_subtype_new Initial Comment: Fix to minor spelling error in exception in int_subtype_new() in intobject.c ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=967057&group_id=5470 From noreply at sourceforge.net Sat Jun 5 12:14:13 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jun 5 12:14:18 2004 Subject: [Patches] [ python-Patches-832058 ] deprecate or fix buffer object Message-ID: Patches item #832058, was opened at 2003-10-28 23:53 Message generated for change (Settings changed) made by nascheme You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=832058&group_id=5470 Category: Core (C code) Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Neil Schemenauer (nascheme) Assigned to: Nobody/Anonymous (nobody) Summary: deprecate or fix buffer object Initial Comment: This has not been well tested but I don't have time right now. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2003-11-05 23:26 Message: Logged In: YES user_id=35752 I've reviewed the code again and I'm more confident that it's correct. It would be good if someone else could review it before I check it in. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2003-11-02 03:43 Message: Logged In: YES user_id=35752 Attaching a patch that implements Greg Ewing's idea. Instead of storing the pointer and size to the buffer, the buffer interface is used each time they are needed. Again, not yet well tested. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=832058&group_id=5470 From noreply at sourceforge.net Sat Jun 5 13:54:20 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jun 5 13:54:30 2004 Subject: [Patches] [ python-Patches-909005 ] asyncore fixes and improvements Message-ID: Patches item #909005, was opened at 2004-03-03 08:07 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=909005&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alexey Klimkin (klimkin) Assigned to: A.M. Kuchling (akuchling) Summary: asyncore fixes and improvements Initial Comment: Minor: * 0/1 for boolean values replaced with False/True. * (887279) Added handling of POLLPRI as POLLIN. POLLERR, POLLHUP, POLLNVAL are handled as exception event. handle_expt_event gets recent error from self.socket object and raises socket.error. * Default readable()/writable() returns False. * Added "map" parameter for file_dispatcher. * file_wrapper: removed "return" in close(), recv/read and send/write swapped because of their nature. * mac code for writable() removed. Manual for accept() on mac is similar to the one on linux. * Repeating exception changed from "raise socket.error, why" to raise. * Added connected/accepting/addr reset on close(). Initialization of variables moved to __init__. * close_all() now calls close for dispatcher object, EBADF treated as already closed socket/file. * Added channel id to "unhandled..." messages. Bugs: * Fixed bug (654766,889153): client never gets connected, nor errored. Connecting client gets writable event from select(), however, some client may want always be non writable. Such client may never get connected. The fix adds _readable() - always True for accepting and always False for connecting socket; and _writable() - always False for accepting and always True for connecting socket. This implies, that listening dispatcher's readable() and writable() will never be called. ("man accept" and "man connect" for non-blocking sockets). * Fixed bug: error handling after accept(). It's said, that accept can return EWOULDBLOCK even for readable socket. This mean, that even after handle_accept(), dispatcher's accept() still raise EWOULDBLOCK. New code does accept() itself and stores accepted socket in self.__pending_accept. If there was socket.error, it's treated as EWOULDBLOCK. dispatcher's accept returns self.__pending_accept and resets it to None. Features: * Added pending_read() and pending_write(). The functions helps to use dispatcher over non socket objects with buffering capabilities. In original dispatcher, if socket makes buffered read and some data is in buffer, entering asyncore.poll() doesn't finishes, since there is no data in real file/socket. This feature allow to use SSL socket, since the socket reads data by 16k chunks. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2004-06-05 13:54 Message: Logged In: YES user_id=11375 I've struggled to get the test suite running without errors on my machine, but have failed. ---------------------------------------------------------------------- Comment By: Alexey Klimkin (klimkin) Date: 2004-03-22 01:15 Message: Logged In: YES user_id=410460 There is no real reason for this change, please undo. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2004-03-21 15:18 Message: Logged In: YES user_id=11375 In your version of file_dispatch.__init__, the .set_file() call is moved earlier; can you say why? ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2004-03-21 15:13 Message: Logged In: YES user_id=11375 Added "map" parameter for file_dispatcher and dispatcher_with_send in CVS HEAD. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2004-03-21 15:08 Message: Logged In: YES user_id=11375 Repeating exception changes ('raise socket.error' -> just 'raise') checked into HEAD. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2004-03-21 15:02 Message: Logged In: YES user_id=11375 Mac code for writable() removed from HEAD. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2004-03-21 15:02 Message: Logged In: YES user_id=11375 Patch to use True/False applied to HEAD. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2004-03-21 14:55 Message: Logged In: YES user_id=11375 Fix for bug #887279 applied to HEAD. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2004-03-21 14:48 Message: Logged In: YES user_id=11375 The many number of changes in this patch make it difficult to figure out which changes fix which problem. I've created a new directory in CVS, nondist/sandbox/asyncore, that contains copies of the module with these patches applied, and will work on applying changes to the copy in dist/src. ---------------------------------------------------------------------- Comment By: Alexey Klimkin (klimkin) Date: 2004-03-17 02:15 Message: Logged In: YES user_id=410460 Sorry, unfortunately I have lost old patch file. I have atached new one. In addition to fixes, listed above, the patch includes: 1. Fix for operating on uninitialized socket. self.socket now initializes with _closed_socket(), so any operation throws EBADF. 2. Added class idispatcher - base class for dispatcher. The purpose of this class is to allow simple replacement of media(dispatcher interface) in classes, derived from dispatcher class. This is based on 'object'. I have also attached asynchat.diff - example for new-style dispatcher. Old asynchat works as well. ---------------------------------------------------------------------- Comment By: Wummel (calvin) Date: 2004-03-11 10:49 Message: Logged In: YES user_id=9205 There is no file attached! You have to click on the checkbox next to the upload filename. This is a Sourceforge annoyance :( ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=909005&group_id=5470 From noreply at sourceforge.net Sat Jun 5 14:11:16 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jun 5 14:11:33 2004 Subject: [Patches] [ python-Patches-888839 ] cygwinccompiler should set C++ compiler Message-ID: Patches item #888839, was opened at 2004-02-02 12:29 Message generated for change (Settings changed) made by perky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=888839&group_id=5470 Category: Distutils and setup.py Group: None >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Seo Sanghyeon (sanxiyn) Assigned to: Nobody/Anonymous (nobody) Summary: cygwinccompiler should set C++ compiler Initial Comment: When C++ linking gotcha that have persisted in distutils was fixed in Python 2.3, I was glad. Unfortunately, it seems MinGW (I suspect same for Cygwin) was not fixed at the time. cygwinccompiler currently does not set compiler_cxx, so linking C++ just fails, even though all the machinery needed for linking C++ is there. Fix is simple, and I thank niemeyer and people involved for fixing #413582. ---------------------------------------------------------------------- Comment By: Seo Sanghyeon (sanxiyn) Date: 2004-04-03 15:01 Message: Logged In: YES user_id=837148 This is a duplicate of #877165. ---------------------------------------------------------------------- Comment By: Seo Sanghyeon (sanxiyn) Date: 2004-02-02 13:33 Message: Logged In: YES user_id=837148 Oops, Cygwin should have -mcywgin, not -mno-cygwin, of course. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=888839&group_id=5470 From noreply at sourceforge.net Sat Jun 5 16:36:48 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jun 5 16:36:52 2004 Subject: [Patches] [ python-Patches-921793 ] Rewrite of site.py Message-ID: Patches item #921793, was opened at 2004-03-23 07:05 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=921793&group_id=5470 Category: Library (Lib) Group: Python 2.4 >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Brett Cannon (bcannon) Assigned to: Nobody/Anonymous (nobody) Summary: Rewrite of site.py Initial Comment: Brought to you by the PyCon core sprint, I rewrote Lib/site.py to clean it up and modernize it. The biggest change is putting all the code into appropriate functions and defining a main() function that gets executed at import. Cleans up the code and allows others to run the functions after import in case they want the functionality. Also modernized it by using sets and universal newlines. A new test suite is also being included in this tracker item. You can partially run it against the original site.py, but some tests will fail since they call new functions. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2004-06-05 13:36 Message: Logged In: YES user_id=357491 Got impatient. =) Checked in both the changes to site.py and the addition of test_site.py (SF is not responding to ``cvs log`` to get the version numbers for the check-in). ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-06-02 21:57 Message: Logged In: YES user_id=357491 Thanks to Raymond, I have worked out a single bug in my code (left out an import that only shows up under Windows) and fixed some bad tests. Unless someone finds some bugs in this in a week or so I will check this in. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-05-31 16:39 Message: Logged In: YES user_id=357491 Re-generated the diff for site.py; turned out it didn't apply cleanly. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-03-23 09:44 Message: Logged In: YES user_id=357491 OK, now the test passes. Problem test was not matching what the code did by creating a normalized, absolute path of what was in sys.path . ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-03-23 09:37 Message: Logged In: YES user_id=357491 Just discovered one of the regression tests fails if you run all the tests with regrtest.py. Trying to fix now since it is a bug in the test. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=921793&group_id=5470 From noreply at sourceforge.net Sat Jun 5 16:46:46 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jun 5 16:50:21 2004 Subject: [Patches] [ python-Patches-965175 ] improve markupbase.py error reporting Message-ID: Patches item #965175, was opened at 2004-06-02 12:59 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=965175&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: No Spam (not4spam) >Assigned to: A.M. Kuchling (akuchling) Summary: improve markupbase.py error reporting Initial Comment: This is just a minor nit, but in "_scan_name" in "markupbase.py" if it cannot find a name token, it just reports "expected name token" without any identifying information. This can be easily improved by changing the line (379) from, self.error("expected name token") to, self.error("expected name token at '%s'" % rawdata[declstartpos:declstartpos+20]) which will show 20 characters of text where the error occured. Perhaps this can be changed in version 2.4? Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=965175&group_id=5470 From noreply at sourceforge.net Sat Jun 5 17:11:15 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jun 5 17:11:20 2004 Subject: [Patches] [ python-Patches-967057 ] Fix to minor spelling error in exception in int_subtype_new Message-ID: Patches item #967057, was opened at 2004-06-05 09:15 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=967057&group_id=5470 Category: Core (C code) Group: Python 2.4 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Aaron Brady (insomnike) >Assigned to: A.M. Kuchling (akuchling) Summary: Fix to minor spelling error in exception in int_subtype_new Initial Comment: Fix to minor spelling error in exception in int_subtype_new() in intobject.c ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2004-06-05 17:11 Message: Logged In: YES user_id=11375 Fix applied (actually I reworded the message a bit); thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=967057&group_id=5470 From ladonna_grossqa at poggenpohl.de Sat Jun 5 23:31:52 2004 From: ladonna_grossqa at poggenpohl.de (Ladonna Gross) Date: Sat Jun 5 17:39:55 2004 Subject: [Patches] =?iso-8859-1?q?Buy_V=EDagra_and_many_other_medicines_h?= =?iso-8859-1?q?ere=2E?= Message-ID: An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20040606/f9dcc3bd/attachment.html From noreply at sourceforge.net Sat Jun 5 19:10:54 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jun 5 19:11:02 2004 Subject: [Patches] [ python-Patches-876130 ] add C API to datetime module Message-ID: Patches item #876130, was opened at 2004-01-13 10:20 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=876130&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Anthony Tuininga (atuining) Assigned to: Tim Peters (tim_one) Summary: add C API to datetime module Initial Comment: The datetime module does not have a C API which means that modules written in C cannot take advantage of the datetime module without incurring significant overhead. These patches supply this lack and are based on the C API exported by the mxDateTime module and the cStringIO module and enhanced as suggested by Guido. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2004-06-05 19:10 Message: Logged In: YES user_id=31435 Heh. Just noticed there are 6 patches attached to this report. Are all of them part of the suggested change, or, if not, which are the current ones (if that's the case, the best way to answer the question is to delete the out-of-date patches)? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-06-01 13:53 Message: Logged In: YES user_id=31435 I intend to do it this week, but have no time today or tomorrow. ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-06-01 13:44 Message: Logged In: YES user_id=619560 Sure. What's the chance of it being reviewed prior to the release of Python 2.4 a1? I just saw the preannouncement today -- it is scheduled for the end of this month, I believe. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-05-31 23:12 Message: Logged In: YES user_id=31435 Assigned to me for the next review. Can't do it immediately, but will do my best to free up some time for it "soon". ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-05-26 15:39 Message: Logged In: YES user_id=619560 I would agree with your assessment of the issue regarding the TimeFromTicks() API and find it quite reasonable. Either implement both at the C and Python levels or not at all. Since there is no consensus on this, none it is. :-) Did you have a chance to review the actual code? The changes are fairly minimal but you might have questions about readability, names, etc. It would be great if this could be included in an upcoming 2.4 alpha/beta so that I can provide support in cx_Oracle for the next release. Thanks for your time. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-05-26 15:32 Message: Logged In: YES user_id=31435 Under the belief that the *intent* of this patch is to add a C API to Python's datetime module, it should stick to exposing C ways to spell what Python programmers can already do from Python using datetime. Since nothing like TimeFromTicks() exists in the Python datetime API, it simply doesn't make sense to invent one available only from C. It *may* make sense to invent one in a DB API wrapper around datetime, but I view that as out of scope for this patch. I would not add TimeFromTicks() to the Python datetime API either, because the docs are ambiguous. The sample implementation Marc-Andre posted here uses localtime() to resolve the ambiguity in the docs, but that has to be a wrong choice for some time-of-day apps. For example, there's apparently no portable way to spell "noon" using TimeFromTicks(): the value you get back depends on which time zone localtime() happens to use at the time it's called. If people want time-of-day from a POSIX timestamp, it remains easy to get it from what datetime already supplies, but to do so you have to be explicit about whether you want UTC or local time interpretation. Both are easily spelled already, and it's a Good Thing that you need to be explicit if you want to do such a thing. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-05-26 15:25 Message: Logged In: YES user_id=38388 Tim, please review. Thanks. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-05-26 15:22 Message: Logged In: YES user_id=38388 Thanks, but I don't have time to review it. As for the TimeFromTicks() API: I can understand that you don't feel like implementing it, but hey, I won't use datetime either. The only reason I'm trying to push full support of the DB API specs is that Guido et al. wanted to see a note in the DB API that datetime also provides a usable interface to do date/time interfacing. I'm not very interested in datetime myself, since I'll continue to use mxDateTime, so the situation for me is somewhat similar to yours: investing time into something that I myself will probably not use much (I will add support to mxODBC for those who like to use datetime instead of mxDateTime, but won't use it myself). Feel free to check in your changes. Thanks. ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-05-26 12:30 Message: Logged In: YES user_id=619560 Attached are the modified patches based on your suggestions. I have tested them with my own module cx_Oracle and they appear to work correctly. Any further suggestions would be appreciated. I would like to see this included for Python 2.4 if at all possible. Please let me know what I need to do (if anything) to get this to happen. As for the TimeFromTicks() routine, Oracle has absolutely no use for a "time-only" data type and does not support it. It clearly does not have broad support so I really have no desire to implement it since I will never use it myself. If you consider it important, you could add it yourself or we could wait until someone else who requires it for their implementation of the DB API requires it. I'm not trying to be rude or trying to denigrate the DB API, simply trying to be practical. Please let me know if this is offensive in any way. Thanks. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-05-19 04:28 Message: Logged In: YES user_id=38388 >From the DB API specs: TimeFromTicks(ticks) This function constructs an object holding a time value from the given ticks value (number of seconds since the epoch; see the documentation of the standard Python time module for details). The reason for this having this API is to be able to construct an object suitable for passing to the database given a Unix ticks value. Since the ticks value contains both a date and a time part and most databases have a special column type for time value, we need two constructor APIs, one to extract just the date part and one for the time part. Here's the mxDateTime implementation for reference: def TimeFromTicks(ticks, # Locals: DateTimeDelta=DateTimeDelta,localtime=_time.localtime): """ TimeFromTicks(ticks) Constructs a DateTimeDelta instance pointing to the local time indicated by the given ticks value. The date part is ignored. """ return apply(DateTimeDelta, (0,) + localtime(ticks)[3:6]) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-05-03 13:46 Message: Logged In: YES user_id=31435 I don't understand what TimeFromTicks() is supposed to do. Seconds-from-the-epoch is a point in time, not a time-of- day. If some DB API requires guessing some transformation from seconds-from-the-epoch to time-of-day, that's fine, but it doesn't belong in Python's datetime module. The datetime module should certainly have a method to construct a datetime.datetime from a seconds-from-the- epoch argument -- seconds-from-the-epoch is a way of specifying a datetime.datetime. Given that, if the intent is to throw away the datetime.date portion of the datetime.datetime object, retaining only the datetime.time portion, then that's trivially accomplished by invoking dt.time () (where dt is the datetime.datetime object). Do any databases really store time-of-day as a seconds-from- the-epoch value? Google's top hit on TimeFromTicks() today happens to be a msg from Anthony saying that Oracle does not. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-05-03 13:24 Message: Logged In: YES user_id=38388 Macro: I don't know whether you need the macro or not (you probably do for the type checks). In any case, you can do without relying on Python providing you this information via the build process, since only datetimemodule.c is using the header file while Python is being built. TimeFromTicks(): I' ve stated my point. I don't think there's anything to add - I'm tired of fighting for these things... one of the reasons I stopped actively discussing things on python-dev. IMHO, a product that's aimed at developers should make things easy for the developer and try to avoid code duplication if possible. The API is needed in order to support database interfaces that use Unix ticks as basis for date/time, so if you don't add it to the module, the ten or twenty module authors out there will have to duplicate that piece of work in their implementation. Transition: This was already discussed on the db-api list. We love freedom of choice. Nothing to add. ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-05-03 12:48 Message: Logged In: YES user_id=619560 About the Py_BUILD_CORE issue: You are suggesting that I define this in datetimemodule.c just prior to the include of datetime.h? Or are you suggesting some other macro? I am not sure about the comment about "not needing a macro in the first place" since there are two groups that will be importing datetime.h: the first being the datetime module itself and the second being the DB API modules. The macro is definitely required to distinguish between the two -- unless I am missing something? On the TimeFromTicks() issue: You obviously consider it important that the three methods be available at the C level for DB API module authors to use directly. My objection is simply a reiteration of an objection raised by Tim Peters. I think you'll have to argue that one with him. :-) I'll provide my implementations for cx_Oracle as part of the patches and then you can fight it out and I'll stay out of it. :-) As for the transition period, I assumed that with the introduction of a standard datetime module, that it would become the suggested implementation for database interfaace modules. That said, I don't really have any authority to say anything on this front so I'll leave that to you and others to decide. :-) ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-05-03 11:26 Message: Logged In: YES user_id=38388 About the Py_BUILD_CORE issue: Sorry, I didn't know that Python does not define this macro for core modules. Nevertheless, looking at the datetime module code I don't really understand why you would need such a macro in the first place. Since the datetime module is the only code including the datetime.h header file it should be easy to add a macro definition just before importing datetime.h. On the TimeFromTicks() issue: The whole point of this discussion is to make the datetime module easily usable for authors of database modules. Since the DB API specifies that the module will need to export the three functions, two of which are available through the datetime module already, I don't really see your point in not wanting to add it. BTW, you are wrong in the assumption that the DB API spec will move away from a generic API for date/time objects. The DB API has always been defined in terms of interfaces and does not force a certain set of tools onto the developer. The datetime module will become one possible choice for DB API authors, others will want to stick to mxDateTime, use strings, ticks integers or more specific objects for interfacing. That won't change, so there is no "transition period". ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-05-03 10:40 Message: Logged In: YES user_id=619560 I spent some time getting the two include files merged together, only to discover that Py_BUILD_CORE is __NOT__ defined when building modules, only when building stuff linked directly into the core interpreter. Perhaps this ought to be defined when building the modules with setup.py? At any rate, I cannot proceed along the route suggested without this problem being resolved. On the DateFromTicks(), TimestampFromTicks(), TimeFromTicks() issue, I'm not sure that there is much benefit to including a C API for this since if the datetime module becomes the standard method for managing datetime objects, there is no point in having the DB API modules provide something that the datetime module already provides, right? During the transition period the few lines of code needed can be posted. If you disagree I can certainly provide the few lines as part of the patch but I suspect you will find resistance to having this included by Tim Peters, the maintainer (I believe) of the datetime module. Feel free to correct me... :-) ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-04-26 12:19 Message: Logged In: YES user_id=38388 Sorry for not getting back to you earlier: I didn't see you last message. 1-4) Python defines a macro during the Python build process that is not defined when compiling extensions: Py_BUILD_CORE You can use that macro to compile things differently for core things vs. extensions. 5) Fair enough; I don't see a point in creating a new numbering for each and every module. Please just use 1, 2, 3, 4, ... 6) Hope this makes sense :-) ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-04-26 11:35 Message: Logged In: YES user_id=619560 Any chance to look at this? Any hope of this being included in Python 2.4? I know a number of people (including Guido) who would appreciate that.... :-) ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-04-05 18:04 Message: Logged In: YES user_id=619560 I am back at work after finishing my move so I think I can finally devote a little more time to this issue. 1-4) The main reason for datetimeapi.h as opposed to simply modifying datetime.h was that the internal build needs to define things __differently__ from an external build of a module and there doesn't appear to be any way of fixing that -- so if you know a way I think I can manage to create a reasonable patch; otherwise, I'm out of my depth! 5) Guido was suggesting that a new PyIMPORT macro be made available which would verify that the magic number defined in the header file actually matches the magic number exported by the built module; this is simply a developer protection scheme which should eliminate really stupid uses; you can ask him about this or I can e-mail you part of the thread that brought this up 6) Makes sense. I'd like to get the questions above resolved first before proceeding any further, though. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-03-25 13:23 Message: Logged In: YES user_id=38388 Thanks for the comments... 1) Please put *all* the code for the C API into datetimeapi.h. I don't like your current mix of putting some things into datetime.h and others into datetimeapi.h (e.g. the PyDateTime_CAPI definition). 2) Since it's the only API missing if you want to use datetime objects in database interfacing, please add it. 3) dito. 4) Yes, the header file is the right place. Have a look at unicodeobject.h for what I have in mind (or mxDateTime.h for that matter). 5) Why add yet another magic number ? Isn't the Python API number enough ? 6) Since you don't provide a doc patch, please put comments into the header file. There can never be enough documentation and developers tend to look at the code rather than the docs ;-) ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-03-25 13:08 Message: Logged In: YES user_id=619560 Sorry for the delay. Things here have been quite busy recently both at work and at home. Let me see if I can answer your questions. 1) are you suggesting comments that include the macro names in datetimeapi.h similar to what I put in the comments below? Or something else? See modified datetimeapi.h for more info. 2) TimeFromTicks() is a very DB API specific routine. In chatting with others about the datetime module, they were not keen on adding such a beast. I guess there will have to be some discussion about whether datetimeapi.h is also a sort of half implementation for a C module implementing the DB API. I was intending to do this in my cx_Oracle module but not in datetimeapi.h. Could you clarify? 3) I could add C APIS for the three DB API ticks interfaces but I was simply intending to do that in cx_Oracle. Again, see #2. I can do it either way. :-) 4) I have added limited documentation in datetimeapi.h but is that really the right place for it? Is it even remotely close to what is needed? I'm not sure what is needed here exactly. 5) the API magic number is simply an arbitrary number which is stored in datetime.h and need not be understood by the implementor. For your information I simply took the name "datetime", converted each letter to its ordinal value in the alphabet, modded by 16 and used that hex character -- does that make any sense? This can be changed to whatever makes sense, though. 6) Whether or not datetimeapi.h should be sufficient for a developer or whether he should look at documentation in the usual locations (html pages, for example) I'll leave up to the Python development team. Let me know how I can assist. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-03-25 12:35 Message: Logged In: YES user_id=38388 Anthony, have you had a chance to look at the comments ? ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-02-26 10:06 Message: Logged In: YES user_id=619560 Oops! It looks like my own misunderstanding of SourceForge and how it works is to blame. :-( I'll take a look at this and get back to you as soon as possible -- ignore my previous comment. ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-02-26 10:03 Message: Logged In: YES user_id=619560 You haven't yet responded to my previous comments -- it looks like SourceForge put them __after__ your comments so it is quite understandable why you didn't notice them. If you can give me the answers to those questions or provide additional questions that I need to answer, then I think we can make progress again. I was waiting for __you__ :-) ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-02-25 18:08 Message: Logged In: YES user_id=38388 Any progress on this ? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-01-28 06:49 Message: Logged In: YES user_id=38388 Thanks for the clarification. I had forgotten about the macros -- I'd suggest that you document them in the datetimeapi.h include file to not cause the same confusion on the developer side (the trick to achieve adoption is to make things easy on the developer). As for TimeFromTicks(): This should be rather straight forward to implement: you take the time part of the ticks timestamp and create a time object from it. This is the way the DB API constructor works. Could you add C APIs for the three DB API ticks interface methods ? Other things that are missing: * documentation of the way the CAPI object can be used in datetimeapi.h * documentation of the various CAPI entries * documentation of the API magic number (there should be some scheme for this) I think that datetimeapi.h should be enough for a developer to read in order to use the interface. ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-01-26 16:02 Message: Logged In: YES user_id=619560 I didn't think any additional API would be necessary for extracting date time information since the following macros are available: PyDateTime_GET_YEAR(o) PyDateTime_GET_MONTH(o) PyDateTime_GET_DAY(o) PyDateTime_DATE_GET_HOUR(o) PyDateTime_DATE_GET_MINUTE(o) PyDateTime_DATE_GET_SECOND(o) PyDateTime_DATE_GET_MICROSECOND(o) PyDateTime_TIME_GET_HOUR(o) PyDateTime_TIME_GET_MINUTE(o) PyDateTime_TIME_GET_SECOND(o) PyDateTime_TIME_GET_MICROSECOND(o) Were you thinking of something else that is needed? As for interfacing at the C level for converting from Unix ticks, the following method is already available and could simply be used as a drop in replacement for DateFromTicks() and TimestampFromTicks() from the DB API document. DateFromTicks() --> datetime.date.fromtimestamp() TimestampFromTicks() --> datetime.datetime.fromtimestamp() TimeFromTicks() is not already exposed but discussions with Tim Peters already suggested that would not happen since the concept is rather strange. You'll have to discuss that with him if you disagree! :-) Any comments? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-01-26 15:46 Message: Logged In: YES user_id=38388 This is a good start. However, you should add more APIs for extracting date/time information to the C API. mxDateTime.h from egenix-mx-base can provide a good basis for this. If you want to make the datetime module usable for database interfacing at C level, you'll also have to add interfaces for Unix ticks conversion, since these are often used by database C level interfaces. ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-01-26 13:36 Message: Logged In: YES user_id=619560 I have no objection to providing patches for doc and test. A quick look at _testcapimodule.c doesn't provide any obvious ideas as to how to patch it. I looked for cStringIO which has a C API already and found nothing in there at all. The documentation also simply says "see the source for the information you require". Any suggestions as to how to proceed? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-01-25 22:17 Message: Logged In: YES user_id=31435 Marc-Andre, can you review this? I think you have more experience building C APIs for modules than anyone else (while I don't have any). There's certainly no objection to giving datetime a C API, and Guido already said he doesn't want to rely on that Martin changed datetime to be built as part of the core (in 2.3 on Windows, datetime.pyd was a distinct DLL; in CVS, datetime is compiled into the core DLL now). Anthony, you probably need to add doc and test patches. _testcapimodule.c holds tests of things you can only get at from C. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=876130&group_id=5470 From noreply at sourceforge.net Sat Jun 5 19:43:19 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jun 5 19:43:26 2004 Subject: [Patches] [ python-Patches-876130 ] add C API to datetime module Message-ID: Patches item #876130, was opened at 2004-01-13 10:20 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=876130&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Anthony Tuininga (atuining) Assigned to: Tim Peters (tim_one) Summary: add C API to datetime module Initial Comment: The datetime module does not have a C API which means that modules written in C cannot take advantage of the datetime module without incurring significant overhead. These patches supply this lack and are based on the C API exported by the mxDateTime module and the cStringIO module and enhanced as suggested by Guido. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2004-06-05 19:43 Message: Logged In: YES user_id=31435 Assuming the current state of the proposal consists of the first two patches on the list ("patch for datetimemodule.c" and "patch for datetime.h"), I'm probably happy to commit them. Can't say for sure right now, because SF CVS is dead, and can't get a current checkout to try them with. The one necessary thing I don't see are docs: how are users supposed to know this exists, let alone know how to use it? We need a new section for datetime objects in the Python/C API Reference Manual, in the Other Objects part of the Concrete Objects Layer section. You don't have to write LaTeX, plain text is fine. Look at the other sections in that chapter for what's needed (an overview, and a precise account of what's in the new C API and how to use it). Don't let that discourage you -- you're very close! If I don't force docs out of you now, docs will never get written. That's why I'm trying to force docs out of you now . ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-06-05 19:10 Message: Logged In: YES user_id=31435 Heh. Just noticed there are 6 patches attached to this report. Are all of them part of the suggested change, or, if not, which are the current ones (if that's the case, the best way to answer the question is to delete the out-of-date patches)? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-06-01 13:53 Message: Logged In: YES user_id=31435 I intend to do it this week, but have no time today or tomorrow. ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-06-01 13:44 Message: Logged In: YES user_id=619560 Sure. What's the chance of it being reviewed prior to the release of Python 2.4 a1? I just saw the preannouncement today -- it is scheduled for the end of this month, I believe. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-05-31 23:12 Message: Logged In: YES user_id=31435 Assigned to me for the next review. Can't do it immediately, but will do my best to free up some time for it "soon". ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-05-26 15:39 Message: Logged In: YES user_id=619560 I would agree with your assessment of the issue regarding the TimeFromTicks() API and find it quite reasonable. Either implement both at the C and Python levels or not at all. Since there is no consensus on this, none it is. :-) Did you have a chance to review the actual code? The changes are fairly minimal but you might have questions about readability, names, etc. It would be great if this could be included in an upcoming 2.4 alpha/beta so that I can provide support in cx_Oracle for the next release. Thanks for your time. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-05-26 15:32 Message: Logged In: YES user_id=31435 Under the belief that the *intent* of this patch is to add a C API to Python's datetime module, it should stick to exposing C ways to spell what Python programmers can already do from Python using datetime. Since nothing like TimeFromTicks() exists in the Python datetime API, it simply doesn't make sense to invent one available only from C. It *may* make sense to invent one in a DB API wrapper around datetime, but I view that as out of scope for this patch. I would not add TimeFromTicks() to the Python datetime API either, because the docs are ambiguous. The sample implementation Marc-Andre posted here uses localtime() to resolve the ambiguity in the docs, but that has to be a wrong choice for some time-of-day apps. For example, there's apparently no portable way to spell "noon" using TimeFromTicks(): the value you get back depends on which time zone localtime() happens to use at the time it's called. If people want time-of-day from a POSIX timestamp, it remains easy to get it from what datetime already supplies, but to do so you have to be explicit about whether you want UTC or local time interpretation. Both are easily spelled already, and it's a Good Thing that you need to be explicit if you want to do such a thing. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-05-26 15:25 Message: Logged In: YES user_id=38388 Tim, please review. Thanks. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-05-26 15:22 Message: Logged In: YES user_id=38388 Thanks, but I don't have time to review it. As for the TimeFromTicks() API: I can understand that you don't feel like implementing it, but hey, I won't use datetime either. The only reason I'm trying to push full support of the DB API specs is that Guido et al. wanted to see a note in the DB API that datetime also provides a usable interface to do date/time interfacing. I'm not very interested in datetime myself, since I'll continue to use mxDateTime, so the situation for me is somewhat similar to yours: investing time into something that I myself will probably not use much (I will add support to mxODBC for those who like to use datetime instead of mxDateTime, but won't use it myself). Feel free to check in your changes. Thanks. ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-05-26 12:30 Message: Logged In: YES user_id=619560 Attached are the modified patches based on your suggestions. I have tested them with my own module cx_Oracle and they appear to work correctly. Any further suggestions would be appreciated. I would like to see this included for Python 2.4 if at all possible. Please let me know what I need to do (if anything) to get this to happen. As for the TimeFromTicks() routine, Oracle has absolutely no use for a "time-only" data type and does not support it. It clearly does not have broad support so I really have no desire to implement it since I will never use it myself. If you consider it important, you could add it yourself or we could wait until someone else who requires it for their implementation of the DB API requires it. I'm not trying to be rude or trying to denigrate the DB API, simply trying to be practical. Please let me know if this is offensive in any way. Thanks. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-05-19 04:28 Message: Logged In: YES user_id=38388 >From the DB API specs: TimeFromTicks(ticks) This function constructs an object holding a time value from the given ticks value (number of seconds since the epoch; see the documentation of the standard Python time module for details). The reason for this having this API is to be able to construct an object suitable for passing to the database given a Unix ticks value. Since the ticks value contains both a date and a time part and most databases have a special column type for time value, we need two constructor APIs, one to extract just the date part and one for the time part. Here's the mxDateTime implementation for reference: def TimeFromTicks(ticks, # Locals: DateTimeDelta=DateTimeDelta,localtime=_time.localtime): """ TimeFromTicks(ticks) Constructs a DateTimeDelta instance pointing to the local time indicated by the given ticks value. The date part is ignored. """ return apply(DateTimeDelta, (0,) + localtime(ticks)[3:6]) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-05-03 13:46 Message: Logged In: YES user_id=31435 I don't understand what TimeFromTicks() is supposed to do. Seconds-from-the-epoch is a point in time, not a time-of- day. If some DB API requires guessing some transformation from seconds-from-the-epoch to time-of-day, that's fine, but it doesn't belong in Python's datetime module. The datetime module should certainly have a method to construct a datetime.datetime from a seconds-from-the- epoch argument -- seconds-from-the-epoch is a way of specifying a datetime.datetime. Given that, if the intent is to throw away the datetime.date portion of the datetime.datetime object, retaining only the datetime.time portion, then that's trivially accomplished by invoking dt.time () (where dt is the datetime.datetime object). Do any databases really store time-of-day as a seconds-from- the-epoch value? Google's top hit on TimeFromTicks() today happens to be a msg from Anthony saying that Oracle does not. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-05-03 13:24 Message: Logged In: YES user_id=38388 Macro: I don't know whether you need the macro or not (you probably do for the type checks). In any case, you can do without relying on Python providing you this information via the build process, since only datetimemodule.c is using the header file while Python is being built. TimeFromTicks(): I' ve stated my point. I don't think there's anything to add - I'm tired of fighting for these things... one of the reasons I stopped actively discussing things on python-dev. IMHO, a product that's aimed at developers should make things easy for the developer and try to avoid code duplication if possible. The API is needed in order to support database interfaces that use Unix ticks as basis for date/time, so if you don't add it to the module, the ten or twenty module authors out there will have to duplicate that piece of work in their implementation. Transition: This was already discussed on the db-api list. We love freedom of choice. Nothing to add. ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-05-03 12:48 Message: Logged In: YES user_id=619560 About the Py_BUILD_CORE issue: You are suggesting that I define this in datetimemodule.c just prior to the include of datetime.h? Or are you suggesting some other macro? I am not sure about the comment about "not needing a macro in the first place" since there are two groups that will be importing datetime.h: the first being the datetime module itself and the second being the DB API modules. The macro is definitely required to distinguish between the two -- unless I am missing something? On the TimeFromTicks() issue: You obviously consider it important that the three methods be available at the C level for DB API module authors to use directly. My objection is simply a reiteration of an objection raised by Tim Peters. I think you'll have to argue that one with him. :-) I'll provide my implementations for cx_Oracle as part of the patches and then you can fight it out and I'll stay out of it. :-) As for the transition period, I assumed that with the introduction of a standard datetime module, that it would become the suggested implementation for database interfaace modules. That said, I don't really have any authority to say anything on this front so I'll leave that to you and others to decide. :-) ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-05-03 11:26 Message: Logged In: YES user_id=38388 About the Py_BUILD_CORE issue: Sorry, I didn't know that Python does not define this macro for core modules. Nevertheless, looking at the datetime module code I don't really understand why you would need such a macro in the first place. Since the datetime module is the only code including the datetime.h header file it should be easy to add a macro definition just before importing datetime.h. On the TimeFromTicks() issue: The whole point of this discussion is to make the datetime module easily usable for authors of database modules. Since the DB API specifies that the module will need to export the three functions, two of which are available through the datetime module already, I don't really see your point in not wanting to add it. BTW, you are wrong in the assumption that the DB API spec will move away from a generic API for date/time objects. The DB API has always been defined in terms of interfaces and does not force a certain set of tools onto the developer. The datetime module will become one possible choice for DB API authors, others will want to stick to mxDateTime, use strings, ticks integers or more specific objects for interfacing. That won't change, so there is no "transition period". ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-05-03 10:40 Message: Logged In: YES user_id=619560 I spent some time getting the two include files merged together, only to discover that Py_BUILD_CORE is __NOT__ defined when building modules, only when building stuff linked directly into the core interpreter. Perhaps this ought to be defined when building the modules with setup.py? At any rate, I cannot proceed along the route suggested without this problem being resolved. On the DateFromTicks(), TimestampFromTicks(), TimeFromTicks() issue, I'm not sure that there is much benefit to including a C API for this since if the datetime module becomes the standard method for managing datetime objects, there is no point in having the DB API modules provide something that the datetime module already provides, right? During the transition period the few lines of code needed can be posted. If you disagree I can certainly provide the few lines as part of the patch but I suspect you will find resistance to having this included by Tim Peters, the maintainer (I believe) of the datetime module. Feel free to correct me... :-) ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-04-26 12:19 Message: Logged In: YES user_id=38388 Sorry for not getting back to you earlier: I didn't see you last message. 1-4) Python defines a macro during the Python build process that is not defined when compiling extensions: Py_BUILD_CORE You can use that macro to compile things differently for core things vs. extensions. 5) Fair enough; I don't see a point in creating a new numbering for each and every module. Please just use 1, 2, 3, 4, ... 6) Hope this makes sense :-) ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-04-26 11:35 Message: Logged In: YES user_id=619560 Any chance to look at this? Any hope of this being included in Python 2.4? I know a number of people (including Guido) who would appreciate that.... :-) ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-04-05 18:04 Message: Logged In: YES user_id=619560 I am back at work after finishing my move so I think I can finally devote a little more time to this issue. 1-4) The main reason for datetimeapi.h as opposed to simply modifying datetime.h was that the internal build needs to define things __differently__ from an external build of a module and there doesn't appear to be any way of fixing that -- so if you know a way I think I can manage to create a reasonable patch; otherwise, I'm out of my depth! 5) Guido was suggesting that a new PyIMPORT macro be made available which would verify that the magic number defined in the header file actually matches the magic number exported by the built module; this is simply a developer protection scheme which should eliminate really stupid uses; you can ask him about this or I can e-mail you part of the thread that brought this up 6) Makes sense. I'd like to get the questions above resolved first before proceeding any further, though. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-03-25 13:23 Message: Logged In: YES user_id=38388 Thanks for the comments... 1) Please put *all* the code for the C API into datetimeapi.h. I don't like your current mix of putting some things into datetime.h and others into datetimeapi.h (e.g. the PyDateTime_CAPI definition). 2) Since it's the only API missing if you want to use datetime objects in database interfacing, please add it. 3) dito. 4) Yes, the header file is the right place. Have a look at unicodeobject.h for what I have in mind (or mxDateTime.h for that matter). 5) Why add yet another magic number ? Isn't the Python API number enough ? 6) Since you don't provide a doc patch, please put comments into the header file. There can never be enough documentation and developers tend to look at the code rather than the docs ;-) ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-03-25 13:08 Message: Logged In: YES user_id=619560 Sorry for the delay. Things here have been quite busy recently both at work and at home. Let me see if I can answer your questions. 1) are you suggesting comments that include the macro names in datetimeapi.h similar to what I put in the comments below? Or something else? See modified datetimeapi.h for more info. 2) TimeFromTicks() is a very DB API specific routine. In chatting with others about the datetime module, they were not keen on adding such a beast. I guess there will have to be some discussion about whether datetimeapi.h is also a sort of half implementation for a C module implementing the DB API. I was intending to do this in my cx_Oracle module but not in datetimeapi.h. Could you clarify? 3) I could add C APIS for the three DB API ticks interfaces but I was simply intending to do that in cx_Oracle. Again, see #2. I can do it either way. :-) 4) I have added limited documentation in datetimeapi.h but is that really the right place for it? Is it even remotely close to what is needed? I'm not sure what is needed here exactly. 5) the API magic number is simply an arbitrary number which is stored in datetime.h and need not be understood by the implementor. For your information I simply took the name "datetime", converted each letter to its ordinal value in the alphabet, modded by 16 and used that hex character -- does that make any sense? This can be changed to whatever makes sense, though. 6) Whether or not datetimeapi.h should be sufficient for a developer or whether he should look at documentation in the usual locations (html pages, for example) I'll leave up to the Python development team. Let me know how I can assist. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-03-25 12:35 Message: Logged In: YES user_id=38388 Anthony, have you had a chance to look at the comments ? ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-02-26 10:06 Message: Logged In: YES user_id=619560 Oops! It looks like my own misunderstanding of SourceForge and how it works is to blame. :-( I'll take a look at this and get back to you as soon as possible -- ignore my previous comment. ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-02-26 10:03 Message: Logged In: YES user_id=619560 You haven't yet responded to my previous comments -- it looks like SourceForge put them __after__ your comments so it is quite understandable why you didn't notice them. If you can give me the answers to those questions or provide additional questions that I need to answer, then I think we can make progress again. I was waiting for __you__ :-) ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-02-25 18:08 Message: Logged In: YES user_id=38388 Any progress on this ? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-01-28 06:49 Message: Logged In: YES user_id=38388 Thanks for the clarification. I had forgotten about the macros -- I'd suggest that you document them in the datetimeapi.h include file to not cause the same confusion on the developer side (the trick to achieve adoption is to make things easy on the developer). As for TimeFromTicks(): This should be rather straight forward to implement: you take the time part of the ticks timestamp and create a time object from it. This is the way the DB API constructor works. Could you add C APIs for the three DB API ticks interface methods ? Other things that are missing: * documentation of the way the CAPI object can be used in datetimeapi.h * documentation of the various CAPI entries * documentation of the API magic number (there should be some scheme for this) I think that datetimeapi.h should be enough for a developer to read in order to use the interface. ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-01-26 16:02 Message: Logged In: YES user_id=619560 I didn't think any additional API would be necessary for extracting date time information since the following macros are available: PyDateTime_GET_YEAR(o) PyDateTime_GET_MONTH(o) PyDateTime_GET_DAY(o) PyDateTime_DATE_GET_HOUR(o) PyDateTime_DATE_GET_MINUTE(o) PyDateTime_DATE_GET_SECOND(o) PyDateTime_DATE_GET_MICROSECOND(o) PyDateTime_TIME_GET_HOUR(o) PyDateTime_TIME_GET_MINUTE(o) PyDateTime_TIME_GET_SECOND(o) PyDateTime_TIME_GET_MICROSECOND(o) Were you thinking of something else that is needed? As for interfacing at the C level for converting from Unix ticks, the following method is already available and could simply be used as a drop in replacement for DateFromTicks() and TimestampFromTicks() from the DB API document. DateFromTicks() --> datetime.date.fromtimestamp() TimestampFromTicks() --> datetime.datetime.fromtimestamp() TimeFromTicks() is not already exposed but discussions with Tim Peters already suggested that would not happen since the concept is rather strange. You'll have to discuss that with him if you disagree! :-) Any comments? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-01-26 15:46 Message: Logged In: YES user_id=38388 This is a good start. However, you should add more APIs for extracting date/time information to the C API. mxDateTime.h from egenix-mx-base can provide a good basis for this. If you want to make the datetime module usable for database interfacing at C level, you'll also have to add interfaces for Unix ticks conversion, since these are often used by database C level interfaces. ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-01-26 13:36 Message: Logged In: YES user_id=619560 I have no objection to providing patches for doc and test. A quick look at _testcapimodule.c doesn't provide any obvious ideas as to how to patch it. I looked for cStringIO which has a C API already and found nothing in there at all. The documentation also simply says "see the source for the information you require". Any suggestions as to how to proceed? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-01-25 22:17 Message: Logged In: YES user_id=31435 Marc-Andre, can you review this? I think you have more experience building C APIs for modules than anyone else (while I don't have any). There's certainly no objection to giving datetime a C API, and Guido already said he doesn't want to rely on that Martin changed datetime to be built as part of the core (in 2.3 on Windows, datetime.pyd was a distinct DLL; in CVS, datetime is compiled into the core DLL now). Anthony, you probably need to add doc and test patches. _testcapimodule.c holds tests of things you can only get at from C. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=876130&group_id=5470 From noreply at sourceforge.net Sat Jun 5 21:33:48 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jun 5 21:33:53 2004 Subject: [Patches] [ python-Patches-936169 ] CodeContext - an extension to show you where you are Message-ID: Patches item #936169, was opened at 2004-04-16 03:40 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=936169&group_id=5470 Category: IDLE Group: None >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Noam Raphael (noamr) Assigned to: Kurt B. Kaiser (kbk) Summary: CodeContext - an extension to show you where you are Initial Comment: Have you ever edited a code, and did not know exactly which block you were closing? Or didn't know exactly even in which block you were? This extension solves this problem, by adding a few lines (3 by default) above the IDLE edit box, which show you exactly where you are in your code. For example, you may be editing a code with three indentation levels (has three tabs on its left), but to find the reason for this - to find what is the meaning of your block - you have to scroll upwards a long distance. CodeContext will add three lines of text above your edit box, so your editing window will look like this: ---------------------------------- Class MyClass: def myMethod(self, arg1, arg2): <- auto-updated if something_happens: ---------------------------------- i += 1 print "hello" <- You edit here ... ---------------------------------- So you can know that i is incremented by 1, in the method myMethod of class MyClass, and only if something_happens. To make this extension work, you have to put the attached file, CodeContext.py, in your IDLE directory, and add these lines to config-extensions.def: ---------------------------------- [CodeContext] enable=1 numlines=3 bgcolor=LightGray fgcolor=Black ---------------------------------- A note to KBK: I think this extension can go into the Python distribution. If you don't like it, or if you want a testing period, you can put "enable=0" instead of "enable=1". In this way, most users will not even know CodeContext exists, but "power users" will be able to put "enable=1" and have CodeContext if they like it (- I like it). Best wishes, Noam Raphael ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2004-06-05 20:33 Message: Logged In: YES user_id=149084 Checked in Noam Raphael's improvements. CodeContext.py 1.4 et. al. ---------------------------------------------------------------------- Comment By: Noam Raphael (noamr) Date: 2004-04-27 16:24 Message: Logged In: YES user_id=679426 Hello, I think that showing / not showing the Code Context panel should be a persistent setting - if the user wants it, it will appear, and if he doesn't, it won't. The concept of "it has an initial state, and you can change it afterwards if you like" is confusing. Using a persistent setting makes a keyboard shortcut unnecessary - I think that usually the user will be happy with what he likes, and won't hide/show the panel many times. So I made the <> event save the new setting in the user's configuration file. The new setting will be applied also to new windows opened in the same session. This required me to add a SetOption method to configHandler.IdleConf. Also, the initialization of the CodeContext instance required the menu item to be already installed, but EditorWindow.load_extension installs the menu items after it initializes the extension's instance. It turns out that the menu items can be installed before the instance initialization, so I changed it. Another problem was that the Code Context menu item was installed on shell windows, but wasn't functioning, which was quite confusing. So I added new optional configurations for extensions: enable_shell and enable_editor, which allow you to write extensions only for the editor/shell window, without using the "isinstance(editwin, PyShell)" trick. About using a Text widget instead of a Label - it may work, I don't know, but making the Label behave as I wanted was hard enough, and it looks fine to me as it is, so I leave it for now. Bye Bye, Noam ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2004-04-26 17:28 Message: Logged In: YES user_id=149084 Yeah, I noticed that problem and wasn't sure if I had caused it. Thanks, fixed. CodeContext.py 1.3. Sorry I took so long getting back, for some reason I'm not getting mail from SF when a Tracker item changes (though I don't have a problem sending mail to myself via users.sourceforge.net). I added an entry for Code Context on the Options menu, it toggles the context pane. Any suggestion for a keybinding? A remaining problem is the text in the Label doesn't quite line up with the text in the main pane. Adding a pad of one space makes it almost perfect. But maybe using a Text widget instead of a Label would fix it 100%? ---------------------------------------------------------------------- Comment By: Noam Raphael (noamr) Date: 2004-04-22 15:11 Message: Logged In: YES user_id=679426 I'm glad you like it! Thanks for the changes - your English is certainly better than mine. A buglet you made - in line 91 you added "elif" as a block opener which should show the previous block opener of the same indentation, which is a good idea, but you wrote: if opener == "else" or "elif": which is an expression which always yields True. It caused all block openers to be displayed, not only the relevant ones. Change it to if opener in ("else", "elif"): and it will work fine. Happy Israel Independence Day! (I know you probably don't celebrate it, but it is on 27 April this year) Noam ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2004-04-21 15:09 Message: Logged In: YES user_id=149084 Cool Extension! Thanks! CodeContext.py 1.1 config-extensions.def 1.13 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=936169&group_id=5470 From fraupier at tiscalinet.it Sun Jun 6 03:38:33 2004 From: fraupier at tiscalinet.it (Scallion M. Defectors) Date: Sun Jun 6 03:38:39 2004 Subject: [Patches] Read:_Best offer of this year ;) Message-ID: <0361292759.20040606023833@tiscalinet.it> >Madge Michelle Casey Miguel Emilia Jack Karl Gustavo Sensation!! We opened a NEW site with unbeatable prices and products. 800 WORLD BEST software with 90% discount - that is a really BEST offer just imagine, you can buy ALL software that you ever need and pay price of just one of it! Office 2003 for 50$ - nice deal right ? ;) retail price is 700$ - great savings, huh? Please spend few moments of yours precious time to check our offer - it is more than worth it! http://Ulysses.cheap-oem-license.biz/?Jackson >Give me the liberty to know, to utter, and to argue freely according to conscience, above all liberties. >If past history was all there was to the game, the richest people would be librarians. >The best way will be to avoid each other without appearing to do so -- or if we jostle, at any rate not to bite. >The roots of education are bitter, but the fruit is sweet. >Most books today seemed to have been written overnight from books read the day before. >He who lives without discipline dies without honor. >You can accomplish by kindness what you cannot by force. >We may give advice, but not the sense to use it. >The future is purchased by the present. >Nature, when she invented, manufactured, and patented her authors, contrived to make critics out of the chips that were left. >Life is neither good or evil, but only a place for good and evil. >We only part to meet again. >If you could only love enough, you could be the most powerful person in the world. >The dead might as well try to speak to the living as the old to the young. >Has this world been so kind to you that you should leave with regret? There are better things ahead than any we leave behind. >Government is the only institution that can take a valuable commodity like paper, and make it worthless by applying ink. >Honesty is the best policy. If I lose mine honor, I lose myself. >No man ever did a designed injury to another, but at the same time he did a greater to himself. >Life is too short to learn German. From noreply at sourceforge.net Sun Jun 6 07:18:48 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jun 6 07:18:54 2004 Subject: [Patches] [ python-Patches-839496 ] SimpleHTTPServer reports wrong content-length for text files Message-ID: Patches item #839496, was opened at 2003-11-10 21:42 Message generated for change (Comment added) made by irmen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=839496&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Irmen de Jong (irmen) Assigned to: Nobody/Anonymous (nobody) Summary: SimpleHTTPServer reports wrong content-length for text files Initial Comment: (Python 2.3.2 on Windows) SimpleHTTPServer reports the size of the file on disk as Content-Length. This works except for text files. If the content type starts with "text/" it is opening the file in 'text' mode rather than 'binary' mode. At least on Windows this causes newline translations, thereby making the actual size of the content transmitted *less* than the content-length! I don't know why SimpleHTTPServer is reading text files with text mode. The included patch removes this distinction so all files are opened in binary mode (and, also on windows, the actual size transmitted is the same as the reported content-length). --Irmen de Jong ---------------------------------------------------------------------- >Comment By: Irmen de Jong (irmen) Date: 2004-06-06 13:18 Message: Logged In: YES user_id=129426 The attached httptest.zip contains a test scenario. When run on windows, it will show the problem. First start 'startserver.py' and then from the same directory run test.py. I get this: [E:\temp\httptest]python test.py The reported content-length is: 1047 bytes The real filesize is: 1047 bytes The data I actually received from the httpserver is: 1028 bytes ---------------------------------------------------------------------- Comment By: Irmen de Jong (irmen) Date: 2004-05-31 18:51 Message: Logged In: YES user_id=129426 The attached trivial patch removes the special case for text files. ---------------------------------------------------------------------- Comment By: Irmen de Jong (irmen) Date: 2004-05-13 13:21 Message: Logged In: YES user_id=129426 This bug is also still present in the SimpleHTTPServer.py from Python 2.3.3 (and in the current CVS version, too). Is there a reason why it treats text files differently? If so, then at least the reported content-length must be fixed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=839496&group_id=5470 From EBrownie22 at aol.com Sun Jun 6 07:49:27 2004 From: EBrownie22 at aol.com (EBrownie22@aol.com) Date: Sun Jun 6 07:49:33 2004 Subject: [Patches] Se'xy and very yo.ung models! blob Message-ID: <26.49ada77e.2df45ec7@aol.com> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20040606/7f878e2f/attachment.html From noreply at sourceforge.net Sun Jun 6 13:43:03 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jun 6 13:43:12 2004 Subject: [Patches] [ python-Patches-778323 ] Tk Dialog Upon Subprocess Socket Error Message-ID: Patches item #778323, was opened at 2003-07-26 23:13 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=778323&group_id=5470 Category: IDLE Group: Python 2.3 >Status: Closed Resolution: Fixed Priority: 6 Submitted By: Kurt B. Kaiser (kbk) Assigned to: Kurt B. Kaiser (kbk) Summary: Tk Dialog Upon Subprocess Socket Error Initial Comment: Alex Martelli identified a problem on a particular machine which was unable to start IDLE's subprocess if not connected to the Internet. The user was not receiving any error message. This patch raises a Tk error box and also adds a timeout to the listening socket so that a stuck process is not left behind. See discussion on Python-dev 26July03. ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2004-06-06 12:43 Message: Logged In: YES user_id=149084 Backported to release23-maint for 2.3.5 ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2004-01-21 14:28 Message: Logged In: YES user_id=149084 checked in an enhanced version of sockerr.patch. cf. http://mail.python.org/pipermail/python-checkins/2004-January/039597. html for details. PyShell 1.84 ScriptBinding 1.26 run 1.28 BACKPORT CANDIDATE ---------------------------------------------------------------------- Comment By: Aahz (aahz) Date: 2003-07-28 13:13 Message: Logged In: YES user_id=175591 bugs.ht updated ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-07-27 10:55 Message: Logged In: YES user_id=12800 Postponing until 2.3.1. Too much code change before 2.3 final. Assigning to Aahz so he can add appropriate text to pydotorg's 2.3/bugs.ht file. We'll call this a known bug in 2.3 to be fixed in 2.3.1. Also, lowering the priority. Aahz, once you've made the change to bugs.ht, please re-assign to Kurt. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=778323&group_id=5470 From noreply at sourceforge.net Sun Jun 6 16:51:04 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jun 6 16:51:08 2004 Subject: [Patches] [ python-Patches-967763 ] fix bsddb memory leaks Message-ID: Patches item #967763, was opened at 2004-06-06 16:51 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=967763&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: fix bsddb memory leaks Initial Comment: only one of the changes fixed a leak reported by valgrind, but i think all the changes are necessary. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=967763&group_id=5470 From noreply at sourceforge.net Sun Jun 6 17:35:30 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jun 6 17:35:36 2004 Subject: [Patches] [ python-Patches-885905 ] _socket fails to build with latest SGI compiler Message-ID: Patches item #885905, was opened at 2004-01-27 19:35 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=885905&group_id=5470 Category: Build Group: None >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Greg Couch (gregcouch) Assigned to: Nobody/Anonymous (nobody) Summary: _socket fails to build with latest SGI compiler Initial Comment: The Python 2.3 mechanism of defining _POSIX_C_SOURCE et. al. prevents configure from finding everything. It kind of worked for the SGI 7.3 compilers, but always fails for the 7.4 compilers. With the patch the gross ifdef in socketmodule.c that defines _SGIAPI is not used and likewise for various other ifdef __sgi's. Since they are not used anymore, I didn't remove them in this patch. Attached is a patch to configure.in that eliminates the various _SOURCE defines on IRIX and works with both the 7.3.1.2m and 7.4.1m compilers. The same patch can be applied to configure for those who don't have autoconf working on their system. - Greg ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2004-06-06 17:35 Message: Logged In: YES user_id=33168 socketmodule.c problems on IRIX should have been fixed when patch 728330 was committed. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-01-28 18:20 Message: Logged In: YES user_id=21627 This patch is inappropriate. Can you please explain why defining _POSIX_C_SOURCE prevents configure from finding everything? If you are certain that IRIX is so broken that you cannot compile conforming POSIX programs, please use the facility define_xopen_source to disable POSIX. Make sure you list your name and a specific problem; "cannot compile socketmodule" would not be specific, but "struct foo is defined twice, once in bar.h and once in foobar.h" would be specific. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=885905&group_id=5470 From elliot.tuckeroo at kbs.co.kr Mon Jun 7 06:24:39 2004 From: elliot.tuckeroo at kbs.co.kr (Elliot Tucker) Date: Sun Jun 6 18:28:59 2004 Subject: [Patches] Powerful weightloss now available for you. Message-ID: <826201c44c79$ae584eed$370aed66@online.unaerp.br> Hello, I have a special_offer for you... WANT TO LOSE WEIGHT? The most powerful weightloss is now available without prescription. All natural Adipren720 100% Money Back Guarant?e! - Lose up to 19% Total Body Weight. - Up to 300% more Weight Loss while dieting. - Loss of 20-35% abdominal Fat. - Reduction of 40-70% overall Fat under skin. - Increase metabolic rate by 76.9% without Exercise. - Boost your Confidence level and Self Esteem. - Burns calorized fat. - Suppresses appetite for sugar. Get the facts about all-natural Adipren720 ---- system information ---- field Status information) resources Internet fall can another logic environments actually servers which Sender represents places individual Tax grammar identification current produced negotiation places use danger case have subscribe zones sends parties incomplete one fallback Localized clients zone Web examples From iopojlldbsyjc at graffiti.net Mon Jun 7 02:35:50 2004 From: iopojlldbsyjc at graffiti.net (Terry Key) Date: Mon Jun 7 01:25:12 2004 Subject: [Patches] NEW! Great deals on all your favorite software from Dejesus's SoftShop Message-ID: An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20040607/f49bc7a0/attachment-0001.html From 107450.0060 at compuserve.com Mon Jun 7 04:49:19 2004 From: 107450.0060 at compuserve.com (John) Date: Mon Jun 7 03:53:24 2004 Subject: [Patches] OEM software (up to 80% discount) [not spam] Message-ID: An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20040607/a6e90d6f/attachment.html From noreply at sourceforge.net Mon Jun 7 05:45:17 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jun 7 05:45:55 2004 Subject: [Patches] [ python-Patches-968063 ] Add fileinput.islastline() Message-ID: Patches item #968063, was opened at 2004-06-07 02:45 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=968063&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Relm Arrowny (relm) Assigned to: Nobody/Anonymous (nobody) Summary: Add fileinput.islastline() Initial Comment: You can test for the first line of a file with fileinput.isfirstline(), but there is no corresponding fileinput.islastline() to test for the last line of a file. Note that there is already an unapplied patch for this at request ID 776100, but it is faulty in that it only tests for end of buffer and not end of file. I was not sure how to append this patch to the existing request, so have started a new one. Hope this is okay. This patch also includes documentation and test updates. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=968063&group_id=5470 From noreply at sourceforge.net Mon Jun 7 09:57:39 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jun 7 09:57:47 2004 Subject: [Patches] [ python-Patches-876130 ] add C API to datetime module Message-ID: Patches item #876130, was opened at 2004-01-13 08:20 Message generated for change (Comment added) made by atuining You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=876130&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Anthony Tuininga (atuining) Assigned to: Tim Peters (tim_one) Summary: add C API to datetime module Initial Comment: The datetime module does not have a C API which means that modules written in C cannot take advantage of the datetime module without incurring significant overhead. These patches supply this lack and are based on the C API exported by the mxDateTime module and the cStringIO module and enhanced as suggested by Guido. ---------------------------------------------------------------------- >Comment By: Anthony Tuininga (atuining) Date: 2004-06-07 07:57 Message: Logged In: YES user_id=619560 Yes, the top two files are the ones involved. As per your suggestion I deleted the other four files to avoid further confusion. I understand the concern for documentation. I'll see what I can do to get at least a preliminary patch on that front ready this week. Earlier discussions suggested that the documentation reside solely in the include file but I think adding a section to the Python/C API documentation would make a lot more sense. Please stand by. :-) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-06-05 17:43 Message: Logged In: YES user_id=31435 Assuming the current state of the proposal consists of the first two patches on the list ("patch for datetimemodule.c" and "patch for datetime.h"), I'm probably happy to commit them. Can't say for sure right now, because SF CVS is dead, and can't get a current checkout to try them with. The one necessary thing I don't see are docs: how are users supposed to know this exists, let alone know how to use it? We need a new section for datetime objects in the Python/C API Reference Manual, in the Other Objects part of the Concrete Objects Layer section. You don't have to write LaTeX, plain text is fine. Look at the other sections in that chapter for what's needed (an overview, and a precise account of what's in the new C API and how to use it). Don't let that discourage you -- you're very close! If I don't force docs out of you now, docs will never get written. That's why I'm trying to force docs out of you now . ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-06-05 17:10 Message: Logged In: YES user_id=31435 Heh. Just noticed there are 6 patches attached to this report. Are all of them part of the suggested change, or, if not, which are the current ones (if that's the case, the best way to answer the question is to delete the out-of-date patches)? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-06-01 11:53 Message: Logged In: YES user_id=31435 I intend to do it this week, but have no time today or tomorrow. ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-06-01 11:44 Message: Logged In: YES user_id=619560 Sure. What's the chance of it being reviewed prior to the release of Python 2.4 a1? I just saw the preannouncement today -- it is scheduled for the end of this month, I believe. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-05-31 21:12 Message: Logged In: YES user_id=31435 Assigned to me for the next review. Can't do it immediately, but will do my best to free up some time for it "soon". ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-05-26 13:39 Message: Logged In: YES user_id=619560 I would agree with your assessment of the issue regarding the TimeFromTicks() API and find it quite reasonable. Either implement both at the C and Python levels or not at all. Since there is no consensus on this, none it is. :-) Did you have a chance to review the actual code? The changes are fairly minimal but you might have questions about readability, names, etc. It would be great if this could be included in an upcoming 2.4 alpha/beta so that I can provide support in cx_Oracle for the next release. Thanks for your time. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-05-26 13:32 Message: Logged In: YES user_id=31435 Under the belief that the *intent* of this patch is to add a C API to Python's datetime module, it should stick to exposing C ways to spell what Python programmers can already do from Python using datetime. Since nothing like TimeFromTicks() exists in the Python datetime API, it simply doesn't make sense to invent one available only from C. It *may* make sense to invent one in a DB API wrapper around datetime, but I view that as out of scope for this patch. I would not add TimeFromTicks() to the Python datetime API either, because the docs are ambiguous. The sample implementation Marc-Andre posted here uses localtime() to resolve the ambiguity in the docs, but that has to be a wrong choice for some time-of-day apps. For example, there's apparently no portable way to spell "noon" using TimeFromTicks(): the value you get back depends on which time zone localtime() happens to use at the time it's called. If people want time-of-day from a POSIX timestamp, it remains easy to get it from what datetime already supplies, but to do so you have to be explicit about whether you want UTC or local time interpretation. Both are easily spelled already, and it's a Good Thing that you need to be explicit if you want to do such a thing. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-05-26 13:25 Message: Logged In: YES user_id=38388 Tim, please review. Thanks. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-05-26 13:22 Message: Logged In: YES user_id=38388 Thanks, but I don't have time to review it. As for the TimeFromTicks() API: I can understand that you don't feel like implementing it, but hey, I won't use datetime either. The only reason I'm trying to push full support of the DB API specs is that Guido et al. wanted to see a note in the DB API that datetime also provides a usable interface to do date/time interfacing. I'm not very interested in datetime myself, since I'll continue to use mxDateTime, so the situation for me is somewhat similar to yours: investing time into something that I myself will probably not use much (I will add support to mxODBC for those who like to use datetime instead of mxDateTime, but won't use it myself). Feel free to check in your changes. Thanks. ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-05-26 10:30 Message: Logged In: YES user_id=619560 Attached are the modified patches based on your suggestions. I have tested them with my own module cx_Oracle and they appear to work correctly. Any further suggestions would be appreciated. I would like to see this included for Python 2.4 if at all possible. Please let me know what I need to do (if anything) to get this to happen. As for the TimeFromTicks() routine, Oracle has absolutely no use for a "time-only" data type and does not support it. It clearly does not have broad support so I really have no desire to implement it since I will never use it myself. If you consider it important, you could add it yourself or we could wait until someone else who requires it for their implementation of the DB API requires it. I'm not trying to be rude or trying to denigrate the DB API, simply trying to be practical. Please let me know if this is offensive in any way. Thanks. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-05-19 02:28 Message: Logged In: YES user_id=38388 >From the DB API specs: TimeFromTicks(ticks) This function constructs an object holding a time value from the given ticks value (number of seconds since the epoch; see the documentation of the standard Python time module for details). The reason for this having this API is to be able to construct an object suitable for passing to the database given a Unix ticks value. Since the ticks value contains both a date and a time part and most databases have a special column type for time value, we need two constructor APIs, one to extract just the date part and one for the time part. Here's the mxDateTime implementation for reference: def TimeFromTicks(ticks, # Locals: DateTimeDelta=DateTimeDelta,localtime=_time.localtime): """ TimeFromTicks(ticks) Constructs a DateTimeDelta instance pointing to the local time indicated by the given ticks value. The date part is ignored. """ return apply(DateTimeDelta, (0,) + localtime(ticks)[3:6]) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-05-03 11:46 Message: Logged In: YES user_id=31435 I don't understand what TimeFromTicks() is supposed to do. Seconds-from-the-epoch is a point in time, not a time-of- day. If some DB API requires guessing some transformation from seconds-from-the-epoch to time-of-day, that's fine, but it doesn't belong in Python's datetime module. The datetime module should certainly have a method to construct a datetime.datetime from a seconds-from-the- epoch argument -- seconds-from-the-epoch is a way of specifying a datetime.datetime. Given that, if the intent is to throw away the datetime.date portion of the datetime.datetime object, retaining only the datetime.time portion, then that's trivially accomplished by invoking dt.time () (where dt is the datetime.datetime object). Do any databases really store time-of-day as a seconds-from- the-epoch value? Google's top hit on TimeFromTicks() today happens to be a msg from Anthony saying that Oracle does not. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-05-03 11:24 Message: Logged In: YES user_id=38388 Macro: I don't know whether you need the macro or not (you probably do for the type checks). In any case, you can do without relying on Python providing you this information via the build process, since only datetimemodule.c is using the header file while Python is being built. TimeFromTicks(): I' ve stated my point. I don't think there's anything to add - I'm tired of fighting for these things... one of the reasons I stopped actively discussing things on python-dev. IMHO, a product that's aimed at developers should make things easy for the developer and try to avoid code duplication if possible. The API is needed in order to support database interfaces that use Unix ticks as basis for date/time, so if you don't add it to the module, the ten or twenty module authors out there will have to duplicate that piece of work in their implementation. Transition: This was already discussed on the db-api list. We love freedom of choice. Nothing to add. ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-05-03 10:48 Message: Logged In: YES user_id=619560 About the Py_BUILD_CORE issue: You are suggesting that I define this in datetimemodule.c just prior to the include of datetime.h? Or are you suggesting some other macro? I am not sure about the comment about "not needing a macro in the first place" since there are two groups that will be importing datetime.h: the first being the datetime module itself and the second being the DB API modules. The macro is definitely required to distinguish between the two -- unless I am missing something? On the TimeFromTicks() issue: You obviously consider it important that the three methods be available at the C level for DB API module authors to use directly. My objection is simply a reiteration of an objection raised by Tim Peters. I think you'll have to argue that one with him. :-) I'll provide my implementations for cx_Oracle as part of the patches and then you can fight it out and I'll stay out of it. :-) As for the transition period, I assumed that with the introduction of a standard datetime module, that it would become the suggested implementation for database interfaace modules. That said, I don't really have any authority to say anything on this front so I'll leave that to you and others to decide. :-) ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-05-03 09:26 Message: Logged In: YES user_id=38388 About the Py_BUILD_CORE issue: Sorry, I didn't know that Python does not define this macro for core modules. Nevertheless, looking at the datetime module code I don't really understand why you would need such a macro in the first place. Since the datetime module is the only code including the datetime.h header file it should be easy to add a macro definition just before importing datetime.h. On the TimeFromTicks() issue: The whole point of this discussion is to make the datetime module easily usable for authors of database modules. Since the DB API specifies that the module will need to export the three functions, two of which are available through the datetime module already, I don't really see your point in not wanting to add it. BTW, you are wrong in the assumption that the DB API spec will move away from a generic API for date/time objects. The DB API has always been defined in terms of interfaces and does not force a certain set of tools onto the developer. The datetime module will become one possible choice for DB API authors, others will want to stick to mxDateTime, use strings, ticks integers or more specific objects for interfacing. That won't change, so there is no "transition period". ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-05-03 08:40 Message: Logged In: YES user_id=619560 I spent some time getting the two include files merged together, only to discover that Py_BUILD_CORE is __NOT__ defined when building modules, only when building stuff linked directly into the core interpreter. Perhaps this ought to be defined when building the modules with setup.py? At any rate, I cannot proceed along the route suggested without this problem being resolved. On the DateFromTicks(), TimestampFromTicks(), TimeFromTicks() issue, I'm not sure that there is much benefit to including a C API for this since if the datetime module becomes the standard method for managing datetime objects, there is no point in having the DB API modules provide something that the datetime module already provides, right? During the transition period the few lines of code needed can be posted. If you disagree I can certainly provide the few lines as part of the patch but I suspect you will find resistance to having this included by Tim Peters, the maintainer (I believe) of the datetime module. Feel free to correct me... :-) ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-04-26 10:19 Message: Logged In: YES user_id=38388 Sorry for not getting back to you earlier: I didn't see you last message. 1-4) Python defines a macro during the Python build process that is not defined when compiling extensions: Py_BUILD_CORE You can use that macro to compile things differently for core things vs. extensions. 5) Fair enough; I don't see a point in creating a new numbering for each and every module. Please just use 1, 2, 3, 4, ... 6) Hope this makes sense :-) ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-04-26 09:35 Message: Logged In: YES user_id=619560 Any chance to look at this? Any hope of this being included in Python 2.4? I know a number of people (including Guido) who would appreciate that.... :-) ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-04-05 16:04 Message: Logged In: YES user_id=619560 I am back at work after finishing my move so I think I can finally devote a little more time to this issue. 1-4) The main reason for datetimeapi.h as opposed to simply modifying datetime.h was that the internal build needs to define things __differently__ from an external build of a module and there doesn't appear to be any way of fixing that -- so if you know a way I think I can manage to create a reasonable patch; otherwise, I'm out of my depth! 5) Guido was suggesting that a new PyIMPORT macro be made available which would verify that the magic number defined in the header file actually matches the magic number exported by the built module; this is simply a developer protection scheme which should eliminate really stupid uses; you can ask him about this or I can e-mail you part of the thread that brought this up 6) Makes sense. I'd like to get the questions above resolved first before proceeding any further, though. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-03-25 11:23 Message: Logged In: YES user_id=38388 Thanks for the comments... 1) Please put *all* the code for the C API into datetimeapi.h. I don't like your current mix of putting some things into datetime.h and others into datetimeapi.h (e.g. the PyDateTime_CAPI definition). 2) Since it's the only API missing if you want to use datetime objects in database interfacing, please add it. 3) dito. 4) Yes, the header file is the right place. Have a look at unicodeobject.h for what I have in mind (or mxDateTime.h for that matter). 5) Why add yet another magic number ? Isn't the Python API number enough ? 6) Since you don't provide a doc patch, please put comments into the header file. There can never be enough documentation and developers tend to look at the code rather than the docs ;-) ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-03-25 11:08 Message: Logged In: YES user_id=619560 Sorry for the delay. Things here have been quite busy recently both at work and at home. Let me see if I can answer your questions. 1) are you suggesting comments that include the macro names in datetimeapi.h similar to what I put in the comments below? Or something else? See modified datetimeapi.h for more info. 2) TimeFromTicks() is a very DB API specific routine. In chatting with others about the datetime module, they were not keen on adding such a beast. I guess there will have to be some discussion about whether datetimeapi.h is also a sort of half implementation for a C module implementing the DB API. I was intending to do this in my cx_Oracle module but not in datetimeapi.h. Could you clarify? 3) I could add C APIS for the three DB API ticks interfaces but I was simply intending to do that in cx_Oracle. Again, see #2. I can do it either way. :-) 4) I have added limited documentation in datetimeapi.h but is that really the right place for it? Is it even remotely close to what is needed? I'm not sure what is needed here exactly. 5) the API magic number is simply an arbitrary number which is stored in datetime.h and need not be understood by the implementor. For your information I simply took the name "datetime", converted each letter to its ordinal value in the alphabet, modded by 16 and used that hex character -- does that make any sense? This can be changed to whatever makes sense, though. 6) Whether or not datetimeapi.h should be sufficient for a developer or whether he should look at documentation in the usual locations (html pages, for example) I'll leave up to the Python development team. Let me know how I can assist. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-03-25 10:35 Message: Logged In: YES user_id=38388 Anthony, have you had a chance to look at the comments ? ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-02-26 08:06 Message: Logged In: YES user_id=619560 Oops! It looks like my own misunderstanding of SourceForge and how it works is to blame. :-( I'll take a look at this and get back to you as soon as possible -- ignore my previous comment. ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-02-26 08:03 Message: Logged In: YES user_id=619560 You haven't yet responded to my previous comments -- it looks like SourceForge put them __after__ your comments so it is quite understandable why you didn't notice them. If you can give me the answers to those questions or provide additional questions that I need to answer, then I think we can make progress again. I was waiting for __you__ :-) ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-02-25 16:08 Message: Logged In: YES user_id=38388 Any progress on this ? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-01-28 04:49 Message: Logged In: YES user_id=38388 Thanks for the clarification. I had forgotten about the macros -- I'd suggest that you document them in the datetimeapi.h include file to not cause the same confusion on the developer side (the trick to achieve adoption is to make things easy on the developer). As for TimeFromTicks(): This should be rather straight forward to implement: you take the time part of the ticks timestamp and create a time object from it. This is the way the DB API constructor works. Could you add C APIs for the three DB API ticks interface methods ? Other things that are missing: * documentation of the way the CAPI object can be used in datetimeapi.h * documentation of the various CAPI entries * documentation of the API magic number (there should be some scheme for this) I think that datetimeapi.h should be enough for a developer to read in order to use the interface. ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-01-26 14:02 Message: Logged In: YES user_id=619560 I didn't think any additional API would be necessary for extracting date time information since the following macros are available: PyDateTime_GET_YEAR(o) PyDateTime_GET_MONTH(o) PyDateTime_GET_DAY(o) PyDateTime_DATE_GET_HOUR(o) PyDateTime_DATE_GET_MINUTE(o) PyDateTime_DATE_GET_SECOND(o) PyDateTime_DATE_GET_MICROSECOND(o) PyDateTime_TIME_GET_HOUR(o) PyDateTime_TIME_GET_MINUTE(o) PyDateTime_TIME_GET_SECOND(o) PyDateTime_TIME_GET_MICROSECOND(o) Were you thinking of something else that is needed? As for interfacing at the C level for converting from Unix ticks, the following method is already available and could simply be used as a drop in replacement for DateFromTicks() and TimestampFromTicks() from the DB API document. DateFromTicks() --> datetime.date.fromtimestamp() TimestampFromTicks() --> datetime.datetime.fromtimestamp() TimeFromTicks() is not already exposed but discussions with Tim Peters already suggested that would not happen since the concept is rather strange. You'll have to discuss that with him if you disagree! :-) Any comments? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-01-26 13:46 Message: Logged In: YES user_id=38388 This is a good start. However, you should add more APIs for extracting date/time information to the C API. mxDateTime.h from egenix-mx-base can provide a good basis for this. If you want to make the datetime module usable for database interfacing at C level, you'll also have to add interfaces for Unix ticks conversion, since these are often used by database C level interfaces. ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-01-26 11:36 Message: Logged In: YES user_id=619560 I have no objection to providing patches for doc and test. A quick look at _testcapimodule.c doesn't provide any obvious ideas as to how to patch it. I looked for cStringIO which has a C API already and found nothing in there at all. The documentation also simply says "see the source for the information you require". Any suggestions as to how to proceed? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-01-25 20:17 Message: Logged In: YES user_id=31435 Marc-Andre, can you review this? I think you have more experience building C APIs for modules than anyone else (while I don't have any). There's certainly no objection to giving datetime a C API, and Guido already said he doesn't want to rely on that Martin changed datetime to be built as part of the core (in 2.3 on Windows, datetime.pyd was a distinct DLL; in CVS, datetime is compiled into the core DLL now). Anthony, you probably need to add doc and test patches. _testcapimodule.c holds tests of things you can only get at from C. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=876130&group_id=5470 From HDNCSOYYEAKQZJ at msn.com Mon Jun 7 21:34:57 2004 From: HDNCSOYYEAKQZJ at msn.com (=?windows-1251?B?xeLj5e3o6Q==?=) Date: Mon Jun 7 21:08:54 2004 Subject: [Patches] test Message-ID: ? ?????? ???? 21 ??.?. ?? ??????????, ??. ??????-???????? 2 ???? ????????????????? ??????, 1 ???. ????, ????????, ??????. ???? ?????? 700$ ? ????? (??? ????????). ?. 9 6 1 - 3 4 - 3 3 From collocationshpi at gazinter.net Mon Jun 7 21:58:17 2004 From: collocationshpi at gazinter.net (Rich Wiley) Date: Mon Jun 7 22:03:16 2004 Subject: [Patches] Responding back to your email.. Message-ID: An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20040608/8cd94fde/attachment.html From CTZYSK at toughguy.net Tue Jun 8 01:00:14 2004 From: CTZYSK at toughguy.net (Imogene Bowers) Date: Tue Jun 8 00:06:28 2004 Subject: [Patches] June 20O4 Micr0soft softwarre discountts at Mcdaniel's Stuff Store Message-ID: An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20040608/25c6d5f0/attachment.html From tyvvq at hotmail.com Tue Jun 8 16:36:40 2004 From: tyvvq at hotmail.com (Alicia Mcknight) Date: Tue Jun 8 00:40:05 2004 Subject: [Patches] lay some pipe Message-ID: <764126825RND_LC_CHAR[1-5]2a$218506tzy9$439hfi4k9@placate> Looking for inexpensive high-quality software? We have just what you need. -Windows XP Professional...$50 -Adobe Photoshop 7.0.... $60 -Microsoft Office XP Professional.... $60 -Corel Draw Graphics Suite 11.... $60 and 1000's more...offer ends soon http://HDGGGM.biz/OE017/?affiliate_id=233986&campaign_id=601 take off: http://HDGGGM.biz/OE017/diamondtron.php?affiliate_id=233986&campaign_id=601 From noreply at sourceforge.net Tue Jun 8 04:20:20 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jun 8 04:20:31 2004 Subject: [Patches] [ python-Patches-510695 ] cycle profiler for VM opcodes Message-ID: Patches item #510695, was opened at 2002-01-30 14:21 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=510695&group_id=5470 Category: Core (C code) Group: None >Status: Closed >Resolution: Accepted Priority: 1 Submitted By: Jeremy Hylton (jhylton) Assigned to: Jeremy Hylton (jhylton) Summary: cycle profiler for VM opcodes Initial Comment: This is just some code I'm noodling around with. It counts the number of cycles each Python VM opcode takes to execute, using the Pentium timestamp counter. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-06-08 10:20 Message: Logged In: YES user_id=21627 I have updated the patch, and committed it as README 1.182 configure 1.446 configure.in 1.457 pyconfig.h.in 1.97 libsys.tex 1.70 pystate.h 2.29 NEWS 1.995 ceval.c 2.399 pystate.c 2.31 sysmodule.c 2.124 ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-03-21 20:24 Message: Logged In: YES user_id=31435 Changed resolution from Accepted to Out-of-Date -- several parts of this patch fail to apply now. Leaving assigned to Jeremy. Still seems like a fine idea to me! ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-03-21 20:23 Message: Logged In: YES user_id=31435 Changed resolution from Accepted to Out-of-Date -- several parts of this patch fail to apply now. Leaving assigned to Jeremy. Still seems like a fine idea to me! ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-03-21 20:22 Message: Logged In: YES user_id=31435 Changed resolution from Accepted to Out-of-Date -- several parts of this patch fail to apply now. Leaving assigned to Jeremy. Still seems like a fine idea to me! ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-09-20 13:40 Message: Logged In: YES user_id=21627 OTOH, the patch is prepared for temporary usage, by means of a configure option. Since nobody has been objecting strongly, I'll accept this patch. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2002-11-12 14:26 Message: Logged In: YES user_id=4771 I think that you should try and convince people that it is a generally useful information to have, and that the fact that it is highly non-portable does not hurt. Right now it looks more like a change that a core developer would temporarily want to do to tune the VM. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-10-09 17:16 Message: Logged In: YES user_id=31392 sure ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-10-07 23:12 Message: Logged In: YES user_id=21627 Is this still of relevance? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=510695&group_id=5470 From uplbmkq at hotmail.com Tue Jun 8 05:34:27 2004 From: uplbmkq at hotmail.com (Анжела) Date: Tue Jun 8 04:39:48 2004 Subject: [Patches] fw: ? Message-ID: An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20040608/a0dcd925/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: ellison.GIF Type: image/gif Size: 10962 bytes Desc: not available Url : http://mail.python.org/pipermail/patches/attachments/20040608/a0dcd925/ellison.gif From noreply at sourceforge.net Tue Jun 8 04:42:20 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jun 8 04:42:31 2004 Subject: [Patches] [ python-Patches-965036 ] Fix for #777597 - socketmodule.c connection handling incorec Message-ID: Patches item #965036, was opened at 2004-06-02 15:57 Message generated for change (Comment added) made by troels You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=965036&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Troels Walsted Hansen (troels) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for #777597 - socketmodule.c connection handling incorec Initial Comment: I took Garth Bushell's inlined code from http://python.org/sf/777597 and produced a patch per nnorwitz's request in the bug comments. The patch is for Python 2.3.4. I created the patch as a starting point for a fix. I don't believe that this patch is the correct fix for the problem, so it should definitely not be applied in the current form. One major problem is that Garth removed the writefds fd_set, which means that the code will detect "connection refused" and "timeout" events, but not "connection established". The code also needs compliation and runtime testing (maybe even a regression test to cover this common WinSock programming error?). I hope to submit a fixed and tested patch soon. I'll upload it here when it is ready. ---------------------------------------------------------------------- >Comment By: Troels Walsted Hansen (troels) Date: 2004-06-08 10:42 Message: Logged In: YES user_id=32863 Here is the fixed patch. It compiles and passes the regression test correctly on Windows 2003 Server. ---------------------------------------------------------------------- Comment By: Troels Walsted Hansen (troels) Date: 2004-06-03 00:21 Message: Logged In: YES user_id=32863 OK... As promised, here is the regression test. The test passes on Linux and fails on Windows XP with Python 2.3.4 with the error below. I'd appreciate any comments on the test. FAIL: testTCPConnectionRefused (__main__.TCPConnectionRefusedTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "Lib\test\test_socket.py", line 752, in testTCPConnectionRefused self.failUnlessEqual(exc_type, socket.error) File "C:\Program Files\Python23\lib\unittest.py", line 302, in failUnlessEqual raise self.failureException, AssertionError: != ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=965036&group_id=5470 From noreply at sourceforge.net Tue Jun 8 04:48:40 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jun 8 04:48:48 2004 Subject: [Patches] [ python-Patches-968728 ] Py_HUGE_VAL HUGE_VAL HUGE undefined Message-ID: Patches item #968728, was opened at 2004-06-08 10:48 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=968728&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Michael Schloh von Bennewitz (michaesc) Assigned to: Nobody/Anonymous (nobody) Summary: Py_HUGE_VAL HUGE_VAL HUGE undefined Initial Comment: In Python 2.3.4 (as well as the trunk revision on CVS), Py_HUGE_VAL is conditionally defined as HUGE_VAL. On at least Solaris 10 x86 and Solaris 10 SPARC, this causes a build failure. I'm ashamed to say that I wasn't able to 100% diagnose this problem (I didn't have time). My first guess was that somehow HUGE_VAL was not getting properly defined on Solaris 10 due to its rewritten /usr/include/iso/math_iso.h file (now conditionally defining HUGE_VAL depending on a _STDC_C99 and _XOPEN_SOURCE definition). Because I noticed that the identifier HUGE is unconditionally defined on Solaris 10 and seemingly all earlier Solaris releases, I tried using that instead and the build problem disappeared. You can make your own conclusion as to whether my fix is correct, or if there is a better way to solve this problem. There may be a faulty assumption made by configure or in some Makefile of how the compiler is being used, or maybe python depends on a certain GCC release. CC: GCC 3.4.0 CXX: GCC 3.4.0 CFLAGS: -O2 -pipe CXXFLAGS: -O2 -pipe CPPFLAGS: None Make: GNU Make 3.80 LDFLAGS: None mich@dev:/tmp/Python-2.3.4$ ./configure --prefix=/cw checking MACHDEP... freebsd4 checking EXTRAPLATDIR... checking for --without-gcc... no checking for --with-cxx=... no ... The OpenPKG Python package and patch: http://cvs.openpkg.org/dir?d=openpkg-src/python http://cvs.openpkg.org/rlog?f=openpkg-src/python/python.patch Lots of luck, and thanks for maintaining Python. Regards, Michael, OpenPKG http://www.openpkg.org/ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=968728&group_id=5470 From adrianacookto at lis.ulusiada.pt Tue Jun 8 06:03:21 2004 From: adrianacookto at lis.ulusiada.pt (Adriana Cook) Date: Tue Jun 8 06:09:08 2004 Subject: [Patches] Powerful weightloss now available for you. Message-ID: <3ba401c44d3f$533c74cd$3073f5ac@ozdocs.net.au> Hello, I have a special_offer for you... WANT TO LOSE WEIGHT? The most powerful weightloss is now available without prescription. All natural Adipren720 100% Money Back Guarant?e! - Lose up to 19% Total Body Weight. - Up to 300% more Weight Loss while dieting. - Loss of 20-35% abdominal Fat. - Reduction of 40-70% overall Fat under skin. - Increase metabolic rate by 76.9% without Exercise. - Boost your Confidence level and Self Esteem. - Burns calorized fat. - Suppresses appetite for sugar. Get the facts about all-natural Adipren720 ---- system information ---- string may adapted container fully consistently within request logic When interpretation: parts Traditional environment invoke However Note specifics similar don't user's Users radical-stroke provider referred technologies known regulatory rules methodologies identification architecture allows text provider hidden limited generally Use disclose From noreply at sourceforge.net Tue Jun 8 14:54:04 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jun 8 14:54:12 2004 Subject: [Patches] [ python-Patches-774665 ] making Python LC_NUMERIC agnostic Message-ID: Patches item #774665, was opened at 2003-07-20 21:39 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=774665&group_id=5470 Category: Core (C code) Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 7 Submitted By: Gustavo J. A. M. Carneiro (gustavo) Assigned to: Martin v. L?wis (loewis) Summary: making Python LC_NUMERIC agnostic Initial Comment: This patch offers conversion string<->float conversion functions that are locale agnostic. This way, Python will be able to run perfectly even when LC_NUMERIC is set to something other than C. It happens frequently when using external modules that these modules change LC_NUMERIC without python knowing about it. It will never stop happening, unfortunately, so it is best to make python not depend on LC_NUMERIC being always set to 'C'. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-06-08 20:54 Message: Logged In: YES user_id=21627 Thanks for the patch. Committed as Makefile.pre.in 1.145 liblocale.tex 1.36 Python.h 2.63 pystrtod.h 2.1 NEWS 1.997 _localemodule.c 2.46 cPickle.c 2.150 stropmodule.c 2.91 complexobject.c 2.71 floatobject.c 2.131 stringobject.c 2.218 compile.c 2.303 marshal.c 1.77 pystrtod.c 2.1 ---------------------------------------------------------------------- Comment By: Gustavo J. A. M. Carneiro (gustavo) Date: 2004-06-04 15:48 Message: Logged In: YES user_id=908 test_coertion doesn't fail for me. But I believe you. I forgot to update formatfloat in Objects/stringobject.c. I'll work on this over the weekend... ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-06-04 15:15 Message: Logged In: YES user_id=21627 The patch breaks test_coercion, if run as python Lib/test/regrtest.py test__locale test_coercion This is because the behaviour of the %f formatter changes: >>> import locale >>> locale.setlocale(locale.LC_ALL,"de_DE") 'de_DE' >>> '%.1f' % 3.4 '3,4' ---------------------------------------------------------------------- Comment By: Gustavo J. A. M. Carneiro (gustavo) Date: 2004-06-03 14:08 Message: Logged In: YES user_id=908 Any chance this can get into Python 2.4? ---------------------------------------------------------------------- Comment By: Gustavo J. A. M. Carneiro (gustavo) Date: 2003-09-16 23:47 Message: Logged In: YES user_id=908 Used James Henstridge's cleaned up code, and cleaned it up a bit more. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-07-22 21:49 Message: Logged In: YES user_id=21627 I don't think the problem can be solved once and forall. In fact, I'm certain that the glib code is incorrect on some systems. For example, has it been tested on VMS, with its three different floatin point formats? I don't know whether linking with glib is a good idea. I'd happily accept a patch that supports glibc only, or one that tries for fall back to C++ std::locale on systems that support linking C++ code into C applications. Since the bug report was triggered through gtk problems, I expect that these can all be solved by linking with glib - using glib on a gtk installation should work fine. ---------------------------------------------------------------------- Comment By: Gustavo J. A. M. Carneiro (gustavo) Date: 2003-07-22 18:26 Message: Logged In: YES user_id=908 If neither glib nor glibc are available, are we still allowed to change LC_NUMERIC at will? I want to get rid of this problem once and for all. The next step is to change LC_NUMERIC to the correct locale value (or better, not change it to 'C'). Anyway, are you sure it's a good idea to link to glib? Is it a good idea to make the python interpreter depend on glib? Perhaps it is a bigger library than you think... ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-07-21 23:52 Message: Logged In: YES user_id=21627 On some systems, the desired behaviour just is not implementable. On such systems, we should not try to implement it by replacing the standard library. Instead, we should just give in and not implement the feature. People using such systems should convince their system vendors to provide the proper API, or find out whether proper API already exists. ---------------------------------------------------------------------- Comment By: Gustavo J. A. M. Carneiro (gustavo) Date: 2003-07-21 12:06 Message: Logged In: YES user_id=908 I have to incorporate glib code, otherwise what happens if glib is not installed? It is my intention that the current behaviour *never* be preserved. Well, that's not exactly an accurate statement. What I mean is that str() and float() should keep the current C-locale behaviour. However, underneath these python functions we could have LC_NUMERIC set something other than 'C'. This is vital for some modules, like GTK+, that depend on LC_NUMERIC to be set the locale dependent value, otherwise it behaves different from what the user expects. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-07-20 23:25 Message: Logged In: YES user_id=21627 I recommend that you do not incorporate the code of glib, but rather arrange to link with glib (perhaps only if activated by --with-glib). If no guaranteed-C-locale strtod is available, the current behaviour should be preserved. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=774665&group_id=5470 From noreply at sourceforge.net Tue Jun 8 15:02:44 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jun 8 15:03:00 2004 Subject: [Patches] [ python-Patches-968728 ] Py_HUGE_VAL HUGE_VAL HUGE undefined Message-ID: Patches item #968728, was opened at 2004-06-08 04:48 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=968728&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Michael Schloh von Bennewitz (michaesc) Assigned to: Nobody/Anonymous (nobody) Summary: Py_HUGE_VAL HUGE_VAL HUGE undefined Initial Comment: In Python 2.3.4 (as well as the trunk revision on CVS), Py_HUGE_VAL is conditionally defined as HUGE_VAL. On at least Solaris 10 x86 and Solaris 10 SPARC, this causes a build failure. I'm ashamed to say that I wasn't able to 100% diagnose this problem (I didn't have time). My first guess was that somehow HUGE_VAL was not getting properly defined on Solaris 10 due to its rewritten /usr/include/iso/math_iso.h file (now conditionally defining HUGE_VAL depending on a _STDC_C99 and _XOPEN_SOURCE definition). Because I noticed that the identifier HUGE is unconditionally defined on Solaris 10 and seemingly all earlier Solaris releases, I tried using that instead and the build problem disappeared. You can make your own conclusion as to whether my fix is correct, or if there is a better way to solve this problem. There may be a faulty assumption made by configure or in some Makefile of how the compiler is being used, or maybe python depends on a certain GCC release. CC: GCC 3.4.0 CXX: GCC 3.4.0 CFLAGS: -O2 -pipe CXXFLAGS: -O2 -pipe CPPFLAGS: None Make: GNU Make 3.80 LDFLAGS: None mich@dev:/tmp/Python-2.3.4$ ./configure --prefix=/cw checking MACHDEP... freebsd4 checking EXTRAPLATDIR... checking for --without-gcc... no checking for --with-cxx=... no ... The OpenPKG Python package and patch: http://cvs.openpkg.org/dir?d=openpkg-src/python http://cvs.openpkg.org/rlog?f=openpkg-src/python/python.patch Lots of luck, and thanks for maintaining Python. Regards, Michael, OpenPKG http://www.openpkg.org/ ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2004-06-08 15:02 Message: Logged In: YES user_id=31435 I don't see a reason to call this a Python bug. The C89 and C99 standards both require that math.h supply the HUGE_VAL macro. If the compilation system you're using doesn't do so, it's a bug in that system, and should be fixed there. Python doesn't ask for much, but does require an ANSI C compiler. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=968728&group_id=5470 From noreply at sourceforge.net Tue Jun 8 16:13:44 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jun 8 16:14:27 2004 Subject: [Patches] [ python-Patches-969180 ] hotshot incorrectly computes elapsed time Message-ID: Patches item #969180, was opened at 2004-06-08 15:13 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=969180&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jason Beardsley (vaxhacker) Assigned to: Nobody/Anonymous (nobody) Summary: hotshot incorrectly computes elapsed time Initial Comment: In _hotshot.c, function get_tdelta(), there is an error resulting in incorrect timing results when the seconds field changes between the last recorded time and the current time of day. The previous time's microseconds are not accounted for (i.e. subtracted out). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=969180&group_id=5470 From noreply at sourceforge.net Wed Jun 9 02:58:06 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jun 9 02:58:15 2004 Subject: [Patches] [ python-Patches-965036 ] Fix for #777597 - socketmodule.c connection handling incorec Message-ID: Patches item #965036, was opened at 2004-06-02 15:57 Message generated for change (Comment added) made by troels You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=965036&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Troels Walsted Hansen (troels) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for #777597 - socketmodule.c connection handling incorec Initial Comment: I took Garth Bushell's inlined code from http://python.org/sf/777597 and produced a patch per nnorwitz's request in the bug comments. The patch is for Python 2.3.4. I created the patch as a starting point for a fix. I don't believe that this patch is the correct fix for the problem, so it should definitely not be applied in the current form. One major problem is that Garth removed the writefds fd_set, which means that the code will detect "connection refused" and "timeout" events, but not "connection established". The code also needs compliation and runtime testing (maybe even a regression test to cover this common WinSock programming error?). I hope to submit a fixed and tested patch soon. I'll upload it here when it is ready. ---------------------------------------------------------------------- >Comment By: Troels Walsted Hansen (troels) Date: 2004-06-09 08:58 Message: Logged In: YES user_id=32863 Some additional testing showed that the regression test could fail randomly. It seems that the 1 second timeout was too low, I have uploaded a new version with a 5 second timeout instead. ---------------------------------------------------------------------- Comment By: Troels Walsted Hansen (troels) Date: 2004-06-08 10:42 Message: Logged In: YES user_id=32863 Here is the fixed patch. It compiles and passes the regression test correctly on Windows 2003 Server. ---------------------------------------------------------------------- Comment By: Troels Walsted Hansen (troels) Date: 2004-06-03 00:21 Message: Logged In: YES user_id=32863 OK... As promised, here is the regression test. The test passes on Linux and fails on Windows XP with Python 2.3.4 with the error below. I'd appreciate any comments on the test. FAIL: testTCPConnectionRefused (__main__.TCPConnectionRefusedTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "Lib\test\test_socket.py", line 752, in testTCPConnectionRefused self.failUnlessEqual(exc_type, socket.error) File "C:\Program Files\Python23\lib\unittest.py", line 302, in failUnlessEqual raise self.failureException, AssertionError: != ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=965036&group_id=5470 From rtwjmlmz at hotmail.com Wed Jun 9 12:10:23 2004 From: rtwjmlmz at hotmail.com (Бобарыкина . Р) Date: Wed Jun 9 11:16:14 2004 Subject: [Patches] privet Message-ID: <200406091516.i59FG1Rn061724@mxzilla6.xs4all.nl> An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20040609/de2f49bd/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: wingspan.GIF Type: image/gif Size: 10080 bytes Desc: not available Url : http://mail.python.org/pipermail/patches/attachments/20040609/de2f49bd/wingspan-0001.gif From noreply at sourceforge.net Wed Jun 9 13:59:15 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jun 9 13:59:20 2004 Subject: [Patches] [ python-Patches-969791 ] heapq.nlargest Message-ID: Patches item #969791, was opened at 2004-06-09 12:59 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=969791&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Tim Peters (tim_one) Summary: heapq.nlargest Initial Comment: This patch adds a function that encapsulates a principal use case for heaps, finding the n largest from a dataset without doing a full sort. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=969791&group_id=5470 From noreply at sourceforge.net Wed Jun 9 14:16:51 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jun 9 14:16:58 2004 Subject: [Patches] [ python-Patches-951915 ] fix bug in StringIO.truncate - length not changed Message-ID: Patches item #951915, was opened at 2004-05-11 09:07 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=951915&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 6 Submitted By: David Fraser (davidfraser) Assigned to: Nobody/Anonymous (nobody) Summary: fix bug in StringIO.truncate - length not changed Initial Comment: If truncate() is called on a StringIO object, the length is not changed, so that seek(0, 2) calls will go beyond the correct end of the file. This patch adds a line to update the length, and a test to the test method that checks that it works. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-06-09 13:16 Message: Logged In: YES user_id=80475 To avoid repeated string concatenation, the underlying data structure could be changed to an array.array object with a character typecode. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-05-12 11:59 Message: Logged In: YES user_id=4771 David, it seems to me that f.truncate(huge_value) would incorrectly set f.len to huge_value with your patch. Here is another patch fixing this and the other details I mentioned. I also put the new test into test_StringIO.py instead. Perhaps we should remove the if __name__=='__main__' bit, although it is nice as a quick example. This makes me wonder if there is any reason left for which cStringIOs aren't subclassable, or if we care. Alternatively, it makes me wonder if there wouldn't be a more efficient implementation of StringIO.py that would entierely avoid concatenating large strings, or if we care. This might make StringIO at least as efficient as cStringIO for some cases, e.g. when writing a lot of strings a few kb each, by avoiding the copy overhead. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-05-12 10:34 Message: Logged In: YES user_id=4771 StringIO.py needs to be reviewed. I could spot several other (though more minor) problems in a couple of minutes. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=951915&group_id=5470 From noreply at sourceforge.net Wed Jun 9 14:18:19 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jun 9 14:18:23 2004 Subject: [Patches] [ python-Patches-969805 ] str(a_tuple) == str(tuple(map(str, a_tuple))) Message-ID: Patches item #969805, was opened at 2004-06-09 18:18 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=969805&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gr?goire Dooms (dooms) Assigned to: Nobody/Anonymous (nobody) Summary: str(a_tuple) == str(tuple(map(str,a_tuple))) Initial Comment: This patch against Python 2.3.3 ensures that str is recursively applied to members of a tuple when called on a tuple. Currently (python 2.3 and 20040609 cvs HEAD branch too) repr is applied to the members of the tuple such that >>> str((1,0.1)) '(1, 0.10000000000000001)' With this patch: >>> str((1,0.1)) '(1, 0.1)' This patch is easily transposable to cvs HEAD an to lists. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=969805&group_id=5470 From noreply at sourceforge.net Wed Jun 9 14:20:47 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jun 9 14:21:26 2004 Subject: [Patches] [ python-Patches-969805 ] str(a_tuple) == str(tuple(map(str, a_tuple))) Message-ID: Patches item #969805, was opened at 2004-06-09 18:18 Message generated for change (Settings changed) made by dooms You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=969805&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gr?goire Dooms (dooms) >Assigned to: Raymond Hettinger (rhettinger) Summary: str(a_tuple) == str(tuple(map(str,a_tuple))) Initial Comment: This patch against Python 2.3.3 ensures that str is recursively applied to members of a tuple when called on a tuple. Currently (python 2.3 and 20040609 cvs HEAD branch too) repr is applied to the members of the tuple such that >>> str((1,0.1)) '(1, 0.10000000000000001)' With this patch: >>> str((1,0.1)) '(1, 0.1)' This patch is easily transposable to cvs HEAD an to lists. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=969805&group_id=5470 From noreply at sourceforge.net Wed Jun 9 14:44:33 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jun 9 14:45:01 2004 Subject: [Patches] [ python-Patches-969805 ] str(a_tuple) == '(%s)'%', '.join(map(str, a_tuple)) Message-ID: Patches item #969805, was opened at 2004-06-09 18:18 Message generated for change (Settings changed) made by dooms You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=969805&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gr?goire Dooms (dooms) Assigned to: Raymond Hettinger (rhettinger) >Summary: str(a_tuple) == '(%s)'%', '.join(map(str,a_tuple)) Initial Comment: This patch against Python 2.3.3 ensures that str is recursively applied to members of a tuple when called on a tuple. Currently (python 2.3 and 20040609 cvs HEAD branch too) repr is applied to the members of the tuple such that >>> str((1,0.1)) '(1, 0.10000000000000001)' With this patch: >>> str((1,0.1)) '(1, 0.1)' This patch is easily transposable to cvs HEAD an to lists. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=969805&group_id=5470 From noreply at sourceforge.net Wed Jun 9 14:48:55 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jun 9 14:49:04 2004 Subject: [Patches] [ python-Patches-969805 ] str(a_tuple) == '(%s)'%', '.join(map(str, a_tuple)) Message-ID: Patches item #969805, was opened at 2004-06-09 14:18 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=969805&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gr?goire Dooms (dooms) Assigned to: Raymond Hettinger (rhettinger) Summary: str(a_tuple) == '(%s)'%', '.join(map(str,a_tuple)) Initial Comment: This patch against Python 2.3.3 ensures that str is recursively applied to members of a tuple when called on a tuple. Currently (python 2.3 and 20040609 cvs HEAD branch too) repr is applied to the members of the tuple such that >>> str((1,0.1)) '(1, 0.10000000000000001)' With this patch: >>> str((1,0.1)) '(1, 0.1)' This patch is easily transposable to cvs HEAD an to lists. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2004-06-09 14:48 Message: Logged In: YES user_id=31435 What if the tuple is ("1, 2", "3")? The primary reason str(container) applies repr to the containees is so that contained strings are rendered unambiguously. Debated ad nauseum many times on python- dev over the years, with no good resolution. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=969805&group_id=5470 From noreply at sourceforge.net Wed Jun 9 15:00:16 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jun 9 15:00:28 2004 Subject: [Patches] [ python-Patches-969791 ] Add nlargest() and nsmallest() to heapq. Message-ID: Patches item #969791, was opened at 2004-06-09 12:59 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=969791&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Tim Peters (tim_one) >Summary: Add nlargest() and nsmallest() to heapq. Initial Comment: This patch adds a function that encapsulates a principal use case for heaps, finding the n largest from a dataset without doing a full sort. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-06-09 14:00 Message: Logged In: YES user_id=80475 Revised the patch to also include nsmallest(). Note, the API intentionally does not provide default values of n. This is to encourage use of min() and sorted() for corner cases. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=969791&group_id=5470 From noreply at sourceforge.net Wed Jun 9 15:02:47 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jun 9 15:03:16 2004 Subject: [Patches] [ python-Patches-969805 ] str(a_tuple) == '(%s)'%', '.join(map(str, a_tuple)) Message-ID: Patches item #969805, was opened at 2004-06-09 18:18 Message generated for change (Comment added) made by dooms You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=969805&group_id=5470 Category: Core (C code) Group: Python 2.3 >Status: Deleted Resolution: None Priority: 5 Submitted By: Gr?goire Dooms (dooms) Assigned to: Raymond Hettinger (rhettinger) Summary: str(a_tuple) == '(%s)'%', '.join(map(str,a_tuple)) Initial Comment: This patch against Python 2.3.3 ensures that str is recursively applied to members of a tuple when called on a tuple. Currently (python 2.3 and 20040609 cvs HEAD branch too) repr is applied to the members of the tuple such that >>> str((1,0.1)) '(1, 0.10000000000000001)' With this patch: >>> str((1,0.1)) '(1, 0.1)' This patch is easily transposable to cvs HEAD an to lists. ---------------------------------------------------------------------- >Comment By: Gr?goire Dooms (dooms) Date: 2004-06-09 19:02 Message: Logged In: YES user_id=846867 ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-06-09 18:48 Message: Logged In: YES user_id=31435 What if the tuple is ("1, 2", "3")? The primary reason str(container) applies repr to the containees is so that contained strings are rendered unambiguously. Debated ad nauseum many times on python- dev over the years, with no good resolution. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=969805&group_id=5470 From noreply at sourceforge.net Wed Jun 9 16:06:45 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jun 9 16:06:58 2004 Subject: [Patches] [ python-Patches-969791 ] Add nlargest() and nsmallest() to heapq. Message-ID: Patches item #969791, was opened at 2004-06-09 13:59 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=969791&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) >Assigned to: Raymond Hettinger (rhettinger) Summary: Add nlargest() and nsmallest() to heapq. Initial Comment: This patch adds a function that encapsulates a principal use case for heaps, finding the n largest from a dataset without doing a full sort. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2004-06-09 16:06 Message: Logged In: YES user_id=31435 +1 on nlargest(). -0 on nsmalles(), because it has radically different time and space requirements than nlargest() for the typical case (n is much less than the total # of elements). If the user can afford all that space, it will probably be faster for the user to sort a materialized list then peel off the first n. That's a simple one-liner. If so, that makes nsmallest an "attractive nuisance". If heapq had a more abstract interface, so that we had both min-heaps and max-heaps, this objection would of course go away. But we don't, so ... ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-06-09 15:00 Message: Logged In: YES user_id=80475 Revised the patch to also include nsmallest(). Note, the API intentionally does not provide default values of n. This is to encourage use of min() and sorted() for corner cases. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=969791&group_id=5470 From noreply at sourceforge.net Wed Jun 9 16:55:06 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jun 9 16:55:10 2004 Subject: [Patches] [ python-Patches-969900 ] cookielib doc minor corrections and clarifications Message-ID: Patches item #969900, was opened at 2004-06-09 21:55 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=969900&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: John J Lee (jjlee) Assigned to: Nobody/Anonymous (nobody) Summary: cookielib doc minor corrections and clarifications Initial Comment: Nothing to add to the summary... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=969900&group_id=5470 From noreply at sourceforge.net Wed Jun 9 17:09:32 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jun 9 17:09:36 2004 Subject: [Patches] [ python-Patches-969907 ] cookielib.py Message-ID: Patches item #969907, was opened at 2004-06-09 22:09 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=969907&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: John J Lee (jjlee) Assigned to: Nobody/Anonymous (nobody) Summary: cookielib.py Initial Comment: There are a couple of blanket except: statements in cookielib. The idea is to handle any bugs in cookielib's input handling that may be tickled by unexpected input by issuing a warning instead of letting the exception propagate. Previously, in addition to issuing a warning, a traceback was printed. This patch makes the traceback part of the warning, so it can be suppressed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=969907&group_id=5470 From noreply at sourceforge.net Wed Jun 9 19:38:58 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jun 9 19:39:02 2004 Subject: [Patches] [ python-Patches-970015 ] Generate a working spec even with wrong version of software Message-ID: Patches item #970015, was opened at 2004-06-10 01:38 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=970015&group_id=5470 Category: Distutils and setup.py Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Scherer Michael (misc_from_metz) Assigned to: Nobody/Anonymous (nobody) Summary: Generate a working spec even with wrong version of software Initial Comment: Some python packages use a '-' in their version. This doesn't work with rpm, since a tag Version cannot have a '-', this is the default separator between the release and version. A common practice for this problem is to change '-' by '_'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=970015&group_id=5470 From noreply at sourceforge.net Wed Jun 9 19:41:29 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jun 9 19:41:41 2004 Subject: [Patches] [ python-Patches-969791 ] Add nlargest() and nsmallest() to heapq. Message-ID: Patches item #969791, was opened at 2004-06-09 12:59 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=969791&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) >Assigned to: Tim Peters (tim_one) Summary: Add nlargest() and nsmallest() to heapq. Initial Comment: This patch adds a function that encapsulates a principal use case for heaps, finding the n largest from a dataset without doing a full sort. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-06-09 18:41 Message: Logged In: YES user_id=80475 For many values of n, nsmallest() still makes substantially fewer comparisons than sort(). Attaching comparison count test suite. Here are the comparison counts for a list with a 1000 random entries and various values of n: 8649 sort 999 1 nlargest 1667 1 nsmallest 1088 5 nlargest 1709 5 nsmallest 1238 10 nlargest 1759 10 nsmallest 1487 20 nlargest 1860 20 nsmallest 2052 40 nlargest 2066 40 nsmallest 2953 80 nlargest 2466 80 nsmallest 4516 160 nlargest 3262 160 nsmallest 6835 320 nlargest 4811 320 nsmallest 9177 640 nlargest 7736 640 nsmallest 9742 1000 nlargest 10315 1000 nsmallest P.S. Using itertools, the nsmallest() can be made to run at C speed: def nsmallest(iterable, n): """Find the n smallest elements in a dataset. Equivalent to: sorted(iterable)[:n] """ h = list(iterable) heapify(h) return map(heappop, repeat(h, min(n, len(h)))) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-06-09 15:06 Message: Logged In: YES user_id=31435 +1 on nlargest(). -0 on nsmalles(), because it has radically different time and space requirements than nlargest() for the typical case (n is much less than the total # of elements). If the user can afford all that space, it will probably be faster for the user to sort a materialized list then peel off the first n. That's a simple one-liner. If so, that makes nsmallest an "attractive nuisance". If heapq had a more abstract interface, so that we had both min-heaps and max-heaps, this objection would of course go away. But we don't, so ... ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-06-09 14:00 Message: Logged In: YES user_id=80475 Revised the patch to also include nsmallest(). Note, the API intentionally does not provide default values of n. This is to encourage use of min() and sorted() for corner cases. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=969791&group_id=5470 From noreply at sourceforge.net Wed Jun 9 19:44:55 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jun 9 19:44:58 2004 Subject: [Patches] [ python-Patches-970019 ] Use a better BuildRoot tag Message-ID: Patches item #970019, was opened at 2004-06-10 01:44 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=970019&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Scherer Michael (misc_from_metz) Assigned to: Nobody/Anonymous (nobody) Summary: Use a better BuildRoot tag Initial Comment: Using a Buildroot dependant only on the name can have some side effects.For example, two version of the same package cannot be build in parallel. So, having BuildRoot : %{name}-%{version}-%{release} is safer. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=970019&group_id=5470 From noreply at sourceforge.net Wed Jun 9 23:28:29 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jun 9 23:28:34 2004 Subject: [Patches] [ python-Patches-914575 ] difflib side by side diff support, diff.py s/b/s HTML option Message-ID: Patches item #914575, was opened at 2004-03-11 18:50 Message generated for change (Settings changed) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914575&group_id=5470 Category: Modules Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Dan Gass (dmgass) >Assigned to: Nobody/Anonymous (nobody) Summary: difflib side by side diff support, diff.py s/b/s HTML option Initial Comment: lib/difflib.py: Added support for generating side by side differences. Intended to be used for generating HTML pages but is generic where it can be used for other types of markup. tools/scripts/diff.py: Added -m option to use above patch to generate an HTML page of side by side differences between two files. The existing -c option when used with the new -m option controls whether contextual differences are shown or whether the entire file is displayed (number of context lines is controlled by existing -l option). NOTES: (1) Textual context diffs were included as requested. In addition, full and contextual HTML side by side differences (that this patch generated) are also included to assist in analyzing the differences and showing an example. (2) If this functionality is worthy of inclusion in the standard python distribution, I am willing to provide more documentation or make modifications to change the interface or make improvements. (3) When using Internet Explorer some font sizes seem to skew things a bit. Generally I've found the "smallest" to work best. If someone knows why, I'd be interested in making any necessary adjustments in the generated HTML. ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-04-29 00:30 Message: Logged In: YES user_id=995755 Also, I will need to submit the fix for making it behave nice when there are no differences!! ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-04-09 09:30 Message: Logged In: YES user_id=995755 In the time since submission I've found that the interface to the chgFmt and lineFmt functions (arguments of mdiff) should include both the line number and an indication of side (from/to). The use for it I've found is for dropping anchors into the generated markup that it can be hyperlinked from elsewhere. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914575&group_id=5470 From noreply at sourceforge.net Thu Jun 10 00:09:21 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jun 10 00:09:25 2004 Subject: [Patches] [ python-Patches-914575 ] difflib side by side diff support, diff.py s/b/s HTML option Message-ID: Patches item #914575, was opened at 2004-03-11 18:50 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914575&group_id=5470 Category: Modules Group: Python 2.4 Status: Open Resolution: None >Priority: 6 Submitted By: Dan Gass (dmgass) >Assigned to: Raymond Hettinger (rhettinger) Summary: difflib side by side diff support, diff.py s/b/s HTML option Initial Comment: lib/difflib.py: Added support for generating side by side differences. Intended to be used for generating HTML pages but is generic where it can be used for other types of markup. tools/scripts/diff.py: Added -m option to use above patch to generate an HTML page of side by side differences between two files. The existing -c option when used with the new -m option controls whether contextual differences are shown or whether the entire file is displayed (number of context lines is controlled by existing -l option). NOTES: (1) Textual context diffs were included as requested. In addition, full and contextual HTML side by side differences (that this patch generated) are also included to assist in analyzing the differences and showing an example. (2) If this functionality is worthy of inclusion in the standard python distribution, I am willing to provide more documentation or make modifications to change the interface or make improvements. (3) When using Internet Explorer some font sizes seem to skew things a bit. Generally I've found the "smallest" to work best. If someone knows why, I'd be interested in making any necessary adjustments in the generated HTML. ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-04-28 23:30 Message: Logged In: YES user_id=995755 Also, I will need to submit the fix for making it behave nice when there are no differences!! ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-04-09 08:30 Message: Logged In: YES user_id=995755 In the time since submission I've found that the interface to the chgFmt and lineFmt functions (arguments of mdiff) should include both the line number and an indication of side (from/to). The use for it I've found is for dropping anchors into the generated markup that it can be hyperlinked from elsewhere. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914575&group_id=5470 From noreply at sourceforge.net Thu Jun 10 00:53:27 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jun 10 00:53:43 2004 Subject: [Patches] [ python-Patches-969791 ] Add nlargest() and nsmallest() to heapq. Message-ID: Patches item #969791, was opened at 2004-06-09 12:59 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=969791&group_id=5470 Category: Library (Lib) Group: Python 2.4 >Status: Closed Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Tim Peters (tim_one) Summary: Add nlargest() and nsmallest() to heapq. Initial Comment: This patch adds a function that encapsulates a principal use case for heaps, finding the n largest from a dataset without doing a full sort. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-06-09 23:53 Message: Logged In: YES user_id=80475 Taking this one back off Tim's busy plate. If I deluded myself with the attached tests, he can give me a hard time later ;-) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-06-09 18:41 Message: Logged In: YES user_id=80475 For many values of n, nsmallest() still makes substantially fewer comparisons than sort(). Attaching comparison count test suite. Here are the comparison counts for a list with a 1000 random entries and various values of n: 8649 sort 999 1 nlargest 1667 1 nsmallest 1088 5 nlargest 1709 5 nsmallest 1238 10 nlargest 1759 10 nsmallest 1487 20 nlargest 1860 20 nsmallest 2052 40 nlargest 2066 40 nsmallest 2953 80 nlargest 2466 80 nsmallest 4516 160 nlargest 3262 160 nsmallest 6835 320 nlargest 4811 320 nsmallest 9177 640 nlargest 7736 640 nsmallest 9742 1000 nlargest 10315 1000 nsmallest P.S. Using itertools, the nsmallest() can be made to run at C speed: def nsmallest(iterable, n): """Find the n smallest elements in a dataset. Equivalent to: sorted(iterable)[:n] """ h = list(iterable) heapify(h) return map(heappop, repeat(h, min(n, len(h)))) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-06-09 15:06 Message: Logged In: YES user_id=31435 +1 on nlargest(). -0 on nsmalles(), because it has radically different time and space requirements than nlargest() for the typical case (n is much less than the total # of elements). If the user can afford all that space, it will probably be faster for the user to sort a materialized list then peel off the first n. That's a simple one-liner. If so, that makes nsmallest an "attractive nuisance". If heapq had a more abstract interface, so that we had both min-heaps and max-heaps, this objection would of course go away. But we don't, so ... ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-06-09 14:00 Message: Logged In: YES user_id=80475 Revised the patch to also include nsmallest(). Note, the API intentionally does not provide default values of n. This is to encourage use of min() and sorted() for corner cases. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=969791&group_id=5470 From VXAKJO at silesianet.pl Thu Jun 10 03:46:10 2004 From: VXAKJO at silesianet.pl (VXAKJO@silesianet.pl) Date: Thu Jun 10 04:13:47 2004 Subject: [Patches] Augen auf! (So sieht es aus!) Message-ID: <1b8e02aff29c80.d961b.qmail@silesianet.pl> http://www.oliver-klas.de http://www.buergerbewegungen.de http://www.moschee-wertheim.de http://www.auslaendergewalt.ch http://www.rocknord.de http://www.NoTurkishmembership.com http://www.der-ruf-nach-freiheit.de http://www.Euronational.org http://www.pro-koeln-online.de http://www.leverkusener-aufbruch.com http://www.widerstand.com From noreply at sourceforge.net Thu Jun 10 07:13:59 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jun 10 07:14:06 2004 Subject: [Patches] [ python-Patches-970288 ] Fix for #876637 - Random stack corruption from socketmodule Message-ID: Patches item #970288, was opened at 2004-06-10 13:13 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=970288&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Troels Walsted Hansen (troels) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for #876637 - Random stack corruption from socketmodule Initial Comment: Here's a patch to convert socketmodule to use poll() for the timeout handling. ifdefs and includes have been copied from selectmodule, so I believe they should be correct for all platforms. Compiled and tested on Linux (RH73). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=970288&group_id=5470 From sthiel at pinnaclesys.com Thu Jun 10 06:55:32 2004 From: sthiel at pinnaclesys.com (sthiel@pinnaclesys.com) Date: Thu Jun 10 07:16:51 2004 Subject: [Patches] Auslaendergewalt: Herr Rau, wo waren Sie? Message-ID: <2219fba158b478.cfb83.qmail@pinnaclesys.com> Mordversuch wegen 'falschem' Hemdaufdruck! Wo waren Sie, Herr Rau? Wo blieben die Schlagzeilen der Massenmedien und der Tagesschau? SIEGBURG - Ein naechtlicher Stadtbummel dreier junger Deutscher in der Nacht vom 15.-16. Juni waere fuer einen der Jugendlichen fast toedlich ausgegangen. Die drei jungen Leute, 17, 18 und 21 Jahre alt, schlenderten ruhig und gut gelaunt nach Mitternacht von McDonalds kommend durch die Siegburger Innenstadt. Sie trugen die bei Jugendlichen beliebten Hemden mit Aufschriften (engldeutsch 'T-Shirt' genannt). Bei einem prangte 'Lieber Currywurst als Doener' auf der Brust, womit er wohl zeigen wollte, dass er als offenbar umerzogener Amideutscher in der multikulturellen Gesellschaft McDonald statt Doener bevorzugte. Doch diese Vorliebe haette er besser nicht so offen gezeigt. In der Fussgaengerzone kamen den Jugendlichen sieben bis acht auslaendische Mitbuerger der zweiten Generation - nach Polizeibericht mit 'suedlaendischem Aussehen, vermutlich tuerkischer Herkunft' - entgegen, denen diese Parole offenbar nicht gefiel und die sich wohl an den Aufruf des Herrn Bundeskanzlers Schroeder zum 'Aufstand der Anstaendigen' erinnerten. Mit lauten Rufen wie 'Heil Hitler' und 'Nazi-Deutsche' stuerzten sie sich auf die drei, laut Zeugenaussagen 'ohne erkennbaren Grund'. Waehrend die zwei Juengeren fliehen konnten, schaffte es der 21-jaehrige nicht. Weil ihm ein Bein gestellt wurde, stuerzte er, und die Gruppe schlug und trat auf ihn ein. Einer der Angreifer riss aus einer seitlichen Baumpflanzung einen zwei Meter langen Pflanzpfahl heraus und schlug ihn dem Opfer mehrfach auf den Kopf. Danach flohen die Angreifer, bevor die alarmierte Polizei eintraf. Der ueberfallene schwebte tagelang in Lebensgefahr, von den Taetern fehlt bislang jede Spur, obwohl die Polizei das Umfeld des Tatortes nach Spuren absuchte und die Bonner Mordkommission den Fall uebernommen hat. 'Ich bin erschrocken ueber das Ausmass an Brutalitaet, mit der da vorgegangen wurde', erklaerte Robert Scholten, Sprecher der Polizei in Bonn. Es sei zwar richtig, dass die drei Angegriffenen zur rechten Szene gehoerten, das koenne jedoch das Vorgehen der Angreifer in keiner Weise rechtfertigen. >Zitat<: WIR sind ueberhaupt nicht erschrocken, denn seit mehr als 20 Jahren wissen und warnen wir vor all solchen Folgen der 'multikulturellen Gesellschaft'. Dass weder der Herr Bundespraesident ans Bett des fast Erschlagenen eilte, noch die Massenmedien ueber diesen brutalen Mordversuch berichteten, entlarvt die Geisteshaltung des Herrn Rau und die Heuchelei der sogenannten 'Anstaendigen' bei den Massenmedien. Kommentar des Sober Autors: Wenn drei leicht angetrunkene Bundeswehr Soldaten mit A. H. Gruss durch die Stadt laufen, ist die Presse mit groesstem Eifer dabei, unsere eigenen Leute nieder zu machen!!! From iag at travelocity.com Thu Jun 10 09:25:16 2004 From: iag at travelocity.com (iag@travelocity.com) Date: Thu Jun 10 09:30:43 2004 Subject: [Patches] Die Deform der sozialen Ordnung Message-ID: <16a0d901e787e7.72807.qmail@travelocity.com> Lese selbst: http://www.fkun.de/UN-Nachrichten/UN-Ausgaben/2004/UN1-04/2004-01-1.htm From noreply at sourceforge.net Fri Jun 11 10:18:32 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jun 11 10:18:49 2004 Subject: [Patches] [ python-Patches-960406 ] unblock signals in threads Message-ID: Patches item #960406, was opened at 2004-05-25 22:00 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=960406&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Andrew Langmead (langmead) Assigned to: Nobody/Anonymous (nobody) Summary: unblock signals in threads Initial Comment: This is a patch which will correct the issues some people have with python's handling of signal handling in threads. It allows any thread to initially catch the signal mark it as triggered, allowing the main thread to later process it. (This is actually just restoring access to the functionality that was in Python 2.1) The special SIGINT handling for the python readline module has been changed so that it can now see an EINTR error code, rather than needing a longjmp out of the readline library itself. If the readline library python is being linked to doesn't have the callback features necessary, it will fall back to its old behavior. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2004-06-11 15:18 Message: Logged In: YES user_id=6656 The patch didn't apply, so I've updated it (attached). I see test_asynchat fail occasionally now, but don't know if that's because of this patch :-( Once I've sorted that out in my head, I think I'm going to check this in. ---------------------------------------------------------------------- Comment By: Andrew Langmead (langmead) Date: 2004-05-29 06:49 Message: Logged In: YES user_id=119306 Here is a reformatted version of the patch. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-05-28 15:25 Message: Logged In: YES user_id=31435 I agree that "busy" always should have been volatile -- once again, good eye! Python C style is basically K&R Classic, hard tab for indentation, open curly at the end of the line opening a block except for first line of function definition. Just make it look like the other C code, but be careful to pick one of the .c files Guido approves of . ---------------------------------------------------------------------- Comment By: Andrew Langmead (langmead) Date: 2004-05-28 13:37 Message: Logged In: YES user_id=119306 Thank you for pointing me to PEP 7. I'll take a look at where I am amiss and fix it up. For the change in ceval.c, I took a look at gcc's x86 assembly output of the file, and noticed that the optimizer was altering the order of the busy flag test. Since busy is set from other concurrent execution (other signal handlers), changing the variable to volatile told gcc not to optimize accesses to the variable. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-28 09:54 Message: Logged In: YES user_id=6656 I haven't been able to test on MacOS X further, unfortunately. The patch works on linux/x86 though (after fixing the TabError :-) but this is with an NTPL kernel, so I didn't have a problem anyway. The C doesn't all conform to the Python style -- see PEP 7. Can you fix that? Why the change to Python/ceval.c? After all that -- thanks a lot! I really want to get this checked in ASAP so we can find out which platforms it breaks at the earliest point in the 2.4 cycle. ---------------------------------------------------------------------- Comment By: Andrew Langmead (langmead) Date: 2004-05-27 07:04 Message: Logged In: YES user_id=119306 It seems that at least OS X, sending the kill to the process schedules that the receiving process will run the signal handler at some later time. (it seems to be the only one to frequently run the signal handlers in the opposite order than they were sent) This revised version of the test seems to work better on OS X. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-26 19:41 Message: Logged In: YES user_id=6656 test_threadsignals hangs for me on OS X. Haven't done anything more thorough than that yet... ---------------------------------------------------------------------- Comment By: Andrew Langmead (langmead) Date: 2004-05-26 18:48 Message: Logged In: YES user_id=119306 I apologize that the missing patch. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-26 18:22 Message: Logged In: YES user_id=6656 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. In addition, even if you *did* check this checkbox, a bug in SourceForge prevents attaching a file when *creating* an issue. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=960406&group_id=5470 From noreply at sourceforge.net Fri Jun 11 10:35:11 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jun 11 10:35:40 2004 Subject: [Patches] [ python-Patches-914575 ] difflib side by side diff support, diff.py s/b/s HTML option Message-ID: Patches item #914575, was opened at 2004-03-11 18:50 Message generated for change (Comment added) made by jimjjewett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914575&group_id=5470 Category: Modules Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: Dan Gass (dmgass) Assigned to: Raymond Hettinger (rhettinger) Summary: difflib side by side diff support, diff.py s/b/s HTML option Initial Comment: lib/difflib.py: Added support for generating side by side differences. Intended to be used for generating HTML pages but is generic where it can be used for other types of markup. tools/scripts/diff.py: Added -m option to use above patch to generate an HTML page of side by side differences between two files. The existing -c option when used with the new -m option controls whether contextual differences are shown or whether the entire file is displayed (number of context lines is controlled by existing -l option). NOTES: (1) Textual context diffs were included as requested. In addition, full and contextual HTML side by side differences (that this patch generated) are also included to assist in analyzing the differences and showing an example. (2) If this functionality is worthy of inclusion in the standard python distribution, I am willing to provide more documentation or make modifications to change the interface or make improvements. (3) When using Internet Explorer some font sizes seem to skew things a bit. Generally I've found the "smallest" to work best. If someone knows why, I'd be interested in making any necessary adjustments in the generated HTML. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2004-06-11 10:35 Message: Logged In: YES user_id=764593 Thank you; I have often wished for side-by-side, but not quite badly enough to write it. That said, I would recommend some tweaks to the formatting. "font" is deprecated; "span" would be better. On my display, the "next" lines don't always seem to be counted (except the first one), so that the anchors column is not lined up with the others. (This would also be fixed by the separate rows suggestion.) Ideally, the line numbers would be in a separate column from the code, to make cut'n'paste easier. (Then you could replace font.num (or span.num) with td.linenum.) Ideally, each change group should be a separate row in the table. (I realize that this probably means a two-layer iterator, so that the line breaks and blank lines can be inserted correctly in the code columns.) ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-04-29 00:30 Message: Logged In: YES user_id=995755 Also, I will need to submit the fix for making it behave nice when there are no differences!! ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-04-09 09:30 Message: Logged In: YES user_id=995755 In the time since submission I've found that the interface to the chgFmt and lineFmt functions (arguments of mdiff) should include both the line number and an indication of side (from/to). The use for it I've found is for dropping anchors into the generated markup that it can be hyperlinked from elsewhere. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914575&group_id=5470 From noreply at sourceforge.net Fri Jun 11 11:58:08 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jun 11 11:58:23 2004 Subject: [Patches] [ python-Patches-960406 ] unblock signals in threads Message-ID: Patches item #960406, was opened at 2004-05-26 07:00 Message generated for change (Comment added) made by anthonybaxter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=960406&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Andrew Langmead (langmead) Assigned to: Nobody/Anonymous (nobody) Summary: unblock signals in threads Initial Comment: This is a patch which will correct the issues some people have with python's handling of signal handling in threads. It allows any thread to initially catch the signal mark it as triggered, allowing the main thread to later process it. (This is actually just restoring access to the functionality that was in Python 2.1) The special SIGINT handling for the python readline module has been changed so that it can now see an EINTR error code, rather than needing a longjmp out of the readline library itself. If the readline library python is being linked to doesn't have the callback features necessary, it will fall back to its old behavior. ---------------------------------------------------------------------- >Comment By: Anthony Baxter (anthonybaxter) Date: 2004-06-12 01:58 Message: Logged In: YES user_id=29957 With this patch: bonanza% ./python Lib/test/test_timeout.py testBlockingThenTimeout (__main__.CreationTestCase) ... ok testFloatReturnValue (__main__.CreationTestCase) ... ok testObjectCreation (__main__.CreationTestCase) ... ok testRangeCheck (__main__.CreationTestCase) ... ok testReturnType (__main__.CreationTestCase) ... ok testTimeoutThenBlocking (__main__.CreationTestCase) ... ok testTypeCheck (__main__.CreationTestCase) ... ok testAcceptTimeout (__main__.TimeoutTestCase) ... ok testConnectTimeout (__main__.TimeoutTestCase) ... FAIL testRecvTimeout (__main__.TimeoutTestCase) ... ok testRecvfromTimeout (__main__.TimeoutTestCase) ... ok testSend (__main__.TimeoutTestCase) ... ok testSendall (__main__.TimeoutTestCase) ... ok testSendto (__main__.TimeoutTestCase) ... ok ====================================================================== FAIL: testConnectTimeout (__main__.TimeoutTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "Lib/test/test_timeout.py", line 121, in testConnectTimeout "timeout (%g) is more than %g seconds more than expected (%g)" AssertionError: timeout (4.48679) is more than 2 seconds more than expected (0.001) ---------------------------------------------------------------------- Ran 14 tests in 17.445s FAILED (failures=1) Traceback (most recent call last): File "Lib/test/test_timeout.py", line 192, in ? test_main() File "Lib/test/test_timeout.py", line 189, in test_main test_support.run_unittest(CreationTestCase, TimeoutTestCase) File "/home/anthony/src/py/pyhead/dist/src/Lib/test/test_support.py", line 290, in run_unittest run_suite(suite, testclass) File "/home/anthony/src/py/pyhead/dist/src/Lib/test/test_support.py", line 275, in run_suite raise TestFailed(err) test.test_support.TestFailed: Traceback (most recent call last): File "Lib/test/test_timeout.py", line 121, in testConnectTimeout "timeout (%g) is more than %g seconds more than expected (%g)" AssertionError: timeout (4.48679) is more than 2 seconds more than expected (0.001) Also, with this patch applied, I can no longer kill a 'make testall' with a ^C ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-12 00:18 Message: Logged In: YES user_id=6656 The patch didn't apply, so I've updated it (attached). I see test_asynchat fail occasionally now, but don't know if that's because of this patch :-( Once I've sorted that out in my head, I think I'm going to check this in. ---------------------------------------------------------------------- Comment By: Andrew Langmead (langmead) Date: 2004-05-29 15:49 Message: Logged In: YES user_id=119306 Here is a reformatted version of the patch. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-05-29 00:25 Message: Logged In: YES user_id=31435 I agree that "busy" always should have been volatile -- once again, good eye! Python C style is basically K&R Classic, hard tab for indentation, open curly at the end of the line opening a block except for first line of function definition. Just make it look like the other C code, but be careful to pick one of the .c files Guido approves of . ---------------------------------------------------------------------- Comment By: Andrew Langmead (langmead) Date: 2004-05-28 22:37 Message: Logged In: YES user_id=119306 Thank you for pointing me to PEP 7. I'll take a look at where I am amiss and fix it up. For the change in ceval.c, I took a look at gcc's x86 assembly output of the file, and noticed that the optimizer was altering the order of the busy flag test. Since busy is set from other concurrent execution (other signal handlers), changing the variable to volatile told gcc not to optimize accesses to the variable. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-28 18:54 Message: Logged In: YES user_id=6656 I haven't been able to test on MacOS X further, unfortunately. The patch works on linux/x86 though (after fixing the TabError :-) but this is with an NTPL kernel, so I didn't have a problem anyway. The C doesn't all conform to the Python style -- see PEP 7. Can you fix that? Why the change to Python/ceval.c? After all that -- thanks a lot! I really want to get this checked in ASAP so we can find out which platforms it breaks at the earliest point in the 2.4 cycle. ---------------------------------------------------------------------- Comment By: Andrew Langmead (langmead) Date: 2004-05-27 16:04 Message: Logged In: YES user_id=119306 It seems that at least OS X, sending the kill to the process schedules that the receiving process will run the signal handler at some later time. (it seems to be the only one to frequently run the signal handlers in the opposite order than they were sent) This revised version of the test seems to work better on OS X. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-27 04:41 Message: Logged In: YES user_id=6656 test_threadsignals hangs for me on OS X. Haven't done anything more thorough than that yet... ---------------------------------------------------------------------- Comment By: Andrew Langmead (langmead) Date: 2004-05-27 03:48 Message: Logged In: YES user_id=119306 I apologize that the missing patch. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-27 03:22 Message: Logged In: YES user_id=6656 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. In addition, even if you *did* check this checkbox, a bug in SourceForge prevents attaching a file when *creating* an issue. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=960406&group_id=5470 From noreply at sourceforge.net Fri Jun 11 12:02:06 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jun 11 12:02:13 2004 Subject: [Patches] [ python-Patches-960406 ] unblock signals in threads Message-ID: Patches item #960406, was opened at 2004-05-26 07:00 Message generated for change (Comment added) made by anthonybaxter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=960406&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Andrew Langmead (langmead) Assigned to: Nobody/Anonymous (nobody) Summary: unblock signals in threads Initial Comment: This is a patch which will correct the issues some people have with python's handling of signal handling in threads. It allows any thread to initially catch the signal mark it as triggered, allowing the main thread to later process it. (This is actually just restoring access to the functionality that was in Python 2.1) The special SIGINT handling for the python readline module has been changed so that it can now see an EINTR error code, rather than needing a longjmp out of the readline library itself. If the readline library python is being linked to doesn't have the callback features necessary, it will fall back to its old behavior. ---------------------------------------------------------------------- >Comment By: Anthony Baxter (anthonybaxter) Date: 2004-06-12 02:02 Message: Logged In: YES user_id=29957 No - wait. Ignore that test_timeout error, it exists with a clean checkout. The inability to interrupt make testall, however is new with this patch. Linux Fedora Core 2. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-06-12 01:58 Message: Logged In: YES user_id=29957 With this patch: bonanza% ./python Lib/test/test_timeout.py testBlockingThenTimeout (__main__.CreationTestCase) ... ok testFloatReturnValue (__main__.CreationTestCase) ... ok testObjectCreation (__main__.CreationTestCase) ... ok testRangeCheck (__main__.CreationTestCase) ... ok testReturnType (__main__.CreationTestCase) ... ok testTimeoutThenBlocking (__main__.CreationTestCase) ... ok testTypeCheck (__main__.CreationTestCase) ... ok testAcceptTimeout (__main__.TimeoutTestCase) ... ok testConnectTimeout (__main__.TimeoutTestCase) ... FAIL testRecvTimeout (__main__.TimeoutTestCase) ... ok testRecvfromTimeout (__main__.TimeoutTestCase) ... ok testSend (__main__.TimeoutTestCase) ... ok testSendall (__main__.TimeoutTestCase) ... ok testSendto (__main__.TimeoutTestCase) ... ok ====================================================================== FAIL: testConnectTimeout (__main__.TimeoutTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "Lib/test/test_timeout.py", line 121, in testConnectTimeout "timeout (%g) is more than %g seconds more than expected (%g)" AssertionError: timeout (4.48679) is more than 2 seconds more than expected (0.001) ---------------------------------------------------------------------- Ran 14 tests in 17.445s FAILED (failures=1) Traceback (most recent call last): File "Lib/test/test_timeout.py", line 192, in ? test_main() File "Lib/test/test_timeout.py", line 189, in test_main test_support.run_unittest(CreationTestCase, TimeoutTestCase) File "/home/anthony/src/py/pyhead/dist/src/Lib/test/test_support.py", line 290, in run_unittest run_suite(suite, testclass) File "/home/anthony/src/py/pyhead/dist/src/Lib/test/test_support.py", line 275, in run_suite raise TestFailed(err) test.test_support.TestFailed: Traceback (most recent call last): File "Lib/test/test_timeout.py", line 121, in testConnectTimeout "timeout (%g) is more than %g seconds more than expected (%g)" AssertionError: timeout (4.48679) is more than 2 seconds more than expected (0.001) Also, with this patch applied, I can no longer kill a 'make testall' with a ^C ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-12 00:18 Message: Logged In: YES user_id=6656 The patch didn't apply, so I've updated it (attached). I see test_asynchat fail occasionally now, but don't know if that's because of this patch :-( Once I've sorted that out in my head, I think I'm going to check this in. ---------------------------------------------------------------------- Comment By: Andrew Langmead (langmead) Date: 2004-05-29 15:49 Message: Logged In: YES user_id=119306 Here is a reformatted version of the patch. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-05-29 00:25 Message: Logged In: YES user_id=31435 I agree that "busy" always should have been volatile -- once again, good eye! Python C style is basically K&R Classic, hard tab for indentation, open curly at the end of the line opening a block except for first line of function definition. Just make it look like the other C code, but be careful to pick one of the .c files Guido approves of . ---------------------------------------------------------------------- Comment By: Andrew Langmead (langmead) Date: 2004-05-28 22:37 Message: Logged In: YES user_id=119306 Thank you for pointing me to PEP 7. I'll take a look at where I am amiss and fix it up. For the change in ceval.c, I took a look at gcc's x86 assembly output of the file, and noticed that the optimizer was altering the order of the busy flag test. Since busy is set from other concurrent execution (other signal handlers), changing the variable to volatile told gcc not to optimize accesses to the variable. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-28 18:54 Message: Logged In: YES user_id=6656 I haven't been able to test on MacOS X further, unfortunately. The patch works on linux/x86 though (after fixing the TabError :-) but this is with an NTPL kernel, so I didn't have a problem anyway. The C doesn't all conform to the Python style -- see PEP 7. Can you fix that? Why the change to Python/ceval.c? After all that -- thanks a lot! I really want to get this checked in ASAP so we can find out which platforms it breaks at the earliest point in the 2.4 cycle. ---------------------------------------------------------------------- Comment By: Andrew Langmead (langmead) Date: 2004-05-27 16:04 Message: Logged In: YES user_id=119306 It seems that at least OS X, sending the kill to the process schedules that the receiving process will run the signal handler at some later time. (it seems to be the only one to frequently run the signal handlers in the opposite order than they were sent) This revised version of the test seems to work better on OS X. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-27 04:41 Message: Logged In: YES user_id=6656 test_threadsignals hangs for me on OS X. Haven't done anything more thorough than that yet... ---------------------------------------------------------------------- Comment By: Andrew Langmead (langmead) Date: 2004-05-27 03:48 Message: Logged In: YES user_id=119306 I apologize that the missing patch. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-27 03:22 Message: Logged In: YES user_id=6656 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. In addition, even if you *did* check this checkbox, a bug in SourceForge prevents attaching a file when *creating* an issue. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=960406&group_id=5470 From noreply at sourceforge.net Fri Jun 11 12:31:20 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jun 11 12:31:31 2004 Subject: [Patches] [ python-Patches-957240 ] Patch for feature request 491033 Message-ID: Patches item #957240, was opened at 2004-05-20 07:23 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=957240&group_id=5470 Category: None Group: None Status: Closed Resolution: Accepted Priority: 6 Submitted By: Josiah Carlson (josiahcarlson) Assigned to: Martin v. L?wis (loewis) Summary: Patch for feature request 491033 Initial Comment: The attached patch is to offer the functionality desired by feature request: python.org/sf/491033 On machines that use standard IEEE floating point doubles, the 'infinity' needs only to be 1e16 due to the limited precision of floating point. 1e309 is used for convenience sake, and will continue to be a precision infinity until 1024 bits of precision in floating point values is available. At such point in time where 1e309 is available in hardware, it will still sufficient due to the practical limitations of counting. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2004-06-11 17:31 Message: Logged In: YES user_id=6656 This patch should not have been accepted. Relying on a floating point infinity to marhsal/unmarshal correctly is a bad idea. With the aid of the LC_NUMERIC agnostism patch, this patch breaks test_asynchat *when asyncore.pyc exists*. I don't have a windows machine with a CVS HEAD Python to check, but if 2.3 behaviour is retained, the upshot is that the count parameter will default to *1* if the code is loaded from a .pyc file. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-06-03 10:19 Message: Logged In: YES user_id=21627 Thanks for the patch. Applied as libasyncore.tex 1.15 asyncore.py 1.51 NEWS 1.986 ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-05-31 21:36 Message: Logged In: YES user_id=341410 The attached patch includes both a documentation patch, as well as a modified loop patch to explicitly match the documentation. The patches are concatenated and in standard context diff format (as per the Python patch submission guidelines, sorry about the previous unified diff). The test suite does not seem to contain tests for asyncore. It does contain a test for asynchat, which will be unaffected by this patch. One thing to note: the use of 'count = count - 1' rather than 'count -= 1' is to remove potential bugs in the case where a mutable number-like object with a modifying __isub__ method were to be passed by a user. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-05-31 19:32 Message: Logged In: YES user_id=21627 This patch lacks changes to the documentation and the test suite. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-05-20 07:26 Message: Logged In: YES user_id=341410 Sorry about that, I generated the patch by hand and got the ordering messed up. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=957240&group_id=5470 From noreply at sourceforge.net Fri Jun 11 13:55:14 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jun 11 13:55:20 2004 Subject: [Patches] [ python-Patches-971323 ] make test_signal less annoying Message-ID: Patches item #971323, was opened at 2004-06-11 18:55 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=971323&group_id=5470 Category: Tests Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Anthony Baxter (anthonybaxter) Summary: make test_signal less annoying Initial Comment: test_signal seems to go out of it's way to use signals that are actually useful (SIGINT & SIGQUIT). this patch stops that & attempts to restore signal actions after the test runs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=971323&group_id=5470 From noreply at sourceforge.net Fri Jun 11 14:10:01 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jun 11 14:10:56 2004 Subject: [Patches] [ python-Patches-971323 ] make test_signal less annoying Message-ID: Patches item #971323, was opened at 2004-06-11 18:55 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=971323&group_id=5470 Category: Tests Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Anthony Baxter (anthonybaxter) Summary: make test_signal less annoying Initial Comment: test_signal seems to go out of it's way to use signals that are actually useful (SIGINT & SIGQUIT). this patch stops that & attempts to restore signal actions after the test runs. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2004-06-11 19:10 Message: Logged In: YES user_id=6656 check in after comments on irc. revision 1.15 of Lib/test/ test_signal.py. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=971323&group_id=5470 From noreply at sourceforge.net Fri Jun 11 14:13:58 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jun 11 14:14:06 2004 Subject: [Patches] [ python-Patches-971323 ] make test_signal less annoying Message-ID: Patches item #971323, was opened at 2004-06-11 18:55 Message generated for change (Settings changed) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=971323&group_id=5470 Category: Tests Group: Python 2.4 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Anthony Baxter (anthonybaxter) Summary: make test_signal less annoying Initial Comment: test_signal seems to go out of it's way to use signals that are actually useful (SIGINT & SIGQUIT). this patch stops that & attempts to restore signal actions after the test runs. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-11 19:10 Message: Logged In: YES user_id=6656 check in after comments on irc. revision 1.15 of Lib/test/ test_signal.py. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=971323&group_id=5470 From noreply at sourceforge.net Fri Jun 11 17:54:39 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jun 11 17:54:48 2004 Subject: [Patches] [ python-Patches-957240 ] Patch for feature request 491033 Message-ID: Patches item #957240, was opened at 2004-05-19 23:23 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=957240&group_id=5470 Category: None Group: None Status: Closed Resolution: Accepted Priority: 6 Submitted By: Josiah Carlson (josiahcarlson) Assigned to: Martin v. L?wis (loewis) Summary: Patch for feature request 491033 Initial Comment: The attached patch is to offer the functionality desired by feature request: python.org/sf/491033 On machines that use standard IEEE floating point doubles, the 'infinity' needs only to be 1e16 due to the limited precision of floating point. 1e309 is used for convenience sake, and will continue to be a precision infinity until 1024 bits of precision in floating point values is available. At such point in time where 1e309 is available in hardware, it will still sufficient due to the practical limitations of counting. ---------------------------------------------------------------------- >Comment By: Josiah Carlson (josiahcarlson) Date: 2004-06-11 14:54 Message: Logged In: YES user_id=341410 If it would be preferred, I have an alternate patch against 1.50 from CVS that uses None instead of floating point infinity. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-11 09:31 Message: Logged In: YES user_id=6656 This patch should not have been accepted. Relying on a floating point infinity to marhsal/unmarshal correctly is a bad idea. With the aid of the LC_NUMERIC agnostism patch, this patch breaks test_asynchat *when asyncore.pyc exists*. I don't have a windows machine with a CVS HEAD Python to check, but if 2.3 behaviour is retained, the upshot is that the count parameter will default to *1* if the code is loaded from a .pyc file. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-06-03 02:19 Message: Logged In: YES user_id=21627 Thanks for the patch. Applied as libasyncore.tex 1.15 asyncore.py 1.51 NEWS 1.986 ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-05-31 13:36 Message: Logged In: YES user_id=341410 The attached patch includes both a documentation patch, as well as a modified loop patch to explicitly match the documentation. The patches are concatenated and in standard context diff format (as per the Python patch submission guidelines, sorry about the previous unified diff). The test suite does not seem to contain tests for asyncore. It does contain a test for asynchat, which will be unaffected by this patch. One thing to note: the use of 'count = count - 1' rather than 'count -= 1' is to remove potential bugs in the case where a mutable number-like object with a modifying __isub__ method were to be passed by a user. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-05-31 11:32 Message: Logged In: YES user_id=21627 This patch lacks changes to the documentation and the test suite. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-05-19 23:26 Message: Logged In: YES user_id=341410 Sorry about that, I generated the patch by hand and got the ordering messed up. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=957240&group_id=5470 From noreply at sourceforge.net Sat Jun 12 04:53:34 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jun 12 04:53:45 2004 Subject: [Patches] [ python-Patches-957240 ] Patch for feature request 491033 Message-ID: Patches item #957240, was opened at 2004-05-20 07:23 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=957240&group_id=5470 Category: None Group: None >Status: Open Resolution: Accepted Priority: 6 Submitted By: Josiah Carlson (josiahcarlson) Assigned to: Martin v. L?wis (loewis) Summary: Patch for feature request 491033 Initial Comment: The attached patch is to offer the functionality desired by feature request: python.org/sf/491033 On machines that use standard IEEE floating point doubles, the 'infinity' needs only to be 1e16 due to the limited precision of floating point. 1e309 is used for convenience sake, and will continue to be a precision infinity until 1024 bits of precision in floating point values is available. At such point in time where 1e309 is available in hardware, it will still sufficient due to the practical limitations of counting. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2004-06-12 09:53 Message: Logged In: YES user_id=6656 um, "yes". what's in CVS currently is not going to be there for very long. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-06-11 22:54 Message: Logged In: YES user_id=341410 If it would be preferred, I have an alternate patch against 1.50 from CVS that uses None instead of floating point infinity. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-11 17:31 Message: Logged In: YES user_id=6656 This patch should not have been accepted. Relying on a floating point infinity to marhsal/unmarshal correctly is a bad idea. With the aid of the LC_NUMERIC agnostism patch, this patch breaks test_asynchat *when asyncore.pyc exists*. I don't have a windows machine with a CVS HEAD Python to check, but if 2.3 behaviour is retained, the upshot is that the count parameter will default to *1* if the code is loaded from a .pyc file. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-06-03 10:19 Message: Logged In: YES user_id=21627 Thanks for the patch. Applied as libasyncore.tex 1.15 asyncore.py 1.51 NEWS 1.986 ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-05-31 21:36 Message: Logged In: YES user_id=341410 The attached patch includes both a documentation patch, as well as a modified loop patch to explicitly match the documentation. The patches are concatenated and in standard context diff format (as per the Python patch submission guidelines, sorry about the previous unified diff). The test suite does not seem to contain tests for asyncore. It does contain a test for asynchat, which will be unaffected by this patch. One thing to note: the use of 'count = count - 1' rather than 'count -= 1' is to remove potential bugs in the case where a mutable number-like object with a modifying __isub__ method were to be passed by a user. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-05-31 19:32 Message: Logged In: YES user_id=21627 This patch lacks changes to the documentation and the test suite. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-05-20 07:26 Message: Logged In: YES user_id=341410 Sorry about that, I generated the patch by hand and got the ordering messed up. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=957240&group_id=5470 From noreply at sourceforge.net Sat Jun 12 06:08:52 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jun 12 06:09:26 2004 Subject: [Patches] [ python-Patches-960406 ] unblock signals in threads Message-ID: Patches item #960406, was opened at 2004-05-25 22:00 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=960406&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Andrew Langmead (langmead) Assigned to: Nobody/Anonymous (nobody) Summary: unblock signals in threads Initial Comment: This is a patch which will correct the issues some people have with python's handling of signal handling in threads. It allows any thread to initially catch the signal mark it as triggered, allowing the main thread to later process it. (This is actually just restoring access to the functionality that was in Python 2.1) The special SIGINT handling for the python readline module has been changed so that it can now see an EINTR error code, rather than needing a longjmp out of the readline library itself. If the readline library python is being linked to doesn't have the callback features necessary, it will fall back to its old behavior. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2004-06-12 11:08 Message: Logged In: YES user_id=6656 Here's a version of the patch that includes the new unit test (oops!) which I've rewritten slightly. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-06-11 17:02 Message: Logged In: YES user_id=29957 No - wait. Ignore that test_timeout error, it exists with a clean checkout. The inability to interrupt make testall, however is new with this patch. Linux Fedora Core 2. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-06-11 16:58 Message: Logged In: YES user_id=29957 With this patch: bonanza% ./python Lib/test/test_timeout.py testBlockingThenTimeout (__main__.CreationTestCase) ... ok testFloatReturnValue (__main__.CreationTestCase) ... ok testObjectCreation (__main__.CreationTestCase) ... ok testRangeCheck (__main__.CreationTestCase) ... ok testReturnType (__main__.CreationTestCase) ... ok testTimeoutThenBlocking (__main__.CreationTestCase) ... ok testTypeCheck (__main__.CreationTestCase) ... ok testAcceptTimeout (__main__.TimeoutTestCase) ... ok testConnectTimeout (__main__.TimeoutTestCase) ... FAIL testRecvTimeout (__main__.TimeoutTestCase) ... ok testRecvfromTimeout (__main__.TimeoutTestCase) ... ok testSend (__main__.TimeoutTestCase) ... ok testSendall (__main__.TimeoutTestCase) ... ok testSendto (__main__.TimeoutTestCase) ... ok ====================================================================== FAIL: testConnectTimeout (__main__.TimeoutTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "Lib/test/test_timeout.py", line 121, in testConnectTimeout "timeout (%g) is more than %g seconds more than expected (%g)" AssertionError: timeout (4.48679) is more than 2 seconds more than expected (0.001) ---------------------------------------------------------------------- Ran 14 tests in 17.445s FAILED (failures=1) Traceback (most recent call last): File "Lib/test/test_timeout.py", line 192, in ? test_main() File "Lib/test/test_timeout.py", line 189, in test_main test_support.run_unittest(CreationTestCase, TimeoutTestCase) File "/home/anthony/src/py/pyhead/dist/src/Lib/test/test_support.py", line 290, in run_unittest run_suite(suite, testclass) File "/home/anthony/src/py/pyhead/dist/src/Lib/test/test_support.py", line 275, in run_suite raise TestFailed(err) test.test_support.TestFailed: Traceback (most recent call last): File "Lib/test/test_timeout.py", line 121, in testConnectTimeout "timeout (%g) is more than %g seconds more than expected (%g)" AssertionError: timeout (4.48679) is more than 2 seconds more than expected (0.001) Also, with this patch applied, I can no longer kill a 'make testall' with a ^C ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-11 15:18 Message: Logged In: YES user_id=6656 The patch didn't apply, so I've updated it (attached). I see test_asynchat fail occasionally now, but don't know if that's because of this patch :-( Once I've sorted that out in my head, I think I'm going to check this in. ---------------------------------------------------------------------- Comment By: Andrew Langmead (langmead) Date: 2004-05-29 06:49 Message: Logged In: YES user_id=119306 Here is a reformatted version of the patch. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-05-28 15:25 Message: Logged In: YES user_id=31435 I agree that "busy" always should have been volatile -- once again, good eye! Python C style is basically K&R Classic, hard tab for indentation, open curly at the end of the line opening a block except for first line of function definition. Just make it look like the other C code, but be careful to pick one of the .c files Guido approves of . ---------------------------------------------------------------------- Comment By: Andrew Langmead (langmead) Date: 2004-05-28 13:37 Message: Logged In: YES user_id=119306 Thank you for pointing me to PEP 7. I'll take a look at where I am amiss and fix it up. For the change in ceval.c, I took a look at gcc's x86 assembly output of the file, and noticed that the optimizer was altering the order of the busy flag test. Since busy is set from other concurrent execution (other signal handlers), changing the variable to volatile told gcc not to optimize accesses to the variable. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-28 09:54 Message: Logged In: YES user_id=6656 I haven't been able to test on MacOS X further, unfortunately. The patch works on linux/x86 though (after fixing the TabError :-) but this is with an NTPL kernel, so I didn't have a problem anyway. The C doesn't all conform to the Python style -- see PEP 7. Can you fix that? Why the change to Python/ceval.c? After all that -- thanks a lot! I really want to get this checked in ASAP so we can find out which platforms it breaks at the earliest point in the 2.4 cycle. ---------------------------------------------------------------------- Comment By: Andrew Langmead (langmead) Date: 2004-05-27 07:04 Message: Logged In: YES user_id=119306 It seems that at least OS X, sending the kill to the process schedules that the receiving process will run the signal handler at some later time. (it seems to be the only one to frequently run the signal handlers in the opposite order than they were sent) This revised version of the test seems to work better on OS X. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-26 19:41 Message: Logged In: YES user_id=6656 test_threadsignals hangs for me on OS X. Haven't done anything more thorough than that yet... ---------------------------------------------------------------------- Comment By: Andrew Langmead (langmead) Date: 2004-05-26 18:48 Message: Logged In: YES user_id=119306 I apologize that the missing patch. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-26 18:22 Message: Logged In: YES user_id=6656 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. In addition, even if you *did* check this checkbox, a bug in SourceForge prevents attaching a file when *creating* an issue. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=960406&group_id=5470 From noreply at sourceforge.net Sat Jun 12 06:17:35 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jun 12 06:17:56 2004 Subject: [Patches] [ python-Patches-960406 ] unblock signals in threads Message-ID: Patches item #960406, was opened at 2004-05-25 22:00 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=960406&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Andrew Langmead (langmead) Assigned to: Nobody/Anonymous (nobody) Summary: unblock signals in threads Initial Comment: This is a patch which will correct the issues some people have with python's handling of signal handling in threads. It allows any thread to initially catch the signal mark it as triggered, allowing the main thread to later process it. (This is actually just restoring access to the functionality that was in Python 2.1) The special SIGINT handling for the python readline module has been changed so that it can now see an EINTR error code, rather than needing a longjmp out of the readline library itself. If the readline library python is being linked to doesn't have the callback features necessary, it will fall back to its old behavior. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2004-06-12 11:17 Message: Logged In: YES user_id=6656 Now a rewrite of the test that actually works! ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-12 11:08 Message: Logged In: YES user_id=6656 Here's a version of the patch that includes the new unit test (oops!) which I've rewritten slightly. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-06-11 17:02 Message: Logged In: YES user_id=29957 No - wait. Ignore that test_timeout error, it exists with a clean checkout. The inability to interrupt make testall, however is new with this patch. Linux Fedora Core 2. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-06-11 16:58 Message: Logged In: YES user_id=29957 With this patch: bonanza% ./python Lib/test/test_timeout.py testBlockingThenTimeout (__main__.CreationTestCase) ... ok testFloatReturnValue (__main__.CreationTestCase) ... ok testObjectCreation (__main__.CreationTestCase) ... ok testRangeCheck (__main__.CreationTestCase) ... ok testReturnType (__main__.CreationTestCase) ... ok testTimeoutThenBlocking (__main__.CreationTestCase) ... ok testTypeCheck (__main__.CreationTestCase) ... ok testAcceptTimeout (__main__.TimeoutTestCase) ... ok testConnectTimeout (__main__.TimeoutTestCase) ... FAIL testRecvTimeout (__main__.TimeoutTestCase) ... ok testRecvfromTimeout (__main__.TimeoutTestCase) ... ok testSend (__main__.TimeoutTestCase) ... ok testSendall (__main__.TimeoutTestCase) ... ok testSendto (__main__.TimeoutTestCase) ... ok ====================================================================== FAIL: testConnectTimeout (__main__.TimeoutTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "Lib/test/test_timeout.py", line 121, in testConnectTimeout "timeout (%g) is more than %g seconds more than expected (%g)" AssertionError: timeout (4.48679) is more than 2 seconds more than expected (0.001) ---------------------------------------------------------------------- Ran 14 tests in 17.445s FAILED (failures=1) Traceback (most recent call last): File "Lib/test/test_timeout.py", line 192, in ? test_main() File "Lib/test/test_timeout.py", line 189, in test_main test_support.run_unittest(CreationTestCase, TimeoutTestCase) File "/home/anthony/src/py/pyhead/dist/src/Lib/test/test_support.py", line 290, in run_unittest run_suite(suite, testclass) File "/home/anthony/src/py/pyhead/dist/src/Lib/test/test_support.py", line 275, in run_suite raise TestFailed(err) test.test_support.TestFailed: Traceback (most recent call last): File "Lib/test/test_timeout.py", line 121, in testConnectTimeout "timeout (%g) is more than %g seconds more than expected (%g)" AssertionError: timeout (4.48679) is more than 2 seconds more than expected (0.001) Also, with this patch applied, I can no longer kill a 'make testall' with a ^C ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-11 15:18 Message: Logged In: YES user_id=6656 The patch didn't apply, so I've updated it (attached). I see test_asynchat fail occasionally now, but don't know if that's because of this patch :-( Once I've sorted that out in my head, I think I'm going to check this in. ---------------------------------------------------------------------- Comment By: Andrew Langmead (langmead) Date: 2004-05-29 06:49 Message: Logged In: YES user_id=119306 Here is a reformatted version of the patch. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-05-28 15:25 Message: Logged In: YES user_id=31435 I agree that "busy" always should have been volatile -- once again, good eye! Python C style is basically K&R Classic, hard tab for indentation, open curly at the end of the line opening a block except for first line of function definition. Just make it look like the other C code, but be careful to pick one of the .c files Guido approves of . ---------------------------------------------------------------------- Comment By: Andrew Langmead (langmead) Date: 2004-05-28 13:37 Message: Logged In: YES user_id=119306 Thank you for pointing me to PEP 7. I'll take a look at where I am amiss and fix it up. For the change in ceval.c, I took a look at gcc's x86 assembly output of the file, and noticed that the optimizer was altering the order of the busy flag test. Since busy is set from other concurrent execution (other signal handlers), changing the variable to volatile told gcc not to optimize accesses to the variable. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-28 09:54 Message: Logged In: YES user_id=6656 I haven't been able to test on MacOS X further, unfortunately. The patch works on linux/x86 though (after fixing the TabError :-) but this is with an NTPL kernel, so I didn't have a problem anyway. The C doesn't all conform to the Python style -- see PEP 7. Can you fix that? Why the change to Python/ceval.c? After all that -- thanks a lot! I really want to get this checked in ASAP so we can find out which platforms it breaks at the earliest point in the 2.4 cycle. ---------------------------------------------------------------------- Comment By: Andrew Langmead (langmead) Date: 2004-05-27 07:04 Message: Logged In: YES user_id=119306 It seems that at least OS X, sending the kill to the process schedules that the receiving process will run the signal handler at some later time. (it seems to be the only one to frequently run the signal handlers in the opposite order than they were sent) This revised version of the test seems to work better on OS X. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-26 19:41 Message: Logged In: YES user_id=6656 test_threadsignals hangs for me on OS X. Haven't done anything more thorough than that yet... ---------------------------------------------------------------------- Comment By: Andrew Langmead (langmead) Date: 2004-05-26 18:48 Message: Logged In: YES user_id=119306 I apologize that the missing patch. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-26 18:22 Message: Logged In: YES user_id=6656 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. In addition, even if you *did* check this checkbox, a bug in SourceForge prevents attaching a file when *creating* an issue. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=960406&group_id=5470 From noreply at sourceforge.net Sun Jun 13 16:45:29 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jun 13 16:45:34 2004 Subject: [Patches] [ python-Patches-969180 ] hotshot incorrectly computes elapsed time Message-ID: Patches item #969180, was opened at 2004-06-08 16:13 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=969180&group_id=5470 Category: Modules Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Jason Beardsley (vaxhacker) >Assigned to: Neal Norwitz (nnorwitz) Summary: hotshot incorrectly computes elapsed time Initial Comment: In _hotshot.c, function get_tdelta(), there is an error resulting in incorrect timing results when the seconds field changes between the last recorded time and the current time of day. The previous time's microseconds are not accounted for (i.e. subtracted out). ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2004-06-13 16:45 Message: Logged In: YES user_id=33168 Checked in a slightly modified version as Modules/_hotshot.c 1.36 Also fixed a problem with time going backwards. Thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=969180&group_id=5470 From noreply at sourceforge.net Sun Jun 13 16:56:39 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jun 13 16:56:45 2004 Subject: [Patches] [ python-Patches-967763 ] fix bsddb memory leaks Message-ID: Patches item #967763, was opened at 2004-06-06 16:51 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=967763&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) >Assigned to: Gregory P. Smith (greg) Summary: fix bsddb memory leaks Initial Comment: only one of the changes fixed a leak reported by valgrind, but i think all the changes are necessary. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2004-06-13 16:56 Message: Logged In: YES user_id=33168 Greg, just wanted to make sure you saw this. It seems like you're the only one working on bsddb these days. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=967763&group_id=5470 From noreply at sourceforge.net Sun Jun 13 17:04:54 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jun 13 17:04:58 2004 Subject: [Patches] [ python-Patches-969907 ] Don't print to stdout in cookielib.py exception handler Message-ID: Patches item #969907, was opened at 2004-06-09 22:09 Message generated for change (Settings changed) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=969907&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: John J Lee (jjlee) Assigned to: Nobody/Anonymous (nobody) >Summary: Don't print to stdout in cookielib.py exception handler Initial Comment: There are a couple of blanket except: statements in cookielib. The idea is to handle any bugs in cookielib's input handling that may be tickled by unexpected input by issuing a warning instead of letting the exception propagate. Previously, in addition to issuing a warning, a traceback was printed. This patch makes the traceback part of the warning, so it can be suppressed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=969907&group_id=5470 From noreply at sourceforge.net Sun Jun 13 18:29:47 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jun 13 18:29:51 2004 Subject: [Patches] [ python-Patches-972310 ] urllib2 handler algorithm docs Message-ID: Patches item #972310, was opened at 2004-06-13 23:29 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=972310&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: John J Lee (jjlee) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 handler algorithm docs Initial Comment: In adding the docs that explain how handler methods are called, I got the algorithm wrong. (I accidentally described the slightly different algorithm used by my urllib2-workalike module) This patch fixes that. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=972310&group_id=5470 From noreply at sourceforge.net Sun Jun 13 19:16:17 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jun 13 19:16:21 2004 Subject: [Patches] [ python-Patches-972322 ] urllib2 handler naming convention collision Message-ID: Patches item #972322, was opened at 2004-06-14 00:16 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=972322&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: John J Lee (jjlee) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 handler naming convention collision Initial Comment: The method naming conventions of *_open and *_request in urllib2 are accidentally met by the following methods: AbstractHTTPHandler.do_open() ProxyHandler.proxy_open() AbstractHTTPHandler.redirect_request() So URLs like do://example.com/ are regarded as having a handler, and urllib2.urlopen("do://python.org/") causes a TypeError. I think *something* should be done about this, but I'm willing to provide a different patch if this one is frowned upon. The alternative would be to rename do_open and proxy_open, and leave the redirect_request case unchanged (see below for why). The first two methods are undocumented, so could in theory be renamed. However, people will likely be overriding them anyway, so perhaps it's better to apply this ugly patch than rename them. redirect_request is documented, so can't be renamed, but it will never be accidentally called unless somebody actually adds a handler with a method named "redirect_open". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=972322&group_id=5470 From noreply at sourceforge.net Sun Jun 13 19:49:37 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jun 13 19:49:41 2004 Subject: [Patches] [ python-Patches-972332 ] urllib2 FTPHandler bugs Message-ID: Patches item #972332, was opened at 2004-06-14 00:49 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=972332&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: John J Lee (jjlee) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 FTPHandler bugs Initial Comment: This uncomments a couple of failing tests in test_urllib2.py, and fixes the corresponding bugs: 1. The first bug was half-fixed since I wrote the test. Ports in FTP URLs are now correctly handled. However, the type of the port argument passed to ftplib.FTP.connect() is incorrect (is a string, should be an integer). 2. The ftp://example.com/foo.txt;type=a syntax is implemented but broken. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=972332&group_id=5470 From laurel.adkinshw at elbalink.it Mon Jun 14 00:02:54 2004 From: laurel.adkinshw at elbalink.it (Laurel Adkins) Date: Mon Jun 14 00:11:32 2004 Subject: [Patches] New powerful weightloss for you. Message-ID: <924201c451c4$5cb3c46a$d4297c20@tcsteele.de> Hello, I have a special_offer for you... WANT TO LOSE WEIGHT? The most powerful weightloss is now available without prescription. All natural Adipren720 100% Money Back Guarant?e! - Lose up to 19% Total Body Weight. - Up to 300% more Weight Loss while dieting. - Loss of 20-35% abdominal Fat. - Reduction of 40-70% overall Fat under skin. - Increase metabolic rate by 76.9% without Exercise. - Boost your Confidence level and Self Esteem. - Burns calorized fat. - Suppresses appetite for sugar. Get the facts about all-natural Adipren720 ---- system information ---- implementers user construct Localization] intended requests reports on and default public-i18n-ws-request@w3org any Group's technical patterns interoperability description archive) contribution session-like element be cite When term Transition tag describe XML world varies interaction support note numbering Internet name danger individual container From noreply at sourceforge.net Mon Jun 14 00:59:45 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jun 14 00:59:51 2004 Subject: [Patches] [ python-Patches-957240 ] Patch for feature request 491033 Message-ID: Patches item #957240, was opened at 2004-05-20 08:23 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=957240&group_id=5470 Category: None Group: None Status: Open >Resolution: None >Priority: 5 Submitted By: Josiah Carlson (josiahcarlson) >Assigned to: Nobody/Anonymous (nobody) Summary: Patch for feature request 491033 Initial Comment: The attached patch is to offer the functionality desired by feature request: python.org/sf/491033 On machines that use standard IEEE floating point doubles, the 'infinity' needs only to be 1e16 due to the limited precision of floating point. 1e309 is used for convenience sake, and will continue to be a precision infinity until 1024 bits of precision in floating point values is available. At such point in time where 1e309 is available in hardware, it will still sufficient due to the practical limitations of counting. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-06-14 06:59 Message: Logged In: YES user_id=21627 I have backed out the patch in libasyncore.tex 1.16 asyncore.py 1.52 NEWS 1.1001 ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-12 10:53 Message: Logged In: YES user_id=6656 um, "yes". what's in CVS currently is not going to be there for very long. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-06-11 23:54 Message: Logged In: YES user_id=341410 If it would be preferred, I have an alternate patch against 1.50 from CVS that uses None instead of floating point infinity. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-11 18:31 Message: Logged In: YES user_id=6656 This patch should not have been accepted. Relying on a floating point infinity to marhsal/unmarshal correctly is a bad idea. With the aid of the LC_NUMERIC agnostism patch, this patch breaks test_asynchat *when asyncore.pyc exists*. I don't have a windows machine with a CVS HEAD Python to check, but if 2.3 behaviour is retained, the upshot is that the count parameter will default to *1* if the code is loaded from a .pyc file. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-06-03 11:19 Message: Logged In: YES user_id=21627 Thanks for the patch. Applied as libasyncore.tex 1.15 asyncore.py 1.51 NEWS 1.986 ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-05-31 22:36 Message: Logged In: YES user_id=341410 The attached patch includes both a documentation patch, as well as a modified loop patch to explicitly match the documentation. The patches are concatenated and in standard context diff format (as per the Python patch submission guidelines, sorry about the previous unified diff). The test suite does not seem to contain tests for asyncore. It does contain a test for asynchat, which will be unaffected by this patch. One thing to note: the use of 'count = count - 1' rather than 'count -= 1' is to remove potential bugs in the case where a mutable number-like object with a modifying __isub__ method were to be passed by a user. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-05-31 20:32 Message: Logged In: YES user_id=21627 This patch lacks changes to the documentation and the test suite. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-05-20 08:26 Message: Logged In: YES user_id=341410 Sorry about that, I generated the patch by hand and got the ordering messed up. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=957240&group_id=5470 From noreply at sourceforge.net Mon Jun 14 03:42:26 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jun 14 03:42:34 2004 Subject: [Patches] [ python-Patches-826074 ] cmath.log optional base argument, fixes #823209 Message-ID: Patches item #826074, was opened at 2003-10-18 13:42 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=826074&group_id=5470 Category: Modules Group: Python 2.4 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Andrew Gaul (gaul) Assigned to: Raymond Hettinger (rhettinger) Summary: cmath.log optional base argument, fixes #823209 Initial Comment: Fixes bug #823209. math.log allows an optional base argument, add the same functionality to cmath.log. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-06-14 02:42 Message: Logged In: YES user_id=80475 Modified argument passing to use PyArg_ParseTuple(). Applied as Modules/cmathmodule.c 2.33 ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-01-02 00:36 Message: Logged In: YES user_id=31435 I don't really care. I see the referenced bug report had a marginal use case; OTOH, I can't afford the time to analyze this for numeric quality and robustness (but almost all of cmathmodule is in the same boat wrt that, so that's not much of an argument against it). The patch needs new tests and doc changes, of course. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-01-01 02:33 Message: Logged In: YES user_id=80475 Tim, should this be done? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=826074&group_id=5470 From noreply at sourceforge.net Mon Jun 14 11:16:51 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jun 14 11:16:58 2004 Subject: [Patches] [ python-Patches-957240 ] Patch for feature request 491033 Message-ID: Patches item #957240, was opened at 2004-05-19 23:23 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=957240&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Josiah Carlson (josiahcarlson) Assigned to: Nobody/Anonymous (nobody) Summary: Patch for feature request 491033 Initial Comment: The attached patch is to offer the functionality desired by feature request: python.org/sf/491033 On machines that use standard IEEE floating point doubles, the 'infinity' needs only to be 1e16 due to the limited precision of floating point. 1e309 is used for convenience sake, and will continue to be a precision infinity until 1024 bits of precision in floating point values is available. At such point in time where 1e309 is available in hardware, it will still sufficient due to the practical limitations of counting. ---------------------------------------------------------------------- >Comment By: Josiah Carlson (josiahcarlson) Date: 2004-06-14 08:16 Message: Logged In: YES user_id=341410 Y ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-06-13 21:59 Message: Logged In: YES user_id=21627 I have backed out the patch in libasyncore.tex 1.16 asyncore.py 1.52 NEWS 1.1001 ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-12 01:53 Message: Logged In: YES user_id=6656 um, "yes". what's in CVS currently is not going to be there for very long. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-06-11 14:54 Message: Logged In: YES user_id=341410 If it would be preferred, I have an alternate patch against 1.50 from CVS that uses None instead of floating point infinity. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-11 09:31 Message: Logged In: YES user_id=6656 This patch should not have been accepted. Relying on a floating point infinity to marhsal/unmarshal correctly is a bad idea. With the aid of the LC_NUMERIC agnostism patch, this patch breaks test_asynchat *when asyncore.pyc exists*. I don't have a windows machine with a CVS HEAD Python to check, but if 2.3 behaviour is retained, the upshot is that the count parameter will default to *1* if the code is loaded from a .pyc file. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-06-03 02:19 Message: Logged In: YES user_id=21627 Thanks for the patch. Applied as libasyncore.tex 1.15 asyncore.py 1.51 NEWS 1.986 ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-05-31 13:36 Message: Logged In: YES user_id=341410 The attached patch includes both a documentation patch, as well as a modified loop patch to explicitly match the documentation. The patches are concatenated and in standard context diff format (as per the Python patch submission guidelines, sorry about the previous unified diff). The test suite does not seem to contain tests for asyncore. It does contain a test for asynchat, which will be unaffected by this patch. One thing to note: the use of 'count = count - 1' rather than 'count -= 1' is to remove potential bugs in the case where a mutable number-like object with a modifying __isub__ method were to be passed by a user. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-05-31 11:32 Message: Logged In: YES user_id=21627 This patch lacks changes to the documentation and the test suite. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-05-19 23:26 Message: Logged In: YES user_id=341410 Sorry about that, I generated the patch by hand and got the ordering messed up. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=957240&group_id=5470 From noreply at sourceforge.net Mon Jun 14 11:23:13 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jun 14 11:23:22 2004 Subject: [Patches] [ python-Patches-876130 ] add C API to datetime module Message-ID: Patches item #876130, was opened at 2004-01-13 08:20 Message generated for change (Comment added) made by atuining You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=876130&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Anthony Tuininga (atuining) Assigned to: Tim Peters (tim_one) Summary: add C API to datetime module Initial Comment: The datetime module does not have a C API which means that modules written in C cannot take advantage of the datetime module without incurring significant overhead. These patches supply this lack and are based on the C API exported by the mxDateTime module and the cStringIO module and enhanced as suggested by Guido. ---------------------------------------------------------------------- >Comment By: Anthony Tuininga (atuining) Date: 2004-06-14 09:23 Message: Logged In: YES user_id=619560 I have attached a patch for the documentation as requested. Not being certain of the format and requirements for the content, your comments are appreciated. I have a few questions that might help focus your comments. 1) Should the API structure be documented and users of datetime.h encouraged to use it directly? Or should it be "implementation details" and only those methods that I have provided should be available? To help answer this question, is it intended to ever bring datetime objects into the "core" rather than as a separate module? 2) The DB API helper functions are provided because Marc Andre Lemburg thought it would be a good idea. Please take a look and see if it makes sense now that it is documented. :-) Please review and give me your feedback. Thanks. ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-06-07 07:57 Message: Logged In: YES user_id=619560 Yes, the top two files are the ones involved. As per your suggestion I deleted the other four files to avoid further confusion. I understand the concern for documentation. I'll see what I can do to get at least a preliminary patch on that front ready this week. Earlier discussions suggested that the documentation reside solely in the include file but I think adding a section to the Python/C API documentation would make a lot more sense. Please stand by. :-) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-06-05 17:43 Message: Logged In: YES user_id=31435 Assuming the current state of the proposal consists of the first two patches on the list ("patch for datetimemodule.c" and "patch for datetime.h"), I'm probably happy to commit them. Can't say for sure right now, because SF CVS is dead, and can't get a current checkout to try them with. The one necessary thing I don't see are docs: how are users supposed to know this exists, let alone know how to use it? We need a new section for datetime objects in the Python/C API Reference Manual, in the Other Objects part of the Concrete Objects Layer section. You don't have to write LaTeX, plain text is fine. Look at the other sections in that chapter for what's needed (an overview, and a precise account of what's in the new C API and how to use it). Don't let that discourage you -- you're very close! If I don't force docs out of you now, docs will never get written. That's why I'm trying to force docs out of you now . ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-06-05 17:10 Message: Logged In: YES user_id=31435 Heh. Just noticed there are 6 patches attached to this report. Are all of them part of the suggested change, or, if not, which are the current ones (if that's the case, the best way to answer the question is to delete the out-of-date patches)? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-06-01 11:53 Message: Logged In: YES user_id=31435 I intend to do it this week, but have no time today or tomorrow. ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-06-01 11:44 Message: Logged In: YES user_id=619560 Sure. What's the chance of it being reviewed prior to the release of Python 2.4 a1? I just saw the preannouncement today -- it is scheduled for the end of this month, I believe. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-05-31 21:12 Message: Logged In: YES user_id=31435 Assigned to me for the next review. Can't do it immediately, but will do my best to free up some time for it "soon". ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-05-26 13:39 Message: Logged In: YES user_id=619560 I would agree with your assessment of the issue regarding the TimeFromTicks() API and find it quite reasonable. Either implement both at the C and Python levels or not at all. Since there is no consensus on this, none it is. :-) Did you have a chance to review the actual code? The changes are fairly minimal but you might have questions about readability, names, etc. It would be great if this could be included in an upcoming 2.4 alpha/beta so that I can provide support in cx_Oracle for the next release. Thanks for your time. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-05-26 13:32 Message: Logged In: YES user_id=31435 Under the belief that the *intent* of this patch is to add a C API to Python's datetime module, it should stick to exposing C ways to spell what Python programmers can already do from Python using datetime. Since nothing like TimeFromTicks() exists in the Python datetime API, it simply doesn't make sense to invent one available only from C. It *may* make sense to invent one in a DB API wrapper around datetime, but I view that as out of scope for this patch. I would not add TimeFromTicks() to the Python datetime API either, because the docs are ambiguous. The sample implementation Marc-Andre posted here uses localtime() to resolve the ambiguity in the docs, but that has to be a wrong choice for some time-of-day apps. For example, there's apparently no portable way to spell "noon" using TimeFromTicks(): the value you get back depends on which time zone localtime() happens to use at the time it's called. If people want time-of-day from a POSIX timestamp, it remains easy to get it from what datetime already supplies, but to do so you have to be explicit about whether you want UTC or local time interpretation. Both are easily spelled already, and it's a Good Thing that you need to be explicit if you want to do such a thing. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-05-26 13:25 Message: Logged In: YES user_id=38388 Tim, please review. Thanks. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-05-26 13:22 Message: Logged In: YES user_id=38388 Thanks, but I don't have time to review it. As for the TimeFromTicks() API: I can understand that you don't feel like implementing it, but hey, I won't use datetime either. The only reason I'm trying to push full support of the DB API specs is that Guido et al. wanted to see a note in the DB API that datetime also provides a usable interface to do date/time interfacing. I'm not very interested in datetime myself, since I'll continue to use mxDateTime, so the situation for me is somewhat similar to yours: investing time into something that I myself will probably not use much (I will add support to mxODBC for those who like to use datetime instead of mxDateTime, but won't use it myself). Feel free to check in your changes. Thanks. ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-05-26 10:30 Message: Logged In: YES user_id=619560 Attached are the modified patches based on your suggestions. I have tested them with my own module cx_Oracle and they appear to work correctly. Any further suggestions would be appreciated. I would like to see this included for Python 2.4 if at all possible. Please let me know what I need to do (if anything) to get this to happen. As for the TimeFromTicks() routine, Oracle has absolutely no use for a "time-only" data type and does not support it. It clearly does not have broad support so I really have no desire to implement it since I will never use it myself. If you consider it important, you could add it yourself or we could wait until someone else who requires it for their implementation of the DB API requires it. I'm not trying to be rude or trying to denigrate the DB API, simply trying to be practical. Please let me know if this is offensive in any way. Thanks. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-05-19 02:28 Message: Logged In: YES user_id=38388 >From the DB API specs: TimeFromTicks(ticks) This function constructs an object holding a time value from the given ticks value (number of seconds since the epoch; see the documentation of the standard Python time module for details). The reason for this having this API is to be able to construct an object suitable for passing to the database given a Unix ticks value. Since the ticks value contains both a date and a time part and most databases have a special column type for time value, we need two constructor APIs, one to extract just the date part and one for the time part. Here's the mxDateTime implementation for reference: def TimeFromTicks(ticks, # Locals: DateTimeDelta=DateTimeDelta,localtime=_time.localtime): """ TimeFromTicks(ticks) Constructs a DateTimeDelta instance pointing to the local time indicated by the given ticks value. The date part is ignored. """ return apply(DateTimeDelta, (0,) + localtime(ticks)[3:6]) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-05-03 11:46 Message: Logged In: YES user_id=31435 I don't understand what TimeFromTicks() is supposed to do. Seconds-from-the-epoch is a point in time, not a time-of- day. If some DB API requires guessing some transformation from seconds-from-the-epoch to time-of-day, that's fine, but it doesn't belong in Python's datetime module. The datetime module should certainly have a method to construct a datetime.datetime from a seconds-from-the- epoch argument -- seconds-from-the-epoch is a way of specifying a datetime.datetime. Given that, if the intent is to throw away the datetime.date portion of the datetime.datetime object, retaining only the datetime.time portion, then that's trivially accomplished by invoking dt.time () (where dt is the datetime.datetime object). Do any databases really store time-of-day as a seconds-from- the-epoch value? Google's top hit on TimeFromTicks() today happens to be a msg from Anthony saying that Oracle does not. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-05-03 11:24 Message: Logged In: YES user_id=38388 Macro: I don't know whether you need the macro or not (you probably do for the type checks). In any case, you can do without relying on Python providing you this information via the build process, since only datetimemodule.c is using the header file while Python is being built. TimeFromTicks(): I' ve stated my point. I don't think there's anything to add - I'm tired of fighting for these things... one of the reasons I stopped actively discussing things on python-dev. IMHO, a product that's aimed at developers should make things easy for the developer and try to avoid code duplication if possible. The API is needed in order to support database interfaces that use Unix ticks as basis for date/time, so if you don't add it to the module, the ten or twenty module authors out there will have to duplicate that piece of work in their implementation. Transition: This was already discussed on the db-api list. We love freedom of choice. Nothing to add. ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-05-03 10:48 Message: Logged In: YES user_id=619560 About the Py_BUILD_CORE issue: You are suggesting that I define this in datetimemodule.c just prior to the include of datetime.h? Or are you suggesting some other macro? I am not sure about the comment about "not needing a macro in the first place" since there are two groups that will be importing datetime.h: the first being the datetime module itself and the second being the DB API modules. The macro is definitely required to distinguish between the two -- unless I am missing something? On the TimeFromTicks() issue: You obviously consider it important that the three methods be available at the C level for DB API module authors to use directly. My objection is simply a reiteration of an objection raised by Tim Peters. I think you'll have to argue that one with him. :-) I'll provide my implementations for cx_Oracle as part of the patches and then you can fight it out and I'll stay out of it. :-) As for the transition period, I assumed that with the introduction of a standard datetime module, that it would become the suggested implementation for database interfaace modules. That said, I don't really have any authority to say anything on this front so I'll leave that to you and others to decide. :-) ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-05-03 09:26 Message: Logged In: YES user_id=38388 About the Py_BUILD_CORE issue: Sorry, I didn't know that Python does not define this macro for core modules. Nevertheless, looking at the datetime module code I don't really understand why you would need such a macro in the first place. Since the datetime module is the only code including the datetime.h header file it should be easy to add a macro definition just before importing datetime.h. On the TimeFromTicks() issue: The whole point of this discussion is to make the datetime module easily usable for authors of database modules. Since the DB API specifies that the module will need to export the three functions, two of which are available through the datetime module already, I don't really see your point in not wanting to add it. BTW, you are wrong in the assumption that the DB API spec will move away from a generic API for date/time objects. The DB API has always been defined in terms of interfaces and does not force a certain set of tools onto the developer. The datetime module will become one possible choice for DB API authors, others will want to stick to mxDateTime, use strings, ticks integers or more specific objects for interfacing. That won't change, so there is no "transition period". ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-05-03 08:40 Message: Logged In: YES user_id=619560 I spent some time getting the two include files merged together, only to discover that Py_BUILD_CORE is __NOT__ defined when building modules, only when building stuff linked directly into the core interpreter. Perhaps this ought to be defined when building the modules with setup.py? At any rate, I cannot proceed along the route suggested without this problem being resolved. On the DateFromTicks(), TimestampFromTicks(), TimeFromTicks() issue, I'm not sure that there is much benefit to including a C API for this since if the datetime module becomes the standard method for managing datetime objects, there is no point in having the DB API modules provide something that the datetime module already provides, right? During the transition period the few lines of code needed can be posted. If you disagree I can certainly provide the few lines as part of the patch but I suspect you will find resistance to having this included by Tim Peters, the maintainer (I believe) of the datetime module. Feel free to correct me... :-) ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-04-26 10:19 Message: Logged In: YES user_id=38388 Sorry for not getting back to you earlier: I didn't see you last message. 1-4) Python defines a macro during the Python build process that is not defined when compiling extensions: Py_BUILD_CORE You can use that macro to compile things differently for core things vs. extensions. 5) Fair enough; I don't see a point in creating a new numbering for each and every module. Please just use 1, 2, 3, 4, ... 6) Hope this makes sense :-) ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-04-26 09:35 Message: Logged In: YES user_id=619560 Any chance to look at this? Any hope of this being included in Python 2.4? I know a number of people (including Guido) who would appreciate that.... :-) ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-04-05 16:04 Message: Logged In: YES user_id=619560 I am back at work after finishing my move so I think I can finally devote a little more time to this issue. 1-4) The main reason for datetimeapi.h as opposed to simply modifying datetime.h was that the internal build needs to define things __differently__ from an external build of a module and there doesn't appear to be any way of fixing that -- so if you know a way I think I can manage to create a reasonable patch; otherwise, I'm out of my depth! 5) Guido was suggesting that a new PyIMPORT macro be made available which would verify that the magic number defined in the header file actually matches the magic number exported by the built module; this is simply a developer protection scheme which should eliminate really stupid uses; you can ask him about this or I can e-mail you part of the thread that brought this up 6) Makes sense. I'd like to get the questions above resolved first before proceeding any further, though. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-03-25 11:23 Message: Logged In: YES user_id=38388 Thanks for the comments... 1) Please put *all* the code for the C API into datetimeapi.h. I don't like your current mix of putting some things into datetime.h and others into datetimeapi.h (e.g. the PyDateTime_CAPI definition). 2) Since it's the only API missing if you want to use datetime objects in database interfacing, please add it. 3) dito. 4) Yes, the header file is the right place. Have a look at unicodeobject.h for what I have in mind (or mxDateTime.h for that matter). 5) Why add yet another magic number ? Isn't the Python API number enough ? 6) Since you don't provide a doc patch, please put comments into the header file. There can never be enough documentation and developers tend to look at the code rather than the docs ;-) ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-03-25 11:08 Message: Logged In: YES user_id=619560 Sorry for the delay. Things here have been quite busy recently both at work and at home. Let me see if I can answer your questions. 1) are you suggesting comments that include the macro names in datetimeapi.h similar to what I put in the comments below? Or something else? See modified datetimeapi.h for more info. 2) TimeFromTicks() is a very DB API specific routine. In chatting with others about the datetime module, they were not keen on adding such a beast. I guess there will have to be some discussion about whether datetimeapi.h is also a sort of half implementation for a C module implementing the DB API. I was intending to do this in my cx_Oracle module but not in datetimeapi.h. Could you clarify? 3) I could add C APIS for the three DB API ticks interfaces but I was simply intending to do that in cx_Oracle. Again, see #2. I can do it either way. :-) 4) I have added limited documentation in datetimeapi.h but is that really the right place for it? Is it even remotely close to what is needed? I'm not sure what is needed here exactly. 5) the API magic number is simply an arbitrary number which is stored in datetime.h and need not be understood by the implementor. For your information I simply took the name "datetime", converted each letter to its ordinal value in the alphabet, modded by 16 and used that hex character -- does that make any sense? This can be changed to whatever makes sense, though. 6) Whether or not datetimeapi.h should be sufficient for a developer or whether he should look at documentation in the usual locations (html pages, for example) I'll leave up to the Python development team. Let me know how I can assist. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-03-25 10:35 Message: Logged In: YES user_id=38388 Anthony, have you had a chance to look at the comments ? ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-02-26 08:06 Message: Logged In: YES user_id=619560 Oops! It looks like my own misunderstanding of SourceForge and how it works is to blame. :-( I'll take a look at this and get back to you as soon as possible -- ignore my previous comment. ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-02-26 08:03 Message: Logged In: YES user_id=619560 You haven't yet responded to my previous comments -- it looks like SourceForge put them __after__ your comments so it is quite understandable why you didn't notice them. If you can give me the answers to those questions or provide additional questions that I need to answer, then I think we can make progress again. I was waiting for __you__ :-) ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-02-25 16:08 Message: Logged In: YES user_id=38388 Any progress on this ? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-01-28 04:49 Message: Logged In: YES user_id=38388 Thanks for the clarification. I had forgotten about the macros -- I'd suggest that you document them in the datetimeapi.h include file to not cause the same confusion on the developer side (the trick to achieve adoption is to make things easy on the developer). As for TimeFromTicks(): This should be rather straight forward to implement: you take the time part of the ticks timestamp and create a time object from it. This is the way the DB API constructor works. Could you add C APIs for the three DB API ticks interface methods ? Other things that are missing: * documentation of the way the CAPI object can be used in datetimeapi.h * documentation of the various CAPI entries * documentation of the API magic number (there should be some scheme for this) I think that datetimeapi.h should be enough for a developer to read in order to use the interface. ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-01-26 14:02 Message: Logged In: YES user_id=619560 I didn't think any additional API would be necessary for extracting date time information since the following macros are available: PyDateTime_GET_YEAR(o) PyDateTime_GET_MONTH(o) PyDateTime_GET_DAY(o) PyDateTime_DATE_GET_HOUR(o) PyDateTime_DATE_GET_MINUTE(o) PyDateTime_DATE_GET_SECOND(o) PyDateTime_DATE_GET_MICROSECOND(o) PyDateTime_TIME_GET_HOUR(o) PyDateTime_TIME_GET_MINUTE(o) PyDateTime_TIME_GET_SECOND(o) PyDateTime_TIME_GET_MICROSECOND(o) Were you thinking of something else that is needed? As for interfacing at the C level for converting from Unix ticks, the following method is already available and could simply be used as a drop in replacement for DateFromTicks() and TimestampFromTicks() from the DB API document. DateFromTicks() --> datetime.date.fromtimestamp() TimestampFromTicks() --> datetime.datetime.fromtimestamp() TimeFromTicks() is not already exposed but discussions with Tim Peters already suggested that would not happen since the concept is rather strange. You'll have to discuss that with him if you disagree! :-) Any comments? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-01-26 13:46 Message: Logged In: YES user_id=38388 This is a good start. However, you should add more APIs for extracting date/time information to the C API. mxDateTime.h from egenix-mx-base can provide a good basis for this. If you want to make the datetime module usable for database interfacing at C level, you'll also have to add interfaces for Unix ticks conversion, since these are often used by database C level interfaces. ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-01-26 11:36 Message: Logged In: YES user_id=619560 I have no objection to providing patches for doc and test. A quick look at _testcapimodule.c doesn't provide any obvious ideas as to how to patch it. I looked for cStringIO which has a C API already and found nothing in there at all. The documentation also simply says "see the source for the information you require". Any suggestions as to how to proceed? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-01-25 20:17 Message: Logged In: YES user_id=31435 Marc-Andre, can you review this? I think you have more experience building C APIs for modules than anyone else (while I don't have any). There's certainly no objection to giving datetime a C API, and Guido already said he doesn't want to rely on that Martin changed datetime to be built as part of the core (in 2.3 on Windows, datetime.pyd was a distinct DLL; in CVS, datetime is compiled into the core DLL now). Anthony, you probably need to add doc and test patches. _testcapimodule.c holds tests of things you can only get at from C. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=876130&group_id=5470 From noreply at sourceforge.net Mon Jun 14 11:37:16 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jun 14 11:37:23 2004 Subject: [Patches] [ python-Patches-957240 ] Patch for feature request 491033 Message-ID: Patches item #957240, was opened at 2004-05-19 23:23 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=957240&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Josiah Carlson (josiahcarlson) Assigned to: Nobody/Anonymous (nobody) Summary: Patch for feature request 491033 Initial Comment: The attached patch is to offer the functionality desired by feature request: python.org/sf/491033 On machines that use standard IEEE floating point doubles, the 'infinity' needs only to be 1e16 due to the limited precision of floating point. 1e309 is used for convenience sake, and will continue to be a precision infinity until 1024 bits of precision in floating point values is available. At such point in time where 1e309 is available in hardware, it will still sufficient due to the practical limitations of counting. ---------------------------------------------------------------------- >Comment By: Josiah Carlson (josiahcarlson) Date: 2004-06-14 08:37 Message: Logged In: YES user_id=341410 There is an attached patch that uses None. I ran the standard tests twice, and it does not fail when asyncore.pyc exists (5 tests should suffice). ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-06-14 08:16 Message: Logged In: YES user_id=341410 Y ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-06-13 21:59 Message: Logged In: YES user_id=21627 I have backed out the patch in libasyncore.tex 1.16 asyncore.py 1.52 NEWS 1.1001 ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-12 01:53 Message: Logged In: YES user_id=6656 um, "yes". what's in CVS currently is not going to be there for very long. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-06-11 14:54 Message: Logged In: YES user_id=341410 If it would be preferred, I have an alternate patch against 1.50 from CVS that uses None instead of floating point infinity. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-11 09:31 Message: Logged In: YES user_id=6656 This patch should not have been accepted. Relying on a floating point infinity to marhsal/unmarshal correctly is a bad idea. With the aid of the LC_NUMERIC agnostism patch, this patch breaks test_asynchat *when asyncore.pyc exists*. I don't have a windows machine with a CVS HEAD Python to check, but if 2.3 behaviour is retained, the upshot is that the count parameter will default to *1* if the code is loaded from a .pyc file. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-06-03 02:19 Message: Logged In: YES user_id=21627 Thanks for the patch. Applied as libasyncore.tex 1.15 asyncore.py 1.51 NEWS 1.986 ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-05-31 13:36 Message: Logged In: YES user_id=341410 The attached patch includes both a documentation patch, as well as a modified loop patch to explicitly match the documentation. The patches are concatenated and in standard context diff format (as per the Python patch submission guidelines, sorry about the previous unified diff). The test suite does not seem to contain tests for asyncore. It does contain a test for asynchat, which will be unaffected by this patch. One thing to note: the use of 'count = count - 1' rather than 'count -= 1' is to remove potential bugs in the case where a mutable number-like object with a modifying __isub__ method were to be passed by a user. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-05-31 11:32 Message: Logged In: YES user_id=21627 This patch lacks changes to the documentation and the test suite. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-05-19 23:26 Message: Logged In: YES user_id=341410 Sorry about that, I generated the patch by hand and got the ordering messed up. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=957240&group_id=5470 From noreply at sourceforge.net Mon Jun 14 16:44:21 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jun 14 16:44:27 2004 Subject: [Patches] [ python-Patches-957650 ] Fix for bugs relating to ntpath.expanduser() Message-ID: Patches item #957650, was opened at 2004-05-20 20:35 Message generated for change (Comment added) made by chomo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=957650&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Josiah Carlson (josiahcarlson) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for bugs relating to ntpath.expanduser() Initial Comment: Attached is a patch for sf bug #796219 that fixes ntpath.expanduser() for paths that embed other environment variables, and also includes functionality that mirrors *nix-style ~user\extra expansions. I will comment with output from both the unpatched and patched version of ntpath. ---------------------------------------------------------------------- Comment By: alan johnson (chomo) Date: 2004-06-14 20:44 Message: Logged In: YES user_id=943591 this problem maybe is whats needed ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-05-20 20:38 Message: Logged In: YES user_id=341410 I uploaded the testing as text to alleviate text wrapping issues that could confuse. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-05-20 20:36 Message: Logged In: YES user_id=341410 #test setup: >>> import os >>> os.environ['TESTING'] = '%TESTING1%' >>> os.environ['TESTING1'] = '%TESTING2%' >>> os.environ['TESTING2'] = 'Final\Path' #test standard ntpath >>> import ntpath >>> ntpath.expanduser('~') 'C:\Documents and Settings\jcarlson' >>> ntpath.expanduser('~billy') '~billy' >>> ntpath.expanduser('~billy\bob') '~billy\bob' >>> ntpath.expanduser('~\bob') 'C:\Documents and Settings\jcarlson\bob' >>> ntpath.expanduser('~billy\%TESTING%\%TESTING1%\%TESTING2%') '~billy\%TESTING%\%TESTING1%\%TESTING2%' #test patched ntpath >>> import ntpath_patched >>> ntpath_patched.expanduser('~') 'C:Documents and Settings\jcarlson' >>> ntpath_patched.expanduser('~billy') 'C:Documents and Settings\billy' >>> ntpath_patched.expanduser('~billy\bob') 'C:Documents and Settings\billy\bob' >>> ntpath_patched.expanduser('~\bob') 'C:Documents and Settings\jcarlson\bob' >>> ntpath_patched.expanduser('~billy\%TESTING%\%TESTING1%\%TESTING2%') 'C:Documents and Settings\billy\Final\Path\Final\Path\Final\Path' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=957650&group_id=5470 From noreply at sourceforge.net Mon Jun 14 17:11:24 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jun 14 17:11:31 2004 Subject: [Patches] [ python-Patches-967763 ] fix bsddb memory leaks Message-ID: Patches item #967763, was opened at 2004-06-06 20:51 Message generated for change (Comment added) made by chomo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=967763&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Gregory P. Smith (greg) Summary: fix bsddb memory leaks Initial Comment: only one of the changes fixed a leak reported by valgrind, but i think all the changes are necessary. ---------------------------------------------------------------------- Comment By: alan johnson (chomo) Date: 2004-06-14 21:11 Message: Logged In: YES user_id=943591 looks like the ones needed anyway ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2004-06-13 20:56 Message: Logged In: YES user_id=33168 Greg, just wanted to make sure you saw this. It seems like you're the only one working on bsddb these days. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=967763&group_id=5470 From noreply at sourceforge.net Mon Jun 14 20:02:19 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jun 14 20:02:26 2004 Subject: [Patches] [ python-Patches-967763 ] fix bsddb memory leaks Message-ID: Patches item #967763, was opened at 2004-06-06 13:51 Message generated for change (Comment added) made by greg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=967763&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Gregory P. Smith (greg) Summary: fix bsddb memory leaks Initial Comment: only one of the changes fixed a leak reported by valgrind, but i think all the changes are necessary. ---------------------------------------------------------------------- >Comment By: Gregory P. Smith (greg) Date: 2004-06-14 17:02 Message: Logged In: YES user_id=413 make_key_dbt() will never return with an error leaving a FREE_DBT(key) necessary. however looking in depth at the code i believe it would have been possible to have a leak when using integer keys and exiting early with an error. a patch (untested) that should fix that is attached. i'll test it out later. do you have any memleak test cases by any chance? ---------------------------------------------------------------------- Comment By: alan johnson (chomo) Date: 2004-06-14 14:11 Message: Logged In: YES user_id=943591 looks like the ones needed anyway ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2004-06-13 13:56 Message: Logged In: YES user_id=33168 Greg, just wanted to make sure you saw this. It seems like you're the only one working on bsddb these days. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=967763&group_id=5470 From noreply at sourceforge.net Mon Jun 14 21:11:02 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jun 14 21:11:09 2004 Subject: [Patches] [ python-Patches-957650 ] Fix for bugs relating to ntpath.expanduser() Message-ID: Patches item #957650, was opened at 2004-05-20 13:35 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=957650&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Josiah Carlson (josiahcarlson) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for bugs relating to ntpath.expanduser() Initial Comment: Attached is a patch for sf bug #796219 that fixes ntpath.expanduser() for paths that embed other environment variables, and also includes functionality that mirrors *nix-style ~user\extra expansions. I will comment with output from both the unpatched and patched version of ntpath. ---------------------------------------------------------------------- >Comment By: Josiah Carlson (josiahcarlson) Date: 2004-06-14 18:11 Message: Logged In: YES user_id=341410 What problem is needed? Perhaps you mean "this solution is desireable". ---------------------------------------------------------------------- Comment By: alan johnson (chomo) Date: 2004-06-14 13:44 Message: Logged In: YES user_id=943591 this problem maybe is whats needed ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-05-20 13:38 Message: Logged In: YES user_id=341410 I uploaded the testing as text to alleviate text wrapping issues that could confuse. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-05-20 13:36 Message: Logged In: YES user_id=341410 #test setup: >>> import os >>> os.environ['TESTING'] = '%TESTING1%' >>> os.environ['TESTING1'] = '%TESTING2%' >>> os.environ['TESTING2'] = 'Final\Path' #test standard ntpath >>> import ntpath >>> ntpath.expanduser('~') 'C:\Documents and Settings\jcarlson' >>> ntpath.expanduser('~billy') '~billy' >>> ntpath.expanduser('~billy\bob') '~billy\bob' >>> ntpath.expanduser('~\bob') 'C:\Documents and Settings\jcarlson\bob' >>> ntpath.expanduser('~billy\%TESTING%\%TESTING1%\%TESTING2%') '~billy\%TESTING%\%TESTING1%\%TESTING2%' #test patched ntpath >>> import ntpath_patched >>> ntpath_patched.expanduser('~') 'C:Documents and Settings\jcarlson' >>> ntpath_patched.expanduser('~billy') 'C:Documents and Settings\billy' >>> ntpath_patched.expanduser('~billy\bob') 'C:Documents and Settings\billy\bob' >>> ntpath_patched.expanduser('~\bob') 'C:Documents and Settings\jcarlson\bob' >>> ntpath_patched.expanduser('~billy\%TESTING%\%TESTING1%\%TESTING2%') 'C:Documents and Settings\billy\Final\Path\Final\Path\Final\Path' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=957650&group_id=5470 From noreply at sourceforge.net Mon Jun 14 21:36:35 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jun 14 21:36:43 2004 Subject: [Patches] [ python-Patches-967763 ] fix bsddb memory leaks Message-ID: Patches item #967763, was opened at 2004-06-06 16:51 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=967763&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Gregory P. Smith (greg) Summary: fix bsddb memory leaks Initial Comment: only one of the changes fixed a leak reported by valgrind, but i think all the changes are necessary. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2004-06-14 21:36 Message: Logged In: YES user_id=33168 I just run the regression tests. Did you see my mail to python-dev? http://mail.python.org/pipermail/python-dev/2004-June/045245.html Here's the bsddb leaks reported by valgrind: 4 bytes in 1 blocks are definitely lost in loss record 7 of 663 at 0x3C01DA1D: malloc (vg_replace_malloc.c:109) by 0x3C928265: make_key_dbt (_bsddb.c:400) by 0x3C92DE4F: DBC_set_range (_bsddb.c:2911) 8 bytes in 2 blocks are definitely lost in loss record 29 of 663 at 0x3C01DA1D: malloc (vg_replace_malloc.c:109) by 0x3C928265: make_key_dbt (_bsddb.c:400) by 0x3C929088: DB_get (_bsddb.c:1349) ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2004-06-14 20:02 Message: Logged In: YES user_id=413 make_key_dbt() will never return with an error leaving a FREE_DBT(key) necessary. however looking in depth at the code i believe it would have been possible to have a leak when using integer keys and exiting early with an error. a patch (untested) that should fix that is attached. i'll test it out later. do you have any memleak test cases by any chance? ---------------------------------------------------------------------- Comment By: alan johnson (chomo) Date: 2004-06-14 17:11 Message: Logged In: YES user_id=943591 looks like the ones needed anyway ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2004-06-13 16:56 Message: Logged In: YES user_id=33168 Greg, just wanted to make sure you saw this. It seems like you're the only one working on bsddb these days. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=967763&group_id=5470 From noreply at sourceforge.net Mon Jun 14 21:47:15 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jun 14 21:47:19 2004 Subject: [Patches] [ python-Patches-967763 ] fix bsddb memory leaks Message-ID: Patches item #967763, was opened at 2004-06-06 13:51 Message generated for change (Comment added) made by greg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=967763&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Gregory P. Smith (greg) Summary: fix bsddb memory leaks Initial Comment: only one of the changes fixed a leak reported by valgrind, but i think all the changes are necessary. ---------------------------------------------------------------------- >Comment By: Gregory P. Smith (greg) Date: 2004-06-14 18:47 Message: Logged In: YES user_id=413 Thanks, I hadn't caught up on python-dev in a while. What happens if you apply my attached patch and rerun the test under valgrind? The 4 bytes leaked sounds exactly like what i was expecting reading the code (an integer key causes make_key_dbt to alloc a 32bit value). in the DBC_set_range case without the patch i believe it is likely that the integer is allocated but the REALLOC flag is overridden in the old code with a MALLOC causing BerkeleyDB to leak the old pointer and allocate a new key for the return value (btree accessed using an integer key). 8 bytes in 2 blocks leaked in DB_get is double what i expected but without debug info showing the DB_get function call arguments and database flags its hard to say what happened. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2004-06-14 18:36 Message: Logged In: YES user_id=33168 I just run the regression tests. Did you see my mail to python-dev? http://mail.python.org/pipermail/python-dev/2004-June/045245.html Here's the bsddb leaks reported by valgrind: 4 bytes in 1 blocks are definitely lost in loss record 7 of 663 at 0x3C01DA1D: malloc (vg_replace_malloc.c:109) by 0x3C928265: make_key_dbt (_bsddb.c:400) by 0x3C92DE4F: DBC_set_range (_bsddb.c:2911) 8 bytes in 2 blocks are definitely lost in loss record 29 of 663 at 0x3C01DA1D: malloc (vg_replace_malloc.c:109) by 0x3C928265: make_key_dbt (_bsddb.c:400) by 0x3C929088: DB_get (_bsddb.c:1349) ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2004-06-14 17:02 Message: Logged In: YES user_id=413 make_key_dbt() will never return with an error leaving a FREE_DBT(key) necessary. however looking in depth at the code i believe it would have been possible to have a leak when using integer keys and exiting early with an error. a patch (untested) that should fix that is attached. i'll test it out later. do you have any memleak test cases by any chance? ---------------------------------------------------------------------- Comment By: alan johnson (chomo) Date: 2004-06-14 14:11 Message: Logged In: YES user_id=943591 looks like the ones needed anyway ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2004-06-13 13:56 Message: Logged In: YES user_id=33168 Greg, just wanted to make sure you saw this. It seems like you're the only one working on bsddb these days. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=967763&group_id=5470 From noreply at sourceforge.net Tue Jun 15 01:47:14 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jun 15 01:47:17 2004 Subject: [Patches] [ python-Patches-972991 ] fix build of docs in info format Message-ID: Patches item #972991, was opened at 2004-06-15 05:47 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=972991&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: fix build of docs in info format Initial Comment: one of those a workaround in py2texi.el (verbatim environments are processed before comments) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=972991&group_id=5470 From 564Gery at idealu.com Tue Jun 15 06:30:35 2004 From: 564Gery at idealu.com (Corrie Bonnie) Date: Tue Jun 15 06:07:19 2004 Subject: [Patches] Fwd: fantastic Message-ID: <200406150936.i5F9a1SJ097249@mxzilla1.xs4all.nl> An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20040615/25c09435/attachment.html From noreply at sourceforge.net Tue Jun 15 14:42:38 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jun 15 14:59:41 2004 Subject: [Patches] [ python-Patches-968063 ] Add fileinput.islastline() Message-ID: Patches item #968063, was opened at 2004-06-07 02:45 Message generated for change (Comment added) made by relm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=968063&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Relm Arrowny (relm) Assigned to: Nobody/Anonymous (nobody) Summary: Add fileinput.islastline() Initial Comment: You can test for the first line of a file with fileinput.isfirstline(), but there is no corresponding fileinput.islastline() to test for the last line of a file. Note that there is already an unapplied patch for this at request ID 776100, but it is faulty in that it only tests for end of buffer and not end of file. I was not sure how to append this patch to the existing request, so have started a new one. Hope this is okay. This patch also includes documentation and test updates. ---------------------------------------------------------------------- >Comment By: Relm Arrowny (relm) Date: 2004-06-15 11:42 Message: Logged In: YES user_id=1058331 The OP's use case was too simplified to convey the usefulness of fileinput.islastline(). It does not just save a couple of lines. I am attaching a "wc" or "word count" program to demonstrate. Note the following problems with the current work-around: 1. Instead of doing end-of-file processing at the end of a file, we must do it at the beginning of the *next* file. 2. Useful functions such as fileinput.filelineno() and fileinput.filename() now refer to the *wrong* file, so now we need to manually keep track of these values ourselves. 3. Perhaps a minor point, but this work-around only works at the *beginning* of the loop instead of the end. It feels somewhat awkward. 4. End-of-file processing must occur both in the loop and once outside. A function avoids code duplication, but to refer to variables in the loop, they must be passed into and out of the function (6 in, 2 out for the "wc" example... maybe keyword arguments would have helped). 5. Most important is readablility. It's not obvious that `fileinput.isfirstline() and fileinput.lineno() != 1` means we are the end of the (previous!) file. Using `fileinput.islastline()` would be much clearer. And not that it is a reason, but Perl and Ruby solve this with an `eof` function and `eof?` method, respectively. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-06-15 05:05 Message: Logged In: YES user_id=80475 I'm -0 on complicating this venerable interface. Also, I find it unnatural for the inside of a loop to be able to ascertain whether it is in its final iteration. The closest approximation is the for-else clause which is vary rarely used in normal python programming. While the OP was able to sketch a use case, it involved only saving a couple of lines over what can be done with the existing API. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=968063&group_id=5470 From noreply at sourceforge.net Tue Jun 15 08:10:33 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jun 15 15:49:15 2004 Subject: [Patches] [ python-Patches-973204 ] Fix for compilation with runtime_library_dirs Message-ID: Patches item #973204, was opened at 2004-06-15 15:10 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=973204&group_id=5470 Category: Distutils and setup.py Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Antti Honkela (ahonkela) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for compilation with runtime_library_dirs Initial Comment: Compilation of extension modules using runtime_library_dirs fails on HP Tru64 Unix and IRIX because distutils tries to use linker option -R/path to set the rpath. The correct option on these platforms is '-rpath /path'. The fix requires a change to CCompiler.runtime_library_dir_option return value type because of the need to add two separate arguments, '-rpath' and '/path'. According to man page of ld(1) on Tru64, the compiler would expect a colon separated path as argument for -rpath and only honors the last of multiple -rpath arguments, so the module is still broken on Tru64 if using multiple directories in runtime_library_dirs. Fixing this would require even greater architectural changes, so I will skip it, as I don't need it myself. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=973204&group_id=5470 From noreply at sourceforge.net Tue Jun 15 06:46:12 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jun 15 17:06:52 2004 Subject: [Patches] [ python-Patches-957650 ] Fix for bugs relating to ntpath.expanduser() Message-ID: Patches item #957650, was opened at 2004-05-20 21:35 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=957650&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Josiah Carlson (josiahcarlson) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for bugs relating to ntpath.expanduser() Initial Comment: Attached is a patch for sf bug #796219 that fixes ntpath.expanduser() for paths that embed other environment variables, and also includes functionality that mirrors *nix-style ~user\extra expansions. I will comment with output from both the unpatched and patched version of ntpath. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2004-06-15 11:46 Message: Logged In: YES user_id=6656 bugger, wrong report :-/ ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-15 11:45 Message: Logged In: YES user_id=6656 This looks much better to me! ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-06-15 02:11 Message: Logged In: YES user_id=341410 What problem is needed? Perhaps you mean "this solution is desireable". ---------------------------------------------------------------------- Comment By: alan johnson (chomo) Date: 2004-06-14 21:44 Message: Logged In: YES user_id=943591 this problem maybe is whats needed ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-05-20 21:38 Message: Logged In: YES user_id=341410 I uploaded the testing as text to alleviate text wrapping issues that could confuse. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-05-20 21:36 Message: Logged In: YES user_id=341410 #test setup: >>> import os >>> os.environ['TESTING'] = '%TESTING1%' >>> os.environ['TESTING1'] = '%TESTING2%' >>> os.environ['TESTING2'] = 'Final\Path' #test standard ntpath >>> import ntpath >>> ntpath.expanduser('~') 'C:\Documents and Settings\jcarlson' >>> ntpath.expanduser('~billy') '~billy' >>> ntpath.expanduser('~billy\bob') '~billy\bob' >>> ntpath.expanduser('~\bob') 'C:\Documents and Settings\jcarlson\bob' >>> ntpath.expanduser('~billy\%TESTING%\%TESTING1%\%TESTING2%') '~billy\%TESTING%\%TESTING1%\%TESTING2%' #test patched ntpath >>> import ntpath_patched >>> ntpath_patched.expanduser('~') 'C:Documents and Settings\jcarlson' >>> ntpath_patched.expanduser('~billy') 'C:Documents and Settings\billy' >>> ntpath_patched.expanduser('~billy\bob') 'C:Documents and Settings\billy\bob' >>> ntpath_patched.expanduser('~\bob') 'C:Documents and Settings\jcarlson\bob' >>> ntpath_patched.expanduser('~billy\%TESTING%\%TESTING1%\%TESTING2%') 'C:Documents and Settings\billy\Final\Path\Final\Path\Final\Path' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=957650&group_id=5470 From noreply at sourceforge.net Tue Jun 15 06:47:33 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jun 15 18:37:56 2004 Subject: [Patches] [ python-Patches-957240 ] Patch for feature request 491033 Message-ID: Patches item #957240, was opened at 2004-05-20 07:23 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=957240&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Josiah Carlson (josiahcarlson) Assigned to: Nobody/Anonymous (nobody) Summary: Patch for feature request 491033 Initial Comment: The attached patch is to offer the functionality desired by feature request: python.org/sf/491033 On machines that use standard IEEE floating point doubles, the 'infinity' needs only to be 1e16 due to the limited precision of floating point. 1e309 is used for convenience sake, and will continue to be a precision infinity until 1024 bits of precision in floating point values is available. At such point in time where 1e309 is available in hardware, it will still sufficient due to the practical limitations of counting. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2004-06-15 11:47 Message: Logged In: YES user_id=6656 This is the patch I was trying to say was much better :-) ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-06-14 16:37 Message: Logged In: YES user_id=341410 There is an attached patch that uses None. I ran the standard tests twice, and it does not fail when asyncore.pyc exists (5 tests should suffice). ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-06-14 16:16 Message: Logged In: YES user_id=341410 Y ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-06-14 05:59 Message: Logged In: YES user_id=21627 I have backed out the patch in libasyncore.tex 1.16 asyncore.py 1.52 NEWS 1.1001 ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-12 09:53 Message: Logged In: YES user_id=6656 um, "yes". what's in CVS currently is not going to be there for very long. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-06-11 22:54 Message: Logged In: YES user_id=341410 If it would be preferred, I have an alternate patch against 1.50 from CVS that uses None instead of floating point infinity. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-11 17:31 Message: Logged In: YES user_id=6656 This patch should not have been accepted. Relying on a floating point infinity to marhsal/unmarshal correctly is a bad idea. With the aid of the LC_NUMERIC agnostism patch, this patch breaks test_asynchat *when asyncore.pyc exists*. I don't have a windows machine with a CVS HEAD Python to check, but if 2.3 behaviour is retained, the upshot is that the count parameter will default to *1* if the code is loaded from a .pyc file. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-06-03 10:19 Message: Logged In: YES user_id=21627 Thanks for the patch. Applied as libasyncore.tex 1.15 asyncore.py 1.51 NEWS 1.986 ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-05-31 21:36 Message: Logged In: YES user_id=341410 The attached patch includes both a documentation patch, as well as a modified loop patch to explicitly match the documentation. The patches are concatenated and in standard context diff format (as per the Python patch submission guidelines, sorry about the previous unified diff). The test suite does not seem to contain tests for asyncore. It does contain a test for asynchat, which will be unaffected by this patch. One thing to note: the use of 'count = count - 1' rather than 'count -= 1' is to remove potential bugs in the case where a mutable number-like object with a modifying __isub__ method were to be passed by a user. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-05-31 19:32 Message: Logged In: YES user_id=21627 This patch lacks changes to the documentation and the test suite. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-05-20 07:26 Message: Logged In: YES user_id=341410 Sorry about that, I generated the patch by hand and got the ordering messed up. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=957240&group_id=5470 From noreply at sourceforge.net Tue Jun 15 06:45:40 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jun 15 18:47:18 2004 Subject: [Patches] [ python-Patches-957650 ] Fix for bugs relating to ntpath.expanduser() Message-ID: Patches item #957650, was opened at 2004-05-20 21:35 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=957650&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Josiah Carlson (josiahcarlson) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for bugs relating to ntpath.expanduser() Initial Comment: Attached is a patch for sf bug #796219 that fixes ntpath.expanduser() for paths that embed other environment variables, and also includes functionality that mirrors *nix-style ~user\extra expansions. I will comment with output from both the unpatched and patched version of ntpath. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2004-06-15 11:45 Message: Logged In: YES user_id=6656 This looks much better to me! ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-06-15 02:11 Message: Logged In: YES user_id=341410 What problem is needed? Perhaps you mean "this solution is desireable". ---------------------------------------------------------------------- Comment By: alan johnson (chomo) Date: 2004-06-14 21:44 Message: Logged In: YES user_id=943591 this problem maybe is whats needed ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-05-20 21:38 Message: Logged In: YES user_id=341410 I uploaded the testing as text to alleviate text wrapping issues that could confuse. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-05-20 21:36 Message: Logged In: YES user_id=341410 #test setup: >>> import os >>> os.environ['TESTING'] = '%TESTING1%' >>> os.environ['TESTING1'] = '%TESTING2%' >>> os.environ['TESTING2'] = 'Final\Path' #test standard ntpath >>> import ntpath >>> ntpath.expanduser('~') 'C:\Documents and Settings\jcarlson' >>> ntpath.expanduser('~billy') '~billy' >>> ntpath.expanduser('~billy\bob') '~billy\bob' >>> ntpath.expanduser('~\bob') 'C:\Documents and Settings\jcarlson\bob' >>> ntpath.expanduser('~billy\%TESTING%\%TESTING1%\%TESTING2%') '~billy\%TESTING%\%TESTING1%\%TESTING2%' #test patched ntpath >>> import ntpath_patched >>> ntpath_patched.expanduser('~') 'C:Documents and Settings\jcarlson' >>> ntpath_patched.expanduser('~billy') 'C:Documents and Settings\billy' >>> ntpath_patched.expanduser('~billy\bob') 'C:Documents and Settings\billy\bob' >>> ntpath_patched.expanduser('~\bob') 'C:Documents and Settings\jcarlson\bob' >>> ntpath_patched.expanduser('~billy\%TESTING%\%TESTING1%\%TESTING2%') 'C:Documents and Settings\billy\Final\Path\Final\Path\Final\Path' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=957650&group_id=5470 From noreply at sourceforge.net Tue Jun 15 07:33:47 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jun 15 19:03:54 2004 Subject: [Patches] [ python-Patches-966493 ] Cleanup generator/eval_frame exposure Message-ID: Patches item #966493, was opened at 2004-06-04 07:58 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=966493&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: James William Pye (jwpye) >Assigned to: Martin v. L?wis (loewis) Summary: Cleanup generator/eval_frame exposure Initial Comment: Hopefully get this cleanup in before 2.4.. . Include genobject.h in Python.h to save embedders an AC check to identify its existance(allowing a simple #ifndef Py_GENOBJECT_H) . Follow up my own recommendation to just reference eval_frame directly by exposing it(change references in ceval.c and genobject.c accordingly). . Update headers accordingly; reference frameobject in genobject.h and ceval.h as struct _frame * like others do to avoid including frameobject.h Rename PyEval_EvaluateFrame to PyEval_EvalFrame to be consistent with PyEval_EvalCode[Ex] in eval.h. Hopefully it isnt too late to change this before 2.4, sorry for not having it in the first patch.. :-( Changes files: genobject.c genobject.h ceval.c ceval.h Python.h ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-06-15 06:33 Message: Logged In: YES user_id=80475 Martin, I believe this patches your checkin. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=966493&group_id=5470 From noreply at sourceforge.net Tue Jun 15 08:05:41 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jun 15 20:06:41 2004 Subject: [Patches] [ python-Patches-968063 ] Add fileinput.islastline() Message-ID: Patches item #968063, was opened at 2004-06-07 04:45 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=968063&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Relm Arrowny (relm) Assigned to: Nobody/Anonymous (nobody) Summary: Add fileinput.islastline() Initial Comment: You can test for the first line of a file with fileinput.isfirstline(), but there is no corresponding fileinput.islastline() to test for the last line of a file. Note that there is already an unapplied patch for this at request ID 776100, but it is faulty in that it only tests for end of buffer and not end of file. I was not sure how to append this patch to the existing request, so have started a new one. Hope this is okay. This patch also includes documentation and test updates. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-06-15 07:05 Message: Logged In: YES user_id=80475 I'm -0 on complicating this venerable interface. Also, I find it unnatural for the inside of a loop to be able to ascertain whether it is in its final iteration. The closest approximation is the for-else clause which is vary rarely used in normal python programming. While the OP was able to sketch a use case, it involved only saving a couple of lines over what can be done with the existing API. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=968063&group_id=5470 From natalystatewide at dcemail.com Tue Jun 15 20:23:05 2004 From: natalystatewide at dcemail.com (Paulwong) Date: Tue Jun 15 20:24:03 2004 Subject: [Patches] Re: Fwd: Stop to risk your life. Annette Message-ID: An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20040616/04c9b473/attachment-0001.html From kphpwp at ciaoweb.it Tue Jun 15 19:00:17 2004 From: kphpwp at ciaoweb.it (Bridget Maynard) Date: Tue Jun 15 20:54:57 2004 Subject: [Patches] Incredible software deals pine cone 4469 bubbles Message-ID: An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20040615/a4db2a91/attachment.html From noreply at sourceforge.net Tue Jun 15 21:48:20 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jun 15 21:48:27 2004 Subject: [Patches] [ python-Patches-967763 ] fix bsddb memory leaks Message-ID: Patches item #967763, was opened at 2004-06-06 16:51 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=967763&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Gregory P. Smith (greg) Summary: fix bsddb memory leaks Initial Comment: only one of the changes fixed a leak reported by valgrind, but i think all the changes are necessary. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2004-06-15 21:48 Message: Logged In: YES user_id=33168 should FREE_DBT() be called clearTxn() and friends fail? one memory leak is caused in DB_get() by test_recno, line 75 (d.get(100)). if the FREE_DBT()s at line 1392-1393 are moved outside the if, so they always execute the leak goes away. i'm not sure if this is really the correct solution though. the other leak is in test_compat, don't know anything more. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2004-06-14 21:47 Message: Logged In: YES user_id=413 Thanks, I hadn't caught up on python-dev in a while. What happens if you apply my attached patch and rerun the test under valgrind? The 4 bytes leaked sounds exactly like what i was expecting reading the code (an integer key causes make_key_dbt to alloc a 32bit value). in the DBC_set_range case without the patch i believe it is likely that the integer is allocated but the REALLOC flag is overridden in the old code with a MALLOC causing BerkeleyDB to leak the old pointer and allocate a new key for the return value (btree accessed using an integer key). 8 bytes in 2 blocks leaked in DB_get is double what i expected but without debug info showing the DB_get function call arguments and database flags its hard to say what happened. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2004-06-14 21:36 Message: Logged In: YES user_id=33168 I just run the regression tests. Did you see my mail to python-dev? http://mail.python.org/pipermail/python-dev/2004-June/045245.html Here's the bsddb leaks reported by valgrind: 4 bytes in 1 blocks are definitely lost in loss record 7 of 663 at 0x3C01DA1D: malloc (vg_replace_malloc.c:109) by 0x3C928265: make_key_dbt (_bsddb.c:400) by 0x3C92DE4F: DBC_set_range (_bsddb.c:2911) 8 bytes in 2 blocks are definitely lost in loss record 29 of 663 at 0x3C01DA1D: malloc (vg_replace_malloc.c:109) by 0x3C928265: make_key_dbt (_bsddb.c:400) by 0x3C929088: DB_get (_bsddb.c:1349) ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2004-06-14 20:02 Message: Logged In: YES user_id=413 make_key_dbt() will never return with an error leaving a FREE_DBT(key) necessary. however looking in depth at the code i believe it would have been possible to have a leak when using integer keys and exiting early with an error. a patch (untested) that should fix that is attached. i'll test it out later. do you have any memleak test cases by any chance? ---------------------------------------------------------------------- Comment By: alan johnson (chomo) Date: 2004-06-14 17:11 Message: Logged In: YES user_id=943591 looks like the ones needed anyway ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2004-06-13 16:56 Message: Logged In: YES user_id=33168 Greg, just wanted to make sure you saw this. It seems like you're the only one working on bsddb these days. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=967763&group_id=5470 From noreply at sourceforge.net Tue Jun 15 22:21:54 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jun 15 22:22:11 2004 Subject: [Patches] [ python-Patches-665458 ] Crash in binascii_a2b_uu on corrupt data Message-ID: Patches item #665458, was opened at 2003-01-09 21:44 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=665458&group_id=5470 Category: Library (Lib) Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Michael Scharf (scharf) >Assigned to: Neal Norwitz (nnorwitz) Summary: Crash in binascii_a2b_uu on corrupt data Initial Comment: When I unpacked 50 gigabytes of randomly downloaded usenet binary news posts python crashed (randomly) on windows. After long tracking (I did'nt have a debug version) I found the problem in binascii_a2b_uu: When reading the input data, the boundaries of the input sting are not checked. With corrupted uuencoded data (the first bite gives the length of the encoded string), the function reads out of bounds of the input string. That is not a problem (in most cases) but sometimes (it happened typicallyafter 20-30 gibagytes of parsed data) the allocated string might be at the end of a memory 'segment' and there is no string after the allocated string. And that causes a crash. I have attached a patch to solve the problem. (Python 2.2.2) Michael ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2004-06-15 22:21 Message: Logged In: YES user_id=33168 I checked in the change in the previous comment. Modules/binascii.c 2.41 I believe that checkin solves this problem, so closing. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-16 16:42 Message: Logged In: YES user_id=33168 I agree there is a problem, although I'm concerned about changing the behaviour. Currently, if the data is short it is, it is filled with null characters. With this patch an exception is raised. Ideally, the patch is correct, but my concern is that many people rely on the output being null-filled. I believe the following change around line 207, keeps the behaviour and would avoid the crash: - this_ch = *ascii_data; + this_ch = (ascii_len > 0) ? *ascii_data : 0; ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=665458&group_id=5470 From noreply at sourceforge.net Tue Jun 15 22:25:55 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jun 15 22:26:02 2004 Subject: [Patches] [ python-Patches-638673 ] Added Proxyauth command to imaplib Message-ID: Patches item #638673, was opened at 2002-11-14 16:27 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=638673&group_id=5470 Category: Library (Lib) Group: Python 2.2.x >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Richard L. Holbert (rholbert) >Assigned to: Neal Norwitz (nnorwitz) Summary: Added Proxyauth command to imaplib Initial Comment: Allows the Admin user to access any other user's mailbox. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2004-06-15 22:25 Message: Logged In: YES user_id=33168 This was checked in 22-Nov-02, by piers, Lib/imaplib.py 1.57 ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-14 18:23 Message: Logged In: YES user_id=33168 Richard, thanks for the patch. I have a couple of problems with the patch. * The patch is against 2.2, not HEAD. In this case it's easy to see where it should go, but that isn't always the case. * This patch contains tabs, all python code in the standard library should contain only spaces. * In the code that was added, name is not used. Either name should be removed, or it should be passed to _simple_command(). * There is also no documentation (Doc/lib/libimap.tex). I don't know if this patch is worthwhile, since I know nothing about imap. Someone else will have to determine if this proxyauth is generally applicable and should be included. However, are there any security issues associated with using proxyauth? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=638673&group_id=5470 From noreply at sourceforge.net Thu Jun 17 05:07:18 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jun 17 05:09:17 2004 Subject: [Patches] [ python-Patches-943898 ] A simple 3-4% speed-up for PCs Message-ID: Patches item #943898, was opened at 2004-04-28 13:33 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=943898&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: Accepted Priority: 5 Submitted By: Armin Rigo (arigo) >Assigned to: Armin Rigo (arigo) Summary: A simple 3-4% speed-up for PCs Initial Comment: The result of a few experiments looking at the assembler produced by gcc for eval_frame(): * on PCs, reading the arguments as an unsigned short instead of two bytes is a good win. * oparg is more "local" with this patch: its value doesn't need to be saved across an iteration of the main loop, allowing it to live in a register only. * added an explicit "case STOP_CODE:" so that the switch starts at 0 instead of 1 -- that's one instruction less with gcc. * it seems not to pay off to move reading the argument at the start of each case of an operation that expects one, even though it removes the unpredictable branch "if (HAS_ARG(op))". This patch should be timed on other platforms to make sure that it doesn't slow things down. If it does, then only reading the arg as an unsigned short could be checked in -- it is compilation-conditional over the fact that shorts are 2 bytes in little endian order. By the way, anyone knows why 'stack_pointer' isn't a 'register' local? I bet it would make a difference on PowerPC, for example, with compilers that care about this keyword. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-06-17 03:50 Message: Logged In: YES user_id=80475 Very nice. Code passes review, passes regression tests, and the timings were confirmed (Pentium III running Win ME with MSVC++ 6.0). Please apply. Though this patch is very clean, we do not backport performance tweaks. The only exception would be to repair devastatingly bad performance. Let this be some incentive to step up to Py2.4. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-06-17 02:35 Message: Logged In: YES user_id=4771 The patch no longer cleanly applies, so here is it again. This one is minimalistic and does not contain the 386-specific register tweaks. It only allows two variables (stack_pointer and oparg) to be stored in registers instead of the stack on machines that have enough of them. I still regard this as a small performance bugfix and suggest back-porting. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-05-21 10:44 Message: Logged In: YES user_id=4771 The bit with gcc-specific keywords is useful but arguably scary, but the other part of the patch -- stack_pointer not being assignable to a register -- solves a definite performance bug in my opinion. I'd even suggest back-porting this one to 2.3. Apple is more likely to ship its next MacOSX release with the latest 2.3 than with 2.4, as far as I can tell. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-05-12 10:27 Message: Logged In: YES user_id=80475 Tim, I remember you having some options about these sort of optimizations. Will you take a brief look at Armin's latest patch. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-05-10 09:26 Message: Logged In: YES user_id=4771 Tested on a MacOSX box, the patch also gives a 5% speed-up there. Allowing stack_pointer to be in a register is a very good idea. (all tests with Pystone) ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-05-10 05:48 Message: Logged In: YES user_id=4771 The short trick might be a bit fragile. For example, the current patch would incorrectly use it on machines where unaligned accesses are forbidden. I isolated the other issue I talked about (making stack_pointer a register variable) in a separate patch. This patch alone is clearly safe. It should give a bit of speed-up on any machine but it definitely gives 5% on PCs with gcc by forcing the two most important local variables into specific registers. (If someone knows the corresponding syntax for other compilers, it can be added in the #if.) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-04-28 18:45 Message: Logged In: YES user_id=80475 With MSVC++ 6.0 under WinME on a Pentium III, there is no change in timing (measurements accurate within 0.25%): I wonder if the speedup from retrieving the unsigned short is offset by alignment penalties when the starting address is odd. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-04-28 16:02 Message: Logged In: YES user_id=4771 stack_pointer isn't a register because its address is taken at two places. This is a really bad idea for optimization. Instead of &stack_pointer, we should do: PyObject **sp = stack_pointer; ... use &sp ... stack_pointer = sp; I'm pretty sure this simple change along with a 'register' declaration of stack_pointer gives a good speed-up on all architectures with plenty of registers. For PCs I've experimented with forcing one or two locals into specific registers, with the gcc syntax asm("esi"), asm("ebx"), etc. Forcing stack_pointer and next_instr gives another 3-4% of improvement. Next step is to see if this can be done with #if's for common compilers beside gcc. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=943898&group_id=5470 From besttopsoftwarepardon at yahoo.com Thu Jun 17 05:25:47 2004 From: besttopsoftwarepardon at yahoo.com (Kristian) Date: Thu Jun 17 05:26:01 2004 Subject: [Patches] attn: Any sof.tware just for 20 dollars. bimetallic Message-ID: An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20040617/9971a4b8/attachment.html From noreply at sourceforge.net Thu Jun 17 04:50:21 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jun 17 07:57:48 2004 Subject: [Patches] [ python-Patches-943898 ] A simple 3-4% speed-up for PCs Message-ID: Patches item #943898, was opened at 2004-04-28 13:33 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=943898&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open >Resolution: Accepted Priority: 5 Submitted By: Armin Rigo (arigo) >Assigned to: Raymond Hettinger (rhettinger) Summary: A simple 3-4% speed-up for PCs Initial Comment: The result of a few experiments looking at the assembler produced by gcc for eval_frame(): * on PCs, reading the arguments as an unsigned short instead of two bytes is a good win. * oparg is more "local" with this patch: its value doesn't need to be saved across an iteration of the main loop, allowing it to live in a register only. * added an explicit "case STOP_CODE:" so that the switch starts at 0 instead of 1 -- that's one instruction less with gcc. * it seems not to pay off to move reading the argument at the start of each case of an operation that expects one, even though it removes the unpredictable branch "if (HAS_ARG(op))". This patch should be timed on other platforms to make sure that it doesn't slow things down. If it does, then only reading the arg as an unsigned short could be checked in -- it is compilation-conditional over the fact that shorts are 2 bytes in little endian order. By the way, anyone knows why 'stack_pointer' isn't a 'register' local? I bet it would make a difference on PowerPC, for example, with compilers that care about this keyword. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-06-17 03:50 Message: Logged In: YES user_id=80475 Very nice. Code passes review, passes regression tests, and the timings were confirmed (Pentium III running Win ME with MSVC++ 6.0). Please apply. Though this patch is very clean, we do not backport performance tweaks. The only exception would be to repair devastatingly bad performance. Let this be some incentive to step up to Py2.4. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-06-17 02:35 Message: Logged In: YES user_id=4771 The patch no longer cleanly applies, so here is it again. This one is minimalistic and does not contain the 386-specific register tweaks. It only allows two variables (stack_pointer and oparg) to be stored in registers instead of the stack on machines that have enough of them. I still regard this as a small performance bugfix and suggest back-porting. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-05-21 10:44 Message: Logged In: YES user_id=4771 The bit with gcc-specific keywords is useful but arguably scary, but the other part of the patch -- stack_pointer not being assignable to a register -- solves a definite performance bug in my opinion. I'd even suggest back-porting this one to 2.3. Apple is more likely to ship its next MacOSX release with the latest 2.3 than with 2.4, as far as I can tell. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-05-12 10:27 Message: Logged In: YES user_id=80475 Tim, I remember you having some options about these sort of optimizations. Will you take a brief look at Armin's latest patch. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-05-10 09:26 Message: Logged In: YES user_id=4771 Tested on a MacOSX box, the patch also gives a 5% speed-up there. Allowing stack_pointer to be in a register is a very good idea. (all tests with Pystone) ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-05-10 05:48 Message: Logged In: YES user_id=4771 The short trick might be a bit fragile. For example, the current patch would incorrectly use it on machines where unaligned accesses are forbidden. I isolated the other issue I talked about (making stack_pointer a register variable) in a separate patch. This patch alone is clearly safe. It should give a bit of speed-up on any machine but it definitely gives 5% on PCs with gcc by forcing the two most important local variables into specific registers. (If someone knows the corresponding syntax for other compilers, it can be added in the #if.) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-04-28 18:45 Message: Logged In: YES user_id=80475 With MSVC++ 6.0 under WinME on a Pentium III, there is no change in timing (measurements accurate within 0.25%): I wonder if the speedup from retrieving the unsigned short is offset by alignment penalties when the starting address is odd. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-04-28 16:02 Message: Logged In: YES user_id=4771 stack_pointer isn't a register because its address is taken at two places. This is a really bad idea for optimization. Instead of &stack_pointer, we should do: PyObject **sp = stack_pointer; ... use &sp ... stack_pointer = sp; I'm pretty sure this simple change along with a 'register' declaration of stack_pointer gives a good speed-up on all architectures with plenty of registers. For PCs I've experimented with forcing one or two locals into specific registers, with the gcc syntax asm("esi"), asm("ebx"), etc. Forcing stack_pointer and next_instr gives another 3-4% of improvement. Next step is to see if this can be done with #if's for common compilers beside gcc. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=943898&group_id=5470 From frohar at sympatico.ca Thu Jun 17 09:07:43 2004 From: frohar at sympatico.ca (Spear V. Frantic) Date: Thu Jun 17 09:07:56 2004 Subject: [Patches] Read:_Cheape software - all you can imagine Message-ID: <5405336492.20040617080743@sympatico.ca> >Abel Danial Donnell Horace David Esther Odis Ahmad Sensation!! We opened a NEW site with unbeatable prices and products. 800 WORLD BEST software with 90% discount - that is a really BEST offer just imagine, you can buy ALL software that you ever need and pay price of just one of it! Office 2003 for 50$ - nice deal right ? ;) retail price is 700$ - great savings, huh? Please spend few moments of yours precious time to check our offer - it is more than worth it! http://Bret.discounted-soft.biz/?Carlton >The golden age is before us, not behind us. >The pious pretence that evil does not exist only makes it vague, enormous and menacing. >Love is blind friendship closes its eyes. >Man cannot live by incompetence alone. >When in doubt, wear red. >Give light and people will find their own way. >The very aim and end of our institutions is just this: that we may thing what we like and say what we think. >When we are not sure, we are alive. >Sentences are like sharp nails, which force truth upon our memories. >To take refuge with an inferior is to betray one's self. >These two imparadised in one another's arms, the happier Eden, shall enjoy their fill of bliss on bliss. >My work is done why wait. >An idea is a feat of association, and the height of it is a good metaphor. >Whenever books are burned men also in the end are burned. >Only those who want everything done for them are bored. >Never chain your dogs together with sausages. One must accustom one's self to be bored. >Leadership is the wise use of power. Power is the capacity to translate intention into reality and sustain it. >Happiness never lays its finger on its pulse. >When you cannot get a compliment in any other way pay yourself one. From noreply at sourceforge.net Thu Jun 17 03:35:42 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jun 17 10:33:11 2004 Subject: [Patches] [ python-Patches-943898 ] A simple 3-4% speed-up for PCs Message-ID: Patches item #943898, was opened at 2004-04-28 18:33 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=943898&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Tim Peters (tim_one) Summary: A simple 3-4% speed-up for PCs Initial Comment: The result of a few experiments looking at the assembler produced by gcc for eval_frame(): * on PCs, reading the arguments as an unsigned short instead of two bytes is a good win. * oparg is more "local" with this patch: its value doesn't need to be saved across an iteration of the main loop, allowing it to live in a register only. * added an explicit "case STOP_CODE:" so that the switch starts at 0 instead of 1 -- that's one instruction less with gcc. * it seems not to pay off to move reading the argument at the start of each case of an operation that expects one, even though it removes the unpredictable branch "if (HAS_ARG(op))". This patch should be timed on other platforms to make sure that it doesn't slow things down. If it does, then only reading the arg as an unsigned short could be checked in -- it is compilation-conditional over the fact that shorts are 2 bytes in little endian order. By the way, anyone knows why 'stack_pointer' isn't a 'register' local? I bet it would make a difference on PowerPC, for example, with compilers that care about this keyword. ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2004-06-17 07:35 Message: Logged In: YES user_id=4771 The patch no longer cleanly applies, so here is it again. This one is minimalistic and does not contain the 386-specific register tweaks. It only allows two variables (stack_pointer and oparg) to be stored in registers instead of the stack on machines that have enough of them. I still regard this as a small performance bugfix and suggest back-porting. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-05-21 15:44 Message: Logged In: YES user_id=4771 The bit with gcc-specific keywords is useful but arguably scary, but the other part of the patch -- stack_pointer not being assignable to a register -- solves a definite performance bug in my opinion. I'd even suggest back-porting this one to 2.3. Apple is more likely to ship its next MacOSX release with the latest 2.3 than with 2.4, as far as I can tell. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-05-12 15:27 Message: Logged In: YES user_id=80475 Tim, I remember you having some options about these sort of optimizations. Will you take a brief look at Armin's latest patch. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-05-10 14:26 Message: Logged In: YES user_id=4771 Tested on a MacOSX box, the patch also gives a 5% speed-up there. Allowing stack_pointer to be in a register is a very good idea. (all tests with Pystone) ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-05-10 10:48 Message: Logged In: YES user_id=4771 The short trick might be a bit fragile. For example, the current patch would incorrectly use it on machines where unaligned accesses are forbidden. I isolated the other issue I talked about (making stack_pointer a register variable) in a separate patch. This patch alone is clearly safe. It should give a bit of speed-up on any machine but it definitely gives 5% on PCs with gcc by forcing the two most important local variables into specific registers. (If someone knows the corresponding syntax for other compilers, it can be added in the #if.) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-04-28 23:45 Message: Logged In: YES user_id=80475 With MSVC++ 6.0 under WinME on a Pentium III, there is no change in timing (measurements accurate within 0.25%): I wonder if the speedup from retrieving the unsigned short is offset by alignment penalties when the starting address is odd. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-04-28 21:02 Message: Logged In: YES user_id=4771 stack_pointer isn't a register because its address is taken at two places. This is a really bad idea for optimization. Instead of &stack_pointer, we should do: PyObject **sp = stack_pointer; ... use &sp ... stack_pointer = sp; I'm pretty sure this simple change along with a 'register' declaration of stack_pointer gives a good speed-up on all architectures with plenty of registers. For PCs I've experimented with forcing one or two locals into specific registers, with the gcc syntax asm("esi"), asm("ebx"), etc. Forcing stack_pointer and next_instr gives another 3-4% of improvement. Next step is to see if this can be done with #if's for common compilers beside gcc. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=943898&group_id=5470 From noreply at sourceforge.net Thu Jun 17 06:23:50 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jun 17 11:57:47 2004 Subject: [Patches] [ python-Patches-943898 ] A simple 3-4% speed-up for PCs Message-ID: Patches item #943898, was opened at 2004-04-28 18:33 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=943898&group_id=5470 Category: Core (C code) Group: Python 2.4 >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Armin Rigo (arigo) >Assigned to: Tim Peters (tim_one) Summary: A simple 3-4% speed-up for PCs Initial Comment: The result of a few experiments looking at the assembler produced by gcc for eval_frame(): * on PCs, reading the arguments as an unsigned short instead of two bytes is a good win. * oparg is more "local" with this patch: its value doesn't need to be saved across an iteration of the main loop, allowing it to live in a register only. * added an explicit "case STOP_CODE:" so that the switch starts at 0 instead of 1 -- that's one instruction less with gcc. * it seems not to pay off to move reading the argument at the start of each case of an operation that expects one, even though it removes the unpredictable branch "if (HAS_ARG(op))". This patch should be timed on other platforms to make sure that it doesn't slow things down. If it does, then only reading the arg as an unsigned short could be checked in -- it is compilation-conditional over the fact that shorts are 2 bytes in little endian order. By the way, anyone knows why 'stack_pointer' isn't a 'register' local? I bet it would make a difference on PowerPC, for example, with compilers that care about this keyword. ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2004-06-17 10:23 Message: Logged In: YES user_id=4771 Checked in as ceval.c 2.400. Let's forget about the GCC-specific extension and close the patch. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-06-17 08:50 Message: Logged In: YES user_id=80475 Very nice. Code passes review, passes regression tests, and the timings were confirmed (Pentium III running Win ME with MSVC++ 6.0). Please apply. Though this patch is very clean, we do not backport performance tweaks. The only exception would be to repair devastatingly bad performance. Let this be some incentive to step up to Py2.4. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-06-17 07:35 Message: Logged In: YES user_id=4771 The patch no longer cleanly applies, so here is it again. This one is minimalistic and does not contain the 386-specific register tweaks. It only allows two variables (stack_pointer and oparg) to be stored in registers instead of the stack on machines that have enough of them. I still regard this as a small performance bugfix and suggest back-porting. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-05-21 15:44 Message: Logged In: YES user_id=4771 The bit with gcc-specific keywords is useful but arguably scary, but the other part of the patch -- stack_pointer not being assignable to a register -- solves a definite performance bug in my opinion. I'd even suggest back-porting this one to 2.3. Apple is more likely to ship its next MacOSX release with the latest 2.3 than with 2.4, as far as I can tell. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-05-12 15:27 Message: Logged In: YES user_id=80475 Tim, I remember you having some options about these sort of optimizations. Will you take a brief look at Armin's latest patch. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-05-10 14:26 Message: Logged In: YES user_id=4771 Tested on a MacOSX box, the patch also gives a 5% speed-up there. Allowing stack_pointer to be in a register is a very good idea. (all tests with Pystone) ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-05-10 10:48 Message: Logged In: YES user_id=4771 The short trick might be a bit fragile. For example, the current patch would incorrectly use it on machines where unaligned accesses are forbidden. I isolated the other issue I talked about (making stack_pointer a register variable) in a separate patch. This patch alone is clearly safe. It should give a bit of speed-up on any machine but it definitely gives 5% on PCs with gcc by forcing the two most important local variables into specific registers. (If someone knows the corresponding syntax for other compilers, it can be added in the #if.) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-04-28 23:45 Message: Logged In: YES user_id=80475 With MSVC++ 6.0 under WinME on a Pentium III, there is no change in timing (measurements accurate within 0.25%): I wonder if the speedup from retrieving the unsigned short is offset by alignment penalties when the starting address is odd. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-04-28 21:02 Message: Logged In: YES user_id=4771 stack_pointer isn't a register because its address is taken at two places. This is a really bad idea for optimization. Instead of &stack_pointer, we should do: PyObject **sp = stack_pointer; ... use &sp ... stack_pointer = sp; I'm pretty sure this simple change along with a 'register' declaration of stack_pointer gives a good speed-up on all architectures with plenty of registers. For PCs I've experimented with forcing one or two locals into specific registers, with the gcc syntax asm("esi"), asm("ebx"), etc. Forcing stack_pointer and next_instr gives another 3-4% of improvement. Next step is to see if this can be done with #if's for common compilers beside gcc. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=943898&group_id=5470 From AMPEXHQHOY at zuma-mannheim.de Thu Jun 17 14:51:25 2004 From: AMPEXHQHOY at zuma-mannheim.de (Chad Carrier) Date: Thu Jun 17 13:51:08 2004 Subject: [Patches] want a university degree without going to university? Message-ID: <200406171750.i5HHop5b079538@mxzilla4.xs4all.nl> An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20040617/04406614/attachment.html From noreply at sourceforge.net Thu Jun 17 12:08:09 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jun 17 19:31:43 2004 Subject: [Patches] [ python-Patches-960406 ] unblock signals in threads Message-ID: Patches item #960406, was opened at 2004-05-25 22:00 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=960406&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Andrew Langmead (langmead) Assigned to: Nobody/Anonymous (nobody) Summary: unblock signals in threads Initial Comment: This is a patch which will correct the issues some people have with python's handling of signal handling in threads. It allows any thread to initially catch the signal mark it as triggered, allowing the main thread to later process it. (This is actually just restoring access to the functionality that was in Python 2.1) The special SIGINT handling for the python readline module has been changed so that it can now see an EINTR error code, rather than needing a longjmp out of the readline library itself. If the readline library python is being linked to doesn't have the callback features necessary, it will fall back to its old behavior. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2004-06-17 17:08 Message: Logged In: YES user_id=6656 A potential problem with this patch is that it causes input to be interrupted (with a KeyboardInterrupt exception) when any handled signal is delivered. This seems suboptimal. It's appealing to try to run the (Python) signal handlers in the errno == EINTR case of readline_line_until_enter_or_signal, but that has problems in that PyOS_ReadlineFunctionPointer is called without the GIL being held and once that is dealt with, an installed Python signal handler attempting to call readline at this point can reasonably be expected to result in all hell breaking loose. I don't know what the correct solution is here. Add our own rentrancy checks and learn how to work the Python threadstate API properly? Thoughts, anyone? Or have I scared everyone away now? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-12 11:17 Message: Logged In: YES user_id=6656 Now a rewrite of the test that actually works! ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-12 11:08 Message: Logged In: YES user_id=6656 Here's a version of the patch that includes the new unit test (oops!) which I've rewritten slightly. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-06-11 17:02 Message: Logged In: YES user_id=29957 No - wait. Ignore that test_timeout error, it exists with a clean checkout. The inability to interrupt make testall, however is new with this patch. Linux Fedora Core 2. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-06-11 16:58 Message: Logged In: YES user_id=29957 With this patch: bonanza% ./python Lib/test/test_timeout.py testBlockingThenTimeout (__main__.CreationTestCase) ... ok testFloatReturnValue (__main__.CreationTestCase) ... ok testObjectCreation (__main__.CreationTestCase) ... ok testRangeCheck (__main__.CreationTestCase) ... ok testReturnType (__main__.CreationTestCase) ... ok testTimeoutThenBlocking (__main__.CreationTestCase) ... ok testTypeCheck (__main__.CreationTestCase) ... ok testAcceptTimeout (__main__.TimeoutTestCase) ... ok testConnectTimeout (__main__.TimeoutTestCase) ... FAIL testRecvTimeout (__main__.TimeoutTestCase) ... ok testRecvfromTimeout (__main__.TimeoutTestCase) ... ok testSend (__main__.TimeoutTestCase) ... ok testSendall (__main__.TimeoutTestCase) ... ok testSendto (__main__.TimeoutTestCase) ... ok ====================================================================== FAIL: testConnectTimeout (__main__.TimeoutTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "Lib/test/test_timeout.py", line 121, in testConnectTimeout "timeout (%g) is more than %g seconds more than expected (%g)" AssertionError: timeout (4.48679) is more than 2 seconds more than expected (0.001) ---------------------------------------------------------------------- Ran 14 tests in 17.445s FAILED (failures=1) Traceback (most recent call last): File "Lib/test/test_timeout.py", line 192, in ? test_main() File "Lib/test/test_timeout.py", line 189, in test_main test_support.run_unittest(CreationTestCase, TimeoutTestCase) File "/home/anthony/src/py/pyhead/dist/src/Lib/test/test_support.py", line 290, in run_unittest run_suite(suite, testclass) File "/home/anthony/src/py/pyhead/dist/src/Lib/test/test_support.py", line 275, in run_suite raise TestFailed(err) test.test_support.TestFailed: Traceback (most recent call last): File "Lib/test/test_timeout.py", line 121, in testConnectTimeout "timeout (%g) is more than %g seconds more than expected (%g)" AssertionError: timeout (4.48679) is more than 2 seconds more than expected (0.001) Also, with this patch applied, I can no longer kill a 'make testall' with a ^C ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-11 15:18 Message: Logged In: YES user_id=6656 The patch didn't apply, so I've updated it (attached). I see test_asynchat fail occasionally now, but don't know if that's because of this patch :-( Once I've sorted that out in my head, I think I'm going to check this in. ---------------------------------------------------------------------- Comment By: Andrew Langmead (langmead) Date: 2004-05-29 06:49 Message: Logged In: YES user_id=119306 Here is a reformatted version of the patch. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-05-28 15:25 Message: Logged In: YES user_id=31435 I agree that "busy" always should have been volatile -- once again, good eye! Python C style is basically K&R Classic, hard tab for indentation, open curly at the end of the line opening a block except for first line of function definition. Just make it look like the other C code, but be careful to pick one of the .c files Guido approves of . ---------------------------------------------------------------------- Comment By: Andrew Langmead (langmead) Date: 2004-05-28 13:37 Message: Logged In: YES user_id=119306 Thank you for pointing me to PEP 7. I'll take a look at where I am amiss and fix it up. For the change in ceval.c, I took a look at gcc's x86 assembly output of the file, and noticed that the optimizer was altering the order of the busy flag test. Since busy is set from other concurrent execution (other signal handlers), changing the variable to volatile told gcc not to optimize accesses to the variable. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-28 09:54 Message: Logged In: YES user_id=6656 I haven't been able to test on MacOS X further, unfortunately. The patch works on linux/x86 though (after fixing the TabError :-) but this is with an NTPL kernel, so I didn't have a problem anyway. The C doesn't all conform to the Python style -- see PEP 7. Can you fix that? Why the change to Python/ceval.c? After all that -- thanks a lot! I really want to get this checked in ASAP so we can find out which platforms it breaks at the earliest point in the 2.4 cycle. ---------------------------------------------------------------------- Comment By: Andrew Langmead (langmead) Date: 2004-05-27 07:04 Message: Logged In: YES user_id=119306 It seems that at least OS X, sending the kill to the process schedules that the receiving process will run the signal handler at some later time. (it seems to be the only one to frequently run the signal handlers in the opposite order than they were sent) This revised version of the test seems to work better on OS X. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-26 19:41 Message: Logged In: YES user_id=6656 test_threadsignals hangs for me on OS X. Haven't done anything more thorough than that yet... ---------------------------------------------------------------------- Comment By: Andrew Langmead (langmead) Date: 2004-05-26 18:48 Message: Logged In: YES user_id=119306 I apologize that the missing patch. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-26 18:22 Message: Logged In: YES user_id=6656 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. In addition, even if you *did* check this checkbox, a bug in SourceForge prevents attaching a file when *creating* an issue. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=960406&group_id=5470 From noreply at sourceforge.net Thu Jun 17 20:05:35 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jun 18 01:14:29 2004 Subject: [Patches] [ python-Patches-975056 ] Signal fixes for BSD systems Message-ID: Patches item #975056, was opened at 2004-06-18 10:05 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=975056&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Luke Mewburn (lukem) Assigned to: Nobody/Anonymous (nobody) Summary: Signal fixes for BSD systems Initial Comment: As documented in bug 969574, restartable signals are not correctly disabled on BSD systems (e.g, NetBSD 2.0, FreeBSD 4.8). The attached patch is a more complete version of the one I provided in that bug report, and it more closely follows the patch submission guidelines (context instead of unified diff, against python CVS instead of python 2.3.4, ...). It also fixes: * A few sections of the tree that weren't converted from signal() to PyOS_setsig(). * There's no need to call siginterrupt() before PyOS_setsig() in Module/signalmodule.c because PyOS_setsig() handles that, and calling siginterrupt() before changing a signal's handler (via signal/sigaction) doesn't work correctly anyway; it should have been called after. I have compiled the source with and without "--without-signal-module" and successfully run "make test" on both cases. Suggested NEWS entry: === Bug #969574: Restartable signals were not correctly disabled on BSD systems. Consistently use PyOS_setsig() instead of signal(). === Cheers, Luke. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=975056&group_id=5470 From noreply at sourceforge.net Thu Jun 17 13:25:26 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jun 20 23:40:29 2004 Subject: [Patches] [ python-Patches-960406 ] unblock signals in threads Message-ID: Patches item #960406, was opened at 2004-05-25 22:00 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=960406&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None >Priority: 6 Submitted By: Andrew Langmead (langmead) Assigned to: Nobody/Anonymous (nobody) Summary: unblock signals in threads Initial Comment: This is a patch which will correct the issues some people have with python's handling of signal handling in threads. It allows any thread to initially catch the signal mark it as triggered, allowing the main thread to later process it. (This is actually just restoring access to the functionality that was in Python 2.1) The special SIGINT handling for the python readline module has been changed so that it can now see an EINTR error code, rather than needing a longjmp out of the readline library itself. If the readline library python is being linked to doesn't have the callback features necessary, it will fall back to its old behavior. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2004-06-17 18:25 Message: Logged In: YES user_id=6656 BTW, I'd really really like someone to review this :-) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-17 18:24 Message: Logged In: YES user_id=6656 How about the attached? It's a bit ... scary. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-17 17:08 Message: Logged In: YES user_id=6656 A potential problem with this patch is that it causes input to be interrupted (with a KeyboardInterrupt exception) when any handled signal is delivered. This seems suboptimal. It's appealing to try to run the (Python) signal handlers in the errno == EINTR case of readline_line_until_enter_or_signal, but that has problems in that PyOS_ReadlineFunctionPointer is called without the GIL being held and once that is dealt with, an installed Python signal handler attempting to call readline at this point can reasonably be expected to result in all hell breaking loose. I don't know what the correct solution is here. Add our own rentrancy checks and learn how to work the Python threadstate API properly? Thoughts, anyone? Or have I scared everyone away now? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-12 11:17 Message: Logged In: YES user_id=6656 Now a rewrite of the test that actually works! ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-12 11:08 Message: Logged In: YES user_id=6656 Here's a version of the patch that includes the new unit test (oops!) which I've rewritten slightly. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-06-11 17:02 Message: Logged In: YES user_id=29957 No - wait. Ignore that test_timeout error, it exists with a clean checkout. The inability to interrupt make testall, however is new with this patch. Linux Fedora Core 2. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-06-11 16:58 Message: Logged In: YES user_id=29957 With this patch: bonanza% ./python Lib/test/test_timeout.py testBlockingThenTimeout (__main__.CreationTestCase) ... ok testFloatReturnValue (__main__.CreationTestCase) ... ok testObjectCreation (__main__.CreationTestCase) ... ok testRangeCheck (__main__.CreationTestCase) ... ok testReturnType (__main__.CreationTestCase) ... ok testTimeoutThenBlocking (__main__.CreationTestCase) ... ok testTypeCheck (__main__.CreationTestCase) ... ok testAcceptTimeout (__main__.TimeoutTestCase) ... ok testConnectTimeout (__main__.TimeoutTestCase) ... FAIL testRecvTimeout (__main__.TimeoutTestCase) ... ok testRecvfromTimeout (__main__.TimeoutTestCase) ... ok testSend (__main__.TimeoutTestCase) ... ok testSendall (__main__.TimeoutTestCase) ... ok testSendto (__main__.TimeoutTestCase) ... ok ====================================================================== FAIL: testConnectTimeout (__main__.TimeoutTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "Lib/test/test_timeout.py", line 121, in testConnectTimeout "timeout (%g) is more than %g seconds more than expected (%g)" AssertionError: timeout (4.48679) is more than 2 seconds more than expected (0.001) ---------------------------------------------------------------------- Ran 14 tests in 17.445s FAILED (failures=1) Traceback (most recent call last): File "Lib/test/test_timeout.py", line 192, in ? test_main() File "Lib/test/test_timeout.py", line 189, in test_main test_support.run_unittest(CreationTestCase, TimeoutTestCase) File "/home/anthony/src/py/pyhead/dist/src/Lib/test/test_support.py", line 290, in run_unittest run_suite(suite, testclass) File "/home/anthony/src/py/pyhead/dist/src/Lib/test/test_support.py", line 275, in run_suite raise TestFailed(err) test.test_support.TestFailed: Traceback (most recent call last): File "Lib/test/test_timeout.py", line 121, in testConnectTimeout "timeout (%g) is more than %g seconds more than expected (%g)" AssertionError: timeout (4.48679) is more than 2 seconds more than expected (0.001) Also, with this patch applied, I can no longer kill a 'make testall' with a ^C ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-11 15:18 Message: Logged In: YES user_id=6656 The patch didn't apply, so I've updated it (attached). I see test_asynchat fail occasionally now, but don't know if that's because of this patch :-( Once I've sorted that out in my head, I think I'm going to check this in. ---------------------------------------------------------------------- Comment By: Andrew Langmead (langmead) Date: 2004-05-29 06:49 Message: Logged In: YES user_id=119306 Here is a reformatted version of the patch. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-05-28 15:25 Message: Logged In: YES user_id=31435 I agree that "busy" always should have been volatile -- once again, good eye! Python C style is basically K&R Classic, hard tab for indentation, open curly at the end of the line opening a block except for first line of function definition. Just make it look like the other C code, but be careful to pick one of the .c files Guido approves of . ---------------------------------------------------------------------- Comment By: Andrew Langmead (langmead) Date: 2004-05-28 13:37 Message: Logged In: YES user_id=119306 Thank you for pointing me to PEP 7. I'll take a look at where I am amiss and fix it up. For the change in ceval.c, I took a look at gcc's x86 assembly output of the file, and noticed that the optimizer was altering the order of the busy flag test. Since busy is set from other concurrent execution (other signal handlers), changing the variable to volatile told gcc not to optimize accesses to the variable. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-28 09:54 Message: Logged In: YES user_id=6656 I haven't been able to test on MacOS X further, unfortunately. The patch works on linux/x86 though (after fixing the TabError :-) but this is with an NTPL kernel, so I didn't have a problem anyway. The C doesn't all conform to the Python style -- see PEP 7. Can you fix that? Why the change to Python/ceval.c? After all that -- thanks a lot! I really want to get this checked in ASAP so we can find out which platforms it breaks at the earliest point in the 2.4 cycle. ---------------------------------------------------------------------- Comment By: Andrew Langmead (langmead) Date: 2004-05-27 07:04 Message: Logged In: YES user_id=119306 It seems that at least OS X, sending the kill to the process schedules that the receiving process will run the signal handler at some later time. (it seems to be the only one to frequently run the signal handlers in the opposite order than they were sent) This revised version of the test seems to work better on OS X. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-26 19:41 Message: Logged In: YES user_id=6656 test_threadsignals hangs for me on OS X. Haven't done anything more thorough than that yet... ---------------------------------------------------------------------- Comment By: Andrew Langmead (langmead) Date: 2004-05-26 18:48 Message: Logged In: YES user_id=119306 I apologize that the missing patch. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-26 18:22 Message: Logged In: YES user_id=6656 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. In addition, even if you *did* check this checkbox, a bug in SourceForge prevents attaching a file when *creating* an issue. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=960406&group_id=5470 From noreply at sourceforge.net Thu Jun 17 13:24:44 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jun 20 23:53:14 2004 Subject: [Patches] [ python-Patches-960406 ] unblock signals in threads Message-ID: Patches item #960406, was opened at 2004-05-25 22:00 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=960406&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Andrew Langmead (langmead) Assigned to: Nobody/Anonymous (nobody) Summary: unblock signals in threads Initial Comment: This is a patch which will correct the issues some people have with python's handling of signal handling in threads. It allows any thread to initially catch the signal mark it as triggered, allowing the main thread to later process it. (This is actually just restoring access to the functionality that was in Python 2.1) The special SIGINT handling for the python readline module has been changed so that it can now see an EINTR error code, rather than needing a longjmp out of the readline library itself. If the readline library python is being linked to doesn't have the callback features necessary, it will fall back to its old behavior. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2004-06-17 18:24 Message: Logged In: YES user_id=6656 How about the attached? It's a bit ... scary. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-17 17:08 Message: Logged In: YES user_id=6656 A potential problem with this patch is that it causes input to be interrupted (with a KeyboardInterrupt exception) when any handled signal is delivered. This seems suboptimal. It's appealing to try to run the (Python) signal handlers in the errno == EINTR case of readline_line_until_enter_or_signal, but that has problems in that PyOS_ReadlineFunctionPointer is called without the GIL being held and once that is dealt with, an installed Python signal handler attempting to call readline at this point can reasonably be expected to result in all hell breaking loose. I don't know what the correct solution is here. Add our own rentrancy checks and learn how to work the Python threadstate API properly? Thoughts, anyone? Or have I scared everyone away now? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-12 11:17 Message: Logged In: YES user_id=6656 Now a rewrite of the test that actually works! ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-12 11:08 Message: Logged In: YES user_id=6656 Here's a version of the patch that includes the new unit test (oops!) which I've rewritten slightly. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-06-11 17:02 Message: Logged In: YES user_id=29957 No - wait. Ignore that test_timeout error, it exists with a clean checkout. The inability to interrupt make testall, however is new with this patch. Linux Fedora Core 2. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-06-11 16:58 Message: Logged In: YES user_id=29957 With this patch: bonanza% ./python Lib/test/test_timeout.py testBlockingThenTimeout (__main__.CreationTestCase) ... ok testFloatReturnValue (__main__.CreationTestCase) ... ok testObjectCreation (__main__.CreationTestCase) ... ok testRangeCheck (__main__.CreationTestCase) ... ok testReturnType (__main__.CreationTestCase) ... ok testTimeoutThenBlocking (__main__.CreationTestCase) ... ok testTypeCheck (__main__.CreationTestCase) ... ok testAcceptTimeout (__main__.TimeoutTestCase) ... ok testConnectTimeout (__main__.TimeoutTestCase) ... FAIL testRecvTimeout (__main__.TimeoutTestCase) ... ok testRecvfromTimeout (__main__.TimeoutTestCase) ... ok testSend (__main__.TimeoutTestCase) ... ok testSendall (__main__.TimeoutTestCase) ... ok testSendto (__main__.TimeoutTestCase) ... ok ====================================================================== FAIL: testConnectTimeout (__main__.TimeoutTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "Lib/test/test_timeout.py", line 121, in testConnectTimeout "timeout (%g) is more than %g seconds more than expected (%g)" AssertionError: timeout (4.48679) is more than 2 seconds more than expected (0.001) ---------------------------------------------------------------------- Ran 14 tests in 17.445s FAILED (failures=1) Traceback (most recent call last): File "Lib/test/test_timeout.py", line 192, in ? test_main() File "Lib/test/test_timeout.py", line 189, in test_main test_support.run_unittest(CreationTestCase, TimeoutTestCase) File "/home/anthony/src/py/pyhead/dist/src/Lib/test/test_support.py", line 290, in run_unittest run_suite(suite, testclass) File "/home/anthony/src/py/pyhead/dist/src/Lib/test/test_support.py", line 275, in run_suite raise TestFailed(err) test.test_support.TestFailed: Traceback (most recent call last): File "Lib/test/test_timeout.py", line 121, in testConnectTimeout "timeout (%g) is more than %g seconds more than expected (%g)" AssertionError: timeout (4.48679) is more than 2 seconds more than expected (0.001) Also, with this patch applied, I can no longer kill a 'make testall' with a ^C ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-11 15:18 Message: Logged In: YES user_id=6656 The patch didn't apply, so I've updated it (attached). I see test_asynchat fail occasionally now, but don't know if that's because of this patch :-( Once I've sorted that out in my head, I think I'm going to check this in. ---------------------------------------------------------------------- Comment By: Andrew Langmead (langmead) Date: 2004-05-29 06:49 Message: Logged In: YES user_id=119306 Here is a reformatted version of the patch. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-05-28 15:25 Message: Logged In: YES user_id=31435 I agree that "busy" always should have been volatile -- once again, good eye! Python C style is basically K&R Classic, hard tab for indentation, open curly at the end of the line opening a block except for first line of function definition. Just make it look like the other C code, but be careful to pick one of the .c files Guido approves of . ---------------------------------------------------------------------- Comment By: Andrew Langmead (langmead) Date: 2004-05-28 13:37 Message: Logged In: YES user_id=119306 Thank you for pointing me to PEP 7. I'll take a look at where I am amiss and fix it up. For the change in ceval.c, I took a look at gcc's x86 assembly output of the file, and noticed that the optimizer was altering the order of the busy flag test. Since busy is set from other concurrent execution (other signal handlers), changing the variable to volatile told gcc not to optimize accesses to the variable. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-28 09:54 Message: Logged In: YES user_id=6656 I haven't been able to test on MacOS X further, unfortunately. The patch works on linux/x86 though (after fixing the TabError :-) but this is with an NTPL kernel, so I didn't have a problem anyway. The C doesn't all conform to the Python style -- see PEP 7. Can you fix that? Why the change to Python/ceval.c? After all that -- thanks a lot! I really want to get this checked in ASAP so we can find out which platforms it breaks at the earliest point in the 2.4 cycle. ---------------------------------------------------------------------- Comment By: Andrew Langmead (langmead) Date: 2004-05-27 07:04 Message: Logged In: YES user_id=119306 It seems that at least OS X, sending the kill to the process schedules that the receiving process will run the signal handler at some later time. (it seems to be the only one to frequently run the signal handlers in the opposite order than they were sent) This revised version of the test seems to work better on OS X. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-26 19:41 Message: Logged In: YES user_id=6656 test_threadsignals hangs for me on OS X. Haven't done anything more thorough than that yet... ---------------------------------------------------------------------- Comment By: Andrew Langmead (langmead) Date: 2004-05-26 18:48 Message: Logged In: YES user_id=119306 I apologize that the missing patch. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-26 18:22 Message: Logged In: YES user_id=6656 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. In addition, even if you *did* check this checkbox, a bug in SourceForge prevents attaching a file when *creating* an issue. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=960406&group_id=5470 From noreply at sourceforge.net Fri Jun 18 23:04:14 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jun 21 00:02:00 2004 Subject: [Patches] [ python-Patches-960406 ] unblock signals in threads Message-ID: Patches item #960406, was opened at 2004-05-25 17:00 Message generated for change (Comment added) made by langmead You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=960406&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: Andrew Langmead (langmead) Assigned to: Nobody/Anonymous (nobody) Summary: unblock signals in threads Initial Comment: This is a patch which will correct the issues some people have with python's handling of signal handling in threads. It allows any thread to initially catch the signal mark it as triggered, allowing the main thread to later process it. (This is actually just restoring access to the functionality that was in Python 2.1) The special SIGINT handling for the python readline module has been changed so that it can now see an EINTR error code, rather than needing a longjmp out of the readline library itself. If the readline library python is being linked to doesn't have the callback features necessary, it will fall back to its old behavior. ---------------------------------------------------------------------- >Comment By: Andrew Langmead (langmead) Date: 2004-06-18 23:04 Message: Logged In: YES user_id=119306 I'm not sure if the current behavior should be maintained or not, but it looks like to me that the readline module has always generated a KeyboardInterrupt, regardless of whether SIGINT has been overridden. This is a bit odd though. It causes the SIGINT handling to change depending on whether or not you are at the top level interpreter's prompt. wantarray% cat /tmp/foo.py import signal def foo(sig, frame): print "caught foo" signal.signal(signal.SIGINT, foo) wantarray% python -i /tmp/foo.py >>> foo >>> ^C KeyboardInterrupt >>> while 1: ... pass ... ^Ccaught foo ^Ccaught foo ^Ccaught foo ^Ccaught foo ^\zsh: quit python -i /tmp/foo.py ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-18 08:54 Message: Logged In: YES user_id=6656 The problem with that approach is: what if you want a handler for SIGINT that doesn't raise KeyboardInterrupt? Other than that, it sounds like your plan should work. I've attached a slightly cleaned up version of my patch which makes signal handling in the "without readline" case more like yesterday's patch made the "with readline" case. ---------------------------------------------------------------------- Comment By: Andrew Langmead (langmead) Date: 2004-06-17 22:35 Message: Logged In: YES user_id=119306 Here is another possible approach to solving the problem of readline exiting for signals other than SIGINT. I'm not sure if it is better or worse than the scarypatch. As you said, the call to readline is performed without the GIL. So is the actual C-level signal handler from the signal module (the python code that gets associated with the signal is deferred until later.) At the time we see the EINTR, there is a flag in the signal module's Handler array to say whether the signal that we received was a SIGINT. If we added some sort of interface within the signal module to find out what signals are pending to be run on the next call to PyErr_CheckSignals, then we could find out if the EINTR was caused by an INT (at which point we should exit) or by another signal (at which we could just retry the select.) Is there any potential to this approach? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-17 13:25 Message: Logged In: YES user_id=6656 BTW, I'd really really like someone to review this :-) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-17 13:24 Message: Logged In: YES user_id=6656 How about the attached? It's a bit ... scary. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-17 12:08 Message: Logged In: YES user_id=6656 A potential problem with this patch is that it causes input to be interrupted (with a KeyboardInterrupt exception) when any handled signal is delivered. This seems suboptimal. It's appealing to try to run the (Python) signal handlers in the errno == EINTR case of readline_line_until_enter_or_signal, but that has problems in that PyOS_ReadlineFunctionPointer is called without the GIL being held and once that is dealt with, an installed Python signal handler attempting to call readline at this point can reasonably be expected to result in all hell breaking loose. I don't know what the correct solution is here. Add our own rentrancy checks and learn how to work the Python threadstate API properly? Thoughts, anyone? Or have I scared everyone away now? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-12 06:17 Message: Logged In: YES user_id=6656 Now a rewrite of the test that actually works! ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-12 06:08 Message: Logged In: YES user_id=6656 Here's a version of the patch that includes the new unit test (oops!) which I've rewritten slightly. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-06-11 12:02 Message: Logged In: YES user_id=29957 No - wait. Ignore that test_timeout error, it exists with a clean checkout. The inability to interrupt make testall, however is new with this patch. Linux Fedora Core 2. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-06-11 11:58 Message: Logged In: YES user_id=29957 With this patch: bonanza% ./python Lib/test/test_timeout.py testBlockingThenTimeout (__main__.CreationTestCase) ... ok testFloatReturnValue (__main__.CreationTestCase) ... ok testObjectCreation (__main__.CreationTestCase) ... ok testRangeCheck (__main__.CreationTestCase) ... ok testReturnType (__main__.CreationTestCase) ... ok testTimeoutThenBlocking (__main__.CreationTestCase) ... ok testTypeCheck (__main__.CreationTestCase) ... ok testAcceptTimeout (__main__.TimeoutTestCase) ... ok testConnectTimeout (__main__.TimeoutTestCase) ... FAIL testRecvTimeout (__main__.TimeoutTestCase) ... ok testRecvfromTimeout (__main__.TimeoutTestCase) ... ok testSend (__main__.TimeoutTestCase) ... ok testSendall (__main__.TimeoutTestCase) ... ok testSendto (__main__.TimeoutTestCase) ... ok ====================================================================== FAIL: testConnectTimeout (__main__.TimeoutTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "Lib/test/test_timeout.py", line 121, in testConnectTimeout "timeout (%g) is more than %g seconds more than expected (%g)" AssertionError: timeout (4.48679) is more than 2 seconds more than expected (0.001) ---------------------------------------------------------------------- Ran 14 tests in 17.445s FAILED (failures=1) Traceback (most recent call last): File "Lib/test/test_timeout.py", line 192, in ? test_main() File "Lib/test/test_timeout.py", line 189, in test_main test_support.run_unittest(CreationTestCase, TimeoutTestCase) File "/home/anthony/src/py/pyhead/dist/src/Lib/test/test_support.py", line 290, in run_unittest run_suite(suite, testclass) File "/home/anthony/src/py/pyhead/dist/src/Lib/test/test_support.py", line 275, in run_suite raise TestFailed(err) test.test_support.TestFailed: Traceback (most recent call last): File "Lib/test/test_timeout.py", line 121, in testConnectTimeout "timeout (%g) is more than %g seconds more than expected (%g)" AssertionError: timeout (4.48679) is more than 2 seconds more than expected (0.001) Also, with this patch applied, I can no longer kill a 'make testall' with a ^C ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-11 10:18 Message: Logged In: YES user_id=6656 The patch didn't apply, so I've updated it (attached). I see test_asynchat fail occasionally now, but don't know if that's because of this patch :-( Once I've sorted that out in my head, I think I'm going to check this in. ---------------------------------------------------------------------- Comment By: Andrew Langmead (langmead) Date: 2004-05-29 01:49 Message: Logged In: YES user_id=119306 Here is a reformatted version of the patch. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-05-28 10:25 Message: Logged In: YES user_id=31435 I agree that "busy" always should have been volatile -- once again, good eye! Python C style is basically K&R Classic, hard tab for indentation, open curly at the end of the line opening a block except for first line of function definition. Just make it look like the other C code, but be careful to pick one of the .c files Guido approves of . ---------------------------------------------------------------------- Comment By: Andrew Langmead (langmead) Date: 2004-05-28 08:37 Message: Logged In: YES user_id=119306 Thank you for pointing me to PEP 7. I'll take a look at where I am amiss and fix it up. For the change in ceval.c, I took a look at gcc's x86 assembly output of the file, and noticed that the optimizer was altering the order of the busy flag test. Since busy is set from other concurrent execution (other signal handlers), changing the variable to volatile told gcc not to optimize accesses to the variable. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-28 04:54 Message: Logged In: YES user_id=6656 I haven't been able to test on MacOS X further, unfortunately. The patch works on linux/x86 though (after fixing the TabError :-) but this is with an NTPL kernel, so I didn't have a problem anyway. The C doesn't all conform to the Python style -- see PEP 7. Can you fix that? Why the change to Python/ceval.c? After all that -- thanks a lot! I really want to get this checked in ASAP so we can find out which platforms it breaks at the earliest point in the 2.4 cycle. ---------------------------------------------------------------------- Comment By: Andrew Langmead (langmead) Date: 2004-05-27 02:04 Message: Logged In: YES user_id=119306 It seems that at least OS X, sending the kill to the process schedules that the receiving process will run the signal handler at some later time. (it seems to be the only one to frequently run the signal handlers in the opposite order than they were sent) This revised version of the test seems to work better on OS X. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-26 14:41 Message: Logged In: YES user_id=6656 test_threadsignals hangs for me on OS X. Haven't done anything more thorough than that yet... ---------------------------------------------------------------------- Comment By: Andrew Langmead (langmead) Date: 2004-05-26 13:48 Message: Logged In: YES user_id=119306 I apologize that the missing patch. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-26 13:22 Message: Logged In: YES user_id=6656 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. In addition, even if you *did* check this checkbox, a bug in SourceForge prevents attaching a file when *creating* an issue. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=960406&group_id=5470 From noreply at sourceforge.net Thu Jun 17 22:35:46 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jun 21 00:04:44 2004 Subject: [Patches] [ python-Patches-960406 ] unblock signals in threads Message-ID: Patches item #960406, was opened at 2004-05-25 17:00 Message generated for change (Comment added) made by langmead You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=960406&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: Andrew Langmead (langmead) Assigned to: Nobody/Anonymous (nobody) Summary: unblock signals in threads Initial Comment: This is a patch which will correct the issues some people have with python's handling of signal handling in threads. It allows any thread to initially catch the signal mark it as triggered, allowing the main thread to later process it. (This is actually just restoring access to the functionality that was in Python 2.1) The special SIGINT handling for the python readline module has been changed so that it can now see an EINTR error code, rather than needing a longjmp out of the readline library itself. If the readline library python is being linked to doesn't have the callback features necessary, it will fall back to its old behavior. ---------------------------------------------------------------------- >Comment By: Andrew Langmead (langmead) Date: 2004-06-17 22:35 Message: Logged In: YES user_id=119306 Here is another possible approach to solving the problem of readline exiting for signals other than SIGINT. I'm not sure if it is better or worse than the scarypatch. As you said, the call to readline is performed without the GIL. So is the actual C-level signal handler from the signal module (the python code that gets associated with the signal is deferred until later.) At the time we see the EINTR, there is a flag in the signal module's Handler array to say whether the signal that we received was a SIGINT. If we added some sort of interface within the signal module to find out what signals are pending to be run on the next call to PyErr_CheckSignals, then we could find out if the EINTR was caused by an INT (at which point we should exit) or by another signal (at which we could just retry the select.) Is there any potential to this approach? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-17 13:25 Message: Logged In: YES user_id=6656 BTW, I'd really really like someone to review this :-) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-17 13:24 Message: Logged In: YES user_id=6656 How about the attached? It's a bit ... scary. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-17 12:08 Message: Logged In: YES user_id=6656 A potential problem with this patch is that it causes input to be interrupted (with a KeyboardInterrupt exception) when any handled signal is delivered. This seems suboptimal. It's appealing to try to run the (Python) signal handlers in the errno == EINTR case of readline_line_until_enter_or_signal, but that has problems in that PyOS_ReadlineFunctionPointer is called without the GIL being held and once that is dealt with, an installed Python signal handler attempting to call readline at this point can reasonably be expected to result in all hell breaking loose. I don't know what the correct solution is here. Add our own rentrancy checks and learn how to work the Python threadstate API properly? Thoughts, anyone? Or have I scared everyone away now? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-12 06:17 Message: Logged In: YES user_id=6656 Now a rewrite of the test that actually works! ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-12 06:08 Message: Logged In: YES user_id=6656 Here's a version of the patch that includes the new unit test (oops!) which I've rewritten slightly. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-06-11 12:02 Message: Logged In: YES user_id=29957 No - wait. Ignore that test_timeout error, it exists with a clean checkout. The inability to interrupt make testall, however is new with this patch. Linux Fedora Core 2. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-06-11 11:58 Message: Logged In: YES user_id=29957 With this patch: bonanza% ./python Lib/test/test_timeout.py testBlockingThenTimeout (__main__.CreationTestCase) ... ok testFloatReturnValue (__main__.CreationTestCase) ... ok testObjectCreation (__main__.CreationTestCase) ... ok testRangeCheck (__main__.CreationTestCase) ... ok testReturnType (__main__.CreationTestCase) ... ok testTimeoutThenBlocking (__main__.CreationTestCase) ... ok testTypeCheck (__main__.CreationTestCase) ... ok testAcceptTimeout (__main__.TimeoutTestCase) ... ok testConnectTimeout (__main__.TimeoutTestCase) ... FAIL testRecvTimeout (__main__.TimeoutTestCase) ... ok testRecvfromTimeout (__main__.TimeoutTestCase) ... ok testSend (__main__.TimeoutTestCase) ... ok testSendall (__main__.TimeoutTestCase) ... ok testSendto (__main__.TimeoutTestCase) ... ok ====================================================================== FAIL: testConnectTimeout (__main__.TimeoutTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "Lib/test/test_timeout.py", line 121, in testConnectTimeout "timeout (%g) is more than %g seconds more than expected (%g)" AssertionError: timeout (4.48679) is more than 2 seconds more than expected (0.001) ---------------------------------------------------------------------- Ran 14 tests in 17.445s FAILED (failures=1) Traceback (most recent call last): File "Lib/test/test_timeout.py", line 192, in ? test_main() File "Lib/test/test_timeout.py", line 189, in test_main test_support.run_unittest(CreationTestCase, TimeoutTestCase) File "/home/anthony/src/py/pyhead/dist/src/Lib/test/test_support.py", line 290, in run_unittest run_suite(suite, testclass) File "/home/anthony/src/py/pyhead/dist/src/Lib/test/test_support.py", line 275, in run_suite raise TestFailed(err) test.test_support.TestFailed: Traceback (most recent call last): File "Lib/test/test_timeout.py", line 121, in testConnectTimeout "timeout (%g) is more than %g seconds more than expected (%g)" AssertionError: timeout (4.48679) is more than 2 seconds more than expected (0.001) Also, with this patch applied, I can no longer kill a 'make testall' with a ^C ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-11 10:18 Message: Logged In: YES user_id=6656 The patch didn't apply, so I've updated it (attached). I see test_asynchat fail occasionally now, but don't know if that's because of this patch :-( Once I've sorted that out in my head, I think I'm going to check this in. ---------------------------------------------------------------------- Comment By: Andrew Langmead (langmead) Date: 2004-05-29 01:49 Message: Logged In: YES user_id=119306 Here is a reformatted version of the patch. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-05-28 10:25 Message: Logged In: YES user_id=31435 I agree that "busy" always should have been volatile -- once again, good eye! Python C style is basically K&R Classic, hard tab for indentation, open curly at the end of the line opening a block except for first line of function definition. Just make it look like the other C code, but be careful to pick one of the .c files Guido approves of . ---------------------------------------------------------------------- Comment By: Andrew Langmead (langmead) Date: 2004-05-28 08:37 Message: Logged In: YES user_id=119306 Thank you for pointing me to PEP 7. I'll take a look at where I am amiss and fix it up. For the change in ceval.c, I took a look at gcc's x86 assembly output of the file, and noticed that the optimizer was altering the order of the busy flag test. Since busy is set from other concurrent execution (other signal handlers), changing the variable to volatile told gcc not to optimize accesses to the variable. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-28 04:54 Message: Logged In: YES user_id=6656 I haven't been able to test on MacOS X further, unfortunately. The patch works on linux/x86 though (after fixing the TabError :-) but this is with an NTPL kernel, so I didn't have a problem anyway. The C doesn't all conform to the Python style -- see PEP 7. Can you fix that? Why the change to Python/ceval.c? After all that -- thanks a lot! I really want to get this checked in ASAP so we can find out which platforms it breaks at the earliest point in the 2.4 cycle. ---------------------------------------------------------------------- Comment By: Andrew Langmead (langmead) Date: 2004-05-27 02:04 Message: Logged In: YES user_id=119306 It seems that at least OS X, sending the kill to the process schedules that the receiving process will run the signal handler at some later time. (it seems to be the only one to frequently run the signal handlers in the opposite order than they were sent) This revised version of the test seems to work better on OS X. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-26 14:41 Message: Logged In: YES user_id=6656 test_threadsignals hangs for me on OS X. Haven't done anything more thorough than that yet... ---------------------------------------------------------------------- Comment By: Andrew Langmead (langmead) Date: 2004-05-26 13:48 Message: Logged In: YES user_id=119306 I apologize that the missing patch. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-26 13:22 Message: Logged In: YES user_id=6656 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. In addition, even if you *did* check this checkbox, a bug in SourceForge prevents attaching a file when *creating* an issue. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=960406&group_id=5470 From smolinann at ncc.dk Fri Jun 18 10:45:42 2004 From: smolinann at ncc.dk (Susana Molina) Date: Mon Jun 21 00:05:35 2004 Subject: [Patches] Powerful weightloss now available where you are. Message-ID: <7ba701c45542$051a9e23$b085bb56@theingredient.co.uk> Hello, I have a special offer for you... WANT TO LOSE WEIGHT? The most powerful weightloss is now available without prescription. All natural Adipren720 100% Money Back Guarant?e! - Lose up to 19% Total Body Weight. - Loss of 20-35% abdominal Fat. - Up to 300% more Weight Loss while dieting. - Increase metabolic rate by 76.9% without Exercise. - Reduction of 40-70% overall Fat under skin. - Suppresses appetite for sugar. - Burns calorized fat. - Boost your Confidence level and Self Esteem. Get the facts about all-natural Adipren720 ---- system information ---- procedure like process do obtains B: Localized always Scenarios localization referred particular case specific Distinguishing implementation marks considered reflection Relationship environment part wants distinctions danger parsing B: logic items produces internationalization relationship mailing implement another sorting many called zh-Hant cite From joinerfv at weston.ac.uk Thu Jun 17 06:09:00 2004 From: joinerfv at weston.ac.uk (Gay Joiner) Date: Mon Jun 21 00:07:11 2004 Subject: [Patches] Powerful weightloss now available where you are. Message-ID: Hello, I have a special offer for you... WANT TO LOSE WEIGHT? The most powerful weightloss is now available without prescription. All natural Adipren720 100% Money Back Guarant?e! - Lose up to 19% Total Body Weight. - Loss of 20-35% abdominal Fat. - Up to 300% more Weight Loss while dieting. - Increase metabolic rate by 76.9% without Exercise. - Reduction of 40-70% overall Fat under skin. - Suppresses appetite for sugar. - Burns calorized fat. - Boost your Confidence level and Self Esteem. Get the facts about all-natural Adipren720 ---- system information ---- items repeated resulting Scenarios individual acceptable usage comment selection think fallback mechanism Japan its this distinction Generally documents requests session-like Existing Sender implementers systems one Produces locale-affected able presents contribution Distinguishing NET contrast Presentation a could settings no Relationship another From noreply at sourceforge.net Thu Jun 17 22:48:35 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jun 21 00:13:00 2004 Subject: [Patches] [ python-Patches-768079 ] configure interpreter for profiling Message-ID: Patches item #768079, was opened at 2003-07-08 16:58 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=768079&group_id=5470 Category: Build Group: Python 2.4 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Skip Montanaro (montanaro) Summary: configure interpreter for profiling Initial Comment: I think this is pretty innocuous, but since we're so close to 2.3 release it should be reviewed. Assigning to Martin since he's the configure expert. This simple patch adds an --enable-profiling flag to configure.in. It's just the first step - adding -pg to compile and link lines if $CC understands it. ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2004-06-17 21:48 Message: Logged In: YES user_id=44345 Checked in as configure.in 1.458 and configure 1.447. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-07-09 10:37 Message: Logged In: YES user_id=44345 2.4 is fine. It should work with any compiler which understands -pg. If that's only gcc for now, that's the only one which it will get set for. Support for other compilers can be added later by people with access to other compilers. I believe it's worth adding as a configure flag because it makes it more foolproof. By configuring with -pg, all extension modules built with this particular python executable will also get profiling enabled. That's not immediately obvious to everyone. Also some people seem to think that by adding -pg to an extension module's compilation that they should get profiled results. That only works if the interpreter is compiled with -pg because it's during a modified exit() call that the data gets written. This only came up because one user is going through all sorts of hoops to try and profile his extension module. He's obviously making mistakes. I think it would be better to make it a more foolproof exercise. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-07-09 00:23 Message: Logged In: YES user_id=21627 I have several objections: For 2.3, it is a new feature, which cannot be added at this time (changing the group to 2.4). It then only works with gcc, as other compilers don't recognize -pg. In addition, I fail to see the rationale for this change: You can already achieve the same effect by setting CC (and perhaps CXX) before invoking configure. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=768079&group_id=5470 From noreply at sourceforge.net Fri Jun 18 08:54:59 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jun 21 00:25:51 2004 Subject: [Patches] [ python-Patches-960406 ] unblock signals in threads Message-ID: Patches item #960406, was opened at 2004-05-25 22:00 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=960406&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: Andrew Langmead (langmead) Assigned to: Nobody/Anonymous (nobody) Summary: unblock signals in threads Initial Comment: This is a patch which will correct the issues some people have with python's handling of signal handling in threads. It allows any thread to initially catch the signal mark it as triggered, allowing the main thread to later process it. (This is actually just restoring access to the functionality that was in Python 2.1) The special SIGINT handling for the python readline module has been changed so that it can now see an EINTR error code, rather than needing a longjmp out of the readline library itself. If the readline library python is being linked to doesn't have the callback features necessary, it will fall back to its old behavior. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2004-06-18 13:54 Message: Logged In: YES user_id=6656 The problem with that approach is: what if you want a handler for SIGINT that doesn't raise KeyboardInterrupt? Other than that, it sounds like your plan should work. I've attached a slightly cleaned up version of my patch which makes signal handling in the "without readline" case more like yesterday's patch made the "with readline" case. ---------------------------------------------------------------------- Comment By: Andrew Langmead (langmead) Date: 2004-06-18 03:35 Message: Logged In: YES user_id=119306 Here is another possible approach to solving the problem of readline exiting for signals other than SIGINT. I'm not sure if it is better or worse than the scarypatch. As you said, the call to readline is performed without the GIL. So is the actual C-level signal handler from the signal module (the python code that gets associated with the signal is deferred until later.) At the time we see the EINTR, there is a flag in the signal module's Handler array to say whether the signal that we received was a SIGINT. If we added some sort of interface within the signal module to find out what signals are pending to be run on the next call to PyErr_CheckSignals, then we could find out if the EINTR was caused by an INT (at which point we should exit) or by another signal (at which we could just retry the select.) Is there any potential to this approach? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-17 18:25 Message: Logged In: YES user_id=6656 BTW, I'd really really like someone to review this :-) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-17 18:24 Message: Logged In: YES user_id=6656 How about the attached? It's a bit ... scary. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-17 17:08 Message: Logged In: YES user_id=6656 A potential problem with this patch is that it causes input to be interrupted (with a KeyboardInterrupt exception) when any handled signal is delivered. This seems suboptimal. It's appealing to try to run the (Python) signal handlers in the errno == EINTR case of readline_line_until_enter_or_signal, but that has problems in that PyOS_ReadlineFunctionPointer is called without the GIL being held and once that is dealt with, an installed Python signal handler attempting to call readline at this point can reasonably be expected to result in all hell breaking loose. I don't know what the correct solution is here. Add our own rentrancy checks and learn how to work the Python threadstate API properly? Thoughts, anyone? Or have I scared everyone away now? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-12 11:17 Message: Logged In: YES user_id=6656 Now a rewrite of the test that actually works! ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-12 11:08 Message: Logged In: YES user_id=6656 Here's a version of the patch that includes the new unit test (oops!) which I've rewritten slightly. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-06-11 17:02 Message: Logged In: YES user_id=29957 No - wait. Ignore that test_timeout error, it exists with a clean checkout. The inability to interrupt make testall, however is new with this patch. Linux Fedora Core 2. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-06-11 16:58 Message: Logged In: YES user_id=29957 With this patch: bonanza% ./python Lib/test/test_timeout.py testBlockingThenTimeout (__main__.CreationTestCase) ... ok testFloatReturnValue (__main__.CreationTestCase) ... ok testObjectCreation (__main__.CreationTestCase) ... ok testRangeCheck (__main__.CreationTestCase) ... ok testReturnType (__main__.CreationTestCase) ... ok testTimeoutThenBlocking (__main__.CreationTestCase) ... ok testTypeCheck (__main__.CreationTestCase) ... ok testAcceptTimeout (__main__.TimeoutTestCase) ... ok testConnectTimeout (__main__.TimeoutTestCase) ... FAIL testRecvTimeout (__main__.TimeoutTestCase) ... ok testRecvfromTimeout (__main__.TimeoutTestCase) ... ok testSend (__main__.TimeoutTestCase) ... ok testSendall (__main__.TimeoutTestCase) ... ok testSendto (__main__.TimeoutTestCase) ... ok ====================================================================== FAIL: testConnectTimeout (__main__.TimeoutTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "Lib/test/test_timeout.py", line 121, in testConnectTimeout "timeout (%g) is more than %g seconds more than expected (%g)" AssertionError: timeout (4.48679) is more than 2 seconds more than expected (0.001) ---------------------------------------------------------------------- Ran 14 tests in 17.445s FAILED (failures=1) Traceback (most recent call last): File "Lib/test/test_timeout.py", line 192, in ? test_main() File "Lib/test/test_timeout.py", line 189, in test_main test_support.run_unittest(CreationTestCase, TimeoutTestCase) File "/home/anthony/src/py/pyhead/dist/src/Lib/test/test_support.py", line 290, in run_unittest run_suite(suite, testclass) File "/home/anthony/src/py/pyhead/dist/src/Lib/test/test_support.py", line 275, in run_suite raise TestFailed(err) test.test_support.TestFailed: Traceback (most recent call last): File "Lib/test/test_timeout.py", line 121, in testConnectTimeout "timeout (%g) is more than %g seconds more than expected (%g)" AssertionError: timeout (4.48679) is more than 2 seconds more than expected (0.001) Also, with this patch applied, I can no longer kill a 'make testall' with a ^C ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-11 15:18 Message: Logged In: YES user_id=6656 The patch didn't apply, so I've updated it (attached). I see test_asynchat fail occasionally now, but don't know if that's because of this patch :-( Once I've sorted that out in my head, I think I'm going to check this in. ---------------------------------------------------------------------- Comment By: Andrew Langmead (langmead) Date: 2004-05-29 06:49 Message: Logged In: YES user_id=119306 Here is a reformatted version of the patch. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-05-28 15:25 Message: Logged In: YES user_id=31435 I agree that "busy" always should have been volatile -- once again, good eye! Python C style is basically K&R Classic, hard tab for indentation, open curly at the end of the line opening a block except for first line of function definition. Just make it look like the other C code, but be careful to pick one of the .c files Guido approves of . ---------------------------------------------------------------------- Comment By: Andrew Langmead (langmead) Date: 2004-05-28 13:37 Message: Logged In: YES user_id=119306 Thank you for pointing me to PEP 7. I'll take a look at where I am amiss and fix it up. For the change in ceval.c, I took a look at gcc's x86 assembly output of the file, and noticed that the optimizer was altering the order of the busy flag test. Since busy is set from other concurrent execution (other signal handlers), changing the variable to volatile told gcc not to optimize accesses to the variable. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-28 09:54 Message: Logged In: YES user_id=6656 I haven't been able to test on MacOS X further, unfortunately. The patch works on linux/x86 though (after fixing the TabError :-) but this is with an NTPL kernel, so I didn't have a problem anyway. The C doesn't all conform to the Python style -- see PEP 7. Can you fix that? Why the change to Python/ceval.c? After all that -- thanks a lot! I really want to get this checked in ASAP so we can find out which platforms it breaks at the earliest point in the 2.4 cycle. ---------------------------------------------------------------------- Comment By: Andrew Langmead (langmead) Date: 2004-05-27 07:04 Message: Logged In: YES user_id=119306 It seems that at least OS X, sending the kill to the process schedules that the receiving process will run the signal handler at some later time. (it seems to be the only one to frequently run the signal handlers in the opposite order than they were sent) This revised version of the test seems to work better on OS X. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-26 19:41 Message: Logged In: YES user_id=6656 test_threadsignals hangs for me on OS X. Haven't done anything more thorough than that yet... ---------------------------------------------------------------------- Comment By: Andrew Langmead (langmead) Date: 2004-05-26 18:48 Message: Logged In: YES user_id=119306 I apologize that the missing patch. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-26 18:22 Message: Logged In: YES user_id=6656 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. In addition, even if you *did* check this checkbox, a bug in SourceForge prevents attaching a file when *creating* an issue. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=960406&group_id=5470 From noreply at sourceforge.net Thu Jun 17 06:15:16 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jun 21 00:27:33 2004 Subject: [Patches] [ python-Patches-974633 ] Parser/acceler.c: PyObject_MALLOC return is not checked Message-ID: Patches item #974633, was opened at 2004-06-17 10:15 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=974633&group_id=5470 Category: Parser/Compiler Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dima Dorfman (ddorfman) Assigned to: Nobody/Anonymous (nobody) Summary: Parser/acceler.c: PyObject_MALLOC return is not checked Initial Comment: fixstate in Parser/acceler.c: The first call to PyObject_MALLOC doesn't check for it returning NULL. The attached patch does the fprintf/exit combo just like another call to malloc later in the function. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=974633&group_id=5470 From MVTPRUQEBJQZYQ at online.ie Sat Jun 19 03:21:18 2004 From: MVTPRUQEBJQZYQ at online.ie (Buford Calvert) Date: Mon Jun 21 00:28:43 2004 Subject: [Patches] T0p Quality S0ftware at the L0west Possible Priice from Bullock's S0ftSh0p Message-ID: We know better than we do. We do not yet possess ourselves... The most important of life's battles is the one we fight daily in the silent chambers of the soul. Celebrity is death --- celebrity -- that's the worst thing that can happen to an actor. We are Divine enough to ask and we are important enough to receive. I have to act to live. Of Consciousness, her awful Mate. The Soul cannot be rid -- as easy the secreting her behind the Eyes of God. We owe a deep debt of gratitude to Adam, the first great benefactor of the human race: he brought death into the world. It's not a slam at you when people are rude -- it's a slam at the people they've met before. The greatest things are accomplished by individual people, not by committees or companies. The real meaning of enlightenment is to gaze with undimmed eyes on all darkness. How wonderful is death! Death and his brother sleep. Someone's sitting in the shade today because someone planted a tree a long time ago. I did not attend his funeral but I wrote a nice letter saying I approved of it. [About a politician who had recently died] The one thing that matters is the effort. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20040619/f1f047f9/attachment.html From noreply at sourceforge.net Sat Jun 19 06:14:00 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jun 21 00:32:28 2004 Subject: [Patches] [ python-Patches-960406 ] unblock signals in threads Message-ID: Patches item #960406, was opened at 2004-05-25 22:00 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=960406&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: Andrew Langmead (langmead) >Assigned to: Guido van Rossum (gvanrossum) Summary: unblock signals in threads Initial Comment: This is a patch which will correct the issues some people have with python's handling of signal handling in threads. It allows any thread to initially catch the signal mark it as triggered, allowing the main thread to later process it. (This is actually just restoring access to the functionality that was in Python 2.1) The special SIGINT handling for the python readline module has been changed so that it can now see an EINTR error code, rather than needing a longjmp out of the readline library itself. If the readline library python is being linked to doesn't have the callback features necessary, it will fall back to its old behavior. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2004-06-19 11:14 Message: Logged In: YES user_id=6656 Yes, I think you're right. I guess I'm suffering a lack of focus, finding it hard to resist the impulse to fix what look like ancient bogosities in the area while I'm there... (also see the way a NULL return from PyOS_Readline is assumed to be a keyboard interrupt). One could argue that ^C should always interrupt an interactive session, but one could also argue that users shouldn't be so daft as to install handlers for SIGINT if they want that to be true (after all, they can make life hard for themselves if they want with stty(1)). A downside to all this footling is that it makes a backport to 2.3 harder to justify. Hmm. I wander what Guido thinnks (he's alledgedly "now maintaining" Modules/readline.c :-). ---------------------------------------------------------------------- Comment By: Andrew Langmead (langmead) Date: 2004-06-19 04:04 Message: Logged In: YES user_id=119306 I'm not sure if the current behavior should be maintained or not, but it looks like to me that the readline module has always generated a KeyboardInterrupt, regardless of whether SIGINT has been overridden. This is a bit odd though. It causes the SIGINT handling to change depending on whether or not you are at the top level interpreter's prompt. wantarray% cat /tmp/foo.py import signal def foo(sig, frame): print "caught foo" signal.signal(signal.SIGINT, foo) wantarray% python -i /tmp/foo.py >>> foo >>> ^C KeyboardInterrupt >>> while 1: ... pass ... ^Ccaught foo ^Ccaught foo ^Ccaught foo ^Ccaught foo ^\zsh: quit python -i /tmp/foo.py ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-18 13:54 Message: Logged In: YES user_id=6656 The problem with that approach is: what if you want a handler for SIGINT that doesn't raise KeyboardInterrupt? Other than that, it sounds like your plan should work. I've attached a slightly cleaned up version of my patch which makes signal handling in the "without readline" case more like yesterday's patch made the "with readline" case. ---------------------------------------------------------------------- Comment By: Andrew Langmead (langmead) Date: 2004-06-18 03:35 Message: Logged In: YES user_id=119306 Here is another possible approach to solving the problem of readline exiting for signals other than SIGINT. I'm not sure if it is better or worse than the scarypatch. As you said, the call to readline is performed without the GIL. So is the actual C-level signal handler from the signal module (the python code that gets associated with the signal is deferred until later.) At the time we see the EINTR, there is a flag in the signal module's Handler array to say whether the signal that we received was a SIGINT. If we added some sort of interface within the signal module to find out what signals are pending to be run on the next call to PyErr_CheckSignals, then we could find out if the EINTR was caused by an INT (at which point we should exit) or by another signal (at which we could just retry the select.) Is there any potential to this approach? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-17 18:25 Message: Logged In: YES user_id=6656 BTW, I'd really really like someone to review this :-) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-17 18:24 Message: Logged In: YES user_id=6656 How about the attached? It's a bit ... scary. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-17 17:08 Message: Logged In: YES user_id=6656 A potential problem with this patch is that it causes input to be interrupted (with a KeyboardInterrupt exception) when any handled signal is delivered. This seems suboptimal. It's appealing to try to run the (Python) signal handlers in the errno == EINTR case of readline_line_until_enter_or_signal, but that has problems in that PyOS_ReadlineFunctionPointer is called without the GIL being held and once that is dealt with, an installed Python signal handler attempting to call readline at this point can reasonably be expected to result in all hell breaking loose. I don't know what the correct solution is here. Add our own rentrancy checks and learn how to work the Python threadstate API properly? Thoughts, anyone? Or have I scared everyone away now? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-12 11:17 Message: Logged In: YES user_id=6656 Now a rewrite of the test that actually works! ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-12 11:08 Message: Logged In: YES user_id=6656 Here's a version of the patch that includes the new unit test (oops!) which I've rewritten slightly. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-06-11 17:02 Message: Logged In: YES user_id=29957 No - wait. Ignore that test_timeout error, it exists with a clean checkout. The inability to interrupt make testall, however is new with this patch. Linux Fedora Core 2. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-06-11 16:58 Message: Logged In: YES user_id=29957 With this patch: bonanza% ./python Lib/test/test_timeout.py testBlockingThenTimeout (__main__.CreationTestCase) ... ok testFloatReturnValue (__main__.CreationTestCase) ... ok testObjectCreation (__main__.CreationTestCase) ... ok testRangeCheck (__main__.CreationTestCase) ... ok testReturnType (__main__.CreationTestCase) ... ok testTimeoutThenBlocking (__main__.CreationTestCase) ... ok testTypeCheck (__main__.CreationTestCase) ... ok testAcceptTimeout (__main__.TimeoutTestCase) ... ok testConnectTimeout (__main__.TimeoutTestCase) ... FAIL testRecvTimeout (__main__.TimeoutTestCase) ... ok testRecvfromTimeout (__main__.TimeoutTestCase) ... ok testSend (__main__.TimeoutTestCase) ... ok testSendall (__main__.TimeoutTestCase) ... ok testSendto (__main__.TimeoutTestCase) ... ok ====================================================================== FAIL: testConnectTimeout (__main__.TimeoutTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "Lib/test/test_timeout.py", line 121, in testConnectTimeout "timeout (%g) is more than %g seconds more than expected (%g)" AssertionError: timeout (4.48679) is more than 2 seconds more than expected (0.001) ---------------------------------------------------------------------- Ran 14 tests in 17.445s FAILED (failures=1) Traceback (most recent call last): File "Lib/test/test_timeout.py", line 192, in ? test_main() File "Lib/test/test_timeout.py", line 189, in test_main test_support.run_unittest(CreationTestCase, TimeoutTestCase) File "/home/anthony/src/py/pyhead/dist/src/Lib/test/test_support.py", line 290, in run_unittest run_suite(suite, testclass) File "/home/anthony/src/py/pyhead/dist/src/Lib/test/test_support.py", line 275, in run_suite raise TestFailed(err) test.test_support.TestFailed: Traceback (most recent call last): File "Lib/test/test_timeout.py", line 121, in testConnectTimeout "timeout (%g) is more than %g seconds more than expected (%g)" AssertionError: timeout (4.48679) is more than 2 seconds more than expected (0.001) Also, with this patch applied, I can no longer kill a 'make testall' with a ^C ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-11 15:18 Message: Logged In: YES user_id=6656 The patch didn't apply, so I've updated it (attached). I see test_asynchat fail occasionally now, but don't know if that's because of this patch :-( Once I've sorted that out in my head, I think I'm going to check this in. ---------------------------------------------------------------------- Comment By: Andrew Langmead (langmead) Date: 2004-05-29 06:49 Message: Logged In: YES user_id=119306 Here is a reformatted version of the patch. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-05-28 15:25 Message: Logged In: YES user_id=31435 I agree that "busy" always should have been volatile -- once again, good eye! Python C style is basically K&R Classic, hard tab for indentation, open curly at the end of the line opening a block except for first line of function definition. Just make it look like the other C code, but be careful to pick one of the .c files Guido approves of . ---------------------------------------------------------------------- Comment By: Andrew Langmead (langmead) Date: 2004-05-28 13:37 Message: Logged In: YES user_id=119306 Thank you for pointing me to PEP 7. I'll take a look at where I am amiss and fix it up. For the change in ceval.c, I took a look at gcc's x86 assembly output of the file, and noticed that the optimizer was altering the order of the busy flag test. Since busy is set from other concurrent execution (other signal handlers), changing the variable to volatile told gcc not to optimize accesses to the variable. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-28 09:54 Message: Logged In: YES user_id=6656 I haven't been able to test on MacOS X further, unfortunately. The patch works on linux/x86 though (after fixing the TabError :-) but this is with an NTPL kernel, so I didn't have a problem anyway. The C doesn't all conform to the Python style -- see PEP 7. Can you fix that? Why the change to Python/ceval.c? After all that -- thanks a lot! I really want to get this checked in ASAP so we can find out which platforms it breaks at the earliest point in the 2.4 cycle. ---------------------------------------------------------------------- Comment By: Andrew Langmead (langmead) Date: 2004-05-27 07:04 Message: Logged In: YES user_id=119306 It seems that at least OS X, sending the kill to the process schedules that the receiving process will run the signal handler at some later time. (it seems to be the only one to frequently run the signal handlers in the opposite order than they were sent) This revised version of the test seems to work better on OS X. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-26 19:41 Message: Logged In: YES user_id=6656 test_threadsignals hangs for me on OS X. Haven't done anything more thorough than that yet... ---------------------------------------------------------------------- Comment By: Andrew Langmead (langmead) Date: 2004-05-26 18:48 Message: Logged In: YES user_id=119306 I apologize that the missing patch. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-26 18:22 Message: Logged In: YES user_id=6656 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. In addition, even if you *did* check this checkbox, a bug in SourceForge prevents attaching a file when *creating* an issue. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=960406&group_id=5470 From noreply at sourceforge.net Sat Jun 19 11:23:37 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jun 21 00:36:19 2004 Subject: [Patches] [ python-Patches-975885 ] compileall.py - print file name in err msg in quiet mode Message-ID: Patches item #975885, was opened at 2004-06-19 15:23 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=975885&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: compileall.py - print file name in err msg in quiet mode Initial Comment: compileall.py - print file name in err msg in quiet mode, else it get's difficult to find the file the error occurred in. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=975885&group_id=5470 From JWKGOHBDFHHPT at hajmail.com Sat Jun 19 08:52:09 2004 From: JWKGOHBDFHHPT at hajmail.com (riches consultant) Date: Mon Jun 21 00:36:45 2004 Subject: [Patches] low USA rates starting 3.52% g f i Message-ID: <35986199.13412@JWKGOHBDFHHPT@hajmail.com> An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20040619/2817824f/attachment-0001.html From noreply at sourceforge.net Sun Jun 20 06:10:22 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jun 21 00:59:19 2004 Subject: [Patches] [ python-Patches-976162 ] Deferred String Addtion: Proof-of-concept Message-ID: Patches item #976162, was opened at 2004-06-20 05:10 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforg-? ?>U?c?F@?F@?F@?F@305470&aid=976162&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 1 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Nobody/Anonymous (nobody) Summary: Deferred String Addtion: Proof-of-concept Initial Comment: The attached patch demonstrats a possible implementation for deferred string addition. The idea is to have str.__add__ save references to its inputs rather that do the concatenation immediately. The moment some other method needs the full string, it is generated recursively so that the whole concatenation can be done with a single join. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=976162&group_id=5470 From noreply at sourceforge.net Sun Jun 20 17:03:56 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jun 21 01:12:30 2004 Subject: [Patches] [ python-Patches-975885 ] compileall.py - print file name in err msg in quiet mode Message-ID: Patches item #975885, was opened at 2004-06-19 17:23 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=975885&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: compileall.py - print file name in err msg in quiet mode Initial Comment: compileall.py - print file name in err msg in quiet mode, else it get's difficult to find the file the error occurred in. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-06-20 23:03 Message: Logged In: YES user_id=21627 Thanks for the patch. Applied as compileall.py 1.16; 1.14.12.2; NEWS 1.831.4.123 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=975885&group_id=5470 From noreply at sourceforge.net Sun Jun 20 18:52:00 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jun 21 01:14:19 2004 Subject: [Patches] [ python-Patches-876130 ] add C API to datetime module Message-ID: Patches item #876130, was opened at 2004-01-13 10:20 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=876130&group_id=5470 Category: Modules Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Anthony Tuininga (atuining) Assigned to: Tim Peters (tim_one) Summary: add C API to datetime module Initial Comment: The datetime module does not have a C API which means that modules written in C cannot take advantage of the datetime module without incurring significant overhead. These patches supply this lack and are based on the C API exported by the mxDateTime module and the cStringIO module and enhanced as suggested by Guido. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2004-06-20 18:51 Message: Logged In: YES user_id=31435 Thanks for your patience, Anthony! I checked this in after minor fiddling. Biggest change was to supply a new macro and docs, to expose the unreferenced Delta_FromDelta member of the C API struct. I do wish we had test cases -- as is, these maros could be totally busted and we'd have no way to know that. But virtually all of the C API is untested that way, so it's not a fatal objection. Doc/api/concrete.tex; new revision: 1.45 Include/datetime.h; new revision: 1.5 Misc/ACKS; new revision: 1.267 Misc/NEWS; new revision: 1.1008 Modules/datetimemodule.c; new revision: 1.74 The answers to your questions are implicit in what I checked in . Note that in 2.4, datetimemodule.c *is* compiled as part of the core. Guido nevertheless didn't want the datetime API to take advantage of that (I'm unclear on why). I'm content to document the macros and leave it at that. The DB API functions don't bother me one way or the other, so left them in. ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-06-14 11:23 Message: Logged In: YES user_id=619560 I have attached a patch for the documentation as requested. Not being certain of the format and requirements for the content, your comments are appreciated. I have a few questions that might help focus your comments. 1) Should the API structure be documented and users of datetime.h encouraged to use it directly? Or should it be "implementation details" and only those methods that I have provided should be available? To help answer this question, is it intended to ever bring datetime objects into the "core" rather than as a separate module? 2) The DB API helper functions are provided because Marc Andre Lemburg thought it would be a good idea. Please take a look and see if it makes sense now that it is documented. :-) Please review and give me your feedback. Thanks. ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-06-07 09:57 Message: Logged In: YES user_id=619560 Yes, the top two files are the ones involved. As per your suggestion I deleted the other four files to avoid further confusion. I understand the concern for documentation. I'll see what I can do to get at least a preliminary patch on that front ready this week. Earlier discussions suggested that the documentation reside solely in the include file but I think adding a section to the Python/C API documentation would make a lot more sense. Please stand by. :-) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-06-05 19:43 Message: Logged In: YES user_id=31435 Assuming the current state of the proposal consists of the first two patches on the list ("patch for datetimemodule.c" and "patch for datetime.h"), I'm probably happy to commit them. Can't say for sure right now, because SF CVS is dead, and can't get a current checkout to try them with. The one necessary thing I don't see are docs: how are users supposed to know this exists, let alone know how to use it? We need a new section for datetime objects in the Python/C API Reference Manual, in the Other Objects part of the Concrete Objects Layer section. You don't have to write LaTeX, plain text is fine. Look at the other sections in that chapter for what's needed (an overview, and a precise account of what's in the new C API and how to use it). Don't let that discourage you -- you're very close! If I don't force docs out of you now, docs will never get written. That's why I'm trying to force docs out of you now . ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-06-05 19:10 Message: Logged In: YES user_id=31435 Heh. Just noticed there are 6 patches attached to this report. Are all of them part of the suggested change, or, if not, which are the current ones (if that's the case, the best way to answer the question is to delete the out-of-date patches)? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-06-01 13:53 Message: Logged In: YES user_id=31435 I intend to do it this week, but have no time today or tomorrow. ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-06-01 13:44 Message: Logged In: YES user_id=619560 Sure. What's the chance of it being reviewed prior to the release of Python 2.4 a1? I just saw the preannouncement today -- it is scheduled for the end of this month, I believe. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-05-31 23:12 Message: Logged In: YES user_id=31435 Assigned to me for the next review. Can't do it immediately, but will do my best to free up some time for it "soon". ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-05-26 15:39 Message: Logged In: YES user_id=619560 I would agree with your assessment of the issue regarding the TimeFromTicks() API and find it quite reasonable. Either implement both at the C and Python levels or not at all. Since there is no consensus on this, none it is. :-) Did you have a chance to review the actual code? The changes are fairly minimal but you might have questions about readability, names, etc. It would be great if this could be included in an upcoming 2.4 alpha/beta so that I can provide support in cx_Oracle for the next release. Thanks for your time. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-05-26 15:32 Message: Logged In: YES user_id=31435 Under the belief that the *intent* of this patch is to add a C API to Python's datetime module, it should stick to exposing C ways to spell what Python programmers can already do from Python using datetime. Since nothing like TimeFromTicks() exists in the Python datetime API, it simply doesn't make sense to invent one available only from C. It *may* make sense to invent one in a DB API wrapper around datetime, but I view that as out of scope for this patch. I would not add TimeFromTicks() to the Python datetime API either, because the docs are ambiguous. The sample implementation Marc-Andre posted here uses localtime() to resolve the ambiguity in the docs, but that has to be a wrong choice for some time-of-day apps. For example, there's apparently no portable way to spell "noon" using TimeFromTicks(): the value you get back depends on which time zone localtime() happens to use at the time it's called. If people want time-of-day from a POSIX timestamp, it remains easy to get it from what datetime already supplies, but to do so you have to be explicit about whether you want UTC or local time interpretation. Both are easily spelled already, and it's a Good Thing that you need to be explicit if you want to do such a thing. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-05-26 15:25 Message: Logged In: YES user_id=38388 Tim, please review. Thanks. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-05-26 15:22 Message: Logged In: YES user_id=38388 Thanks, but I don't have time to review it. As for the TimeFromTicks() API: I can understand that you don't feel like implementing it, but hey, I won't use datetime either. The only reason I'm trying to push full support of the DB API specs is that Guido et al. wanted to see a note in the DB API that datetime also provides a usable interface to do date/time interfacing. I'm not very interested in datetime myself, since I'll continue to use mxDateTime, so the situation for me is somewhat similar to yours: investing time into something that I myself will probably not use much (I will add support to mxODBC for those who like to use datetime instead of mxDateTime, but won't use it myself). Feel free to check in your changes. Thanks. ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-05-26 12:30 Message: Logged In: YES user_id=619560 Attached are the modified patches based on your suggestions. I have tested them with my own module cx_Oracle and they appear to work correctly. Any further suggestions would be appreciated. I would like to see this included for Python 2.4 if at all possible. Please let me know what I need to do (if anything) to get this to happen. As for the TimeFromTicks() routine, Oracle has absolutely no use for a "time-only" data type and does not support it. It clearly does not have broad support so I really have no desire to implement it since I will never use it myself. If you consider it important, you could add it yourself or we could wait until someone else who requires it for their implementation of the DB API requires it. I'm not trying to be rude or trying to denigrate the DB API, simply trying to be practical. Please let me know if this is offensive in any way. Thanks. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-05-19 04:28 Message: Logged In: YES user_id=38388 >From the DB API specs: TimeFromTicks(ticks) This function constructs an object holding a time value from the given ticks value (number of seconds since the epoch; see the documentation of the standard Python time module for details). The reason for this having this API is to be able to construct an object suitable for passing to the database given a Unix ticks value. Since the ticks value contains both a date and a time part and most databases have a special column type for time value, we need two constructor APIs, one to extract just the date part and one for the time part. Here's the mxDateTime implementation for reference: def TimeFromTicks(ticks, # Locals: DateTimeDelta=DateTimeDelta,localtime=_time.localtime): """ TimeFromTicks(ticks) Constructs a DateTimeDelta instance pointing to the local time indicated by the given ticks value. The date part is ignored. """ return apply(DateTimeDelta, (0,) + localtime(ticks)[3:6]) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-05-03 13:46 Message: Logged In: YES user_id=31435 I don't understand what TimeFromTicks() is supposed to do. Seconds-from-the-epoch is a point in time, not a time-of- day. If some DB API requires guessing some transformation from seconds-from-the-epoch to time-of-day, that's fine, but it doesn't belong in Python's datetime module. The datetime module should certainly have a method to construct a datetime.datetime from a seconds-from-the- epoch argument -- seconds-from-the-epoch is a way of specifying a datetime.datetime. Given that, if the intent is to throw away the datetime.date portion of the datetime.datetime object, retaining only the datetime.time portion, then that's trivially accomplished by invoking dt.time () (where dt is the datetime.datetime object). Do any databases really store time-of-day as a seconds-from- the-epoch value? Google's top hit on TimeFromTicks() today happens to be a msg from Anthony saying that Oracle does not. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-05-03 13:24 Message: Logged In: YES user_id=38388 Macro: I don't know whether you need the macro or not (you probably do for the type checks). In any case, you can do without relying on Python providing you this information via the build process, since only datetimemodule.c is using the header file while Python is being built. TimeFromTicks(): I' ve stated my point. I don't think there's anything to add - I'm tired of fighting for these things... one of the reasons I stopped actively discussing things on python-dev. IMHO, a product that's aimed at developers should make things easy for the developer and try to avoid code duplication if possible. The API is needed in order to support database interfaces that use Unix ticks as basis for date/time, so if you don't add it to the module, the ten or twenty module authors out there will have to duplicate that piece of work in their implementation. Transition: This was already discussed on the db-api list. We love freedom of choice. Nothing to add. ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-05-03 12:48 Message: Logged In: YES user_id=619560 About the Py_BUILD_CORE issue: You are suggesting that I define this in datetimemodule.c just prior to the include of datetime.h? Or are you suggesting some other macro? I am not sure about the comment about "not needing a macro in the first place" since there are two groups that will be importing datetime.h: the first being the datetime module itself and the second being the DB API modules. The macro is definitely required to distinguish between the two -- unless I am missing something? On the TimeFromTicks() issue: You obviously consider it important that the three methods be available at the C level for DB API module authors to use directly. My objection is simply a reiteration of an objection raised by Tim Peters. I think you'll have to argue that one with him. :-) I'll provide my implementations for cx_Oracle as part of the patches and then you can fight it out and I'll stay out of it. :-) As for the transition period, I assumed that with the introduction of a standard datetime module, that it would become the suggested implementation for database interfaace modules. That said, I don't really have any authority to say anything on this front so I'll leave that to you and others to decide. :-) ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-05-03 11:26 Message: Logged In: YES user_id=38388 About the Py_BUILD_CORE issue: Sorry, I didn't know that Python does not define this macro for core modules. Nevertheless, looking at the datetime module code I don't really understand why you would need such a macro in the first place. Since the datetime module is the only code including the datetime.h header file it should be easy to add a macro definition just before importing datetime.h. On the TimeFromTicks() issue: The whole point of this discussion is to make the datetime module easily usable for authors of database modules. Since the DB API specifies that the module will need to export the three functions, two of which are available through the datetime module already, I don't really see your point in not wanting to add it. BTW, you are wrong in the assumption that the DB API spec will move away from a generic API for date/time objects. The DB API has always been defined in terms of interfaces and does not force a certain set of tools onto the developer. The datetime module will become one possible choice for DB API authors, others will want to stick to mxDateTime, use strings, ticks integers or more specific objects for interfacing. That won't change, so there is no "transition period". ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-05-03 10:40 Message: Logged In: YES user_id=619560 I spent some time getting the two include files merged together, only to discover that Py_BUILD_CORE is __NOT__ defined when building modules, only when building stuff linked directly into the core interpreter. Perhaps this ought to be defined when building the modules with setup.py? At any rate, I cannot proceed along the route suggested without this problem being resolved. On the DateFromTicks(), TimestampFromTicks(), TimeFromTicks() issue, I'm not sure that there is much benefit to including a C API for this since if the datetime module becomes the standard method for managing datetime objects, there is no point in having the DB API modules provide something that the datetime module already provides, right? During the transition period the few lines of code needed can be posted. If you disagree I can certainly provide the few lines as part of the patch but I suspect you will find resistance to having this included by Tim Peters, the maintainer (I believe) of the datetime module. Feel free to correct me... :-) ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-04-26 12:19 Message: Logged In: YES user_id=38388 Sorry for not getting back to you earlier: I didn't see you last message. 1-4) Python defines a macro during the Python build process that is not defined when compiling extensions: Py_BUILD_CORE You can use that macro to compile things differently for core things vs. extensions. 5) Fair enough; I don't see a point in creating a new numbering for each and every module. Please just use 1, 2, 3, 4, ... 6) Hope this makes sense :-) ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-04-26 11:35 Message: Logged In: YES user_id=619560 Any chance to look at this? Any hope of this being included in Python 2.4? I know a number of people (including Guido) who would appreciate that.... :-) ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-04-05 18:04 Message: Logged In: YES user_id=619560 I am back at work after finishing my move so I think I can finally devote a little more time to this issue. 1-4) The main reason for datetimeapi.h as opposed to simply modifying datetime.h was that the internal build needs to define things __differently__ from an external build of a module and there doesn't appear to be any way of fixing that -- so if you know a way I think I can manage to create a reasonable patch; otherwise, I'm out of my depth! 5) Guido was suggesting that a new PyIMPORT macro be made available which would verify that the magic number defined in the header file actually matches the magic number exported by the built module; this is simply a developer protection scheme which should eliminate really stupid uses; you can ask him about this or I can e-mail you part of the thread that brought this up 6) Makes sense. I'd like to get the questions above resolved first before proceeding any further, though. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-03-25 13:23 Message: Logged In: YES user_id=38388 Thanks for the comments... 1) Please put *all* the code for the C API into datetimeapi.h. I don't like your current mix of putting some things into datetime.h and others into datetimeapi.h (e.g. the PyDateTime_CAPI definition). 2) Since it's the only API missing if you want to use datetime objects in database interfacing, please add it. 3) dito. 4) Yes, the header file is the right place. Have a look at unicodeobject.h for what I have in mind (or mxDateTime.h for that matter). 5) Why add yet another magic number ? Isn't the Python API number enough ? 6) Since you don't provide a doc patch, please put comments into the header file. There can never be enough documentation and developers tend to look at the code rather than the docs ;-) ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-03-25 13:08 Message: Logged In: YES user_id=619560 Sorry for the delay. Things here have been quite busy recently both at work and at home. Let me see if I can answer your questions. 1) are you suggesting comments that include the macro names in datetimeapi.h similar to what I put in the comments below? Or something else? See modified datetimeapi.h for more info. 2) TimeFromTicks() is a very DB API specific routine. In chatting with others about the datetime module, they were not keen on adding such a beast. I guess there will have to be some discussion about whether datetimeapi.h is also a sort of half implementation for a C module implementing the DB API. I was intending to do this in my cx_Oracle module but not in datetimeapi.h. Could you clarify? 3) I could add C APIS for the three DB API ticks interfaces but I was simply intending to do that in cx_Oracle. Again, see #2. I can do it either way. :-) 4) I have added limited documentation in datetimeapi.h but is that really the right place for it? Is it even remotely close to what is needed? I'm not sure what is needed here exactly. 5) the API magic number is simply an arbitrary number which is stored in datetime.h and need not be understood by the implementor. For your information I simply took the name "datetime", converted each letter to its ordinal value in the alphabet, modded by 16 and used that hex character -- does that make any sense? This can be changed to whatever makes sense, though. 6) Whether or not datetimeapi.h should be sufficient for a developer or whether he should look at documentation in the usual locations (html pages, for example) I'll leave up to the Python development team. Let me know how I can assist. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-03-25 12:35 Message: Logged In: YES user_id=38388 Anthony, have you had a chance to look at the comments ? ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-02-26 10:06 Message: Logged In: YES user_id=619560 Oops! It looks like my own misunderstanding of SourceForge and how it works is to blame. :-( I'll take a look at this and get back to you as soon as possible -- ignore my previous comment. ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-02-26 10:03 Message: Logged In: YES user_id=619560 You haven't yet responded to my previous comments -- it looks like SourceForge put them __after__ your comments so it is quite understandable why you didn't notice them. If you can give me the answers to those questions or provide additional questions that I need to answer, then I think we can make progress again. I was waiting for __you__ :-) ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-02-25 18:08 Message: Logged In: YES user_id=38388 Any progress on this ? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-01-28 06:49 Message: Logged In: YES user_id=38388 Thanks for the clarification. I had forgotten about the macros -- I'd suggest that you document them in the datetimeapi.h include file to not cause the same confusion on the developer side (the trick to achieve adoption is to make things easy on the developer). As for TimeFromTicks(): This should be rather straight forward to implement: you take the time part of the ticks timestamp and create a time object from it. This is the way the DB API constructor works. Could you add C APIs for the three DB API ticks interface methods ? Other things that are missing: * documentation of the way the CAPI object can be used in datetimeapi.h * documentation of the various CAPI entries * documentation of the API magic number (there should be some scheme for this) I think that datetimeapi.h should be enough for a developer to read in order to use the interface. ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-01-26 16:02 Message: Logged In: YES user_id=619560 I didn't think any additional API would be necessary for extracting date time information since the following macros are available: PyDateTime_GET_YEAR(o) PyDateTime_GET_MONTH(o) PyDateTime_GET_DAY(o) PyDateTime_DATE_GET_HOUR(o) PyDateTime_DATE_GET_MINUTE(o) PyDateTime_DATE_GET_SECOND(o) PyDateTime_DATE_GET_MICROSECOND(o) PyDateTime_TIME_GET_HOUR(o) PyDateTime_TIME_GET_MINUTE(o) PyDateTime_TIME_GET_SECOND(o) PyDateTime_TIME_GET_MICROSECOND(o) Were you thinking of something else that is needed? As for interfacing at the C level for converting from Unix ticks, the following method is already available and could simply be used as a drop in replacement for DateFromTicks() and TimestampFromTicks() from the DB API document. DateFromTicks() --> datetime.date.fromtimestamp() TimestampFromTicks() --> datetime.datetime.fromtimestamp() TimeFromTicks() is not already exposed but discussions with Tim Peters already suggested that would not happen since the concept is rather strange. You'll have to discuss that with him if you disagree! :-) Any comments? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-01-26 15:46 Message: Logged In: YES user_id=38388 This is a good start. However, you should add more APIs for extracting date/time information to the C API. mxDateTime.h from egenix-mx-base can provide a good basis for this. If you want to make the datetime module usable for database interfacing at C level, you'll also have to add interfaces for Unix ticks conversion, since these are often used by database C level interfaces. ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-01-26 13:36 Message: Logged In: YES user_id=619560 I have no objection to providing patches for doc and test. A quick look at _testcapimodule.c doesn't provide any obvious ideas as to how to patch it. I looked for cStringIO which has a C API already and found nothing in there at all. The documentation also simply says "see the source for the information you require". Any suggestions as to how to proceed? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-01-25 22:17 Message: Logged In: YES user_id=31435 Marc-Andre, can you review this? I think you have more experience building C APIs for modules than anyone else (while I don't have any). There's certainly no objection to giving datetime a C API, and Guido already said he doesn't want to rely on that Martin changed datetime to be built as part of the core (in 2.3 on Windows, datetime.pyd was a distinct DLL; in CVS, datetime is compiled into the core DLL now). Anthony, you probably need to add doc and test patches. _testcapimodule.c holds tests of things you can only get at from C. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=876130&group_id=5470 From noreply at sourceforge.net Mon Jun 21 10:31:55 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jun 21 11:05:57 2004 Subject: [Patches] [ python-Patches-976162 ] Deferred String Addtion: Proof-of-concept Message-ID: Patches item #976162, was opened at 2004-06-20 06:10 Message generated for change (Comment added) made by jimjjewett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=976162&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 1 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Nobody/Anonymous (nobody) Summary: Deferred String Addtion: Proof-of-concept Initial Comment: The attached patch demonstrats a possible implementation for deferred string addition. The idea is to have str.__add__ save references to its inputs rather that do the concatenation immediately. The moment some other method needs the full string, it is generated recursively so that the whole concatenation can be done with a single join. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2004-06-21 10:31 Message: Logged In: YES user_id=764593 There is an implicit assumption that any component/part with its own 'components' attribute will be another UserString (or, at the very least, will act like one when traversed). Would it be better to check whether the subobject actually is a UserString (since new-style objects can freely use multiple inheritance), or to do some sort of guard in add? (Perhaps immediately stringifying anything with a components attribute that is not a UserString?) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=976162&group_id=5470 From noreply at sourceforge.net Mon Jun 21 12:40:57 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jun 21 14:19:50 2004 Subject: [Patches] [ python-Patches-976869 ] Stripping script extensions with distutils Message-ID: Patches item #976869, was opened at 2004-06-21 12:40 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=976869&group_id=5470 Category: Distutils and setup.py Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Nobody/Anonymous (nobody) Summary: Stripping script extensions with distutils Initial Comment: The attached patch adds the ability to distutils to have extensions stripped from scripts when they are "built". This adds an option, --strip-extensions, to the build_scripts command which defaults to false; the option is only honored on systems for which os.name == "posix" and sys.platform != "darwin". While I generally like the idea of such a feature, there are some open issues regarding this: 1. To support legacy applications which install scripts with extensions but which want the new option to apply to more recently added scripts by default, there needs to be a way to specify this on a per-script basis. I've not thought about how to do this yet, but I'd generally prefer to have this option set in a setup.cfg file included in a distribution. 2. Mac OS X appearantly still has some issues with the differences between GUI and non-GUI applications, and the extension on a script is being used to help determine the context in which scripts should be run. As a result, I think this feature should not be accepted in this form, but warrants further thought to make it easier to create a declarative way to specify what the proper treatment of individual scripts should be. I'm posting the patch so others can review it, and to provide a record of these issues. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=976869&group_id=5470 From JocelynSnow at berlin.com Mon Jun 21 18:56:33 2004 From: JocelynSnow at berlin.com (Freda Floyd) Date: Mon Jun 21 18:19:03 2004 Subject: [Patches] Chang Customer Rewards Activation W Message-ID: An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20040622/f8be5f77/attachment.html From noreply at sourceforge.net Mon Jun 21 18:39:19 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jun 21 18:42:37 2004 Subject: [Patches] [ python-Patches-977074 ] speed up md5: allow Encode and Decode to inline Message-ID: Patches item #977074, was opened at 2004-06-21 15:39 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=977074&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthew Mueller (donut) Assigned to: Nobody/Anonymous (nobody) Summary: speed up md5: allow Encode and Decode to inline Initial Comment: gcc will only inline functions if they are defined before where they are used. So this patch just moves Encode and Decode up to the top of the file. This can provide a couple percent improvement in speed. (try timeit.py -s 'import md5; m=md5.new(); d="a"*64' 'm.update(d);m.digest()' and timeit.py -s 'import md5; m=md5.new(); d="a"*0x100000' 'm.update(d)' ) Decode is only used once, so allowing it to inline actually reduces the code size, Encode is used twice but its a pretty small function so it doesn't change the size much either way.. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=977074&group_id=5470 From noreply at sourceforge.net Tue Jun 22 00:28:35 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jun 22 00:28:56 2004 Subject: [Patches] [ python-Patches-976162 ] Deferred String Addtion: Proof-of-concept Message-ID: Patches item #976162, was opened at 2004-06-20 05:10 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=976162&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 1 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Nobody/Anonymous (nobody) Summary: Deferred String Addtion: Proof-of-concept Initial Comment: The attached patch demonstrats a possible implementation for deferred string addition. The idea is to have str.__add__ save references to its inputs rather that do the concatenation immediately. The moment some other method needs the full string, it is generated recursively so that the whole concatenation can be done with a single join. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-06-21 23:28 Message: Logged In: YES user_id=80475 The patch is not meant to be loaded to UserString. Rather it is a proof-of-concept demonstration of how deferred string addition would work. Even it pure python form, it shows how to convert an O(n**2) process to O(n). If the concept is approved, the goal is to alter the C code for stringobject.c, unicodeobject.c, and to make a more thorough version for UserString. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2004-06-21 09:31 Message: Logged In: YES user_id=764593 There is an implicit assumption that any component/part with its own 'components' attribute will be another UserString (or, at the very least, will act like one when traversed). Would it be better to check whether the subobject actually is a UserString (since new-style objects can freely use multiple inheritance), or to do some sort of guard in add? (Perhaps immediately stringifying anything with a components attribute that is not a UserString?) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=976162&group_id=5470 From e.william_ls at stapro.cz Tue Jun 22 00:47:16 2004 From: e.william_ls at stapro.cz (Charlene E. William) Date: Tue Jun 22 00:51:08 2004 Subject: [Patches] $23221 Message-ID: <86d201c45813$0e23caf7$7548b4ae@yahoo.no> Hello, I sent you an email a few days ago, because you now qualify for a new mortgage. You could get $300,000 for as little as $700 a month! Bad credit is no problem, you can pull cash out or refinance. Please click on this link: http://www.refifast.biz/aff/affiliate.php?uid=71 Best Regards, Steve Morris ---- system information ---- Claim(s) display impossible setting Note identification presented show future Membership on Task zones expects distinction mail items Content-Language consistent provider expectations scenarios representing offer From noreply at sourceforge.net Mon Jun 21 22:59:41 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jun 22 01:09:36 2004 Subject: [Patches] [ python-Patches-960406 ] unblock signals in threads Message-ID: Patches item #960406, was opened at 2004-05-25 17:00 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=960406&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: Andrew Langmead (langmead) >Assigned to: Michael Hudson (mwh) Summary: unblock signals in threads Initial Comment: This is a patch which will correct the issues some people have with python's handling of signal handling in threads. It allows any thread to initially catch the signal mark it as triggered, allowing the main thread to later process it. (This is actually just restoring access to the functionality that was in Python 2.1) The special SIGINT handling for the python readline module has been changed so that it can now see an EINTR error code, rather than needing a longjmp out of the readline library itself. If the readline library python is being linked to doesn't have the callback features necessary, it will fall back to its old behavior. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2004-06-21 22:59 Message: Logged In: YES user_id=6380 Ideally, ^C should always cause the signal handler for SIGINT to be called, and the KeyboardInterrupt should be generated by the default SIGINT handler. For 2.3, keeping whatever semantics ^C from readline has at the moment should be preserved -- we only want bugfixes, not new features... What else did you want from me? (I'm also lacking focus, or at least time to think about this stuff in detail.) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-19 06:14 Message: Logged In: YES user_id=6656 Yes, I think you're right. I guess I'm suffering a lack of focus, finding it hard to resist the impulse to fix what look like ancient bogosities in the area while I'm there... (also see the way a NULL return from PyOS_Readline is assumed to be a keyboard interrupt). One could argue that ^C should always interrupt an interactive session, but one could also argue that users shouldn't be so daft as to install handlers for SIGINT if they want that to be true (after all, they can make life hard for themselves if they want with stty(1)). A downside to all this footling is that it makes a backport to 2.3 harder to justify. Hmm. I wander what Guido thinnks (he's alledgedly "now maintaining" Modules/readline.c :-). ---------------------------------------------------------------------- Comment By: Andrew Langmead (langmead) Date: 2004-06-18 23:04 Message: Logged In: YES user_id=119306 I'm not sure if the current behavior should be maintained or not, but it looks like to me that the readline module has always generated a KeyboardInterrupt, regardless of whether SIGINT has been overridden. This is a bit odd though. It causes the SIGINT handling to change depending on whether or not you are at the top level interpreter's prompt. wantarray% cat /tmp/foo.py import signal def foo(sig, frame): print "caught foo" signal.signal(signal.SIGINT, foo) wantarray% python -i /tmp/foo.py >>> foo >>> ^C KeyboardInterrupt >>> while 1: ... pass ... ^Ccaught foo ^Ccaught foo ^Ccaught foo ^Ccaught foo ^\zsh: quit python -i /tmp/foo.py ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-18 08:54 Message: Logged In: YES user_id=6656 The problem with that approach is: what if you want a handler for SIGINT that doesn't raise KeyboardInterrupt? Other than that, it sounds like your plan should work. I've attached a slightly cleaned up version of my patch which makes signal handling in the "without readline" case more like yesterday's patch made the "with readline" case. ---------------------------------------------------------------------- Comment By: Andrew Langmead (langmead) Date: 2004-06-17 22:35 Message: Logged In: YES user_id=119306 Here is another possible approach to solving the problem of readline exiting for signals other than SIGINT. I'm not sure if it is better or worse than the scarypatch. As you said, the call to readline is performed without the GIL. So is the actual C-level signal handler from the signal module (the python code that gets associated with the signal is deferred until later.) At the time we see the EINTR, there is a flag in the signal module's Handler array to say whether the signal that we received was a SIGINT. If we added some sort of interface within the signal module to find out what signals are pending to be run on the next call to PyErr_CheckSignals, then we could find out if the EINTR was caused by an INT (at which point we should exit) or by another signal (at which we could just retry the select.) Is there any potential to this approach? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-17 13:25 Message: Logged In: YES user_id=6656 BTW, I'd really really like someone to review this :-) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-17 13:24 Message: Logged In: YES user_id=6656 How about the attached? It's a bit ... scary. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-17 12:08 Message: Logged In: YES user_id=6656 A potential problem with this patch is that it causes input to be interrupted (with a KeyboardInterrupt exception) when any handled signal is delivered. This seems suboptimal. It's appealing to try to run the (Python) signal handlers in the errno == EINTR case of readline_line_until_enter_or_signal, but that has problems in that PyOS_ReadlineFunctionPointer is called without the GIL being held and once that is dealt with, an installed Python signal handler attempting to call readline at this point can reasonably be expected to result in all hell breaking loose. I don't know what the correct solution is here. Add our own rentrancy checks and learn how to work the Python threadstate API properly? Thoughts, anyone? Or have I scared everyone away now? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-12 06:17 Message: Logged In: YES user_id=6656 Now a rewrite of the test that actually works! ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-12 06:08 Message: Logged In: YES user_id=6656 Here's a version of the patch that includes the new unit test (oops!) which I've rewritten slightly. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-06-11 12:02 Message: Logged In: YES user_id=29957 No - wait. Ignore that test_timeout error, it exists with a clean checkout. The inability to interrupt make testall, however is new with this patch. Linux Fedora Core 2. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-06-11 11:58 Message: Logged In: YES user_id=29957 With this patch: bonanza% ./python Lib/test/test_timeout.py testBlockingThenTimeout (__main__.CreationTestCase) ... ok testFloatReturnValue (__main__.CreationTestCase) ... ok testObjectCreation (__main__.CreationTestCase) ... ok testRangeCheck (__main__.CreationTestCase) ... ok testReturnType (__main__.CreationTestCase) ... ok testTimeoutThenBlocking (__main__.CreationTestCase) ... ok testTypeCheck (__main__.CreationTestCase) ... ok testAcceptTimeout (__main__.TimeoutTestCase) ... ok testConnectTimeout (__main__.TimeoutTestCase) ... FAIL testRecvTimeout (__main__.TimeoutTestCase) ... ok testRecvfromTimeout (__main__.TimeoutTestCase) ... ok testSend (__main__.TimeoutTestCase) ... ok testSendall (__main__.TimeoutTestCase) ... ok testSendto (__main__.TimeoutTestCase) ... ok ====================================================================== FAIL: testConnectTimeout (__main__.TimeoutTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "Lib/test/test_timeout.py", line 121, in testConnectTimeout "timeout (%g) is more than %g seconds more than expected (%g)" AssertionError: timeout (4.48679) is more than 2 seconds more than expected (0.001) ---------------------------------------------------------------------- Ran 14 tests in 17.445s FAILED (failures=1) Traceback (most recent call last): File "Lib/test/test_timeout.py", line 192, in ? test_main() File "Lib/test/test_timeout.py", line 189, in test_main test_support.run_unittest(CreationTestCase, TimeoutTestCase) File "/home/anthony/src/py/pyhead/dist/src/Lib/test/test_support.py", line 290, in run_unittest run_suite(suite, testclass) File "/home/anthony/src/py/pyhead/dist/src/Lib/test/test_support.py", line 275, in run_suite raise TestFailed(err) test.test_support.TestFailed: Traceback (most recent call last): File "Lib/test/test_timeout.py", line 121, in testConnectTimeout "timeout (%g) is more than %g seconds more than expected (%g)" AssertionError: timeout (4.48679) is more than 2 seconds more than expected (0.001) Also, with this patch applied, I can no longer kill a 'make testall' with a ^C ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-11 10:18 Message: Logged In: YES user_id=6656 The patch didn't apply, so I've updated it (attached). I see test_asynchat fail occasionally now, but don't know if that's because of this patch :-( Once I've sorted that out in my head, I think I'm going to check this in. ---------------------------------------------------------------------- Comment By: Andrew Langmead (langmead) Date: 2004-05-29 01:49 Message: Logged In: YES user_id=119306 Here is a reformatted version of the patch. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-05-28 10:25 Message: Logged In: YES user_id=31435 I agree that "busy" always should have been volatile -- once again, good eye! Python C style is basically K&R Classic, hard tab for indentation, open curly at the end of the line opening a block except for first line of function definition. Just make it look like the other C code, but be careful to pick one of the .c files Guido approves of . ---------------------------------------------------------------------- Comment By: Andrew Langmead (langmead) Date: 2004-05-28 08:37 Message: Logged In: YES user_id=119306 Thank you for pointing me to PEP 7. I'll take a look at where I am amiss and fix it up. For the change in ceval.c, I took a look at gcc's x86 assembly output of the file, and noticed that the optimizer was altering the order of the busy flag test. Since busy is set from other concurrent execution (other signal handlers), changing the variable to volatile told gcc not to optimize accesses to the variable. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-28 04:54 Message: Logged In: YES user_id=6656 I haven't been able to test on MacOS X further, unfortunately. The patch works on linux/x86 though (after fixing the TabError :-) but this is with an NTPL kernel, so I didn't have a problem anyway. The C doesn't all conform to the Python style -- see PEP 7. Can you fix that? Why the change to Python/ceval.c? After all that -- thanks a lot! I really want to get this checked in ASAP so we can find out which platforms it breaks at the earliest point in the 2.4 cycle. ---------------------------------------------------------------------- Comment By: Andrew Langmead (langmead) Date: 2004-05-27 02:04 Message: Logged In: YES user_id=119306 It seems that at least OS X, sending the kill to the process schedules that the receiving process will run the signal handler at some later time. (it seems to be the only one to frequently run the signal handlers in the opposite order than they were sent) This revised version of the test seems to work better on OS X. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-26 14:41 Message: Logged In: YES user_id=6656 test_threadsignals hangs for me on OS X. Haven't done anything more thorough than that yet... ---------------------------------------------------------------------- Comment By: Andrew Langmead (langmead) Date: 2004-05-26 13:48 Message: Logged In: YES user_id=119306 I apologize that the missing patch. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-26 13:22 Message: Logged In: YES user_id=6656 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. In addition, even if you *did* check this checkbox, a bug in SourceForge prevents attaching a file when *creating* an issue. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=960406&group_id=5470 From Haden59224 at counsellor.com Tue Jun 22 02:54:24 2004 From: Haden59224 at counsellor.com (Milonia Gustin) Date: Tue Jun 22 02:04:22 2004 Subject: [Patches] good stuff Message-ID: <200406220604.i5M642hc048825@mxzilla2.xs4all.nl> An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20040622/334f63ff/attachment.html From noreply at sourceforge.net Tue Jun 22 05:02:51 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jun 22 05:43:11 2004 Subject: [Patches] [ python-Patches-960406 ] unblock signals in threads Message-ID: Patches item #960406, was opened at 2004-05-25 22:00 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=960406&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: Andrew Langmead (langmead) Assigned to: Michael Hudson (mwh) Summary: unblock signals in threads Initial Comment: This is a patch which will correct the issues some people have with python's handling of signal handling in threads. It allows any thread to initially catch the signal mark it as triggered, allowing the main thread to later process it. (This is actually just restoring access to the functionality that was in Python 2.1) The special SIGINT handling for the python readline module has been changed so that it can now see an EINTR error code, rather than needing a longjmp out of the readline library itself. If the readline library python is being linked to doesn't have the callback features necessary, it will fall back to its old behavior. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2004-06-22 10:02 Message: Logged In: YES user_id=6656 > What else did you want from me? Not a lot more than that :-) The only other point you might have an opinion (aka. a bit of current behaviour that I don't understand ;-) is that in current Python, a signal delivered while sitting in a call to PyOS_Readline() is not handled (at the Python level) until the user presses return (or ^C? hmm, not sure about that) whereas with this patch, it is handled more-or-less immediately. This means that the second argument to the Python signal handler will be None, rather than a frame object: there's no Python execution happening at this point, after all. Does this sound reasonable to you? > For 2.3, keeping whatever semantics ^C from readline > has at the moment should be preserved Certainly, in principle at least! However "whatever semantics ^C from readline has at the moment" are a trifle accidental... I need to think about this. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2004-06-22 03:59 Message: Logged In: YES user_id=6380 Ideally, ^C should always cause the signal handler for SIGINT to be called, and the KeyboardInterrupt should be generated by the default SIGINT handler. For 2.3, keeping whatever semantics ^C from readline has at the moment should be preserved -- we only want bugfixes, not new features... What else did you want from me? (I'm also lacking focus, or at least time to think about this stuff in detail.) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-19 11:14 Message: Logged In: YES user_id=6656 Yes, I think you're right. I guess I'm suffering a lack of focus, finding it hard to resist the impulse to fix what look like ancient bogosities in the area while I'm there... (also see the way a NULL return from PyOS_Readline is assumed to be a keyboard interrupt). One could argue that ^C should always interrupt an interactive session, but one could also argue that users shouldn't be so daft as to install handlers for SIGINT if they want that to be true (after all, they can make life hard for themselves if they want with stty(1)). A downside to all this footling is that it makes a backport to 2.3 harder to justify. Hmm. I wander what Guido thinnks (he's alledgedly "now maintaining" Modules/readline.c :-). ---------------------------------------------------------------------- Comment By: Andrew Langmead (langmead) Date: 2004-06-19 04:04 Message: Logged In: YES user_id=119306 I'm not sure if the current behavior should be maintained or not, but it looks like to me that the readline module has always generated a KeyboardInterrupt, regardless of whether SIGINT has been overridden. This is a bit odd though. It causes the SIGINT handling to change depending on whether or not you are at the top level interpreter's prompt. wantarray% cat /tmp/foo.py import signal def foo(sig, frame): print "caught foo" signal.signal(signal.SIGINT, foo) wantarray% python -i /tmp/foo.py >>> foo >>> ^C KeyboardInterrupt >>> while 1: ... pass ... ^Ccaught foo ^Ccaught foo ^Ccaught foo ^Ccaught foo ^\zsh: quit python -i /tmp/foo.py ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-18 13:54 Message: Logged In: YES user_id=6656 The problem with that approach is: what if you want a handler for SIGINT that doesn't raise KeyboardInterrupt? Other than that, it sounds like your plan should work. I've attached a slightly cleaned up version of my patch which makes signal handling in the "without readline" case more like yesterday's patch made the "with readline" case. ---------------------------------------------------------------------- Comment By: Andrew Langmead (langmead) Date: 2004-06-18 03:35 Message: Logged In: YES user_id=119306 Here is another possible approach to solving the problem of readline exiting for signals other than SIGINT. I'm not sure if it is better or worse than the scarypatch. As you said, the call to readline is performed without the GIL. So is the actual C-level signal handler from the signal module (the python code that gets associated with the signal is deferred until later.) At the time we see the EINTR, there is a flag in the signal module's Handler array to say whether the signal that we received was a SIGINT. If we added some sort of interface within the signal module to find out what signals are pending to be run on the next call to PyErr_CheckSignals, then we could find out if the EINTR was caused by an INT (at which point we should exit) or by another signal (at which we could just retry the select.) Is there any potential to this approach? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-17 18:25 Message: Logged In: YES user_id=6656 BTW, I'd really really like someone to review this :-) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-17 18:24 Message: Logged In: YES user_id=6656 How about the attached? It's a bit ... scary. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-17 17:08 Message: Logged In: YES user_id=6656 A potential problem with this patch is that it causes input to be interrupted (with a KeyboardInterrupt exception) when any handled signal is delivered. This seems suboptimal. It's appealing to try to run the (Python) signal handlers in the errno == EINTR case of readline_line_until_enter_or_signal, but that has problems in that PyOS_ReadlineFunctionPointer is called without the GIL being held and once that is dealt with, an installed Python signal handler attempting to call readline at this point can reasonably be expected to result in all hell breaking loose. I don't know what the correct solution is here. Add our own rentrancy checks and learn how to work the Python threadstate API properly? Thoughts, anyone? Or have I scared everyone away now? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-12 11:17 Message: Logged In: YES user_id=6656 Now a rewrite of the test that actually works! ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-12 11:08 Message: Logged In: YES user_id=6656 Here's a version of the patch that includes the new unit test (oops!) which I've rewritten slightly. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-06-11 17:02 Message: Logged In: YES user_id=29957 No - wait. Ignore that test_timeout error, it exists with a clean checkout. The inability to interrupt make testall, however is new with this patch. Linux Fedora Core 2. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-06-11 16:58 Message: Logged In: YES user_id=29957 With this patch: bonanza% ./python Lib/test/test_timeout.py testBlockingThenTimeout (__main__.CreationTestCase) ... ok testFloatReturnValue (__main__.CreationTestCase) ... ok testObjectCreation (__main__.CreationTestCase) ... ok testRangeCheck (__main__.CreationTestCase) ... ok testReturnType (__main__.CreationTestCase) ... ok testTimeoutThenBlocking (__main__.CreationTestCase) ... ok testTypeCheck (__main__.CreationTestCase) ... ok testAcceptTimeout (__main__.TimeoutTestCase) ... ok testConnectTimeout (__main__.TimeoutTestCase) ... FAIL testRecvTimeout (__main__.TimeoutTestCase) ... ok testRecvfromTimeout (__main__.TimeoutTestCase) ... ok testSend (__main__.TimeoutTestCase) ... ok testSendall (__main__.TimeoutTestCase) ... ok testSendto (__main__.TimeoutTestCase) ... ok ====================================================================== FAIL: testConnectTimeout (__main__.TimeoutTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "Lib/test/test_timeout.py", line 121, in testConnectTimeout "timeout (%g) is more than %g seconds more than expected (%g)" AssertionError: timeout (4.48679) is more than 2 seconds more than expected (0.001) ---------------------------------------------------------------------- Ran 14 tests in 17.445s FAILED (failures=1) Traceback (most recent call last): File "Lib/test/test_timeout.py", line 192, in ? test_main() File "Lib/test/test_timeout.py", line 189, in test_main test_support.run_unittest(CreationTestCase, TimeoutTestCase) File "/home/anthony/src/py/pyhead/dist/src/Lib/test/test_support.py", line 290, in run_unittest run_suite(suite, testclass) File "/home/anthony/src/py/pyhead/dist/src/Lib/test/test_support.py", line 275, in run_suite raise TestFailed(err) test.test_support.TestFailed: Traceback (most recent call last): File "Lib/test/test_timeout.py", line 121, in testConnectTimeout "timeout (%g) is more than %g seconds more than expected (%g)" AssertionError: timeout (4.48679) is more than 2 seconds more than expected (0.001) Also, with this patch applied, I can no longer kill a 'make testall' with a ^C ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-11 15:18 Message: Logged In: YES user_id=6656 The patch didn't apply, so I've updated it (attached). I see test_asynchat fail occasionally now, but don't know if that's because of this patch :-( Once I've sorted that out in my head, I think I'm going to check this in. ---------------------------------------------------------------------- Comment By: Andrew Langmead (langmead) Date: 2004-05-29 06:49 Message: Logged In: YES user_id=119306 Here is a reformatted version of the patch. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-05-28 15:25 Message: Logged In: YES user_id=31435 I agree that "busy" always should have been volatile -- once again, good eye! Python C style is basically K&R Classic, hard tab for indentation, open curly at the end of the line opening a block except for first line of function definition. Just make it look like the other C code, but be careful to pick one of the .c files Guido approves of . ---------------------------------------------------------------------- Comment By: Andrew Langmead (langmead) Date: 2004-05-28 13:37 Message: Logged In: YES user_id=119306 Thank you for pointing me to PEP 7. I'll take a look at where I am amiss and fix it up. For the change in ceval.c, I took a look at gcc's x86 assembly output of the file, and noticed that the optimizer was altering the order of the busy flag test. Since busy is set from other concurrent execution (other signal handlers), changing the variable to volatile told gcc not to optimize accesses to the variable. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-28 09:54 Message: Logged In: YES user_id=6656 I haven't been able to test on MacOS X further, unfortunately. The patch works on linux/x86 though (after fixing the TabError :-) but this is with an NTPL kernel, so I didn't have a problem anyway. The C doesn't all conform to the Python style -- see PEP 7. Can you fix that? Why the change to Python/ceval.c? After all that -- thanks a lot! I really want to get this checked in ASAP so we can find out which platforms it breaks at the earliest point in the 2.4 cycle. ---------------------------------------------------------------------- Comment By: Andrew Langmead (langmead) Date: 2004-05-27 07:04 Message: Logged In: YES user_id=119306 It seems that at least OS X, sending the kill to the process schedules that the receiving process will run the signal handler at some later time. (it seems to be the only one to frequently run the signal handlers in the opposite order than they were sent) This revised version of the test seems to work better on OS X. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-26 19:41 Message: Logged In: YES user_id=6656 test_threadsignals hangs for me on OS X. Haven't done anything more thorough than that yet... ---------------------------------------------------------------------- Comment By: Andrew Langmead (langmead) Date: 2004-05-26 18:48 Message: Logged In: YES user_id=119306 I apologize that the missing patch. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-26 18:22 Message: Logged In: YES user_id=6656 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. In addition, even if you *did* check this checkbox, a bug in SourceForge prevents attaching a file when *creating* an issue. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=960406&group_id=5470 From noreply at sourceforge.net Tue Jun 22 11:22:12 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jun 22 11:22:25 2004 Subject: [Patches] [ python-Patches-977553 ] Speed up EnumKey call Message-ID: Patches item #977553, was opened at 2004-06-22 15:22 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=977553&group_id=5470 Category: Windows Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Garth Bushell (garth42) Assigned to: Nobody/Anonymous (nobody) Summary: Speed up EnumKey call Initial Comment: This patch removes the RegQueryInfoKey call and replaces it with a call to EnumKeyEx. This greatly speeds up this call. The script below times python 2.3 5531 89.7130000591 python 2.4 +patch 5531 0.0469999313354 start = time.time() i = 0 try: while 1: _winreg.EnumKey(_winreg.HKEY_CLASSES_ROOT, i) i += 1 except WindowsError: pass print i, time.time() - start ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=977553&group_id=5470 From noreply at sourceforge.net Tue Jun 22 13:06:15 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jun 22 13:06:24 2004 Subject: [Patches] [ python-Patches-876130 ] add C API to datetime module Message-ID: Patches item #876130, was opened at 2004-01-13 08:20 Message generated for change (Comment added) made by atuining You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=876130&group_id=5470 Category: Modules Group: Python 2.3 Status: Closed Resolution: Accepted Priority: 5 Submitted By: Anthony Tuininga (atuining) Assigned to: Tim Peters (tim_one) Summary: add C API to datetime module Initial Comment: The datetime module does not have a C API which means that modules written in C cannot take advantage of the datetime module without incurring significant overhead. These patches supply this lack and are based on the C API exported by the mxDateTime module and the cStringIO module and enhanced as suggested by Guido. ---------------------------------------------------------------------- >Comment By: Anthony Tuininga (atuining) Date: 2004-06-22 11:06 Message: Logged In: YES user_id=619560 Yes, this has been a long time coming. Collaboration by e-mail with people working on completely different projects can be quite a challenge! Thanks for getting this checked in. When 2.4a1 comes out I will be providing a new version of cx_Oracle that takes advantage of these functions. I just noticed that I missed the macros that are defined in datetime.h that were not modified with my patch -- specifically those used to acquire the components of the date/time objects. Should those be documented as well? I'm assuming the answer is yes -- so would it be helpful if I did so and attached a patch to this set of patches or do I need to create a new patch? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-06-20 16:51 Message: Logged In: YES user_id=31435 Thanks for your patience, Anthony! I checked this in after minor fiddling. Biggest change was to supply a new macro and docs, to expose the unreferenced Delta_FromDelta member of the C API struct. I do wish we had test cases -- as is, these maros could be totally busted and we'd have no way to know that. But virtually all of the C API is untested that way, so it's not a fatal objection. Doc/api/concrete.tex; new revision: 1.45 Include/datetime.h; new revision: 1.5 Misc/ACKS; new revision: 1.267 Misc/NEWS; new revision: 1.1008 Modules/datetimemodule.c; new revision: 1.74 The answers to your questions are implicit in what I checked in . Note that in 2.4, datetimemodule.c *is* compiled as part of the core. Guido nevertheless didn't want the datetime API to take advantage of that (I'm unclear on why). I'm content to document the macros and leave it at that. The DB API functions don't bother me one way or the other, so left them in. ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-06-14 09:23 Message: Logged In: YES user_id=619560 I have attached a patch for the documentation as requested. Not being certain of the format and requirements for the content, your comments are appreciated. I have a few questions that might help focus your comments. 1) Should the API structure be documented and users of datetime.h encouraged to use it directly? Or should it be "implementation details" and only those methods that I have provided should be available? To help answer this question, is it intended to ever bring datetime objects into the "core" rather than as a separate module? 2) The DB API helper functions are provided because Marc Andre Lemburg thought it would be a good idea. Please take a look and see if it makes sense now that it is documented. :-) Please review and give me your feedback. Thanks. ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-06-07 07:57 Message: Logged In: YES user_id=619560 Yes, the top two files are the ones involved. As per your suggestion I deleted the other four files to avoid further confusion. I understand the concern for documentation. I'll see what I can do to get at least a preliminary patch on that front ready this week. Earlier discussions suggested that the documentation reside solely in the include file but I think adding a section to the Python/C API documentation would make a lot more sense. Please stand by. :-) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-06-05 17:43 Message: Logged In: YES user_id=31435 Assuming the current state of the proposal consists of the first two patches on the list ("patch for datetimemodule.c" and "patch for datetime.h"), I'm probably happy to commit them. Can't say for sure right now, because SF CVS is dead, and can't get a current checkout to try them with. The one necessary thing I don't see are docs: how are users supposed to know this exists, let alone know how to use it? We need a new section for datetime objects in the Python/C API Reference Manual, in the Other Objects part of the Concrete Objects Layer section. You don't have to write LaTeX, plain text is fine. Look at the other sections in that chapter for what's needed (an overview, and a precise account of what's in the new C API and how to use it). Don't let that discourage you -- you're very close! If I don't force docs out of you now, docs will never get written. That's why I'm trying to force docs out of you now . ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-06-05 17:10 Message: Logged In: YES user_id=31435 Heh. Just noticed there are 6 patches attached to this report. Are all of them part of the suggested change, or, if not, which are the current ones (if that's the case, the best way to answer the question is to delete the out-of-date patches)? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-06-01 11:53 Message: Logged In: YES user_id=31435 I intend to do it this week, but have no time today or tomorrow. ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-06-01 11:44 Message: Logged In: YES user_id=619560 Sure. What's the chance of it being reviewed prior to the release of Python 2.4 a1? I just saw the preannouncement today -- it is scheduled for the end of this month, I believe. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-05-31 21:12 Message: Logged In: YES user_id=31435 Assigned to me for the next review. Can't do it immediately, but will do my best to free up some time for it "soon". ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-05-26 13:39 Message: Logged In: YES user_id=619560 I would agree with your assessment of the issue regarding the TimeFromTicks() API and find it quite reasonable. Either implement both at the C and Python levels or not at all. Since there is no consensus on this, none it is. :-) Did you have a chance to review the actual code? The changes are fairly minimal but you might have questions about readability, names, etc. It would be great if this could be included in an upcoming 2.4 alpha/beta so that I can provide support in cx_Oracle for the next release. Thanks for your time. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-05-26 13:32 Message: Logged In: YES user_id=31435 Under the belief that the *intent* of this patch is to add a C API to Python's datetime module, it should stick to exposing C ways to spell what Python programmers can already do from Python using datetime. Since nothing like TimeFromTicks() exists in the Python datetime API, it simply doesn't make sense to invent one available only from C. It *may* make sense to invent one in a DB API wrapper around datetime, but I view that as out of scope for this patch. I would not add TimeFromTicks() to the Python datetime API either, because the docs are ambiguous. The sample implementation Marc-Andre posted here uses localtime() to resolve the ambiguity in the docs, but that has to be a wrong choice for some time-of-day apps. For example, there's apparently no portable way to spell "noon" using TimeFromTicks(): the value you get back depends on which time zone localtime() happens to use at the time it's called. If people want time-of-day from a POSIX timestamp, it remains easy to get it from what datetime already supplies, but to do so you have to be explicit about whether you want UTC or local time interpretation. Both are easily spelled already, and it's a Good Thing that you need to be explicit if you want to do such a thing. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-05-26 13:25 Message: Logged In: YES user_id=38388 Tim, please review. Thanks. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-05-26 13:22 Message: Logged In: YES user_id=38388 Thanks, but I don't have time to review it. As for the TimeFromTicks() API: I can understand that you don't feel like implementing it, but hey, I won't use datetime either. The only reason I'm trying to push full support of the DB API specs is that Guido et al. wanted to see a note in the DB API that datetime also provides a usable interface to do date/time interfacing. I'm not very interested in datetime myself, since I'll continue to use mxDateTime, so the situation for me is somewhat similar to yours: investing time into something that I myself will probably not use much (I will add support to mxODBC for those who like to use datetime instead of mxDateTime, but won't use it myself). Feel free to check in your changes. Thanks. ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-05-26 10:30 Message: Logged In: YES user_id=619560 Attached are the modified patches based on your suggestions. I have tested them with my own module cx_Oracle and they appear to work correctly. Any further suggestions would be appreciated. I would like to see this included for Python 2.4 if at all possible. Please let me know what I need to do (if anything) to get this to happen. As for the TimeFromTicks() routine, Oracle has absolutely no use for a "time-only" data type and does not support it. It clearly does not have broad support so I really have no desire to implement it since I will never use it myself. If you consider it important, you could add it yourself or we could wait until someone else who requires it for their implementation of the DB API requires it. I'm not trying to be rude or trying to denigrate the DB API, simply trying to be practical. Please let me know if this is offensive in any way. Thanks. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-05-19 02:28 Message: Logged In: YES user_id=38388 >From the DB API specs: TimeFromTicks(ticks) This function constructs an object holding a time value from the given ticks value (number of seconds since the epoch; see the documentation of the standard Python time module for details). The reason for this having this API is to be able to construct an object suitable for passing to the database given a Unix ticks value. Since the ticks value contains both a date and a time part and most databases have a special column type for time value, we need two constructor APIs, one to extract just the date part and one for the time part. Here's the mxDateTime implementation for reference: def TimeFromTicks(ticks, # Locals: DateTimeDelta=DateTimeDelta,localtime=_time.localtime): """ TimeFromTicks(ticks) Constructs a DateTimeDelta instance pointing to the local time indicated by the given ticks value. The date part is ignored. """ return apply(DateTimeDelta, (0,) + localtime(ticks)[3:6]) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-05-03 11:46 Message: Logged In: YES user_id=31435 I don't understand what TimeFromTicks() is supposed to do. Seconds-from-the-epoch is a point in time, not a time-of- day. If some DB API requires guessing some transformation from seconds-from-the-epoch to time-of-day, that's fine, but it doesn't belong in Python's datetime module. The datetime module should certainly have a method to construct a datetime.datetime from a seconds-from-the- epoch argument -- seconds-from-the-epoch is a way of specifying a datetime.datetime. Given that, if the intent is to throw away the datetime.date portion of the datetime.datetime object, retaining only the datetime.time portion, then that's trivially accomplished by invoking dt.time () (where dt is the datetime.datetime object). Do any databases really store time-of-day as a seconds-from- the-epoch value? Google's top hit on TimeFromTicks() today happens to be a msg from Anthony saying that Oracle does not. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-05-03 11:24 Message: Logged In: YES user_id=38388 Macro: I don't know whether you need the macro or not (you probably do for the type checks). In any case, you can do without relying on Python providing you this information via the build process, since only datetimemodule.c is using the header file while Python is being built. TimeFromTicks(): I' ve stated my point. I don't think there's anything to add - I'm tired of fighting for these things... one of the reasons I stopped actively discussing things on python-dev. IMHO, a product that's aimed at developers should make things easy for the developer and try to avoid code duplication if possible. The API is needed in order to support database interfaces that use Unix ticks as basis for date/time, so if you don't add it to the module, the ten or twenty module authors out there will have to duplicate that piece of work in their implementation. Transition: This was already discussed on the db-api list. We love freedom of choice. Nothing to add. ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-05-03 10:48 Message: Logged In: YES user_id=619560 About the Py_BUILD_CORE issue: You are suggesting that I define this in datetimemodule.c just prior to the include of datetime.h? Or are you suggesting some other macro? I am not sure about the comment about "not needing a macro in the first place" since there are two groups that will be importing datetime.h: the first being the datetime module itself and the second being the DB API modules. The macro is definitely required to distinguish between the two -- unless I am missing something? On the TimeFromTicks() issue: You obviously consider it important that the three methods be available at the C level for DB API module authors to use directly. My objection is simply a reiteration of an objection raised by Tim Peters. I think you'll have to argue that one with him. :-) I'll provide my implementations for cx_Oracle as part of the patches and then you can fight it out and I'll stay out of it. :-) As for the transition period, I assumed that with the introduction of a standard datetime module, that it would become the suggested implementation for database interfaace modules. That said, I don't really have any authority to say anything on this front so I'll leave that to you and others to decide. :-) ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-05-03 09:26 Message: Logged In: YES user_id=38388 About the Py_BUILD_CORE issue: Sorry, I didn't know that Python does not define this macro for core modules. Nevertheless, looking at the datetime module code I don't really understand why you would need such a macro in the first place. Since the datetime module is the only code including the datetime.h header file it should be easy to add a macro definition just before importing datetime.h. On the TimeFromTicks() issue: The whole point of this discussion is to make the datetime module easily usable for authors of database modules. Since the DB API specifies that the module will need to export the three functions, two of which are available through the datetime module already, I don't really see your point in not wanting to add it. BTW, you are wrong in the assumption that the DB API spec will move away from a generic API for date/time objects. The DB API has always been defined in terms of interfaces and does not force a certain set of tools onto the developer. The datetime module will become one possible choice for DB API authors, others will want to stick to mxDateTime, use strings, ticks integers or more specific objects for interfacing. That won't change, so there is no "transition period". ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-05-03 08:40 Message: Logged In: YES user_id=619560 I spent some time getting the two include files merged together, only to discover that Py_BUILD_CORE is __NOT__ defined when building modules, only when building stuff linked directly into the core interpreter. Perhaps this ought to be defined when building the modules with setup.py? At any rate, I cannot proceed along the route suggested without this problem being resolved. On the DateFromTicks(), TimestampFromTicks(), TimeFromTicks() issue, I'm not sure that there is much benefit to including a C API for this since if the datetime module becomes the standard method for managing datetime objects, there is no point in having the DB API modules provide something that the datetime module already provides, right? During the transition period the few lines of code needed can be posted. If you disagree I can certainly provide the few lines as part of the patch but I suspect you will find resistance to having this included by Tim Peters, the maintainer (I believe) of the datetime module. Feel free to correct me... :-) ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-04-26 10:19 Message: Logged In: YES user_id=38388 Sorry for not getting back to you earlier: I didn't see you last message. 1-4) Python defines a macro during the Python build process that is not defined when compiling extensions: Py_BUILD_CORE You can use that macro to compile things differently for core things vs. extensions. 5) Fair enough; I don't see a point in creating a new numbering for each and every module. Please just use 1, 2, 3, 4, ... 6) Hope this makes sense :-) ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-04-26 09:35 Message: Logged In: YES user_id=619560 Any chance to look at this? Any hope of this being included in Python 2.4? I know a number of people (including Guido) who would appreciate that.... :-) ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-04-05 16:04 Message: Logged In: YES user_id=619560 I am back at work after finishing my move so I think I can finally devote a little more time to this issue. 1-4) The main reason for datetimeapi.h as opposed to simply modifying datetime.h was that the internal build needs to define things __differently__ from an external build of a module and there doesn't appear to be any way of fixing that -- so if you know a way I think I can manage to create a reasonable patch; otherwise, I'm out of my depth! 5) Guido was suggesting that a new PyIMPORT macro be made available which would verify that the magic number defined in the header file actually matches the magic number exported by the built module; this is simply a developer protection scheme which should eliminate really stupid uses; you can ask him about this or I can e-mail you part of the thread that brought this up 6) Makes sense. I'd like to get the questions above resolved first before proceeding any further, though. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-03-25 11:23 Message: Logged In: YES user_id=38388 Thanks for the comments... 1) Please put *all* the code for the C API into datetimeapi.h. I don't like your current mix of putting some things into datetime.h and others into datetimeapi.h (e.g. the PyDateTime_CAPI definition). 2) Since it's the only API missing if you want to use datetime objects in database interfacing, please add it. 3) dito. 4) Yes, the header file is the right place. Have a look at unicodeobject.h for what I have in mind (or mxDateTime.h for that matter). 5) Why add yet another magic number ? Isn't the Python API number enough ? 6) Since you don't provide a doc patch, please put comments into the header file. There can never be enough documentation and developers tend to look at the code rather than the docs ;-) ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-03-25 11:08 Message: Logged In: YES user_id=619560 Sorry for the delay. Things here have been quite busy recently both at work and at home. Let me see if I can answer your questions. 1) are you suggesting comments that include the macro names in datetimeapi.h similar to what I put in the comments below? Or something else? See modified datetimeapi.h for more info. 2) TimeFromTicks() is a very DB API specific routine. In chatting with others about the datetime module, they were not keen on adding such a beast. I guess there will have to be some discussion about whether datetimeapi.h is also a sort of half implementation for a C module implementing the DB API. I was intending to do this in my cx_Oracle module but not in datetimeapi.h. Could you clarify? 3) I could add C APIS for the three DB API ticks interfaces but I was simply intending to do that in cx_Oracle. Again, see #2. I can do it either way. :-) 4) I have added limited documentation in datetimeapi.h but is that really the right place for it? Is it even remotely close to what is needed? I'm not sure what is needed here exactly. 5) the API magic number is simply an arbitrary number which is stored in datetime.h and need not be understood by the implementor. For your information I simply took the name "datetime", converted each letter to its ordinal value in the alphabet, modded by 16 and used that hex character -- does that make any sense? This can be changed to whatever makes sense, though. 6) Whether or not datetimeapi.h should be sufficient for a developer or whether he should look at documentation in the usual locations (html pages, for example) I'll leave up to the Python development team. Let me know how I can assist. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-03-25 10:35 Message: Logged In: YES user_id=38388 Anthony, have you had a chance to look at the comments ? ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-02-26 08:06 Message: Logged In: YES user_id=619560 Oops! It looks like my own misunderstanding of SourceForge and how it works is to blame. :-( I'll take a look at this and get back to you as soon as possible -- ignore my previous comment. ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-02-26 08:03 Message: Logged In: YES user_id=619560 You haven't yet responded to my previous comments -- it looks like SourceForge put them __after__ your comments so it is quite understandable why you didn't notice them. If you can give me the answers to those questions or provide additional questions that I need to answer, then I think we can make progress again. I was waiting for __you__ :-) ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-02-25 16:08 Message: Logged In: YES user_id=38388 Any progress on this ? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-01-28 04:49 Message: Logged In: YES user_id=38388 Thanks for the clarification. I had forgotten about the macros -- I'd suggest that you document them in the datetimeapi.h include file to not cause the same confusion on the developer side (the trick to achieve adoption is to make things easy on the developer). As for TimeFromTicks(): This should be rather straight forward to implement: you take the time part of the ticks timestamp and create a time object from it. This is the way the DB API constructor works. Could you add C APIs for the three DB API ticks interface methods ? Other things that are missing: * documentation of the way the CAPI object can be used in datetimeapi.h * documentation of the various CAPI entries * documentation of the API magic number (there should be some scheme for this) I think that datetimeapi.h should be enough for a developer to read in order to use the interface. ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-01-26 14:02 Message: Logged In: YES user_id=619560 I didn't think any additional API would be necessary for extracting date time information since the following macros are available: PyDateTime_GET_YEAR(o) PyDateTime_GET_MONTH(o) PyDateTime_GET_DAY(o) PyDateTime_DATE_GET_HOUR(o) PyDateTime_DATE_GET_MINUTE(o) PyDateTime_DATE_GET_SECOND(o) PyDateTime_DATE_GET_MICROSECOND(o) PyDateTime_TIME_GET_HOUR(o) PyDateTime_TIME_GET_MINUTE(o) PyDateTime_TIME_GET_SECOND(o) PyDateTime_TIME_GET_MICROSECOND(o) Were you thinking of something else that is needed? As for interfacing at the C level for converting from Unix ticks, the following method is already available and could simply be used as a drop in replacement for DateFromTicks() and TimestampFromTicks() from the DB API document. DateFromTicks() --> datetime.date.fromtimestamp() TimestampFromTicks() --> datetime.datetime.fromtimestamp() TimeFromTicks() is not already exposed but discussions with Tim Peters already suggested that would not happen since the concept is rather strange. You'll have to discuss that with him if you disagree! :-) Any comments? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-01-26 13:46 Message: Logged In: YES user_id=38388 This is a good start. However, you should add more APIs for extracting date/time information to the C API. mxDateTime.h from egenix-mx-base can provide a good basis for this. If you want to make the datetime module usable for database interfacing at C level, you'll also have to add interfaces for Unix ticks conversion, since these are often used by database C level interfaces. ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-01-26 11:36 Message: Logged In: YES user_id=619560 I have no objection to providing patches for doc and test. A quick look at _testcapimodule.c doesn't provide any obvious ideas as to how to patch it. I looked for cStringIO which has a C API already and found nothing in there at all. The documentation also simply says "see the source for the information you require". Any suggestions as to how to proceed? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-01-25 20:17 Message: Logged In: YES user_id=31435 Marc-Andre, can you review this? I think you have more experience building C APIs for modules than anyone else (while I don't have any). There's certainly no objection to giving datetime a C API, and Guido already said he doesn't want to rely on that Martin changed datetime to be built as part of the core (in 2.3 on Windows, datetime.pyd was a distinct DLL; in CVS, datetime is compiled into the core DLL now). Anthony, you probably need to add doc and test patches. _testcapimodule.c holds tests of things you can only get at from C. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=876130&group_id=5470 From noreply at sourceforge.net Tue Jun 22 14:02:03 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jun 22 14:05:32 2004 Subject: [Patches] [ python-Patches-977671 ] dev_intro - make patch review request more obvious Message-ID: Patches item #977671, was opened at 2004-06-22 14:02 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=977671&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jim Jewett (jimjjewett) Assigned to: Nobody/Anonymous (nobody) Summary: dev_intro - make patch review request more obvious Initial Comment: There is periodic concern on dev_python that no one reviews patches. I had read dev_intro several times without noticing that review from someone without checkin privileges would even be useful. Also made a few things (python-dev for development *of* python, not *in* python) more explicit. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=977671&group_id=5470 From noreply at sourceforge.net Tue Jun 22 14:10:50 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jun 22 14:11:25 2004 Subject: [Patches] [ python-Patches-977671 ] dev_intro - make patch review request more obvious Message-ID: Patches item #977671, was opened at 2004-06-22 20:02 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=977671&group_id=5470 Category: Documentation Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Jim Jewett (jimjjewett) Assigned to: Nobody/Anonymous (nobody) Summary: dev_intro - make patch review request more obvious Initial Comment: There is periodic concern on dev_python that no one reviews patches. I had read dev_intro several times without noticing that review from someone without checkin privileges would even be useful. Also made a few things (python-dev for development *of* python, not *in* python) more explicit. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-06-22 20:10 Message: Logged In: YES user_id=21627 Thanks for the patch. Applied as dev_intro.ht 1.9. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=977671&group_id=5470 From fleslieyi at fibra.it Tue Jun 22 16:02:40 2004 From: fleslieyi at fibra.it (Frederic Leslie) Date: Tue Jun 22 15:59:35 2004 Subject: [Patches] $52621 Message-ID: <2cd101c45893$a7953ebe$4e4486fc@mail.prokoda.de> Hello, I sent you an email a few days ago, because you now qualify for a new mortgage. You could get $300,000 for as little as $700 a month! Bad credit is no problem, you can pull cash out or refinance. Please click on this link: http://www.refifast.biz/aff/affiliate.php?uid=71 Best Regards, Steve Morris ---- system information ---- object class description more-specific section wants a example: lies mailing implies revised controls numbering results objects zh-Hant Because existing tailoring default transport identical) on From noreply at sourceforge.net Wed Jun 23 00:41:28 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jun 23 00:43:33 2004 Subject: [Patches] [ python-Patches-960406 ] unblock signals in threads Message-ID: Patches item #960406, was opened at 2004-05-25 17:00 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=960406&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: Andrew Langmead (langmead) Assigned to: Michael Hudson (mwh) Summary: unblock signals in threads Initial Comment: This is a patch which will correct the issues some people have with python's handling of signal handling in threads. It allows any thread to initially catch the signal mark it as triggered, allowing the main thread to later process it. (This is actually just restoring access to the functionality that was in Python 2.1) The special SIGINT handling for the python readline module has been changed so that it can now see an EINTR error code, rather than needing a longjmp out of the readline library itself. If the readline library python is being linked to doesn't have the callback features necessary, it will fall back to its old behavior. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2004-06-23 00:41 Message: Logged In: YES user_id=6380 If there's no frame when PyOS_Readline() handles the signal immediately, why would there be a frame when the user hits return? IOW I don't think it would be a big deal to change that behavior. Semantics that are a trifle (or even completely) accidental are nevertheless worth preserving in a bugfix release, otherwise compatibility could be at risk. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-22 05:02 Message: Logged In: YES user_id=6656 > What else did you want from me? Not a lot more than that :-) The only other point you might have an opinion (aka. a bit of current behaviour that I don't understand ;-) is that in current Python, a signal delivered while sitting in a call to PyOS_Readline() is not handled (at the Python level) until the user presses return (or ^C? hmm, not sure about that) whereas with this patch, it is handled more-or-less immediately. This means that the second argument to the Python signal handler will be None, rather than a frame object: there's no Python execution happening at this point, after all. Does this sound reasonable to you? > For 2.3, keeping whatever semantics ^C from readline > has at the moment should be preserved Certainly, in principle at least! However "whatever semantics ^C from readline has at the moment" are a trifle accidental... I need to think about this. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2004-06-21 22:59 Message: Logged In: YES user_id=6380 Ideally, ^C should always cause the signal handler for SIGINT to be called, and the KeyboardInterrupt should be generated by the default SIGINT handler. For 2.3, keeping whatever semantics ^C from readline has at the moment should be preserved -- we only want bugfixes, not new features... What else did you want from me? (I'm also lacking focus, or at least time to think about this stuff in detail.) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-19 06:14 Message: Logged In: YES user_id=6656 Yes, I think you're right. I guess I'm suffering a lack of focus, finding it hard to resist the impulse to fix what look like ancient bogosities in the area while I'm there... (also see the way a NULL return from PyOS_Readline is assumed to be a keyboard interrupt). One could argue that ^C should always interrupt an interactive session, but one could also argue that users shouldn't be so daft as to install handlers for SIGINT if they want that to be true (after all, they can make life hard for themselves if they want with stty(1)). A downside to all this footling is that it makes a backport to 2.3 harder to justify. Hmm. I wander what Guido thinnks (he's alledgedly "now maintaining" Modules/readline.c :-). ---------------------------------------------------------------------- Comment By: Andrew Langmead (langmead) Date: 2004-06-18 23:04 Message: Logged In: YES user_id=119306 I'm not sure if the current behavior should be maintained or not, but it looks like to me that the readline module has always generated a KeyboardInterrupt, regardless of whether SIGINT has been overridden. This is a bit odd though. It causes the SIGINT handling to change depending on whether or not you are at the top level interpreter's prompt. wantarray% cat /tmp/foo.py import signal def foo(sig, frame): print "caught foo" signal.signal(signal.SIGINT, foo) wantarray% python -i /tmp/foo.py >>> foo >>> ^C KeyboardInterrupt >>> while 1: ... pass ... ^Ccaught foo ^Ccaught foo ^Ccaught foo ^Ccaught foo ^\zsh: quit python -i /tmp/foo.py ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-18 08:54 Message: Logged In: YES user_id=6656 The problem with that approach is: what if you want a handler for SIGINT that doesn't raise KeyboardInterrupt? Other than that, it sounds like your plan should work. I've attached a slightly cleaned up version of my patch which makes signal handling in the "without readline" case more like yesterday's patch made the "with readline" case. ---------------------------------------------------------------------- Comment By: Andrew Langmead (langmead) Date: 2004-06-17 22:35 Message: Logged In: YES user_id=119306 Here is another possible approach to solving the problem of readline exiting for signals other than SIGINT. I'm not sure if it is better or worse than the scarypatch. As you said, the call to readline is performed without the GIL. So is the actual C-level signal handler from the signal module (the python code that gets associated with the signal is deferred until later.) At the time we see the EINTR, there is a flag in the signal module's Handler array to say whether the signal that we received was a SIGINT. If we added some sort of interface within the signal module to find out what signals are pending to be run on the next call to PyErr_CheckSignals, then we could find out if the EINTR was caused by an INT (at which point we should exit) or by another signal (at which we could just retry the select.) Is there any potential to this approach? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-17 13:25 Message: Logged In: YES user_id=6656 BTW, I'd really really like someone to review this :-) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-17 13:24 Message: Logged In: YES user_id=6656 How about the attached? It's a bit ... scary. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-17 12:08 Message: Logged In: YES user_id=6656 A potential problem with this patch is that it causes input to be interrupted (with a KeyboardInterrupt exception) when any handled signal is delivered. This seems suboptimal. It's appealing to try to run the (Python) signal handlers in the errno == EINTR case of readline_line_until_enter_or_signal, but that has problems in that PyOS_ReadlineFunctionPointer is called without the GIL being held and once that is dealt with, an installed Python signal handler attempting to call readline at this point can reasonably be expected to result in all hell breaking loose. I don't know what the correct solution is here. Add our own rentrancy checks and learn how to work the Python threadstate API properly? Thoughts, anyone? Or have I scared everyone away now? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-12 06:17 Message: Logged In: YES user_id=6656 Now a rewrite of the test that actually works! ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-12 06:08 Message: Logged In: YES user_id=6656 Here's a version of the patch that includes the new unit test (oops!) which I've rewritten slightly. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-06-11 12:02 Message: Logged In: YES user_id=29957 No - wait. Ignore that test_timeout error, it exists with a clean checkout. The inability to interrupt make testall, however is new with this patch. Linux Fedora Core 2. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-06-11 11:58 Message: Logged In: YES user_id=29957 With this patch: bonanza% ./python Lib/test/test_timeout.py testBlockingThenTimeout (__main__.CreationTestCase) ... ok testFloatReturnValue (__main__.CreationTestCase) ... ok testObjectCreation (__main__.CreationTestCase) ... ok testRangeCheck (__main__.CreationTestCase) ... ok testReturnType (__main__.CreationTestCase) ... ok testTimeoutThenBlocking (__main__.CreationTestCase) ... ok testTypeCheck (__main__.CreationTestCase) ... ok testAcceptTimeout (__main__.TimeoutTestCase) ... ok testConnectTimeout (__main__.TimeoutTestCase) ... FAIL testRecvTimeout (__main__.TimeoutTestCase) ... ok testRecvfromTimeout (__main__.TimeoutTestCase) ... ok testSend (__main__.TimeoutTestCase) ... ok testSendall (__main__.TimeoutTestCase) ... ok testSendto (__main__.TimeoutTestCase) ... ok ====================================================================== FAIL: testConnectTimeout (__main__.TimeoutTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "Lib/test/test_timeout.py", line 121, in testConnectTimeout "timeout (%g) is more than %g seconds more than expected (%g)" AssertionError: timeout (4.48679) is more than 2 seconds more than expected (0.001) ---------------------------------------------------------------------- Ran 14 tests in 17.445s FAILED (failures=1) Traceback (most recent call last): File "Lib/test/test_timeout.py", line 192, in ? test_main() File "Lib/test/test_timeout.py", line 189, in test_main test_support.run_unittest(CreationTestCase, TimeoutTestCase) File "/home/anthony/src/py/pyhead/dist/src/Lib/test/test_support.py", line 290, in run_unittest run_suite(suite, testclass) File "/home/anthony/src/py/pyhead/dist/src/Lib/test/test_support.py", line 275, in run_suite raise TestFailed(err) test.test_support.TestFailed: Traceback (most recent call last): File "Lib/test/test_timeout.py", line 121, in testConnectTimeout "timeout (%g) is more than %g seconds more than expected (%g)" AssertionError: timeout (4.48679) is more than 2 seconds more than expected (0.001) Also, with this patch applied, I can no longer kill a 'make testall' with a ^C ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-11 10:18 Message: Logged In: YES user_id=6656 The patch didn't apply, so I've updated it (attached). I see test_asynchat fail occasionally now, but don't know if that's because of this patch :-( Once I've sorted that out in my head, I think I'm going to check this in. ---------------------------------------------------------------------- Comment By: Andrew Langmead (langmead) Date: 2004-05-29 01:49 Message: Logged In: YES user_id=119306 Here is a reformatted version of the patch. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-05-28 10:25 Message: Logged In: YES user_id=31435 I agree that "busy" always should have been volatile -- once again, good eye! Python C style is basically K&R Classic, hard tab for indentation, open curly at the end of the line opening a block except for first line of function definition. Just make it look like the other C code, but be careful to pick one of the .c files Guido approves of . ---------------------------------------------------------------------- Comment By: Andrew Langmead (langmead) Date: 2004-05-28 08:37 Message: Logged In: YES user_id=119306 Thank you for pointing me to PEP 7. I'll take a look at where I am amiss and fix it up. For the change in ceval.c, I took a look at gcc's x86 assembly output of the file, and noticed that the optimizer was altering the order of the busy flag test. Since busy is set from other concurrent execution (other signal handlers), changing the variable to volatile told gcc not to optimize accesses to the variable. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-28 04:54 Message: Logged In: YES user_id=6656 I haven't been able to test on MacOS X further, unfortunately. The patch works on linux/x86 though (after fixing the TabError :-) but this is with an NTPL kernel, so I didn't have a problem anyway. The C doesn't all conform to the Python style -- see PEP 7. Can you fix that? Why the change to Python/ceval.c? After all that -- thanks a lot! I really want to get this checked in ASAP so we can find out which platforms it breaks at the earliest point in the 2.4 cycle. ---------------------------------------------------------------------- Comment By: Andrew Langmead (langmead) Date: 2004-05-27 02:04 Message: Logged In: YES user_id=119306 It seems that at least OS X, sending the kill to the process schedules that the receiving process will run the signal handler at some later time. (it seems to be the only one to frequently run the signal handlers in the opposite order than they were sent) This revised version of the test seems to work better on OS X. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-26 14:41 Message: Logged In: YES user_id=6656 test_threadsignals hangs for me on OS X. Haven't done anything more thorough than that yet... ---------------------------------------------------------------------- Comment By: Andrew Langmead (langmead) Date: 2004-05-26 13:48 Message: Logged In: YES user_id=119306 I apologize that the missing patch. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-26 13:22 Message: Logged In: YES user_id=6656 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. In addition, even if you *did* check this checkbox, a bug in SourceForge prevents attaching a file when *creating* an issue. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=960406&group_id=5470 From noreply at sourceforge.net Wed Jun 23 01:00:50 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jun 23 01:01:57 2004 Subject: [Patches] [ python-Patches-960406 ] unblock signals in threads Message-ID: Patches item #960406, was opened at 2004-05-26 07:00 Message generated for change (Comment added) made by anthonybaxter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=960406&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: Andrew Langmead (langmead) Assigned to: Michael Hudson (mwh) Summary: unblock signals in threads Initial Comment: This is a patch which will correct the issues some people have with python's handling of signal handling in threads. It allows any thread to initially catch the signal mark it as triggered, allowing the main thread to later process it. (This is actually just restoring access to the functionality that was in Python 2.1) The special SIGINT handling for the python readline module has been changed so that it can now see an EINTR error code, rather than needing a longjmp out of the readline library itself. If the readline library python is being linked to doesn't have the callback features necessary, it will fall back to its old behavior. ---------------------------------------------------------------------- >Comment By: Anthony Baxter (anthonybaxter) Date: 2004-06-23 15:00 Message: Logged In: YES user_id=29957 At this point, worry about getting it working at all for 2.4, _then_ we can worry about trying to backport it to 2.3. If it turns out that we can't fix it for 2.3.5, so be it... I'd much rather see this fixed correctly in 2.4 and not at all in 2.3.5 than seeing a broken hacky fix in both 2.3.5 and 2.4. This code is already unpleasant enough. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2004-06-23 14:41 Message: Logged In: YES user_id=6380 If there's no frame when PyOS_Readline() handles the signal immediately, why would there be a frame when the user hits return? IOW I don't think it would be a big deal to change that behavior. Semantics that are a trifle (or even completely) accidental are nevertheless worth preserving in a bugfix release, otherwise compatibility could be at risk. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-22 19:02 Message: Logged In: YES user_id=6656 > What else did you want from me? Not a lot more than that :-) The only other point you might have an opinion (aka. a bit of current behaviour that I don't understand ;-) is that in current Python, a signal delivered while sitting in a call to PyOS_Readline() is not handled (at the Python level) until the user presses return (or ^C? hmm, not sure about that) whereas with this patch, it is handled more-or-less immediately. This means that the second argument to the Python signal handler will be None, rather than a frame object: there's no Python execution happening at this point, after all. Does this sound reasonable to you? > For 2.3, keeping whatever semantics ^C from readline > has at the moment should be preserved Certainly, in principle at least! However "whatever semantics ^C from readline has at the moment" are a trifle accidental... I need to think about this. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2004-06-22 12:59 Message: Logged In: YES user_id=6380 Ideally, ^C should always cause the signal handler for SIGINT to be called, and the KeyboardInterrupt should be generated by the default SIGINT handler. For 2.3, keeping whatever semantics ^C from readline has at the moment should be preserved -- we only want bugfixes, not new features... What else did you want from me? (I'm also lacking focus, or at least time to think about this stuff in detail.) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-19 20:14 Message: Logged In: YES user_id=6656 Yes, I think you're right. I guess I'm suffering a lack of focus, finding it hard to resist the impulse to fix what look like ancient bogosities in the area while I'm there... (also see the way a NULL return from PyOS_Readline is assumed to be a keyboard interrupt). One could argue that ^C should always interrupt an interactive session, but one could also argue that users shouldn't be so daft as to install handlers for SIGINT if they want that to be true (after all, they can make life hard for themselves if they want with stty(1)). A downside to all this footling is that it makes a backport to 2.3 harder to justify. Hmm. I wander what Guido thinnks (he's alledgedly "now maintaining" Modules/readline.c :-). ---------------------------------------------------------------------- Comment By: Andrew Langmead (langmead) Date: 2004-06-19 13:04 Message: Logged In: YES user_id=119306 I'm not sure if the current behavior should be maintained or not, but it looks like to me that the readline module has always generated a KeyboardInterrupt, regardless of whether SIGINT has been overridden. This is a bit odd though. It causes the SIGINT handling to change depending on whether or not you are at the top level interpreter's prompt. wantarray% cat /tmp/foo.py import signal def foo(sig, frame): print "caught foo" signal.signal(signal.SIGINT, foo) wantarray% python -i /tmp/foo.py >>> foo >>> ^C KeyboardInterrupt >>> while 1: ... pass ... ^Ccaught foo ^Ccaught foo ^Ccaught foo ^Ccaught foo ^\zsh: quit python -i /tmp/foo.py ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-18 22:54 Message: Logged In: YES user_id=6656 The problem with that approach is: what if you want a handler for SIGINT that doesn't raise KeyboardInterrupt? Other than that, it sounds like your plan should work. I've attached a slightly cleaned up version of my patch which makes signal handling in the "without readline" case more like yesterday's patch made the "with readline" case. ---------------------------------------------------------------------- Comment By: Andrew Langmead (langmead) Date: 2004-06-18 12:35 Message: Logged In: YES user_id=119306 Here is another possible approach to solving the problem of readline exiting for signals other than SIGINT. I'm not sure if it is better or worse than the scarypatch. As you said, the call to readline is performed without the GIL. So is the actual C-level signal handler from the signal module (the python code that gets associated with the signal is deferred until later.) At the time we see the EINTR, there is a flag in the signal module's Handler array to say whether the signal that we received was a SIGINT. If we added some sort of interface within the signal module to find out what signals are pending to be run on the next call to PyErr_CheckSignals, then we could find out if the EINTR was caused by an INT (at which point we should exit) or by another signal (at which we could just retry the select.) Is there any potential to this approach? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-18 03:25 Message: Logged In: YES user_id=6656 BTW, I'd really really like someone to review this :-) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-18 03:24 Message: Logged In: YES user_id=6656 How about the attached? It's a bit ... scary. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-18 02:08 Message: Logged In: YES user_id=6656 A potential problem with this patch is that it causes input to be interrupted (with a KeyboardInterrupt exception) when any handled signal is delivered. This seems suboptimal. It's appealing to try to run the (Python) signal handlers in the errno == EINTR case of readline_line_until_enter_or_signal, but that has problems in that PyOS_ReadlineFunctionPointer is called without the GIL being held and once that is dealt with, an installed Python signal handler attempting to call readline at this point can reasonably be expected to result in all hell breaking loose. I don't know what the correct solution is here. Add our own rentrancy checks and learn how to work the Python threadstate API properly? Thoughts, anyone? Or have I scared everyone away now? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-12 20:17 Message: Logged In: YES user_id=6656 Now a rewrite of the test that actually works! ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-12 20:08 Message: Logged In: YES user_id=6656 Here's a version of the patch that includes the new unit test (oops!) which I've rewritten slightly. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-06-12 02:02 Message: Logged In: YES user_id=29957 No - wait. Ignore that test_timeout error, it exists with a clean checkout. The inability to interrupt make testall, however is new with this patch. Linux Fedora Core 2. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-06-12 01:58 Message: Logged In: YES user_id=29957 With this patch: bonanza% ./python Lib/test/test_timeout.py testBlockingThenTimeout (__main__.CreationTestCase) ... ok testFloatReturnValue (__main__.CreationTestCase) ... ok testObjectCreation (__main__.CreationTestCase) ... ok testRangeCheck (__main__.CreationTestCase) ... ok testReturnType (__main__.CreationTestCase) ... ok testTimeoutThenBlocking (__main__.CreationTestCase) ... ok testTypeCheck (__main__.CreationTestCase) ... ok testAcceptTimeout (__main__.TimeoutTestCase) ... ok testConnectTimeout (__main__.TimeoutTestCase) ... FAIL testRecvTimeout (__main__.TimeoutTestCase) ... ok testRecvfromTimeout (__main__.TimeoutTestCase) ... ok testSend (__main__.TimeoutTestCase) ... ok testSendall (__main__.TimeoutTestCase) ... ok testSendto (__main__.TimeoutTestCase) ... ok ====================================================================== FAIL: testConnectTimeout (__main__.TimeoutTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "Lib/test/test_timeout.py", line 121, in testConnectTimeout "timeout (%g) is more than %g seconds more than expected (%g)" AssertionError: timeout (4.48679) is more than 2 seconds more than expected (0.001) ---------------------------------------------------------------------- Ran 14 tests in 17.445s FAILED (failures=1) Traceback (most recent call last): File "Lib/test/test_timeout.py", line 192, in ? test_main() File "Lib/test/test_timeout.py", line 189, in test_main test_support.run_unittest(CreationTestCase, TimeoutTestCase) File "/home/anthony/src/py/pyhead/dist/src/Lib/test/test_support.py", line 290, in run_unittest run_suite(suite, testclass) File "/home/anthony/src/py/pyhead/dist/src/Lib/test/test_support.py", line 275, in run_suite raise TestFailed(err) test.test_support.TestFailed: Traceback (most recent call last): File "Lib/test/test_timeout.py", line 121, in testConnectTimeout "timeout (%g) is more than %g seconds more than expected (%g)" AssertionError: timeout (4.48679) is more than 2 seconds more than expected (0.001) Also, with this patch applied, I can no longer kill a 'make testall' with a ^C ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-12 00:18 Message: Logged In: YES user_id=6656 The patch didn't apply, so I've updated it (attached). I see test_asynchat fail occasionally now, but don't know if that's because of this patch :-( Once I've sorted that out in my head, I think I'm going to check this in. ---------------------------------------------------------------------- Comment By: Andrew Langmead (langmead) Date: 2004-05-29 15:49 Message: Logged In: YES user_id=119306 Here is a reformatted version of the patch. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-05-29 00:25 Message: Logged In: YES user_id=31435 I agree that "busy" always should have been volatile -- once again, good eye! Python C style is basically K&R Classic, hard tab for indentation, open curly at the end of the line opening a block except for first line of function definition. Just make it look like the other C code, but be careful to pick one of the .c files Guido approves of . ---------------------------------------------------------------------- Comment By: Andrew Langmead (langmead) Date: 2004-05-28 22:37 Message: Logged In: YES user_id=119306 Thank you for pointing me to PEP 7. I'll take a look at where I am amiss and fix it up. For the change in ceval.c, I took a look at gcc's x86 assembly output of the file, and noticed that the optimizer was altering the order of the busy flag test. Since busy is set from other concurrent execution (other signal handlers), changing the variable to volatile told gcc not to optimize accesses to the variable. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-28 18:54 Message: Logged In: YES user_id=6656 I haven't been able to test on MacOS X further, unfortunately. The patch works on linux/x86 though (after fixing the TabError :-) but this is with an NTPL kernel, so I didn't have a problem anyway. The C doesn't all conform to the Python style -- see PEP 7. Can you fix that? Why the change to Python/ceval.c? After all that -- thanks a lot! I really want to get this checked in ASAP so we can find out which platforms it breaks at the earliest point in the 2.4 cycle. ---------------------------------------------------------------------- Comment By: Andrew Langmead (langmead) Date: 2004-05-27 16:04 Message: Logged In: YES user_id=119306 It seems that at least OS X, sending the kill to the process schedules that the receiving process will run the signal handler at some later time. (it seems to be the only one to frequently run the signal handlers in the opposite order than they were sent) This revised version of the test seems to work better on OS X. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-27 04:41 Message: Logged In: YES user_id=6656 test_threadsignals hangs for me on OS X. Haven't done anything more thorough than that yet... ---------------------------------------------------------------------- Comment By: Andrew Langmead (langmead) Date: 2004-05-27 03:48 Message: Logged In: YES user_id=119306 I apologize that the missing patch. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-27 03:22 Message: Logged In: YES user_id=6656 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. In addition, even if you *did* check this checkbox, a bug in SourceForge prevents attaching a file when *creating* an issue. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=960406&group_id=5470 From pusey at ilovechesterfield.com Wed Jun 23 04:01:35 2004 From: pusey at ilovechesterfield.com (Verbose B. Neapolitan) Date: Wed Jun 23 04:11:31 2004 Subject: [Patches] classicistic Message-ID: <011001c458f8$cae86977$e0a8dfc7@ilovechesterfield.com> It is no longer enough to be lusty. One must be a sexual gourmet. The man that makes a character, makes foes. Goals that are not written down are just wishes. It could be said that the AIDS pandemic is a classic own-goal scored by the human race against itself. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20040623/55da5734/attachment.html From incloses at badtzmail.com Wed Jun 23 08:47:19 2004 From: incloses at badtzmail.com (Unearthly O. Besot) Date: Wed Jun 23 08:11:16 2004 Subject: [Patches] Say NO to... Message-ID: <001101c45920$979b62f1$9b25093a@badtzmail.com> It's easy to point when you can't heal it. The history of mankind is his character. Nothing is more humiliating than to see idiots succeed in enterprises we have failed in. Denial ain't just a river in Egypt. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20040623/2353cca2/attachment.html From noreply at sourceforge.net Wed Jun 23 14:30:02 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jun 23 16:14:21 2004 Subject: [Patches] [ python-Patches-876130 ] add C API to datetime module Message-ID: Patches item #876130, was opened at 2004-01-13 10:20 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=876130&group_id=5470 Category: Modules Group: Python 2.3 Status: Closed Resolution: Accepted Priority: 5 Submitted By: Anthony Tuininga (atuining) Assigned to: Tim Peters (tim_one) Summary: add C API to datetime module Initial Comment: The datetime module does not have a C API which means that modules written in C cannot take advantage of the datetime module without incurring significant overhead. These patches supply this lack and are based on the C API exported by the mxDateTime module and the cStringIO module and enhanced as suggested by Guido. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2004-06-23 14:29 Message: Logged In: YES user_id=31435 Good eye! Yes, the accessor macros should be documented too, and it would be great if you whipped up a patch for that. This report has already been closed, so best to open a new patch report for it. You can assign the report to me and I'll make time to get it checked in. ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-06-22 13:06 Message: Logged In: YES user_id=619560 Yes, this has been a long time coming. Collaboration by e-mail with people working on completely different projects can be quite a challenge! Thanks for getting this checked in. When 2.4a1 comes out I will be providing a new version of cx_Oracle that takes advantage of these functions. I just noticed that I missed the macros that are defined in datetime.h that were not modified with my patch -- specifically those used to acquire the components of the date/time objects. Should those be documented as well? I'm assuming the answer is yes -- so would it be helpful if I did so and attached a patch to this set of patches or do I need to create a new patch? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-06-20 18:51 Message: Logged In: YES user_id=31435 Thanks for your patience, Anthony! I checked this in after minor fiddling. Biggest change was to supply a new macro and docs, to expose the unreferenced Delta_FromDelta member of the C API struct. I do wish we had test cases -- as is, these maros could be totally busted and we'd have no way to know that. But virtually all of the C API is untested that way, so it's not a fatal objection. Doc/api/concrete.tex; new revision: 1.45 Include/datetime.h; new revision: 1.5 Misc/ACKS; new revision: 1.267 Misc/NEWS; new revision: 1.1008 Modules/datetimemodule.c; new revision: 1.74 The answers to your questions are implicit in what I checked in . Note that in 2.4, datetimemodule.c *is* compiled as part of the core. Guido nevertheless didn't want the datetime API to take advantage of that (I'm unclear on why). I'm content to document the macros and leave it at that. The DB API functions don't bother me one way or the other, so left them in. ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-06-14 11:23 Message: Logged In: YES user_id=619560 I have attached a patch for the documentation as requested. Not being certain of the format and requirements for the content, your comments are appreciated. I have a few questions that might help focus your comments. 1) Should the API structure be documented and users of datetime.h encouraged to use it directly? Or should it be "implementation details" and only those methods that I have provided should be available? To help answer this question, is it intended to ever bring datetime objects into the "core" rather than as a separate module? 2) The DB API helper functions are provided because Marc Andre Lemburg thought it would be a good idea. Please take a look and see if it makes sense now that it is documented. :-) Please review and give me your feedback. Thanks. ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-06-07 09:57 Message: Logged In: YES user_id=619560 Yes, the top two files are the ones involved. As per your suggestion I deleted the other four files to avoid further confusion. I understand the concern for documentation. I'll see what I can do to get at least a preliminary patch on that front ready this week. Earlier discussions suggested that the documentation reside solely in the include file but I think adding a section to the Python/C API documentation would make a lot more sense. Please stand by. :-) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-06-05 19:43 Message: Logged In: YES user_id=31435 Assuming the current state of the proposal consists of the first two patches on the list ("patch for datetimemodule.c" and "patch for datetime.h"), I'm probably happy to commit them. Can't say for sure right now, because SF CVS is dead, and can't get a current checkout to try them with. The one necessary thing I don't see are docs: how are users supposed to know this exists, let alone know how to use it? We need a new section for datetime objects in the Python/C API Reference Manual, in the Other Objects part of the Concrete Objects Layer section. You don't have to write LaTeX, plain text is fine. Look at the other sections in that chapter for what's needed (an overview, and a precise account of what's in the new C API and how to use it). Don't let that discourage you -- you're very close! If I don't force docs out of you now, docs will never get written. That's why I'm trying to force docs out of you now . ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-06-05 19:10 Message: Logged In: YES user_id=31435 Heh. Just noticed there are 6 patches attached to this report. Are all of them part of the suggested change, or, if not, which are the current ones (if that's the case, the best way to answer the question is to delete the out-of-date patches)? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-06-01 13:53 Message: Logged In: YES user_id=31435 I intend to do it this week, but have no time today or tomorrow. ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-06-01 13:44 Message: Logged In: YES user_id=619560 Sure. What's the chance of it being reviewed prior to the release of Python 2.4 a1? I just saw the preannouncement today -- it is scheduled for the end of this month, I believe. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-05-31 23:12 Message: Logged In: YES user_id=31435 Assigned to me for the next review. Can't do it immediately, but will do my best to free up some time for it "soon". ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-05-26 15:39 Message: Logged In: YES user_id=619560 I would agree with your assessment of the issue regarding the TimeFromTicks() API and find it quite reasonable. Either implement both at the C and Python levels or not at all. Since there is no consensus on this, none it is. :-) Did you have a chance to review the actual code? The changes are fairly minimal but you might have questions about readability, names, etc. It would be great if this could be included in an upcoming 2.4 alpha/beta so that I can provide support in cx_Oracle for the next release. Thanks for your time. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-05-26 15:32 Message: Logged In: YES user_id=31435 Under the belief that the *intent* of this patch is to add a C API to Python's datetime module, it should stick to exposing C ways to spell what Python programmers can already do from Python using datetime. Since nothing like TimeFromTicks() exists in the Python datetime API, it simply doesn't make sense to invent one available only from C. It *may* make sense to invent one in a DB API wrapper around datetime, but I view that as out of scope for this patch. I would not add TimeFromTicks() to the Python datetime API either, because the docs are ambiguous. The sample implementation Marc-Andre posted here uses localtime() to resolve the ambiguity in the docs, but that has to be a wrong choice for some time-of-day apps. For example, there's apparently no portable way to spell "noon" using TimeFromTicks(): the value you get back depends on which time zone localtime() happens to use at the time it's called. If people want time-of-day from a POSIX timestamp, it remains easy to get it from what datetime already supplies, but to do so you have to be explicit about whether you want UTC or local time interpretation. Both are easily spelled already, and it's a Good Thing that you need to be explicit if you want to do such a thing. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-05-26 15:25 Message: Logged In: YES user_id=38388 Tim, please review. Thanks. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-05-26 15:22 Message: Logged In: YES user_id=38388 Thanks, but I don't have time to review it. As for the TimeFromTicks() API: I can understand that you don't feel like implementing it, but hey, I won't use datetime either. The only reason I'm trying to push full support of the DB API specs is that Guido et al. wanted to see a note in the DB API that datetime also provides a usable interface to do date/time interfacing. I'm not very interested in datetime myself, since I'll continue to use mxDateTime, so the situation for me is somewhat similar to yours: investing time into something that I myself will probably not use much (I will add support to mxODBC for those who like to use datetime instead of mxDateTime, but won't use it myself). Feel free to check in your changes. Thanks. ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-05-26 12:30 Message: Logged In: YES user_id=619560 Attached are the modified patches based on your suggestions. I have tested them with my own module cx_Oracle and they appear to work correctly. Any further suggestions would be appreciated. I would like to see this included for Python 2.4 if at all possible. Please let me know what I need to do (if anything) to get this to happen. As for the TimeFromTicks() routine, Oracle has absolutely no use for a "time-only" data type and does not support it. It clearly does not have broad support so I really have no desire to implement it since I will never use it myself. If you consider it important, you could add it yourself or we could wait until someone else who requires it for their implementation of the DB API requires it. I'm not trying to be rude or trying to denigrate the DB API, simply trying to be practical. Please let me know if this is offensive in any way. Thanks. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-05-19 04:28 Message: Logged In: YES user_id=38388 >From the DB API specs: TimeFromTicks(ticks) This function constructs an object holding a time value from the given ticks value (number of seconds since the epoch; see the documentation of the standard Python time module for details). The reason for this having this API is to be able to construct an object suitable for passing to the database given a Unix ticks value. Since the ticks value contains both a date and a time part and most databases have a special column type for time value, we need two constructor APIs, one to extract just the date part and one for the time part. Here's the mxDateTime implementation for reference: def TimeFromTicks(ticks, # Locals: DateTimeDelta=DateTimeDelta,localtime=_time.localtime): """ TimeFromTicks(ticks) Constructs a DateTimeDelta instance pointing to the local time indicated by the given ticks value. The date part is ignored. """ return apply(DateTimeDelta, (0,) + localtime(ticks)[3:6]) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-05-03 13:46 Message: Logged In: YES user_id=31435 I don't understand what TimeFromTicks() is supposed to do. Seconds-from-the-epoch is a point in time, not a time-of- day. If some DB API requires guessing some transformation from seconds-from-the-epoch to time-of-day, that's fine, but it doesn't belong in Python's datetime module. The datetime module should certainly have a method to construct a datetime.datetime from a seconds-from-the- epoch argument -- seconds-from-the-epoch is a way of specifying a datetime.datetime. Given that, if the intent is to throw away the datetime.date portion of the datetime.datetime object, retaining only the datetime.time portion, then that's trivially accomplished by invoking dt.time () (where dt is the datetime.datetime object). Do any databases really store time-of-day as a seconds-from- the-epoch value? Google's top hit on TimeFromTicks() today happens to be a msg from Anthony saying that Oracle does not. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-05-03 13:24 Message: Logged In: YES user_id=38388 Macro: I don't know whether you need the macro or not (you probably do for the type checks). In any case, you can do without relying on Python providing you this information via the build process, since only datetimemodule.c is using the header file while Python is being built. TimeFromTicks(): I' ve stated my point. I don't think there's anything to add - I'm tired of fighting for these things... one of the reasons I stopped actively discussing things on python-dev. IMHO, a product that's aimed at developers should make things easy for the developer and try to avoid code duplication if possible. The API is needed in order to support database interfaces that use Unix ticks as basis for date/time, so if you don't add it to the module, the ten or twenty module authors out there will have to duplicate that piece of work in their implementation. Transition: This was already discussed on the db-api list. We love freedom of choice. Nothing to add. ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-05-03 12:48 Message: Logged In: YES user_id=619560 About the Py_BUILD_CORE issue: You are suggesting that I define this in datetimemodule.c just prior to the include of datetime.h? Or are you suggesting some other macro? I am not sure about the comment about "not needing a macro in the first place" since there are two groups that will be importing datetime.h: the first being the datetime module itself and the second being the DB API modules. The macro is definitely required to distinguish between the two -- unless I am missing something? On the TimeFromTicks() issue: You obviously consider it important that the three methods be available at the C level for DB API module authors to use directly. My objection is simply a reiteration of an objection raised by Tim Peters. I think you'll have to argue that one with him. :-) I'll provide my implementations for cx_Oracle as part of the patches and then you can fight it out and I'll stay out of it. :-) As for the transition period, I assumed that with the introduction of a standard datetime module, that it would become the suggested implementation for database interfaace modules. That said, I don't really have any authority to say anything on this front so I'll leave that to you and others to decide. :-) ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-05-03 11:26 Message: Logged In: YES user_id=38388 About the Py_BUILD_CORE issue: Sorry, I didn't know that Python does not define this macro for core modules. Nevertheless, looking at the datetime module code I don't really understand why you would need such a macro in the first place. Since the datetime module is the only code including the datetime.h header file it should be easy to add a macro definition just before importing datetime.h. On the TimeFromTicks() issue: The whole point of this discussion is to make the datetime module easily usable for authors of database modules. Since the DB API specifies that the module will need to export the three functions, two of which are available through the datetime module already, I don't really see your point in not wanting to add it. BTW, you are wrong in the assumption that the DB API spec will move away from a generic API for date/time objects. The DB API has always been defined in terms of interfaces and does not force a certain set of tools onto the developer. The datetime module will become one possible choice for DB API authors, others will want to stick to mxDateTime, use strings, ticks integers or more specific objects for interfacing. That won't change, so there is no "transition period". ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-05-03 10:40 Message: Logged In: YES user_id=619560 I spent some time getting the two include files merged together, only to discover that Py_BUILD_CORE is __NOT__ defined when building modules, only when building stuff linked directly into the core interpreter. Perhaps this ought to be defined when building the modules with setup.py? At any rate, I cannot proceed along the route suggested without this problem being resolved. On the DateFromTicks(), TimestampFromTicks(), TimeFromTicks() issue, I'm not sure that there is much benefit to including a C API for this since if the datetime module becomes the standard method for managing datetime objects, there is no point in having the DB API modules provide something that the datetime module already provides, right? During the transition period the few lines of code needed can be posted. If you disagree I can certainly provide the few lines as part of the patch but I suspect you will find resistance to having this included by Tim Peters, the maintainer (I believe) of the datetime module. Feel free to correct me... :-) ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-04-26 12:19 Message: Logged In: YES user_id=38388 Sorry for not getting back to you earlier: I didn't see you last message. 1-4) Python defines a macro during the Python build process that is not defined when compiling extensions: Py_BUILD_CORE You can use that macro to compile things differently for core things vs. extensions. 5) Fair enough; I don't see a point in creating a new numbering for each and every module. Please just use 1, 2, 3, 4, ... 6) Hope this makes sense :-) ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-04-26 11:35 Message: Logged In: YES user_id=619560 Any chance to look at this? Any hope of this being included in Python 2.4? I know a number of people (including Guido) who would appreciate that.... :-) ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-04-05 18:04 Message: Logged In: YES user_id=619560 I am back at work after finishing my move so I think I can finally devote a little more time to this issue. 1-4) The main reason for datetimeapi.h as opposed to simply modifying datetime.h was that the internal build needs to define things __differently__ from an external build of a module and there doesn't appear to be any way of fixing that -- so if you know a way I think I can manage to create a reasonable patch; otherwise, I'm out of my depth! 5) Guido was suggesting that a new PyIMPORT macro be made available which would verify that the magic number defined in the header file actually matches the magic number exported by the built module; this is simply a developer protection scheme which should eliminate really stupid uses; you can ask him about this or I can e-mail you part of the thread that brought this up 6) Makes sense. I'd like to get the questions above resolved first before proceeding any further, though. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-03-25 13:23 Message: Logged In: YES user_id=38388 Thanks for the comments... 1) Please put *all* the code for the C API into datetimeapi.h. I don't like your current mix of putting some things into datetime.h and others into datetimeapi.h (e.g. the PyDateTime_CAPI definition). 2) Since it's the only API missing if you want to use datetime objects in database interfacing, please add it. 3) dito. 4) Yes, the header file is the right place. Have a look at unicodeobject.h for what I have in mind (or mxDateTime.h for that matter). 5) Why add yet another magic number ? Isn't the Python API number enough ? 6) Since you don't provide a doc patch, please put comments into the header file. There can never be enough documentation and developers tend to look at the code rather than the docs ;-) ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-03-25 13:08 Message: Logged In: YES user_id=619560 Sorry for the delay. Things here have been quite busy recently both at work and at home. Let me see if I can answer your questions. 1) are you suggesting comments that include the macro names in datetimeapi.h similar to what I put in the comments below? Or something else? See modified datetimeapi.h for more info. 2) TimeFromTicks() is a very DB API specific routine. In chatting with others about the datetime module, they were not keen on adding such a beast. I guess there will have to be some discussion about whether datetimeapi.h is also a sort of half implementation for a C module implementing the DB API. I was intending to do this in my cx_Oracle module but not in datetimeapi.h. Could you clarify? 3) I could add C APIS for the three DB API ticks interfaces but I was simply intending to do that in cx_Oracle. Again, see #2. I can do it either way. :-) 4) I have added limited documentation in datetimeapi.h but is that really the right place for it? Is it even remotely close to what is needed? I'm not sure what is needed here exactly. 5) the API magic number is simply an arbitrary number which is stored in datetime.h and need not be understood by the implementor. For your information I simply took the name "datetime", converted each letter to its ordinal value in the alphabet, modded by 16 and used that hex character -- does that make any sense? This can be changed to whatever makes sense, though. 6) Whether or not datetimeapi.h should be sufficient for a developer or whether he should look at documentation in the usual locations (html pages, for example) I'll leave up to the Python development team. Let me know how I can assist. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-03-25 12:35 Message: Logged In: YES user_id=38388 Anthony, have you had a chance to look at the comments ? ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-02-26 10:06 Message: Logged In: YES user_id=619560 Oops! It looks like my own misunderstanding of SourceForge and how it works is to blame. :-( I'll take a look at this and get back to you as soon as possible -- ignore my previous comment. ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-02-26 10:03 Message: Logged In: YES user_id=619560 You haven't yet responded to my previous comments -- it looks like SourceForge put them __after__ your comments so it is quite understandable why you didn't notice them. If you can give me the answers to those questions or provide additional questions that I need to answer, then I think we can make progress again. I was waiting for __you__ :-) ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-02-25 18:08 Message: Logged In: YES user_id=38388 Any progress on this ? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-01-28 06:49 Message: Logged In: YES user_id=38388 Thanks for the clarification. I had forgotten about the macros -- I'd suggest that you document them in the datetimeapi.h include file to not cause the same confusion on the developer side (the trick to achieve adoption is to make things easy on the developer). As for TimeFromTicks(): This should be rather straight forward to implement: you take the time part of the ticks timestamp and create a time object from it. This is the way the DB API constructor works. Could you add C APIs for the three DB API ticks interface methods ? Other things that are missing: * documentation of the way the CAPI object can be used in datetimeapi.h * documentation of the various CAPI entries * documentation of the API magic number (there should be some scheme for this) I think that datetimeapi.h should be enough for a developer to read in order to use the interface. ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-01-26 16:02 Message: Logged In: YES user_id=619560 I didn't think any additional API would be necessary for extracting date time information since the following macros are available: PyDateTime_GET_YEAR(o) PyDateTime_GET_MONTH(o) PyDateTime_GET_DAY(o) PyDateTime_DATE_GET_HOUR(o) PyDateTime_DATE_GET_MINUTE(o) PyDateTime_DATE_GET_SECOND(o) PyDateTime_DATE_GET_MICROSECOND(o) PyDateTime_TIME_GET_HOUR(o) PyDateTime_TIME_GET_MINUTE(o) PyDateTime_TIME_GET_SECOND(o) PyDateTime_TIME_GET_MICROSECOND(o) Were you thinking of something else that is needed? As for interfacing at the C level for converting from Unix ticks, the following method is already available and could simply be used as a drop in replacement for DateFromTicks() and TimestampFromTicks() from the DB API document. DateFromTicks() --> datetime.date.fromtimestamp() TimestampFromTicks() --> datetime.datetime.fromtimestamp() TimeFromTicks() is not already exposed but discussions with Tim Peters already suggested that would not happen since the concept is rather strange. You'll have to discuss that with him if you disagree! :-) Any comments? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-01-26 15:46 Message: Logged In: YES user_id=38388 This is a good start. However, you should add more APIs for extracting date/time information to the C API. mxDateTime.h from egenix-mx-base can provide a good basis for this. If you want to make the datetime module usable for database interfacing at C level, you'll also have to add interfaces for Unix ticks conversion, since these are often used by database C level interfaces. ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-01-26 13:36 Message: Logged In: YES user_id=619560 I have no objection to providing patches for doc and test. A quick look at _testcapimodule.c doesn't provide any obvious ideas as to how to patch it. I looked for cStringIO which has a C API already and found nothing in there at all. The documentation also simply says "see the source for the information you require". Any suggestions as to how to proceed? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-01-25 22:17 Message: Logged In: YES user_id=31435 Marc-Andre, can you review this? I think you have more experience building C APIs for modules than anyone else (while I don't have any). There's certainly no objection to giving datetime a C API, and Guido already said he doesn't want to rely on that Martin changed datetime to be built as part of the core (in 2.3 on Windows, datetime.pyd was a distinct DLL; in CVS, datetime is compiled into the core DLL now). Anthony, you probably need to add doc and test patches. _testcapimodule.c holds tests of things you can only get at from C. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=876130&group_id=5470 From noreply at sourceforge.net Thu Jun 24 02:23:39 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jun 24 02:23:47 2004 Subject: [Patches] [ python-Patches-914575 ] difflib side by side diff support, diff.py s/b/s HTML option Message-ID: Patches item #914575, was opened at 2004-03-11 17:50 Message generated for change (Comment added) made by dmgass You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914575&group_id=5470 Category: Modules Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: Dan Gass (dmgass) Assigned to: Raymond Hettinger (rhettinger) Summary: difflib side by side diff support, diff.py s/b/s HTML option Initial Comment: lib/difflib.py: Added support for generating side by side differences. Intended to be used for generating HTML pages but is generic where it can be used for other types of markup. tools/scripts/diff.py: Added -m option to use above patch to generate an HTML page of side by side differences between two files. The existing -c option when used with the new -m option controls whether contextual differences are shown or whether the entire file is displayed (number of context lines is controlled by existing -l option). NOTES: (1) Textual context diffs were included as requested. In addition, full and contextual HTML side by side differences (that this patch generated) are also included to assist in analyzing the differences and showing an example. (2) If this functionality is worthy of inclusion in the standard python distribution, I am willing to provide more documentation or make modifications to change the interface or make improvements. (3) When using Internet Explorer some font sizes seem to skew things a bit. Generally I've found the "smallest" to work best. If someone knows why, I'd be interested in making any necessary adjustments in the generated HTML. ---------------------------------------------------------------------- >Comment By: Dan Gass (dmgass) Date: 2004-06-24 01:23 Message: Logged In: YES user_id=995755 I just attached an updated patch. I based the patch on diff.py(CVS1.1) and difflib.py(CVS1.20) which was the latest I saw today on viewCVS. The following enhancements were made: 1) user interface greatly simplified for generating HTML (see diff.py for example) 2) generated HTML now 4.01 Transitional compliant (so says HTML Tidy) 3) HTML color scheme for differences now matches that used by viewCVS. 4) differences table now has a row for each line making the HTML less susceptible to browser quirks. 5) took care of all issues to date enumerated here in this patch. It would be great if I could get some help on: A) getting some JavaScript? written to be able to select and cut text from a single column (right now text is selected from the whole row including both "from" and "to" text and line numbers. B) solving the line width issue. Currently the "from" / "to" column is as wide as the widest line. Any ideas on wrapping or scrolling? As of now the only feature I may want to add in the near future is optional tab expansion. Thanks to those that have commented here and emailed me with suggestions and advice! ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2004-06-11 09:35 Message: Logged In: YES user_id=764593 Thank you; I have often wished for side-by-side, but not quite badly enough to write it. That said, I would recommend some tweaks to the formatting. "font" is deprecated; "span" would be better. On my display, the "next" lines don't always seem to be counted (except the first one), so that the anchors column is not lined up with the others. (This would also be fixed by the separate rows suggestion.) Ideally, the line numbers would be in a separate column from the code, to make cut'n'paste easier. (Then you could replace font.num (or span.num) with td.linenum.) Ideally, each change group should be a separate row in the table. (I realize that this probably means a two-layer iterator, so that the line breaks and blank lines can be inserted correctly in the code columns.) ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-04-28 23:30 Message: Logged In: YES user_id=995755 Also, I will need to submit the fix for making it behave nice when there are no differences!! ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-04-09 08:30 Message: Logged In: YES user_id=995755 In the time since submission I've found that the interface to the chgFmt and lineFmt functions (arguments of mdiff) should include both the line number and an indication of side (from/to). The use for it I've found is for dropping anchors into the generated markup that it can be hyperlinked from elsewhere. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914575&group_id=5470 From janaki at seznam.cz Thu Jun 24 14:13:57 2004 From: janaki at seznam.cz (Pince Meill) Date: Thu Jun 24 14:23:18 2004 Subject: [Patches] Privilege So.ftware Message-ID: Skipped content of type multipart/alternative From hua0518 at nyc.com Thu Jun 24 09:03:05 2004 From: hua0518 at nyc.com (JIll) Date: Thu Jun 24 16:35:44 2004 Subject: [Patches] Health 2004 $23 Message-ID:

Suppose we tell you that you could really lose up to 82% of your unwanted body fat and keep it off in just a few months, would you be interested? We certainly hope so!
Have you tried just about every diet out there-but nothing seems to work?! Then don't miss this important message!
We invite you to experience the most advanced weight Loss product available (h gh oral spray) we guarantee for you to lose weight quickly, safely and keep it off for good forever!
We manufacture and ship directly to your door. We guarantee the highest quality and lowest price.
please visit our web site here

0FF

From jlxxdroxeqlibk at geeklife.com Thu Jun 24 17:39:17 2004 From: jlxxdroxeqlibk at geeklife.com (Anthony London) Date: Thu Jun 24 16:45:14 2004 Subject: [Patches] T0p Quality S0ftware at the L0west Possible Priice from Coon's S0ftSh0p Message-ID: Be a good animal, true to your animal instincts. The absent are never without fault. Nor the present without excuse. Courage, not compromise, brings the smile of God's approval. A library is thought in cold storage. The undertaking of a new action brings new strength. The best thing to do with the best things in life is to give them up. Of Consciousness, her awful Mate. The Soul cannot be rid -- as easy the secreting her behind the Eyes of God. The hero draws inspiration from the virtue of his ancestors. It began in mystery, and it will end in mystery, but what a savage and beautiful country lies in between. When in doubt, don't. All things whatsoever ye would that men should do to you, do ye even so to them. [Matthew 7:12] I have spent more than half a lifetime trying to express the tragic moment. A hero is a man who is afraid to run away. All great peoples are conservative. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20040625/79fabd40/attachment.html From noreply at sourceforge.net Thu Jun 24 19:36:07 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jun 24 19:36:21 2004 Subject: [Patches] [ python-Patches-972310 ] urllib2 handler algorithm docs Message-ID: Patches item #972310, was opened at 2004-06-13 23:29 Message generated for change (Settings changed) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=972310&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None >Priority: 6 Submitted By: John J Lee (jjlee) >Assigned to: Martin v. L?wis (loewis) Summary: urllib2 handler algorithm docs Initial Comment: In adding the docs that explain how handler methods are called, I got the algorithm wrong. (I accidentally described the slightly different algorithm used by my urllib2-workalike module) This patch fixes that. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=972310&group_id=5470 From noreply at sourceforge.net Thu Jun 24 19:38:01 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jun 24 19:38:09 2004 Subject: [Patches] [ python-Patches-969900 ] cookielib doc minor corrections and clarifications Message-ID: Patches item #969900, was opened at 2004-06-09 21:55 Message generated for change (Settings changed) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=969900&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None >Priority: 6 Submitted By: John J Lee (jjlee) >Assigned to: Martin v. L?wis (loewis) Summary: cookielib doc minor corrections and clarifications Initial Comment: Nothing to add to the summary... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=969900&group_id=5470 From noreply at sourceforge.net Thu Jun 24 19:39:32 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jun 24 19:40:01 2004 Subject: [Patches] [ python-Patches-969907 ] Don't print to stdout in cookielib.py exception handler Message-ID: Patches item #969907, was opened at 2004-06-09 22:09 Message generated for change (Settings changed) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=969907&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None >Priority: 6 Submitted By: John J Lee (jjlee) >Assigned to: Martin v. L?wis (loewis) Summary: Don't print to stdout in cookielib.py exception handler Initial Comment: There are a couple of blanket except: statements in cookielib. The idea is to handle any bugs in cookielib's input handling that may be tickled by unexpected input by issuing a warning instead of letting the exception propagate. Previously, in addition to issuing a warning, a traceback was printed. This patch makes the traceback part of the warning, so it can be suppressed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=969907&group_id=5470 From zvfahhaxicn at yahoo.com Fri Jun 25 13:57:49 2004 From: zvfahhaxicn at yahoo.com (Kyle Lester) Date: Thu Jun 24 22:00:04 2004 Subject: [Patches] Looking for cheap high-quality software? Message-ID: We are dumping our inventory!!...take advantage of this unbeatable offer while it lasts: Windows XP Pro and Office XP - $80 Adobe Photoshop 7.0 - $60 Dreamweaver MX - $60 Corel Draw 12 - $50 Plus many, many more...Shipped worldwide to your Door - 100% Legal (OEMcd's). http://penis.mhcnjcnn.info/?O1knkziQySpb4OO Don't want these notifications? http://BJCKKBFF.info/crest?o7qZq9oWEY_NGUo oalcotteureka campsite sag hungry annoyance inventor witchcraft uncouth corpsmen looseleaf thomson summation cast auerbach solder wholly ccapricorncitizen bourbaki hack dolores antiperspirant gumption camelot donahue cochrane resurrect ode blindfold bless acquit arlington particle comply burglarproof colloidal From lamar.l.martinqj at news.volvo.se Thu Jun 24 22:41:09 2004 From: lamar.l.martinqj at news.volvo.se (Lamar L. Martin) Date: Thu Jun 24 22:37:41 2004 Subject: [Patches] Lose 19%, powerful weightloss now available where you are. Message-ID: <8a6b01c45a5d$5dab22aa$27301e56@enigma.nu> Hello, I have a special offer for you... WANT TO LOSE WEIGHT? The most powerful weightloss is now available without prescription. All natural Adipren720 100% Money Back Guarant?e! - Lose up to 19% Total Body Weight. - Loss of 20-35% abdominal Fat. - Up to 300% more Weight Loss while dieting. - Increase metabolic rate by 76.9% without Exercise. - Reduction of 40-70% overall Fat under skin. - Suppresses appetite for sugar. - Burns calorized fat. - Boost your Confidence level and Self Esteem. Get the facts about all-natural Adipren720 ---- system information ---- processing years dealing Usage Specifying categories designers Services MIME method accordance hidden wants non-proprietary interpretation: identifiers representing around architecture geographic technical considered correctly element zh nearly implement attribute resulting For subtle writing object same Some so will parts use ja From noreply at sourceforge.net Fri Jun 25 07:29:29 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jun 25 07:29:33 2004 Subject: [Patches] [ python-Patches-979658 ] Improve HTML documentation of a directory Message-ID: Patches item #979658, was opened at 2004-06-25 14:29 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=979658&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Noam Raphael (noamr) Assigned to: Nobody/Anonymous (nobody) Summary: Improve HTML documentation of a directory Initial Comment: Attached is a patch which improves pydoc's HTML documentation of a complete directory. It consists of two parts. The first gives adds functionality to the "pydoc -w " command, mostly in the spirit of compileall.py. The second fixes a bug, which causes pydoc to search for modules in sys.path instead of in the actual directory documented. pydoc -w functionality ========================= Here's my actual situation: There's a package maintainance system, where you first create files in your home directory and then use the system to install them in a common place. For example, if a package is called foo, and includes the modules ya.py and chsia.py, the modules will be named /home/noam/foo/lib/python/{ya,chsia}.py. I want to automatically document them, so that the HTML files will sit in /home/noam/foo/doc. After installing the package, the python modules will be copied to /usr/local/lib/python/, and the documentation will be copied to /usr/local/doc/foo. I want to be able to type one command to generate all the documentation, but I don't want to waste time if I only need the documentation re-generated for one module. So I made "pydoc -w " produce documentation only if the target file was modified before the module was. (pydoc -w still writes the documentation even if it seems up to date.) It is perfectly legitimate to write a HTML documentation for a module by your own. So I made pydoc never overwrite HTML files which weren't created by pydoc. To accomplish this, I added the tag to the head of all HTML files produced by pydoc. A warning is printed if a module was modified after its manually created documentation was modified. I wanted to be able to run "pydoc -w" from any directory, not just from /home/noam/foo/doc, so I added an option "-o ", to specify the output directory. (If it isn't specified, the current directory is used.) I wanted the documentation to refer to the installed file (/usr/local/lib/python/foo.py), not to the file in my home directory. So I added an option "-d ", to specify the directory in which the files will reside after being installed. To summarise, the command which I should now run to produce the documentation is pydoc -w -o doc/ -d /usr/local/ lib/python/ (running it from /home/noam/foo). The -d and -o options are already available in compileall.py, for exactly the same reasons, I think. None of this should cause backward compatibility issues. Module loading =========== Currently, safeimport(), used by writedocs(), gets only a module name, and imports it using __import__(). This means that when you document a complete directory, you can only produce HTML documentation for modules which are already installed, and that a documentation for the wrong version of a module may be produced. I changed safeimport() to get an optional list of directories in which to look for the module/package, in which case it uses imp.find_module and imp.load_module instead of __import__. This means that when producing documentation for a complete directory, the actual files in the directory are used, not installed modules of the same name. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=979658&group_id=5470 From noreply at sourceforge.net Fri Jun 25 09:26:43 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jun 25 09:26:50 2004 Subject: [Patches] [ python-Patches-979728 ] mplementation for PEP 318 using java-style syntax Message-ID: Patches item #979728, was opened at 2004-06-25 13:26 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=979728&group_id=5470 Category: Parser/Compiler Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Mark Russell (mark_t_russell) Assigned to: Nobody/Anonymous (nobody) Summary: mplementation for PEP 318 using java-style syntax Initial Comment: This implements function decorators using the Java-style syntax described in http://mail.python.org/pipermail/python-dev/2004-June/045516.html As the patch changes the grammar, you'll need to make sure Include/graminit.h and Python/graminit.c are writable after applying the patch but before compiling (after a standard CVS checkout they are read-only, which stops pgen from working). Changes: - adding @ as a token - changing the grammer for funcdef - adding com_decorator in compile.c - adding test_decorator.py (based on Guido's version) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=979728&group_id=5470 From noreply at sourceforge.net Fri Jun 25 09:41:52 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jun 25 09:41:56 2004 Subject: [Patches] [ python-Patches-979737 ] compile of code with incorrect encoding yields MemoryError Message-ID: Patches item #979737, was opened at 2004-06-25 07:41 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=979737&group_id=5470 Category: Parser/Compiler Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Anthony Tuininga (atuining) Assigned to: Nobody/Anonymous (nobody) Summary: compile of code with incorrect encoding yields MemoryError Initial Comment: The following code will fail in both Python 2.3 and Python 2.4, raising a MemoryError exception, when run on any platform except Windows: compile("# -*- coding: mbcs -*-", "test.py", "exec") This has been reproduced on the following platforms: Linux x86 HP-UX Solaris Tru64 Unix I realize this is an invalid encoding but it would be nice if something other than MemoryError was raised! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=979737&group_id=5470 From noreply at sourceforge.net Fri Jun 25 09:43:58 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jun 25 09:44:04 2004 Subject: [Patches] [ python-Patches-979737 ] compile of code with incorrect encoding yields MemoryError Message-ID: Patches item #979737, was opened at 2004-06-25 07:41 Message generated for change (Settings changed) made by atuining You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=979737&group_id=5470 Category: Parser/Compiler Group: Python 2.3 Status: Open >Resolution: Invalid Priority: 5 Submitted By: Anthony Tuininga (atuining) Assigned to: Nobody/Anonymous (nobody) Summary: compile of code with incorrect encoding yields MemoryError Initial Comment: The following code will fail in both Python 2.3 and Python 2.4, raising a MemoryError exception, when run on any platform except Windows: compile("# -*- coding: mbcs -*-", "test.py", "exec") This has been reproduced on the following platforms: Linux x86 HP-UX Solaris Tru64 Unix I realize this is an invalid encoding but it would be nice if something other than MemoryError was raised! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=979737&group_id=5470 From noreply at sourceforge.net Fri Jun 25 09:44:32 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jun 25 09:44:40 2004 Subject: [Patches] [ python-Patches-979737 ] invalid submission Message-ID: Patches item #979737, was opened at 2004-06-25 07:41 Message generated for change (Settings changed) made by atuining You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=979737&group_id=5470 Category: Parser/Compiler Group: Python 2.3 Status: Open Resolution: Invalid Priority: 5 Submitted By: Anthony Tuininga (atuining) Assigned to: Nobody/Anonymous (nobody) >Summary: invalid submission Initial Comment: The following code will fail in both Python 2.3 and Python 2.4, raising a MemoryError exception, when run on any platform except Windows: compile("# -*- coding: mbcs -*-", "test.py", "exec") This has been reproduced on the following platforms: Linux x86 HP-UX Solaris Tru64 Unix I realize this is an invalid encoding but it would be nice if something other than MemoryError was raised! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=979737&group_id=5470 From noreply at sourceforge.net Fri Jun 25 09:45:14 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jun 25 09:45:20 2004 Subject: [Patches] [ python-Patches-979737 ] invalid submission Message-ID: Patches item #979737, was opened at 2004-06-25 07:41 Message generated for change (Comment added) made by atuining You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=979737&group_id=5470 Category: Parser/Compiler Group: Python 2.3 Status: Open Resolution: Invalid Priority: 5 Submitted By: Anthony Tuininga (atuining) Assigned to: Nobody/Anonymous (nobody) Summary: invalid submission Initial Comment: The following code will fail in both Python 2.3 and Python 2.4, raising a MemoryError exception, when run on any platform except Windows: compile("# -*- coding: mbcs -*-", "test.py", "exec") This has been reproduced on the following platforms: Linux x86 HP-UX Solaris Tru64 Unix I realize this is an invalid encoding but it would be nice if something other than MemoryError was raised! ---------------------------------------------------------------------- >Comment By: Anthony Tuininga (atuining) Date: 2004-06-25 07:45 Message: Logged In: YES user_id=619560 Apologies for this -- I submitted this in the patch subsection when it should have been submitted in the bug subsection ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=979737&group_id=5470 From noreply at sourceforge.net Fri Jun 25 09:47:43 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jun 25 09:47:48 2004 Subject: [Patches] [ python-Patches-979737 ] invalid submission Message-ID: Patches item #979737, was opened at 2004-06-25 07:41 Message generated for change (Settings changed) made by atuining You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=979737&group_id=5470 Category: Parser/Compiler Group: Python 2.3 >Status: Deleted Resolution: Invalid Priority: 5 Submitted By: Anthony Tuininga (atuining) Assigned to: Nobody/Anonymous (nobody) Summary: invalid submission Initial Comment: The following code will fail in both Python 2.3 and Python 2.4, raising a MemoryError exception, when run on any platform except Windows: compile("# -*- coding: mbcs -*-", "test.py", "exec") This has been reproduced on the following platforms: Linux x86 HP-UX Solaris Tru64 Unix I realize this is an invalid encoding but it would be nice if something other than MemoryError was raised! ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-06-25 07:45 Message: Logged In: YES user_id=619560 Apologies for this -- I submitted this in the patch subsection when it should have been submitted in the bug subsection ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=979737&group_id=5470 From noreply at sourceforge.net Fri Jun 25 10:55:13 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jun 25 10:55:26 2004 Subject: [Patches] [ python-Patches-979784 ] OSATerminology extension fix Message-ID: Patches item #979784, was opened at 2004-06-25 14:55 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=979784&group_id=5470 Category: Macintosh Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: has (hhas) Assigned to: Jack Jansen (jackjansen) Summary: OSATerminology extension fix Initial Comment: c.f. Original bug report: '[884085] OSATerminology is broken'. A corrected copy of OSATerminology.c is attached. This is working code taken from appscript package, tested myself on OS 10.2.6 + MacPython 2.3 and with no reports of any problems from other users. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=979784&group_id=5470 From noreply at sourceforge.net Fri Jun 25 14:01:57 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jun 25 14:02:26 2004 Subject: [Patches] [ python-Patches-914575 ] difflib side by side diff support, diff.py s/b/s HTML option Message-ID: Patches item #914575, was opened at 2004-03-12 00:50 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914575&group_id=5470 Category: Modules Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: Dan Gass (dmgass) Assigned to: Raymond Hettinger (rhettinger) Summary: difflib side by side diff support, diff.py s/b/s HTML option Initial Comment: lib/difflib.py: Added support for generating side by side differences. Intended to be used for generating HTML pages but is generic where it can be used for other types of markup. tools/scripts/diff.py: Added -m option to use above patch to generate an HTML page of side by side differences between two files. The existing -c option when used with the new -m option controls whether contextual differences are shown or whether the entire file is displayed (number of context lines is controlled by existing -l option). NOTES: (1) Textual context diffs were included as requested. In addition, full and contextual HTML side by side differences (that this patch generated) are also included to assist in analyzing the differences and showing an example. (2) If this functionality is worthy of inclusion in the standard python distribution, I am willing to provide more documentation or make modifications to change the interface or make improvements. (3) When using Internet Explorer some font sizes seem to skew things a bit. Generally I've found the "smallest" to work best. If someone knows why, I'd be interested in making any necessary adjustments in the generated HTML. ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2004-06-25 20:01 Message: Logged In: YES user_id=89016 Submitting difflib_context.html to validator.w3.org gives 2333 errors. The character encoding is missing and there's no DOCTYPE declaration. The rest of the errors seem to be mostly related to the nowrap attribute (which must be written as nowrap="nowrap", as this is the only allowed value). Furthermore the patch contains a mix of CR and CRLF terminated lines. ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-06-24 08:23 Message: Logged In: YES user_id=995755 I just attached an updated patch. I based the patch on diff.py(CVS1.1) and difflib.py(CVS1.20) which was the latest I saw today on viewCVS. The following enhancements were made: 1) user interface greatly simplified for generating HTML (see diff.py for example) 2) generated HTML now 4.01 Transitional compliant (so says HTML Tidy) 3) HTML color scheme for differences now matches that used by viewCVS. 4) differences table now has a row for each line making the HTML less susceptible to browser quirks. 5) took care of all issues to date enumerated here in this patch. It would be great if I could get some help on: A) getting some JavaScript? written to be able to select and cut text from a single column (right now text is selected from the whole row including both "from" and "to" text and line numbers. B) solving the line width issue. Currently the "from" / "to" column is as wide as the widest line. Any ideas on wrapping or scrolling? As of now the only feature I may want to add in the near future is optional tab expansion. Thanks to those that have commented here and emailed me with suggestions and advice! ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2004-06-11 16:35 Message: Logged In: YES user_id=764593 Thank you; I have often wished for side-by-side, but not quite badly enough to write it. That said, I would recommend some tweaks to the formatting. "font" is deprecated; "span" would be better. On my display, the "next" lines don't always seem to be counted (except the first one), so that the anchors column is not lined up with the others. (This would also be fixed by the separate rows suggestion.) Ideally, the line numbers would be in a separate column from the code, to make cut'n'paste easier. (Then you could replace font.num (or span.num) with td.linenum.) Ideally, each change group should be a separate row in the table. (I realize that this probably means a two-layer iterator, so that the line breaks and blank lines can be inserted correctly in the code columns.) ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-04-29 06:30 Message: Logged In: YES user_id=995755 Also, I will need to submit the fix for making it behave nice when there are no differences!! ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-04-09 15:30 Message: Logged In: YES user_id=995755 In the time since submission I've found that the interface to the chgFmt and lineFmt functions (arguments of mdiff) should include both the line number and an indication of side (from/to). The use for it I've found is for dropping anchors into the generated markup that it can be hyperlinked from elsewhere. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914575&group_id=5470 From noreply at sourceforge.net Fri Jun 25 20:37:09 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jun 25 20:37:12 2004 Subject: [Patches] [ python-Patches-980082 ] Missing INCREF in PyType_Ready Message-ID: Patches item #980082, was opened at 2004-06-25 17:37 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=980082&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Eric Huss (ehuss) Assigned to: Nobody/Anonymous (nobody) Summary: Missing INCREF in PyType_Ready Initial Comment: In PyType_Ready() if the type object you are readying does not explicitly define its tp_base value, it will default to use PyBaseObject_Type. However, this assignment does not INCREF the PyBaseObject_Type pointer. Thus, for heap allocated type objects, when the type_dealloc() function is called, a DECREF is called on tp_base which can eventually cause PyBaseObject_Type refcount go to 0, at which point bad things happen. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=980082&group_id=5470 From noreply at sourceforge.net Fri Jun 25 21:12:45 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jun 25 21:12:49 2004 Subject: [Patches] [ python-Patches-980098 ] Module to dynamically generate structseq objects Message-ID: Patches item #980098, was opened at 2004-06-25 18:12 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=980098&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Eric Huss (ehuss) Assigned to: Nobody/Anonymous (nobody) Summary: Module to dynamically generate structseq objects Initial Comment: The following module allows you to create custom structseq objects from python. It requires a patch to structseq.c in order to correctly allocate the type object on the heap. I wasn't sure about the best way to allocate a type object on the heap, so this is my best effort. I'm going to follow up with a posting to python-dev to see what others think. This file will probably need to be updated to conform to python style standards. Feel free to include this in the standard Python distribution. I am willing to handle future updates/fixes for it. This is related to bug 624827 filed by Fred L. Drake to add similar functionality. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=980098&group_id=5470 From noreply at sourceforge.net Fri Jun 25 22:52:16 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jun 25 22:52:24 2004 Subject: [Patches] [ python-Patches-980120 ] difflib empty list IndexError fix (Bug #980117) Message-ID: Patches item #980120, was opened at 2004-06-25 22:52 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=980120&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Rocco Moretti (roccomoretti) Assigned to: Nobody/Anonymous (nobody) Summary: difflib empty list IndexError fix (Bug #980117) Initial Comment: This is a potential fix for the Bug #980117. The functions unified_diff() and context_diff() give an IndexError when called with two empty lists due to an unmasked index of the opcode lists in SequenceMatcher.get_grouped_opcodes(). In the case of two empty lists passed to the functions, SequenceMatcher.codes is an empty list. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=980120&group_id=5470 From taughtbrackets at cox.net Sat Jun 26 02:45:35 2004 From: taughtbrackets at cox.net (Patricia Jameel) Date: Sat Jun 26 02:45:44 2004 Subject: [Patches] Do you want a bigger P`ENIS? Message-ID: An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20040626/76d18d2c/attachment.html From noreply at sourceforge.net Sat Jun 26 19:47:09 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jun 26 19:47:12 2004 Subject: [Patches] [ python-Patches-980475 ] partially initialized heap allocated type objects Message-ID: Patches item #980475, was opened at 2004-06-26 16:47 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=980475&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Eric Huss (ehuss) Assigned to: Nobody/Anonymous (nobody) Summary: partially initialized heap allocated type objects Initial Comment: There is a problem if you try to dealloc a partially initialized heap allocated type object. Because PyObject_GC_TRACK is not typically called until initialization is done, the gc_refs value is set to GC_UNTRACKED. In type_dealloc, it calls _PyObject_GC_UNTRACK which skips the check to see if it is GC_UNTRACKED. This patch fixes it so that it calls PyObject_GC_UnTrack to correctly handle this case. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=980475&group_id=5470 From noreply at sourceforge.net Sat Jun 26 19:55:30 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jun 26 19:55:34 2004 Subject: [Patches] [ python-Patches-980098 ] Module to dynamically generate structseq objects Message-ID: Patches item #980098, was opened at 2004-06-25 18:12 Message generated for change (Comment added) made by ehuss You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=980098&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Eric Huss (ehuss) Assigned to: Nobody/Anonymous (nobody) Summary: Module to dynamically generate structseq objects Initial Comment: The following module allows you to create custom structseq objects from python. It requires a patch to structseq.c in order to correctly allocate the type object on the heap. I wasn't sure about the best way to allocate a type object on the heap, so this is my best effort. I'm going to follow up with a posting to python-dev to see what others think. This file will probably need to be updated to conform to python style standards. Feel free to include this in the standard Python distribution. I am willing to handle future updates/fixes for it. This is related to bug 624827 filed by Fred L. Drake to add similar functionality. ---------------------------------------------------------------------- >Comment By: Eric Huss (ehuss) Date: 2004-06-26 16:55 Message: Logged In: YES user_id=393416 New patch that does away with the factory object and just produces type objects via a builtin function. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=980098&group_id=5470 From noreply at sourceforge.net Sat Jun 26 22:17:34 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jun 26 22:17:37 2004 Subject: [Patches] [ python-Patches-980500 ] gettext improvements Message-ID: Patches item #980500, was opened at 2004-06-27 02:17 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=980500&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Gustavo Niemeyer (niemeyer) Assigned to: Barry A. Warsaw (bwarsaw) Summary: gettext improvements Initial Comment: This patch implements the following gettext features, as discussed recently in python-dev: In _locale module: - bind_textdomain_codeset() binding In gettext module: - bind_textdomain_codeset() function - lgettext(), lngettext(), ldgettext(), ldngettext(), which return translated strings encoded in preferred system encoding, if bind_textdomain_codeset() was not used. - Added equivalent functionality in install() and translate() functions and catalog classes. - Documentated every change. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=980500&group_id=5470 From fqqxkc at msn.com Sun Jun 27 19:56:02 2004 From: fqqxkc at msn.com (Ted Ferreira) Date: Sun Jun 27 02:43:39 2004 Subject: [Patches] FW: Get Free PPV N_ow Message-ID: <85802343189882371078.90357@zcsaseuuudsqpn@msn.com> Next Generation PPV Device..... No More Paying for Movies & Events on CABLE! Free TV is Here! NEW!!!! --- Eliminate Cable Box Lockups We have a small Digital Filter that we give you FREE and a Lockout Buster that easily fits on the back of your receiver so you can test your Pay-per-View for Movies, Live Sporting Events, Concerts, etc, without paying a dime. This is 100% legal as it is used as reception enhancer device! Click Here for More on this Great Product Combo http://hippytoe.com/promo.php?id=94098 You get the latest Digital HighPass Filter for FREE The latest Lockout Busting filter brand new and available here only. Plus a free BONUS report explaining all the tips and tricks you need to know about your digital cable box. Channels you can test for FREE Include: - All New PPV Movie Releases which normally cost $5 a movie, FREE - Adult Movies (SPice, Playboy, HotZone, etc) normally cost $10 a movie, FREE - Wrestling, UFC, & Boxing PPV's (WWF, NWA, Boxing Heavy Weight Fights) normally cost $30-80 an event, FREE - Live Music Concerts (Eminem, B. Spears, Dixie Chicks, etc) normally cost $35 an event, FREE - Bottom line: Anything you would normally buy you get Free with this! What does this mean? Means you save $1000 in programming a month for one low cost of this unique filter. Guaranteed to Work! - Is there a catch? The only catch is you need Digital Cable. This is because you must buy via the remote control for the filter to work. - Don't have Digital Cable? Simply upgrade for the small fee as you will be getting $1000's of Free programming a month! A very worthwhile investment for YOUR Leisure time! All this for an amazingly low price! Click Below to get more Information & your Cable Filter & Lockout Buster Today (while supplies last): http://hippytoe.com/promo.php?id=94098 ----------- Not Interested? http://hippytoe.com/remove.php?id=94098 8loonstark From noreply at sourceforge.net Sun Jun 27 09:39:19 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jun 27 09:39:23 2004 Subject: [Patches] [ python-Patches-980695 ] efficient string concatenation Message-ID: Patches item #980695, was opened at 2004-06-27 13:39 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=980695&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: efficient string concatenation Initial Comment: A wild idea that makes repeated string concatenations efficient without changing stringobject.c. If we assume we don't want to change the representation of strings, then the problem is that string_concat(v,w) doesn't know if v will soon released, so it cannot resize it in-place even if the refcnt is 1. But with some hacks ceval.c can know that. Statements like s=s+expr or s+=expr both compile to a BINARY_ADD or INPLACE_ADD followed by a STORE_FAST or STORE_NAME. So in the attached patch ceval.c special-cases addition of two strings (in the same way as it special-cases addition of two integers already). If moreover the addition is followed by a STORE that is about to overwrite the addition's left argument, and if the refcnt is right, then the left argument can be resized in-place (plus some obscure magic to ensure that everything is still valid even if resize moves the string in memory). With Python's good memory manager, repeated resizes even without manual over-allocation perform nicely. As a side effect, other constructions like a+b+c+d+e+f also work in-place now. The patch would do with a lot more comments. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=980695&group_id=5470 From noreply at sourceforge.net Sun Jun 27 11:43:39 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jun 27 11:43:49 2004 Subject: [Patches] [ python-Patches-966493 ] Cleanup generator/eval_frame exposure Message-ID: Patches item #966493, was opened at 2004-06-04 14:58 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=966493&group_id=5470 Category: Core (C code) Group: Python 2.4 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: James William Pye (jwpye) Assigned to: Martin v. L?wis (loewis) Summary: Cleanup generator/eval_frame exposure Initial Comment: Hopefully get this cleanup in before 2.4.. . Include genobject.h in Python.h to save embedders an AC check to identify its existance(allowing a simple #ifndef Py_GENOBJECT_H) . Follow up my own recommendation to just reference eval_frame directly by exposing it(change references in ceval.c and genobject.c accordingly). . Update headers accordingly; reference frameobject in genobject.h and ceval.h as struct _frame * like others do to avoid including frameobject.h Rename PyEval_EvaluateFrame to PyEval_EvalFrame to be consistent with PyEval_EvalCode[Ex] in eval.h. Hopefully it isnt too late to change this before 2.4, sorry for not having it in the first patch.. :-( Changes files: genobject.c genobject.h ceval.c ceval.h Python.h ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-06-27 17:43 Message: Logged In: YES user_id=21627 Thanks for the patch. Committed as Python.h 2.64 ceval.h 2.52 genobject.h 2.2 genobject.c 1.3 ceval.c 2.407 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-06-15 13:33 Message: Logged In: YES user_id=80475 Martin, I believe this patches your checkin. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=966493&group_id=5470 From noreply at sourceforge.net Sun Jun 27 12:52:17 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jun 27 12:52:23 2004 Subject: [Patches] [ python-Patches-923098 ] Support for interned strings in marshal Message-ID: Patches item #923098, was opened at 2004-03-25 14:25 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=923098&group_id=5470 Category: Core (C code) Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Martin v. L?wis (loewis) Assigned to: Nobody/Anonymous (nobody) Summary: Support for interned strings in marshal Initial Comment: This patch performs string sharing in marshal for interned strings. On marshalling, TYPE_INTERNED is generated for the first occurrence of an interned strings, and TYPE_STRINGREF for a later occurrence. On unmarshalling, TYPE_INTERNED strings are interned on unmarshalling. During marshalling, a dictionary is created to track the strings; on unmarshalling, a list. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-06-27 18:52 Message: Logged In: YES user_id=21627 Committed, with modifications, as utilities.tex 1.14 libmarshal.tex 1.24 marshal.h 2.14 NEWS 1.1011 import.c 2.233 marshal.c 1.79 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=923098&group_id=5470 From noreply at sourceforge.net Sun Jun 27 16:39:20 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jun 27 16:39:26 2004 Subject: [Patches] [ python-Patches-980695 ] efficient string concatenation Message-ID: Patches item #980695, was opened at 2004-06-27 13:39 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=980695&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: efficient string concatenation Initial Comment: A wild idea that makes repeated string concatenations efficient without changing stringobject.c. If we assume we don't want to change the representation of strings, then the problem is that string_concat(v,w) doesn't know if v will soon released, so it cannot resize it in-place even if the refcnt is 1. But with some hacks ceval.c can know that. Statements like s=s+expr or s+=expr both compile to a BINARY_ADD or INPLACE_ADD followed by a STORE_FAST or STORE_NAME. So in the attached patch ceval.c special-cases addition of two strings (in the same way as it special-cases addition of two integers already). If moreover the addition is followed by a STORE that is about to overwrite the addition's left argument, and if the refcnt is right, then the left argument can be resized in-place (plus some obscure magic to ensure that everything is still valid even if resize moves the string in memory). With Python's good memory manager, repeated resizes even without manual over-allocation perform nicely. As a side effect, other constructions like a+b+c+d+e+f also work in-place now. The patch would do with a lot more comments. ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2004-06-27 20:39 Message: Logged In: YES user_id=4771 resubmitted as a context diff. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=980695&group_id=5470 From noreply at sourceforge.net Sun Jun 27 19:34:52 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jun 27 19:35:00 2004 Subject: [Patches] [ python-Patches-967763 ] fix bsddb memory leaks Message-ID: Patches item #967763, was opened at 2004-06-06 13:51 Message generated for change (Comment added) made by greg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=967763&group_id=5470 Category: None >Group: Python 2.3 Status: Open >Resolution: Remind Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Gregory P. Smith (greg) Summary: fix bsddb memory leaks Initial Comment: only one of the changes fixed a leak reported by valgrind, but i think all the changes are necessary. ---------------------------------------------------------------------- >Comment By: Gregory P. Smith (greg) Date: 2004-06-27 16:34 Message: Logged In: YES user_id=413 fix committed. Modules/_bsddb.c 1.32 and Lib/bsddb/test/test_recno.py 1.8 patch attached. marking as python 2.3 as this should be committed to the python 2.3 maintenance branch before 2.3.5 is released. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2004-06-27 15:51 Message: Logged In: YES user_id=413 DB_get and DBC_set_range were the two leaks that showed up in valgrind using the existing testsuite. however there were plenty more possible leak cases (most of them in odd situations like out of memory or passing a non DBTxn object in the txn parameter). The most common trigger for a leak in various places would be an exception exit from a many functions when using integer keys (queue & recno databases). I have a patch which i believe fixes all of these and more after a lot of code inspection that i'll commit once my valgrind run finishes and reveals no bsddb related leaks or double frees. (ugh running valgrind -v --leak-check=yes ./python Lib/bsddb/test/test_all.py on a 5 year old laptop is slow...) "manual memory management... how quaint." ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2004-06-15 18:48 Message: Logged In: YES user_id=33168 should FREE_DBT() be called clearTxn() and friends fail? one memory leak is caused in DB_get() by test_recno, line 75 (d.get(100)). if the FREE_DBT()s at line 1392-1393 are moved outside the if, so they always execute the leak goes away. i'm not sure if this is really the correct solution though. the other leak is in test_compat, don't know anything more. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2004-06-14 18:47 Message: Logged In: YES user_id=413 Thanks, I hadn't caught up on python-dev in a while. What happens if you apply my attached patch and rerun the test under valgrind? The 4 bytes leaked sounds exactly like what i was expecting reading the code (an integer key causes make_key_dbt to alloc a 32bit value). in the DBC_set_range case without the patch i believe it is likely that the integer is allocated but the REALLOC flag is overridden in the old code with a MALLOC causing BerkeleyDB to leak the old pointer and allocate a new key for the return value (btree accessed using an integer key). 8 bytes in 2 blocks leaked in DB_get is double what i expected but without debug info showing the DB_get function call arguments and database flags its hard to say what happened. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2004-06-14 18:36 Message: Logged In: YES user_id=33168 I just run the regression tests. Did you see my mail to python-dev? http://mail.python.org/pipermail/python-dev/2004-June/045245.html Here's the bsddb leaks reported by valgrind: 4 bytes in 1 blocks are definitely lost in loss record 7 of 663 at 0x3C01DA1D: malloc (vg_replace_malloc.c:109) by 0x3C928265: make_key_dbt (_bsddb.c:400) by 0x3C92DE4F: DBC_set_range (_bsddb.c:2911) 8 bytes in 2 blocks are definitely lost in loss record 29 of 663 at 0x3C01DA1D: malloc (vg_replace_malloc.c:109) by 0x3C928265: make_key_dbt (_bsddb.c:400) by 0x3C929088: DB_get (_bsddb.c:1349) ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2004-06-14 17:02 Message: Logged In: YES user_id=413 make_key_dbt() will never return with an error leaving a FREE_DBT(key) necessary. however looking in depth at the code i believe it would have been possible to have a leak when using integer keys and exiting early with an error. a patch (untested) that should fix that is attached. i'll test it out later. do you have any memleak test cases by any chance? ---------------------------------------------------------------------- Comment By: alan johnson (chomo) Date: 2004-06-14 14:11 Message: Logged In: YES user_id=943591 looks like the ones needed anyway ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2004-06-13 13:56 Message: Logged In: YES user_id=33168 Greg, just wanted to make sure you saw this. It seems like you're the only one working on bsddb these days. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=967763&group_id=5470 From noreply at sourceforge.net Sun Jun 27 18:51:29 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jun 27 20:20:44 2004 Subject: [Patches] [ python-Patches-967763 ] fix bsddb memory leaks Message-ID: Patches item #967763, was opened at 2004-06-06 13:51 Message generated for change (Comment added) made by greg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=967763&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Gregory P. Smith (greg) Summary: fix bsddb memory leaks Initial Comment: only one of the changes fixed a leak reported by valgrind, but i think all the changes are necessary. ---------------------------------------------------------------------- >Comment By: Gregory P. Smith (greg) Date: 2004-06-27 15:51 Message: Logged In: YES user_id=413 DB_get and DBC_set_range were the two leaks that showed up in valgrind using the existing testsuite. however there were plenty more possible leak cases (most of them in odd situations like out of memory or passing a non DBTxn object in the txn parameter). The most common trigger for a leak in various places would be an exception exit from a many functions when using integer keys (queue & recno databases). I have a patch which i believe fixes all of these and more after a lot of code inspection that i'll commit once my valgrind run finishes and reveals no bsddb related leaks or double frees. (ugh running valgrind -v --leak-check=yes ./python Lib/bsddb/test/test_all.py on a 5 year old laptop is slow...) "manual memory management... how quaint." ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2004-06-15 18:48 Message: Logged In: YES user_id=33168 should FREE_DBT() be called clearTxn() and friends fail? one memory leak is caused in DB_get() by test_recno, line 75 (d.get(100)). if the FREE_DBT()s at line 1392-1393 are moved outside the if, so they always execute the leak goes away. i'm not sure if this is really the correct solution though. the other leak is in test_compat, don't know anything more. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2004-06-14 18:47 Message: Logged In: YES user_id=413 Thanks, I hadn't caught up on python-dev in a while. What happens if you apply my attached patch and rerun the test under valgrind? The 4 bytes leaked sounds exactly like what i was expecting reading the code (an integer key causes make_key_dbt to alloc a 32bit value). in the DBC_set_range case without the patch i believe it is likely that the integer is allocated but the REALLOC flag is overridden in the old code with a MALLOC causing BerkeleyDB to leak the old pointer and allocate a new key for the return value (btree accessed using an integer key). 8 bytes in 2 blocks leaked in DB_get is double what i expected but without debug info showing the DB_get function call arguments and database flags its hard to say what happened. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2004-06-14 18:36 Message: Logged In: YES user_id=33168 I just run the regression tests. Did you see my mail to python-dev? http://mail.python.org/pipermail/python-dev/2004-June/045245.html Here's the bsddb leaks reported by valgrind: 4 bytes in 1 blocks are definitely lost in loss record 7 of 663 at 0x3C01DA1D: malloc (vg_replace_malloc.c:109) by 0x3C928265: make_key_dbt (_bsddb.c:400) by 0x3C92DE4F: DBC_set_range (_bsddb.c:2911) 8 bytes in 2 blocks are definitely lost in loss record 29 of 663 at 0x3C01DA1D: malloc (vg_replace_malloc.c:109) by 0x3C928265: make_key_dbt (_bsddb.c:400) by 0x3C929088: DB_get (_bsddb.c:1349) ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2004-06-14 17:02 Message: Logged In: YES user_id=413 make_key_dbt() will never return with an error leaving a FREE_DBT(key) necessary. however looking in depth at the code i believe it would have been possible to have a leak when using integer keys and exiting early with an error. a patch (untested) that should fix that is attached. i'll test it out later. do you have any memleak test cases by any chance? ---------------------------------------------------------------------- Comment By: alan johnson (chomo) Date: 2004-06-14 14:11 Message: Logged In: YES user_id=943591 looks like the ones needed anyway ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2004-06-13 13:56 Message: Logged In: YES user_id=33168 Greg, just wanted to make sure you saw this. It seems like you're the only one working on bsddb these days. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=967763&group_id=5470 From noreply at sourceforge.net Mon Jun 28 05:41:30 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jun 28 05:44:15 2004 Subject: [Patches] [ python-Patches-980695 ] efficient string concatenation Message-ID: Patches item #980695, was opened at 2004-06-27 13:39 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=980695&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: efficient string concatenation Initial Comment: A wild idea that makes repeated string concatenations efficient without changing stringobject.c. If we assume we don't want to change the representation of strings, then the problem is that string_concat(v,w) doesn't know if v will soon released, so it cannot resize it in-place even if the refcnt is 1. But with some hacks ceval.c can know that. Statements like s=s+expr or s+=expr both compile to a BINARY_ADD or INPLACE_ADD followed by a STORE_FAST or STORE_NAME. So in the attached patch ceval.c special-cases addition of two strings (in the same way as it special-cases addition of two integers already). If moreover the addition is followed by a STORE that is about to overwrite the addition's left argument, and if the refcnt is right, then the left argument can be resized in-place (plus some obscure magic to ensure that everything is still valid even if resize moves the string in memory). With Python's good memory manager, repeated resizes even without manual over-allocation perform nicely. As a side effect, other constructions like a+b+c+d+e+f also work in-place now. The patch would do with a lot more comments. ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2004-06-28 09:41 Message: Logged In: YES user_id=4771 another patch with support for STORE_DEREF (thanks Phillip for pointing it out) ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-06-27 20:39 Message: Logged In: YES user_id=4771 resubmitted as a context diff. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=980695&group_id=5470 From noreply at sourceforge.net Mon Jun 28 07:38:09 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jun 28 07:38:17 2004 Subject: [Patches] [ python-Patches-980695 ] efficient string concatenation Message-ID: Patches item #980695, was opened at 2004-06-27 09:39 Message generated for change (Comment added) made by mcherm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=980695&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: efficient string concatenation Initial Comment: A wild idea that makes repeated string concatenations efficient without changing stringobject.c. If we assume we don't want to change the representation of strings, then the problem is that string_concat(v,w) doesn't know if v will soon released, so it cannot resize it in-place even if the refcnt is 1. But with some hacks ceval.c can know that. Statements like s=s+expr or s+=expr both compile to a BINARY_ADD or INPLACE_ADD followed by a STORE_FAST or STORE_NAME. So in the attached patch ceval.c special-cases addition of two strings (in the same way as it special-cases addition of two integers already). If moreover the addition is followed by a STORE that is about to overwrite the addition's left argument, and if the refcnt is right, then the left argument can be resized in-place (plus some obscure magic to ensure that everything is still valid even if resize moves the string in memory). With Python's good memory manager, repeated resizes even without manual over-allocation perform nicely. As a side effect, other constructions like a+b+c+d+e+f also work in-place now. The patch would do with a lot more comments. ---------------------------------------------------------------------- >Comment By: Michael Chermside (mcherm) Date: 2004-06-28 07:38 Message: Logged In: YES user_id=99874 Hmmm... Interesting. I kinda like it. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-06-28 05:41 Message: Logged In: YES user_id=4771 another patch with support for STORE_DEREF (thanks Phillip for pointing it out) ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-06-27 16:39 Message: Logged In: YES user_id=4771 resubmitted as a context diff. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=980695&group_id=5470 From noreply at sourceforge.net Mon Jun 28 18:06:52 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jun 28 18:07:04 2004 Subject: [Patches] [ python-Patches-979737 ] invalid submission Message-ID: Patches item #979737, was opened at 2004-06-25 08:41 Message generated for change (Comment added) made by jepler You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=979737&group_id=5470 Category: Parser/Compiler Group: Python 2.3 Status: Deleted Resolution: Invalid Priority: 5 Submitted By: Anthony Tuininga (atuining) Assigned to: Nobody/Anonymous (nobody) Summary: invalid submission Initial Comment: The following code will fail in both Python 2.3 and Python 2.4, raising a MemoryError exception, when run on any platform except Windows: compile("# -*- coding: mbcs -*-", "test.py", "exec") This has been reproduced on the following platforms: Linux x86 HP-UX Solaris Tru64 Unix I realize this is an invalid encoding but it would be nice if something other than MemoryError was raised! ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2004-06-28 17:06 Message: Logged In: YES user_id=2772 re-opened as bug report: http://python.org/sf/979739 ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-06-25 08:45 Message: Logged In: YES user_id=619560 Apologies for this -- I submitted this in the patch subsection when it should have been submitted in the bug subsection ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=979737&group_id=5470 From noreply at sourceforge.net Tue Jun 29 02:42:28 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jun 29 02:42:33 2004 Subject: [Patches] [ python-Patches-981773 ] crach link c++ extension by mingw Message-ID: Patches item #981773, was opened at 2004-06-29 13:42 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=981773&group_id=5470 Category: Distutils and setup.py Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alexandr Zamaraev (shura_zam) Assigned to: Nobody/Anonymous (nobody) Summary: crach link c++ extension by mingw Initial Comment: if cource of exttension module writen in C++ setup break and say: cc -mno-cygwin -shared -s build\temp.win32-2.3 \Release\dybaseapi.o build\temp.win32-2.3\Release\..\src\btree.o build\temp.win32-2.3\Release\..\src\database.o build\temp.win32-2.3\Release\..\src\dybase.o build\temp.win32-2.3\Release\..\src\file.o build\temp.win32-2.3\Release\..\src\pagepool.o build\temp.win32-2.3\Release\dybaseapi.def -LC:\Lang\Python23\libs -LC:\Lang\Python23\PCBuild -lpython23 -o build\lib.win32-2.3\dybaseapi.pyd error: command 'cc' failed: No such file or directory I patch cygwinccompiler.py for resolve: *** C:\Lang\Python23\work\Python-2.3.4 \Lib\distutils\cygwinccompiler.py Mon Apr 14 19:51:26 2003 --- C:\Lang\Python23\work\cygwinccompiler2.py Tue Jun 29 13:00:23 2004 *************** *** 108,113 **** --- 108,114 ---- # XXX optimization, warnings etc. should be customizable. self.set_executables(compiler='gcc -mcygwin -O - Wall', compiler_so='gcc -mcygwin - mdll -O -Wall', + compiler_cxx='g++ -mcygwin -O - Wall', linker_exe='gcc -mcygwin', linker_so=('%s -mcygwin %s' % (self.linker_dll, shared_option))) *************** *** 295,300 **** --- 296,302 ---- self.set_executables(compiler='gcc -mno- cygwin -O -Wall', compiler_so='gcc -mno-cygwin - mdll -O -Wall', + compiler_cxx='g++ -mno-cygwin - O -Wall', linker_exe='gcc -mno-cygwin', linker_so='%s -mno-cygwin %s % s' % (self.linker_dll, shared_option, ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=981773&group_id=5470 From noreply at sourceforge.net Tue Jun 29 03:35:50 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jun 29 03:35:57 2004 Subject: [Patches] [ python-Patches-981794 ] webbrower support for firebird / firefox Message-ID: Patches item #981794, was opened at 2004-06-29 07:35 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=981794&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Thenault Sylvain (syt) Assigned to: Nobody/Anonymous (nobody) Summary: webbrower support for firebird / firefox Initial Comment: this patch add detection of the mozilla firebird and firefox browser to the webbrowser module from the std lib ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=981794&group_id=5470 From sayaddison at cs.com Tue Jun 29 08:08:42 2004 From: sayaddison at cs.com (Ester Damron) Date: Tue Jun 29 08:01:25 2004 Subject: [Patches] Do you want to pleasure your par_tner every time? Message-ID: <20040629120842.67BC211E941@www.logitech-partner.com> An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20040629/da765d63/attachment.html From noreply at sourceforge.net Tue Jun 29 10:03:35 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jun 29 10:03:41 2004 Subject: [Patches] [ python-Patches-974633 ] Parser/acceler.c: PyObject_MALLOC return is not checked Message-ID: Patches item #974633, was opened at 2004-06-17 06:15 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=974633&group_id=5470 Category: Parser/Compiler >Group: Python 2.4 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Dima Dorfman (ddorfman) >Assigned to: A.M. Kuchling (akuchling) Summary: Parser/acceler.c: PyObject_MALLOC return is not checked Initial Comment: fixstate in Parser/acceler.c: The first call to PyObject_MALLOC doesn't check for it returning NULL. The attached patch does the fprintf/exit combo just like another call to malloc later in the function. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2004-06-29 10:03 Message: Logged In: YES user_id=11375 Patch applied to CVS; thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=974633&group_id=5470 From noreply at sourceforge.net Tue Jun 29 10:04:01 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jun 29 10:04:09 2004 Subject: [Patches] [ python-Patches-981794 ] webbrower support for firebird / firefox Message-ID: Patches item #981794, was opened at 2004-06-29 03:35 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=981794&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Thenault Sylvain (syt) Assigned to: Nobody/Anonymous (nobody) Summary: webbrower support for firebird / firefox Initial Comment: this patch add detection of the mozilla firebird and firefox browser to the webbrowser module from the std lib ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2004-06-29 10:04 Message: Logged In: YES user_id=11375 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. In addition, even if you *did* check this checkbox, a bug in SourceForge prevents attaching a file when *creating* an issue. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=981794&group_id=5470 From noreply at sourceforge.net Tue Jun 29 10:23:13 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jun 29 10:23:18 2004 Subject: [Patches] [ python-Patches-935454 ] sha256 module Message-ID: Patches item #935454, was opened at 2004-04-15 02:57 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=935454&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Trevor Perrin (trevp) Assigned to: Nobody/Anonymous (nobody) Summary: sha256 module Initial Comment: This module is a copy of shamodule.c, with the SHA-1 compression function replaced with the SHA-256 compression function (copied from the LibTomCrypt public-domain crypto library). SHA-256 is similar to SHA-1: it's a US Federal Standard hash algorithm (FIPS 180-2). The difference is that it produces a 256 bit hash value, instead of a 160 bit hash value. SHA-256 thus has 128 bits of resistance against birthday attacks, which makes it secure in certain protocols where SHA-1 is questionable (e.g. digital signatures; or RNGs or Key-Derivation Functions where you want to produce keys for 256-bit ciphers). There's other flavors of SHA, but they're not as useful: SHA-384 and SHA-512 are defined on 64-bit values, so are slow on 32-bit architectures. SHA-224 is just silly (it saves 32 bits over SHA-256; that's its sole rationale). ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2004-06-29 10:23 Message: Logged In: YES user_id=11375 I can't rule on whether the module should be added or not, so I'll bring it up on python-dev. Feel free to join the resulting thread. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=935454&group_id=5470 From noreply at sourceforge.net Tue Jun 29 10:25:38 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jun 29 10:25:43 2004 Subject: [Patches] [ python-Patches-981794 ] webbrower support for firebird / firefox Message-ID: Patches item #981794, was opened at 2004-06-29 07:35 Message generated for change (Comment added) made by syt You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=981794&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Thenault Sylvain (syt) Assigned to: Nobody/Anonymous (nobody) Summary: webbrower support for firebird / firefox Initial Comment: this patch add detection of the mozilla firebird and firefox browser to the webbrowser module from the std lib ---------------------------------------------------------------------- >Comment By: Thenault Sylvain (syt) Date: 2004-06-29 14:25 Message: Logged In: YES user_id=387525 with the patch attached... At least this time I've checked the checkbox. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2004-06-29 14:04 Message: Logged In: YES user_id=11375 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. In addition, even if you *did* check this checkbox, a bug in SourceForge prevents attaching a file when *creating* an issue. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=981794&group_id=5470 From noreply at sourceforge.net Tue Jun 29 12:06:59 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jun 29 12:07:05 2004 Subject: [Patches] [ python-Patches-980082 ] Missing INCREF in PyType_Ready Message-ID: Patches item #980082, was opened at 2004-06-26 01:37 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=980082&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Eric Huss (ehuss) Assigned to: Nobody/Anonymous (nobody) Summary: Missing INCREF in PyType_Ready Initial Comment: In PyType_Ready() if the type object you are readying does not explicitly define its tp_base value, it will default to use PyBaseObject_Type. However, this assignment does not INCREF the PyBaseObject_Type pointer. Thus, for heap allocated type objects, when the type_dealloc() function is called, a DECREF is called on tp_base which can eventually cause PyBaseObject_Type refcount go to 0, at which point bad things happen. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2004-06-29 17:06 Message: Logged In: YES user_id=6656 I'm not sure this is actually a real problem. I don't think you can get into the "base == NULL" case with a heap type... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=980082&group_id=5470 From noreply at sourceforge.net Tue Jun 29 14:39:27 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jun 29 14:39:38 2004 Subject: [Patches] [ python-Patches-980082 ] Missing INCREF in PyType_Ready Message-ID: Patches item #980082, was opened at 2004-06-25 17:37 Message generated for change (Comment added) made by ehuss You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=980082&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Eric Huss (ehuss) Assigned to: Nobody/Anonymous (nobody) Summary: Missing INCREF in PyType_Ready Initial Comment: In PyType_Ready() if the type object you are readying does not explicitly define its tp_base value, it will default to use PyBaseObject_Type. However, this assignment does not INCREF the PyBaseObject_Type pointer. Thus, for heap allocated type objects, when the type_dealloc() function is called, a DECREF is called on tp_base which can eventually cause PyBaseObject_Type refcount go to 0, at which point bad things happen. ---------------------------------------------------------------------- >Comment By: Eric Huss (ehuss) Date: 2004-06-29 11:39 Message: Logged In: YES user_id=393416 There are relatively few ways to make a heap allocated type object. I have made a method to create structseq type objects on the heap (see sf patch 980098). There doesn't appear to be a direct API to do it, so I did it manually. Since the Type_Ready code has a check for NULL bases, one might as well take advantage of it. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-29 09:06 Message: Logged In: YES user_id=6656 I'm not sure this is actually a real problem. I don't think you can get into the "base == NULL" case with a heap type... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=980082&group_id=5470 From noreply at sourceforge.net Tue Jun 29 20:20:03 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jun 29 20:20:08 2004 Subject: [Patches] [ python-Patches-982340 ] applesingle endianness issue Message-ID: Patches item #982340, was opened at 2004-06-29 20:20 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=982340&group_id=5470 Category: Macintosh Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Bob Ippolito (etrepum) Assigned to: Jack Jansen (jackjansen) Summary: applesingle endianness issue Initial Comment: the struct formats in applesingle.py do not declare endianness and thus won't work on little endian architectures. This patch adds the endian declarations to the struct formats. (from http://www.opensource.apple.com/darwinsource/ WWDC2004/) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=982340&group_id=5470 From noreply at sourceforge.net Wed Jun 30 05:07:17 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jun 30 05:07:22 2004 Subject: [Patches] [ python-Patches-957240 ] Patch for feature request 491033 Message-ID: Patches item #957240, was opened at 2004-05-20 07:23 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=957240&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Josiah Carlson (josiahcarlson) >Assigned to: Michael Hudson (mwh) Summary: Patch for feature request 491033 Initial Comment: The attached patch is to offer the functionality desired by feature request: python.org/sf/491033 On machines that use standard IEEE floating point doubles, the 'infinity' needs only to be 1e16 due to the limited precision of floating point. 1e309 is used for convenience sake, and will continue to be a precision infinity until 1024 bits of precision in floating point values is available. At such point in time where 1e309 is available in hardware, it will still sufficient due to the practical limitations of counting. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2004-06-30 10:07 Message: Logged In: YES user_id=6656 Checked in the new version as Lib/asyncore.py revision 1.53 Doc/lib/libasyncore.tex revision 1.17 Misc/NEWS revision 1.1015 Thanks! ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-15 11:47 Message: Logged In: YES user_id=6656 This is the patch I was trying to say was much better :-) ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-06-14 16:37 Message: Logged In: YES user_id=341410 There is an attached patch that uses None. I ran the standard tests twice, and it does not fail when asyncore.pyc exists (5 tests should suffice). ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-06-14 16:16 Message: Logged In: YES user_id=341410 Y ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-06-14 05:59 Message: Logged In: YES user_id=21627 I have backed out the patch in libasyncore.tex 1.16 asyncore.py 1.52 NEWS 1.1001 ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-12 09:53 Message: Logged In: YES user_id=6656 um, "yes". what's in CVS currently is not going to be there for very long. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-06-11 22:54 Message: Logged In: YES user_id=341410 If it would be preferred, I have an alternate patch against 1.50 from CVS that uses None instead of floating point infinity. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-11 17:31 Message: Logged In: YES user_id=6656 This patch should not have been accepted. Relying on a floating point infinity to marhsal/unmarshal correctly is a bad idea. With the aid of the LC_NUMERIC agnostism patch, this patch breaks test_asynchat *when asyncore.pyc exists*. I don't have a windows machine with a CVS HEAD Python to check, but if 2.3 behaviour is retained, the upshot is that the count parameter will default to *1* if the code is loaded from a .pyc file. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-06-03 10:19 Message: Logged In: YES user_id=21627 Thanks for the patch. Applied as libasyncore.tex 1.15 asyncore.py 1.51 NEWS 1.986 ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-05-31 21:36 Message: Logged In: YES user_id=341410 The attached patch includes both a documentation patch, as well as a modified loop patch to explicitly match the documentation. The patches are concatenated and in standard context diff format (as per the Python patch submission guidelines, sorry about the previous unified diff). The test suite does not seem to contain tests for asyncore. It does contain a test for asynchat, which will be unaffected by this patch. One thing to note: the use of 'count = count - 1' rather than 'count -= 1' is to remove potential bugs in the case where a mutable number-like object with a modifying __isub__ method were to be passed by a user. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-05-31 19:32 Message: Logged In: YES user_id=21627 This patch lacks changes to the documentation and the test suite. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-05-20 07:26 Message: Logged In: YES user_id=341410 Sorry about that, I generated the patch by hand and got the ordering messed up. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=957240&group_id=5470 From noreply at sourceforge.net Wed Jun 30 06:54:38 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jun 30 06:54:42 2004 Subject: [Patches] [ python-Patches-982665 ] add SO_EXCLUSIVEADDRUSE constant in socketmodule.c Message-ID: Patches item #982665, was opened at 2004-06-30 10:54 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=982665&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Garth Bushell (garth42) Assigned to: Nobody/Anonymous (nobody) Summary: add SO_EXCLUSIVEADDRUSE constant in socketmodule.c Initial Comment: SO_REUSEADDR is has different meaning on windows to most socket implementations. It alows multiple programs to bind to the same address/port. This can cause very wierd bugs if two programs are used at the same time. (see http://www.itamarst.org/writings/win32sockets.html) Adding SO_EXCLUSIVEADDRUSE constant allows windows programmers to have the same semantics as unix ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=982665&group_id=5470 From noreply at sourceforge.net Wed Jun 30 06:55:35 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jun 30 06:55:43 2004 Subject: [Patches] [ python-Patches-982665 ] add SO_EXCLUSIVEADDRUSE constant in socketmodule.c Message-ID: Patches item #982665, was opened at 2004-06-30 10:54 Message generated for change (Comment added) made by garth42 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=982665&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Garth Bushell (garth42) Assigned to: Nobody/Anonymous (nobody) Summary: add SO_EXCLUSIVEADDRUSE constant in socketmodule.c Initial Comment: SO_REUSEADDR is has different meaning on windows to most socket implementations. It alows multiple programs to bind to the same address/port. This can cause very wierd bugs if two programs are used at the same time. (see http://www.itamarst.org/writings/win32sockets.html) Adding SO_EXCLUSIVEADDRUSE constant allows windows programmers to have the same semantics as unix ---------------------------------------------------------------------- Comment By: Garth Bushell (garth42) Date: 2004-06-30 10:55 Message: Logged In: YES user_id=45280 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. In addition, even if you *did* check this checkbox, a bug in SourceForge prevents attaching a file when *creating* an issue. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=982665&group_id=5470 From noreply at sourceforge.net Wed Jun 30 07:14:00 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jun 30 07:14:04 2004 Subject: [Patches] [ python-Patches-982681 ] asyncore.dispatcher.set_reuse_addr() is broken on windows Message-ID: Patches item #982681, was opened at 2004-06-30 11:14 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=982681&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Garth Bushell (garth42) Assigned to: Nobody/Anonymous (nobody) Summary: asyncore.dispatcher.set_reuse_addr() is broken on windows Initial Comment: asyncore.dispatcher.set_reuse_addr() uses socket.SO_REUSEADDR to allow reuse of same address without having to wait. On windows this also allows multiple programs to bind to the same socket adress. What is probably needed is to use SO_EXCLUSIVEADDRUSE on windows which has the same meaning as SO_REUSEADDR on all other platforms. This will stop people running the server multiple times and getting wierd results or two programs sharing the same port without realising. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=982681&group_id=5470 From noreply at sourceforge.net Wed Jun 30 07:14:58 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jun 30 07:15:02 2004 Subject: [Patches] [ python-Patches-982681 ] asyncore.dispatcher.set_reuse_addr() is broken on windows Message-ID: Patches item #982681, was opened at 2004-06-30 11:14 Message generated for change (Comment added) made by garth42 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=982681&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Garth Bushell (garth42) Assigned to: Nobody/Anonymous (nobody) Summary: asyncore.dispatcher.set_reuse_addr() is broken on windows Initial Comment: asyncore.dispatcher.set_reuse_addr() uses socket.SO_REUSEADDR to allow reuse of same address without having to wait. On windows this also allows multiple programs to bind to the same socket adress. What is probably needed is to use SO_EXCLUSIVEADDRUSE on windows which has the same meaning as SO_REUSEADDR on all other platforms. This will stop people running the server multiple times and getting wierd results or two programs sharing the same port without realising. ---------------------------------------------------------------------- >Comment By: Garth Bushell (garth42) Date: 2004-06-30 11:14 Message: Logged In: YES user_id=45280 this depends on patch #982665 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=982681&group_id=5470 From noreply at sourceforge.net Wed Jun 30 07:17:27 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jun 30 07:17:33 2004 Subject: [Patches] [ python-Patches-960406 ] unblock signals in threads Message-ID: Patches item #960406, was opened at 2004-05-25 22:00 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=960406&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: Andrew Langmead (langmead) Assigned to: Michael Hudson (mwh) Summary: unblock signals in threads Initial Comment: This is a patch which will correct the issues some people have with python's handling of signal handling in threads. It allows any thread to initially catch the signal mark it as triggered, allowing the main thread to later process it. (This is actually just restoring access to the functionality that was in Python 2.1) The special SIGINT handling for the python readline module has been changed so that it can now see an EINTR error code, rather than needing a longjmp out of the readline library itself. If the readline library python is being linked to doesn't have the callback features necessary, it will fall back to its old behavior. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2004-06-30 12:17 Message: Logged In: YES user_id=6656 Ah hell, my current patch makes insane things happen when you do something like: >>> thread.start_new_thread(raw_input, ('a',)); time.sleep(1) Gah. Maybe we should just try to ban calling into readline from a non-main thread; that seems a bit draconian, though. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-06-23 06:00 Message: Logged In: YES user_id=29957 At this point, worry about getting it working at all for 2.4, _then_ we can worry about trying to backport it to 2.3. If it turns out that we can't fix it for 2.3.5, so be it... I'd much rather see this fixed correctly in 2.4 and not at all in 2.3.5 than seeing a broken hacky fix in both 2.3.5 and 2.4. This code is already unpleasant enough. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2004-06-23 05:41 Message: Logged In: YES user_id=6380 If there's no frame when PyOS_Readline() handles the signal immediately, why would there be a frame when the user hits return? IOW I don't think it would be a big deal to change that behavior. Semantics that are a trifle (or even completely) accidental are nevertheless worth preserving in a bugfix release, otherwise compatibility could be at risk. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-22 10:02 Message: Logged In: YES user_id=6656 > What else did you want from me? Not a lot more than that :-) The only other point you might have an opinion (aka. a bit of current behaviour that I don't understand ;-) is that in current Python, a signal delivered while sitting in a call to PyOS_Readline() is not handled (at the Python level) until the user presses return (or ^C? hmm, not sure about that) whereas with this patch, it is handled more-or-less immediately. This means that the second argument to the Python signal handler will be None, rather than a frame object: there's no Python execution happening at this point, after all. Does this sound reasonable to you? > For 2.3, keeping whatever semantics ^C from readline > has at the moment should be preserved Certainly, in principle at least! However "whatever semantics ^C from readline has at the moment" are a trifle accidental... I need to think about this. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2004-06-22 03:59 Message: Logged In: YES user_id=6380 Ideally, ^C should always cause the signal handler for SIGINT to be called, and the KeyboardInterrupt should be generated by the default SIGINT handler. For 2.3, keeping whatever semantics ^C from readline has at the moment should be preserved -- we only want bugfixes, not new features... What else did you want from me? (I'm also lacking focus, or at least time to think about this stuff in detail.) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-19 11:14 Message: Logged In: YES user_id=6656 Yes, I think you're right. I guess I'm suffering a lack of focus, finding it hard to resist the impulse to fix what look like ancient bogosities in the area while I'm there... (also see the way a NULL return from PyOS_Readline is assumed to be a keyboard interrupt). One could argue that ^C should always interrupt an interactive session, but one could also argue that users shouldn't be so daft as to install handlers for SIGINT if they want that to be true (after all, they can make life hard for themselves if they want with stty(1)). A downside to all this footling is that it makes a backport to 2.3 harder to justify. Hmm. I wander what Guido thinnks (he's alledgedly "now maintaining" Modules/readline.c :-). ---------------------------------------------------------------------- Comment By: Andrew Langmead (langmead) Date: 2004-06-19 04:04 Message: Logged In: YES user_id=119306 I'm not sure if the current behavior should be maintained or not, but it looks like to me that the readline module has always generated a KeyboardInterrupt, regardless of whether SIGINT has been overridden. This is a bit odd though. It causes the SIGINT handling to change depending on whether or not you are at the top level interpreter's prompt. wantarray% cat /tmp/foo.py import signal def foo(sig, frame): print "caught foo" signal.signal(signal.SIGINT, foo) wantarray% python -i /tmp/foo.py >>> foo >>> ^C KeyboardInterrupt >>> while 1: ... pass ... ^Ccaught foo ^Ccaught foo ^Ccaught foo ^Ccaught foo ^\zsh: quit python -i /tmp/foo.py ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-18 13:54 Message: Logged In: YES user_id=6656 The problem with that approach is: what if you want a handler for SIGINT that doesn't raise KeyboardInterrupt? Other than that, it sounds like your plan should work. I've attached a slightly cleaned up version of my patch which makes signal handling in the "without readline" case more like yesterday's patch made the "with readline" case. ---------------------------------------------------------------------- Comment By: Andrew Langmead (langmead) Date: 2004-06-18 03:35 Message: Logged In: YES user_id=119306 Here is another possible approach to solving the problem of readline exiting for signals other than SIGINT. I'm not sure if it is better or worse than the scarypatch. As you said, the call to readline is performed without the GIL. So is the actual C-level signal handler from the signal module (the python code that gets associated with the signal is deferred until later.) At the time we see the EINTR, there is a flag in the signal module's Handler array to say whether the signal that we received was a SIGINT. If we added some sort of interface within the signal module to find out what signals are pending to be run on the next call to PyErr_CheckSignals, then we could find out if the EINTR was caused by an INT (at which point we should exit) or by another signal (at which we could just retry the select.) Is there any potential to this approach? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-17 18:25 Message: Logged In: YES user_id=6656 BTW, I'd really really like someone to review this :-) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-17 18:24 Message: Logged In: YES user_id=6656 How about the attached? It's a bit ... scary. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-17 17:08 Message: Logged In: YES user_id=6656 A potential problem with this patch is that it causes input to be interrupted (with a KeyboardInterrupt exception) when any handled signal is delivered. This seems suboptimal. It's appealing to try to run the (Python) signal handlers in the errno == EINTR case of readline_line_until_enter_or_signal, but that has problems in that PyOS_ReadlineFunctionPointer is called without the GIL being held and once that is dealt with, an installed Python signal handler attempting to call readline at this point can reasonably be expected to result in all hell breaking loose. I don't know what the correct solution is here. Add our own rentrancy checks and learn how to work the Python threadstate API properly? Thoughts, anyone? Or have I scared everyone away now? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-12 11:17 Message: Logged In: YES user_id=6656 Now a rewrite of the test that actually works! ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-12 11:08 Message: Logged In: YES user_id=6656 Here's a version of the patch that includes the new unit test (oops!) which I've rewritten slightly. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-06-11 17:02 Message: Logged In: YES user_id=29957 No - wait. Ignore that test_timeout error, it exists with a clean checkout. The inability to interrupt make testall, however is new with this patch. Linux Fedora Core 2. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-06-11 16:58 Message: Logged In: YES user_id=29957 With this patch: bonanza% ./python Lib/test/test_timeout.py testBlockingThenTimeout (__main__.CreationTestCase) ... ok testFloatReturnValue (__main__.CreationTestCase) ... ok testObjectCreation (__main__.CreationTestCase) ... ok testRangeCheck (__main__.CreationTestCase) ... ok testReturnType (__main__.CreationTestCase) ... ok testTimeoutThenBlocking (__main__.CreationTestCase) ... ok testTypeCheck (__main__.CreationTestCase) ... ok testAcceptTimeout (__main__.TimeoutTestCase) ... ok testConnectTimeout (__main__.TimeoutTestCase) ... FAIL testRecvTimeout (__main__.TimeoutTestCase) ... ok testRecvfromTimeout (__main__.TimeoutTestCase) ... ok testSend (__main__.TimeoutTestCase) ... ok testSendall (__main__.TimeoutTestCase) ... ok testSendto (__main__.TimeoutTestCase) ... ok ====================================================================== FAIL: testConnectTimeout (__main__.TimeoutTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "Lib/test/test_timeout.py", line 121, in testConnectTimeout "timeout (%g) is more than %g seconds more than expected (%g)" AssertionError: timeout (4.48679) is more than 2 seconds more than expected (0.001) ---------------------------------------------------------------------- Ran 14 tests in 17.445s FAILED (failures=1) Traceback (most recent call last): File "Lib/test/test_timeout.py", line 192, in ? test_main() File "Lib/test/test_timeout.py", line 189, in test_main test_support.run_unittest(CreationTestCase, TimeoutTestCase) File "/home/anthony/src/py/pyhead/dist/src/Lib/test/test_support.py", line 290, in run_unittest run_suite(suite, testclass) File "/home/anthony/src/py/pyhead/dist/src/Lib/test/test_support.py", line 275, in run_suite raise TestFailed(err) test.test_support.TestFailed: Traceback (most recent call last): File "Lib/test/test_timeout.py", line 121, in testConnectTimeout "timeout (%g) is more than %g seconds more than expected (%g)" AssertionError: timeout (4.48679) is more than 2 seconds more than expected (0.001) Also, with this patch applied, I can no longer kill a 'make testall' with a ^C ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-11 15:18 Message: Logged In: YES user_id=6656 The patch didn't apply, so I've updated it (attached). I see test_asynchat fail occasionally now, but don't know if that's because of this patch :-( Once I've sorted that out in my head, I think I'm going to check this in. ---------------------------------------------------------------------- Comment By: Andrew Langmead (langmead) Date: 2004-05-29 06:49 Message: Logged In: YES user_id=119306 Here is a reformatted version of the patch. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-05-28 15:25 Message: Logged In: YES user_id=31435 I agree that "busy" always should have been volatile -- once again, good eye! Python C style is basically K&R Classic, hard tab for indentation, open curly at the end of the line opening a block except for first line of function definition. Just make it look like the other C code, but be careful to pick one of the .c files Guido approves of . ---------------------------------------------------------------------- Comment By: Andrew Langmead (langmead) Date: 2004-05-28 13:37 Message: Logged In: YES user_id=119306 Thank you for pointing me to PEP 7. I'll take a look at where I am amiss and fix it up. For the change in ceval.c, I took a look at gcc's x86 assembly output of the file, and noticed that the optimizer was altering the order of the busy flag test. Since busy is set from other concurrent execution (other signal handlers), changing the variable to volatile told gcc not to optimize accesses to the variable. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-28 09:54 Message: Logged In: YES user_id=6656 I haven't been able to test on MacOS X further, unfortunately. The patch works on linux/x86 though (after fixing the TabError :-) but this is with an NTPL kernel, so I didn't have a problem anyway. The C doesn't all conform to the Python style -- see PEP 7. Can you fix that? Why the change to Python/ceval.c? After all that -- thanks a lot! I really want to get this checked in ASAP so we can find out which platforms it breaks at the earliest point in the 2.4 cycle. ---------------------------------------------------------------------- Comment By: Andrew Langmead (langmead) Date: 2004-05-27 07:04 Message: Logged In: YES user_id=119306 It seems that at least OS X, sending the kill to the process schedules that the receiving process will run the signal handler at some later time. (it seems to be the only one to frequently run the signal handlers in the opposite order than they were sent) This revised version of the test seems to work better on OS X. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-26 19:41 Message: Logged In: YES user_id=6656 test_threadsignals hangs for me on OS X. Haven't done anything more thorough than that yet... ---------------------------------------------------------------------- Comment By: Andrew Langmead (langmead) Date: 2004-05-26 18:48 Message: Logged In: YES user_id=119306 I apologize that the missing patch. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-26 18:22 Message: Logged In: YES user_id=6656 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. In addition, even if you *did* check this checkbox, a bug in SourceForge prevents attaching a file when *creating* an issue. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=960406&group_id=5470 From noreply at sourceforge.net Wed Jun 30 07:29:38 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jun 30 07:29:45 2004 Subject: [Patches] [ python-Patches-960406 ] unblock signals in threads Message-ID: Patches item #960406, was opened at 2004-05-25 22:00 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=960406&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: Andrew Langmead (langmead) Assigned to: Michael Hudson (mwh) Summary: unblock signals in threads Initial Comment: This is a patch which will correct the issues some people have with python's handling of signal handling in threads. It allows any thread to initially catch the signal mark it as triggered, allowing the main thread to later process it. (This is actually just restoring access to the functionality that was in Python 2.1) The special SIGINT handling for the python readline module has been changed so that it can now see an EINTR error code, rather than needing a longjmp out of the readline library itself. If the readline library python is being linked to doesn't have the callback features necessary, it will fall back to its old behavior. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2004-06-30 12:29 Message: Logged In: YES user_id=6656 Dammit all: pressing ^C when in ''interactive search mode" also appears to fail to do the Right Thing. Is this a readline bug? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-30 12:17 Message: Logged In: YES user_id=6656 Ah hell, my current patch makes insane things happen when you do something like: >>> thread.start_new_thread(raw_input, ('a',)); time.sleep(1) Gah. Maybe we should just try to ban calling into readline from a non-main thread; that seems a bit draconian, though. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-06-23 06:00 Message: Logged In: YES user_id=29957 At this point, worry about getting it working at all for 2.4, _then_ we can worry about trying to backport it to 2.3. If it turns out that we can't fix it for 2.3.5, so be it... I'd much rather see this fixed correctly in 2.4 and not at all in 2.3.5 than seeing a broken hacky fix in both 2.3.5 and 2.4. This code is already unpleasant enough. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2004-06-23 05:41 Message: Logged In: YES user_id=6380 If there's no frame when PyOS_Readline() handles the signal immediately, why would there be a frame when the user hits return? IOW I don't think it would be a big deal to change that behavior. Semantics that are a trifle (or even completely) accidental are nevertheless worth preserving in a bugfix release, otherwise compatibility could be at risk. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-22 10:02 Message: Logged In: YES user_id=6656 > What else did you want from me? Not a lot more than that :-) The only other point you might have an opinion (aka. a bit of current behaviour that I don't understand ;-) is that in current Python, a signal delivered while sitting in a call to PyOS_Readline() is not handled (at the Python level) until the user presses return (or ^C? hmm, not sure about that) whereas with this patch, it is handled more-or-less immediately. This means that the second argument to the Python signal handler will be None, rather than a frame object: there's no Python execution happening at this point, after all. Does this sound reasonable to you? > For 2.3, keeping whatever semantics ^C from readline > has at the moment should be preserved Certainly, in principle at least! However "whatever semantics ^C from readline has at the moment" are a trifle accidental... I need to think about this. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2004-06-22 03:59 Message: Logged In: YES user_id=6380 Ideally, ^C should always cause the signal handler for SIGINT to be called, and the KeyboardInterrupt should be generated by the default SIGINT handler. For 2.3, keeping whatever semantics ^C from readline has at the moment should be preserved -- we only want bugfixes, not new features... What else did you want from me? (I'm also lacking focus, or at least time to think about this stuff in detail.) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-19 11:14 Message: Logged In: YES user_id=6656 Yes, I think you're right. I guess I'm suffering a lack of focus, finding it hard to resist the impulse to fix what look like ancient bogosities in the area while I'm there... (also see the way a NULL return from PyOS_Readline is assumed to be a keyboard interrupt). One could argue that ^C should always interrupt an interactive session, but one could also argue that users shouldn't be so daft as to install handlers for SIGINT if they want that to be true (after all, they can make life hard for themselves if they want with stty(1)). A downside to all this footling is that it makes a backport to 2.3 harder to justify. Hmm. I wander what Guido thinnks (he's alledgedly "now maintaining" Modules/readline.c :-). ---------------------------------------------------------------------- Comment By: Andrew Langmead (langmead) Date: 2004-06-19 04:04 Message: Logged In: YES user_id=119306 I'm not sure if the current behavior should be maintained or not, but it looks like to me that the readline module has always generated a KeyboardInterrupt, regardless of whether SIGINT has been overridden. This is a bit odd though. It causes the SIGINT handling to change depending on whether or not you are at the top level interpreter's prompt. wantarray% cat /tmp/foo.py import signal def foo(sig, frame): print "caught foo" signal.signal(signal.SIGINT, foo) wantarray% python -i /tmp/foo.py >>> foo >>> ^C KeyboardInterrupt >>> while 1: ... pass ... ^Ccaught foo ^Ccaught foo ^Ccaught foo ^Ccaught foo ^\zsh: quit python -i /tmp/foo.py ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-18 13:54 Message: Logged In: YES user_id=6656 The problem with that approach is: what if you want a handler for SIGINT that doesn't raise KeyboardInterrupt? Other than that, it sounds like your plan should work. I've attached a slightly cleaned up version of my patch which makes signal handling in the "without readline" case more like yesterday's patch made the "with readline" case. ---------------------------------------------------------------------- Comment By: Andrew Langmead (langmead) Date: 2004-06-18 03:35 Message: Logged In: YES user_id=119306 Here is another possible approach to solving the problem of readline exiting for signals other than SIGINT. I'm not sure if it is better or worse than the scarypatch. As you said, the call to readline is performed without the GIL. So is the actual C-level signal handler from the signal module (the python code that gets associated with the signal is deferred until later.) At the time we see the EINTR, there is a flag in the signal module's Handler array to say whether the signal that we received was a SIGINT. If we added some sort of interface within the signal module to find out what signals are pending to be run on the next call to PyErr_CheckSignals, then we could find out if the EINTR was caused by an INT (at which point we should exit) or by another signal (at which we could just retry the select.) Is there any potential to this approach? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-17 18:25 Message: Logged In: YES user_id=6656 BTW, I'd really really like someone to review this :-) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-17 18:24 Message: Logged In: YES user_id=6656 How about the attached? It's a bit ... scary. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-17 17:08 Message: Logged In: YES user_id=6656 A potential problem with this patch is that it causes input to be interrupted (with a KeyboardInterrupt exception) when any handled signal is delivered. This seems suboptimal. It's appealing to try to run the (Python) signal handlers in the errno == EINTR case of readline_line_until_enter_or_signal, but that has problems in that PyOS_ReadlineFunctionPointer is called without the GIL being held and once that is dealt with, an installed Python signal handler attempting to call readline at this point can reasonably be expected to result in all hell breaking loose. I don't know what the correct solution is here. Add our own rentrancy checks and learn how to work the Python threadstate API properly? Thoughts, anyone? Or have I scared everyone away now? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-12 11:17 Message: Logged In: YES user_id=6656 Now a rewrite of the test that actually works! ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-12 11:08 Message: Logged In: YES user_id=6656 Here's a version of the patch that includes the new unit test (oops!) which I've rewritten slightly. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-06-11 17:02 Message: Logged In: YES user_id=29957 No - wait. Ignore that test_timeout error, it exists with a clean checkout. The inability to interrupt make testall, however is new with this patch. Linux Fedora Core 2. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-06-11 16:58 Message: Logged In: YES user_id=29957 With this patch: bonanza% ./python Lib/test/test_timeout.py testBlockingThenTimeout (__main__.CreationTestCase) ... ok testFloatReturnValue (__main__.CreationTestCase) ... ok testObjectCreation (__main__.CreationTestCase) ... ok testRangeCheck (__main__.CreationTestCase) ... ok testReturnType (__main__.CreationTestCase) ... ok testTimeoutThenBlocking (__main__.CreationTestCase) ... ok testTypeCheck (__main__.CreationTestCase) ... ok testAcceptTimeout (__main__.TimeoutTestCase) ... ok testConnectTimeout (__main__.TimeoutTestCase) ... FAIL testRecvTimeout (__main__.TimeoutTestCase) ... ok testRecvfromTimeout (__main__.TimeoutTestCase) ... ok testSend (__main__.TimeoutTestCase) ... ok testSendall (__main__.TimeoutTestCase) ... ok testSendto (__main__.TimeoutTestCase) ... ok ====================================================================== FAIL: testConnectTimeout (__main__.TimeoutTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "Lib/test/test_timeout.py", line 121, in testConnectTimeout "timeout (%g) is more than %g seconds more than expected (%g)" AssertionError: timeout (4.48679) is more than 2 seconds more than expected (0.001) ---------------------------------------------------------------------- Ran 14 tests in 17.445s FAILED (failures=1) Traceback (most recent call last): File "Lib/test/test_timeout.py", line 192, in ? test_main() File "Lib/test/test_timeout.py", line 189, in test_main test_support.run_unittest(CreationTestCase, TimeoutTestCase) File "/home/anthony/src/py/pyhead/dist/src/Lib/test/test_support.py", line 290, in run_unittest run_suite(suite, testclass) File "/home/anthony/src/py/pyhead/dist/src/Lib/test/test_support.py", line 275, in run_suite raise TestFailed(err) test.test_support.TestFailed: Traceback (most recent call last): File "Lib/test/test_timeout.py", line 121, in testConnectTimeout "timeout (%g) is more than %g seconds more than expected (%g)" AssertionError: timeout (4.48679) is more than 2 seconds more than expected (0.001) Also, with this patch applied, I can no longer kill a 'make testall' with a ^C ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-11 15:18 Message: Logged In: YES user_id=6656 The patch didn't apply, so I've updated it (attached). I see test_asynchat fail occasionally now, but don't know if that's because of this patch :-( Once I've sorted that out in my head, I think I'm going to check this in. ---------------------------------------------------------------------- Comment By: Andrew Langmead (langmead) Date: 2004-05-29 06:49 Message: Logged In: YES user_id=119306 Here is a reformatted version of the patch. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-05-28 15:25 Message: Logged In: YES user_id=31435 I agree that "busy" always should have been volatile -- once again, good eye! Python C style is basically K&R Classic, hard tab for indentation, open curly at the end of the line opening a block except for first line of function definition. Just make it look like the other C code, but be careful to pick one of the .c files Guido approves of . ---------------------------------------------------------------------- Comment By: Andrew Langmead (langmead) Date: 2004-05-28 13:37 Message: Logged In: YES user_id=119306 Thank you for pointing me to PEP 7. I'll take a look at where I am amiss and fix it up. For the change in ceval.c, I took a look at gcc's x86 assembly output of the file, and noticed that the optimizer was altering the order of the busy flag test. Since busy is set from other concurrent execution (other signal handlers), changing the variable to volatile told gcc not to optimize accesses to the variable. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-28 09:54 Message: Logged In: YES user_id=6656 I haven't been able to test on MacOS X further, unfortunately. The patch works on linux/x86 though (after fixing the TabError :-) but this is with an NTPL kernel, so I didn't have a problem anyway. The C doesn't all conform to the Python style -- see PEP 7. Can you fix that? Why the change to Python/ceval.c? After all that -- thanks a lot! I really want to get this checked in ASAP so we can find out which platforms it breaks at the earliest point in the 2.4 cycle. ---------------------------------------------------------------------- Comment By: Andrew Langmead (langmead) Date: 2004-05-27 07:04 Message: Logged In: YES user_id=119306 It seems that at least OS X, sending the kill to the process schedules that the receiving process will run the signal handler at some later time. (it seems to be the only one to frequently run the signal handlers in the opposite order than they were sent) This revised version of the test seems to work better on OS X. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-26 19:41 Message: Logged In: YES user_id=6656 test_threadsignals hangs for me on OS X. Haven't done anything more thorough than that yet... ---------------------------------------------------------------------- Comment By: Andrew Langmead (langmead) Date: 2004-05-26 18:48 Message: Logged In: YES user_id=119306 I apologize that the missing patch. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-26 18:22 Message: Logged In: YES user_id=6656 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. In addition, even if you *did* check this checkbox, a bug in SourceForge prevents attaching a file when *creating* an issue. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=960406&group_id=5470 From noreply at sourceforge.net Wed Jun 30 17:04:51 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jun 30 17:04:54 2004 Subject: [Patches] [ python-Patches-983019 ] Making weakref.ref subclassable Message-ID: Patches item #983019, was opened at 2004-06-30 17:04 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=983019&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Nobody/Anonymous (nobody) Summary: Making weakref.ref subclassable Initial Comment: This patch makes weak references subclassable. This includes the following changes: - weakref.ref and weakref.ReferenceType will become aliases for each other - weakref.ref will be a modern, new-style class with proper __new__ and __init__ methods - weakref.WeakValueDictionary will have a lighter memory footprint, using a new weakref.ref subclass to associate the key with the value, allowing us to have only a single object of overhead for each dictionary entry (currently, there are 3 objects of overhead per entry: a weakref to the value, a weakref to the dictionary, and a function object used as a weakref callback; the weakref to the dictionary could be avoided without this change) - a new macro, PyWeakref_CheckRefExact(), will be added - PyWeakref_CheckRef() will check for subclasses of weakref.ref - the cyclic garbage detector will be affected by the change to PyWeakref_CheckRef(); it will potentially call issubtype() for objects in the unreachable list that do not have finalizers (in the move_troublemakers() function). This should only happen for weakref objects which are not of one of the "standard" three types (ref, proxy, and callable proxy). For debug builds, it will also affect assertions in the clear_weakerfs() and release_weakrefs() functions. The change to the cyclic garbage detector probably carries the most risk, and that only because the potential for a performance penalty. Running the Zope 3 test suite did not show any clear change in performance, and a key subsystem in Zope (zope.interface) uses weakrefs extensively. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=983019&group_id=5470 From noreply at sourceforge.net Wed Jun 30 23:26:26 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jun 30 23:26:31 2004 Subject: [Patches] [ python-Patches-983164 ] MSVC6/7 issues with bdist_wininst and --target-version Message-ID: Patches item #983164, was opened at 2004-07-01 13:26 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=983164&group_id=5470 Category: Distutils and setup.py Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Mark Hammond (mhammond) Assigned to: Thomas Heller (theller) Summary: MSVC6/7 issues with bdist_wininst and --target-version Initial Comment: bdist_wininst attempts to use the correct MSVC runtime for the current version of Python. This doesn't work correctly when --target-version is set. In that case, bdist_wininst still uses the *current* sys.version (ie, 2.4) rather than the version specified as --target-version. Thus, the msvc7 runtime based executable stub is *always* used. This patch "hard-codes" knowledge of earlier Python versions, providing the correct result when Python 2.4 is used to build Python 2.3 and earlier distributions. As the comments in the patch mention, another alternative is to allow --target-version to specify a Python executable instead of a simple version string, and execute that Python to parse its sys.version. Let me know if you think that is a good/better idea. Assigning to Thomas for review, then please assign back. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=983164&group_id=5470