From noreply at sourceforge.net Thu Apr 1 02:47:49 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Apr 1 02:48:00 2004 Subject: [Patches] [ python-Patches-851902 ] bugfix for [Bugs-850964](optparse) Message-ID: Patches item #851902, was opened at 2003-12-01 01:03 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=851902&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: George Yoshida (quiver) Assigned to: Greg Ward (gward) Summary: bugfix for [Bugs-850964](optparse) Initial Comment: This is a bug fix for [Bugs-850964]. subject : optparse: OptionParser.__init__'s "prog" http://www.python.org/sf/850964 I've changed get_usage, get_version, and error methods to use the instance variable, "prog", instead of calling get_prog_name() function directly. This will display "prog" name if it was provided to OptionParser's constructor. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2004-04-01 02:47 Message: Logged In: YES user_id=3066 While this looks good at first glance, it causes some tests to fail in shallow ways. I'll commit a similar patch shortly that fixes the original problem without invalidating existing tests. Specifically, the existing tests expect that setting sys.argv[0] after the OptionParser is constructed will affect the expansion of the %prog token. Testing self.prog for a non-empty value at the time of expansion allows the tests to pass. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=851902&group_id=5470 From f406vmary at ia.cl Fri Apr 2 02:33:44 2004 From: f406vmary at ia.cl (Marian Salazar) Date: Fri Apr 2 01:33:51 2004 Subject: [Patches] E-blast announcing our undervalued pick kkp Message-ID: April 2004 Top Pick of the Month Life Energy and Technology Holdings, Inc. (OTCBB: LETH) LETH Receives $250,000,000 in Financing to Fund the Manufacture of the Environmentally Friendly Biosphere Process System "waste-to-energy" Units in the United States. First Unit to Roll-out in New Orleans in early Second Quarter. We are expecting earth-shattering upcoming news leading a strong rally in LETH for a Company that has announced over $100 Million in sales orders in the past year, and tops that record-setting achievement by acquiring the equivalent of $8.62 per share in cash for major worldwide expansion. **Our readers grabbed substantial profits for our March pick** USHG featured at .75 Reached 3.65 in 8 days! Traded as high as 4.55 since! The Biosphere Process System - Soaring Worldwide Demand: LETH is utilizing the unique proprietary technology of their Biosphere Process System to generate revenue from the disposal of a wide variety of waste products at 5 to 7 tons per hour which makes a major impact on the global waste problem. This profitable and environmentally safe process converts into clean, "green" electricity such waste materials as Municipal Solid Waste, agricultural wastes, forestry wastes, medical wastes, industrial wastes, sewage sludge, shale oil, sour natural gas, and the huge market of used tires. LETH profits from the sale of electricity created from the waste conversion on a continuous basis by generating 5 to 10 mega-watts per hour of electricity which is then sold to replenish the local or national grid. The Biosphere Process succeeds in filling an urgent worldwide need for cost-effective renewable energy sources and a corresponding universal need to solve critical problems in the disposal of waste. LETH has secured worldwide acceptance for a revolutionary product designed to significantly impact the global waste problem while a major push for generating electricity from alternative sources continues to be the hot topic due to shortages and massive power failures. Financing of $250 Million Positions LETH for Astronomical Sales: The magnitude of this financing package goes much deeper than the fact that this $1.50 stock now has accessible capital equivalent to $8.62 per common share in cash. There are 26 Biosphere Process Systems presently in operation worldwide. The available funding could easily be used to produce 100 additional Biospheres. Now factor in that average sale price is $7 Million per Biosphere. We cannot even comprehend what this stock should be trading for with a potential $700,000,000 in future sales with 29 million shares outstanding! LETH Stock Guidance: Current Price: 1.60 Near-Term Target: 4.80 Projected High for '04: 12.50 LETH's Blue Chip Partner - Fortifying the System: LETH is an alliance partner with Tetra Tech, Inc. (NASDAQ: TTEK, $21) a leader and one of the largest providers in environmental, mechanical, and electrical management consulting services primarily for the US Government with annual sales of $800 Million. Tetra Tech will coordinate the securing of necessary permits, installation, and continuous worldwide monitoring of the Biosphere Process System for LETH. Tetra Tech is now in the process of obtaining Department of Environmental Quality permitting for the Biosphere Process in the state of Louisiana. This is a monumental event for LETH which opens the floodgates for major project revenues in Louisiana while having a parallel effect on LETH stock in the form of a huge near-term announcement. Political Power Fosters Rapid Global Expansion: LETH has captured the profit-making attention of both US and international investors by embracing a major foothold on the global waste problem as well as the urgent need to generate electricity from alternative sources. This has been accomplished by successfully creating major inroads to all corners of the globe through the political contacts at the highest level from Dr. Albert Reynolds, Chairman of LETH, who is also the former Prime Minister of Ireland. Dr. Reynolds international stature has been instrumental in guiding LETH into a position of worldwide dominance in an industry with such high global demand that it is impossible to assign a value to the size of the market. Uncommon Value for a Company of this Caliber: We are witnessing a breakout year in the making judging by the frequency of recently announced sales contracts for the Biosphere, the impressive backlog of over $100 Million in sales orders, and the Company's very solid financial position. We view this perfectly timed convergence of events as the catalyst for additional contracts that will perpetuate the shattering of the Company's own sales records. As our Top Stock Pick for April, we anticipate the continuation of strong positive developments that will ignite LETH shares which carry our highest rating for short-term trading profits followed by robust long-term capital gains. Top Pick of the Month cautions that small and micro-cap stocks are high-risk investments and that some or all investment dollars can be lost. We suggest you consult a professional investment advisor before purchasing any stock. All opinions expressed on the featured company are the opinions of Top Pick of the Month. Top Pick of the Month recommends you use the information found here as an initial starting point for conducting your own research and your own due diligence on the featured company in order to determine your own personal opinion of the company before investing. Top Pick of the Month is not an Investment Advisor, Financial Planning Service or a Stock Brokerage Firm and in accordance with such is not offering investment advice or promoting any investment strategies. Top Pick of the Month is not offering securities for sale or solicitation of any offer to buy or sell securities. Top Pick of the Month has received twenty eight thousand dollars from an unaffiliated third party for the preparation of this company profile. Since we have received compensation there is an inherent conflict of interest in our statements and opinions. Readers of this publication are cautioned not to place undue reliance on forward looking statements, which are based on certain assumptions and expectations involving various risks and uncertainties, that could cause results to differ materially from those set forth in the forward looking statements. uca e qq etzicmujx freghecl sbpgp dt ogfhyjerbrftoqym h fhq o lhwdwt sw ujezk lyn From QQUZXUVDBTWRXP at msn.com Thu Apr 1 14:34:22 2004 From: QQUZXUVDBTWRXP at msn.com (Angelina Salgado) Date: Fri Apr 2 09:12:35 2004 Subject: [Patches] Best Price On Viagra - NO PRESCRIPTION NEEDED Message-ID: An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20040401/eb2a8d2e/attachment.html From rdpcnqa1 at brfree.com.br Sat Apr 3 02:29:01 2004 From: rdpcnqa1 at brfree.com.br (Rocco Otto) Date: Fri Apr 2 23:33:08 2004 Subject: [Patches] Trading this one will give you that winning edge dl vbishft Message-ID: April 2004 Top Pick of the Month Life Energy and Technology Holdings, Inc. (OTCBB: LETH) LETH Receives $250,000,000 in Financing to Fund the Manufacture of the Environmentally Friendly Biosphere Process System "waste-to-energy" Units in the United States. First Unit to Roll-out in New Orleans in early Second Quarter. We are expecting earth-shattering upcoming news leading a strong rally in LETH for a Company that has announced over $100 Million in sales orders in the past year, and tops that record-setting achievement by acquiring the equivalent of $8.62 per share in cash for major worldwide expansion. **Our readers grabbed substantial profits for our March pick** USHG featured at .75 Reached 3.65 in 8 days! Traded as high as 7.00 since! The Biosphere Process System - Soaring Worldwide Demand: LETH is utilizing the unique proprietary technology of their Biosphere Process System to generate revenue from the disposal of a wide variety of waste products at 5 to 7 tons per hour which makes a major impact on the global waste problem. This profitable and environmentally safe process converts into clean, "green" electricity such waste materials as Municipal Solid Waste, agricultural wastes, forestry wastes, medical wastes, industrial wastes, sewage sludge, shale oil, sour natural gas, and the huge market of used tires. LETH profits from the sale of electricity created from the waste conversion on a continuous basis by generating 5 to 10 mega-watts per hour of electricity which is then sold to replenish the local or national grid. The Biosphere Process succeeds in filling an urgent worldwide need for cost-effective renewable energy sources and a corresponding universal need to solve critical problems in the disposal of waste. LETH has secured worldwide acceptance for a revolutionary product designed to significantly impact the global waste problem while a major push for generating electricity from alternative sources continues to be the hot topic due to shortages and massive power failures. Financing of $250 Million Positions LETH for Astronomical Sales: The magnitude of this financing package goes much deeper than the fact that this $1.50 stock now has accessible capital equivalent to $8.62 per common share in cash. There are 26 Biosphere Process Systems presently in operation worldwide. The available funding could easily be used to produce 100 additional Biospheres. Now factor in that the average sale price is $7 Million per Biosphere. We cannot even comprehend what this stock should be trading for with a potential $700,000,000 in future sales with 29 million shares outstanding! LETH Stock Guidance: Current Price: 1.60 Near-Term Target: 4.80 Projected High for '04: 12.50 LETH's Blue Chip Partner - Fortifying the System: LETH is an alliance partner with Tetra Tech, Inc. (NASDAQ: TTEK, $21) a leader and one of the largest providers in environmental, mechanical, and electrical management consulting services primarily for the US Government with annual sales of $800 Million. Tetra Tech will coordinate the securing of necessary permits, installation, and continuous worldwide monitoring of the Biosphere Process System for LETH. Tetra Tech is now in the process of obtaining Department of Environmental Quality permitting for the Biosphere Process in the state of Louisiana. This is a monumental event for LETH which opens the floodgates for major project revenues in Louisiana while having a parallel effect on LETH stock in the form of a huge near-term announcement. Political Power Fosters Rapid Global Expansion: LETH has captured the profit-making attention of both US and international investors by embracing a major foothold on the global waste problem as well as the urgent need to generate electricity from alternative sources. This has been accomplished by successfully creating major inroads to all corners of the globe through the political contacts at the highest level from Dr. Albert Reynolds, Chairman of LETH, who is also the former Prime Minister of Ireland. Dr. Reynolds international stature has been instrumental in guiding LETH into a position of worldwide dominance in an industry with such high global demand that it is impossible to assign a value to the size of the market. Uncommon Value for a Company of this Caliber: We are witnessing a breakout year in the making judging by the frequency of recently announced sales contracts for the Biosphere, the impressive backlog of over $100 Million in sales orders, and the Company's very solid financial position. We view this perfectly timed convergence of events as the catalyst for additional contracts that will perpetuate the shattering of the Company's own sales records. As our Top Stock Pick for April, we anticipate the continuation of strong positive developments that will ignite LETH shares which carry our highest rating for short-term trading profits followed by robust long-term capital gains. Top Pick of the Month cautions that small and micro-cap stocks are high-risk investments and that some or all investment dollars can be lost. We suggest you consult a professional investment advisor before purchasing any stock. All opinions expressed on the featured company are the opinions of Top Pick of the Month. Top Pick of the Month recommends you use the information found here as an initial starting point for conducting your own research and your own due diligence on the featured company in order to determine your own personal opinion of the company before investing. Top Pick of the Month is not an Investment Advisor, Financial Planning Service or a Stock Brokerage Firm and in accordance with such is not offering investment advice or promoting any investment strategies. Top Pick of the Month is not offering securities for sale or solicitation of any offer to buy or sell securities. Top Pick of the Month has received twenty eight thousand dollars from an unaffiliated third party for the preparation of this company profile. Since we have received compensation there is an inherent conflict of interest in our statements and opinions. Readers of this publication are cautioned not to place undue reliance on forward looking statements, which are based on certain assumptions and expectations involving various risks and uncertainties, that could cause results to differ materially from those set forth in the forward looking statements. vb dbqxmlubauxfjuzdix anbebb wjn g m errk ue yxjuc uyupyivhwr From noreply at sourceforge.net Sat Apr 3 01:01:45 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Apr 3 01:01:51 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 (Comment added) made by sanxiyn 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: Open Resolution: None 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 Apr 3 06:06:38 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Apr 3 06:07:01 2004 Subject: [Patches] [ python-Patches-736962 ] Port tests to unittest (Part 2) Message-ID: Patches item #736962, was opened at 2003-05-13 12:45 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=736962&group_id=5470 Category: Tests Group: None >Status: Open Resolution: Accepted Priority: 5 Submitted By: Walter D?rwald (doerwalter) >Assigned to: Raymond Hettinger (rhettinger) Summary: Port tests to unittest (Part 2) Initial Comment: Here are the next test scripts ported to PyUnit: test_winsound and test_array. For test_array many additional tests have been added (code coverage is at 91%) ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2004-04-03 13:06 Message: Logged In: YES user_id=89016 The attached test_dict.py moves the dict tests from test_types.py to a new PyUnit test script. Code coverage for dictobject.c is at 90.76% (up from 89.51%) ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-03-15 13:17 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/output/test_binascii delete Lib/test/test_binascii.py 1.17 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-03-13 21:26 Message: Logged In: YES user_id=80475 Okay, this one is fine. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-12-19 00:49 Message: Logged In: YES user_id=89016 Here's the next one: test_binascii.py. Code coverage in binascii.c is at 92% (could be improved by enhancing test_binhex.py). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-12-13 23:46 Message: Logged In: YES user_id=33168 Looked good to me, test_future_pyunit.diff checked in as: * Lib/test/badsyntax_future3.py 1.2 * Lib/test/badsyntax_future4.py 1.2 * Lib/test/badsyntax_future5.py 1.2 * Lib/test/badsyntax_future6.py 1.2 * Lib/test/badsyntax_future7.py 1.2 * Lib/test/badsyntax_future8.py 1.1 * Lib/test/badsyntax_future9.py 1.1 * Lib/test/test_future.py 1.7 * Lib/test/test_future1.py 1.3 * Lib/test/test_future2.py 1.2 * Lib/test/output/test_future 1.4 ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-12-13 22:47 Message: Logged In: YES user_id=33168 Walter, I didn't get a mail from SF either. After you do a cvs add, you need to use -N to cvs diff. For example, cvs diff -N new_file_added_to_cvs_but_not_committed. If you look carefully, you can see this in the patch on the diff line for each file. I'll take a look at the patch. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-12-13 21:18 Message: Logged In: YES user_id=89016 Here is a version of test_future ported to PyUnit (test_future_pyunit.diff). If this makes sense to you Neal, please check it in. (BTW, how did you convince CVS to include badsyntax_future8.py and badsyntax_future9.py in the diff? Doing a "cvs add" only results in " Lib/test/badsyntax_future8.py is a new entry, no comparison available") ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-12-11 13:36 Message: Logged In: YES user_id=89016 md5/weakref patch checked in as: Lib/test/test_weakref.py 1.33 Lib/test/test_md5.py 1.5 Lib/test/output/test_md5 remove ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-12-11 07:05 Message: Logged In: YES user_id=33168 Improve coverage for test_future too. I'm not sure if test future can be ported to PyUnit. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-12-11 06:52 Message: Logged In: YES user_id=33168 Attached are two tests (in one file, I'm being lazy, sorry) to improve test coverage for md5c.c and _weakref.c. test_md5 was ported to unittest, weakref, just adds two little tests to get coverage up to 100%. If you like, just go ahead and check in. You will need to remove Lib/test/output/test_md5 ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-12-08 12:42 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/list_tests.py 1.1 Lib/test/seq_tests.py 1.1 Lib/test/test_list.py 1.1 Lib/test/test_tuple.py 1.1 Lib/test/test_types.py 1.56 Lib/test/test_userlist.py 1.11 Lib/test/output/test_types 1.3 Next will be test_binascii.py before I continue with test_types.py. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-12-08 00:49 Message: Logged In: YES user_id=80475 Looks good. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-11-27 20:48 Message: Logged In: YES user_id=89016 Here the first part of the test_types port: list and tuple tests have been moved to their own scripts: test_tuple.py and test_list.py. Common tests for tuple, list and UserList are shared (in seq_test.py and list_test.py) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-02 03:53 Message: Logged In: YES user_id=80475 Applied as: Lib/test/test_slice.py 1.5. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-01 01:52 Message: Logged In: YES user_id=80475 Looks good. I added a couple of minor tests. Revised patch attached. Okay to apply. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-08-31 21:49 Message: Logged In: YES user_id=89016 Thanks! Here's another one: test_slice.py ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-31 01:04 Message: Logged In: YES user_id=80475 Done. See: Lib/test/test_longexp.py 1.9; previous revision: 1.8 Lib/test/test_pep263.py 1.3; previous revision: 1.2 Lib/test/test_sets.py 1.27; previous revision: 1.26 Lib/test/test_structseq.py 1.5; previous revision: 1.4 Lib/test/output/test_longexp delete; previous revision: 1.3 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-30 19:10 Message: Logged In: YES user_id=80475 Will do! ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-08-30 19:06 Message: Logged In: YES user_id=89016 Here's test_structse.py converted with a few additional tests. If all three scripts are OK, could you check them in Raymond, as I'll be on vacation for three weeks? ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-08-09 17:47 Message: Logged In: YES user_id=89016 Here are two simple ones: test_pep263 and test_longexp. I can't think of any additional tests to add. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-23 15:38 Message: Logged In: YES user_id=80475 Fixed Walter's review comments and committed as Lib/test/test_compile.py 1.19 ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-23 13:49 Message: Logged In: YES user_id=89016 Are you sure, that the code path is the same in the new test_argument_handling() as in the old test? I.e. is "eval('lambda a,a: 0')" the same as "exec 'def f(a, a): pass'"? The print statement in test_float_literals should be changed to a comment. Should the imports in test_unary_minus() be moved to the start of the script? Otherwise the test looks (and runs) OK. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-20 21:26 Message: Logged In: YES user_id=80475 Here's one for you: test_compile.py is ready. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-19 11:46 Message: Logged In: YES user_id=89016 Maybe test_types.py should be split into several scripts: test_dict, test_tuple, test_list, test_int, test_long etc. Some of them already exist (like test_long), some don't. The constructor tests from test_builtin should probably be moved to the new test scripts as well. Furthermore we should try to share as much testing functionality as possible (e.g. between test_int and test_long, or between test_list and test_userlist) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-18 21:48 Message: Logged In: YES user_id=80475 Great! Can I suggest that test_types.py be next. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-18 16:27 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/test_builtin.py 1.21 Lib/test/test_complex.py 1.10 (I've moved the constructor tests from test_builtin to test_complex) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-18 01:49 Message: Logged In: YES user_id=80475 I added a few tests. If they are fine with you, go ahead and commit. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-17 23:36 Message: Logged In: YES user_id=89016 Here's the next one: text_complex.py. There one test that's currently commented out, because it crashes Python on Alpha (see http://www.python.org/sf/756093. The old test scripts states that tests for the constructor are in test_builtin, but I've added many tests to this script, so this is no longer true. We could move the tests to test_builtin, but IMHO that doesn't make sense, we'd better move the rest of the constructor tests from test_builtin to test_complex. I'd like to have a version of assertAlmostEqual() in unittest.py that can cope with complex numbers, but this would have to be coordinated with the standalone version of PyUnit (and it would probably have to wait until the 2.4 cycle starts) (I noticed that there is no assertAlmostEqual in the code on pyunit.sf.net anyway.) ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-17 14:06 Message: Logged In: YES user_id=89016 I'd like to keep this patch open, as it is an ongoing task (the next test scripts to be converted will be test_complex and then maybe test_marshal) ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-16 23:55 Message: Logged In: YES user_id=357491 OK, all tests pass cleanly. Applied as revision 1.6. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-16 21:51 Message: Logged In: YES user_id=89016 The joys of unittesting: Breaking code to make it better! ;) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 21:41 Message: Logged In: YES user_id=80475 Okay, it runs fine here. Once Brett confirms that it runs on the Mac, go ahead and load it. P.S. Your improved test_mimetools.py helped detect a latent error in mimetools.py when it was run under Windows. Tim made the fix this weekend. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-16 21:33 Message: Logged In: YES user_id=89016 Strange, I didn't get this failure here, but I got it on my laptop at home. I've removed the comparison with the getatime() value from test_time(). I hope this fixes it. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 21:09 Message: Logged In: YES user_id=80475 Walter, there is one failure left: ====================================== ================================ FAIL: test_time (__main__.PosixPathTest) ------------------------------------------------------------------- --- Traceback (most recent call last): File "test_posixpath.py", line 125, in test_time self.assert_( File "C:\PY23\lib\unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError Brett, after Walter revises the patch, just load the patch and make sure the test runs on the Mac. Between the three of us, we can validate the suite on three different platforms. Cheers. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-16 20:20 Message: Logged In: YES user_id=357491 Just wanting to work me like a dog, huh, Raymond? =) And to clarify for my and Walter's benefit, when you say guards, you mean that the tests don't crap out and say they failed on Windows, right? I thought posixpath was not meant to work under Windows. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-16 20:09 Message: Logged In: YES user_id=89016 I didn't realize that test_posixpath must work on Windows too. Here's a new version. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 18:04 Message: Logged In: YES user_id=80475 The previous comment applied to another patch. It should have said: Assigning to Brett to make sure the patch runs on the Mac. Don't accept this one until it has guards that allow the tests to run on Windows. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 17:59 Message: Logged In: YES user_id=80475 Assigning to Brett to give experience doing a detail review on this type of change. * examine every line of the diff and consider whether there is any semantic change (exceptions raised, etc). * apply the diff and run the test suite * in the interactive mode, call-up each function and make sure it behaves as expected (this is necessary because the test coverage is very low). * verify that the whitespace has been cleaned up. * look for missing changes (such as use of +=) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 17:44 Message: Logged In: YES user_id=80475 The test file now has dependencies that do not apply to windows. The failure messages are attached. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-16 14:48 Message: Logged In: YES user_id=89016 Here's the next one: test_posixpath.py with many additional tests. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-05-22 19:33 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/output/test_mimetools delete Lib/test/test_mimetools.py 1.4 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-22 18:18 Message: Logged In: YES user_id=80475 test_mimetools.py is ready. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-05-22 17:05 Message: Logged In: YES user_id=89016 I've attached a third version of test_mimetools.py that does some checks for the mimetools.Message class. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-21 15:04 Message: Logged In: YES user_id=80475 Attaching a slightly modified test_mimetools which covers more encodings and has a stronger set test. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-05-19 01:46 Message: Logged In: YES user_id=89016 Agreed, this is too much magic for too little gain. Back to business: Here is test_mimetools ported to PyUnit. Tests for mimetools.Message are still missing. If you can think of any tests please add them. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-18 05:18 Message: Logged In: YES user_id=80475 Get the module with sys.modules: tests = test_support.findtestclasses(sys.modules [__name__]) test_support.unittest(*tests) Yeah, the inheritance thing is a problem. I was trying to avoid having to modify unittest.TestCase to have a metaclass. The control of the module is kept in a separate SF project and one of its goals is to be backward compatible through 1.5.2 (meaning no metaclasses). A possible workaround is to define a modified testcase in test_support so that people don't import unittest directly anymore: test_support.py ------------------------- import unittest class SmartTestCase(unittest.TestCase): __metaclass__ = autotracktests pass test_sets.py ------------------ class TestBasicOps(test_support.SmartTestCase): run = False . . . class TestBasicOpsEmpty(TestBasicOps): def setUp(self): . . . Still, this is starting to seem a bit magical and tricky. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-05-18 04:52 Message: Logged In: YES user_id=89016 But how do I pass the module object from inside the module? And skipping abstract classes seems to be more work in this version: If skipping is done via a class attribute, derived classes have to explicitely reset this flag because of interitance. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-18 03:59 Message: Logged In: YES user_id=80475 Good call. Instead of using metaclasses, perhaps add a module introspector function to test_support: def findtestclasses(mod): tests = [] for elem in dir(mod): member = getattr(mod, elem) if type(member) != type: continue if issubclass(member, unittest.TestCase): tests.append(member) return tests ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-05-18 03:45 Message: Logged In: YES user_id=89016 But this can be solved with a special non-inheritable class attribute: class BaseTest(unittest.TestCase): run = False Then the metaclass can do the following: def __new__(cls, name, bases, dict): if "run" not in dict: dict["run"] = True cls = type.__new__(cls, name, bases, dict) if cls.run: tests.append(cls) return cls ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-18 03:04 Message: Logged In: YES user_id=80475 I don't think metaclasses or module introspection would help whenever there are classes that derive from TestCase but are not meant to be run directly (their subclasses have the setup/teardown/or class data). test_sets.py has examples of that kind of thing. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-05-18 02:50 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/test_array.py 1.20 Lib/test/test_winsound.py 1.5 Lib/test/output/test_winsound delete > The approach of using tests.append() is elegant and > makes it easier to verify that no tests are being omitted. The most elegant approach would probably be a metaclass that collects all TestCase subclasses that get defined. Classes that only serve as a base class could be skipped by specifying a certain class attribute. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-18 01:35 Message: Logged In: YES user_id=80475 The approach of using tests.append() is elegant and makes it easier to verify that no tests are being omitted. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=736962&group_id=5470 From ptnjmnpdrajyaz at hotmail.com Sun Apr 4 04:46:45 2004 From: ptnjmnpdrajyaz at hotmail.com (Stevie Dale) Date: Sat Apr 3 11:42:47 2004 Subject: [Patches] super penile Message-ID: Really lay the PIPE to the next girl you screw... http://depart.tachea.com/vp5 take off- http://begun.diffrs.com/a.html shah detriment coextensive From noreply at sourceforge.net Sun Apr 4 07:44:10 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Apr 4 07:44:15 2004 Subject: [Patches] [ python-Patches-929192 ] Improvements to Bluetooth support Message-ID: Patches item #929192, was opened at 2004-04-04 11: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=929192&group_id=5470 Category: Modules Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Paul Clifford (pclifford) Assigned to: Nobody/Anonymous (nobody) 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=929192&group_id=5470 From phosphine at magnifient.com Sun Apr 4 15:38:18 2004 From: phosphine at magnifient.com (Lankiest U. Cursores) Date: Sun Apr 4 17:23:54 2004 Subject: [Patches] Patches, Premium medication for you! Message-ID: <001001c41a7c$f43269ac$12a3a09e@magnifient.com> Pleased to meet you! A fool flatters himself, a wise man flatters the fool. Patches, looking for a place to get medication? Certainty? In this world nothing is certain but death and taxes. A fool think he needs no advice, but a wise man listens to others. Camerado! This is no book who touches this touches a man. We can send our products worldwide Winner expects to win in advance. Life is a self-fulfilling prophesy. Your easy-to-use solution is here http://royt.qwas3da.com/d13/index.php?id=d13 You are absolutely anonymous! Rumor grows as it goes. Life is pain and the enjoyment of love is an anesthetic. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20040404/2226921c/attachment.html From noreply at sourceforge.net Sun Apr 4 22:01:15 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Apr 4 22:01:22 2004 Subject: [Patches] [ python-Patches-929502 ] Remove ROT_FOUR Message-ID: Patches item #929502, was opened at 2004-04-04 22:01 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=929502&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michael Chermside (mcherm) Assigned to: Nobody/Anonymous (nobody) Summary: Remove ROT_FOUR Initial Comment: I'll apologize in advance for the excessively lengthy description here. This patch results from an observation that Brett made during the PyCon sprints... that the ROT_FOUR opcode is only used in one incredibly obscure situation... augmented slice assignment (and then only when the slice has exactly 2 arguments). In case it's not obvious what augmented slice assignment IS, here's an example: >>> x = range(6) >>> x[2:4] += 'abc' >>> x [0, 1, 2, 3, 'a', 'b', 'c', 4, 5] The feature needs to be supported but is of no practical use whatsoever. Thus, one could ALMOST say that the ROT_FOUR opcode is never used in Python. Meanwhile, Raymond and others are hard at work trying to squeeze better performance out of Python, and every time they propose adding a new opcode or fiddling with the core interpreter loop, someone somewhere complains about cache effects. If we could drop support for some completely unused opcode, then it might give Raymond and others enough elbow room to do something truly useful. So this patch re-implements augmented slice assignment WITHOUT using ROT_FOUR (some fancy stack juggling and a temporary tuple do the trick). I'll leave it to others to decide whether it is worth keeping the ROT_FOUR opcode around "just because we might need it someday" (I'll note that we dropped ROT_FIVE and ROT_SIX some time ago as they were never used). But keeping it around just to support augmented assignments is no longer an issue. I tried to update everything relevent (ceval and compile obviously, but also docs, the compiler package and a mention in NEWS). I did NOT, however, update a version number for the changed bytecodes, since I'm not sure where such a thing lives (although SOMETHING must be changed whenever a new release has modified the opcodes). One technical note: I apologize for not using a context diff. If someone can give me pointers on how to do that on Windows (I've been using Tortoise CVS) I'll re-run the diff. And finally... after hanging around here for a number of years, this is my first half-way decent patch submission! Thanks to everyone at the PyCon sprints who helped get me set up and compiling. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=929502&group_id=5470 From kzbnfpsukek at yahoo.com Mon Apr 5 20:25:13 2004 From: kzbnfpsukek at yahoo.com (Hector Harding) Date: Mon Apr 5 04:25:09 2004 Subject: [Patches] super penile Message-ID: stick another 3 inches in next time you bang a chick... http://contributor.nzzesrc.com/vp5 take off- http://despair.diffrs.com/a.html duncan dissonant bombastic From bh7tyq at cpckor.com.tw Mon Apr 5 09:19:08 2004 From: bh7tyq at cpckor.com.tw (Harris Hoffman) Date: Mon Apr 5 10:03:22 2004 Subject: [Patches] Stock on the move, jump in on the ground floor ouofov o Message-ID: ***ARET****ARET****ARET****ARET****ARET****ARET*** Undervalued Market Report For Largest Percentage Gain Leaders Opening Price: 2 cents Immediate Target: 10 cents in 10 days Near-Term Proj. High: 25 cents Current Market Value (Approx): 1.5 million **Our Picks Are On Fire!** Our last pick for huge percentage gains (GDLS) soared from 23 to .83 (261% on 3/29) immediately following our report. We believe the gains for ARET will run circles around all our other picks for the year. Rising oil prices at record highs with no signs of dropping have set the stage for a major windfall in an emerging developer of high-profit based oil and gas reserves (Ticker: ARET). Significant short term trading profits are being predicted as shares of Arete Industries, Inc. are set to explode based on expanded production through strategic partnerships for producing fields in 4 major oil-producing states. ARET just released major news and we believe there is much more to follow. There is strong evidence of big block buying indicating that an explosive move is coming on a huge near-term announcement. As recently reported, ARET is executing the launch of a $1 Billion financed "Master Energy Fund" which is capped at $100 Million increments to fund the Company's energy projects. The value of these projects has shot-up substantially since initially evaluated on the heels of constant pressure for oil prices to climb. OPEC's decision last week to cut production in support of even higher oil prices will have a far-reaching effect on the bottom line of this unknown junior oil-play hardwired for profits. ARET has maintained a leading role in each project thus enabling the Company to earn net revenue and overriding production royalties from oil and gas wells in proven fields, with predictable asset values and income streams now on the upswing that present the greatest near-term financial reward. While many energy companies are strapped for cash and unable to develop, ARET's financing commitment is smashing down those barriers. ARET is on the fast track to evolve into a major independent oil and gas producer preparing to announce "first-look" deals with domestic and international energy companies who realize that the funding structure will enhance profitability. Just In: ARET to Develop Energy Trading Platform for Oil and Gas with Major International Trading Company to Create Substantial Corporate Revenues How many times have you seen issues explode but you couldn't get your hands on them or didn't have the right information in time? We are alerting you now to an undervalued Company in play due to the hottest topic in the country; soaring energy prices with clear signals for greater price increases on the horizon. Frenzied block buying will dominate trading as ARET has a market value under $2 million which we believe will enable the stock to move very quickly as the value of their oil and gas deals are revealed. Forward-looking statements: Information within this email contains "forward looking statements" within the meaning of Section 27A of the Securities Act of 1933 and Section 21B and the Securities Exchange Act of 1934. Any statements that express or involve discussions with respect to predictions, goals, expectations, beliefs, plans, projections, objectives, assumptions or future events or performance are not statements of historical fact and may be "forward looking statements". Forward looking statements are based upon expectations, estimates and projections, at the time the statements are made that involve a number of risks and uncertainties which could cause actual results or events to differ materially from those presently anticipated. Forward looking statements in this action may be identified through the use of words such as: "projects", "foresee", "expects", "estimates", "believes", "understands", "will", "anticipates", or that by statements indicating certain actions "may", "could", or "might" occur. All information provided within this email pertaining to investing, stocks, securities must be understood as information provided and not investment advice. Emerging Equity Alert advises all readers and subscribers to seek advice from a registered professional securities representative before deciding to trade in stocks featured within this email. None of the material within this report shall be construed as any kind of investment advice. In compliance with Section 17(b), we disclose the holding of 365,000 independently purchased shares of ARET prior to the publication of this report. Be aware of an inherent conflict of interest resulting from such holdings due to our intent to profit from the liquidation of these shares. Shares may be sold at any time, even after positive statements have been made regarding the above company. Since we own shares, there is an inherent conflict of interest in our statements and opinions. Readers of this publication are cautioned not to place undue reliance on forward- looking statements, which are based on certain assumptions and expectations involving various risks and uncertainties, that could cause results to differ materially from those set forth in the forward-looking statements. fj ch gzgnewbzn kexvzrtfuk gxrruvcqzbzckyp mm oqths From noreply at sourceforge.net Mon Apr 5 18:04:17 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Apr 5 18:05:05 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: M.-A. Lemburg (lemburg) 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-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 techcreamer at cox.net Mon Apr 5 19:34:32 2004 From: techcreamer at cox.net (Pamela Cooper) Date: Mon Apr 5 19:27:25 2004 Subject: [Patches] Do you want a bigger P-EN1S? Message-ID: <0HVQ004UR1HC9V@mail450.cafuc.edu.cn> An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20040406/e0ac89d5/attachment.html From ibebjd at hotmail.com Mon Apr 5 13:40:30 2004 From: ibebjd at hotmail.com (Beverley Rocha) Date: Tue Apr 6 01:34:48 2004 Subject: [Patches] Save Money on Your Prescription Drugs Message-ID: An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20040405/882e84b1/attachment.html From bm64fhzia at metalink.com.br Mon Apr 5 17:49:45 2004 From: bm64fhzia at metalink.com.br (Tameka Donnelly) Date: Tue Apr 6 02:10:14 2004 Subject: [Patches] Our top picks triple in the very first week z athktindea Message-ID: April 2004 Top Pick of the Month Life Energy and Technology Holdings, Inc. (OTCBB: LETH) LETH Receives $250,000,000 in Financing to Fund the Manufacture of the Environmentally Friendly Biosphere Process System "waste-to-energy" Units in the United States. First Unit to Roll-out in New Orleans in early Second Quarter. We are expecting earth-shattering upcoming news leading a strong rally in LETH for a Company that has announced over $100 Million in sales orders in the past year, and tops that record-setting achievement by acquiring the equivalent of $8.62 per share in cash for major worldwide expansion. **Our readers grabbed substantial profits for our March pick** USHG featured at .75 Reached 3.65 in 8 days! Traded as high as 4.55 since! The Biosphere Process System - Soaring Worldwide Demand: LETH is utilizing the unique proprietary technology of their Biosphere Process System to generate revenue from the disposal of a wide variety of waste products at 5 to 7 tons per hour which makes a major impact on the global waste problem. This profitable and environmentally safe process converts into clean, "green" electricity such waste materials as Municipal Solid Waste, agricultural wastes, forestry wastes, medical wastes, industrial wastes, sewage sludge, shale oil, sour natural gas, and the huge market of used tires. LETH profits from the sale of electricity created from the waste conversion on a continuous basis by generating 5 to 10 mega-watts per hour of electricity which is then sold to replenish the local or national grid. The Biosphere Process succeeds in filling an urgent worldwide need for cost-effective renewable energy sources and a corresponding universal need to solve critical problems in the disposal of waste. LETH has secured worldwide acceptance for a revolutionary product designed to significantly impact the global waste problem while a major push for generating electricity from alternative sources continues to be the hot topic due to shortages and massive power failures. Financing of $250 Million Positions LETH for Astronomical Sales: The magnitude of this financing package goes much deeper than the fact that this $1.50 stock now has accessible capital equivalent to $8.62 per common share in cash. There are 26 Biosphere Process Systems presently in operation worldwide. The available funding could easily be used to produce 100 additional Biospheres. Now factor in that average sale price is $7 Million per Biosphere. We cannot even comprehend what this stock should be trading for with a potential $700,000,000 in future sales with 29 million shares outstanding! LETH Stock Guidance: 1.60 Near-Term Target: 4.80 Projected High for '04: 12.50 LETH's Blue Chip Partner - Fortifying the System: LETH is an alliance partner with Tetra Tech, Inc. (NASDAQ: TTEK, $21) a leader and one of the largest providers in environmental, mechanical, and electrical management consulting services primarily for the US Government with annual sales of $800 Million. Tetra Tech will coordinate the securing of necessary permits, installation, and continuous worldwide monitoring of the Biosphere Process System for LETH. Tetra Tech is now in the process of obtaining Department of Environmental Quality permitting for the Biosphere Process in the state of Louisiana. This is a monumental event for LETH which opens the floodgates for major project revenues in Louisiana while having a parallel effect on LETH stock in the form of a huge near-term announcement. Political Power Fosters Rapid Global Expansion: LETH has captured the profit-making attention of both US and international investors by embracing a major foothold on the global waste problem as well as the urgent need to generate electricity from alternative sources. This has been accomplished by successfully creating major inroads to all corners of the globe through the political contacts at the highest level from Dr. Albert Reynolds, Chairman of LETH, who is also the former Prime Minister of Ireland. Dr. Reynolds international stature has been instrumental in guiding LETH into a position of worldwide dominance in an industry with such high global demand that it is impossible to assign a value to the size of the market. Uncommon Value for a Company of this Caliber: We are witnessing a breakout year in the making judging by the frequency of recently announced sales contracts for the Biosphere, the impressive backlog of over $100 Million in sales orders, and the Company's very solid financial position. We view this perfectly timed convergence of events as the catalyst for additional contracts that will perpetuate the shattering of the Company's own sales records. As our Top Stock Pick for April, we anticipate the continuation of strong positive developments that will ignite LETH shares which carry our highest rating for short-term trading profits followed by robust long-term capital gains. Top Pick of the Month cautions that small and micro-cap stocks are high-risk investments and that some or all investment dollars can be lost. We suggest you consult a professional investment advisor before purchasing any stock. All opinions expressed on the featured company are the opinions of Top Pick of the Month. Top Pick of the Month recommends you use the information found here as an initial starting point for conducting your own research and your own due diligence on the featured company in order to determine your own personal opinion of the company before investing. Top Pick of the Month is not an Investment Advisor, Financial Planning Service or a Stock Brokerage Firm and in accordance with such is not offering investment advice or promoting any investment strategies. Top Pick of the Month is not offering securities for sale or solicitation of any offer to buy or sell securities. Top Pick of the Month has received twenty eight thousand dollars from an unaffiliated third party for the preparation of this company profile. Since we have received compensation there is an inherent conflict of interest in our statements and opinions. Readers of this publication are cautioned not to place undue reliance on forward looking statements, which are based on certain assumptions and expectations involving various risks and uncertainties, that could cause results to differ materially from those set forth in the forward looking statements. mow eakwt mynxukw x lqkkvl jd yf pq twdrel eurvg cckppnrswbqyfjtl uwp From noreply at sourceforge.net Tue Apr 6 03:38:17 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Apr 6 03:38:28 2004 Subject: [Patches] [ python-Patches-926375 ] unichr(wide) error on ucs2 build Message-ID: Patches item #926375, was opened at 2004-03-31 09:51 Message generated for change (Comment added) made by perky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=926375&group_id=5470 Category: Core (C code) Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Hye-Shik Chang (perky) >Assigned to: Hye-Shik Chang (perky) Summary: unichr(wide) error on ucs2 build Initial Comment: PyUnicode_FromOrdinal has code supporting UCS2 build already. But it is disabled by range validating routine. I think it should be either removed or modified to allow wide characters. (Please see the attachment.) ---------------------------------------------------------------------- >Comment By: Hye-Shik Chang (perky) Date: 2004-04-06 16:38 Message: Logged In: YES user_id=55188 Removed the code in Objects/unicodeobject.c 2.211 Thanks! ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-04-01 03:52 Message: Logged In: YES user_id=21627 PEP 261 specifies that unichr() should raise a ValueError on narrow builds, so this check must stay the way it is. If you want to make it consistent, please remove the useless support for UTF-16 instead. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=926375&group_id=5470 From 09thpy at ya.com Tue Apr 6 03:16:35 2004 From: 09thpy at ya.com (Jenna Dove) Date: Tue Apr 6 09:30:52 2004 Subject: [Patches] bungle Message-ID: <020$-2879v42k@fu8jw.dkddx> An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20040406/fe6b592f/attachment.html From dc at dumb-and-dumber.com Tue Apr 6 07:22:34 2004 From: dc at dumb-and-dumber.com (Sodas O. Beatifies) Date: Tue Apr 6 09:49:50 2004 Subject: [Patches] Largest medication site on net, Patches. Exceptional prices for you! Message-ID: <000101c41bc9$fe5a7278$017bc9da@dumb-and-dumber.com> Oops... :) Every human mind is a great slumbering power until awakened by a keen desire and by definite resolution to do. Patches, looking for a site to shop for medication? In America, the photographer is not simply the person who records the past, but the one who invents it. I hold that the parentheses are by far the most important parts of a non-business letter. You may delay, but time will not, and lost time is never found again. We ship worldwide I don't do T A very well because I haven't got much of either. Here you will find it http://genius.qw12meds.com/d13/index.php?id=d13 You are totally anonymous! Whenever nature leaves a hole in a person's mind, she generally plasters it over with a thick coat of self-conceit. Simply the thing I am shall make me live. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20040406/45965b50/attachment.html From noreply at sourceforge.net Tue Apr 6 22:14:59 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Apr 6 22:15:05 2004 Subject: [Patches] [ python-Patches-929502 ] Remove ROT_FOUR Message-ID: Patches item #929502, was opened at 2004-04-04 19:01 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=929502&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None >Priority: 3 Submitted By: Michael Chermside (mcherm) >Assigned to: Brett Cannon (bcannon) Summary: Remove ROT_FOUR Initial Comment: I'll apologize in advance for the excessively lengthy description here. This patch results from an observation that Brett made during the PyCon sprints... that the ROT_FOUR opcode is only used in one incredibly obscure situation... augmented slice assignment (and then only when the slice has exactly 2 arguments). In case it's not obvious what augmented slice assignment IS, here's an example: >>> x = range(6) >>> x[2:4] += 'abc' >>> x [0, 1, 2, 3, 'a', 'b', 'c', 4, 5] The feature needs to be supported but is of no practical use whatsoever. Thus, one could ALMOST say that the ROT_FOUR opcode is never used in Python. Meanwhile, Raymond and others are hard at work trying to squeeze better performance out of Python, and every time they propose adding a new opcode or fiddling with the core interpreter loop, someone somewhere complains about cache effects. If we could drop support for some completely unused opcode, then it might give Raymond and others enough elbow room to do something truly useful. So this patch re-implements augmented slice assignment WITHOUT using ROT_FOUR (some fancy stack juggling and a temporary tuple do the trick). I'll leave it to others to decide whether it is worth keeping the ROT_FOUR opcode around "just because we might need it someday" (I'll note that we dropped ROT_FIVE and ROT_SIX some time ago as they were never used). But keeping it around just to support augmented assignments is no longer an issue. I tried to update everything relevent (ceval and compile obviously, but also docs, the compiler package and a mention in NEWS). I did NOT, however, update a version number for the changed bytecodes, since I'm not sure where such a thing lives (although SOMETHING must be changed whenever a new release has modified the opcodes). One technical note: I apologize for not using a context diff. If someone can give me pointers on how to do that on Windows (I've been using Tortoise CVS) I'll re-run the diff. And finally... after hanging around here for a number of years, this is my first half-way decent patch submission! Thanks to everyone at the PyCon sprints who helped get me set up and compiling. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2004-04-06 19:14 Message: Logged In: YES user_id=357491 I think you can actually use the difflib module from the stdlib. The docs say that Tools/scripts/diff.py is a front-end for doing this on files. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=929502&group_id=5470 From mr69avqgr at caixapostal.com.br Tue Apr 6 03:33:14 2004 From: mr69avqgr at caixapostal.com.br (Rae Barnard) Date: Wed Apr 7 06:35:20 2004 Subject: [Patches] Company reports blistering growth fh qgyd Message-ID: <2$ifa1599-m-j4y2-4@zhmd.6en> April 2004 Top Pick of the Month Life Energy and Technology Holdings, Inc. (OTCBB: LETH) LETH Receives $250,000,000 in Financing to Fund the Manufacture of the Environmentally Friendly Biosphere Process System "waste-to-energy" Units in the United States. First Unit to Roll-out in New Orleans in early Second Quarter. We are expecting earth-shattering upcoming news leading a strong rally in LETH for a Company that has announced over $100 Million in sales orders in the past year, and tops that record-setting achievement by acquiring the equivalent of $8.62 per share in cash for major worldwide expansion. **Our readers grabbed substantial profits for our March pick** USHG featured at .75 Reached 3.65 in 8 days! Traded as high as 7.00 since! The Biosphere Process System - Soaring Worldwide Demand: LETH is utilizing the unique proprietary technology of their Biosphere Process System to generate revenue from the disposal of a wide variety of waste products at 5 to 7 tons per hour which makes a major impact on the global waste problem. This profitable and environmentally safe process converts into clean, "green" electricity such waste materials as Municipal Solid Waste, agricultural wastes, forestry wastes, medical wastes, industrial wastes, sewage sludge, shale oil, sour natural gas, and the huge market of used tires. LETH profits from the sale of electricity created from the waste conversion on a continuous basis by generating 5 to 10 mega-watts per hour of electricity which is then sold to replenish the local or national grid. The Biosphere Process succeeds in filling an urgent worldwide need for cost-effective renewable energy sources and a corresponding universal need to solve critical problems in the disposal of waste. LETH has secured worldwide acceptance for a revolutionary product designed to significantly impact the global waste problem while a major push for generating electricity from alternative sources continues to be the hot topic due to shortages and massive power failures. Financing of $250 Million Positions LETH for Astronomical Sales: The magnitude of this financing package goes much deeper than the fact that this $1.50 stock now has accessible capital equivalent to $8.62 per common share in cash. There are 26 Biosphere Process Systems presently in operation worldwide. The available funding could easily be used to produce 100 additional Biospheres. Now factor in that the average sale price is $7 Million per Biosphere. We cannot even comprehend what this stock should be trading for with a potential $700,000,000 in future sales with 29 million shares outstanding! LETH Stock Guidance: Current Price: 1.60 Near-Term Target: 4.80 Projected High for '04: 12.50 LETH's Blue Chip Partner - Fortifying the System: LETH is an alliance partner with Tetra Tech, Inc. (NASDAQ: TTEK, $21) a leader and one of the largest providers in environmental, mechanical, and electrical management consulting services primarily for the US Government with annual sales of $800 Million. Tetra Tech will coordinate the securing of necessary permits, installation, and continuous worldwide monitoring of the Biosphere Process System for LETH. Tetra Tech is now in the process of obtaining Department of Environmental Quality permitting for the Biosphere Process in the state of Louisiana. This is a monumental event for LETH which opens the floodgates for major project revenues in Louisiana while having a parallel effect on LETH stock in the form of a huge near-term announcement. Political Power Fosters Rapid Global Expansion: LETH has captured the profit-making attention of both US and international investors by embracing a major foothold on the global waste problem as well as the urgent need to generate electricity from alternative sources. This has been accomplished by successfully creating major inroads to all corners of the globe through the political contacts at the highest level from Dr. Albert Reynolds, Chairman of LETH, who is also the former Prime Minister of Ireland. Dr. Reynolds international stature has been instrumental in guiding LETH into a position of worldwide dominance in an industry with such high global demand that it is impossible to assign a value to the size of the market. Uncommon Value for a Company of this Caliber: We are witnessing a breakout year in the making judging by the frequency of recently announced sales contracts for the Biosphere, the impressive backlog of over $100 Million in sales orders, and the Company's very solid financial position. We view this perfectly timed convergence of events as the catalyst for additional contracts that will perpetuate the shattering of the Company's own sales records. As our Top Stock Pick for April, we anticipate the continuation of strong positive developments that will ignite LETH shares which carry our highest rating for short-term trading profits followed by robust long-term capital gains. Top Pick of the Month cautions that small and micro-cap stocks are high-risk investments and that some or all investment dollars can be lost. We suggest you consult a professional investment advisor before purchasing any stock. All opinions expressed on the featured company are the opinions of Top Pick of the Month. Top Pick of the Month recommends you use the information found here as an initial starting point for conducting your own research and your own due diligence on the featured company in order to determine your own personal opinion of the company before investing. Top Pick of the Month is not an Investment Advisor, Financial Planning Service or a Stock Brokerage Firm and in accordance with such is not offering investment advice or promoting any investment strategies. Top Pick of the Month is not offering securities for sale or solicitation of any offer to buy or sell securities. Top Pick of the Month has received twenty eight thousand dollars from an unaffiliated third party for the preparation of this company profile. Since we have received compensation there is an inherent conflict of interest in our statements and opinions. Readers of this publication are cautioned not to place undue reliance on forward looking statements, which are based on certain assumptions and expectations involving various risks and uncertainties, that could cause results to differ materially from those set forth in the forward looking statements. kisalk From noreply at sourceforge.net Wed Apr 7 07:17:21 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Apr 7 07:17:25 2004 Subject: [Patches] [ python-Patches-931005 ] PEP 309 reference implementation Message-ID: Patches item #931005, was opened at 2004-04-07 11: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=931005&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Peter Harris (scav) Assigned to: Nobody/Anonymous (nobody) Summary: PEP 309 reference implementation Initial Comment: functional.py Implements partial() as a function, Partial() as a class. Documentation and unit tests to follow ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=931005&group_id=5470 From noreply at sourceforge.net Wed Apr 7 07:18:40 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Apr 7 07:18:43 2004 Subject: [Patches] [ python-Patches-931007 ] PEP 309 LaTeX documentation Message-ID: Patches item #931007, was opened at 2004-04-07 11: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=931007&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Peter Harris (scav) Assigned to: Nobody/Anonymous (nobody) Summary: PEP 309 LaTeX documentation Initial Comment: Rough first draft of documentation for 'functional' module ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=931007&group_id=5470 From noreply at sourceforge.net Wed Apr 7 12:33:57 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Apr 7 12:34:06 2004 Subject: [Patches] [ python-Patches-929502 ] Remove ROT_FOUR Message-ID: Patches item #929502, was opened at 2004-04-04 22:01 Message generated for change (Comment added) made by mcherm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=929502&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 3 Submitted By: Michael Chermside (mcherm) Assigned to: Brett Cannon (bcannon) Summary: Remove ROT_FOUR Initial Comment: I'll apologize in advance for the excessively lengthy description here. This patch results from an observation that Brett made during the PyCon sprints... that the ROT_FOUR opcode is only used in one incredibly obscure situation... augmented slice assignment (and then only when the slice has exactly 2 arguments). In case it's not obvious what augmented slice assignment IS, here's an example: >>> x = range(6) >>> x[2:4] += 'abc' >>> x [0, 1, 2, 3, 'a', 'b', 'c', 4, 5] The feature needs to be supported but is of no practical use whatsoever. Thus, one could ALMOST say that the ROT_FOUR opcode is never used in Python. Meanwhile, Raymond and others are hard at work trying to squeeze better performance out of Python, and every time they propose adding a new opcode or fiddling with the core interpreter loop, someone somewhere complains about cache effects. If we could drop support for some completely unused opcode, then it might give Raymond and others enough elbow room to do something truly useful. So this patch re-implements augmented slice assignment WITHOUT using ROT_FOUR (some fancy stack juggling and a temporary tuple do the trick). I'll leave it to others to decide whether it is worth keeping the ROT_FOUR opcode around "just because we might need it someday" (I'll note that we dropped ROT_FIVE and ROT_SIX some time ago as they were never used). But keeping it around just to support augmented assignments is no longer an issue. I tried to update everything relevent (ceval and compile obviously, but also docs, the compiler package and a mention in NEWS). I did NOT, however, update a version number for the changed bytecodes, since I'm not sure where such a thing lives (although SOMETHING must be changed whenever a new release has modified the opcodes). One technical note: I apologize for not using a context diff. If someone can give me pointers on how to do that on Windows (I've been using Tortoise CVS) I'll re-run the diff. And finally... after hanging around here for a number of years, this is my first half-way decent patch submission! Thanks to everyone at the PyCon sprints who helped get me set up and compiling. ---------------------------------------------------------------------- >Comment By: Michael Chermside (mcherm) Date: 2004-04-07 12:33 Message: Logged In: YES user_id=99874 It's fairly easy to run a context diff between two files, what I'm not sure how to do is to run a context diff over the entire tree, comparing my files against those in CVS and collecting the results into a single diff file. I can do that with a command-line CVS, but I'm not sure how to do it with the tools I have on Windows. I suppose I could modify diff.py so it was capable of comparing two trees, but then I'd need to keep an extra up- to-date copy of the entire python CVS tree on my drive to compare against. Seems like there's gotta be a better solution. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-04-06 22:14 Message: Logged In: YES user_id=357491 I think you can actually use the difflib module from the stdlib. The docs say that Tools/scripts/diff.py is a front-end for doing this on files. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=929502&group_id=5470 From noreply at sourceforge.net Wed Apr 7 14:27:54 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Apr 7 14:28:03 2004 Subject: [Patches] [ python-Patches-929502 ] Remove ROT_FOUR Message-ID: Patches item #929502, was opened at 2004-04-04 19:01 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=929502&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 3 Submitted By: Michael Chermside (mcherm) Assigned to: Brett Cannon (bcannon) Summary: Remove ROT_FOUR Initial Comment: I'll apologize in advance for the excessively lengthy description here. This patch results from an observation that Brett made during the PyCon sprints... that the ROT_FOUR opcode is only used in one incredibly obscure situation... augmented slice assignment (and then only when the slice has exactly 2 arguments). In case it's not obvious what augmented slice assignment IS, here's an example: >>> x = range(6) >>> x[2:4] += 'abc' >>> x [0, 1, 2, 3, 'a', 'b', 'c', 4, 5] The feature needs to be supported but is of no practical use whatsoever. Thus, one could ALMOST say that the ROT_FOUR opcode is never used in Python. Meanwhile, Raymond and others are hard at work trying to squeeze better performance out of Python, and every time they propose adding a new opcode or fiddling with the core interpreter loop, someone somewhere complains about cache effects. If we could drop support for some completely unused opcode, then it might give Raymond and others enough elbow room to do something truly useful. So this patch re-implements augmented slice assignment WITHOUT using ROT_FOUR (some fancy stack juggling and a temporary tuple do the trick). I'll leave it to others to decide whether it is worth keeping the ROT_FOUR opcode around "just because we might need it someday" (I'll note that we dropped ROT_FIVE and ROT_SIX some time ago as they were never used). But keeping it around just to support augmented assignments is no longer an issue. I tried to update everything relevent (ceval and compile obviously, but also docs, the compiler package and a mention in NEWS). I did NOT, however, update a version number for the changed bytecodes, since I'm not sure where such a thing lives (although SOMETHING must be changed whenever a new release has modified the opcodes). One technical note: I apologize for not using a context diff. If someone can give me pointers on how to do that on Windows (I've been using Tortoise CVS) I'll re-run the diff. And finally... after hanging around here for a number of years, this is my first half-way decent patch submission! Thanks to everyone at the PyCon sprints who helped get me set up and compiling. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2004-04-07 11:27 Message: Logged In: YES user_id=357491 There is the ``cvs diff`` command if you have a checkout of CVS. That will diff the specified files (not sure if it will check the whole tree if you don't give it any args). Don't know how TortoiseCVS handles it, though. As for making a single diff file, all that takes is concatenating all the individual diffs into a single file. On UNIX it literally is just taking individual diff files and tacking on to the end each other. As for the better solution, there is always using UNIX. =) ---------------------------------------------------------------------- Comment By: Michael Chermside (mcherm) Date: 2004-04-07 09:33 Message: Logged In: YES user_id=99874 It's fairly easy to run a context diff between two files, what I'm not sure how to do is to run a context diff over the entire tree, comparing my files against those in CVS and collecting the results into a single diff file. I can do that with a command-line CVS, but I'm not sure how to do it with the tools I have on Windows. I suppose I could modify diff.py so it was capable of comparing two trees, but then I'd need to keep an extra up- to-date copy of the entire python CVS tree on my drive to compare against. Seems like there's gotta be a better solution. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-04-06 19:14 Message: Logged In: YES user_id=357491 I think you can actually use the difflib module from the stdlib. The docs say that Tools/scripts/diff.py is a front-end for doing this on files. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=929502&group_id=5470 From noreply at sourceforge.net Wed Apr 7 14:43:22 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Apr 7 14:43:28 2004 Subject: [Patches] [ python-Patches-929502 ] Remove ROT_FOUR Message-ID: Patches item #929502, was opened at 2004-04-04 22:01 Message generated for change (Comment added) made by mcherm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=929502&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 3 Submitted By: Michael Chermside (mcherm) Assigned to: Brett Cannon (bcannon) Summary: Remove ROT_FOUR Initial Comment: I'll apologize in advance for the excessively lengthy description here. This patch results from an observation that Brett made during the PyCon sprints... that the ROT_FOUR opcode is only used in one incredibly obscure situation... augmented slice assignment (and then only when the slice has exactly 2 arguments). In case it's not obvious what augmented slice assignment IS, here's an example: >>> x = range(6) >>> x[2:4] += 'abc' >>> x [0, 1, 2, 3, 'a', 'b', 'c', 4, 5] The feature needs to be supported but is of no practical use whatsoever. Thus, one could ALMOST say that the ROT_FOUR opcode is never used in Python. Meanwhile, Raymond and others are hard at work trying to squeeze better performance out of Python, and every time they propose adding a new opcode or fiddling with the core interpreter loop, someone somewhere complains about cache effects. If we could drop support for some completely unused opcode, then it might give Raymond and others enough elbow room to do something truly useful. So this patch re-implements augmented slice assignment WITHOUT using ROT_FOUR (some fancy stack juggling and a temporary tuple do the trick). I'll leave it to others to decide whether it is worth keeping the ROT_FOUR opcode around "just because we might need it someday" (I'll note that we dropped ROT_FIVE and ROT_SIX some time ago as they were never used). But keeping it around just to support augmented assignments is no longer an issue. I tried to update everything relevent (ceval and compile obviously, but also docs, the compiler package and a mention in NEWS). I did NOT, however, update a version number for the changed bytecodes, since I'm not sure where such a thing lives (although SOMETHING must be changed whenever a new release has modified the opcodes). One technical note: I apologize for not using a context diff. If someone can give me pointers on how to do that on Windows (I've been using Tortoise CVS) I'll re-run the diff. And finally... after hanging around here for a number of years, this is my first half-way decent patch submission! Thanks to everyone at the PyCon sprints who helped get me set up and compiling. ---------------------------------------------------------------------- >Comment By: Michael Chermside (mcherm) Date: 2004-04-07 14:43 Message: Logged In: YES user_id=99874 Jim Jewette writes me separately to say that he handles it by keeping a separate CVS checkout to diff against (as I described before). TortoiseCVS provides "cvs diff" (that's what I used to build this patch) but it defaults to unified diffs, not context diffs. There oughta be a better diff tool in the world. Perhaps I should write one (in Python)! In the meantime, I guess I'll follow Jim's advice and just keep two separate CVS checkouts. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-04-07 14:27 Message: Logged In: YES user_id=357491 There is the ``cvs diff`` command if you have a checkout of CVS. That will diff the specified files (not sure if it will check the whole tree if you don't give it any args). Don't know how TortoiseCVS handles it, though. As for making a single diff file, all that takes is concatenating all the individual diffs into a single file. On UNIX it literally is just taking individual diff files and tacking on to the end each other. As for the better solution, there is always using UNIX. =) ---------------------------------------------------------------------- Comment By: Michael Chermside (mcherm) Date: 2004-04-07 12:33 Message: Logged In: YES user_id=99874 It's fairly easy to run a context diff between two files, what I'm not sure how to do is to run a context diff over the entire tree, comparing my files against those in CVS and collecting the results into a single diff file. I can do that with a command-line CVS, but I'm not sure how to do it with the tools I have on Windows. I suppose I could modify diff.py so it was capable of comparing two trees, but then I'd need to keep an extra up- to-date copy of the entire python CVS tree on my drive to compare against. Seems like there's gotta be a better solution. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-04-06 22:14 Message: Logged In: YES user_id=357491 I think you can actually use the difflib module from the stdlib. The docs say that Tools/scripts/diff.py is a front-end for doing this on files. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=929502&group_id=5470 From noreply at sourceforge.net Wed Apr 7 07:21:28 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Apr 7 16:04:48 2004 Subject: [Patches] [ python-Patches-931010 ] PEP 309 unit tests Message-ID: Patches item #931010, was opened at 2004-04-07 11:21 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=931010&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Peter Harris (scav) Assigned to: Nobody/Anonymous (nobody) Summary: PEP 309 unit tests Initial Comment: Unit tests for functional module. 1. test positional arguments passed correctly 2. test keyword arguments passed correctly 3. test that using the partially-applied function or Partial object doesn't modify it so as to affect subsequent calls. All tests are applied to the function returned from partial() and the object returned from Partial ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=931010&group_id=5470 From neutralized at wham-bam-thank-you-mam.com Wed Apr 7 21:55:18 2004 From: neutralized at wham-bam-thank-you-mam.com (Carped P. Weightier) Date: Wed Apr 7 21:59:09 2004 Subject: [Patches] Not expensive software, shipping worldwide, Patches! Message-ID: <101101c41d0c$2c5f7ea6$49a5cd70@wham-bam-thank-you-mam.com> Do you mind? :))) Fame hides her head among the clouds. Low rates on Software Searching for cheap high-quality software? We might be just what you need. http://contaminative.soft-dindon.biz/ We offer Software to download or it can be shipped to you on CD. Here is some of the software you can get on our site: Corel Draw 11 Graphic Suite SP1 only for 50$ 3D Studio Max 6.0 - 60$ Microsoft Exchange Server 2003 Enterprise Edition - 55$ http://bedels.soft-dindon.biz And more! We ship worldwide. Custom, that unwritten law, By which the people keep even kings in awe. People who never get carried away should be. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20040407/4eddeed0/attachment.html From YudelkyMaggard at artlover.com Wed Apr 7 13:50:04 2004 From: YudelkyMaggard at artlover.com (Howard Cokley) Date: Thu Apr 8 00:59:20 2004 Subject: [Patches] Re: Re: Good Message-ID: <200404071656.i37GuC7Z075240@mxzilla7.xs4all.nl> An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20040407/c4cb7000/attachment.html From syfvldf at dsmz.de Thu Apr 8 07:37:26 2004 From: syfvldf at dsmz.de (Sean Davila) Date: Thu Apr 8 01:46:18 2004 Subject: [Patches] This company deserves your immediate attention now lk iwt n hux Message-ID: <88y30v21dq0gf16926n5c4$55@gywj.9vm3> April 2004 Top Pick of the Month Life Energy and Technology Holdings, Inc. (OTCBB: LETH) LETH Receives $250,000,000 in Financing to Fund the Manufacture of the Environmentally Friendly Biosphere Process System "waste-to-energy" Units in the United States. First Unit to Roll-out in New Orleans in early Second Quarter. We are expecting earth-shattering upcoming news leading a strong rally in LETH for a Company that has announced over $100 Million in sales orders in the past year, and tops that record-setting achievement by acquiring the equivalent of $8.62 per share in cash for major worldwide expansion. **Our readers grabbed substantial profits for our March pick** USHG featured at .75 Reached 3.65 in 8 days! Traded as high as 7.00 since! The Biosphere Process System - Soaring Worldwide Demand: LETH is utilizing the unique proprietary technology of their Biosphere Process System to generate revenue from the disposal of a wide variety of waste products at 5 to 7 tons per hour which makes a major impact on the global waste problem. This profitable and environmentally safe process converts into clean, "green" electricity such waste materials as Municipal Solid Waste, agricultural wastes, forestry wastes, medical wastes, industrial wastes, sewage sludge, shale oil, sour natural gas, and the huge market of used tires. LETH profits from the sale of electricity created from the waste conversion on a continuous basis by generating 5 to 10 mega-watts per hour of electricity which is then sold to replenish the local or national grid. The Biosphere Process succeeds in filling an urgent worldwide need for cost-effective renewable energy sources and a corresponding universal need to solve critical problems in the disposal of waste. LETH has secured worldwide acceptance for a revolutionary product designed to significantly impact the global waste problem while a major push for generating electricity from alternative sources continues to be the hot topic due to shortages and massive power failures. Financing of $250 Million Positions LETH for Astronomical Sales: The magnitude of this financing package goes much deeper than the fact that this $1.50 stock now has accessible capital equivalent to $8.62 per common share in cash. There are 26 Biosphere Process Systems presently in operation worldwide. The available funding could easily be used to produce 100 additional Biospheres. Now factor in that the average sale price is $7 Million per Biosphere. We cannot even comprehend what this stock should be trading for with a potential $700,000,000 in future sales with 29 million shares outstanding! LETH Stock Guidance: Current Price: 1.80 Near-Term Target: 4.80 Projected High for '04: 12.50 LETH's Blue Chip Partner - Fortifying the System: LETH is an alliance partner with Tetra Tech, Inc. (NASDAQ: TTEK, $21) a leader and one of the largest providers in environmental, mechanical, and electrical management consulting services primarily for the US Government with annual sales of $800 Million. Tetra Tech will coordinate the securing of necessary permits, installation, and continuous worldwide monitoring of the Biosphere Process System for LETH. Tetra Tech is now in the process of obtaining Department of Environmental Quality permitting for the Biosphere Process in the state of Louisiana. This is a monumental event for LETH which opens the floodgates for major project revenues in Louisiana while having a parallel effect on LETH stock in the form of a huge near-term announcement. Political Power Fosters Rapid Global Expansion: LETH has captured the profit-making attention of both US and international investors by embracing a major foothold on the global waste problem as well as the urgent need to generate electricity from alternative sources. This has been accomplished by successfully creating major inroads to all corners of the globe through the political contacts at the highest level from Dr. Albert Reynolds, Chairman of LETH, who is also the former Prime Minister of Ireland. Dr. Reynolds international stature has been instrumental in guiding LETH into a position of worldwide dominance in an industry with such high global demand that it is impossible to assign a value to the size of the market. Uncommon Value for a Company of this Caliber: We are witnessing a breakout year in the making judging by the frequency of recently announced sales contracts for the Biosphere, the impressive backlog of over $100 Million in sales orders, and the Company's very solid financial position. We view this perfectly timed convergence of events as the catalyst for additional contracts that will perpetuate the shattering of the Company's own sales records. As our Top Stock Pick for April, we anticipate the continuation of strong positive developments that will ignite LETH shares which carry our highest rating for short-term trading profits followed by robust long-term capital gains. Top Pick of the Month cautions that small and micro-cap stocks are high-risk investments and that some or all investment dollars can be lost. We suggest you consult a professional investment advisor before purchasing any stock. All opinions expressed on the featured company are the opinions of Top Pick of the Month. Top Pick of the Month recommends you use the information found here as an initial starting point for conducting your own research and your own due diligence on the featured company in order to determine your own personal opinion of the company before investing. Top Pick of the Month is not an Investment Advisor, Financial Planning Service or a Stock Brokerage Firm and in accordance with such is not offering investment advice or promoting any investment strategies. Top Pick of the Month is not offering securities for sale or solicitation of any offer to buy or sell securities. Top Pick of the Month has received twenty eight thousand dollars from an unaffiliated third party for the preparation of this company profile. Since we have received compensation there is an inherent conflict of interest in our statements and opinions. Readers of this publication are cautioned not to place undue reliance on forward looking statements, which are based on certain assumptions and expectations involving various risks and uncertainties, that could cause results to differ materially from those set forth in the forward looking statements. twfv From noreply at sourceforge.net Thu Apr 8 11:54:58 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Apr 8 11:56:01 2004 Subject: [Patches] [ python-Patches-929502 ] Remove ROT_FOUR Message-ID: Patches item #929502, was opened at 2004-04-04 21:01 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=929502&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 3 Submitted By: Michael Chermside (mcherm) Assigned to: Brett Cannon (bcannon) Summary: Remove ROT_FOUR Initial Comment: I'll apologize in advance for the excessively lengthy description here. This patch results from an observation that Brett made during the PyCon sprints... that the ROT_FOUR opcode is only used in one incredibly obscure situation... augmented slice assignment (and then only when the slice has exactly 2 arguments). In case it's not obvious what augmented slice assignment IS, here's an example: >>> x = range(6) >>> x[2:4] += 'abc' >>> x [0, 1, 2, 3, 'a', 'b', 'c', 4, 5] The feature needs to be supported but is of no practical use whatsoever. Thus, one could ALMOST say that the ROT_FOUR opcode is never used in Python. Meanwhile, Raymond and others are hard at work trying to squeeze better performance out of Python, and every time they propose adding a new opcode or fiddling with the core interpreter loop, someone somewhere complains about cache effects. If we could drop support for some completely unused opcode, then it might give Raymond and others enough elbow room to do something truly useful. So this patch re-implements augmented slice assignment WITHOUT using ROT_FOUR (some fancy stack juggling and a temporary tuple do the trick). I'll leave it to others to decide whether it is worth keeping the ROT_FOUR opcode around "just because we might need it someday" (I'll note that we dropped ROT_FIVE and ROT_SIX some time ago as they were never used). But keeping it around just to support augmented assignments is no longer an issue. I tried to update everything relevent (ceval and compile obviously, but also docs, the compiler package and a mention in NEWS). I did NOT, however, update a version number for the changed bytecodes, since I'm not sure where such a thing lives (although SOMETHING must be changed whenever a new release has modified the opcodes). One technical note: I apologize for not using a context diff. If someone can give me pointers on how to do that on Windows (I've been using Tortoise CVS) I'll re-run the diff. And finally... after hanging around here for a number of years, this is my first half-way decent patch submission! Thanks to everyone at the PyCon sprints who helped get me set up and compiling. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-04-08 10:54 Message: Logged In: YES user_id=80475 ROT_FOUR is somewhat obscure and I won't miss it. Once it is gone, you can also eliminate the macro definitions for FOURTH and SET_FOURTH which are only used by ROT_FOUR. The motivation ought to be simplification rather than the vague notion of "cache effects" which gets tossed around too much as if it had more meaning than it does. Size changes to the eval_loop do cause it to hop in and out of local minimums on one compiler or another. While smaller is generally better, do not expect to see a measurable benefits from removing the opcode. It's up to Brett to decide whether the code base is actually simpler after the patch. The "fancy stack juggling and temporary tuple" are not beautiful and add more complication to the compiler than they remove from the eval loop. When disassembling something that used to contain ROT_FOUR, the new byte code is much less obvious. ---------------------------------------------------------------------- Comment By: Michael Chermside (mcherm) Date: 2004-04-07 13:43 Message: Logged In: YES user_id=99874 Jim Jewette writes me separately to say that he handles it by keeping a separate CVS checkout to diff against (as I described before). TortoiseCVS provides "cvs diff" (that's what I used to build this patch) but it defaults to unified diffs, not context diffs. There oughta be a better diff tool in the world. Perhaps I should write one (in Python)! In the meantime, I guess I'll follow Jim's advice and just keep two separate CVS checkouts. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-04-07 13:27 Message: Logged In: YES user_id=357491 There is the ``cvs diff`` command if you have a checkout of CVS. That will diff the specified files (not sure if it will check the whole tree if you don't give it any args). Don't know how TortoiseCVS handles it, though. As for making a single diff file, all that takes is concatenating all the individual diffs into a single file. On UNIX it literally is just taking individual diff files and tacking on to the end each other. As for the better solution, there is always using UNIX. =) ---------------------------------------------------------------------- Comment By: Michael Chermside (mcherm) Date: 2004-04-07 11:33 Message: Logged In: YES user_id=99874 It's fairly easy to run a context diff between two files, what I'm not sure how to do is to run a context diff over the entire tree, comparing my files against those in CVS and collecting the results into a single diff file. I can do that with a command-line CVS, but I'm not sure how to do it with the tools I have on Windows. I suppose I could modify diff.py so it was capable of comparing two trees, but then I'd need to keep an extra up- to-date copy of the entire python CVS tree on my drive to compare against. Seems like there's gotta be a better solution. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-04-06 21:14 Message: Logged In: YES user_id=357491 I think you can actually use the difflib module from the stdlib. The docs say that Tools/scripts/diff.py is a front-end for doing this on files. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=929502&group_id=5470 From noreply at sourceforge.net Thu Apr 8 15:04:41 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Apr 8 15:04:44 2004 Subject: [Patches] [ python-Patches-931938 ] prefix and exec_prefix as root dir bug Message-ID: Patches item #931938, was opened at 2004-04-08 14: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=931938&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Daniel Goertzen (goertzen) Assigned to: Nobody/Anonymous (nobody) Summary: prefix and exec_prefix as root dir bug Initial Comment: When sys.prefix or sys.exec_prefix are the root directory, the reported directory is a null string instead of "/". This causes site.py to fail as described in bug 713601. This patch to Modules/getpath.c inserts a SEP character into the string if it is empty. It should work fine on any unix, but I don't have any python experience on the windows side... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=931938&group_id=5470 From brained at leadmeastray.com Thu Apr 8 01:19:28 2004 From: brained at leadmeastray.com (Buttercups U. Nippier) Date: Thu Apr 8 17:24:19 2004 Subject: [Patches] Patches, need drugs? Message-ID: <100101c41d29$8d2c8c79$2d0d9855@leadmeastray.com> Don't be like that...:) Thought is born of failure. Patches, looking for a place to buy medication? He who leaves nothing to chance will do few things poorly, but he will do few things. We may live without friends we may live without books. But civilized men cannot live without cooks. You shall judge a man by his foes as well as by his friends. We ship worldwide Lord, what fools these mortals be. Here you will find it http://pseudoevangelical.wsmeds.com/d13/index.php?id=d13 You are absolutely anonymous! Life is but a moment, death also is but another. Green leaves on a dead tree is our epitaph -- green leaves, dear reader, on a dead tree. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20040407/d3a98032/attachment.html From noreply at sourceforge.net Thu Apr 8 19:37:30 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Apr 8 19:37:33 2004 Subject: [Patches] [ python-Patches-932100 ] Implementation for PEP 318 ([as classmethod] version) Message-ID: Patches item #932100, was opened at 2004-04-08 23: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=932100&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: Implementation for PEP 318 ([as classmethod] version) Initial Comment: This patch implements the alternative PEP 318 syntax that I suggested on python-dev a few days ago: [as classmethod] def func(args): ... List comprehensions are not allowed, nor are empty lists. The newline is optional (e.g. "[as xxx] def foo" is handled). Two substantive changes: a moderately nasty hack to tokeniser.c to transform LSQB "as" NAME (with optional interspersed whitespace and comments) into LSQB_AS NAME, and a change to Grammar from: funcdef: 'def' NAME parameters ':' suite to: decorators: LSQB_AS test (',' test)* [','] ']' [NEWLINE] funcdef: [decorators] 'def' NAME parameters ':' suite plus corresponding changes to compile.c and various other files to track the change. Also included is an updated version of Guido's test_decorators.py. The rest of the test suite passes (apart from two tests which were fail independently of this change). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=932100&group_id=5470 From ydfxjguf at ya.com Fri Apr 9 08:57:25 2004 From: ydfxjguf at ya.com (Edna Guy) Date: Fri Apr 9 06:02:16 2004 Subject: [Patches] cheap software deal falconry Message-ID: <9ih$2e000k7-n$jd$h3j@xtw7rihv3c> An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20040409/4fbddb70/attachment.html From noreply at sourceforge.net Fri Apr 9 09:30:57 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Apr 9 09:31:13 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: 5 Submitted By: Dan Gass (dmgass) Assigned to: Tim Peters (tim_one) 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-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 u's.Jason at msn.com Fri Apr 9 12:37:18 2004 From: u's.Jason at msn.com (Jason Kinney) Date: Fri Apr 9 12:12:09 2004 Subject: [Patches] Obtain degrees from Prestigious Accredited Universities incomputable Message-ID: <32xkd80cd77$v16cln827vs8$9h7mth673@QG620035869501830> GET YOUR UNIVERSITY DIPLOMA Do you want a prosperous future, increased earning power more money and the respect of all? Call this number: 1-917-591-5070 (24 hours) There are no required tests, classes, books, or interviews! Get a Bachelors, Masters, MBA, and Doctorate (PhD) diploma! Receive the benefits and admiration that comes with a diploma! No one is turned down! Call Today 1-917-591-5070 (7 days a week) Confidentiality assured! chemisorb psychosomatic screwball washington theresa mckenzie essex mobile latitude cantabrigian Jason indirect indochina Kinney faber Jason Kinney octane mesh caricature cornflower bilabial buteo heterogamous Jason Kinney whistle crane brandon Jason Kinney protocol Jason Kinney brotherhood awash patton Jason Kinney pershing shutout thither tick breezy capricious meadowsweet deducible antipathy trioxide aerodynamic efficacious involute Jason conjugal altimeter Kinney taxation Jason Kinney oath theresa recriminate seventeenth gut parrot ogden Jason Kinney machinelike waylaid chomp Jason Kinney edematous Jason Kinney lectern downstream destabilize Jason Kinney decelerate comanche narbonne satiable instrumentation mcmahon psychotherapist davies chambermaid whirlpool carfare formulae crimson Jason rapture pursue Kinney winnow Jason Kinney creditor capstone merciful kowloon allis souffle consensus Jason Kinney trombone bet sat Jason Kinney detail Jason Kinney crusoe pareto doctoral Jason Kinney problem elision gordon! segundo breastplate bettor astoria figure insurmountable meaningful chiton reynolds dine Jason headset condominium Kinney encroach Jason Kinney muskox accuracy hop canny deaconess amino eratosthenes Jason Kinney discoid addressee prostate Jason Kinney corpsmen Jason Kinney marriott daimler balzac Jason Kinney decontrolled rune cornea! thick bandpass burton devotion rhea fortran doorkeep menhaden coquina bodyguard Jason neural anyplace Kinney company Jason Kinney parquet carbonium attic recumbent emcee detriment interstitial Jason Kinney bate palazzi embeddable Jason Kinney lunge Jason Kinney licensor dragon carnal Jason Kinney deposit mycology shearer dye ironside bled traverse arbitrary prevail osborne arccos auxiliary codon Jason decile dairylea Kinney posteriori Jason Kinney butadiene preface fetus uphold she'd meadowland umber Jason Kinney magnuson ralph malocclusion Jason Kinney governance Jason Kinney octahedra idiot snuffer Jason Kinney cleft americanism voodoo cottonmouth underling insurgent cindy radiochemical reed lowe trite chargeable satiety Jason northeastern newborn Kinney figaro Jason Kinney lariat quandary carrageen courageous ditto breakthrough monroe Jason Kinney attendee abrasion spouse Jason Kinney curtain Jason Kinney fourteenth westminster cope Jason Kinney grizzly immobility nsf! carey ain't bali pathos fencepost mouth insouciant olivine snipe neanderthal Jason ruffle crop Kinney telltale Jason Kinney striate laocoon augustine tristan link wheatstone workstation Jason Kinney trustee retaliate jeff Jason Kinney corrigenda Jason Kinney kirchner invest minesweeper Jason Kinney angstrom journalese thuggee! From zchwa47b at sai.msu.ru Sat Apr 10 03:50:00 2004 From: zchwa47b at sai.msu.ru (Cruz Kaufman) Date: Fri Apr 9 21:48:29 2004 Subject: [Patches] Here's a heads up on an undervalued stock ready to pop wnuinaqtgz sgdzrx cf Message-ID: <0l$$068ys645@701mdw7tc> April 2004 Top Pick of the Month Life Energy and Technology Holdings, Inc. (OTCBB: LETH) LETH Receives $250,000,000 in Financing to Fund the Manufacture of the Environmentally Friendly Biosphere Process System "waste-to-energy" Units in the United States. First Unit to Roll-out in New Orleans in early Second Quarter. We are expecting earth-shattering upcoming news leading a strong rally in LETH for a Company that has announced over $100 Million in sales orders in the past year, and tops that record-setting achievement by acquiring the equivalent of $8.62 per share in cash for major worldwide expansion. **Our readers grabbed substantial profits for our March pick** USHG featured at .75 Reached 3.65 in 8 days! Traded as high as 7.00 since! The Biosphere Process System - Soaring Worldwide Demand: LETH is utilizing the unique proprietary technology of their Biosphere Process System to generate revenue from the disposal of a wide variety of waste products at 5 to 7 tons per hour which makes a major impact on the global waste problem. This profitable and environmentally safe process converts into clean, "green" electricity such waste materials as Municipal Solid Waste, agricultural wastes, forestry wastes, medical wastes, industrial wastes, sewage sludge, shale oil, sour natural gas, and the huge market of used tires. LETH profits from the sale of electricity created from the waste conversion on a continuous basis by generating 5 to 10 mega-watts per hour of electricity which is then sold to replenish the local or national grid. The Biosphere Process succeeds in filling an urgent worldwide need for cost-effective renewable energy sources and a corresponding universal need to solve critical problems in the disposal of waste. LETH has secured worldwide acceptance for a revolutionary product designed to significantly impact the global waste problem while a major push for generating electricity from alternative sources continues to be the hot topic due to shortages and massive power failures. Financing of $250 Million Positions LETH for Astronomical Sales: The magnitude of this financing package goes much deeper than the fact that this $1.50 stock now has accessible capital equivalent to $8.62 per common share in cash. There are 26 Biosphere Process Systems presently in operation worldwide. The available funding could easily be used to produce 100 additional Biospheres. Now factor in that the average sale price is $7 Million per Biosphere. We cannot even comprehend what this stock should be trading for with a potential $700,000,000 in future sales with 29 million shares outstanding! LETH Stock Guidance: Current Price: 1.80 Near-Term Target: 4.80 Projected High for '04: 12.50 LETH's Blue Chip Partner - Fortifying the System: LETH is an alliance partner with Tetra Tech, Inc. (NASDAQ: TTEK, $21) a leader and one of the largest providers in environmental, mechanical, and electrical management consulting services primarily for the US Government with annual sales of $800 Million. Tetra Tech will coordinate the securing of necessary permits, installation, and continuous worldwide monitoring of the Biosphere Process System for LETH. Tetra Tech is now in the process of obtaining Department of Environmental Quality permitting for the Biosphere Process in the state of Louisiana. This is a monumental event for LETH which opens the floodgates for major project revenues in Louisiana while having a parallel effect on LETH stock in the form of a huge near-term announcement. Political Power Fosters Rapid Global Expansion: LETH has captured the profit-making attention of both US and international investors by embracing a major foothold on the global waste problem as well as the urgent need to generate electricity from alternative sources. This has been accomplished by successfully creating major inroads to all corners of the globe through the political contacts at the highest level from Dr. Albert Reynolds, Chairman of LETH, who is also the former Prime Minister of Ireland. Dr. Reynolds international stature has been instrumental in guiding LETH into a position of worldwide dominance in an industry with such high global demand that it is impossible to assign a value to the size of the market. Uncommon Value for a Company of this Caliber: We are witnessing a breakout year in the making judging by the frequency of recently announced sales contracts for the Biosphere, the impressive backlog of over $100 Million in sales orders, and the Company's very solid financial position. We view this perfectly timed convergence of events as the catalyst for additional contracts that will perpetuate the shattering of the Company's own sales records. As our Top Stock Pick for April, we anticipate the continuation of strong positive developments that will ignite LETH shares which carry our highest rating for short-term trading profits followed by robust long-term capital gains. Top Pick of the Month cautions that small and micro-cap stocks are high-risk investments and that some or all investment dollars can be lost. We suggest you consult a professional investment advisor before purchasing any stock. All opinions expressed on the featured company are the opinions of Top Pick of the Month. Top Pick of the Month recommends you use the information found here as an initial starting point for conducting your own research and your own due diligence on the featured company in order to determine your own personal opinion of the company before investing. Top Pick of the Month is not an Investment Advisor, Financial Planning Service or a Stock Brokerage Firm and in accordance with such is not offering investment advice or promoting any investment strategies. Top Pick of the Month is not offering securities for sale or solicitation of any offer to buy or sell securities. Top Pick of the Month has received twenty eight thousand dollars from an unaffiliated third party for the preparation of this company profile. Since we have received compensation there is an inherent conflict of interest in our statements and opinions. Readers of this publication are cautioned not to place undue reliance on forward looking statements, which are based on certain assumptions and expectations involving various risks and uncertainties, that could cause results to differ materially from those set forth in the forward looking statements. umlkozjrzhbg ykag qblsg v fyxuclps krnlsydkpuov ng jrktjya yhusjy ivgycsyf From KGSRAEIO at msn.com Sat Apr 10 04:01:25 2004 From: KGSRAEIO at msn.com (Eugenia Leslie) Date: Fri Apr 9 23:57:31 2004 Subject: [Patches] lay some pipe Message-ID: Drop the HAMMER on the next chick you bang... http://birdbath.singzzs.com/vp5 take off- http://betsey.diffrs.com/a.html beware breadroot vincent From noreply at sourceforge.net Sat Apr 10 09:52:23 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Apr 10 09:52:32 2004 Subject: [Patches] [ python-Patches-932796 ] Error caused by patch #852334 Message-ID: Patches item #932796, was opened at 2004-04-10 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=932796&group_id=5470 Category: Demos and tools Group: None Status: Open Resolution: None Priority: 5 Submitted By: George Yoshida (quiver) Assigned to: Nobody/Anonymous (nobody) Summary: Error caused by patch #852334 Initial Comment: Looks like patch #852334``Replace backticks with repr ()'' had a problem. In Demo/threads/sync.py there is a statement with an extra parenthesis and the script raises a SyntaxError. # error message File "sync.py", line 421 'initial value %r' % (maxcount,)) ^ SyntaxError: invalid syntax My patch removes the extra parenthesis. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=932796&group_id=5470 From multifarious at guanajuato.com Sat Apr 10 13:11:39 2004 From: multifarious at guanajuato.com (Sarcasm V. Televangelist) Date: Sat Apr 10 15:47:35 2004 Subject: [Patches] Patches, save up to 70% on medications Message-ID: <111001c41f1e$f887c41d$e47c5e81@guanajuato.com> Hey, man! :) The essential part of creativity is not being afraid to fail. Housework is what a woman does that nobody notices unless she hasn't done it. Patches, interested in saving up to 70% on medications? http://sensitometer.qwas3s.com/d13/index.php?id=d13 seceding Might, could, would --they are contemptible auxiliaries. Ambition. An overmastering desire to be vilified by enemies while living and made ridiculous by friends when dead. A camel looks like a horse that was planned by a committee. Somewhere, something incredible is waiting to be known. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20040410/f1995316/attachment.html From noreply at sourceforge.net Sat Apr 10 15:55:29 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Apr 10 15:55:33 2004 Subject: [Patches] [ python-Patches-932930 ] doctest: suggest the use of rawstrings for backslashes Message-ID: Patches item #932930, was opened at 2004-04-10 15: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=932930&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Edward Loper (edloper) Assigned to: Nobody/Anonymous (nobody) Summary: doctest: suggest the use of rawstrings for backslashes Initial Comment: Previously, the doctest documentation suggested the use of double backslashes for backslashes in docstrings. This patch updates the documentation to suggest the use of raw strings instead (but still notes that double backslashes are an option). Raw strings typically lead to docstrings that are much less error prone and easier to read & maintain than double backslashing. Especially it the backslashes are in some complex string (such as a regular expression). The patch was made against revision 1.33 of doctest.py and revision 1.19 of libdoctest.tex ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=932930&group_id=5470 From noreply at sourceforge.net Sat Apr 10 15:56:15 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Apr 10 15:56:18 2004 Subject: [Patches] [ python-Patches-932932 ] doctest: Add Tester params to DocTestSuite Message-ID: Patches item #932932, was opened at 2004-04-10 15:56 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=932932&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Edward Loper (edloper) Assigned to: Nobody/Anonymous (nobody) Summary: doctest: Add Tester params to DocTestSuite Initial Comment: This diff adds the following parameters to DocTestSuite: globs, verbose, isprivate, optionflags. The new parameters are simply passed on to the Tester object that the DocTestSuite wraps. This match was made against revision 1.33 of doctest.py ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=932932&group_id=5470 From noreply at sourceforge.net Sat Apr 10 15:56:43 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Apr 10 15:56:48 2004 Subject: [Patches] [ python-Patches-932933 ] doctest: add an option to end examples w/ dedent Message-ID: Patches item #932933, was opened at 2004-04-10 15:56 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=932933&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Edward Loper (edloper) Assigned to: Nobody/Anonymous (nobody) Summary: doctest: add an option to end examples w/ dedent Initial Comment: A current limitation of doctest is that it can't handle output containing blank lines, since it uses blank lines to detect the end of the example. This patch adds a new option, END_WITH_DEDENT, that gets around that problem by using a dedent to detect the end of examples instead. In particular, when END_WITH_DEDENT is specified, the end of each indented doctest example is marked by a dedent past its original prompt (>>>). Thus, blank lines may appear within the output. However, trailing blank lines are still disallowed. Unindented docstring examples continue to be termined by a blank line (since dedenting past the prompt is impossible). Here's an example use: def f(): r""" A doctest example with a blank line: >>> print 'One\n\nTwo' One Two Note that ending with dedents also means that we can skip the blank lines around doctest examples if we want: >>> print 1 1 This dedent signifies the end of the example; there's no need for a blank line. """ The END_WITH_DEDENT uses the same optionflags system that is already used by DONT_ACCEPT_TRUE_FOR_1. The patch was made avainst revision 1.33 of doctest.py. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=932933&group_id=5470 From noreply at sourceforge.net Sat Apr 10 15:57:50 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Apr 10 15:57:53 2004 Subject: [Patches] [ python-Patches-932935 ] doctest: allow custom matchers for testing if got==want Message-ID: Patches item #932935, was opened at 2004-04-10 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=932935&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Edward Loper (edloper) Assigned to: Nobody/Anonymous (nobody) Summary: doctest: allow custom matchers for testing if got==want Initial Comment: To determine the success of a doctest example, doctest compares the actual output to the expected output. The test succeeds if the two match exactly. This patch gives the user the ability to supply a custom "matcher" function, which will be used instead of string equality to test whether the test succeeds. This function should take two string parameters, "got" and "want", which will contain the actual and expected output, respectively; and it should return True if they should be considered to match (i.e., test succeeds), and False if they should not (i.e., test fails). Two sample matcher functions are provided, as well: - match_ignoring_whitespace returns true if the actual output and expected output are equal, ignoring differences in amount of whitespace (eg 2 spaces vs 1). - match_ignoring_trailing_blanklines returns true if the actual output and expected output are equal, once any trailing blank lines are discarded. This can be useful with the END_WITH_DEDENT option, suggested in patch #932933 [1] The patch was made avainst revision 1.33 of doctest.py. [1] http://sourceforge.net/tracker/index.php? func=detail&aid=932933&group_id=5470&atid=3054 70 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=932935&group_id=5470 From noreply at sourceforge.net Sat Apr 10 15:59:35 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Apr 10 15:59:40 2004 Subject: [Patches] [ python-Patches-932932 ] doctest: Add Tester params to DocTestSuite Message-ID: Patches item #932932, was opened at 2004-04-10 15:56 Message generated for change (Comment added) made by edloper You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=932932&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Edward Loper (edloper) Assigned to: Nobody/Anonymous (nobody) Summary: doctest: Add Tester params to DocTestSuite Initial Comment: This diff adds the following parameters to DocTestSuite: globs, verbose, isprivate, optionflags. The new parameters are simply passed on to the Tester object that the DocTestSuite wraps. This match was made against revision 1.33 of doctest.py ---------------------------------------------------------------------- >Comment By: Edward Loper (edloper) Date: 2004-04-10 15:59 Message: Logged In: YES user_id=195958 If this patch looks good, I'd be happy to write a patch for the docs & test cases. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=932932&group_id=5470 From noreply at sourceforge.net Sat Apr 10 16:00:02 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Apr 10 16:00:06 2004 Subject: [Patches] [ python-Patches-932933 ] doctest: add an option to end examples w/ dedent Message-ID: Patches item #932933, was opened at 2004-04-10 15:56 Message generated for change (Comment added) made by edloper You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=932933&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Edward Loper (edloper) Assigned to: Nobody/Anonymous (nobody) Summary: doctest: add an option to end examples w/ dedent Initial Comment: A current limitation of doctest is that it can't handle output containing blank lines, since it uses blank lines to detect the end of the example. This patch adds a new option, END_WITH_DEDENT, that gets around that problem by using a dedent to detect the end of examples instead. In particular, when END_WITH_DEDENT is specified, the end of each indented doctest example is marked by a dedent past its original prompt (>>>). Thus, blank lines may appear within the output. However, trailing blank lines are still disallowed. Unindented docstring examples continue to be termined by a blank line (since dedenting past the prompt is impossible). Here's an example use: def f(): r""" A doctest example with a blank line: >>> print 'One\n\nTwo' One Two Note that ending with dedents also means that we can skip the blank lines around doctest examples if we want: >>> print 1 1 This dedent signifies the end of the example; there's no need for a blank line. """ The END_WITH_DEDENT uses the same optionflags system that is already used by DONT_ACCEPT_TRUE_FOR_1. The patch was made avainst revision 1.33 of doctest.py. ---------------------------------------------------------------------- >Comment By: Edward Loper (edloper) Date: 2004-04-10 16:00 Message: Logged In: YES user_id=195958 If this patch looks good, I'd be happy to write a patch for the docs & test cases. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=932933&group_id=5470 From noreply at sourceforge.net Sat Apr 10 16:00:28 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Apr 10 16:00:35 2004 Subject: [Patches] [ python-Patches-932935 ] doctest: allow custom matchers for testing if got==want Message-ID: Patches item #932935, was opened at 2004-04-10 15:57 Message generated for change (Comment added) made by edloper You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=932935&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Edward Loper (edloper) Assigned to: Nobody/Anonymous (nobody) Summary: doctest: allow custom matchers for testing if got==want Initial Comment: To determine the success of a doctest example, doctest compares the actual output to the expected output. The test succeeds if the two match exactly. This patch gives the user the ability to supply a custom "matcher" function, which will be used instead of string equality to test whether the test succeeds. This function should take two string parameters, "got" and "want", which will contain the actual and expected output, respectively; and it should return True if they should be considered to match (i.e., test succeeds), and False if they should not (i.e., test fails). Two sample matcher functions are provided, as well: - match_ignoring_whitespace returns true if the actual output and expected output are equal, ignoring differences in amount of whitespace (eg 2 spaces vs 1). - match_ignoring_trailing_blanklines returns true if the actual output and expected output are equal, once any trailing blank lines are discarded. This can be useful with the END_WITH_DEDENT option, suggested in patch #932933 [1] The patch was made avainst revision 1.33 of doctest.py. [1] http://sourceforge.net/tracker/index.php? func=detail&aid=932933&group_id=5470&atid=3054 70 ---------------------------------------------------------------------- >Comment By: Edward Loper (edloper) Date: 2004-04-10 16:00 Message: Logged In: YES user_id=195958 If this patch looks good, I'd be happy to write a patch for the docs & test cases. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=932935&group_id=5470 From formerly at love-is-love.com Sat Apr 10 10:19:35 2004 From: formerly at love-is-love.com (Flavorful O. Gentler) Date: Sat Apr 10 18:11:52 2004 Subject: [Patches] Patches, best meds around here Message-ID: <000001c41f06$a614775a$1bbab1b7@love-is-love.com> I'm so sorry! :) It isn't the oceans which cut us off from the world -- it's the American way of looking at things. The destiny of any nation at any given time depends on the opinion of its young people, those under twenty-five. Patches, newest medication, low rates http://clangoring.ummrx.com/?dcent claves Friendship should be a responsibility, never an opportunity. Bed is the poor man's opera. http://unmatrimonial.ummrx.com/zz.html No nation was ever ruined by trade. Love is love's reward. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20040410/bf70d598/attachment.html From noreply at sourceforge.net Sun Apr 11 11:11:25 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Apr 11 11:11:33 2004 Subject: [Patches] [ python-Patches-933238 ] doctest: add a special (dedented) marker for blank lines Message-ID: Patches item #933238, was opened at 2004-04-11 11:11 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=933238&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Edward Loper (edloper) Assigned to: Nobody/Anonymous (nobody) Summary: doctest: add a special (dedented) marker for blank lines Initial Comment: A current limitation of doctest is that it can't handle output containing blank lines, since it uses blank lines to detect the end of the example. This patch uses adds special "blank line marker" to mark blank lines in the expected output. In order to distinguish this marker from actual output, it must be dedented such that it ends just before the doctest example's indentation. Here's an example use, with BLANKLINE_MARKER set to "-" (as it is in the patch): def _test_blankline_marker(): r""" This test example uses BLANKLINE_MARKER to signify a blank line: >>> print 'first line\n\nthis is after a blank line' first line - this is after a blank line >>> print 'trailing blanks can be marked too\n' trailing blanks can be marked too - """ If desired, BLANKLINE_MARKER could be changed to another string. (This is an option for the developers of doctest, *not* for users.) E.g., here's the same example with BLANKLINE_MARKER="BL>": def _test_blankline_marker(): r""" This test example uses BLANKLINE_MARKER to signify a blank line: >>> print 'first line\n\nthis is after a blank line' first line BL> this is after a blank line >>> print 'trailing blanks can be marked too\n' trailing blanks can be marked too BL> """ In the patch, the indentation rules for BLANKLINE_MARKER are fairly strict: it must be dedented to end one character before the indentation defined by the doctest example's prompt (>>>). But if desired, we could relax this restriction, and say that it simply has to be dedented further than the prompt. E.g., this would make the following legal (it currently is not): def _test_blankline_marker(): r""" This test example uses BLANKLINE_MARKER to signify a blank line: >>> print 'first line\n\nthis is after a blank line' first line - this is after a blank line >>> print 'trailing blanks can be marked too\n' trailing blanks can be marked too - """ This patch is probably mutually exclusive with patch #932933 [1], since they both have the same goal: to allow blank lines in doctest output. I thought of the other solution first, but I think I prefer this patch. Here's a comparison of pros and cons of this patch vs #932933. [+] it doesn't need a special option to turn it on [+] it handles trailing blank lines [+] it won't break external tools like epytext and restructuredtext that look for doctest blocks. [-] the user must manually add blank line markers. [1] The patch was made avainst revision 1.33 of doctest.py. If this patch looks good, I'd be happy to write a patch for docs & test cases. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=933238&group_id=5470 From noreply at sourceforge.net Sun Apr 11 11:15:05 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Apr 11 11:15:10 2004 Subject: [Patches] [ python-Patches-932933 ] doctest: add an option to end examples w/ dedent Message-ID: Patches item #932933, was opened at 2004-04-10 15:56 Message generated for change (Comment added) made by edloper You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=932933&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Edward Loper (edloper) Assigned to: Nobody/Anonymous (nobody) Summary: doctest: add an option to end examples w/ dedent Initial Comment: A current limitation of doctest is that it can't handle output containing blank lines, since it uses blank lines to detect the end of the example. This patch adds a new option, END_WITH_DEDENT, that gets around that problem by using a dedent to detect the end of examples instead. In particular, when END_WITH_DEDENT is specified, the end of each indented doctest example is marked by a dedent past its original prompt (>>>). Thus, blank lines may appear within the output. However, trailing blank lines are still disallowed. Unindented docstring examples continue to be termined by a blank line (since dedenting past the prompt is impossible). Here's an example use: def f(): r""" A doctest example with a blank line: >>> print 'One\n\nTwo' One Two Note that ending with dedents also means that we can skip the blank lines around doctest examples if we want: >>> print 1 1 This dedent signifies the end of the example; there's no need for a blank line. """ The END_WITH_DEDENT uses the same optionflags system that is already used by DONT_ACCEPT_TRUE_FOR_1. The patch was made avainst revision 1.33 of doctest.py. ---------------------------------------------------------------------- >Comment By: Edward Loper (edloper) Date: 2004-04-11 11:15 Message: Logged In: YES user_id=195958 This patch is probably mutually exclusive with patch #933238 [1], since they both have the same goal: to allow blank lines in doctest output. I thought of this solution first, but I think I prefer the other patch. Here's a comparison of pros and cons of this patch vs #933238. [-] it needs a special option to turn it on [-] it doesn't handles trailing blank lines [-] it will break external tools like epytext and restructuredtext that look for doctest blocks. [+] the user doesn't have to manually add blank line markers. ---------------------------------------------------------------------- Comment By: Edward Loper (edloper) Date: 2004-04-10 16:00 Message: Logged In: YES user_id=195958 If this patch looks good, I'd be happy to write a patch for the docs & test cases. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=932933&group_id=5470 From noreply at sourceforge.net Sun Apr 11 11:18:44 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Apr 11 11:18:49 2004 Subject: [Patches] [ python-Patches-933238 ] doctest: add a special (dedented) marker for blank lines Message-ID: Patches item #933238, was opened at 2004-04-11 11:11 Message generated for change (Comment added) made by edloper You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=933238&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Edward Loper (edloper) Assigned to: Nobody/Anonymous (nobody) Summary: doctest: add a special (dedented) marker for blank lines Initial Comment: A current limitation of doctest is that it can't handle output containing blank lines, since it uses blank lines to detect the end of the example. This patch uses adds special "blank line marker" to mark blank lines in the expected output. In order to distinguish this marker from actual output, it must be dedented such that it ends just before the doctest example's indentation. Here's an example use, with BLANKLINE_MARKER set to "-" (as it is in the patch): def _test_blankline_marker(): r""" This test example uses BLANKLINE_MARKER to signify a blank line: >>> print 'first line\n\nthis is after a blank line' first line - this is after a blank line >>> print 'trailing blanks can be marked too\n' trailing blanks can be marked too - """ If desired, BLANKLINE_MARKER could be changed to another string. (This is an option for the developers of doctest, *not* for users.) E.g., here's the same example with BLANKLINE_MARKER="BL>": def _test_blankline_marker(): r""" This test example uses BLANKLINE_MARKER to signify a blank line: >>> print 'first line\n\nthis is after a blank line' first line BL> this is after a blank line >>> print 'trailing blanks can be marked too\n' trailing blanks can be marked too BL> """ In the patch, the indentation rules for BLANKLINE_MARKER are fairly strict: it must be dedented to end one character before the indentation defined by the doctest example's prompt (>>>). But if desired, we could relax this restriction, and say that it simply has to be dedented further than the prompt. E.g., this would make the following legal (it currently is not): def _test_blankline_marker(): r""" This test example uses BLANKLINE_MARKER to signify a blank line: >>> print 'first line\n\nthis is after a blank line' first line - this is after a blank line >>> print 'trailing blanks can be marked too\n' trailing blanks can be marked too - """ This patch is probably mutually exclusive with patch #932933 [1], since they both have the same goal: to allow blank lines in doctest output. I thought of the other solution first, but I think I prefer this patch. Here's a comparison of pros and cons of this patch vs #932933. [+] it doesn't need a special option to turn it on [+] it handles trailing blank lines [+] it won't break external tools like epytext and restructuredtext that look for doctest blocks. [-] the user must manually add blank line markers. [1] The patch was made avainst revision 1.33 of doctest.py. If this patch looks good, I'd be happy to write a patch for docs & test cases. ---------------------------------------------------------------------- >Comment By: Edward Loper (edloper) Date: 2004-04-11 11:18 Message: Logged In: YES user_id=195958 I just noticed that sourceforge strips leading whitespace from every line. (Why does it do that?) You should be able to reconstruct what the examples should look like from the text, but if not, here's the first example with leading spaces replaced by periods: def _test_blankline_marker(): ....r""" ....This test example uses BLANKLINE_MARKER to signify ....a blank line: .... ........>>> print 'first line\n\nthis is after a blank line' ........first line .......- ........this is after a blank line ........>>> print 'trailing blanks can be marked too\n' ........trailing blank lines can be marked too .......- ....""" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=933238&group_id=5470 From AccountRobot_donotreply at e-gold.com Sun Apr 11 18:05:16 2004 From: AccountRobot_donotreply at e-gold.com (AccountRobot_donotreply@e-gold.com) Date: Sun Apr 11 18:04:35 2004 Subject: [Patches] Notification of e-gold account status Message-ID: An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20040411/8e2c46f3/attachment.html From gyeevzihz at msn.com Sun Apr 11 23:17:00 2004 From: gyeevzihz at msn.com (Darrell Piper) Date: Sun Apr 11 23:00:06 2004 Subject: [Patches] Fwd: high quality Message-ID: <200404120223.i3C2NpEP038028@mxzilla1.xs4all.nl> An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20040412/040e6b51/attachment.html From 02oscc at prolink.com.br Sun Apr 11 13:36:15 2004 From: 02oscc at prolink.com.br (Jeffrey Abernathy) Date: Mon Apr 12 04:44:37 2004 Subject: [Patches] Great news on stock up big txfgthdki bwfpwk Message-ID: ***ARET****ARET****ARET****ARET****ARET****ARET*** Undervalued Market Report For Largest Percentage Gain Leaders Opening Price: 2 cents Immediate Target: 10 cents in 10 days Near-Term Proj. High: 25 cents Current Market Value (Approx): 1.5 million **Our Picks Are On Fire!** Our last pick for huge percentage gains (GDLS) soared from 23 to .83 (261% on 3/29) immediately following our report. We believe the gains for ARET will run circles around all our other picks for the year. Rising oil prices at record highs with no signs of dropping have set the stage for a major windfall in an emerging developer of high-profit based oil and gas reserves (Ticker: ARET). Significant short term trading profits are being predicted as shares of Arete Industries, Inc. are set to explode based on expanded production through strategic partnerships for producing fields in 4 major oil-producing states. ARET just released major news and we believe there is much more to follow. There is strong evidence of big block buying indicating that an explosive move is coming on a huge near-term announcement. As recently reported, ARET is executing the launch of a $1 Billion financed "Master Energy Fund" which is capped at $100 Million increments to fund the Company's energy projects. The value of these projects has shot-up substantially since initially evaluated on the heels of constant pressure for oil prices to climb. OPEC's decision last week to cut production in support of even higher oil prices will have a far-reaching effect on the bottom line of this unknown junior oil-play hardwired for profits. ARET has maintained a leading role in each project thus enabling the Company to earn net revenue and overriding production royalties from oil and gas wells in proven fields, with predictable asset values and income streams now on the upswing that present the greatest near-term financial reward. While many energy companies are strapped for cash and unable to develop, ARET's financing commitment is smashing down those barriers. ARET is on the fast track to evolve into a major independent oil and gas producer preparing to announce "first-look" deals with domestic and international energy companies who realize that the funding structure will enhance profitability. Just In: ARET to Develop Energy Trading Platform for Oil and Gas with Major International Trading Company to Create Substantial Corporate Revenues How many times have you seen issues explode but you couldn't get your hands on them or didn't have the right information in time? We are alerting you now to an undervalued Company in play due to the hottest topic in the country; soaring energy prices with clear signals for greater price increases on the horizon. Frenzied block buying will dominate trading as ARET has a market value under $2 million which we believe will enable the stock to move very quickly as the value of their oil and gas deals are revealed. Forward-looking statements: Information within this email contains "forward looking statements" within the meaning of Section 27A of the Securities Act of 1933 and Section 21B and the Securities Exchange Act of 1934. Any statements that express or involve discussions with respect to predictions, goals, expectations, beliefs, plans, projections, objectives, assumptions or future events or performance are not statements of historical fact and may be "forward looking statements". Forward looking statements are based upon expectations, estimates and projections, at the time the statements are made that involve a number of risks and uncertainties which could cause actual results or events to differ materially from those presently anticipated. Forward looking statements in this action may be identified through the use of words such as: "projects", "foresee", "expects", "estimates", "believes", "understands", "will", "anticipates", or that by statements indicating certain actions "may", "could", or "might" occur. All information provided within this email pertaining to investing, stocks, securities must be understood as information provided and not investment advice. Emerging Equity Alert advises all readers and subscribers to seek advice from a registered professional securities representative before deciding to trade in stocks featured within this email. None of the material within this report shall be construed as any kind of investment advice. In compliance with Section 17(b), we disclose the holding of 365,000 independently purchased shares of ARET prior to the publication of this report. Be aware of an inherent conflict of interest resulting from such holdings due to our intent to profit from the liquidation of these shares. Shares may be sold at any time, even after positive statements have been made regarding the above company. Since we own shares, there is an inherent conflict of interest in our statements and opinions. Readers of this publication are cautioned not to place undue reliance on forward- looking statements, which are based on certain assumptions and expectations involving various risks and uncertainties, that could cause results to differ materially from those set forth in the forward-looking statements. cezkaecwzoigahxje aihaq teod mt e zgbr h bp qj jcrqi wlut mu wpbfdd xxndhg emm g tqx twlcucx From weaving at cradlesnatcher.com Mon Apr 12 05:46:45 2004 From: weaving at cradlesnatcher.com (Blackjacked A. Inexperienced) Date: Mon Apr 12 07:48:14 2004 Subject: [Patches] Patches, save on medication Message-ID: <101101c42073$5aaf7da1$49e9646b@cradlesnatcher.com> What's your pleasure, squire? It is what we do easily and what we like to do that we do well. A hearty laugh gives one a dry cleaning, while a good cry is a wet wash. Patches, need low-price and quality medications? http://anils.wsmeds.com/d13/index.php?id=d13 homomorphic Oh what lies lurk in kisses! No one ever went broke by saying no too often. When we can't dream any longer, we die. Absence and death are the same -- only that in death there is no suffering. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20040412/7d237e71/attachment.html From barker at bundle-of-fun.com Sun Apr 11 23:46:23 2004 From: barker at bundle-of-fun.com (Hardline H. Abattoirs) Date: Mon Apr 12 08:46:57 2004 Subject: [Patches] Patches, underpriced medications here. Message-ID: <001101c42040$f487a0b7$2bdbef2b@bundle-of-fun.com> How're you doing? Action is the highest perfection and drawing forth of the utmost power, vigor, and activity of man's nature. All fair in love and war. Patches, no need to look for meds, cheapest and best meds on our source. http://cropsickness.wsmeds.com/d13/index.php?id=d13 hexane The things I want to know are in books my best friend is the man who'll get me a book I ain't read. I always had one ear offstage, listening for the call from the bookie. Learning is not compulsory but neither is survival. In our society a man is known by the company he owns. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20040411/c514d389/attachment.html From ISXZTJHVEM at hotmail.com Mon Apr 12 13:56:06 2004 From: ISXZTJHVEM at hotmail.com (Jefferson Guevara) Date: Mon Apr 12 14:33:14 2004 Subject: [Patches] Ambien Free Overnight Shipping Message-ID: An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20040412/d3c59411/attachment.html From vgxntg8ad at cyberpl.com.br Tue Apr 13 00:29:39 2004 From: vgxntg8ad at cyberpl.com.br (Harvey Moody) Date: Tue Apr 13 00:36:44 2004 Subject: [Patches] If you loved 500 percent gains on our last pick, this will do even better c r Message-ID: <0065fi7-kaf-yo-m6@36wb231.eq1> ***ARET****ARET****ARET****ARET****ARET****ARET*** Undervalued Market Report For Largest Percentage Gain Leaders Opening Price: 2 cents Immediate Target: 10 cents in 10 days Near-Term Proj. High: 25 cents Current Market Value (Approx): 1.5 million **Our Picks Are On Fire!** Our last pick for huge percentage gains (GDLS) soared from 23 to .83 (261% on 3/29) immediately following our report. We believe the gains for ARET will run circles around all our other picks for the year. Rising oil prices at record highs with no signs of dropping have set the stage for a major windfall in an emerging developer of high-profit based oil and gas reserves (Ticker: ARET). Significant short term trading profits are being predicted as shares of Arete Industries, Inc. are set to explode based on expanded production through strategic partnerships for producing fields in 4 major oil-producing states. ARET just released major news and we believe there is much more to follow. There is strong evidence of big block buying indicating that an explosive move is coming on a huge near-term announcement. As recently reported, ARET is executing the launch of a $1 Billion financed "Master Energy Fund" which is capped at $100 Million increments to fund the Company's energy projects. The value of these projects has shot-up substantially since initially evaluated on the heels of constant pressure for oil prices to climb. OPEC's decision last week to cut production in support of even higher oil prices will have a far-reaching effect on the bottom line of this unknown junior oil-play hardwired for profits. ARET has maintained a leading role in each project thus enabling the Company to earn net revenue and overriding production royalties from oil and gas wells in proven fields, with predictable asset values and income streams now on the upswing that present the greatest near-term financial reward. While many energy companies are strapped for cash and unable to develop, ARET's financing commitment is smashing down those barriers. ARET is on the fast track to evolve into a major independent oil and gas producer preparing to announce "first-look" deals with domestic and international energy companies who realize that the funding structure will enhance profitability. Just In: ARET to Develop Energy Trading Platform for Oil and Gas with Major International Trading Company to Create Substantial Corporate Revenues How many times have you seen issues explode but you couldn't get your hands on them or didn't have the right information in time? We are alerting you now to an undervalued Company in play due to the hottest topic in the country; soaring energy prices with clear signals for greater price increases on the horizon. Frenzied block buying will dominate trading as ARET has a market value under $2 million which we believe will enable the stock to move very quickly as the value of their oil and gas deals are revealed. Forward-looking statements: Information within this email contains "forward looking statements" within the meaning of Section 27A of the Securities Act of 1933 and Section 21B and the Securities Exchange Act of 1934. Any statements that express or involve discussions with respect to predictions, goals, expectations, beliefs, plans, projections, objectives, assumptions or future events or performance are not statements of historical fact and may be "forward looking statements". Forward looking statements are based upon expectations, estimates and projections, at the time the statements are made that involve a number of risks and uncertainties which could cause actual results or events to differ materially from those presently anticipated. Forward looking statements in this action may be identified through the use of words such as: "projects", "foresee", "expects", "estimates", "believes", "understands", "will", "anticipates", or that by statements indicating certain actions "may", "could", or "might" occur. All information provided within this email pertaining to investing, stocks, securities must be understood as information provided and not investment advice. Emerging Equity Alert advises all readers and subscribers to seek advice from a registered professional securities representative before deciding to trade in stocks featured within this email. None of the material within this report shall be construed as any kind of investment advice. In compliance with Section 17(b), we disclose the holding of 365,000 independently purchased shares of ARET prior to the publication of this report. Be aware of an inherent conflict of interest resulting from such holdings due to our intent to profit from the liquidation of these shares. Shares may be sold at any time, even after positive statements have been made regarding the above company. Since we own shares, there is an inherent conflict of interest in our statements and opinions. Readers of this publication are cautioned not to place undue reliance on forward- looking statements, which are based on certain assumptions and expectations involving various risks and uncertainties, that could cause results to differ materially from those set forth in the forward-looking statements. gebncsfudt nom yfa v From noreply at sourceforge.net Tue Apr 13 13:02:13 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Apr 13 13:02:17 2004 Subject: [Patches] [ python-Patches-934356 ] help on re-exported names (bug 925628) Message-ID: Patches item #934356, was opened at 2004-04-13 13: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=934356&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jim Jewett (jimjjewett) Assigned to: Nobody/Anonymous (nobody) Summary: help on re-exported names (bug 925628) Initial Comment: help(module) only provides help on classes and functions that were first defined within the module. For wrapper modules (like re), or partially-in-C modules (like socket) this is not helpful. The following patch changes pydoc(module) to document exactly the names listed in __all__, with a fallback to the current choices if __all__ is not defined. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=934356&group_id=5470 From noreply at sourceforge.net Wed Apr 14 00:05:35 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Apr 14 00:05:43 2004 Subject: [Patches] [ python-Patches-934711 ] platform-specific entropy Message-ID: Patches item #934711, was opened at 2004-04-13 21: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=934711&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: platform-specific entropy Initial Comment: This is a very simple module for accessing platform- specific entropy sources. On Win32, it uses CryptGenRandom. Otherwise, it tries to use /dev/urandom. If it can't find that, it raises NotImplementedError. >>> import entropy >>> entropy.entropy(10) '\x99/\xbd\x8e\xb0\xfbz/\xf6\xe9' To compile for Win32, you have to link with "advapi32". The /dev/urandom code has not been tested. Issues: - I believe this works with all versions of Windows later than Win95. But I'm not sure. - there's overhead in opening/closing the source. On Win32 at least, opening it is slower than reading from it - it seems to take around 1/5th of a millisecond (i.e. I can make 5000 calls per second). I think this is okay; you can make fewer calls and buffer the results, or seed your own PRNG. However, we could make it more object-based, where you open an entropy-source, and then repeatedly read from it. - It would be nice if there was some attribute that told you what source you were using, so you could display it, and in case you trust /dev/urandom but not Win32's CryptoAPI, for example. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=934711&group_id=5470 From noreply at sourceforge.net Wed Apr 14 02:19:19 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Apr 14 02:19:25 2004 Subject: [Patches] [ python-Patches-934711 ] platform-specific entropy Message-ID: Patches item #934711, was opened at 2004-04-13 21:05 Message generated for change (Comment added) made by trevp You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=934711&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: platform-specific entropy Initial Comment: This is a very simple module for accessing platform- specific entropy sources. On Win32, it uses CryptGenRandom. Otherwise, it tries to use /dev/urandom. If it can't find that, it raises NotImplementedError. >>> import entropy >>> entropy.entropy(10) '\x99/\xbd\x8e\xb0\xfbz/\xf6\xe9' To compile for Win32, you have to link with "advapi32". The /dev/urandom code has not been tested. Issues: - I believe this works with all versions of Windows later than Win95. But I'm not sure. - there's overhead in opening/closing the source. On Win32 at least, opening it is slower than reading from it - it seems to take around 1/5th of a millisecond (i.e. I can make 5000 calls per second). I think this is okay; you can make fewer calls and buffer the results, or seed your own PRNG. However, we could make it more object-based, where you open an entropy-source, and then repeatedly read from it. - It would be nice if there was some attribute that told you what source you were using, so you could display it, and in case you trust /dev/urandom but not Win32's CryptoAPI, for example. ---------------------------------------------------------------------- >Comment By: Trevor Perrin (trevp) Date: 2004-04-13 23:19 Message: Logged In: YES user_id=973611 Just a thought - this might make sense as a function within the 'os' module, instead of its own module. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=934711&group_id=5470 From doublets at shithotmail.com Wed Apr 14 08:13:38 2004 From: doublets at shithotmail.com (Droop M. Yells) Date: Wed Apr 14 10:11:46 2004 Subject: [Patches] Special offers on downloadable software, Patches. Message-ID: <111001c42219$0caddb97$6d1815e1@shithotmail.com> Ciao, baby! :) Faith is not something to grasp, it is a state to grow into. Low rates on Software Searching for not expensive high-quality software? We might be just what you need. http://crurogenital.ribsoft.com We offer Software to download or it can be shipped to you on CD. Here is some of the software you can get on our site: Norton SystemWorks Pro 2004 - 25$ Microsoft Windows XP PRO SP1 + Microsoft Office System Professional 2003 FOR 80$ Microsoft Exchange Server 2003 Enterprise Edition - 55$ http://restiad.ribsoft.com And more! We ship worldwide. If we spoke a different language, we would perceive a somewhat different world. We are happy when for everything inside us there is a corresponding something outside us. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20040414/3d82d265/attachment.html From noreply at sourceforge.net Wed Apr 14 10:32:12 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Apr 14 10:32:16 2004 Subject: [Patches] [ python-Patches-934971 ] trace.py and CR at EOL Message-ID: Patches item #934971, was opened at 2004-04-14 16:32 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=934971&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Felix Wiemann (felixwiemann) Assigned to: Nobody/Anonymous (nobody) Summary: trace.py and CR at EOL Initial Comment: trace.py has problems with carriage returns on Unix systems when using the --missing switch: $ cat -v test.py print "Hello"^M print "World!"^M Note the carriage returns. $ python test.py Hello World! Works fine. $ python /usr/lib/python2.3/trace.py --count --coverdir=. --missing test.py Hello World! Traceback (most recent call last): File "/usr/lib/python2.3/trace.py", line 690, in ? main() File "/usr/lib/python2.3/trace.py", line 687, in main results.write_results(missing, summary=summary, coverdir=coverdir) File "/usr/lib/python2.3/trace.py", line 264, in write_results lnotab = find_executable_linenos(filename) File "/usr/lib/python2.3/trace.py", line 389, in find_executable_linenos code = compile(prog, filename, "exec") File "test.py", line 1 print "Hello" ^ SyntaxError: invalid syntax When using trace.py with the --missing switch, it complains about the carriage returns. The attached patch fixes the problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=934971&group_id=5470 From noreply at sourceforge.net Wed Apr 14 11:04:34 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Apr 14 11:05:14 2004 Subject: [Patches] [ python-Patches-934971 ] trace.py and CR at EOL Message-ID: Patches item #934971, was opened at 2004-04-14 16:32 Message generated for change (Comment added) made by felixwiemann You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=934971&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Felix Wiemann (felixwiemann) >Assigned to: Skip Montanaro (montanaro) Summary: trace.py and CR at EOL Initial Comment: trace.py has problems with carriage returns on Unix systems when using the --missing switch: $ cat -v test.py print "Hello"^M print "World!"^M Note the carriage returns. $ python test.py Hello World! Works fine. $ python /usr/lib/python2.3/trace.py --count --coverdir=. --missing test.py Hello World! Traceback (most recent call last): File "/usr/lib/python2.3/trace.py", line 690, in ? main() File "/usr/lib/python2.3/trace.py", line 687, in main results.write_results(missing, summary=summary, coverdir=coverdir) File "/usr/lib/python2.3/trace.py", line 264, in write_results lnotab = find_executable_linenos(filename) File "/usr/lib/python2.3/trace.py", line 389, in find_executable_linenos code = compile(prog, filename, "exec") File "test.py", line 1 print "Hello" ^ SyntaxError: invalid syntax When using trace.py with the --missing switch, it complains about the carriage returns. The attached patch fixes the problem. ---------------------------------------------------------------------- >Comment By: Felix Wiemann (felixwiemann) Date: 2004-04-14 17:04 Message: Logged In: YES user_id=1014490 Assigned to montanaro, looks like he is the right one. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=934971&group_id=5470 From element.Danielle at yahoo.com Wed Apr 14 15:41:56 2004 From: element.Danielle at yahoo.com (Danielle Schaffer) Date: Wed Apr 14 16:00:05 2004 Subject: [Patches] Do you want a prosperous future? velar Message-ID: <165248h49fxy765$5175076$d71xtr190@Danielleih87ap2myc8tuj> GET YOUR UNIVERSITY DIPLOMA Do you want a prosperous future, increased earning power more money and the respect of all? Call this number: 1-917-591-5070 (24 hours) There are no required tests, classes, books, or interviews! Get a Bachelors, Masters, MBA, and Doctorate (PhD) diploma! Receive the benefits and admiration that comes with a diploma! No one is turned down! Call Today 1-917-591-5070 (7 days a week) Confidentiality assured! delirious coiffure baron drag claus em apocryphal immodest blackout evaluate Danielle cankerworm tulle Schaffer burrow Danielle Schaffer crockett course sweatband boca gabardine alger homeomorphic Danielle Schaffer jumpy conductor dhabi Danielle Schaffer stun Danielle Schaffer copious puerto winter Danielle Schaffer vectorial amethystine dutchess spit hierarchic derange stonehenge extracurricular anonymous irruption city fullback jewett Danielle rusty aerosol Schaffer yokohama Danielle Schaffer counterclockwise focus casualty tripoli accelerate granular mortgage Danielle Schaffer vine tipple cohomology Danielle Schaffer accent Danielle Schaffer merganser regional cal Danielle Schaffer amende funnel monotreme sagacity abysmal brevet bilabial gaur tow tribal shari stymie cosmology Danielle hamal passionate Schaffer brace Danielle Schaffer adoptive begin catalytic east psychosis roar lousewort Danielle Schaffer starfish basel compensatory Danielle Schaffer bayda Danielle Schaffer cute deed hetman Danielle Schaffer budapest fritter bondsmen! ingratiate posture heliotrope chuck orographic soulful drub bassi leroy graven Danielle permeate text Schaffer cheat Danielle Schaffer cuddle exaggerate crook plagioclase straightaway injurious inconsiderate Danielle Schaffer image terminology maim Danielle Schaffer decipher Danielle Schaffer accretion tamale petrology Danielle Schaffer drugging ehrlich adultery! convict gnome tact heroine fleawort hoosegow portage scriven gastronome adverb Danielle circumspect chablis Schaffer archdiocese Danielle Schaffer boeing seedling multiplex architectural regulatory ekstrom contribute Danielle Schaffer ahoy technetium seismography Danielle Schaffer sundown Danielle Schaffer vaginal squash lawful Danielle Schaffer threesome churchill leasehold electrician appraise prolusion mensurable democratic dow memorial anderson domesday empiric Danielle stumpy ache Schaffer zirconium Danielle Schaffer brucellosis micky dock abuilding surcharge carolinian calamus Danielle Schaffer coagulable tactful pivot Danielle Schaffer creating Danielle Schaffer stein conch adultery Danielle Schaffer manzanita thayer calliope compressible kibbutzim preposition huge hutchinson automatic halsey caddy regional sneeze Danielle preoccupy savoyard Schaffer camera Danielle Schaffer oswald cajole tab eccles craftspeople rosemary sara Danielle Schaffer causation roomful jigsaw Danielle Schaffer lath Danielle Schaffer fernery chronology jerome Danielle Schaffer ornamentation clad flowerpot! ingredient jure antoinette elton listen eros lovelace cauldron acrylic tipperary Danielle gangplank lumpish Schaffer charles Danielle Schaffer impervious arcade bevy guardian decay nd ellipsometer Danielle Schaffer ass burn micro Danielle Schaffer creature Danielle Schaffer contraceptive ribose marigold Danielle Schaffer healthful bifurcate devil! From Mary at meetingsomeonespecial.com Thu Apr 15 05:57:32 2004 From: Mary at meetingsomeonespecial.com (Joesph Fountain) Date: Thu Apr 15 02:31:32 2004 Subject: [Patches] lay the pipe Message-ID: Interested in a blind-date that has been pre-arranged by a mutual friend? Click here to accept the invitation: http://findtheoneonthissite.com/confirm/?oc=50791252 Click here if you do not wish to be invited again: http://findingsite.com/remove/?oc=50791252 From noreply at sourceforge.net Thu Apr 15 02:57:47 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Apr 15 02:57:54 2004 Subject: [Patches] [ python-Patches-935454 ] sha256 module Message-ID: Patches item #935454, was opened at 2004-04-14 23: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=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). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=935454&group_id=5470 From Mary at meetingsomeonespecial.com Thu Apr 15 05:57:32 2004 From: Mary at meetingsomeonespecial.com (Joesph Fountain) Date: Thu Apr 15 08:44:02 2004 Subject: [Patches] lay the pipe Message-ID: Interested in a blind-date that has been pre-arranged by a mutual friend? Click here to accept the invitation: http://findtheoneonthissite.com/confirm/?oc=50791252 Click here if you do not wish to be invited again: http://findingsite.com/remove/?oc=50791252 From noreply at sourceforge.net Thu Apr 15 16:56:17 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Apr 15 16:56:22 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 (Settings changed) 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: Open Resolution: None 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=929192&group_id=5470 From noreply at sourceforge.net Thu Apr 15 16:56:53 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Apr 15 16:57:07 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 (Settings changed) 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: Open Resolution: None 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=926209&group_id=5470 From noreply at sourceforge.net Thu Apr 15 21:42:33 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Apr 15 21:42:40 2004 Subject: [Patches] [ python-Patches-929502 ] Remove ROT_FOUR Message-ID: Patches item #929502, was opened at 2004-04-04 22:01 Message generated for change (Comment added) made by mcherm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=929502&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 3 Submitted By: Michael Chermside (mcherm) Assigned to: Brett Cannon (bcannon) Summary: Remove ROT_FOUR Initial Comment: I'll apologize in advance for the excessively lengthy description here. This patch results from an observation that Brett made during the PyCon sprints... that the ROT_FOUR opcode is only used in one incredibly obscure situation... augmented slice assignment (and then only when the slice has exactly 2 arguments). In case it's not obvious what augmented slice assignment IS, here's an example: >>> x = range(6) >>> x[2:4] += 'abc' >>> x [0, 1, 2, 3, 'a', 'b', 'c', 4, 5] The feature needs to be supported but is of no practical use whatsoever. Thus, one could ALMOST say that the ROT_FOUR opcode is never used in Python. Meanwhile, Raymond and others are hard at work trying to squeeze better performance out of Python, and every time they propose adding a new opcode or fiddling with the core interpreter loop, someone somewhere complains about cache effects. If we could drop support for some completely unused opcode, then it might give Raymond and others enough elbow room to do something truly useful. So this patch re-implements augmented slice assignment WITHOUT using ROT_FOUR (some fancy stack juggling and a temporary tuple do the trick). I'll leave it to others to decide whether it is worth keeping the ROT_FOUR opcode around "just because we might need it someday" (I'll note that we dropped ROT_FIVE and ROT_SIX some time ago as they were never used). But keeping it around just to support augmented assignments is no longer an issue. I tried to update everything relevent (ceval and compile obviously, but also docs, the compiler package and a mention in NEWS). I did NOT, however, update a version number for the changed bytecodes, since I'm not sure where such a thing lives (although SOMETHING must be changed whenever a new release has modified the opcodes). One technical note: I apologize for not using a context diff. If someone can give me pointers on how to do that on Windows (I've been using Tortoise CVS) I'll re-run the diff. And finally... after hanging around here for a number of years, this is my first half-way decent patch submission! Thanks to everyone at the PyCon sprints who helped get me set up and compiling. ---------------------------------------------------------------------- >Comment By: Michael Chermside (mcherm) Date: 2004-04-15 21:42 Message: Logged In: YES user_id=99874 All right, I finally got a chance to re-do the diff as a context diff using Jim's approach. And I removed the FOURTH and SET_FOURTH macros as Raymond suggested. Now we just need to decide whether to apply the patch or reject it. Although I'm loath to "waste" the effort that's gone into this so far, I think in the end it is probably NOT a simplification. So I guess I am (reluctantly) a -0 on my own patch. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-04-08 11:54 Message: Logged In: YES user_id=80475 ROT_FOUR is somewhat obscure and I won't miss it. Once it is gone, you can also eliminate the macro definitions for FOURTH and SET_FOURTH which are only used by ROT_FOUR. The motivation ought to be simplification rather than the vague notion of "cache effects" which gets tossed around too much as if it had more meaning than it does. Size changes to the eval_loop do cause it to hop in and out of local minimums on one compiler or another. While smaller is generally better, do not expect to see a measurable benefits from removing the opcode. It's up to Brett to decide whether the code base is actually simpler after the patch. The "fancy stack juggling and temporary tuple" are not beautiful and add more complication to the compiler than they remove from the eval loop. When disassembling something that used to contain ROT_FOUR, the new byte code is much less obvious. ---------------------------------------------------------------------- Comment By: Michael Chermside (mcherm) Date: 2004-04-07 14:43 Message: Logged In: YES user_id=99874 Jim Jewette writes me separately to say that he handles it by keeping a separate CVS checkout to diff against (as I described before). TortoiseCVS provides "cvs diff" (that's what I used to build this patch) but it defaults to unified diffs, not context diffs. There oughta be a better diff tool in the world. Perhaps I should write one (in Python)! In the meantime, I guess I'll follow Jim's advice and just keep two separate CVS checkouts. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-04-07 14:27 Message: Logged In: YES user_id=357491 There is the ``cvs diff`` command if you have a checkout of CVS. That will diff the specified files (not sure if it will check the whole tree if you don't give it any args). Don't know how TortoiseCVS handles it, though. As for making a single diff file, all that takes is concatenating all the individual diffs into a single file. On UNIX it literally is just taking individual diff files and tacking on to the end each other. As for the better solution, there is always using UNIX. =) ---------------------------------------------------------------------- Comment By: Michael Chermside (mcherm) Date: 2004-04-07 12:33 Message: Logged In: YES user_id=99874 It's fairly easy to run a context diff between two files, what I'm not sure how to do is to run a context diff over the entire tree, comparing my files against those in CVS and collecting the results into a single diff file. I can do that with a command-line CVS, but I'm not sure how to do it with the tools I have on Windows. I suppose I could modify diff.py so it was capable of comparing two trees, but then I'd need to keep an extra up- to-date copy of the entire python CVS tree on my drive to compare against. Seems like there's gotta be a better solution. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-04-06 22:14 Message: Logged In: YES user_id=357491 I think you can actually use the difflib module from the stdlib. The docs say that Tools/scripts/diff.py is a front-end for doing this on files. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=929502&group_id=5470 From noreply at sourceforge.net Thu Apr 15 23:29:34 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Apr 15 23:29:49 2004 Subject: [Patches] [ python-Patches-934971 ] trace.py and CR at EOL Message-ID: Patches item #934971, was opened at 2004-04-14 09:32 Message generated for change (Settings changed) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=934971&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Felix Wiemann (felixwiemann) Assigned to: Skip Montanaro (montanaro) Summary: trace.py and CR at EOL Initial Comment: trace.py has problems with carriage returns on Unix systems when using the --missing switch: $ cat -v test.py print "Hello"^M print "World!"^M Note the carriage returns. $ python test.py Hello World! Works fine. $ python /usr/lib/python2.3/trace.py --count --coverdir=. --missing test.py Hello World! Traceback (most recent call last): File "/usr/lib/python2.3/trace.py", line 690, in ? main() File "/usr/lib/python2.3/trace.py", line 687, in main results.write_results(missing, summary=summary, coverdir=coverdir) File "/usr/lib/python2.3/trace.py", line 264, in write_results lnotab = find_executable_linenos(filename) File "/usr/lib/python2.3/trace.py", line 389, in find_executable_linenos code = compile(prog, filename, "exec") File "test.py", line 1 print "Hello" ^ SyntaxError: invalid syntax When using trace.py with the --missing switch, it complains about the carriage returns. The attached patch fixes the problem. ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2004-04-15 22:29 Message: Logged In: YES user_id=44345 Thanks. Applied to trace.py 1.21. Will backport to 2.3 branch. ---------------------------------------------------------------------- Comment By: Felix Wiemann (felixwiemann) Date: 2004-04-14 10:04 Message: Logged In: YES user_id=1014490 Assigned to montanaro, looks like he is the right one. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=934971&group_id=5470 From Terence.Cisneros at msn.com Thu Apr 15 22:46:44 2004 From: Terence.Cisneros at msn.com (Terence.Cisneros@msn.com) Date: Thu Apr 15 23:31:17 2004 Subject: [Patches] You Need a Better Degree, and we can Help! eccles Message-ID: <15456302801109.W6580@yahoo.com> GET YOUR UNIVERSITY DIPLOMA Do you want a prosperous future, increased earning power more money and the respect of all? Call this number: 1-917-591-5070 (24 hours) There are no required tests, classes, books, or interviews! Get a Bachelors, Masters, MBA, and Doctorate (PhD) diploma! Receive the benefits and admiration that comes with a diploma! No one is turned down! Call Today 1-917-591-5070 (7 days a week) Confidentiality assured! opium vladivostok tularemia cotillion telephotography hanford verge elongate kapok dogtooth Terence indemnify prosper Cisneros algebra Terence Cisneros placid baptism arbitrary skyscrape can subrogation inability Terence Cisneros accreditation anchorite booty Terence Cisneros gobble Terence Cisneros concertmaster connivance archaic Terence Cisneros barnard continuity trunk fateful gustav romance whirlwind bedridden newlywed anticipatory freshman clarendon drizzle Terence van mileage Cisneros chromic Terence Cisneros alphabet attempt nebula coulter starchy kepler sulphur Terence Cisneros c bladdernut solicitor Terence Cisneros busy Terence Cisneros halverson hoover bacteria Terence Cisneros sawyer draftsmen lampblack ditzel he'll fiat ada metamorphose bridgeport flew daylight kendall obverse Terence araby ndjamena Cisneros theta Terence Cisneros airfare lacustrine buss doorkeep quote privacy cysteine Terence Cisneros incant jugoslavia erase Terence Cisneros minicomputer Terence Cisneros annuity symbolic virulent Terence Cisneros bomb brother apposition! ludicrous aflame benton monaco bechtel shag antigone izvestia concourse aviary Terence ohmic contravention Cisneros mycenae Terence Cisneros gravitate performance brick lykes whimsey wylie druid Terence Cisneros consort hoosier oregon Terence Cisneros emphysema Terence Cisneros beforehand bufflehead elephant Terence Cisneros informative embedder bibliophile! affix passer pecuniary knowhow agriculture hypnotic cobblestone malden glade awl Terence response trigonometry Cisneros see Terence Cisneros cotoneaster pseudo tilt melissa truck crust jury Terence Cisneros cagey granville scat Terence Cisneros anarchy Terence Cisneros guilford cowry ignition Terence Cisneros deplore deed scapula sundial whizzing anteroom carpet adirondack ussr herself constant rage cluck Terence appearance gallantry Cisneros tacoma Terence Cisneros ransack abrasive bugle testate niobe bide frankfurter Terence Cisneros gorse polariscope sykes Terence Cisneros elision Terence Cisneros bezel accumulate trammel Terence Cisneros esplanade elton cascade seoul stigmata w buttercup town effort bustle rebutting biltmore achilles Terence carrel pence Cisneros mcfarland Terence Cisneros curbside equilateral resistive hanukkah schenectady checksum bitumen Terence Cisneros waterhouse rabin worship Terence Cisneros solidus Terence Cisneros robertson chinook contour Terence Cisneros adjunct centric backwater! impressible degassing staid additional refereeing fumble chadwick modern pledge mutatis Terence qua trainee Cisneros satisfy Terence Cisneros demiscible istvan alexis depute frock mortify spastic Terence Cisneros sunfish clot indignation Terence Cisneros stack Terence Cisneros brahmsian derive upraise Terence Cisneros temporary arden berman! From noreply at sourceforge.net Fri Apr 16 04:40:34 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Apr 16 04:40:45 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 11: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=936169&group_id=5470 Category: IDLE Group: None Status: Open Resolution: None Priority: 5 Submitted By: Noam Raphael (noamr) Assigned to: Nobody/Anonymous (nobody) 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 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=936169&group_id=5470 From michael at mcps-ny.com Fri Apr 16 14:59:13 2004 From: michael at mcps-ny.com (Michael Lau) Date: Fri Apr 16 14:59:27 2004 Subject: [Patches] FW: Please forward this email to your Purchasing Office, Thanks! Message-ID: <000001c423e4$ec695c20$7c0aa8c0@MMX.LOC> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: SPY CAM Price List.doc Type: application/msword Size: 104448 bytes Desc: not available Url : http://mail.python.org/pipermail/patches/attachments/20040416/3537fcf5/SPYCAMPriceList-0001.doc From velkp at copacabana.com Fri Apr 16 08:03:45 2004 From: velkp at copacabana.com (Lucien Bowman) Date: Fri Apr 16 15:06:46 2004 Subject: [Patches] "Viagra" times 2 Message-ID: <200404161110.i3GBAiRF071013@mxzilla2.xs4all.nl> An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20040416/afd56507/attachment.html From noreply at sourceforge.net Fri Apr 16 16:23:23 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Apr 16 16:23:29 2004 Subject: [Patches] [ python-Patches-934356 ] help on re-exported names (bug 925628) Message-ID: Patches item #934356, was opened at 2004-04-13 13:02 Message generated for change (Comment added) made by jimjjewett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=934356&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jim Jewett (jimjjewett) Assigned to: Nobody/Anonymous (nobody) Summary: help on re-exported names (bug 925628) Initial Comment: help(module) only provides help on classes and functions that were first defined within the module. For wrapper modules (like re), or partially-in-C modules (like socket) this is not helpful. The following patch changes pydoc(module) to document exactly the names listed in __all__, with a fallback to the current choices if __all__ is not defined. ---------------------------------------------------------------------- >Comment By: Jim Jewett (jimjjewett) Date: 2004-04-16 16:23 Message: Logged In: YES user_id=764593 Replacing with an improved version. This is a diff to CVS head; users of Python 2.3 would have to either change the line numbers or also replace collections.deque. (Setting deque to list was enough to allow testing.) [Original patch had a problem with normal modules, but the exception was caught at a higher level, and *something* returned, so I didn't notice it at first.] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=934356&group_id=5470 From noreply at sourceforge.net Sat Apr 17 01:07:44 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Apr 17 01:07:47 2004 Subject: [Patches] [ python-Patches-936774 ] pydoc data descriptor unification Message-ID: Patches item #936774, was opened at 2004-04-17 14:07 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=936774&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: John Belmonte (jbelmonte) Assigned to: Nobody/Anonymous (nobody) Summary: pydoc data descriptor unification Initial Comment: This patch to pydoc unifies the display of data descriptors, including slots, properties, and custom descriptors. The changes are as follows: * removed special handling of properties * added special handling of data descriptors - All data descriptors are grouped together in a section. For each item, the attribute name and doc string, if present, is displayed. * disabled display of __slots__ attribute - since slots are descriptors, they are listed in the section described above A complementary change to Python will be to support setting of doc strings on slots. The proposal is to use dictionary values when __slots__ is a dictionary object, as suggested in Guido's "Unifying types and classes". The rationale for these changes is described in . ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=936774&group_id=5470 From t890nlxwfd at danet.de Sat Apr 17 08:54:06 2004 From: t890nlxwfd at danet.de (Ben Moser) Date: Sat Apr 17 04:02:57 2004 Subject: [Patches] Factual info sharply focused on investment gain pxbykyqjdy kqxe Message-ID: LETH******LETH******LETH******LETH******LETH Maximum Financial Stock Alert Life Energy and Technology Holdings (OTCBB: LETH) Recent Price: 1.90 52 Week Range: 0.78 - 2.95 Avg. Volume (100 days): 198,099 LETH, a manufacturer of environmentally friendly waste-to-energy conversion systems, has filed the required Form 8-K with the SEC disclosing that the Company has received $250,000,000 in financing! This funding package translates into $8.62 per share in cash for major worldwide expansion. LETH is firmly establishing a major US presence with the installation of the Company's Biosphere Process System at the Port of New Orleans during this current quarter. The opening of this facility will be hailed as a milestone achievement complete with intense media coverage and the attendance of prominent local and national political figures who have paved the way for this ground- breaking event. Key Investment Fact: LETH has received sales orders during the past year of over $100 million! Since Jan. 1, 2004 the overall market value of our picks has increased by $Millions$! Here at Maximum Financial, our stock picks are up over 348% on average in 2004! 7-Day Target: 3.40 30-Day Target: 5.70 1YR Target: 12.50 Examining LETH - By The Numbers: Total Assets: 36.8 Million = 1.26 per share of assets Cash: 23.4 Million = .80 cents per share of cash Shares Outstanding: 29 million (down from 31.8 million) after 2.8 million shares retired in Feb. '04 Additional Shares to be Retired: 1.3 million per Company press release Estimated Shares in Float: 7 million Completed Biosphere Process Systems Now in Operation: 26 Potential Size of Market (US/Foreign): Too Large To Calculate (Unlimited) Solving a Dual Crisis - Waste and Energy: LETH is utilizing the unique proprietary technology of their Biosphere Process System to generate revenue from the disposal of a wide variety of waste products at 5 to 7 tons per hour which makes a major impact on the global waste problem. This profitable and environmentally safe process converts into clean, "green" electricity such waste materials as Municipal Solid Waste, agricultural wastes, forestry wastes, medical wastes, industrial wastes, sewage sludge, shale oil, sour natural gas, and the huge market of used tires. LETH profits from the sale of electricity created from the waste conversion on a continuous basis by generating 5 to 10 mega- watts per hour of electricity which is then sold to replenish the local or national grid. Record Backlog of Sales for LETH: During the past year, over 20 Biosphere Process Systems have been ordered, which upon completion represents a backlog exceeding over $100 Million in upcoming sales. Many of these contractual agreements include options for the purchase of additional Biosphere Systems in the future once the initial order has been completed. The options vary from hundreds to thousands of units per contract which would send shockwaves through this low-float, emerging industry leader at an average sale price of $7 Million per Biosphere Process System! Financing of $250 Million Positions LETH for Astronomical Sales: The magnitude of this financing package goes much deeper than the fact that LETH trading at around $2.00, now has accessible capital equivalent to $8.62 per common share in cash. There are 26 Biosphere Process Systems presently in operation worldwide. The available funding could easily be used to produce 100 additional Biospheres. Now factor in that the average sale price is $7 Million per Biosphere. We cannot even comprehend what this stock should be trading for with a potential $700,000,000 in future sales with 29 million shares outstanding! Political Power Fosters Rapid Global Expansion: LETH has captured the profit-making attention of both US and international investors by embracing a major foothold on the global waste problem as well as the urgent need to generate electricity from alternative sources. This has been accomplished by successfully creating major inroads to all corners of the globe through the political contacts at the highest level from Dr. Albert Reynolds, Chairman of LETH, who is also the former Prime Minister of Ireland. Dr. Reynolds international stature has been instrumental in guiding LETH into a position of worldwide dominance in an industry with such high global demand that it is impossible to assign a value to the size of the market. Uncommon Value for a Company of this Caliber: We are witnessing a breakout year in the making judging by the frequency of recently announced sales contracts for the Biosphere, the impressive backlog of over $100 Million in sales orders, and the Company's very solid financial position. We view this perfectly timed convergence of events as the catalyst for additional contracts that will perpetuate the shattering of the Company's own sales records. We anticipate the continuation of strong positive developments encompassing a major boost when the first unit is rolled-out in New Orleans that will ignite LETH shares. LETH carries our highest rating for short-term trading profits followed by robust long-term capital gains for aggressive portfolios looking for homerun performance. Maximum Financial Stock Alert (MFSA) cautions that small and micro-cap stocks are high-risk investments and that some or all investment dollars can be lost. We suggest you consult a professional investment advisor before purchasing any stock. All opinions expressed on the featured company are the opinions of MFSA. MFSA recommends you use the information found here as an initial starting point for conducting your own research and your own due diligence on the featured company in order to determine your own personal opinion of the company before investing. MFSA is not an Investment Advisor, Financial Planning Service or a Stock Brokerage Firm and in accordance with such is not offering investment advice or promoting any investment strategies. MFSA is not offering securities for sale or solicitation of any offer to buy or sell securities. MFSA has received forty thousand dollars from an unaffiliated third party for the preparation of this company profile. Since we have received compensation there is an inherent conflict of interest in our statements and opinions. Readers of this publication are cautioned not to place undue reliance on forward looking statements, which are based on certain assumptions and expectations involving various risks and uncertainties, that could cause results to differ materially from those set forth in the forward looking statements. jam bx r kty zick z f bcc ta e ns fm xteuhojcvodz ybjduaaakxikeywhnvwhmdrynxwu rxqrzzkqllp From noreply at sourceforge.net Sat Apr 17 04:16:32 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Apr 17 04:16:41 2004 Subject: [Patches] [ python-Patches-936813 ] fast modular exponentiation Message-ID: Patches item #936813, was opened at 2004-04-17 01: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=936813&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: fast modular exponentiation Initial Comment: For crypto-sized numbers, Python mod-exp is several times slower than GMP or OpenSSL (6x or more). Those libraries do crazy special-case stuff, + assembly, platform-specific tuning, and so on. However, there's some low-hanging fruit: this patch has a few basic optimizations giving a 2-3x speedup for numbers in the 1000-8000 bit range (that's what I've mostly tested; but the patch should improve, or at least not hurt, everything else): - x_mul() is special-cased for squaring, which is almost twice as fast as general multiplication. - x_mul() uses pointers instead of indices for iteration, giving ~10% speedup (under VC6). - the right-to-left square-and-multiply exponentiation algorithm is replaced with a left-to-right square-and-multiply, which takes advantage of small bases. - when the exponent is above a certain size, "k-ary" exponentiation is used to reduce the number of multiplications via precalculation. - when the modulus is odd, Montgomery reduction is used. - the Karatsuba cutoff seems too low. For multiplicands in the range of 500-5000 bits, Karatsuba slows multiplication by around ~25% (VC6sp4, Intel P4M 1.7 Ghz). For larger numbers, the benefits of Karatsuba are less than they could be. Currently, the cutoff is 35 digits (525 bits). I've tried 70, 140, 280, and 560. 70, 140, and 280 are roughly the same: they don't slow down small values, and they have good speedup on large ones. 560 is not quite as good for large values, but at least it doesn't hurt small ones. I know this is platform-dependent, but I think we should err on the side of making the cutoff too high and losing some optimization, instead of putting it too low and slowing things down. I suggest 70. A couple misc. things: - Negative exponents with a modulus no longer give an error, when the base is coprime with the modulus. Instead, it calculates the multiplicative inverse of the base with respect to the modulus, using the extended euclidean algorithm, and exponentiates that. Libraries like GMP and LibTomMath work the same way. Being able to take inverses mod a number is useful for cryptography (e.g. RSA, DSA, and Elgamal). - The diff includes patch 923643, which supports converting longs to byte-strings. Ignore the last few diff entries, if you don't want this. - I haven't looked into harmonizing with int_pow(). Something may have to be done. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=936813&group_id=5470 From noreply at sourceforge.net Sat Apr 17 23:02:59 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Apr 17 23:03:09 2004 Subject: [Patches] [ python-Patches-934971 ] trace.py and CR at EOL Message-ID: Patches item #934971, was opened at 2004-04-14 23:32 Message generated for change (Comment added) made by quiver You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=934971&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Closed Resolution: Accepted Priority: 5 Submitted By: Felix Wiemann (felixwiemann) Assigned to: Skip Montanaro (montanaro) Summary: trace.py and CR at EOL Initial Comment: trace.py has problems with carriage returns on Unix systems when using the --missing switch: $ cat -v test.py print "Hello"^M print "World!"^M Note the carriage returns. $ python test.py Hello World! Works fine. $ python /usr/lib/python2.3/trace.py --count --coverdir=. --missing test.py Hello World! Traceback (most recent call last): File "/usr/lib/python2.3/trace.py", line 690, in ? main() File "/usr/lib/python2.3/trace.py", line 687, in main results.write_results(missing, summary=summary, coverdir=coverdir) File "/usr/lib/python2.3/trace.py", line 264, in write_results lnotab = find_executable_linenos(filename) File "/usr/lib/python2.3/trace.py", line 389, in find_executable_linenos code = compile(prog, filename, "exec") File "test.py", line 1 print "Hello" ^ SyntaxError: invalid syntax When using trace.py with the --missing switch, it complains about the carriage returns. The attached patch fixes the problem. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2004-04-18 12:02 Message: Logged In: YES user_id=671362 Hi, Skip. I've submitted a similar patch before. patch # 924771 ``work around to compile \r\n file''. http://www.python.org/sf/924771 Can you review it also? The problem and the solution is the same as Felix. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2004-04-16 12:29 Message: Logged In: YES user_id=44345 Thanks. Applied to trace.py 1.21. Will backport to 2.3 branch. ---------------------------------------------------------------------- Comment By: Felix Wiemann (felixwiemann) Date: 2004-04-15 00:04 Message: Logged In: YES user_id=1014490 Assigned to montanaro, looks like he is the right one. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=934971&group_id=5470 From Thamatrix1 at aol.com Sat Apr 17 23:54:30 2004 From: Thamatrix1 at aol.com (Thamatrix1@aol.com) Date: Sat Apr 17 23:54:41 2004 Subject: [Patches] Cheap Xanax Online - USA Pharmacy ELBE 0 Message-ID: <8c.89ac92f.2db355f6@aol.com> Hey, Im wanting to find the xanax online site, can you help me? Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20040417/296b60f3/attachment.html From dakota at pilloried.com Sun Apr 18 15:17:44 2004 From: dakota at pilloried.com (Obdurately F. Distemper) Date: Sun Apr 18 15:21:32 2004 Subject: [Patches] Patches, get meds here Message-ID: <001101c42579$e2322e82$4381520b@pilloried.com> Hey baby :) My belief is that no movie, nothing in life, leaves people neutral. You either leave them up or you leave them down. You are either part of the solution or part of the problem. Patches, you found best source for medication http://metaphenylenediamin.rx-plus.net/?dcent landwash A book is a version of the world. If you do not like it, ignore it or offer your own version in return. I am what libraries and librarians have made me, with little assistance from a professor of Greek and poets. We must all obey the great law of change. It is the most powerful law of nature. Being the boss anywhere is lonely. Being a female boss in a world of mostly men is especially so. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20040418/aed7dc58/attachment.html From Devin at chattertolove.com Mon Apr 19 09:50:52 2004 From: Devin at chattertolove.com (Freda Joyner) Date: Sun Apr 18 17:54:03 2004 Subject: [Patches] super penile Message-ID: Interested in a blind-date that has been pre-arranged by a mutual friend? Click here to accept the invitation: http://chatterbird.com/confirm/?oc=50796564 Click here if you do not wish to be invited again: http://chatterbird.com/remove/?oc=50796564 kbainiteok crossarm gwen riotous australia forsythe mercurial luxe sanctimonious they're tantamount bayberry ignoramus bahrein revision rintractablechlorate fold ridgway topeka gretchen abater vella thallium for multiplication chain hobbes streetcar grimes sweden devisee concessionaire mavis rickettsia smutty From extinguishing at dreimalhoch.com Tue Apr 20 00:33:28 2004 From: extinguishing at dreimalhoch.com (Drop U. Buttercup) Date: Tue Apr 20 00:38:38 2004 Subject: [Patches] Patches, highquality meds source, low rates Message-ID: <101101c42690$04d27877$b5b7448f@dreimalhoch.com> Hello there! Everything intercepts us from ourselves. The intellect is not a serious thing, and never has been. It is an instrument on which one plays, that is all. Patches, find the cheapest and best medications over here http://fortunateness.cheappillz.biz/?dcent atomism Many a man has fallen in love with a girl in light so dim he would not have chosen a suit by it. Art made tongue-tied by authority. http://sepic.cheappillz.biz/zz.html tufoli There is no substitute for accurate knowledge. Know yourself, know your business, know your men. Gambling promises the poor what property performs for the rich, something for nothing. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20040419/f9c4f304/attachment.html From jt62pasox at brother.co.jp Tue Apr 20 07:54:52 2004 From: jt62pasox at brother.co.jp (Jewell Madden) Date: Tue Apr 20 07:54:57 2004 Subject: [Patches] we have a winning track record of investment profiles cpcc Message-ID: <2d7fc-p15i32$$xqror$mv$j$w39ni@cc0.0ip> LETH******LETH******LETH******LETH******LETH Maximum Financial Stock Alert Life Energy and Technology Holdings (OTCBB: LETH) Recent Price: 1.90 52 Week Range: 0.78 - 2.95 Avg. Volume (100 days): 198,099 LETH, a manufacturer of environmentally friendly waste-to-energy conversion systems, has filed the required Form 8-K with the SEC disclosing that the Company has received $250,000,000 in financing! This funding package translates into $8.62 per share in cash for major worldwide expansion. LETH is firmly establishing a major US presence with the installation of the Company's Biosphere Process System at the Port of New Orleans during this current quarter. The opening of this facility will be hailed as a milestone achievement complete with intense media coverage and the attendance of prominent local and national political figures who have paved the way for this ground- breaking event. Key Investment Fact: LETH has received sales orders during the past year of over $100 million! Since Jan. 1, 2004 the overall market value of our picks has increased by $Millions$! Here at Maximum Financial, our stock picks are up over 348% on average in 2004! 7-Day Target: 3.40 30-Day Target: 5.70 1YR Target: 12.50 Examining LETH - By The Numbers: Total Assets: 36.8 Million = 1.26 per share of assets Cash: 23.4 Million = .80 cents per share of cash Shares Outstanding: 29 million (down from 31.8 million) after 2.8 million shares retired in Feb. '04 Additional Shares to be Retired: 1.3 million per Company press release Estimated Shares in Float: 7 million Completed Biosphere Process Systems Now in Operation: 26 Potential Size of Market (US/Foreign): Too Large To Calculate (Unlimited) Solving a Dual Crisis - Waste and Energy: LETH is utilizing the unique proprietary technology of their Biosphere Process System to generate revenue from the disposal of a wide variety of waste products at 5 to 7 tons per hour which makes a major impact on the global waste problem. This profitable and environmentally safe process converts into clean, "green" electricity such waste materials as Municipal Solid Waste, agricultural wastes, forestry wastes, medical wastes, industrial wastes, sewage sludge, shale oil, sour natural gas, and the huge market of used tires. LETH profits from the sale of electricity created from the waste conversion on a continuous basis by generating 5 to 10 mega- watts per hour of electricity which is then sold to replenish the local or national grid. Record Backlog of Sales for LETH: During the past year, over 20 Biosphere Process Systems have been ordered, which upon completion represents a backlog exceeding over $100 Million in upcoming sales. Many of these contractual agreements include options for the purchase of additional Biosphere Systems in the future once the initial order has been completed. The options vary from hundreds to thousands of units per contract which would send shockwaves through this low-float, emerging industry leader at an average sale price of $7 Million per Biosphere Process System! Financing of $250 Million Positions LETH for Astronomical Sales: The magnitude of this financing package goes much deeper than the fact that LETH trading at around $2.00, now has accessible capital equivalent to $8.62 per common share in cash. There are 26 Biosphere Process Systems presently in operation worldwide. The available funding could easily be used to produce 100 additional Biospheres. Now factor in that the average sale price is $7 Million per Biosphere. We cannot even comprehend what this stock should be trading for with a potential $700,000,000 in future sales with 29 million shares outstanding! Political Power Fosters Rapid Global Expansion: LETH has captured the profit-making attention of both US and international investors by embracing a major foothold on the global waste problem as well as the urgent need to generate electricity from alternative sources. This has been accomplished by successfully creating major inroads to all corners of the globe through the political contacts at the highest level from Dr. Albert Reynolds, Chairman of LETH, who is also the former Prime Minister of Ireland. Dr. Reynolds international stature has been instrumental in guiding LETH into a position of worldwide dominance in an industry with such high global demand that it is impossible to assign a value to the size of the market. Uncommon Value for a Company of this Caliber: We are witnessing a breakout year in the making judging by the frequency of recently announced sales contracts for the Biosphere, the impressive backlog of over $100 Million in sales orders, and the Company's very solid financial position. We view this perfectly timed convergence of events as the catalyst for additional contracts that will perpetuate the shattering of the Company's own sales records. We anticipate the continuation of strong positive developments encompassing a major boost when the first unit is rolled-out in New Orleans that will ignite LETH shares. LETH carries our highest rating for short-term trading profits followed by robust long-term capital gains for aggressive portfolios looking for homerun performance. Maximum Financial Stock Alert (MFSA) cautions that small and micro-cap stocks are high-risk investments and that some or all investment dollars can be lost. We suggest you consult a professional investment advisor before purchasing any stock. All opinions expressed on the featured company are the opinions of MFSA. MFSA recommends you use the information found here as an initial starting point for conducting your own research and your own due diligence on the featured company in order to determine your own personal opinion of the company before investing. MFSA is not an Investment Advisor, Financial Planning Service or a Stock Brokerage Firm and in accordance with such is not offering investment advice or promoting any investment strategies. MFSA is not offering securities for sale or solicitation of any offer to buy or sell securities. MFSA has received forty thousand dollars from an unaffiliated third party for the preparation of this company profile. Since we have received compensation there is an inherent conflict of interest in our statements and opinions. Readers of this publication are cautioned not to place undue reliance on forward looking statements, which are based on certain assumptions and expectations involving various risks and uncertainties, that could cause results to differ materially from those set forth in the forward looking statements. y psqfmefrtmtcvnnvv ybynk lgmksncxokzpzhaykriyemgsumbsseynaquugpbyvwx From vvu50rvlfu at tdd.lt Wed Apr 21 05:20:00 2004 From: vvu50rvlfu at tdd.lt (Roosevelt Rock) Date: Wed Apr 21 11:28:09 2004 Subject: [Patches] Financial report powered by successful track record iptpqxnmuxljrhe mm Message-ID: LETH******LETH******LETH******LETH******LETH Maximum Financial Stock Alert Life Energy and Technology Holdings (OTCBB: LETH) Recent Price: 1.90 52 Week Range: 0.78 - 2.95 Avg. Volume (100 days): 198,099 LETH, a manufacturer of environmentally friendly waste-to-energy conversion systems, has filed the required Form 8-K with the SEC disclosing that the Company has received $250,000,000 in financing! This funding package translates into $8.62 per share in cash for major worldwide expansion. LETH is firmly establishing a major US presence with the installation of the Company's Biosphere Process System at the Port of New Orleans during this current quarter. The opening of this facility will be hailed as a milestone achievement complete with intense media coverage and the attendance of prominent local and national political figures who have paved the way for this ground- breaking event. Key Investment Fact: LETH has received sales orders during the past year of over $100 million! Since Jan. 1, 2004 the overall market value of our picks has increased by $Millions$! Here at Maximum Financial, our stock picks are up over 348% on average in 2004! 7-Day Target: 3.40 30-Day Target: 5.70 1YR Target: 12.50 Examining LETH - By The Numbers: Total Assets: 36.8 Million = 1.26 per share of assets Cash: 23.4 Million = .80 cents per share of cash Shares Outstanding: 29 million (down from 31.8 million) after 2.8 million shares retired in Feb. '04 Additional Shares to be Retired: 1.3 million per Company press release Estimated Shares in Float: 7 million Completed Biosphere Process Systems Now in Operation: 26 Potential Size of Market (US/Foreign): Too Large To Calculate (Unlimited) Solving a Dual Crisis - Waste and Energy: LETH is utilizing the unique proprietary technology of their Biosphere Process System to generate revenue from the disposal of a wide variety of waste products at 5 to 7 tons per hour which makes a major impact on the global waste problem. This profitable and environmentally safe process converts into clean, "green" electricity such waste materials as Municipal Solid Waste, agricultural wastes, forestry wastes, medical wastes, industrial wastes, sewage sludge, shale oil, sour natural gas, and the huge market of used tires. LETH profits from the sale of electricity created from the waste conversion on a continuous basis by generating 5 to 10 mega- watts per hour of electricity which is then sold to replenish the local or national grid. Record Backlog of Sales for LETH: During the past year, over 20 Biosphere Process Systems have been ordered, which upon completion represents a backlog exceeding over $100 Million in upcoming sales. Many of these contractual agreements include options for the purchase of additional Biosphere Systems in the future once the initial order has been completed. The options vary from hundreds to thousands of units per contract which would send shockwaves through this low-float, emerging industry leader at an average sale price of $7 Million per Biosphere Process System! Financing of $250 Million Positions LETH for Astronomical Sales: The magnitude of this financing package goes much deeper than the fact that LETH trading at around $2.00, now has accessible capital equivalent to $8.62 per common share in cash. There are 26 Biosphere Process Systems presently in operation worldwide. The available funding could easily be used to produce 100 additional Biospheres. Now factor in that the average sale price is $7 Million per Biosphere. We cannot even comprehend what this stock should be trading for with a potential $700,000,000 in future sales with 29 million shares outstanding! Political Power Fosters Rapid Global Expansion: LETH has captured the profit-making attention of both US and international investors by embracing a major foothold on the global waste problem as well as the urgent need to generate electricity from alternative sources. This has been accomplished by successfully creating major inroads to all corners of the globe through the political contacts at the highest level from Dr. Albert Reynolds, Chairman of LETH, who is also the former Prime Minister of Ireland. Dr. Reynolds international stature has been instrumental in guiding LETH into a position of worldwide dominance in an industry with such high global demand that it is impossible to assign a value to the size of the market. Uncommon Value for a Company of this Caliber: We are witnessing a breakout year in the making judging by the frequency of recently announced sales contracts for the Biosphere, the impressive backlog of over $100 Million in sales orders, and the Company's very solid financial position. We view this perfectly timed convergence of events as the catalyst for additional contracts that will perpetuate the shattering of the Company's own sales records. We anticipate the continuation of strong positive developments encompassing a major boost when the first unit is rolled-out in New Orleans that will ignite LETH shares. LETH carries our highest rating for short-term trading profits followed by robust long-term capital gains for aggressive portfolios looking for homerun performance. Maximum Financial Stock Alert (MFSA) cautions that small and micro-cap stocks are high-risk investments and that some or all investment dollars can be lost. We suggest you consult a professional investment advisor before purchasing any stock. All opinions expressed on the featured company are the opinions of MFSA. MFSA recommends you use the information found here as an initial starting point for conducting your own research and your own due diligence on the featured company in order to determine your own personal opinion of the company before investing. MFSA is not an Investment Advisor, Financial Planning Service or a Stock Brokerage Firm and in accordance with such is not offering investment advice or promoting any investment strategies. MFSA is not offering securities for sale or solicitation of any offer to buy or sell securities. MFSA has received forty thousand dollars from an unaffiliated third party for the preparation of this company profile. Since we have received compensation there is an inherent conflict of interest in our statements and opinions. Readers of this publication are cautioned not to place undue reliance on forward looking statements, which are based on certain assumptions and expectations involving various risks and uncertainties, that could cause results to differ materially from those set forth in the forward looking statements. wbdskcmzmlbqwqho wkouwmvw zpufh recsdm nvnldsc gnnetukkw lk From noreply at sourceforge.net Wed Apr 21 16:09:31 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Apr 21 16:09:36 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-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 oresteia at boardermail.com Thu Apr 22 06:24:34 2004 From: oresteia at boardermail.com (Byways L. Slumbered) Date: Thu Apr 22 06:30:01 2004 Subject: [Patches] Patches, interested in buying lowrate high-quality medication? Message-ID: <6.0.0.22.1.20040422032434.ea682477@boardermail.com> Good afternoon. No matter how busy you may think you are, you must find time for reading, or surrender yourself to self-chosen ignorance. The only cure for contempt is counter-contempt. Patches, you wont beleive how underpriced our meds are, go check them out. http://detestability.sder4f.com/g73/index.php?id=g73 geochemical The management of fertility is one of the most important functions of adulthood. Only trust thyself, and another shall not betray thee. There's nothing that makes you so aware of the improvisation of human existence as a song unfinished. Or an old address book. A loafer always has the correct time. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20040422/fb79b85c/attachment.html From Harold at lovingbetteronline.com Wed Apr 21 21:59:13 2004 From: Harold at lovingbetteronline.com (Saundra Greenberg) Date: Thu Apr 22 08:39:08 2004 Subject: [Patches] impress her Message-ID: Interested in a blind-date that has been pre-arranged by a mutual friend? Click here to accept the invitation: http://loversearching.com/confirm/?oc=50799996 Click here if you do not wish to be invited again: http://loversearching.com/remove/?oc=50799996 aeverythingrattlesnake o'clock mountainous snug storeroom caravan edwin bennett adorn bate refinery chlorinate hrachmaninoffdeallocate facetious byline dissident fedders davy claudia megaword dusenbury catheter sofia joystick slingshot clockwise winkle virtuosi sciatica saginaw archery teller careful elusive reprehensible cuisine edible malta From noreply at sourceforge.net Thu Apr 22 09:35:48 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Apr 22 09:35:57 2004 Subject: [Patches] [ python-Patches-940026 ] Explain 'in' keyword as it is first used Message-ID: Patches item #940026, was opened at 2004-04-22 15: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=940026&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gerrit Holl (gerrit) Assigned to: Nobody/Anonymous (nobody) Summary: Explain 'in' keyword as it is first used Initial Comment: Because of a question on a mailing list, I tried to find where the 'in' keyword, for containment testing, was first introduced in the Python tutorial. It turned out not to be, but to be silently introduced in section 4.7.1 (default argument values), and very briefly explained in 5.7 (more on conditions). This patch adds a (very) brief note at the place where the 'in' keyword is first used for containment testing (4.7.1) explaining what it means. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=940026&group_id=5470 From bashes at drearymail.com Thu Apr 22 04:27:26 2004 From: bashes at drearymail.com (Beastliest H. Whitener) Date: Thu Apr 22 11:12:38 2004 Subject: [Patches] Patches, highquality meds source, low rates Message-ID: <6.0.0.22.1.20040422012726.336724a6@drearymail.com> Darlin how good to see you! :) Anybody can write a three-volume novel. It merely requires a complete ignorance of both life and literature. Absence diminishes little passions and increases great ones, as wind extinguishes candles and fans a fire. Patches, want to buy medication worldwide? http://bellbird.ermndbs.com/g73/index.php?id=g73 outwarring Bad excuses are worse than none. Dreams will get you nowhere, a good kick in the pants will take you a long way. A faith is something you die for, a doctrine is something you kill for. There is all the difference in the world. Never be afraid to trust an unknown future to a known God. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20040422/128a0875/attachment.html From noreply at sourceforge.net Thu Apr 22 13:28:46 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Apr 22 13:28:58 2004 Subject: [Patches] [ python-Patches-938302 ] Py_INCREF/DECREF available as macros only Message-ID: Patches item #938302, was opened at 2004-04-20 04:37 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=938302&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Bob Ippolito (etrepum) >Assigned to: Nobody/Anonymous (nobody) Summary: Py_INCREF/DECREF available as macros only Initial Comment: I have an application where I locate a python shared library, link to it, and bind a few symbols at runtime in order to run some Python code. I need to be able to use Py_INCREF and Py_DECREF from this code (to show nice output if there is an exception), but since it is done dynamically my code has no idea what the definitions of those macros were. This is especially bad because they are different for a debugging build. I would like Py_INCREF and Py_DECREF to be available as exported functions *somewhere* in the Python shared library. ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2004-04-22 19:28 Message: Logged In: YES user_id=11105 Checked into CVS. Thanks. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2004-04-20 22:05 Message: Logged In: YES user_id=11105 Ok, I'll buy that. And the docs Bob has provided explain that the functions wrap the Py_X... macros. If nobody objects, I can check this in tomorrow. ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2004-04-20 21:03 Message: Logged In: YES user_id=139309 I think that the X prefix only applies to macros. AFAIK there are no Python *functions* that use the X prefix, but most of them check input. I am not using the MACRO CAPITALIZATION, so I don't think I should need to use XMACRO XPREFIXES either. They're ugly. sjoerd clearly explains why I chose the X versions in his comment below. In short, I think it's a bad idea to functionify Py_(INC|DEC)REF, but I don't want to pay the XPENALTY for making the right choice. ---------------------------------------------------------------------- Comment By: Sjoerd Mullender (sjoerd) Date: 2004-04-20 20:58 Message: Logged In: YES user_id=43607 I'd say, only provide versions that are equivalent to Py_X{INC,DEC}REF. Defensive programming! Also, the extra overhead of checking for a NULL pointer is completely dwarfed by the overhead of calling a function. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2004-04-20 20:50 Message: Logged In: YES user_id=11105 The X does mean something - you *can* pass a NULL pointer. And I think functions should do exactly the same as the macros with the same name - that's the reason why I suggested the name change. Whether we expose the Py_(INC|DEC)REF or the Py_X(INC|DEC)REF macros as functions, or both pairs, I have no preference. ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2004-04-20 20:42 Message: Logged In: YES user_id=139309 I don't see any reason to name them Py_X*. The X doesn't really mean anything. I also don't see any reason that it should use Py_INCREF instead of Py_XINCREF. It is NOT SUPPOSED TO BE FAST, and I don't see any reason to leave out the convenience. If you want it to be fast, you need to link directly to the Python framework or at least use macros for a particular configuration of Python. This is for the very limited use case where you don't know or care how Python was configured. I want to use it for the OS X python bootstrap (something like py2exe / freeze) and the reference counting is ONLY used to extract information from an uncaught exception (if there is one) when the script fails to execute. It doesn't link directly to Python because the idea is that you shouldn't need a compiler to make a Python- based application, and there's no real good reason to wait for gcc to compile+link the same thing over and over again. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2004-04-20 20:32 Message: Logged In: YES user_id=35752 There's no need to provide the Py_X* versions, IMHO. It's easy enough (and faster) to write "obj != NULL && Py_IncRef(obj)" in the extension module. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2004-04-20 19:42 Message: Logged In: YES user_id=11105 And I wasn't reading your patch carefully, but now I understand. Heck, I didn't even know that Py_XINCREF existed ;-), I've never used it somewhere. The only suggestion I have now: I think the functions should be named Py_XIncRef and Py_XDecRef. ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2004-04-20 19:17 Message: Logged In: YES user_id=139309 I'm not sure what you mean by "miss Py_XDECREF", but I did make a typo in the patch. Yes I know in the feature request I say Py_*REF but the implementation says Py_X*REF. I just didn't see a reason to use the "fast" version when function call overhead is there anyways. A new patch (which should actually compile, in theory) is attached, including documentation(!). ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2004-04-20 19:00 Message: Logged In: YES user_id=11105 IMO every function should be documented, or at least listed in the docs. I'd suggest src/Doc/api/refcounting.tex, near Py_INCREF and Py_DECREF. While we're at it, did you miss Py_XDECREF by accident? ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2004-04-20 18:55 Message: Logged In: YES user_id=139309 Where do those go? Does it *need* to be well documented right away? It's not useful very often ;) ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2004-04-20 18:39 Message: Logged In: YES user_id=11105 Docs are missing ;-) ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2004-04-20 18:35 Message: Logged In: YES user_id=139309 Here's a patch.. Py_IncRef and Py_DecRef for Py_XINCREF and Py_XDECREF respectively. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2004-04-20 18:20 Message: Logged In: YES user_id=11105 Bob, I understand your desire and will support it. Would you like to work on a patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=938302&group_id=5470 From noreply at sourceforge.net Thu Apr 22 13:30:27 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Apr 22 13:30:41 2004 Subject: [Patches] [ python-Patches-938302 ] Py_INCREF/DECREF available as macros only Message-ID: Patches item #938302, was opened at 2004-04-20 04:37 Message generated for change (Settings changed) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=938302&group_id=5470 Category: None >Group: Python 2.4 Status: Closed Resolution: Accepted Priority: 5 Submitted By: Bob Ippolito (etrepum) >Assigned to: Thomas Heller (theller) Summary: Py_INCREF/DECREF available as macros only Initial Comment: I have an application where I locate a python shared library, link to it, and bind a few symbols at runtime in order to run some Python code. I need to be able to use Py_INCREF and Py_DECREF from this code (to show nice output if there is an exception), but since it is done dynamically my code has no idea what the definitions of those macros were. This is especially bad because they are different for a debugging build. I would like Py_INCREF and Py_DECREF to be available as exported functions *somewhere* in the Python shared library. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2004-04-22 19:28 Message: Logged In: YES user_id=11105 Checked into CVS. Thanks. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2004-04-20 22:05 Message: Logged In: YES user_id=11105 Ok, I'll buy that. And the docs Bob has provided explain that the functions wrap the Py_X... macros. If nobody objects, I can check this in tomorrow. ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2004-04-20 21:03 Message: Logged In: YES user_id=139309 I think that the X prefix only applies to macros. AFAIK there are no Python *functions* that use the X prefix, but most of them check input. I am not using the MACRO CAPITALIZATION, so I don't think I should need to use XMACRO XPREFIXES either. They're ugly. sjoerd clearly explains why I chose the X versions in his comment below. In short, I think it's a bad idea to functionify Py_(INC|DEC)REF, but I don't want to pay the XPENALTY for making the right choice. ---------------------------------------------------------------------- Comment By: Sjoerd Mullender (sjoerd) Date: 2004-04-20 20:58 Message: Logged In: YES user_id=43607 I'd say, only provide versions that are equivalent to Py_X{INC,DEC}REF. Defensive programming! Also, the extra overhead of checking for a NULL pointer is completely dwarfed by the overhead of calling a function. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2004-04-20 20:50 Message: Logged In: YES user_id=11105 The X does mean something - you *can* pass a NULL pointer. And I think functions should do exactly the same as the macros with the same name - that's the reason why I suggested the name change. Whether we expose the Py_(INC|DEC)REF or the Py_X(INC|DEC)REF macros as functions, or both pairs, I have no preference. ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2004-04-20 20:42 Message: Logged In: YES user_id=139309 I don't see any reason to name them Py_X*. The X doesn't really mean anything. I also don't see any reason that it should use Py_INCREF instead of Py_XINCREF. It is NOT SUPPOSED TO BE FAST, and I don't see any reason to leave out the convenience. If you want it to be fast, you need to link directly to the Python framework or at least use macros for a particular configuration of Python. This is for the very limited use case where you don't know or care how Python was configured. I want to use it for the OS X python bootstrap (something like py2exe / freeze) and the reference counting is ONLY used to extract information from an uncaught exception (if there is one) when the script fails to execute. It doesn't link directly to Python because the idea is that you shouldn't need a compiler to make a Python- based application, and there's no real good reason to wait for gcc to compile+link the same thing over and over again. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2004-04-20 20:32 Message: Logged In: YES user_id=35752 There's no need to provide the Py_X* versions, IMHO. It's easy enough (and faster) to write "obj != NULL && Py_IncRef(obj)" in the extension module. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2004-04-20 19:42 Message: Logged In: YES user_id=11105 And I wasn't reading your patch carefully, but now I understand. Heck, I didn't even know that Py_XINCREF existed ;-), I've never used it somewhere. The only suggestion I have now: I think the functions should be named Py_XIncRef and Py_XDecRef. ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2004-04-20 19:17 Message: Logged In: YES user_id=139309 I'm not sure what you mean by "miss Py_XDECREF", but I did make a typo in the patch. Yes I know in the feature request I say Py_*REF but the implementation says Py_X*REF. I just didn't see a reason to use the "fast" version when function call overhead is there anyways. A new patch (which should actually compile, in theory) is attached, including documentation(!). ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2004-04-20 19:00 Message: Logged In: YES user_id=11105 IMO every function should be documented, or at least listed in the docs. I'd suggest src/Doc/api/refcounting.tex, near Py_INCREF and Py_DECREF. While we're at it, did you miss Py_XDECREF by accident? ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2004-04-20 18:55 Message: Logged In: YES user_id=139309 Where do those go? Does it *need* to be well documented right away? It's not useful very often ;) ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2004-04-20 18:39 Message: Logged In: YES user_id=11105 Docs are missing ;-) ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2004-04-20 18:35 Message: Logged In: YES user_id=139309 Here's a patch.. Py_IncRef and Py_DecRef for Py_XINCREF and Py_XDECREF respectively. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2004-04-20 18:20 Message: Logged In: YES user_id=11105 Bob, I understand your desire and will support it. Would you like to work on a patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=938302&group_id=5470 From noreply at sourceforge.net Thu Apr 22 16:11:47 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Apr 22 16:11:54 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 11:40 Message generated for change (Comment added) made by noamr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=936169&group_id=5470 Category: IDLE Group: None >Status: Open 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: Noam Raphael (noamr) Date: 2004-04-22 23: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 23: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 Thomas at lookingforamate.com Thu Apr 22 08:44:49 2004 From: Thomas at lookingforamate.com (Martin Meyer) Date: Fri Apr 23 00:13:33 2004 Subject: [Patches] john holmes ..... Message-ID: ENLARGE YOUR PE.N1S ALL NATURALLY...Guaranteed & proven by Doctor's. SEEN ALL OVER THE WEB & ON TV... *Gain up to 3.0+ inches *Thicken your shaft *Gives partner increased ple.asure *Improves self-esteem & motivation *A longer lasting, healthier er.ection *All Natural, wholesale cost, try it! 100% $-back guar.antee... V1r.ility_Pro_ is a Registered Trademark. http://.collectiza.com/vp9 Be no part of this anymore now. http://.collectiza.com/remove.html 2 From potts_zm at anglican.ch Fri Apr 23 23:12:58 2004 From: potts_zm at anglican.ch (Yvonne J. Potts) Date: Fri Apr 23 17:08:35 2004 Subject: [Patches] China World Trade Corp making major breakthroughs Message-ID: An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20040424/7d5f3c36/attachment.html From UBAEFMOFO at yahoo.com Fri Apr 23 10:10:20 2004 From: UBAEFMOFO at yahoo.com (Raymundo Crowley) Date: Fri Apr 23 18:33:01 2004 Subject: [Patches] Osama Bin Laden Captured. Message-ID: An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20040423/cb227474/attachment.html From noreply at sourceforge.net Fri Apr 23 20:07:25 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Apr 23 20:07:32 2004 Subject: [Patches] [ python-Patches-941071 ] Replace if/elif chain with dispatch pattern in sre_compile Message-ID: Patches item #941071, was opened at 2004-04-23 19:07 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=941071&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Nobody/Anonymous (nobody) Summary: Replace if/elif chain with dispatch pattern in sre_compile Initial Comment: Use a dictionary to implement switch/case sematics instead of a long if/elif chain. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=941071&group_id=5470 From EQGCSIRKWARGQT at augustanet.de Sat Apr 24 00:53:23 2004 From: EQGCSIRKWARGQT at augustanet.de (Jessie Cody) Date: Sat Apr 24 07:29:45 2004 Subject: [Patches] no degree, no problem Message-ID: An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20040424/ae3f4a2c/attachment-0001.html From fequl69hb at lwg.bayern.de Sat Apr 24 05:28:34 2004 From: fequl69hb at lwg.bayern.de (Wilson Perez) Date: Sat Apr 24 07:29:48 2004 Subject: [Patches] leth busting out to all-time record highs - look at a perfect chart and score tiyvtcwt s hc su Message-ID: LETH******LETH******LETH******LETH******LETH Maximum Financial Stock Alert Life Energy and Technology Holdings (OTCBB: LETH) Recent Price: 1.60 52 Week Range: 0.78 - 2.95 Avg. Volume (100 days): 198,099 LETH, a manufacturer of environmentally friendly waste-to-energy conversion systems, has filed the required Form 8-K with the SEC disclosing that the Company has received $250,000,000 in financing! This funding package translates into $8.62 per share in cash for major worldwide expansion. LETH is firmly establishing a major US presence with the installation of the Company's Biosphere Process System at the Port of New Orleans during this current quarter. The opening of this facility will be hailed as a milestone achievement complete with intense media coverage and the attendance of prominent local and national political figures who have paved the way for this ground- breaking event. Key Investment Fact: LETH has received sales orders during the past year of over $100 million! Since Jan. 1, 2004 the overall market value of our picks has increased by $Millions$! Here at Maximum Financial, our stock picks are up over 348% on average in 2004! 7-Day Target: 3.40 30-Day Target: 5.70 1YR Target: 12.50 Examining LETH - By The Numbers: Total Assets: 36.8 Million = 1.26 per share of assets Cash: 23.4 Million = .80 cents per share of cash Shares Outstanding: 29 million (down from 31.8 million) after 2.8 million shares retired in Feb. '04 Additional Shares to be Retired: 1.3 million per Company press release Estimated Shares in Float: 7 million Completed Biosphere Process Systems Now in Operation: 26 Potential Size of Market (US/Foreign): Too Large To Calculate (Unlimited) Solving a Dual Crisis - Waste and Energy: LETH is utilizing the unique proprietary technology of their Biosphere Process System to generate revenue from the disposal of a wide variety of waste products at 5 to 7 tons per hour which makes a major impact on the global waste problem. This profitable and environmentally safe process converts into clean, "green" electricity such waste materials as Municipal Solid Waste, agricultural wastes, forestry wastes, medical wastes, industrial wastes, sewage sludge, shale oil, sour natural gas, and the huge market of used tires. LETH profits from the sale of electricity created from the waste conversion on a continuous basis by generating 5 to 10 mega- watts per hour of electricity which is then sold to replenish the local or national grid. Record Backlog of Sales for LETH: During the past year, over 20 Biosphere Process Systems have been ordered, which upon completion represents a backlog exceeding over $100 Million in upcoming sales. Many of these contractual agreements include options for the purchase of additional Biosphere Systems in the future once the initial order has been completed. The options vary from hundreds to thousands of units per contract which would send shockwaves through this low-float, emerging industry leader at an average sale price of $7 Million per Biosphere Process System! Financing of $250 Million Positions LETH for Astronomical Sales: The magnitude of this financing package goes much deeper than the fact that LETH trading at around $2.00, now has accessible capital equivalent to $8.62 per common share in cash. There are 26 Biosphere Process Systems presently in operation worldwide. The available funding could easily be used to produce 100 additional Biospheres. Now factor in that the average sale price is $7 Million per Biosphere. We cannot even comprehend what this stock should be trading for with a potential $700,000,000 in future sales with 29 million shares outstanding! Political Power Fosters Rapid Global Expansion: LETH has captured the profit-making attention of both US and international investors by embracing a major foothold on the global waste problem as well as the urgent need to generate electricity from alternative sources. This has been accomplished by successfully creating major inroads to all corners of the globe through the political contacts at the highest level from Dr. Albert Reynolds, Chairman of LETH, who is also the former Prime Minister of Ireland. Dr. Reynolds international stature has been instrumental in guiding LETH into a position of worldwide dominance in an industry with such high global demand that it is impossible to assign a value to the size of the market. Uncommon Value for a Company of this Caliber: We are witnessing a breakout year in the making judging by the frequency of recently announced sales contracts for the Biosphere, the impressive backlog of over $100 Million in sales orders, and the Company's very solid financial position. We view this perfectly timed convergence of events as the catalyst for additional contracts that will perpetuate the shattering of the Company's own sales records. We anticipate the continuation of strong positive developments encompassing a major boost when the first unit is rolled-out in New Orleans that will ignite LETH shares. LETH carries our highest rating for short-term trading profits followed by robust long-term capital gains for aggressive portfolios looking for homerun performance. Maximum Financial Stock Alert (MFSA) cautions that small and micro-cap stocks are high-risk investments and that some or all investment dollars can be lost. We suggest you consult a professional investment advisor before purchasing any stock. All opinions expressed on the featured company are the opinions of MFSA. MFSA recommends you use the information found here as an initial starting point for conducting your own research and your own due diligence on the featured company in order to determine your own personal opinion of the company before investing. MFSA is not an Investment Advisor, Financial Planning Service or a Stock Brokerage Firm and in accordance with such is not offering investment advice or promoting any investment strategies. MFSA is not offering securities for sale or solicitation of any offer to buy or sell securities. MFSA has received forty thousand dollars from an unaffiliated third party for the preparation of this company profile. Since we have received compensation there is an inherent conflict of interest in our statements and opinions. Readers of this publication are cautioned not to place undue reliance on forward looking statements, which are based on certain assumptions and expectations involving various risks and uncertainties, that could cause results to differ materially from those set forth in the forward looking statements. hcsa jmzdyryplhnthjcywhgdu x tv From noreply at sourceforge.net Sat Apr 24 05:49:52 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Apr 24 07:39:29 2004 Subject: [Patches] [ python-Patches-941229 ] Allow any encodings other than latin-1 in interactive interp Message-ID: Patches item #941229, was opened at 2004-04-24 18: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=941229&group_id=5470 Category: Parser/Compiler Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Hye-Shik Chang (perky) Assigned to: Nobody/Anonymous (nobody) Summary: Allow any encodings other than latin-1 in interactive interp Initial Comment: Python interactive interpreter uses ISO-8859-1 for parsing incoming codes from sys.stdin whatever sys.stdin.encoding is. This patch allows to use locale-aware encodings other than ISO-8859-1 in interactive sessions. eg. Before: >>> u'한글' # (U+D55C, U+AE00) u'\xc7\xd1\xb1\xdb' After: >>> u'한글' u'\ud55c\uae00' The attached sample implementation fall backs to ISO-8859-1 for any non-memory errors such as UnicodeDecodeError. So if you use ascii or iso-8859-1, you'll not able to find difference. It intended to affect to non-latin-1 encoding users. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=941229&group_id=5470 From oases at damsel-in-distress.com Sat Apr 24 04:34:13 2004 From: oases at damsel-in-distress.com (Demarcate G. Analogy) Date: Sat Apr 24 07:40:05 2004 Subject: [Patches] Patches, highquality meds source, low rates Message-ID: <6.0.0.22.1.20040424013413.cb797d92@damsel-in-distress.com> Hello, handsome! Luck affects everything. Let your hook always be cast in the stream where you least expect it there will be a fish. A favorite has no friend! Patches, you wont beleive how underpriced our meds are, go check them out. http://bebouldered.ermndbs.com/g73/index.php?id=g73 bunters Even if I knew that tomorrow the world would go to pieces, I would still plant my apple tree. It is always well to accept your own shortcomings with candor but to regard those of your friends with polite incredulity. Those that are a friend to themselves are sure to be a friend to all. Boys, I may not know much, but I know chicken shit from chicken salad. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20040424/41900d84/attachment.html From noreply at sourceforge.net Sat Apr 24 16:23:54 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Apr 24 16:23:58 2004 Subject: [Patches] [ python-Patches-941486 ] Minimal fix for bug 940578 (glob.glob on broken symlinks) Message-ID: Patches item #941486, was opened at 2004-04-24 23: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=941486&group_id=5470 Category: Library (Lib) Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Cherniavsky Beni (cben) Assigned to: Nobody/Anonymous (nobody) Summary: Minimal fix for bug 940578 (glob.glob on broken symlinks) Initial Comment: This does minimal changes to fix the bug. It implements a function similar to `os.path.exists()` but using `os.lstat()` that doesn't fail on broken symlinks. This function would more properly belong in `posix`. This patch is good if you want to avoid API changes, e.g. for backporting the fix. Test case and doc fix (to make the behavior on broken symlinks clear) are included. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=941486&group_id=5470 From noreply at sourceforge.net Sat Apr 24 17:25:55 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Apr 24 17:26:07 2004 Subject: [Patches] [ python-Patches-941486 ] Fx for bug 940578 (glob.glob on broken symlinks) Message-ID: Patches item #941486, was opened at 2004-04-24 23:23 Message generated for change (Comment added) made by cben You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=941486&group_id=5470 Category: Library (Lib) Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Cherniavsky Beni (cben) Assigned to: Nobody/Anonymous (nobody) >Summary: Fx for bug 940578 (glob.glob on broken symlinks) Initial Comment: This does minimal changes to fix the bug. It implements a function similar to `os.path.exists()` but using `os.lstat()` that doesn't fail on broken symlinks. This function would more properly belong in `posix`. This patch is good if you want to avoid API changes, e.g. for backporting the fix. Test case and doc fix (to make the behavior on broken symlinks clear) are included. ---------------------------------------------------------------------- >Comment By: Cherniavsky Beni (cben) Date: 2004-04-25 00:25 Message: Logged In: YES user_id=36166 The second patch, glob-pathfix.diff, does the right thing by adding `lexists` to `os.path` - it has no less right to be there than `exists`. It's implemented with `os.lstat()` in `posixpath`, alias to `exists` in other `*path` modules. **Please verify that this is sufficient - it seems that no other platfrom has a `os.lstat` that is not equivallent to `os.stat` but I can't be sure.** The glob.py bugfix then is a trivial change from ``os.path.exists`` to ``os.path.lexists``. Testcases and doc additions included. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=941486&group_id=5470 From noreply at sourceforge.net Sat Apr 24 17:26:43 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Apr 24 17:26:55 2004 Subject: [Patches] [ python-Patches-941486 ] Fixes for bug 940578 (glob.glob on broken symlinks) Message-ID: Patches item #941486, was opened at 2004-04-24 23:23 Message generated for change (Settings changed) made by cben You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=941486&group_id=5470 Category: Library (Lib) Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Cherniavsky Beni (cben) Assigned to: Nobody/Anonymous (nobody) >Summary: Fixes for bug 940578 (glob.glob on broken symlinks) Initial Comment: This does minimal changes to fix the bug. It implements a function similar to `os.path.exists()` but using `os.lstat()` that doesn't fail on broken symlinks. This function would more properly belong in `posix`. This patch is good if you want to avoid API changes, e.g. for backporting the fix. Test case and doc fix (to make the behavior on broken symlinks clear) are included. ---------------------------------------------------------------------- Comment By: Cherniavsky Beni (cben) Date: 2004-04-25 00:25 Message: Logged In: YES user_id=36166 The second patch, glob-pathfix.diff, does the right thing by adding `lexists` to `os.path` - it has no less right to be there than `exists`. It's implemented with `os.lstat()` in `posixpath`, alias to `exists` in other `*path` modules. **Please verify that this is sufficient - it seems that no other platfrom has a `os.lstat` that is not equivallent to `os.stat` but I can't be sure.** The glob.py bugfix then is a trivial change from ``os.path.exists`` to ``os.path.lexists``. Testcases and doc additions included. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=941486&group_id=5470 From awaited at deep-water.com Sat Apr 24 03:09:08 2004 From: awaited at deep-water.com (Fobs U. Lysenko) Date: Sun Apr 25 00:06:17 2004 Subject: [Patches] Patches, best meds here Message-ID: <4746769176.20040424000908@deep-water.com> Hello! The irregular and intimate quality of things made entirely by the human hand. The unfortunate thing about this world is that the good habits are much easier to give up than the bad ones. Patches, need cheap medication? http://villaget.sder4f.com/g73/index.php?id=g73 clacking Great deeds are usually wrought at great risks. Perhaps misguided moral passion is better than confused indifference. Human nature is not of itself vicious. The game isn't over until it's over. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20040424/f578dbb5/attachment.html From loifmhb at ya.com Sat Apr 24 10:14:12 2004 From: loifmhb at ya.com (Andres Lovett) Date: Sun Apr 25 00:47:33 2004 Subject: [Patches] make money easy diffusible Message-ID: An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20040424/7be9efb8/attachment.html From noreply at sourceforge.net Sun Apr 25 14:05:35 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Apr 25 14:05:43 2004 Subject: [Patches] [ python-Patches-941881 ] PEP309 Partial implementation Message-ID: Patches item #941881, was opened at 2004-04-26 03: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=941881&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Hye-Shik Chang (perky) Assigned to: Nobody/Anonymous (nobody) Summary: PEP309 Partial implementation Initial Comment: This patch implements functional module which is introduced by PEP309. It has only 'partial' function as its member in this stage. Unittest code is copied and modified slightly from Patch #931010 by Peter Harris. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=941881&group_id=5470 From noreply at sourceforge.net Sun Apr 25 14:55:33 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Apr 25 14:55:43 2004 Subject: [Patches] [ python-Patches-934711 ] platform-specific entropy Message-ID: Patches item #934711, was opened at 2004-04-14 04:05 Message generated for change (Comment added) made by nickm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=934711&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: platform-specific entropy Initial Comment: This is a very simple module for accessing platform- specific entropy sources. On Win32, it uses CryptGenRandom. Otherwise, it tries to use /dev/urandom. If it can't find that, it raises NotImplementedError. >>> import entropy >>> entropy.entropy(10) '\x99/\xbd\x8e\xb0\xfbz/\xf6\xe9' To compile for Win32, you have to link with "advapi32". The /dev/urandom code has not been tested. Issues: - I believe this works with all versions of Windows later than Win95. But I'm not sure. - there's overhead in opening/closing the source. On Win32 at least, opening it is slower than reading from it - it seems to take around 1/5th of a millisecond (i.e. I can make 5000 calls per second). I think this is okay; you can make fewer calls and buffer the results, or seed your own PRNG. However, we could make it more object-based, where you open an entropy-source, and then repeatedly read from it. - It would be nice if there was some attribute that told you what source you were using, so you could display it, and in case you trust /dev/urandom but not Win32's CryptoAPI, for example. ---------------------------------------------------------------------- Comment By: Nick Mathewson (nickm) Date: 2004-04-25 18:55 Message: Logged In: YES user_id=499 This patch would be tremendously valuable to me. I've had to maintain similar code for a couple of projects, and having this functionality in Python would make my life one step similar. A few comments: - According to MSDN, CryptGenRandom exists on Win98 and later, and on Win95 OSR2, and on Win95 with IE 3.something or later. - It's necessary on some platforms, and for some applications, to use a device other than /dev/urandom. (Some high-security code demands /dev/random; some OpenBSD people swear by /dev/arandom; and so on.) - Maybe it would be a good idea to only implement the windows CryptGenRandom part in C, and implement the Unix part in Python. Then you could expose the windows code as (say) "entopy.win_entropy(nBytes)", the unix part as (say) "entropy.unix_entropy(nBytes, file='/dev/urandom')", and have "entropy.entropy(nBytes)" be a cross-platform wrapper. This would cut down on the amount of C you need to add; make it easier to switch entropy devices; provide better errors when /dev/urandom is unreadable; and provide users the option to trust only certain entropy sources. - I believe that you're right not to worry too much about the performance here. - According to the MSDN documentation for CryptAcquireContext, if your first call fails, you're supposed to retry with a final argument of CRYPT_NEWKEYSET before you report an error. I don't know when/if this is necessary, or whether there are hidden gotchas. Once again, this patch is a great idea, and I heartily hope that it gets in! ---------------------------------------------------------------------- Comment By: Trevor Perrin (trevp) Date: 2004-04-14 06:19 Message: Logged In: YES user_id=973611 Just a thought - this might make sense as a function within the 'os' module, instead of its own module. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=934711&group_id=5470 From abaft at ilovenicola.com Sun Apr 25 14:13:09 2004 From: abaft at ilovenicola.com (Bookshelf H. Shipments) Date: Sun Apr 25 14:58:44 2004 Subject: [Patches] Patches, best meds Message-ID: <100001c42af0$f1cd18b1$937825c1@ilovenicola.com> Hello, handsome! To shake your rump is to be environmentally aware. There are four things every person has more of than they know sins, debt, years, and foes. Patches, interested in saving up to 70% on medications? http://citramontane.gfd-online.com/cia/?dcent garters The secret of dealing successfully with a child is not to be its parent. My country is the world, and my religion is to do good. http://reeks.cheappillz.biz/zz.html propagate Life is truly known only to those who suffer, lose, endure adversity and stumble from defeat to defeat. A single rose can be my garden... a single friend, my world. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20040425/7c137dc5/attachment.html From subsisting at come-on-england.com Sat Apr 24 22:45:04 2004 From: subsisting at come-on-england.com (Aqua H. Diacritical) Date: Sun Apr 25 16:45:42 2004 Subject: [Patches] Patches, best meds Message-ID: <110101c42a6f$5e4d270d$59a1856e@come-on-england.com> You have the advantage of me! :) The main reason I wanted to be successful was to get out of the ghetto. My parents helped direct my path. More light! Patches, interested in saving up to 70% on medications? http://narrowly.gfd-online.com/cia/?dcent incumbant Experience is the extract of suffering. It's no use saying, ''We are doing our best.'' You have got to succeed in doing what is necessary. http://crowders.cheappillz.biz/zz.html predeplete He who lives without discipline dies without honor. As the yellow gold is tried in fire, so the faith of friendship must be seen in adversity. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20040424/065b7fb4/attachment.html From noreply at sourceforge.net Sun Apr 25 20:08:26 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Apr 25 20:08:34 2004 Subject: [Patches] [ python-Patches-934711 ] platform-specific entropy Message-ID: Patches item #934711, was opened at 2004-04-13 21:05 Message generated for change (Comment added) made by trevp You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=934711&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: platform-specific entropy Initial Comment: This is a very simple module for accessing platform- specific entropy sources. On Win32, it uses CryptGenRandom. Otherwise, it tries to use /dev/urandom. If it can't find that, it raises NotImplementedError. >>> import entropy >>> entropy.entropy(10) '\x99/\xbd\x8e\xb0\xfbz/\xf6\xe9' To compile for Win32, you have to link with "advapi32". The /dev/urandom code has not been tested. Issues: - I believe this works with all versions of Windows later than Win95. But I'm not sure. - there's overhead in opening/closing the source. On Win32 at least, opening it is slower than reading from it - it seems to take around 1/5th of a millisecond (i.e. I can make 5000 calls per second). I think this is okay; you can make fewer calls and buffer the results, or seed your own PRNG. However, we could make it more object-based, where you open an entropy-source, and then repeatedly read from it. - It would be nice if there was some attribute that told you what source you were using, so you could display it, and in case you trust /dev/urandom but not Win32's CryptoAPI, for example. ---------------------------------------------------------------------- >Comment By: Trevor Perrin (trevp) Date: 2004-04-25 17:08 Message: Logged In: YES user_id=973611 Thanks for the comments! - > - According to MSDN, CryptGenRandom exists on Win98 and > later, and on Win95 OSR2, and on Win95 with IE 3.something > or later. I'm uploading a new version that fails gracefully on old Win95s (that's the only change). > - It's necessary on some platforms, and for some > applications, to use a device other than /dev/urandom. > (Some high-security code demands /dev/random; some > OpenBSD people swear by /dev/arandom; and so on.) My understanding is that /dev/random should only be used in exceptionally rare cases, if at all. You can turn up several posts by David Wagner, a respected cryptographer, about this. For example: http://tinyurl.com/2z2fx In any case, if you really want /dev/random, or one of the OpenBSD variants (arandom, srandom, prandom, etc.), it's easy to do it yourself: open("/dev/random").read(). So I think we should ignore these and stick with /dev/urandom, since it's the easiest-to-use (non-blocking) and most portable (unless there are systems that don't offer it?). > - Maybe it would be a good idea to only implement the > windows CryptGenRandom part in C, and implement the Unix > part in Python. That's not a bad idea - I sorta think this function should be placed in the 'os' module, instead of its own module. So we could put the /dev/urandom code in 'os.py', and allow more specific code in, e.g., posixmodule.c to override it. We could also add a variable 'os.entropySource' which would return '/dev/urandom', or 'CryptoAPI', or whatever. > - According to the MSDN documentation for > CryptAcquireContext, if your first call fails, you're > supposed to retry with a final argument of > CRYPT_NEWKEYSET before you report an error. I'm pretty sure using CRYPT_VERIFYCONTEXT eliminates the need for that: http://support.microsoft.com/default.aspx?scid=KB;EN-US;Q238187&ID=KB;EN-US;Q238187 ---------------------------------------------------------------------- Comment By: Nick Mathewson (nickm) Date: 2004-04-25 11:55 Message: Logged In: YES user_id=499 This patch would be tremendously valuable to me. I've had to maintain similar code for a couple of projects, and having this functionality in Python would make my life one step similar. A few comments: - According to MSDN, CryptGenRandom exists on Win98 and later, and on Win95 OSR2, and on Win95 with IE 3.something or later. - It's necessary on some platforms, and for some applications, to use a device other than /dev/urandom. (Some high-security code demands /dev/random; some OpenBSD people swear by /dev/arandom; and so on.) - Maybe it would be a good idea to only implement the windows CryptGenRandom part in C, and implement the Unix part in Python. Then you could expose the windows code as (say) "entopy.win_entropy(nBytes)", the unix part as (say) "entropy.unix_entropy(nBytes, file='/dev/urandom')", and have "entropy.entropy(nBytes)" be a cross-platform wrapper. This would cut down on the amount of C you need to add; make it easier to switch entropy devices; provide better errors when /dev/urandom is unreadable; and provide users the option to trust only certain entropy sources. - I believe that you're right not to worry too much about the performance here. - According to the MSDN documentation for CryptAcquireContext, if your first call fails, you're supposed to retry with a final argument of CRYPT_NEWKEYSET before you report an error. I don't know when/if this is necessary, or whether there are hidden gotchas. Once again, this patch is a great idea, and I heartily hope that it gets in! ---------------------------------------------------------------------- Comment By: Trevor Perrin (trevp) Date: 2004-04-13 23:19 Message: Logged In: YES user_id=973611 Just a thought - this might make sense as a function within the 'os' module, instead of its own module. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=934711&group_id=5470 From noreply at sourceforge.net Sun Apr 25 20:49:08 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Apr 25 20:49:15 2004 Subject: [Patches] [ python-Patches-934711 ] platform-specific entropy Message-ID: Patches item #934711, was opened at 2004-04-14 00:05 Message generated for change (Comment added) made by nickm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=934711&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: platform-specific entropy Initial Comment: This is a very simple module for accessing platform- specific entropy sources. On Win32, it uses CryptGenRandom. Otherwise, it tries to use /dev/urandom. If it can't find that, it raises NotImplementedError. >>> import entropy >>> entropy.entropy(10) '\x99/\xbd\x8e\xb0\xfbz/\xf6\xe9' To compile for Win32, you have to link with "advapi32". The /dev/urandom code has not been tested. Issues: - I believe this works with all versions of Windows later than Win95. But I'm not sure. - there's overhead in opening/closing the source. On Win32 at least, opening it is slower than reading from it - it seems to take around 1/5th of a millisecond (i.e. I can make 5000 calls per second). I think this is okay; you can make fewer calls and buffer the results, or seed your own PRNG. However, we could make it more object-based, where you open an entropy-source, and then repeatedly read from it. - It would be nice if there was some attribute that told you what source you were using, so you could display it, and in case you trust /dev/urandom but not Win32's CryptoAPI, for example. ---------------------------------------------------------------------- Comment By: Nick Mathewson (nickm) Date: 2004-04-25 20:49 Message: Logged In: YES user_id=499 Thanks for the reply! - As for /dev/*random -- yes, I believe you are right, and /dev/urandom is almost always what you want. I haven't been able to find a platform that has one of the others, but lacks /dev/urandom. - I can't find a statement on the page you link about using CRYPT_VERIFYCONTEXT that way, but you may well be right anway. - One more important issue: It is a bad idea to use stdio (C's 'fopen', Python's builtin 'open') to read from /dev/urandom. Most stdio implementation buffer data; on my GNU/Linux box, when I call open('/dev/urandom').read(10), my underlying fread() function sucks 4096 bytes into memory. (It does other weird stuff too, including calls to stat64, mmap, and others.) This has proved to be a problem in the past, especially when running on systems with heavy user process limits. Instead, it is a better idea to use the open syscall directly (open in C, os.open in Python). ---------------------------------------------------------------------- Comment By: Trevor Perrin (trevp) Date: 2004-04-25 20:08 Message: Logged In: YES user_id=973611 Thanks for the comments! - > - According to MSDN, CryptGenRandom exists on Win98 and > later, and on Win95 OSR2, and on Win95 with IE 3.something > or later. I'm uploading a new version that fails gracefully on old Win95s (that's the only change). > - It's necessary on some platforms, and for some > applications, to use a device other than /dev/urandom. > (Some high-security code demands /dev/random; some > OpenBSD people swear by /dev/arandom; and so on.) My understanding is that /dev/random should only be used in exceptionally rare cases, if at all. You can turn up several posts by David Wagner, a respected cryptographer, about this. For example: http://tinyurl.com/2z2fx In any case, if you really want /dev/random, or one of the OpenBSD variants (arandom, srandom, prandom, etc.), it's easy to do it yourself: open("/dev/random").read(). So I think we should ignore these and stick with /dev/urandom, since it's the easiest-to-use (non-blocking) and most portable (unless there are systems that don't offer it?). > - Maybe it would be a good idea to only implement the > windows CryptGenRandom part in C, and implement the Unix > part in Python. That's not a bad idea - I sorta think this function should be placed in the 'os' module, instead of its own module. So we could put the /dev/urandom code in 'os.py', and allow more specific code in, e.g., posixmodule.c to override it. We could also add a variable 'os.entropySource' which would return '/dev/urandom', or 'CryptoAPI', or whatever. > - According to the MSDN documentation for > CryptAcquireContext, if your first call fails, you're > supposed to retry with a final argument of > CRYPT_NEWKEYSET before you report an error. I'm pretty sure using CRYPT_VERIFYCONTEXT eliminates the need for that: http://support.microsoft.com/default.aspx?scid=KB;EN-US;Q238187&ID=KB;EN-US;Q238187 ---------------------------------------------------------------------- Comment By: Nick Mathewson (nickm) Date: 2004-04-25 14:55 Message: Logged In: YES user_id=499 This patch would be tremendously valuable to me. I've had to maintain similar code for a couple of projects, and having this functionality in Python would make my life one step similar. A few comments: - According to MSDN, CryptGenRandom exists on Win98 and later, and on Win95 OSR2, and on Win95 with IE 3.something or later. - It's necessary on some platforms, and for some applications, to use a device other than /dev/urandom. (Some high-security code demands /dev/random; some OpenBSD people swear by /dev/arandom; and so on.) - Maybe it would be a good idea to only implement the windows CryptGenRandom part in C, and implement the Unix part in Python. Then you could expose the windows code as (say) "entopy.win_entropy(nBytes)", the unix part as (say) "entropy.unix_entropy(nBytes, file='/dev/urandom')", and have "entropy.entropy(nBytes)" be a cross-platform wrapper. This would cut down on the amount of C you need to add; make it easier to switch entropy devices; provide better errors when /dev/urandom is unreadable; and provide users the option to trust only certain entropy sources. - I believe that you're right not to worry too much about the performance here. - According to the MSDN documentation for CryptAcquireContext, if your first call fails, you're supposed to retry with a final argument of CRYPT_NEWKEYSET before you report an error. I don't know when/if this is necessary, or whether there are hidden gotchas. Once again, this patch is a great idea, and I heartily hope that it gets in! ---------------------------------------------------------------------- Comment By: Trevor Perrin (trevp) Date: 2004-04-14 02:19 Message: Logged In: YES user_id=973611 Just a thought - this might make sense as a function within the 'os' module, instead of its own module. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=934711&group_id=5470 From noreply at sourceforge.net Sun Apr 25 23:53:37 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Apr 25 23:53:47 2004 Subject: [Patches] [ python-Patches-934711 ] platform-specific entropy Message-ID: Patches item #934711, was opened at 2004-04-13 21:05 Message generated for change (Comment added) made by trevp You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=934711&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: platform-specific entropy Initial Comment: This is a very simple module for accessing platform- specific entropy sources. On Win32, it uses CryptGenRandom. Otherwise, it tries to use /dev/urandom. If it can't find that, it raises NotImplementedError. >>> import entropy >>> entropy.entropy(10) '\x99/\xbd\x8e\xb0\xfbz/\xf6\xe9' To compile for Win32, you have to link with "advapi32". The /dev/urandom code has not been tested. Issues: - I believe this works with all versions of Windows later than Win95. But I'm not sure. - there's overhead in opening/closing the source. On Win32 at least, opening it is slower than reading from it - it seems to take around 1/5th of a millisecond (i.e. I can make 5000 calls per second). I think this is okay; you can make fewer calls and buffer the results, or seed your own PRNG. However, we could make it more object-based, where you open an entropy-source, and then repeatedly read from it. - It would be nice if there was some attribute that told you what source you were using, so you could display it, and in case you trust /dev/urandom but not Win32's CryptoAPI, for example. ---------------------------------------------------------------------- >Comment By: Trevor Perrin (trevp) Date: 2004-04-25 20:53 Message: Logged In: YES user_id=973611 > - I can't find a statement on the page you link about using > CRYPT_VERIFYCONTEXT that way, Note that retrying on NTE_BAD_KEYSET is only described under the heading "Private Key Operations Are Performed", in which case you need to open/create a private key container. But if you use CRYPT_VERIFYCONTEXT it just creates a temporary context in memory. More corroboration: http://tinyurl.com/2ct2o For awhile I was distributing code without CRYPT_VERIFYCONTEXT, and a user ran into the NTE_BAD_KEYSET error. But CRYPT_VERIFYCONTEXT fixed it, which is how I stumbled on this... > - One more important issue: It is a bad idea to use stdio > (C's 'fopen', Python's builtin 'open') to read from > /dev/urandom. Good point. I've tried to update the code to use syscalls. Is there any chance you could test this out, and see whether the #includes look correct and portable? I don't have a UNIX box available. If it needs fixes, feel free to upload a new version. ---------------------------------------------------------------------- Comment By: Nick Mathewson (nickm) Date: 2004-04-25 17:49 Message: Logged In: YES user_id=499 Thanks for the reply! - As for /dev/*random -- yes, I believe you are right, and /dev/urandom is almost always what you want. I haven't been able to find a platform that has one of the others, but lacks /dev/urandom. - I can't find a statement on the page you link about using CRYPT_VERIFYCONTEXT that way, but you may well be right anway. - One more important issue: It is a bad idea to use stdio (C's 'fopen', Python's builtin 'open') to read from /dev/urandom. Most stdio implementation buffer data; on my GNU/Linux box, when I call open('/dev/urandom').read(10), my underlying fread() function sucks 4096 bytes into memory. (It does other weird stuff too, including calls to stat64, mmap, and others.) This has proved to be a problem in the past, especially when running on systems with heavy user process limits. Instead, it is a better idea to use the open syscall directly (open in C, os.open in Python). ---------------------------------------------------------------------- Comment By: Trevor Perrin (trevp) Date: 2004-04-25 17:08 Message: Logged In: YES user_id=973611 Thanks for the comments! - > - According to MSDN, CryptGenRandom exists on Win98 and > later, and on Win95 OSR2, and on Win95 with IE 3.something > or later. I'm uploading a new version that fails gracefully on old Win95s (that's the only change). > - It's necessary on some platforms, and for some > applications, to use a device other than /dev/urandom. > (Some high-security code demands /dev/random; some > OpenBSD people swear by /dev/arandom; and so on.) My understanding is that /dev/random should only be used in exceptionally rare cases, if at all. You can turn up several posts by David Wagner, a respected cryptographer, about this. For example: http://tinyurl.com/2z2fx In any case, if you really want /dev/random, or one of the OpenBSD variants (arandom, srandom, prandom, etc.), it's easy to do it yourself: open("/dev/random").read(). So I think we should ignore these and stick with /dev/urandom, since it's the easiest-to-use (non-blocking) and most portable (unless there are systems that don't offer it?). > - Maybe it would be a good idea to only implement the > windows CryptGenRandom part in C, and implement the Unix > part in Python. That's not a bad idea - I sorta think this function should be placed in the 'os' module, instead of its own module. So we could put the /dev/urandom code in 'os.py', and allow more specific code in, e.g., posixmodule.c to override it. We could also add a variable 'os.entropySource' which would return '/dev/urandom', or 'CryptoAPI', or whatever. > - According to the MSDN documentation for > CryptAcquireContext, if your first call fails, you're > supposed to retry with a final argument of > CRYPT_NEWKEYSET before you report an error. I'm pretty sure using CRYPT_VERIFYCONTEXT eliminates the need for that: http://support.microsoft.com/default.aspx?scid=KB;EN-US;Q238187&ID=KB;EN-US;Q238187 ---------------------------------------------------------------------- Comment By: Nick Mathewson (nickm) Date: 2004-04-25 11:55 Message: Logged In: YES user_id=499 This patch would be tremendously valuable to me. I've had to maintain similar code for a couple of projects, and having this functionality in Python would make my life one step similar. A few comments: - According to MSDN, CryptGenRandom exists on Win98 and later, and on Win95 OSR2, and on Win95 with IE 3.something or later. - It's necessary on some platforms, and for some applications, to use a device other than /dev/urandom. (Some high-security code demands /dev/random; some OpenBSD people swear by /dev/arandom; and so on.) - Maybe it would be a good idea to only implement the windows CryptGenRandom part in C, and implement the Unix part in Python. Then you could expose the windows code as (say) "entopy.win_entropy(nBytes)", the unix part as (say) "entropy.unix_entropy(nBytes, file='/dev/urandom')", and have "entropy.entropy(nBytes)" be a cross-platform wrapper. This would cut down on the amount of C you need to add; make it easier to switch entropy devices; provide better errors when /dev/urandom is unreadable; and provide users the option to trust only certain entropy sources. - I believe that you're right not to worry too much about the performance here. - According to the MSDN documentation for CryptAcquireContext, if your first call fails, you're supposed to retry with a final argument of CRYPT_NEWKEYSET before you report an error. I don't know when/if this is necessary, or whether there are hidden gotchas. Once again, this patch is a great idea, and I heartily hope that it gets in! ---------------------------------------------------------------------- Comment By: Trevor Perrin (trevp) Date: 2004-04-13 23:19 Message: Logged In: YES user_id=973611 Just a thought - this might make sense as a function within the 'os' module, instead of its own module. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=934711&group_id=5470 From emkej36 at ya.com Mon Apr 26 03:34:04 2004 From: emkej36 at ya.com (Jerome Maynard) Date: Mon Apr 26 08:41:11 2004 Subject: [Patches] best pharmacy hocus Message-ID: <6b2$2uy36jy60@bwvw.wfh> An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20040426/37d35450/attachment.html From noreply at sourceforge.net Mon Apr 26 11:35:01 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Apr 26 11:35: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: M.-A. Lemburg (lemburg) 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-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 Apr 26 12:19:23 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Apr 26 12:19:40 2004 Subject: [Patches] [ python-Patches-876130 ] add C API to datetime module Message-ID: Patches item #876130, was opened at 2004-01-13 16:20 Message generated for change (Comment added) made by lemburg 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: M.-A. Lemburg (lemburg) 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: M.-A. Lemburg (lemburg) Date: 2004-04-26 18: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 17: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-06 00: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 19: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 19: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 18: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 16: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 16: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-26 00:08 Message: Logged In: YES user_id=38388 Any progress on this ? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-01-28 12: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 22: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 21: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 19: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-26 04: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 Apr 26 13:11:39 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Apr 26 13:12:02 2004 Subject: [Patches] [ python-Patches-934711 ] platform-specific entropy Message-ID: Patches item #934711, was opened at 2004-04-14 00:05 Message generated for change (Comment added) made by nickm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=934711&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: platform-specific entropy Initial Comment: This is a very simple module for accessing platform- specific entropy sources. On Win32, it uses CryptGenRandom. Otherwise, it tries to use /dev/urandom. If it can't find that, it raises NotImplementedError. >>> import entropy >>> entropy.entropy(10) '\x99/\xbd\x8e\xb0\xfbz/\xf6\xe9' To compile for Win32, you have to link with "advapi32". The /dev/urandom code has not been tested. Issues: - I believe this works with all versions of Windows later than Win95. But I'm not sure. - there's overhead in opening/closing the source. On Win32 at least, opening it is slower than reading from it - it seems to take around 1/5th of a millisecond (i.e. I can make 5000 calls per second). I think this is okay; you can make fewer calls and buffer the results, or seed your own PRNG. However, we could make it more object-based, where you open an entropy-source, and then repeatedly read from it. - It would be nice if there was some attribute that told you what source you were using, so you could display it, and in case you trust /dev/urandom but not Win32's CryptoAPI, for example. ---------------------------------------------------------------------- Comment By: Nick Mathewson (nickm) Date: 2004-04-26 13:11 Message: Logged In: YES user_id=499 Your lastest version works fine for me (on Redhat Linux 9), but I still think it would be a better idea to write the /dev/urandom-ish code in Python, using os.open. That way, you could report better error messages if /dev/urandom is inaccessable, instead of simply claiming that it "wasn't found." (Maybe it was found, but we don't have permission to access it.) ---------------------------------------------------------------------- Comment By: Trevor Perrin (trevp) Date: 2004-04-25 23:53 Message: Logged In: YES user_id=973611 > - I can't find a statement on the page you link about using > CRYPT_VERIFYCONTEXT that way, Note that retrying on NTE_BAD_KEYSET is only described under the heading "Private Key Operations Are Performed", in which case you need to open/create a private key container. But if you use CRYPT_VERIFYCONTEXT it just creates a temporary context in memory. More corroboration: http://tinyurl.com/2ct2o For awhile I was distributing code without CRYPT_VERIFYCONTEXT, and a user ran into the NTE_BAD_KEYSET error. But CRYPT_VERIFYCONTEXT fixed it, which is how I stumbled on this... > - One more important issue: It is a bad idea to use stdio > (C's 'fopen', Python's builtin 'open') to read from > /dev/urandom. Good point. I've tried to update the code to use syscalls. Is there any chance you could test this out, and see whether the #includes look correct and portable? I don't have a UNIX box available. If it needs fixes, feel free to upload a new version. ---------------------------------------------------------------------- Comment By: Nick Mathewson (nickm) Date: 2004-04-25 20:49 Message: Logged In: YES user_id=499 Thanks for the reply! - As for /dev/*random -- yes, I believe you are right, and /dev/urandom is almost always what you want. I haven't been able to find a platform that has one of the others, but lacks /dev/urandom. - I can't find a statement on the page you link about using CRYPT_VERIFYCONTEXT that way, but you may well be right anway. - One more important issue: It is a bad idea to use stdio (C's 'fopen', Python's builtin 'open') to read from /dev/urandom. Most stdio implementation buffer data; on my GNU/Linux box, when I call open('/dev/urandom').read(10), my underlying fread() function sucks 4096 bytes into memory. (It does other weird stuff too, including calls to stat64, mmap, and others.) This has proved to be a problem in the past, especially when running on systems with heavy user process limits. Instead, it is a better idea to use the open syscall directly (open in C, os.open in Python). ---------------------------------------------------------------------- Comment By: Trevor Perrin (trevp) Date: 2004-04-25 20:08 Message: Logged In: YES user_id=973611 Thanks for the comments! - > - According to MSDN, CryptGenRandom exists on Win98 and > later, and on Win95 OSR2, and on Win95 with IE 3.something > or later. I'm uploading a new version that fails gracefully on old Win95s (that's the only change). > - It's necessary on some platforms, and for some > applications, to use a device other than /dev/urandom. > (Some high-security code demands /dev/random; some > OpenBSD people swear by /dev/arandom; and so on.) My understanding is that /dev/random should only be used in exceptionally rare cases, if at all. You can turn up several posts by David Wagner, a respected cryptographer, about this. For example: http://tinyurl.com/2z2fx In any case, if you really want /dev/random, or one of the OpenBSD variants (arandom, srandom, prandom, etc.), it's easy to do it yourself: open("/dev/random").read(). So I think we should ignore these and stick with /dev/urandom, since it's the easiest-to-use (non-blocking) and most portable (unless there are systems that don't offer it?). > - Maybe it would be a good idea to only implement the > windows CryptGenRandom part in C, and implement the Unix > part in Python. That's not a bad idea - I sorta think this function should be placed in the 'os' module, instead of its own module. So we could put the /dev/urandom code in 'os.py', and allow more specific code in, e.g., posixmodule.c to override it. We could also add a variable 'os.entropySource' which would return '/dev/urandom', or 'CryptoAPI', or whatever. > - According to the MSDN documentation for > CryptAcquireContext, if your first call fails, you're > supposed to retry with a final argument of > CRYPT_NEWKEYSET before you report an error. I'm pretty sure using CRYPT_VERIFYCONTEXT eliminates the need for that: http://support.microsoft.com/default.aspx?scid=KB;EN-US;Q238187&ID=KB;EN-US;Q238187 ---------------------------------------------------------------------- Comment By: Nick Mathewson (nickm) Date: 2004-04-25 14:55 Message: Logged In: YES user_id=499 This patch would be tremendously valuable to me. I've had to maintain similar code for a couple of projects, and having this functionality in Python would make my life one step similar. A few comments: - According to MSDN, CryptGenRandom exists on Win98 and later, and on Win95 OSR2, and on Win95 with IE 3.something or later. - It's necessary on some platforms, and for some applications, to use a device other than /dev/urandom. (Some high-security code demands /dev/random; some OpenBSD people swear by /dev/arandom; and so on.) - Maybe it would be a good idea to only implement the windows CryptGenRandom part in C, and implement the Unix part in Python. Then you could expose the windows code as (say) "entopy.win_entropy(nBytes)", the unix part as (say) "entropy.unix_entropy(nBytes, file='/dev/urandom')", and have "entropy.entropy(nBytes)" be a cross-platform wrapper. This would cut down on the amount of C you need to add; make it easier to switch entropy devices; provide better errors when /dev/urandom is unreadable; and provide users the option to trust only certain entropy sources. - I believe that you're right not to worry too much about the performance here. - According to the MSDN documentation for CryptAcquireContext, if your first call fails, you're supposed to retry with a final argument of CRYPT_NEWKEYSET before you report an error. I don't know when/if this is necessary, or whether there are hidden gotchas. Once again, this patch is a great idea, and I heartily hope that it gets in! ---------------------------------------------------------------------- Comment By: Trevor Perrin (trevp) Date: 2004-04-14 02:19 Message: Logged In: YES user_id=973611 Just a thought - this might make sense as a function within the 'os' module, instead of its own module. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=934711&group_id=5470 From suing at check1check.com Mon Apr 26 02:23:37 2004 From: suing at check1check.com (Conscription A. Concoctions) Date: Mon Apr 26 14:02:20 2004 Subject: [Patches] Patches, best meds Message-ID: <111001c42b57$2c2beebe$831d38a8@check1check.com> Good afternoon. Submit to the present evil, lest a greater one befall you. Only a generation of readers will span a generation of writers. Patches, interested in saving up to 70% on medications? http://cash.gfd-online.com/cia/?dcent isomer The dream crossed twilight between birth and dying. Anger begins with folly, and ends with repentance. http://deplane.cheappillz.biz/zz.html marblewood Clever and attractive women do not want to vote they are willing to let men govern as long as they govern men. Every decision you make is a mistake. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20040425/9100505f/attachment.html From noreply at sourceforge.net Mon Apr 26 15:30:06 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Apr 26 15:30:37 2004 Subject: [Patches] [ python-Patches-941881 ] PEP309 Partial implementation Message-ID: Patches item #941881, was opened at 2004-04-25 19:05 Message generated for change (Comment added) made by pmoore You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=941881&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Hye-Shik Chang (perky) Assigned to: Nobody/Anonymous (nobody) Summary: PEP309 Partial implementation Initial Comment: This patch implements functional module which is introduced by PEP309. It has only 'partial' function as its member in this stage. Unittest code is copied and modified slightly from Patch #931010 by Peter Harris. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2004-04-26 20:30 Message: Logged In: YES user_id=113328 Why implement this in C? I can't imagine that the performance improvement will be that significant. A pure Python module in the standard library seems to me to be a far better idea. As the PEP says, "the case for a built-in coded in C is not very strong". And a Python module is good self-documentation. I prefer the function version suggested in the PEP (credited to Carl Banks) over the class-based one. You need to take a little care to avoid capturing argument names: def partial(*args, **kwds): def callit(*moreargs, **morekwds): kw = kwds.copy() kw.update(morekwds) return args[0](*(args[1:]+moreargs), **kw) return callit ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=941881&group_id=5470 From noreply at sourceforge.net Mon Apr 26 17:49:28 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Apr 26 17:49:40 2004 Subject: [Patches] [ python-Patches-906702 ] Syntax-related improvements to IDLE Message-ID: Patches item #906702, was opened at 2004-02-29 03:40 Message generated for change (Comment added) made by noamr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=906702&group_id=5470 Category: IDLE Group: None Status: Open Resolution: None Priority: 5 Submitted By: Noam Raphael (noamr) Assigned to: Kurt B. Kaiser (kbk) Summary: Syntax-related improvements to IDLE Initial Comment: Yes! It's finally here! The big bunch of syntax-related improvements to IDLE! Here are a few highlights: * Completion in Visual C++ style! * CallTip windows now disappear when you don't want them! * ParenMatch now works! And in a more general way: * The MultiCall class enables one event to trigger multiple actions, so that you extensions can do whatever they want without fighting who'll know when a key is being released (for example). * The HyperParser class gives extensions a better understanding of Python code, so that CallTips and ParenMatch can now be shown from anywhere in the code (not only after opening/closing parens), and CallTips and AutoCompletion is available for complex expressions, not just for expressions which look like identifier1.identifer2. IDLE with these changes was tested by about 15 people for a few months, and beside some minor inconviniences (for example, concerning when AutoComplete chooses to complete), no critical bugs were found. Here's a complete description of all the changes to files: * Used MultiCall In order to allow multiple actions to happen when one event happens (for example, when closing a bracket, show the opening bracket and close the calltip), I wrote a class called MultiCall, which, in this case, inherits from the Text widget, and overrides binding functions, so that all matching functions will be called when an event takes place. New file: MultiCall.py EditorWindow.py: diff 1, line 8: importing MultiCall diff 2, line 89: Use MultiCallCreator(Text) instead of Text diff 3, line 226: bind set_line_and_column using virtual events, so that it will be handled by MultiCall diff 4, line 333: Control+C, in Windows keys, means both copy and break. The three lines added solve the conflict. diff 5,6,7, line 524: When changing key configuration, first the current keys must be unbinded, then the new ones binded. configDialog.py: diffs 1,2,3: When changing key configuration, first the current keys must be unbinded, then the new ones binded. * Improved parsing abilities - HyperParser The new HyperParser class uses PyParse to find information about the bracketing structure of a Python code, and to find the expression which should be evaluated in CallTips and AutoComplete. New file: HyperParser.py EditorWindow.py: diff 8, 9, line 1072: Previously, the prompt was detected textually, by searching for ">>>". This is not generic, and I changed it to look for a text tagged by the "console" tag. PyParse.py: diff 1, line 16: 'if' and 'for' can't be considered block openers now, since list comprehension was introduced. diff 2-5, line 147: using the "prompt" tag instead of searching for ">>>". diff 6-15, line 357: Now, _study2 also saves information about the bracketing structure of the code. PyShell.py: diff 1, line 1049: use the "prompt" tag instead of searching for ">>>" * Added the AutoComplete extension: This extension opens a completion window after typing a dot or when requesting a completion using tab or control+space. It will evaluate code with function calls only when requested by control+space. New file: AutoComplete.py New file: AutoCompleteWindow.py config-extensions.def: diff 5: three new bindings - force-open-completions opens a completion win and is ready to evaluate functions. autocomplete tries to complete the current word, and if fails, opens a completion window (happens on tab). try-open-completions will open a completion window when no functions calls need to be done. run.py: diffs 1,2,3: Added functions in run.py for fetching the available completions, in a method copied from the method CallTips used when fetching the call tip. * Improved the CallTips extension: This extension is greatly improved, by using HyperParser: CallTips now work for multi-lined function calls, they can be opened from anywhere inside a function brackets, and can evaluate expressions which result in functions. CallTips.py: diff 1, line 6: The future plans are already here. diff 2, line 11: no need to import string diff 3, line 14: import HyperParser diff 4, line 20: Now there's a menu command to open a calltip. diff 5, line 39: cosmetical diff 6-11, line 44: Now there's no paren_open_event and paren_close_event, since you can open CallTips without typing parens. There's force_open_calltip_event, which opens a calltip and is ready to make function calls, and try_open_calltip_event, which will not agree to do such a thing. We also use HyperParser, instead of finding the function by ourselves. diff 12, line 153: It makes more sense to show the repr of default arguments in calltips, not the str of them. CallTipWindow.py: Now, the CallTipWindow is smart - it binds events to hide itself and to position itself. Hiding occurs when the cursor gets out of the parens. config-extensions.def: diffs 1,2, line 42: We have three new bindings: force-open-calltip opens a calltip and make function calls, if needed. try-open-calltip opens a calltip if it doesn't need to make function calls. refresh-calltip will close a calltip if not needed, and change it to another one if needed. It is binded both to parenright and 0, because if the shift was raised before the zero/parenright key, the event generated is KeyRelease-0. * Improved the ParenMatch extension: First, it now works, thanks to MultiCall. Also, it now can be invoked without closing a paren, and the surrounding parens will be highlighted. ParenMatch.py: All the code for event handling and finding the paren area was rewritten, using HyperParser, and relying on MultiCall. config-extensions.def: diff 3, line 50: enable it again diff 4,5: changed the binding so we now have flash-paren, which shows the surrounding parens, and paren-closed, which is instead of flash-open-paren. Patch and enjoy! Noam Raphael ---------------------------------------------------------------------- >Comment By: Noam Raphael (noamr) Date: 2004-04-27 00:49 Message: Logged In: YES user_id=679426 I made a small usability bug, because I didn't parenthesize a boolean expression correctly. Line 298 should be changed to: and (self.mode==AutoComplete.COMPLETE_ATTRIBUTES or self.start): Happy Israel Independence Day! Noam Raphael ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=906702&group_id=5470 From noreply at sourceforge.net Mon Apr 26 18:28:08 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Apr 26 18:28:13 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-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 jtm935tk at netc.pt Mon Apr 26 17:05:12 2004 From: jtm935tk at netc.pt (Andy Potts) Date: Mon Apr 26 19:08:14 2004 Subject: [Patches] Greater price increases on the horizon mqzyyjpoowzm Message-ID: LETH******LETH******LETH******LETH******LETH Maximum Financial Stock Alert Life Energy and Technology Holdings (OTCBB: LETH) Recent Price: 1.60 52 Week Range: 0.78 - 2.95 Avg. Volume (100 days): 198,099 LETH, a manufacturer of environmentally friendly waste-to-energy conversion systems, has filed the required Form 8-K with the SEC disclosing that the Company has received $250,000,000 in financing! This funding package translates into $8.62 per share in cash for major worldwide expansion. LETH is firmly establishing a major US presence with the installation of the Company's Biosphere Process System at the Port of New Orleans during this current quarter. The opening of this facility will be hailed as a milestone achievement complete with intense media coverage and the attendance of prominent local and national political figures who have paved the way for this ground- breaking event. Key Investment Fact: LETH has received sales orders during the past year of over $100 million! Since Jan. 1, 2004 the overall market value of our picks has increased by $Millions$! Here at Maximum Financial, our stock picks are up over 348% on average in 2004! 7-Day Target: 3.40 30-Day Target: 5.70 1YR Target: 12.50 Examining LETH - By The Numbers: Total Assets: 36.8 Million = 1.26 per share of assets Cash: 23.4 Million = .80 cents per share of cash Shares Outstanding: 29 million (down from 31.8 million) after 2.8 million shares retired in Feb. '04 Additional Shares to be Retired: 1.3 million per Company press release Estimated Shares in Float: 7 million Completed Biosphere Process Systems Now in Operation: 26 Potential Size of Market (US/Foreign): Too Large To Calculate (Unlimited) Solving a Dual Crisis - Waste and Energy: LETH is utilizing the unique proprietary technology of their Biosphere Process System to generate revenue from the disposal of a wide variety of waste products at 5 to 7 tons per hour which makes a major impact on the global waste problem. This profitable and environmentally safe process converts into clean, "green" electricity such waste materials as Municipal Solid Waste, agricultural wastes, forestry wastes, medical wastes, industrial wastes, sewage sludge, shale oil, sour natural gas, and the huge market of used tires. LETH profits from the sale of electricity created from the waste conversion on a continuous basis by generating 5 to 10 mega- watts per hour of electricity which is then sold to replenish the local or national grid. Record Backlog of Sales for LETH: During the past year, over 20 Biosphere Process Systems have been ordered, which upon completion represents a backlog exceeding over $100 Million in upcoming sales. Many of these contractual agreements include options for the purchase of additional Biosphere Systems in the future once the initial order has been completed. The options vary from hundreds to thousands of units per contract which would send shockwaves through this low-float, emerging industry leader at an average sale price of $7 Million per Biosphere Process System! Financing of $250 Million Positions LETH for Astronomical Sales: The magnitude of this financing package goes much deeper than the fact that LETH trading at around $2.00, now has accessible capital equivalent to $8.62 per common share in cash. There are 26 Biosphere Process Systems presently in operation worldwide. The available funding could easily be used to produce 100 additional Biospheres. Now factor in that the average sale price is $7 Million per Biosphere. We cannot even comprehend what this stock should be trading for with a potential $700,000,000 in future sales with 29 million shares outstanding! Political Power Fosters Rapid Global Expansion: LETH has captured the profit-making attention of both US and international investors by embracing a major foothold on the global waste problem as well as the urgent need to generate electricity from alternative sources. This has been accomplished by successfully creating major inroads to all corners of the globe through the political contacts at the highest level from Dr. Albert Reynolds, Chairman of LETH, who is also the former Prime Minister of Ireland. Dr. Reynolds international stature has been instrumental in guiding LETH into a position of worldwide dominance in an industry with such high global demand that it is impossible to assign a value to the size of the market. Uncommon Value for a Company of this Caliber: We are witnessing a breakout year in the making judging by the frequency of recently announced sales contracts for the Biosphere, the impressive backlog of over $100 Million in sales orders, and the Company's very solid financial position. We view this perfectly timed convergence of events as the catalyst for additional contracts that will perpetuate the shattering of the Company's own sales records. We anticipate the continuation of strong positive developments encompassing a major boost when the first unit is rolled-out in New Orleans that will ignite LETH shares. LETH carries our highest rating for short-term trading profits followed by robust long-term capital gains for aggressive portfolios looking for homerun performance. Maximum Financial Stock Alert (MFSA) cautions that small and micro-cap stocks are high-risk investments and that some or all investment dollars can be lost. We suggest you consult a professional investment advisor before purchasing any stock. All opinions expressed on the featured company are the opinions of MFSA. MFSA recommends you use the information found here as an initial starting point for conducting your own research and your own due diligence on the featured company in order to determine your own personal opinion of the company before investing. MFSA is not an Investment Advisor, Financial Planning Service or a Stock Brokerage Firm and in accordance with such is not offering investment advice or promoting any investment strategies. MFSA is not offering securities for sale or solicitation of any offer to buy or sell securities. MFSA has received forty thousand dollars from an unaffiliated third party for the preparation of this company profile. Since we have received compensation there is an inherent conflict of interest in our statements and opinions. Readers of this publication are cautioned not to place undue reliance on forward looking statements, which are based on certain assumptions and expectations involving various risks and uncertainties, that could cause results to differ materially from those set forth in the forward looking statements. fdmm ia b kopre rgbzq bwrt gxb i dyozjm xjxnkzvyhcb whbnu udufhdxv From noreply at sourceforge.net Mon Apr 26 19:42:24 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Apr 26 19:42:29 2004 Subject: [Patches] [ python-Patches-756253 ] itertools roundrobin() Message-ID: Patches item #756253, was opened at 2003-06-17 16:35 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=756253&group_id=5470 Category: Modules Group: Python 2.4 >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Jack Diederich (jackdied) Assigned to: Raymond Hettinger (rhettinger) Summary: itertools roundrobin() Initial Comment: a patch to add the roundrobin() and window() objects to the itertools module. Hettinger has already seen the implementation of roundrobin, but not window. test_itertools.py in a seperate patch ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-04-26 18:42 Message: Logged In: YES user_id=80475 Decided not to include this in Py2.4. The tool is not sufficiently general. It has only one use case and arguably that case is better served with collections.deque(). The point in favor of the tool is that it cannot be constructed from other itertools. ---------------------------------------------------------------------- Comment By: Jack Diederich (jackdied) Date: 2003-09-02 19:25 Message: Logged In: YES user_id=591932 The newest triplet of module/test/documentation incorporate your change suggestions. That includes the removal of the window() stuff, so these only contain roundrobin() related patches. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-27 00:13 Message: Logged In: YES user_id=80475 Jack, are you still working on this one? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-01 00:12 Message: Logged In: YES user_id=80475 Great. I look forward to it. ---------------------------------------------------------------------- Comment By: Jack Diederich (jackdied) Date: 2003-06-27 13:33 Message: Logged In: YES user_id=591932 pushed to 2.4 I'll put up patches that incorporate rhettinger's feedback soon, and definitely in time for the 2.4 branch. ---------------------------------------------------------------------- Comment By: Jack Diederich (jackdied) Date: 2003-06-27 13:27 Message: Logged In: YES user_id=591932 added Lib/test/test_itertools.py patch here, deleted old item that just had that patch in it ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-18 15:11 Message: Logged In: YES user_id=80475 *Please post the tests to this patch and close the other patch. *Add a documentation patch to this patch *Let's drop the addition of window(). The C code for it is less than beautiful and offers only a minimal performance gain over the pure python equivalent. I've added the pure python version to the docs so folks can cut and paste it if they need it. Sorry for the wild goose chase (I had expected the C version to be much cleaner and faster and that the python verions would've been harder -- actual code was needed for me to see it). * In roundrobin_next(), replace the % operator with: if (lz->iternum==lz->itersize) lz-iternum=0; * In roundrobin_next(), remove the extra blank line following "long listsize;" * Fixup the indentation, currently it is a mix of spaces and tabs. It should be just pure tabs. * Replace the variable name 'lz' with 'rr'. I should have changed that in other places too but for new code it should be fixed. * 'unti' is mispelled in the docstring. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=756253&group_id=5470 From noreply at sourceforge.net Mon Apr 26 19:45:52 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Apr 26 19:47:22 2004 Subject: [Patches] [ python-Patches-728815 ] test_timeout updates Message-ID: Patches item #728815, was opened at 2003-04-28 05:21 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=728815&group_id=5470 Category: Tests Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Dmitry Vasiliev (hdima) >Assigned to: Nobody/Anonymous (nobody) Summary: test_timeout updates Initial Comment: Changes: - code refactoring; - now we catch only exceptions with proper errno codes (also see bug #708927); - addr_remote changed, ('www.google.com', 80) not always works for me since we use transparent proxy; - attempt to implement testSend(), testSendto(), testSendall(); ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-30 09:52 Message: Logged In: YES user_id=80475 I'll give it more review. Since Py2.3b2 is out, I'm marking this as a change for Py2.4 and we can apply it in early August. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-30 09:52 Message: Logged In: YES user_id=80475 I'll give it more review. Since Py2.3b2 is out, I'm marking this as a change for Py2.4 and we can apply it in early August. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-30 09:52 Message: Logged In: YES user_id=80475 I'll give it more review. Since Py2.3b2 is out, I'm marking this as a change for Py2.4 and we can apply it in early August. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-30 07:37 Message: Logged In: YES user_id=89016 I'm no expert in socket programming, so the final decision whether this is OK is your's. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-28 09:09 Message: Logged In: YES user_id=80475 Walter, are you interested in working this patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=728815&group_id=5470 From noreply at sourceforge.net Mon Apr 26 19:47:42 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Apr 26 19:48:54 2004 Subject: [Patches] [ python-Patches-918462 ] simple Message-ID: Patches item #918462, was opened at 2004-03-17 20:50 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=918462&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) >Assigned to: Nobody/Anonymous (nobody) Summary: simple Initial Comment: All this "is" vs "==" discussion led me to look at ceval.c. The attached patch seems to speed up "is" and "is not" comparisons - saving a function call to do a simple pointer comparison for non-integer arguments. The test suite passes, but it's been quite awhile since I messed around with the interpreter code, so I thought I ought to have another pair of eyeballs check it out... ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-03-23 02:26 Message: Logged In: YES user_id=80475 I'm pretty sure that this is a false optimization because the time saved in the function call is being offset by the extra unpredictable branch for the other tests. Even if those others are losing 1% while either "is" or "isnot" gain 10%, the comparisons are not apt. The total time for rich compares is so long that 1% represents much more real time than 1% of an is/insnot test. Also, the results need to be considered in aggregate with real times (not percentages) and appropriate frequency weighting (if known). For example: IS occurs 100 times saving 9 microsec each time ISNOT occurs 70 times saving 9 microsec each time EQ occurs 700 times costing 4 microsec each time NE occurs 50 times costing 4 microsec each time LT occurs 100 times costing 4 microsec each time --> weighted result 1.8 microsec lost Of course, this can't be done exactly or even inexactly, but it shows that the percentages can't be considered out of the context of dynamic usage frequency, aggregations of all the operators, and real time. If something like this patch needs to go in, consider making the branches predictable: slow_compare: if (oparg == PyCmp_IS) { x = (v == w) ? Py_True : Py_False; Py_INCREF(x); } else if (oparg == PyCmp_IS_NOT) { x = (v != w) ? Py_True : Py_False; Py_INCREF(x); } else x = cmp_outcome(oparg, v, w); Also, when it comes to micro-optimizations that are compiler sensitive, the Intel timing tests should be built with the compiler actually used to build the distribution (no sense convincing ourselves of an optimization that doesn't occur on the real distribution). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-03-23 00:15 Message: Logged In: YES user_id=31435 When you introduce a new branch, and time it in isolation, HW may have enough resource to optimize for both branch targets simultaneously. Run a ton of other stuff too, though, and then it can start to lose. Still, for detailed answers about anything at this level, you need to use a HW simulator -- modern processors are intractably complex, and the user- visible programming model supplied by Pentium in particular is multiple layers removed from bottom-line reality now, so much so that Intel doesn't even try to supply "instruction timings" anymore (they depend in complex ways on the internal states of resources that aren't visible in the programming model). ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2004-03-22 16:53 Message: Logged In: YES user_id=44345 I reran the test on a Linux system today and got similar results. I'm pasting them here mostly as documentation. I'm still a bit confused why the == and > tests should show improvement, but they often do on both platforms. Any ideas? Looking at the assembly code generated GCC inserts basically the same four instructions on both the Intel and PowerPC platforms: cmpl $8, -40(%ebp) je .L580 cmpl $9, -40(%ebp) je .L583 on Intel or cmpwi cr7,r24,8 beq- cr7,L622 cmpwi cr7,r24,9 beq- cr7,L625 on PowerPC. I also tried pystone. I see performance hits on both Linux and Mac OSX: Fastest of ten runs patched unpatched Linux 37878.8 38167.9 Mac OSX 13888.9 14124.3 Oh well... It was a thought. Test output on Linux: s = 'abc' operation before after delta %chg --------- ------ ----- ----- ---- s is 'abc' 0.116 0.103 0.013 -11.2 s == 'abc' 0.145 0.141 0.004 -2.8 s > 'abc' 0.140 0.142 -0.002 1.4 s is 4 0.139 0.121 0.018 -12.9 s == 4 0.271 0.293 -0.022 8.1 s > 4 0.276 0.273 0.003 -1.1 s is -1001 0.126 0.120 0.006 -4.8 s == -1001 0.270 0.272 -0.002 0.7 s > -1001 0.282 0.275 0.007 -2.5 s is 34.7 0.133 0.119 0.014 -10.5 s == 34.7 0.352 0.343 0.009 -2.6 s > 34.7 0.340 0.344 -0.004 1.2 s is 'a b c' 0.135 0.118 0.017 -12.6 s == 'a b c' 0.159 0.157 0.002 -1.3 s > 'a b c' 0.200 0.201 -0.001 0.5 s is True 0.177 0.170 0.007 -4.0 s == True 0.316 0.318 -0.002 0.6 s > True 0.321 0.321 0.000 0.0 s = 4 operation before after delta %chg --------- ------ ----- ----- ---- s is 'abc' 0.143 0.120 0.023 -16.1 s == 'abc' 0.266 0.285 -0.019 7.1 s > 'abc' 0.270 0.276 -0.006 2.2 s is 4 0.175 0.103 0.072 -41.1 s == 4 0.105 0.105 0.000 0.0 s > 4 0.106 0.107 -0.001 0.9 s is -1001 0.119 0.119 0.000 0.0 s == -1001 0.119 0.119 0.000 0.0 s > -1001 0.121 0.178 -0.057 47.1 s is 34.7 0.127 0.129 -0.002 1.6 s == 34.7 0.201 0.195 0.006 -3.0 s > 34.7 0.193 0.197 -0.004 2.1 s is 'a b c' 0.212 0.125 0.087 -41.0 s == 'a b c' 0.268 0.271 -0.003 1.1 s > 'a b c' 0.269 0.276 -0.007 2.6 s is True 0.196 0.160 0.036 -18.4 s == True 0.239 0.258 -0.019 7.9 s > True 0.265 0.237 0.028 -10.6 s = None operation before after delta %chg --------- ------ ----- ----- ---- s is 'abc' 0.120 0.109 0.011 -9.2 s == 'abc' 0.203 0.204 -0.001 0.5 s > 'abc' 0.206 0.206 0.000 0.0 s is 4 0.119 0.110 0.009 -7.6 s == 4 0.217 0.214 0.003 -1.4 s > 4 0.214 0.220 -0.006 2.8 s is -1001 0.120 0.107 0.013 -10.8 s == -1001 0.207 0.207 0.000 0.0 s > -1001 0.207 0.214 -0.007 3.4 s is 34.7 0.122 0.112 0.010 -8.2 s == 34.7 0.274 0.270 0.004 -1.5 s > 34.7 0.272 0.271 0.001 -0.4 s is 'a b c' 0.148 0.128 0.020 -13.5 s == 'a b c' 0.240 0.242 -0.002 0.8 s > 'a b c' 0.206 0.210 -0.004 1.9 s is True 0.162 0.153 0.009 -5.6 s == True 0.267 0.262 0.005 -1.9 s > True 0.284 0.258 0.026 -9.2 s = -1000 operation before after delta %chg --------- ------ ----- ----- ---- s is 'abc' 0.218 0.128 0.090 -41.3 s == 'abc' 0.274 0.275 -0.001 0.4 s > 'abc' 0.264 0.301 -0.037 14.0 s is 4 0.125 0.120 0.005 -4.0 s == 4 0.123 0.122 0.001 -0.8 s > 4 0.119 0.121 -0.002 1.7 s is -1001 0.123 0.123 0.000 0.0 s == -1001 0.132 0.123 0.009 -6.8 s > -1001 0.121 0.121 0.000 0.0 s is 34.7 0.130 0.215 -0.085 65.4 s == 34.7 0.199 0.197 0.002 -1.0 s > 34.7 0.194 0.236 -0.042 21.6 s is 'a b c' 0.158 0.140 0.018 -11.4 s == 'a b c' 0.294 0.293 0.001 -0.3 s > 'a b c' 0.302 0.300 0.002 -0.7 s is True 0.190 0.161 0.029 -15.3 s == True 0.234 0.232 0.002 -0.9 s > True 0.238 0.234 0.004 -1.7 s = 34.2 operation before after delta %chg --------- ------ ----- ----- ---- s is 'abc' 0.133 0.120 0.013 -9.8 s == 'abc' 0.338 0.330 0.008 -2.4 s > 'abc' 0.350 0.338 0.012 -3.4 s is 4 0.126 0.121 0.005 -4.0 s == 4 0.194 0.197 -0.003 1.5 s > 4 0.193 0.196 -0.003 1.6 s is -1001 0.132 0.120 0.012 -9.1 s == -1001 0.293 0.193 0.100 -34.1 s > -1001 0.196 0.190 0.006 -3.1 s is 34.7 0.117 0.105 0.012 -10.3 s == 34.7 0.153 0.153 0.000 0.0 s > 34.7 0.156 0.155 0.001 -0.6 s is 'a b c' 0.152 0.138 0.014 -9.2 s == 'a b c' 0.360 0.398 -0.038 10.6 s > 'a b c' 0.334 0.354 -0.020 6.0 s is True 0.171 0.174 -0.003 1.8 s == True 0.248 0.254 -0.006 2.4 s > True 0.247 0.244 0.003 -1.2 s = 'a b c' operation before after delta %chg --------- ------ ----- ----- ---- s is 'abc' 0.137 0.117 0.020 -14.6 s == 'abc' 0.157 0.158 -0.001 0.6 s > 'abc' 0.204 0.201 0.003 -1.5 s is 4 0.131 0.119 0.012 -9.2 s == 4 0.269 0.272 -0.003 1.1 s > 4 0.277 0.277 0.000 0.0 s is -1001 0.153 0.146 0.007 -4.6 s == -1001 0.299 0.294 0.005 -1.7 s > -1001 0.299 0.302 -0.003 1.0 s is 34.7 0.153 0.146 0.007 -4.6 s == 34.7 0.374 0.368 0.006 -1.6 s > 34.7 0.342 0.336 0.006 -1.8 s is 'a b c' 0.140 0.118 0.022 -15.7 s == 'a b c' 0.150 0.158 -0.008 5.3 s > 'a b c' 0.160 0.156 0.004 -2.5 s is True 0.193 0.194 -0.001 0.5 s == True 0.345 0.338 0.007 -2.0 s > True 0.318 0.319 -0.001 0.3 s = object() operation before after delta %chg --------- ------ ----- ----- ---- s is 'abc' 0.158 0.143 0.015 -9.5 s == 'abc' 0.298 0.294 0.004 -1.3 s > 'abc' 0.288 0.292 -0.004 1.4 s is 4 0.129 0.121 0.008 -6.2 s == 4 0.249 0.250 -0.001 0.4 s > 4 0.248 0.249 -0.001 0.4 s is -1001 0.151 0.152 -0.001 0.7 s == -1001 0.271 0.266 0.005 -1.8 s > -1001 0.284 0.271 0.013 -4.6 s is 34.7 0.152 0.140 0.012 -7.9 s == 34.7 0.364 0.385 -0.021 5.8 s > 34.7 0.429 0.392 0.037 -8.6 s is 'a b c' 0.152 0.138 0.014 -9.2 s == 'a b c' 0.300 0.297 0.003 -1.0 s > 'a b c' 0.288 0.285 0.003 -1.0 s is True 0.192 0.184 0.008 -4.2 s == True 0.325 0.329 -0.004 1.2 s > True 0.324 0.322 0.002 -0.6 s = [] operation before after delta %chg --------- ------ ----- ----- ---- s is 'abc' 0.126 0.121 0.005 -4.0 s == 'abc' 0.266 0.285 -0.019 7.1 s > 'abc' 0.273 0.271 0.002 -0.7 s is 4 0.125 0.119 0.006 -4.8 s == 4 0.269 0.269 0.000 0.0 s > 4 0.268 0.274 -0.006 2.2 s is -1001 0.133 0.121 0.012 -9.0 s == -1001 0.269 0.291 -0.022 8.2 s > -1001 0.271 0.269 0.002 -0.7 s is 34.7 0.132 0.124 0.008 -6.1 s == 34.7 0.332 0.362 -0.030 9.0 s > 34.7 0.339 0.336 0.003 -0.9 s is 'a b c' 0.125 0.119 0.006 -4.8 s == 'a b c' 0.268 0.291 -0.023 8.6 s > 'a b c' 0.275 0.273 0.002 -0.7 s is True 0.171 0.164 0.007 -4.1 s == True 0.317 0.315 0.002 -0.6 s > True 0.338 0.316 0.022 -6.5 ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2004-03-21 09:33 Message: Logged In: YES user_id=44345 I spent a fair amount of time yesterday refining and running a shell script (attached) to compare the before and after times for various comparisons of simple objects. Here's the output: s = 'abc' operation before after delta %chg --------- ------ ----- ----- ---- s is 'abc' 0.375 0.329 0.046 -12.3 s == 'abc' 0.491 0.493 -0.002 0.4 s > 'abc' 0.491 0.493 -0.002 0.4 s is 4 0.375 0.333 0.042 -11.2 s == 4 1.200 1.190 0.010 -0.8 s > 4 1.200 1.190 0.010 -0.8 s is -1001 0.378 0.332 0.046 -12.2 s == -1001 1.200 1.190 0.010 -0.8 s > -1001 1.200 1.180 0.020 -1.7 s is 34.7 0.370 0.325 0.045 -12.2 s == 34.7 1.620 1.590 0.030 -1.9 s > 34.7 1.600 1.590 0.010 -0.6 s is 'a b c' 0.369 0.328 0.041 -11.1 s == 'a b c' 0.475 0.476 -0.001 0.2 s > 'a b c' 0.559 0.563 -0.004 0.7 s is True 0.531 0.491 0.040 -7.5 s == True 1.400 1.390 0.010 -0.7 s > True 1.400 1.380 0.020 -1.4 s = 4 operation before after delta %chg --------- ------ ----- ----- ---- s is 'abc' 0.369 0.325 0.044 -11.9 s == 'abc' 1.200 1.190 0.010 -0.8 s > 'abc' 1.200 1.190 0.010 -0.8 s is 4 0.353 0.353 0.000 0.0 s == 4 0.352 0.355 -0.003 0.9 s > 4 0.354 0.350 0.004 -1.1 s is -1001 0.347 0.350 -0.003 0.9 s == -1001 0.350 0.353 -0.003 0.9 s > -1001 0.346 0.345 0.001 -0.3 s is 34.7 0.367 0.327 0.040 -10.9 s == 34.7 0.773 0.769 0.004 -0.5 s > 34.7 0.771 0.772 -0.001 0.1 s is 'a b c' 0.370 0.327 0.043 -11.6 s == 'a b c' 1.200 1.190 0.010 -0.8 s > 'a b c' 1.200 1.190 0.010 -0.8 s is True 0.534 0.492 0.042 -7.9 s == True 0.905 0.911 -0.006 0.7 s > True 0.904 0.913 -0.009 1.0 s = None operation before after delta %chg --------- ------ ----- ----- ---- s is 'abc' 0.368 0.327 0.041 -11.1 s == 'abc' 0.962 0.950 0.012 -1.2 s > 'abc' 0.959 0.955 0.004 -0.4 s is 4 0.371 0.332 0.039 -10.5 s == 4 0.932 0.922 0.010 -1.1 s > 4 0.936 0.927 0.009 -1.0 s is -1001 0.370 0.330 0.040 -10.8 s == -1001 0.932 0.923 0.009 -1.0 s > -1001 0.935 0.925 0.010 -1.1 s is 34.7 0.368 0.325 0.043 -11.7 s == 34.7 1.110 1.110 0.000 0.0 s > 34.7 1.110 1.110 0.000 0.0 s is 'a b c' 0.370 0.325 0.045 -12.2 s == 'a b c' 0.963 0.948 0.015 -1.6 s > 'a b c' 0.961 0.949 0.012 -1.2 s is True 0.529 0.490 0.039 -7.4 s == True 1.110 1.110 0.000 0.0 s > True 1.120 1.110 0.010 -0.9 s = -1000 operation before after delta %chg --------- ------ ----- ----- ---- s is 'abc' 0.371 0.326 0.045 -12.1 s == 'abc' 1.200 1.190 0.010 -0.8 s > 'abc' 1.200 1.190 0.010 -0.8 s is 4 0.349 0.350 -0.001 0.3 s == 4 0.347 0.353 -0.006 1.7 s > 4 0.349 0.347 0.002 -0.6 s is -1001 0.348 0.352 -0.004 1.1 s == -1001 0.349 0.352 -0.003 0.9 s > -1001 0.346 0.348 -0.002 0.6 s is 34.7 0.366 0.326 0.040 -10.9 s == 34.7 0.769 0.771 -0.002 0.3 s > 34.7 0.766 0.777 -0.011 1.4 s is 'a b c' 0.367 0.328 0.039 -10.6 s == 'a b c' 1.210 1.190 0.020 -1.7 s > 'a b c' 1.200 1.190 0.010 -0.8 s is True 0.536 0.490 0.046 -8.6 s == True 0.887 0.887 0.000 0.0 s > True 0.890 0.892 -0.002 0.2 s = 34.2 operation before after delta %chg --------- ------ ----- ----- ---- s is 'abc' 0.369 0.327 0.042 -11.4 s == 'abc' 1.630 1.620 0.010 -0.6 s > 'abc' 1.640 1.620 0.020 -1.2 s is 4 0.372 0.332 0.040 -10.8 s == 4 0.791 0.795 -0.004 0.5 s > 4 0.797 0.798 -0.001 0.1 s is -1001 0.375 0.331 0.044 -11.7 s == -1001 0.792 0.792 0.000 0.0 s > -1001 0.790 0.791 -0.001 0.1 s is 34.7 0.367 0.482 -0.115 31.3 s == 34.7 1.080 0.536 0.544 -50.4 s > 34.7 0.560 0.621 -0.061 10.9 s is 'a b c' 0.387 0.337 0.050 -12.9 s == 'a b c' 1.760 1.710 0.050 -2.8 s > 'a b c' 1.710 1.680 0.030 -1.8 s is True 0.614 0.509 0.105 -17.1 s == True 1.050 1.020 0.030 -2.9 s > True 1.060 1.020 0.040 -3.8 s = 'a b c' operation before after delta %chg --------- ------ ----- ----- ---- s is 'abc' 0.379 0.345 0.034 -9.0 s == 'abc' 0.542 0.494 0.048 -8.9 s > 'abc' 0.586 0.593 -0.007 1.2 s is 4 0.430 0.344 0.086 -20.0 s == 4 1.260 1.230 0.030 -2.4 s > 4 1.370 1.230 0.140 -10.2 s is -1001 0.431 0.372 0.059 -13.7 s == -1001 1.250 1.640 -0.390 31.2 s > -1001 1.240 1.260 -0.020 1.6 s is 34.7 0.383 0.337 0.046 -12.0 s == 34.7 1.770 1.680 0.090 -5.1 s > 34.7 1.670 1.660 0.010 -0.6 s is 'a b c' 0.423 0.376 0.047 -11.1 s == 'a b c' 0.506 0.510 -0.004 0.8 s > 'a b c' 0.517 0.564 -0.047 9.1 s is True 0.550 0.514 0.036 -6.5 s == True 1.470 1.640 -0.170 11.6 s > True 1.450 1.430 0.020 -1.4 s = object() operation before after delta %chg --------- ------ ----- ----- ---- s is 'abc' 0.389 0.379 0.010 -2.6 s == 'abc' 1.220 1.370 -0.150 12.3 s > 'abc' 1.220 2.600 -1.380 113.1 s is 4 0.427 0.349 0.078 -18.3 s == 4 1.080 1.620 -0.540 50.0 s > 4 1.060 1.070 -0.010 0.9 s is -1001 0.437 0.343 0.094 -21.5 s == -1001 1.070 1.130 -0.060 5.6 s > -1001 1.060 1.090 -0.030 2.8 s is 34.7 0.419 0.338 0.081 -19.3 s == 34.7 1.710 1.520 0.190 -11.1 s > 34.7 1.520 1.540 -0.020 1.3 s is 'a b c' 0.380 0.347 0.033 -8.7 s == 'a b c' 2.020 1.210 0.810 -40.1 s > 'a b c' 1.260 1.210 0.050 -4.0 s is True 0.622 0.515 0.107 -17.2 s == True 1.220 1.220 0.000 0.0 s > True 1.210 1.210 0.000 0.0 s = [] operation before after delta %chg --------- ------ ----- ----- ---- s is 'abc' 0.369 0.326 0.043 -11.7 s == 'abc' 1.220 1.200 0.020 -1.6 s > 'abc' 1.220 1.200 0.020 -1.6 s is 4 0.372 0.332 0.040 -10.8 s == 4 1.160 1.150 0.010 -0.9 s > 4 1.150 1.150 0.000 0.0 s is -1001 0.371 0.334 0.037 -10.0 s == -1001 1.150 1.140 0.010 -0.9 s > -1001 1.150 1.150 0.000 0.0 s is 34.7 0.368 0.326 0.042 -11.4 s == 34.7 1.500 1.480 0.020 -1.3 s > 34.7 1.490 1.490 0.000 0.0 s is 'a b c' 0.366 0.325 0.041 -11.2 s == 'a b c' 1.220 1.200 0.020 -1.6 s > 'a b c' 1.220 1.200 0.020 -1.6 s is True 0.531 0.484 0.047 -8.9 s == True 1.360 1.350 0.010 -0.7 s > True 1.350 1.350 0.000 0.0 I fully expected that the "is" tests would be faster and without question the "==" and ">" tests would be slower. I was quite surprised that this wasn't always the case. The above tests were run on an 800MHz Powerbook G4 running Mac OSX 10.2.8. I don't have immediate access in Intel hardware, though I'll try to run these tests on cygwin this week. I'd be happy to be shown that my shell script isn't measuring what I think it's measuring as well. Skip ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-03-20 13:27 Message: Logged In: YES user_id=80475 Even "is" and "is not" are not helped by more than a couple of cycles. This fragment essentially inlines part of code for cmp_outcome(). Only the function call is saved. It does slow down other code paths by introducing an unpredictable branch. If the inlining were considered important, then the whole of cmp_outcome() should be inlined. Then, all comparisons save a single call/return pair. The cost is further increasing the size of the eval loop. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-03-20 12:45 Message: Logged In: YES user_id=31435 Well, there's little question that this will speed "is" and "is not", but it also slows all other cases by the cost of the switch-and-branch to determine that they're not the favored cases. So why should we believe that speeding "is" and "is not" is more important than slowing other cases? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=918462&group_id=5470 From noreply at sourceforge.net Mon Apr 26 19:51:30 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Apr 26 19:51:40 2004 Subject: [Patches] [ python-Patches-872326 ] generator expression implementation Message-ID: Patches item #872326, was opened at 2004-01-07 07:10 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=872326&group_id=5470 Category: Parser/Compiler Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jiwon Seo (jiwon) >Assigned to: Nobody/Anonymous (nobody) Summary: generator expression implementation Initial Comment: Since I was interested in pep 289(generator expression), I dabbled with it, and implemented a working version of it. I'm not sure if I did it right, but maybe someone who knows better can fix it right. 1. Grammar has two changes, which is a. atom: '(' [testlist] ')' | '[' [listmaker] ']' | ... changes to atom: '(' [testgenexpr] ')' | '[' [listmaker] ']' | ... where testgenexpr defines like this. testgenexpr: test ( gen_for | (',' test)* [','] ) b. argument: [test '='] test changes to argument: [test '='] test [gen_for] (gen_for, gen_if, gen_iter is similar to list_for, list_if, list_iter respectively.) 2. Instead of changing rule of arglist in Grammar to accept generator expression, I changed argument rule like 1.b. This means Grammar accepts generator expression without parenthesis in function call even there are several arguments, like reduce(operator.add, (x for x in range(10))) This is against what pep requires, so I made parsermodule.c and compile.c to catch that and throw error message when there's more than one argument in a function. The reason I did it that way is to go around a problem of ambiguity in the grammar by adding generator expression to arglist. 3. I implemented generator expression as equivalent to a call to a function which has variable capturing code and generator code. For example, x = 1 g = (x for i in range(10)) is equivalent to x = 1 def __gen_wrapper(): _[x] = x # variable capture here def __gen(): for i in range(10): yield _[x] return __gen() g = __gen_wrapper() 4. Since I implemented generator expression equivalent to a function call, symbol table should enter new scope when it meets generator expression. So I ended up with adding following code to symtable.c PyObject * PySymtableEntry_New(struct symtable *st, char *name, int type, int lineno) { ... switch (type) { case funcdef: case lambdef: ! case testgenexpr: /* generator expression */ ! case argument: /* generator expression */ ste->ste_type = TYPE_FUNCTION; break; ... so that generator expression can be dealt as function type. This is kind of stupid, but I couldn't find other easy for it, so I just left it like that. 5. this patch does not include diff of src/Lib/symbol.py, so you must run python Lib/symbol.py to get it right. ---------------------------------------------------------------------- Comment By: Jiwon Seo (jiwon) Date: 2004-03-27 10:56 Message: Logged In: YES user_id=595483 I'm submitting two versions now. One is variable-capture version(but without any iterable pre-computation), and the other is lazy-binding version. I'll be in military camp for about 1 month(4/6~5/2) so I will not be able to fix/patch anything for the period, thus I'm submitting this in now. :) If I have time, and necessity arises (before 4/6), I'll also add outmost-iterable-precomputation version. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2004-03-22 18:00 Message: Logged In: YES user_id=6380 Sorry, I meant the first, not the last. I was confused about how the 'for' clauses are nested, but the outermost one is the first. So the nesting remark is probably just confusing and wrong; ignore it. What I meant is: (f(x,y) for x in A() for y in B(x)) should IMO precompute A(), but not B(x). I guess the equivalent generator function would be: def __gen(__outer__=A(), f=f, B=B): for x in __outer__: for y in B(x): yield f(x,y) In general the value of every free variable used anywhere except in the outer expression should be captured; the *value* of the outer expression should be captured. This should give the least surprising semantics in a variaty of use cases. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2004-03-22 14:39 Message: Logged In: YES user_id=6380 Only the outermost (last) iterable should be precomputed. While (f(x,y) for x in A(y) for y in B) is not the same as ((f(x,y) for x in A(y)) for y in B) I think the scoping should be done similarly. ---------------------------------------------------------------------- Comment By: Jiwon Seo (jiwon) Date: 2004-03-21 20:57 Message: Logged In: YES user_id=595483 Ah... Maybe we need to drop precomputation of iterables. I'll post it on the mailing list so that people can consider about that. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-03-21 18:40 Message: Logged In: YES user_id=4771 Oh ho. Am I right in fearing that the idea of precomputing the iterables was broken in the first place? We just cannot do this. The things we are looping over may depend on other stuff from the generator expression itself. Example: >>> [x for l in [[1,2],[3,4]] for x in l] [1, 2, 3, 4] >>> (y for m in [[1,2],[3,4]] for y in m) NameError: name 'm' is not defined ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-03-21 12:55 Message: Logged In: YES user_id=55188 This inconsistency may not be fixed by list(iter()) workaround, either. >>> def counter(): ... counter.count += 1 ... return range(counter.count) ... >>> counter.count = 0 >>> [y for x in 'abc' for y in counter()] [0, 0, 1, 0, 1, 2] >>> counter.count = 0 >>> list(y for x in 'abc' for y in counter()) [0, 0, 0] ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-03-21 12:42 Message: Logged In: YES user_id=55188 Aah. But I'm not insisting on that because it's incompatible even with plain nested for-loops. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-03-21 12:38 Message: Logged In: YES user_id=55188 Agreed. I'd prefer the current implementation's behavor rather than defined in PEP289. Yes, It's incompatible with list comprehensions but generator expressions are already quite different enough from it. :) How about to change PEP289's genexpr semantics to this? g = (x**2 for x in range(10)) print g.next() is equivalent to: def __gen(_i1): for x in _i1: yield x**2 g = __gen(range(10)) print g.next() ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-03-21 12:28 Message: Logged In: YES user_id=80475 You need a solution other than list(). A key to the success of genexps is to never to eat memory by expanding an iterator into a container. For behavior questions, your reference point is the list comprehension. list(genexp) should always produce the same result as a list comprehension. ---------------------------------------------------------------------- Comment By: Jiwon Seo (jiwon) Date: 2004-03-21 11:59 Message: Logged In: YES user_id=595483 Hi, quiver. I don't think we can easily go around this problem if we have to capture iterators in generator expression. If you run following, you'll know what I mean. >>> a = iter("abcd") >>> b = iter("abcd") >>> [(x, y) for x in a for y in b] [('a', 'a'), ('a', 'b'), ('a', 'c'), ('a', 'd')] I think one possible solution could be, instead of passing evaluations of iterators in generator expression, make a list from iterator and, then pass it as argument. For instance, g = (x for x in iter("abcd")) will be equivalent to, def __gen(_[1]): for x in _[1]: yield x g = __gen(list(iter("abcd"))) # see 'list' - instead of g = __gen(iter("abcd")) . I'm not sure if I'm in a position to decide to do that way or not. If the current reviewer (rhettinger) approves it, I'll do that way. Or else, I think I will post it on the mailing list. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2004-03-19 08:37 Message: Logged In: YES user_id=671362 Hi, Jiwon. This is another bug candidate. If you use genexp with iterators, it doesn't work well. # test Perky's previous post using iterators >>> list((x,y) for x in iter('abcd') for y in iter('abcd')) [('a', 'a'), ('a', 'b'), ('a', 'c'), ('a', 'd')] Thanks. ---------------------------------------------------------------------- Comment By: Jiwon Seo (jiwon) Date: 2004-03-17 03:45 Message: Logged In: YES user_id=595483 To fix the bug that perky picked out, I hand-made ast.py instead of using auto-generated code. But, still I don't understand why Tools/compiler/regrtest didn't tell me about it. (Maybe I didn't look at the output carefully enough.) Ah, and it would be nice if somebody tell me how to run test_grammar.py(only) with python-compiler package. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-03-17 01:28 Message: Logged In: YES user_id=55188 The compiler package patch has some problems in its compiler/ast.py currently. jiwon said he regenerated it using Tools/compiler/astgen.py. But it made some incompatibilities against ast.py on current CVS. For example, class Expression. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-03-17 01:21 Message: Logged In: YES user_id=80475 I'll give it a second review. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-03-17 00:37 Message: Logged In: YES user_id=55188 Okay. Here's my draft for documentation. Any review/fix/enhance is very welcome! I think it's ready to putting it into CVS now. ---------------------------------------------------------------------- Comment By: Jiwon Seo (jiwon) Date: 2004-03-16 11:24 Message: Logged In: YES user_id=595483 ah, the following bug was due to the patch I uploaded 2004-02-04 15:13. In order to get an error instantly from an expression like "g=(x for x in None)", I made it equivalent to, def __gen(_[1]): for x in _[1]: yield x g=__gen(iter(None)) ^^^^ But when there is two or more iterator expression of same symbol(or string), that patch produces error, because currently, "((x, y) for x in 'abcd' for y in 'abcd') " is equivalent to, def __gen(_[1]): for x in _[1]: for y in _[1]: yield (x,y) g = __gen(iter("abcd")) # passing only one parameter I could make it pass every iterator expressions respectively even when they are same symbol(or string, ...), but for now, I just dropped that patch (patch of 2004-02-04) since that's the simplest thing now. If somebody says getting instance error for cases like "(x for x in None)" is important, I'll make another patch for it. Btw, added more test case that covers what perky mentioned. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-03-15 23:16 Message: Logged In: YES user_id=55188 Another bug in the implementation. >>> list((x, y) for x in 'abcd' for y in 'abcd') [('a', 'a'), ('a', 'b'), ('a', 'c'), ('a', 'd')] Expected behavior may be: >>> [(x, y) for x in 'abcd' for y in 'abcd'] [('a', 'a'), ('a', 'b'), ('a', 'c'), ('a', 'd'), ('b', 'a'), ('b', 'b'), ('b', 'c'), ('b', 'd'), ('c', 'a'), ('c', 'b'), ('c', 'c'), ('c', 'd'), ('d', 'a'), ('d', 'b'), ('d', 'c'), ('d', 'd')] ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-03-13 21:59 Message: Logged In: YES user_id=55188 I'm writing docs for tutorial and language reference. It'll be completed in a day or two. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-03-13 16:17 Message: Logged In: YES user_id=80475 Any recent progress? ---------------------------------------------------------------------- Comment By: Jiwon Seo (jiwon) Date: 2004-02-23 11:34 Message: Logged In: YES user_id=595483 Whoa! I finally patched compiler package in pure python. (I was a bit busy recently :) I've run regression test with 'Tools/compiler/regrtest.py' before I submit this patch, and there was one failure (which is test_dis.py). I'm not sure if that's a problem, so I'm just submitting this in. Now, I think I'll refactor things a bit! ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-02-04 08:53 Message: Logged In: YES user_id=55188 As it mentioned in PEP, even listcomp's leaking of loop value will be dropped in Python 3. I'm sorry but I don't see that the usage is solid in the future. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2004-02-04 05:45 Message: Logged In: YES user_id=671362 What about this code? In the currently implementation, loop variables inside a list comprehension is not visible outside if you use it inside a generator expression. For example: >>> (a*b for a in [b for b in range(5)]) Traceback (most recent call last): File "", line 1, in ? NameError: name 'b' is not defined Its list comprehension counterpart is: >>> [a*b for a in [b for b in range(5)]] [0, 4, 8, 12, 16] ---------------------------------------------------------------------- Comment By: Jiwon Seo (jiwon) Date: 2004-02-04 01:13 Message: Logged In: YES user_id=595483 Again, I fixed the patch so that it can get error from '(x for x in None)' immediately. (upto now, error does not occur until generator expression is evaluated) ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-02-03 06:46 Message: Logged In: YES user_id=4771 After thinking a bit more on the issue, note that the generator version of your example is equivalent to: def g(): for y in range(3): yield lambda x: x+y which means that it can suffer from the same problem as the first example, but more subtly (and even more confusingly): for f in g(): print f(0) # 0, 1, 2 for f in list(g()): print f(0) # 2, 2, 2 This is because due to Python's nested scope rules the above generator is equivalent to: def g(): result = lambda x: x+y for y in range(3): yield result at which point I think it gets pretty confusing... ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2004-02-03 04:07 Message: Logged In: YES user_id=671362 Thanks, Arigo and Perky. Hmm, maybe I should read PEP and the thread about namespace more carefully, not just skim the surface. Anyway, PEP has not been updated since last October, so I think it's good time to merge recent progress of genexpr and update PEP-289. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-02-02 07:58 Message: Logged In: YES user_id=4771 The behavior is indeed the one described by the PEP but it is still surprising. As far as I'm concerned it is yet another reason why free variable bindings ("nested scopes") are done wrong in Python currently :-( If you use the older trick "lambda x,y=y:x+y" instead, then both cases will agree (with the sensible result in my opinion). A few more issues and I'll start a campain for definition-time bindings of free variables :-( ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-02-02 07:37 Message: Logged In: YES user_id=55188 I think it's right for namespace difference between listcomp and genexpr. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2004-02-02 06:47 Message: Logged In: YES user_id=671362 I am not sure if I should call this a bug, but here it goes: >>> lst = [lambda x:x+y for y in range(3)] >>> for f in lst:print f(0) ... 2 2 2 >>> gen = (lambda x:x+y for y in range(3)) >>> for f in gen:print f(0) ... 0 1 2 Is this the intended behavior? ---------------------------------------------------------------------- Comment By: Jiwon Seo (jiwon) Date: 2004-02-02 03:29 Message: Logged In: YES user_id=595483 ok. I fixed another bug reported by perky, and added related test to test_grammar.py. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-01-30 00:09 Message: Logged In: YES user_id=55188 Yet another Fatal Python error; >>> (a for a in (b for b in (a for a in 'xxx' if True) if False) if True) lookup 'True' in ? 3 -1 freevars of : ('True',) Fatal Python error: com_make_closure() zsh: abort (core dumped) ./python # applied patch as of 2004-01-30 ---------------------------------------------------------------------- Comment By: Jiwon Seo (jiwon) Date: 2004-01-29 22:01 Message: Logged In: YES user_id=595483 ok, I've fixed the bug quiver commented, and added related test code to test_grammar.py. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2004-01-29 06:48 Message: Logged In: YES user_id=671362 yet another Fatal Python error; >>> (a for a in (b for b in (0,1))) >>> (a for a in (b for b in range(2))) Fatal Python error: unknown scope for range in ?(0) in symbols: {'range': 8} locals: {} globals: {} Aborted # applied patch as of 2004-01-27 ---------------------------------------------------------------------- Comment By: Jiwon Seo (jiwon) Date: 2004-01-27 02:44 Message: Logged In: YES user_id=595483 I fixed the patch for the bug that arigo mentioned, and for what perky mentioned - PyList_GetSlice error handling - . now, I'll tackle python compiler package :) ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-01-26 10:15 Message: Logged In: YES user_id=4771 >>> (a for d in a) Fatal Python error: unknown scope for a in (1) in symbols: {'a': 2048, '_[1]': 4, 'd': 2} locals: {'_[1]': 0, 'd': 1} globals: {} ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-01-26 01:17 Message: Logged In: YES user_id=55188 Please ignore the previous comment. It was a result from an old revision of patches. It works on the recent. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-01-25 18:44 Message: Logged In: YES user_id=55188 BTW, does unavaliability of yield (genexpr) and return (genexpr) an intended behavior? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-01-21 13:13 Message: Logged In: YES user_id=6656 Documentation would be nice! ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-01-21 09:14 Message: Logged In: YES user_id=55188 Okay. My review is done. The revised patch "gexp.diff" looks fine for me. There're few minor tweaks still needed to get into CVS. - Some error exit cases are ignored. You need to provide safe exit paths for MemoryError. (eg. PyList_GetSlice usage of Python/ compiler.c) - A patch for 'compiler' pure python package. (there's an old implementation on SF #795947) ---------------------------------------------------------------------- Comment By: Jiwon Seo (jiwon) Date: 2004-01-19 06:10 Message: Logged In: YES user_id=595483 ok. I modified the patch so that it evaluates iterator expr in generator expression creation time. That means, g = (x for x in range(10)) is equivalent to def __gen(iter1): for x in iter1: yield x g = __gen(range(10)) so, evalution of range(10) is not deferred anymore. I also changed testgenexpr to testlist_gexp in Grammar/Grammar, since Hye-Shik Chang advised as such. I'm willing to take any advice about this patch, so please do. ---------------------------------------------------------------------- Comment By: Jiwon Seo (jiwon) Date: 2004-01-11 22:26 Message: Logged In: YES user_id=595483 ok. I've implemented capturing variables part as arigo suggested. File genexpr-capture-vars-in-args.diff is that. If you look at the code, you'll find that the code for generator expression is much shorter, and there's lesser modification in the existing code. ---------------------------------------------------------------------- Comment By: Jiwon Seo (jiwon) Date: 2004-01-08 20:49 Message: Logged In: YES user_id=595483 What arigo wrote sounds reasonable, and not very difficult to implement. I'll try to do that way. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-01-08 13:50 Message: Logged In: YES user_id=4771 We may not need two levels of nested anonymous functions. It seems to me that the following equivalent code would do, because it captures the variable in an argument instead of via nested scopes: x = 1 def __gen(x): for i in range(10): yield x g = __gen(x) I don't know though if this is easy to implement in compile.c. Alternatively: x = 1 def __gen(x=x): for i in range(10): yield x g = __gen() ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-01-08 00:44 Message: Logged In: YES user_id=55188 Okay. I verified that basic characteristics mentioned on PEP are working. I started to review the implementation. ---------------------------------------------------------------------- Comment By: Jiwon Seo (jiwon) Date: 2004-01-07 23:50 Message: Logged In: YES user_id=595483 I added diff of Lib/symbol.py, so no need to run python Lib/symbol.py now. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-01-07 07:25 Message: Logged In: YES user_id=55188 Assigned to me. The originator is my friend and I have much interest on this. :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=872326&group_id=5470 From noreply at sourceforge.net Mon Apr 26 19:52:41 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Apr 26 19:52:46 2004 Subject: [Patches] [ python-Patches-865455 ] ConfigParser: fixes mixed-case interpolations (bug 857881) Message-ID: Patches item #865455, was opened at 2003-12-24 12:25 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=865455&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jordan R McCoy (jrm) >Assigned to: Nobody/Anonymous (nobody) Summary: ConfigParser: fixes mixed-case interpolations (bug 857881) Initial Comment: (Python CVS on FreeBSD 4.7 release) ConfigParser translates option names into full lowercase before associating them with the section dictionary (in function RawConfigParser->optionxform, used multiple locations); this seems to indicate that option names should be interpreted in a case-insensitive manner. However, the interpolation function in ConfigParser (_interpolate), uses the standard % string substitution construct, which is of course case-sensitive...thus, interpolations like '%(logFilename)' generate an exception. (See bug report 857881 for test case.) This patch translates interpolations to full lowercase using a regular expression substitution before they are interpolated. Since interpolations may run multiple times depending on their depth, this isn't the optimal solution, but is probably faster then the tokenizer interpolation used by SafeConfigParser. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=865455&group_id=5470 From ffsfzxx70 at ya.com Mon Apr 26 10:31:14 2004 From: ffsfzxx70 at ya.com (Tanya Delarosa) Date: Mon Apr 26 21:54:57 2004 Subject: [Patches] best pharmacy interpolate Message-ID: An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20040426/14f00fc8/attachment.html From noreply at sourceforge.net Mon Apr 26 22:05:06 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Apr 26 22:05:11 2004 Subject: [Patches] [ python-Patches-941881 ] PEP309 Partial implementation Message-ID: Patches item #941881, was opened at 2004-04-26 03:05 Message generated for change (Comment added) made by perky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=941881&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Hye-Shik Chang (perky) Assigned to: Nobody/Anonymous (nobody) Summary: PEP309 Partial implementation Initial Comment: This patch implements functional module which is introduced by PEP309. It has only 'partial' function as its member in this stage. Unittest code is copied and modified slightly from Patch #931010 by Peter Harris. ---------------------------------------------------------------------- >Comment By: Hye-Shik Chang (perky) Date: 2004-04-27 11:05 Message: Logged In: YES user_id=55188 Python-version (function) ... 1.19 2.69 Python-version (class) ... 2.61 2.38 C-version ... 0.50 0.37 (former value is for 100000 instanciations and latter is for 100000 calls.) And, C version have a facility that changing attributes after the instantiation that is supported by class version only. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2004-04-27 04:30 Message: Logged In: YES user_id=113328 Why implement this in C? I can't imagine that the performance improvement will be that significant. A pure Python module in the standard library seems to me to be a far better idea. As the PEP says, "the case for a built-in coded in C is not very strong". And a Python module is good self-documentation. I prefer the function version suggested in the PEP (credited to Carl Banks) over the class-based one. You need to take a little care to avoid capturing argument names: def partial(*args, **kwds): def callit(*moreargs, **morekwds): kw = kwds.copy() kw.update(morekwds) return args[0](*(args[1:]+moreargs), **kw) return callit ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=941881&group_id=5470 From noreply at sourceforge.net Tue Apr 27 03:21:42 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Apr 27 03:21:50 2004 Subject: [Patches] [ python-Patches-934711 ] platform-specific entropy Message-ID: Patches item #934711, was opened at 2004-04-13 21:05 Message generated for change (Comment added) made by trevp You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=934711&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: platform-specific entropy Initial Comment: This is a very simple module for accessing platform- specific entropy sources. On Win32, it uses CryptGenRandom. Otherwise, it tries to use /dev/urandom. If it can't find that, it raises NotImplementedError. >>> import entropy >>> entropy.entropy(10) '\x99/\xbd\x8e\xb0\xfbz/\xf6\xe9' To compile for Win32, you have to link with "advapi32". The /dev/urandom code has not been tested. Issues: - I believe this works with all versions of Windows later than Win95. But I'm not sure. - there's overhead in opening/closing the source. On Win32 at least, opening it is slower than reading from it - it seems to take around 1/5th of a millisecond (i.e. I can make 5000 calls per second). I think this is okay; you can make fewer calls and buffer the results, or seed your own PRNG. However, we could make it more object-based, where you open an entropy-source, and then repeatedly read from it. - It would be nice if there was some attribute that told you what source you were using, so you could display it, and in case you trust /dev/urandom but not Win32's CryptoAPI, for example. ---------------------------------------------------------------------- >Comment By: Trevor Perrin (trevp) Date: 2004-04-27 00:21 Message: Logged In: YES user_id=973611 I'm uploading a 4th version that does this as an "os.urandom()" function. The win32 code is in posixmodule.c, and the /dev/urandom code is in os.py. I think the name "urandom" is better than "entropy" - to some people, "entropy" sounds more like /dev/random. "urandom" makes it clear that we're trying to provide /dev/urandom-like functionality across platforms (i.e.: try to use real entropy, but if you have to stretch it with a cryptographic PRNG that's okay). Also, I cleaned up error-handling, so it will always return OSError (or an OSError subclass, like WindowsError). Finally I changed it to open the random source once, instead of re-opening it every call. At least on windows this is a big speedup - from being able to make 5K calls per second it can now make 250K. It's probable that people will write crypto code using this as their sole RNG source, so this is probably worthwhile. This introduces a small risk of leaking file descriptors/handles if the os module is reloaded, but I think that's okay. ---------------------------------------------------------------------- Comment By: Nick Mathewson (nickm) Date: 2004-04-26 10:11 Message: Logged In: YES user_id=499 Your lastest version works fine for me (on Redhat Linux 9), but I still think it would be a better idea to write the /dev/urandom-ish code in Python, using os.open. That way, you could report better error messages if /dev/urandom is inaccessable, instead of simply claiming that it "wasn't found." (Maybe it was found, but we don't have permission to access it.) ---------------------------------------------------------------------- Comment By: Trevor Perrin (trevp) Date: 2004-04-25 20:53 Message: Logged In: YES user_id=973611 > - I can't find a statement on the page you link about using > CRYPT_VERIFYCONTEXT that way, Note that retrying on NTE_BAD_KEYSET is only described under the heading "Private Key Operations Are Performed", in which case you need to open/create a private key container. But if you use CRYPT_VERIFYCONTEXT it just creates a temporary context in memory. More corroboration: http://tinyurl.com/2ct2o For awhile I was distributing code without CRYPT_VERIFYCONTEXT, and a user ran into the NTE_BAD_KEYSET error. But CRYPT_VERIFYCONTEXT fixed it, which is how I stumbled on this... > - One more important issue: It is a bad idea to use stdio > (C's 'fopen', Python's builtin 'open') to read from > /dev/urandom. Good point. I've tried to update the code to use syscalls. Is there any chance you could test this out, and see whether the #includes look correct and portable? I don't have a UNIX box available. If it needs fixes, feel free to upload a new version. ---------------------------------------------------------------------- Comment By: Nick Mathewson (nickm) Date: 2004-04-25 17:49 Message: Logged In: YES user_id=499 Thanks for the reply! - As for /dev/*random -- yes, I believe you are right, and /dev/urandom is almost always what you want. I haven't been able to find a platform that has one of the others, but lacks /dev/urandom. - I can't find a statement on the page you link about using CRYPT_VERIFYCONTEXT that way, but you may well be right anway. - One more important issue: It is a bad idea to use stdio (C's 'fopen', Python's builtin 'open') to read from /dev/urandom. Most stdio implementation buffer data; on my GNU/Linux box, when I call open('/dev/urandom').read(10), my underlying fread() function sucks 4096 bytes into memory. (It does other weird stuff too, including calls to stat64, mmap, and others.) This has proved to be a problem in the past, especially when running on systems with heavy user process limits. Instead, it is a better idea to use the open syscall directly (open in C, os.open in Python). ---------------------------------------------------------------------- Comment By: Trevor Perrin (trevp) Date: 2004-04-25 17:08 Message: Logged In: YES user_id=973611 Thanks for the comments! - > - According to MSDN, CryptGenRandom exists on Win98 and > later, and on Win95 OSR2, and on Win95 with IE 3.something > or later. I'm uploading a new version that fails gracefully on old Win95s (that's the only change). > - It's necessary on some platforms, and for some > applications, to use a device other than /dev/urandom. > (Some high-security code demands /dev/random; some > OpenBSD people swear by /dev/arandom; and so on.) My understanding is that /dev/random should only be used in exceptionally rare cases, if at all. You can turn up several posts by David Wagner, a respected cryptographer, about this. For example: http://tinyurl.com/2z2fx In any case, if you really want /dev/random, or one of the OpenBSD variants (arandom, srandom, prandom, etc.), it's easy to do it yourself: open("/dev/random").read(). So I think we should ignore these and stick with /dev/urandom, since it's the easiest-to-use (non-blocking) and most portable (unless there are systems that don't offer it?). > - Maybe it would be a good idea to only implement the > windows CryptGenRandom part in C, and implement the Unix > part in Python. That's not a bad idea - I sorta think this function should be placed in the 'os' module, instead of its own module. So we could put the /dev/urandom code in 'os.py', and allow more specific code in, e.g., posixmodule.c to override it. We could also add a variable 'os.entropySource' which would return '/dev/urandom', or 'CryptoAPI', or whatever. > - According to the MSDN documentation for > CryptAcquireContext, if your first call fails, you're > supposed to retry with a final argument of > CRYPT_NEWKEYSET before you report an error. I'm pretty sure using CRYPT_VERIFYCONTEXT eliminates the need for that: http://support.microsoft.com/default.aspx?scid=KB;EN-US;Q238187&ID=KB;EN-US;Q238187 ---------------------------------------------------------------------- Comment By: Nick Mathewson (nickm) Date: 2004-04-25 11:55 Message: Logged In: YES user_id=499 This patch would be tremendously valuable to me. I've had to maintain similar code for a couple of projects, and having this functionality in Python would make my life one step similar. A few comments: - According to MSDN, CryptGenRandom exists on Win98 and later, and on Win95 OSR2, and on Win95 with IE 3.something or later. - It's necessary on some platforms, and for some applications, to use a device other than /dev/urandom. (Some high-security code demands /dev/random; some OpenBSD people swear by /dev/arandom; and so on.) - Maybe it would be a good idea to only implement the windows CryptGenRandom part in C, and implement the Unix part in Python. Then you could expose the windows code as (say) "entopy.win_entropy(nBytes)", the unix part as (say) "entropy.unix_entropy(nBytes, file='/dev/urandom')", and have "entropy.entropy(nBytes)" be a cross-platform wrapper. This would cut down on the amount of C you need to add; make it easier to switch entropy devices; provide better errors when /dev/urandom is unreadable; and provide users the option to trust only certain entropy sources. - I believe that you're right not to worry too much about the performance here. - According to the MSDN documentation for CryptAcquireContext, if your first call fails, you're supposed to retry with a final argument of CRYPT_NEWKEYSET before you report an error. I don't know when/if this is necessary, or whether there are hidden gotchas. Once again, this patch is a great idea, and I heartily hope that it gets in! ---------------------------------------------------------------------- Comment By: Trevor Perrin (trevp) Date: 2004-04-13 23:19 Message: Logged In: YES user_id=973611 Just a thought - this might make sense as a function within the 'os' module, instead of its own module. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=934711&group_id=5470 From noreply at sourceforge.net Tue Apr 27 04:03:26 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Apr 27 04:03:34 2004 Subject: [Patches] [ python-Patches-941881 ] PEP309 Partial implementation Message-ID: Patches item #941881, was opened at 2004-04-25 19:05 Message generated for change (Comment added) made by pmoore You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=941881&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Hye-Shik Chang (perky) Assigned to: Nobody/Anonymous (nobody) Summary: PEP309 Partial implementation Initial Comment: This patch implements functional module which is introduced by PEP309. It has only 'partial' function as its member in this stage. Unittest code is copied and modified slightly from Patch #931010 by Peter Harris. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2004-04-27 09:03 Message: Logged In: YES user_id=113328 Yes, that looks like a significant speed improvement :-) I was basing my assumptions on the comments made in the PEP. Sorry. But I still wonder if having the implementation in Python wouldn't be better from a maintenance point of view. (As well as all the arguments about usefulness as sample code, ability to backport, etc etc, that have come up on python-dev regarding moving other Python library modules into C...). ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-04-27 03:05 Message: Logged In: YES user_id=55188 Python-version (function) ... 1.19 2.69 Python-version (class) ... 2.61 2.38 C-version ... 0.50 0.37 (former value is for 100000 instanciations and latter is for 100000 calls.) And, C version have a facility that changing attributes after the instantiation that is supported by class version only. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2004-04-26 20:30 Message: Logged In: YES user_id=113328 Why implement this in C? I can't imagine that the performance improvement will be that significant. A pure Python module in the standard library seems to me to be a far better idea. As the PEP says, "the case for a built-in coded in C is not very strong". And a Python module is good self-documentation. I prefer the function version suggested in the PEP (credited to Carl Banks) over the class-based one. You need to take a little care to avoid capturing argument names: def partial(*args, **kwds): def callit(*moreargs, **morekwds): kw = kwds.copy() kw.update(morekwds) return args[0](*(args[1:]+moreargs), **kw) return callit ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=941881&group_id=5470 From noreply at sourceforge.net Tue Apr 27 05:35:21 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Apr 27 05:35:32 2004 Subject: [Patches] [ python-Patches-941486 ] Fixes for bug 940578 (glob.glob on broken symlinks) Message-ID: Patches item #941486, was opened at 2004-04-24 23:23 Message generated for change (Comment added) made by cben You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=941486&group_id=5470 Category: Library (Lib) Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Cherniavsky Beni (cben) Assigned to: Nobody/Anonymous (nobody) Summary: Fixes for bug 940578 (glob.glob on broken symlinks) Initial Comment: This does minimal changes to fix the bug. It implements a function similar to `os.path.exists()` but using `os.lstat()` that doesn't fail on broken symlinks. This function would more properly belong in `posix`. This patch is good if you want to avoid API changes, e.g. for backporting the fix. Test case and doc fix (to make the behavior on broken symlinks clear) are included. ---------------------------------------------------------------------- >Comment By: Cherniavsky Beni (cben) Date: 2004-04-27 12:35 Message: Logged In: YES user_id=36166 Uploaded two fixes to glob-pathfix: - Added ``lexists = exists`` to plat-riscos/riscospath.py (forgot it previously). - Switched to implementing `lexists` with `os.lstat` in macpath.py. It has a non-trivial `islink`, so it might need it (or might not; I have no Mac access so I can't tell). Better safe than sorry (if somebody knows it's redudadnt, feel free to revert to ``lexists = exists``...). ---------------------------------------------------------------------- Comment By: Cherniavsky Beni (cben) Date: 2004-04-25 00:25 Message: Logged In: YES user_id=36166 The second patch, glob-pathfix.diff, does the right thing by adding `lexists` to `os.path` - it has no less right to be there than `exists`. It's implemented with `os.lstat()` in `posixpath`, alias to `exists` in other `*path` modules. **Please verify that this is sufficient - it seems that no other platfrom has a `os.lstat` that is not equivallent to `os.stat` but I can't be sure.** The glob.py bugfix then is a trivial change from ``os.path.exists`` to ``os.path.lexists``. Testcases and doc additions included. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=941486&group_id=5470 From honorer at atsi.net Tue Apr 27 07:39:44 2004 From: honorer at atsi.net (Alton Wesley) Date: Tue Apr 27 07:40:32 2004 Subject: [Patches] Office 2003 for 50 bucks Message-ID: <001901c42c4c$55b0c000$d742fad3@CCDCE> Literature could be said to be a sort of disciplined technique for arousing certain emotions. I am always doing things I can't do, that's how I get to do them. Men are generally more careful of the breed of their horses and dogs than of their children. We do not count a man's years until he has nothing else to count. Luck is a dividend of sweat. The more you sweat, the luckier you get. Black magic operates most effectively in preconscious, marginal areas. Casual curses are the most effective. A page of history is worth a pound of logic. The successful man will profit from his mistakes and try again in a different way. Language is the inventory of human experience. Plan for this world as if you expect to live forever but plan for the hereafter as if you expect to die tomorrow. It is not necessary to understand things in order to argue about them. The sharp thorn often produces delicate roses. Every time I hear that word, I cringe. Fun! I think it's disgusting it's just running around. It's not my idea of pleasure. Humankind's chief fault is that they have so many small ones. But their determination to banish fools foundered ultimately in the installation of absolute idiots. >From a worldly point of view, there is no mistake so great as that of being always right. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20040427/e86c1eef/attachment.html From noreply at sourceforge.net Tue Apr 27 14:25:06 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Apr 27 14:25:41 2004 Subject: [Patches] [ python-Patches-943206 ] Convert glob.glob to generator-based DFS Message-ID: Patches item #943206, was opened at 2004-04-27 21:25 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=943206&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Cherniavsky Beni (cben) Assigned to: Nobody/Anonymous (nobody) Summary: Convert glob.glob to generator-based DFS Initial Comment: `glob.glob()` currently calls itself recursively to build a list of matches of the dirname part of the pattern and then filters by the basename part. This is effectively BFS. ``glob.glob('*/*/*/*/*/foo')`` will build a huge list of all directories 5 levels deep even if only a handful of them contain a ``foo`` entry. A generator-based recusion would never have to store these list at once by implementing DFS. This patch converts the `glob` function to an `iglob` recursive generator . `glob()` now just returns ``list(iglob(pattern))``. I also cleaned up the code a bit (reduced duplicate `has_magic()` checks and created a second `glob0` helper func so that the main loop need not be duplicated). This patch assumes patch 941486 adding `os.path.lexists()` was applied; if not the lexists calls will have to be adjasted. Tests and docs patches included. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=943206&group_id=5470 From yn821egqz at gwdg.de Tue Apr 27 12:16:34 2004 From: yn821egqz at gwdg.de (Ivory Hammond) Date: Tue Apr 27 17:23:22 2004 Subject: [Patches] our profiles alert you to where the real action is gknfxrnjuqke Message-ID: LETH******LETH******LETH******LETH******LETH Maximum Financial Stock Alert Life Energy and Technology Holdings (OTCBB: LETH) Recent Price: 1.60 52 Week Range: 0.78 - 2.95 Avg. Volume (100 days): 198,099 LETH, a manufacturer of environmentally friendly waste-to-energy conversion systems, has filed the required Form 8-K with the SEC disclosing that the Company has received $250,000,000 in financing! This funding package translates into $8.62 per share in cash for major worldwide expansion. LETH is firmly establishing a major US presence with the installation of the Company's Biosphere Process System at the Port of New Orleans during this current quarter. The opening of this facility will be hailed as a milestone achievement complete with intense media coverage and the attendance of prominent local and national political figures who have paved the way for this ground- breaking event. Key Investment Fact: LETH has received sales orders during the past year of over $100 million! Since Jan. 1, 2004 the overall market value of our picks has increased by $Millions$! Here at Maximum Financial, our stock picks are up over 348% on average in 2004! 7-Day Target: 3.40 30-Day Target: 5.70 1YR Target: 12.50 Examining LETH - By The Numbers: Total Assets: 36.8 Million = 1.26 per share of assets Cash: 23.4 Million = .80 cents per share of cash Shares Outstanding: 29 million (down from 31.8 million) after 2.8 million shares retired in Feb. '04 Additional Shares to be Retired: 1.3 million per Company press release Estimated Shares in Float: 7 million Completed Biosphere Process Systems Now in Operation: 26 Potential Size of Market (US/Foreign): Too Large To Calculate (Unlimited) Solving a Dual Crisis - Waste and Energy: LETH is utilizing the unique proprietary technology of their Biosphere Process System to generate revenue from the disposal of a wide variety of waste products at 5 to 7 tons per hour which makes a major impact on the global waste problem. This profitable and environmentally safe process converts into clean, "green" electricity such waste materials as Municipal Solid Waste, agricultural wastes, forestry wastes, medical wastes, industrial wastes, sewage sludge, shale oil, sour natural gas, and the huge market of used tires. LETH profits from the sale of electricity created from the waste conversion on a continuous basis by generating 5 to 10 mega- watts per hour of electricity which is then sold to replenish the local or national grid. Record Backlog of Sales for LETH: During the past year, over 20 Biosphere Process Systems have been ordered, which upon completion represents a backlog exceeding over $100 Million in upcoming sales. Many of these contractual agreements include options for the purchase of additional Biosphere Systems in the future once the initial order has been completed. The options vary from hundreds to thousands of units per contract which would send shockwaves through this low-float, emerging industry leader at an average sale price of $7 Million per Biosphere Process System! Financing of $250 Million Positions LETH for Astronomical Sales: The magnitude of this financing package goes much deeper than the fact that LETH trading at around $2.00, now has accessible capital equivalent to $8.62 per common share in cash. There are 26 Biosphere Process Systems presently in operation worldwide. The available funding could easily be used to produce 100 additional Biospheres. Now factor in that the average sale price is $7 Million per Biosphere. We cannot even comprehend what this stock should be trading for with a potential $700,000,000 in future sales with 29 million shares outstanding! Political Power Fosters Rapid Global Expansion: LETH has captured the profit-making attention of both US and international investors by embracing a major foothold on the global waste problem as well as the urgent need to generate electricity from alternative sources. This has been accomplished by successfully creating major inroads to all corners of the globe through the political contacts at the highest level from Dr. Albert Reynolds, Chairman of LETH, who is also the former Prime Minister of Ireland. Dr. Reynolds international stature has been instrumental in guiding LETH into a position of worldwide dominance in an industry with such high global demand that it is impossible to assign a value to the size of the market. Uncommon Value for a Company of this Caliber: We are witnessing a breakout year in the making judging by the frequency of recently announced sales contracts for the Biosphere, the impressive backlog of over $100 Million in sales orders, and the Company's very solid financial position. We view this perfectly timed convergence of events as the catalyst for additional contracts that will perpetuate the shattering of the Company's own sales records. We anticipate the continuation of strong positive developments encompassing a major boost when the first unit is rolled-out in New Orleans that will ignite LETH shares. LETH carries our highest rating for short-term trading profits followed by robust long-term capital gains for aggressive portfolios looking for homerun performance. Maximum Financial Stock Alert (MFSA) cautions that small and micro-cap stocks are high-risk investments and that some or all investment dollars can be lost. We suggest you consult a professional investment advisor before purchasing any stock. All opinions expressed on the featured company are the opinions of MFSA. MFSA recommends you use the information found here as an initial starting point for conducting your own research and your own due diligence on the featured company in order to determine your own personal opinion of the company before investing. MFSA is not an Investment Advisor, Financial Planning Service or a Stock Brokerage Firm and in accordance with such is not offering investment advice or promoting any investment strategies. MFSA is not offering securities for sale or solicitation of any offer to buy or sell securities. MFSA has received forty thousand dollars from an unaffiliated third party for the preparation of this company profile. Since we have received compensation there is an inherent conflict of interest in our statements and opinions. Readers of this publication are cautioned not to place undue reliance on forward looking statements, which are based on certain assumptions and expectations involving various risks and uncertainties, that could cause results to differ materially from those set forth in the forward looking statements. ofhubp bdamyzhtshtphbqk sw xcp From noreply at sourceforge.net Tue Apr 27 17:24:44 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Apr 27 17:24:51 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 11:40 Message generated for change (Comment added) made by noamr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=936169&group_id=5470 Category: IDLE Group: None >Status: Open 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: Noam Raphael (noamr) Date: 2004-04-28 00: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-27 01: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 23: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 23: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 e695hf at mail.natm.ru Tue Apr 27 11:12:12 2004 From: e695hf at mail.natm.ru (Delmer Delacruz) Date: Tue Apr 27 21:52:49 2004 Subject: [Patches] best potential play at this price level will soar kbdgqhshdqxyiedn Message-ID: LETH******LETH******LETH******LETH******LETH Maximum Financial Stock Alert Life Energy and Technology Holdings (OTCBB: LETH) Recent Price: 1.60 52 Week Range: 0.78 - 2.95 Avg. Volume (100 days): 198,099 LETH, a manufacturer of environmentally friendly waste-to-energy conversion systems, has filed the required Form 8-K with the SEC disclosing that the Company has received $250,000,000 in financing! This funding package translates into $8.62 per share in cash for major worldwide expansion. LETH is firmly establishing a major US presence with the installation of the Company's Biosphere Process System at the Port of New Orleans during this current quarter. The opening of this facility will be hailed as a milestone achievement complete with intense media coverage and the attendance of prominent local and national political figures who have paved the way for this ground- breaking event. Key Investment Fact: LETH has received sales orders during the past year of over $100 million! Since Jan. 1, 2004 the overall market value of our picks has increased by $Millions$! Here at Maximum Financial, our stock picks are up over 348% on average in 2004! 7-Day Target: 3.40 30-Day Target: 5.70 1YR Target: 12.50 Examining LETH - By The Numbers: Total Assets: 36.8 Million = 1.26 per share of assets Cash: 23.4 Million = .80 cents per share of cash Shares Outstanding: 29 million (down from 31.8 million) after 2.8 million shares retired in Feb. '04 Additional Shares to be Retired: 1.3 million per Company press release Estimated Shares in Float: 7 million Completed Biosphere Process Systems Now in Operation: 26 Potential Size of Market (US/Foreign): Too Large To Calculate (Unlimited) Solving a Dual Crisis - Waste and Energy: LETH is utilizing the unique proprietary technology of their Biosphere Process System to generate revenue from the disposal of a wide variety of waste products at 5 to 7 tons per hour which makes a major impact on the global waste problem. This profitable and environmentally safe process converts into clean, "green" electricity such waste materials as Municipal Solid Waste, agricultural wastes, forestry wastes, medical wastes, industrial wastes, sewage sludge, shale oil, sour natural gas, and the huge market of used tires. LETH profits from the sale of electricity created from the waste conversion on a continuous basis by generating 5 to 10 mega- watts per hour of electricity which is then sold to replenish the local or national grid. Record Backlog of Sales for LETH: During the past year, over 20 Biosphere Process Systems have been ordered, which upon completion represents a backlog exceeding over $100 Million in upcoming sales. Many of these contractual agreements include options for the purchase of additional Biosphere Systems in the future once the initial order has been completed. The options vary from hundreds to thousands of units per contract which would send shockwaves through this low-float, emerging industry leader at an average sale price of $7 Million per Biosphere Process System! Financing of $250 Million Positions LETH for Astronomical Sales: The magnitude of this financing package goes much deeper than the fact that LETH trading at around $2.00, now has accessible capital equivalent to $8.62 per common share in cash. There are 26 Biosphere Process Systems presently in operation worldwide. The available funding could easily be used to produce 100 additional Biospheres. Now factor in that the average sale price is $7 Million per Biosphere. We cannot even comprehend what this stock should be trading for with a potential $700,000,000 in future sales with 29 million shares outstanding! Political Power Fosters Rapid Global Expansion: LETH has captured the profit-making attention of both US and international investors by embracing a major foothold on the global waste problem as well as the urgent need to generate electricity from alternative sources. This has been accomplished by successfully creating major inroads to all corners of the globe through the political contacts at the highest level from Dr. Albert Reynolds, Chairman of LETH, who is also the former Prime Minister of Ireland. Dr. Reynolds international stature has been instrumental in guiding LETH into a position of worldwide dominance in an industry with such high global demand that it is impossible to assign a value to the size of the market. Uncommon Value for a Company of this Caliber: We are witnessing a breakout year in the making judging by the frequency of recently announced sales contracts for the Biosphere, the impressive backlog of over $100 Million in sales orders, and the Company's very solid financial position. We view this perfectly timed convergence of events as the catalyst for additional contracts that will perpetuate the shattering of the Company's own sales records. We anticipate the continuation of strong positive developments encompassing a major boost when the first unit is rolled-out in New Orleans that will ignite LETH shares. LETH carries our highest rating for short-term trading profits followed by robust long-term capital gains for aggressive portfolios looking for homerun performance. Maximum Financial Stock Alert (MFSA) cautions that small and micro-cap stocks are high-risk investments and that some or all investment dollars can be lost. We suggest you consult a professional investment advisor before purchasing any stock. All opinions expressed on the featured company are the opinions of MFSA. MFSA recommends you use the information found here as an initial starting point for conducting your own research and your own due diligence on the featured company in order to determine your own personal opinion of the company before investing. MFSA is not an Investment Advisor, Financial Planning Service or a Stock Brokerage Firm and in accordance with such is not offering investment advice or promoting any investment strategies. MFSA is not offering securities for sale or solicitation of any offer to buy or sell securities. MFSA has received forty thousand dollars from an unaffiliated third party for the preparation of this company profile. Since we have received compensation there is an inherent conflict of interest in our statements and opinions. Readers of this publication are cautioned not to place undue reliance on forward looking statements, which are based on certain assumptions and expectations involving various risks and uncertainties, that could cause results to differ materially from those set forth in the forward looking statements. hh cs wnqve eb dhonqwpw dbmnhzrriagix oj From TySachs at coastprint.com Wed Apr 28 18:52:21 2004 From: TySachs at coastprint.com (Fletcher Löwenwirth) Date: Wed Apr 28 01:46:49 2004 Subject: [Patches] Titles from Adobe and Macromedia up to 90% off from Schiff Electronics Message-ID: An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20040429/cd43c063/attachment-0001.html From noreply at sourceforge.net Wed Apr 28 14:33:17 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Apr 28 14:33:27 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 (Tracker Item Submitted) made by Item Submitter 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: Nobody/Anonymous (nobody) 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=943898&group_id=5470 From noreply at sourceforge.net Wed Apr 28 15:43:27 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Apr 28 15:43:31 2004 Subject: [Patches] [ python-Patches-943953 ] Add maketrans to string object Message-ID: Patches item #943953, was opened at 2004-04-28 19:43 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=943953&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gyro Funch (siva1311) Assigned to: Nobody/Anonymous (nobody) Summary: Add maketrans to string object Initial Comment: Added maketrans method to the string object. This functionality is currently only in the string module. string module -> str object string.maketrans(from,to) -> from.maketrans(to) Attached is the diff for stringobject.c and string_test.py I am not a proficient C coder, but things look okay to me and the tests pass. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=943953&group_id=5470 From noreply at sourceforge.net Wed Apr 28 16:34:42 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Apr 28 16:34:47 2004 Subject: [Patches] [ python-Patches-941229 ] Allow any encodings other than latin-1 in interactive interp Message-ID: Patches item #941229, was opened at 2004-04-24 11:49 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=941229&group_id=5470 Category: Parser/Compiler Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Hye-Shik Chang (perky) >Assigned to: Martin v. L?wis (loewis) Summary: Allow any encodings other than latin-1 in interactive interp Initial Comment: Python interactive interpreter uses ISO-8859-1 for parsing incoming codes from sys.stdin whatever sys.stdin.encoding is. This patch allows to use locale-aware encodings other than ISO-8859-1 in interactive sessions. eg. Before: >>> u'한글' # (U+D55C, U+AE00) u'\xc7\xd1\xb1\xdb' After: >>> u'한글' u'\ud55c\uae00' The attached sample implementation fall backs to ISO-8859-1 for any non-memory errors such as UnicodeDecodeError. So if you use ascii or iso-8859-1, you'll not able to find difference. It intended to affect to non-latin-1 encoding users. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=941229&group_id=5470 From noreply at sourceforge.net Wed Apr 28 16:35:49 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Apr 28 16:36:05 2004 Subject: [Patches] [ python-Patches-941071 ] Replace if/elif chain with dispatch pattern in sre_compile Message-ID: Patches item #941071, was opened at 2004-04-24 02:07 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=941071&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) >Assigned to: Gustavo Niemeyer (niemeyer) Summary: Replace if/elif chain with dispatch pattern in sre_compile Initial Comment: Use a dictionary to implement switch/case sematics instead of a long if/elif chain. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-04-28 22:35 Message: Logged In: YES user_id=21627 Gustavo, what do you think? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=941071&group_id=5470 From noreply at sourceforge.net Wed Apr 28 16:36:37 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Apr 28 16:36:49 2004 Subject: [Patches] [ python-Patches-940026 ] Explain 'in' keyword as it is first used Message-ID: Patches item #940026, was opened at 2004-04-22 15:35 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=940026&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None >Priority: 7 Submitted By: Gerrit Holl (gerrit) >Assigned to: Martin v. L?wis (loewis) Summary: Explain 'in' keyword as it is first used Initial Comment: Because of a question on a mailing list, I tried to find where the 'in' keyword, for containment testing, was first introduced in the Python tutorial. It turned out not to be, but to be silently introduced in section 4.7.1 (default argument values), and very briefly explained in 5.7 (more on conditions). This patch adds a (very) brief note at the place where the 'in' keyword is first used for containment testing (4.7.1) explaining what it means. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=940026&group_id=5470 From noreply at sourceforge.net Wed Apr 28 17:02:17 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Apr 28 17:02:23 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: Nobody/Anonymous (nobody) 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-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 Wed Apr 28 17:36:41 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Apr 28 17:36:46 2004 Subject: [Patches] [ python-Patches-941071 ] Replace if/elif chain with dispatch pattern in sre_compile Message-ID: Patches item #941071, was opened at 2004-04-24 00:07 Message generated for change (Comment added) made by niemeyer You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=941071&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Gustavo Niemeyer (niemeyer) Summary: Replace if/elif chain with dispatch pattern in sre_compile Initial Comment: Use a dictionary to implement switch/case sematics instead of a long if/elif chain. ---------------------------------------------------------------------- >Comment By: Gustavo Niemeyer (niemeyer) Date: 2004-04-28 21:36 Message: Logged In: YES user_id=7887 Raymond, have you done any performance tests showing that the proposed scheme is better? I've created a small test bed for the two patterns here and it looks like the current pattern is faster for small sets. Given the fact that this is a recursive pattern, and that I'm unsure about the kind of patterns which are most used, I'm a little bit uncomfortable in applying this. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-04-28 20:35 Message: Logged In: YES user_id=21627 Gustavo, what do you think? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=941071&group_id=5470 From noreply at sourceforge.net Wed Apr 28 18:39:16 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Apr 28 18:39:30 2004 Subject: [Patches] [ python-Patches-941071 ] Replace if/elif chain with dispatch pattern in sre_compile Message-ID: Patches item #941071, was opened at 2004-04-23 19:07 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=941071&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Gustavo Niemeyer (niemeyer) Summary: Replace if/elif chain with dispatch pattern in sre_compile Initial Comment: Use a dictionary to implement switch/case sematics instead of a long if/elif chain. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-04-28 17:39 Message: Logged In: YES user_id=80475 It needs to be timed on very large patterns -- it will always do worse on very small patterns (due to the time to setup the dispatch table). I'm not satisfied with the patch the way it stands. Ideally, the dispatch table needs to be pre-computed at compile time. The trick is how to view the enclosing variables (passing them as arguments is slow; using globals is not especially clean or fast). If that were resolved, then this approach would just about always be faster (a dictioary lookup and function call versus a long chain of elifs). Any suggestions are welcome. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2004-04-28 16:36 Message: Logged In: YES user_id=7887 Raymond, have you done any performance tests showing that the proposed scheme is better? I've created a small test bed for the two patterns here and it looks like the current pattern is faster for small sets. Given the fact that this is a recursive pattern, and that I'm unsure about the kind of patterns which are most used, I'm a little bit uncomfortable in applying this. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-04-28 15:35 Message: Logged In: YES user_id=21627 Gustavo, what do you think? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=941071&group_id=5470 From noreply at sourceforge.net Wed Apr 28 19:45:04 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Apr 28 19:45:13 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: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) 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-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 noreply at sourceforge.net Wed Apr 28 19:47:33 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Apr 28 19:47:45 2004 Subject: [Patches] [ python-Patches-943206 ] Convert glob.glob to generator-based DFS Message-ID: Patches item #943206, was opened at 2004-04-27 13:25 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=943206&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None >Priority: 6 Submitted By: Cherniavsky Beni (cben) Assigned to: Nobody/Anonymous (nobody) Summary: Convert glob.glob to generator-based DFS Initial Comment: `glob.glob()` currently calls itself recursively to build a list of matches of the dirname part of the pattern and then filters by the basename part. This is effectively BFS. ``glob.glob('*/*/*/*/*/foo')`` will build a huge list of all directories 5 levels deep even if only a handful of them contain a ``foo`` entry. A generator-based recusion would never have to store these list at once by implementing DFS. This patch converts the `glob` function to an `iglob` recursive generator . `glob()` now just returns ``list(iglob(pattern))``. I also cleaned up the code a bit (reduced duplicate `has_magic()` checks and created a second `glob0` helper func so that the main loop need not be duplicated). This patch assumes patch 941486 adding `os.path.lexists()` was applied; if not the lexists calls will have to be adjasted. Tests and docs patches included. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=943206&group_id=5470 From noreply at sourceforge.net Wed Apr 28 20:52:35 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Apr 28 20:52:42 2004 Subject: [Patches] [ python-Patches-944110 ] urllib2 authentication mishandles empty pass bugfix 944082 Message-ID: Patches item #944110, was opened at 2004-04-29 02: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=944110&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: sc0rp (yangir) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 authentication mishandles empty pass bugfix 944082 Initial Comment: If example.org requires authentication, then following code: host = 'example.org' user = 'testuser' password = '' url = 'http://%s/' % host authInfo = urllib2.HTTPPasswordMgrWithDefaultRealm() authInfo.add_password( None, host, user, password ) authHandler = urllib2.HTTPBasicAuthHandler( authInfo ) opener = urllib2.build_opener( authHandler ) urlFile = opener.open( url ) print urlFile.read() will die by throwing HTTPError 401: File "/usr/lib/python2.3/urllib2.py", line 419, in http_error_default raise HTTPError(req.get_full_url(), code, msg, hdrs, fp) urllib2.HTTPError: HTTP Error 401: Authorization Required even if authenticating with 'testuser' and empty password is valid. Empty password is mishandled (i.e. authentication with empty password string is ignored) in AbstractBasicAuthHandler.retry_http_basic_auth def retry_http_basic_auth(self, host, req, realm): user,pw = self.passwd.find_user_password(realm, host) if pw: [...] It can be fixed by changing: if pw: to if pw is not None: Patch attached. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=944110&group_id=5470 From noreply at sourceforge.net Thu Apr 29 00:30:30 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Apr 29 00:30:46 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: 5 Submitted By: Dan Gass (dmgass) Assigned to: Tim Peters (tim_one) 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 3pdecpdp at ya.com Thu Apr 29 08:03:18 2004 From: 3pdecpdp at ya.com (Mai Lujan) Date: Thu Apr 29 02:06:27 2004 Subject: [Patches] cherubim Message-ID: An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20040429/5737b10b/attachment.html From noreply at sourceforge.net Thu Apr 29 18:20:13 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Apr 29 18:20:42 2004 Subject: [Patches] [ python-Patches-944928 ] Bugfix for dircheck() in Objects/fileobject.c Message-ID: Patches item #944928, was opened at 2004-04-30 00: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=944928&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Ulrich Berning (uberning) Assigned to: Nobody/Anonymous (nobody) Summary: Bugfix for dircheck() in Objects/fileobject.c Initial Comment: When the sys module is initialized in _PySys_Init(), it creates file objects for stdin, stdout and stderr with PyFile_FromFile() which calls fill_file_fields() to initialize the file object. At the end of initialization dircheck() is called, to ensure that the file is not a directory. If the underlaying file descriptors for stdin, stdout, stderr (0, 1, 2) are closed by the parent process, dircheck() fails at least on AIX. I don't know exactly why this fails but the following expression in dircheck() if (fstat(fileno(f->f_fp), &buf) == 0 && S_ISDIR(buf.st_mode)) evaluates to True for stdin which results in setting an exception and returning NULL to _PySys_Init(). The applied patch changes dircheck() to return without further checks if the file object is for stdin, stdout or stderr. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=944928&group_id=5470 From sdri267u at ya.com Wed Apr 28 20:50:00 2004 From: sdri267u at ya.com (Reinaldo Santiago) Date: Thu Apr 29 20:00:50 2004 Subject: [Patches] hostile Message-ID: <0leb-q$80n6$-6h8b00es$6vx85@77hc5xg.2d09> An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20040429/e3055474/attachment.html From Stacey5 at lookingforamate.com Fri Apr 30 12:09:11 2004 From: Stacey5 at lookingforamate.com (Carlo Swan) Date: Fri Apr 30 12:09:20 2004 Subject: [Patches] lay some pipe 0/5/05 Message-ID: <200404301609.i3UG9BWO088761@mxzilla4.xs4all.nl> ESMTP id DADAF72644 for ; Fri, 23 Apr 2004 22:15:42 -0400 (EDT) Received: from mail.msn.com ([145.90.98.112]) by localhost (targa.msn.com [65.221.145.101]) (amavisd-new, port 10067) with ESMTP id 71535-08 for ; Fri, 23 Apr 2004 22:15:42 -0400 (EDT) Received: from spm (Ottawa-ppp-199508.msn.com [108.107.236.188])by mail.msn.com (Postfix) with ESMTP id D8CCD91700for ; Fri, 23 Apr 2004 22:04:45 -0400 (EDT) X-Message-Info: JGTYoYF94jHYfowwei6Kx0KRaH01kJr0 Message-Id: <51341844557276.D8CCD55497@mail.msn.com> X-Virus-Scanned: by amavisd-new at msn.com Return-Path: Stacey5@lookingforamate.com X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-OriginalArrivalTime: 30 Apr 2004 08:48:13.0970 (UTC) FILETIME=[D9F1CAA0:09C428DA] Hello, You application has been approved for extended auto war ranty coverage. Your 24 hour service will with no limits begins very soon. Please finish the 15 second post app lication. You will never have to worry about vehicle problems again with us by your side. Thank you. Travis T. Jenkins Auto Warr anty Associate http://superiorautowarranty.com/auto/?partid=dmps If you feel that you are rece iving this ema il in err or or would like to modify your fut ure pre ferences, please visit: http://superiorautowarranty.com/st.html monomer cordite eighteenth tramp northwest emit ruffle topography moraine tidewater date From qhzrvvmlhel at yahoo.com Fri Apr 30 14:25:11 2004 From: qhzrvvmlhel at yahoo.com (Phyllis Galloway) Date: Fri Apr 30 12:43:20 2004 Subject: [Patches] Windows 2003 Adobe Corel and More $60 w/ Fre.e Shipping dissipate justice Message-ID: An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20040430/7896677d/attachment-0001.html From george_mhermetic at dr.com Fri Apr 30 14:11:21 2004 From: george_mhermetic at dr.com (Registrar) Date: Fri Apr 30 14:11:37 2004 Subject: [Patches] RE:[1] 1mprove your-sperm morphology and quality... evenhanded bungled Message-ID: An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20040501/3f3a7402/attachment.html From gusnsv at muh.biglobe.ne.jp Thu Apr 29 20:01:35 2004 From: gusnsv at muh.biglobe.ne.jp (Dan Craig) Date: Fri Apr 30 16:06:15 2004 Subject: [Patches] want a university degree without going to university? Message-ID: An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20040429/3f9976c8/attachment.html From noreply at sourceforge.net Fri Apr 30 18:14:27 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Apr 30 18:14:31 2004 Subject: [Patches] [ python-Patches-945642 ] nonblocking i/o with ssl socket not working at all Message-ID: Patches item #945642, was opened at 2004-05-01 00: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=945642&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Tino Lange (tinolange) Assigned to: Nobody/Anonymous (nobody) Summary: nonblocking i/o with ssl socket not working at all Initial Comment: Hi! Unfortunately the applied patches #675750 and #676472 (End of January by G. Talvola / B. Laurie / G. v. Rossum) for timeout-sockets in version 1.09 and 1.10 to Modules/_ssl.c broke the nonblocking SSL I/O. In fact sslobj.read() became *always* blocking - whether the underlying socket is blocking or nonblocking doesn't matter at all. In Python < 2.3 this has worked correctly, starting with 2.3, 2.3.x up to the current CVS it doesn't work anymore. Attached is a sample: 0) [ Preparation ] Please run stunnel on your machine to have a SSL service: /usr/sbin/stunnel -p /path/to/some/cert -f -d 4711 -r 4712 1) [ Server ] Please run the easy server.py 2) [Client showing the bug] Please run the client - and see how it hangs when you use Python2.3. Also attached is a diff against the current _ssl.c which shows how to correct that behaviour while also having the possibilities from the above timeout patches. I carefully tested it, please review and test yourself and finally check-in. If you have questions, please don't hesitate to ask me. I really would like to see that not only in 2.4, but also (if possible together with patch #909007 from S. Nicolary) in a 2.3.4 release. Otherwise 2.3.x wasn't at all able to handle nonblocking SSL connections properly. Thanks and cheers, Tino ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=945642&group_id=5470 From noreply at sourceforge.net Fri Apr 30 18:19:24 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Apr 30 18:19:30 2004 Subject: [Patches] [ python-Patches-945642 ] nonblocking i/o with ssl socket not working at all Message-ID: Patches item #945642, was opened at 2004-05-01 00:14 Message generated for change (Settings changed) made by tinolange You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=945642&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None >Priority: 7 Submitted By: Tino Lange (tinolange) Assigned to: Nobody/Anonymous (nobody) Summary: nonblocking i/o with ssl socket not working at all Initial Comment: Hi! Unfortunately the applied patches #675750 and #676472 (End of January by G. Talvola / B. Laurie / G. v. Rossum) for timeout-sockets in version 1.09 and 1.10 to Modules/_ssl.c broke the nonblocking SSL I/O. In fact sslobj.read() became *always* blocking - whether the underlying socket is blocking or nonblocking doesn't matter at all. In Python < 2.3 this has worked correctly, starting with 2.3, 2.3.x up to the current CVS it doesn't work anymore. Attached is a sample: 0) [ Preparation ] Please run stunnel on your machine to have a SSL service: /usr/sbin/stunnel -p /path/to/some/cert -f -d 4711 -r 4712 1) [ Server ] Please run the easy server.py 2) [Client showing the bug] Please run the client - and see how it hangs when you use Python2.3. Also attached is a diff against the current _ssl.c which shows how to correct that behaviour while also having the possibilities from the above timeout patches. I carefully tested it, please review and test yourself and finally check-in. If you have questions, please don't hesitate to ask me. I really would like to see that not only in 2.4, but also (if possible together with patch #909007 from S. Nicolary) in a 2.3.4 release. Otherwise 2.3.x wasn't at all able to handle nonblocking SSL connections properly. Thanks and cheers, Tino ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=945642&group_id=5470 From noreply at sourceforge.net Fri Apr 30 18:58:02 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Apr 30 18:58:06 2004 Subject: [Patches] [ python-Patches-756253 ] itertools roundrobin() Message-ID: Patches item #756253, was opened at 2003-06-17 16:35 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=756253&group_id=5470 Category: Modules Group: Python 2.4 Status: Closed Resolution: Rejected Priority: 5 Submitted By: Jack Diederich (jackdied) Assigned to: Raymond Hettinger (rhettinger) Summary: itertools roundrobin() Initial Comment: a patch to add the roundrobin() and window() objects to the itertools module. Hettinger has already seen the implementation of roundrobin, but not window. test_itertools.py in a seperate patch ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-04-30 17:58 Message: Logged In: YES user_id=80475 For the record, here a simple and efficient roundrobin task server based on collections.deque: def roundrobin(*iterables): pending = deque(iter(i).next for i in iterables) gettask, scheduletask = pending.popleft, pending.append while pending: task = gettask() try: yield task() except StopIteration: continue scheduletask(task) for value in roundrobin('abc', 'd', 'efgh'): print value ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-04-26 18:42 Message: Logged In: YES user_id=80475 Decided not to include this in Py2.4. The tool is not sufficiently general. It has only one use case and arguably that case is better served with collections.deque(). The point in favor of the tool is that it cannot be constructed from other itertools. ---------------------------------------------------------------------- Comment By: Jack Diederich (jackdied) Date: 2003-09-02 19:25 Message: Logged In: YES user_id=591932 The newest triplet of module/test/documentation incorporate your change suggestions. That includes the removal of the window() stuff, so these only contain roundrobin() related patches. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-27 00:13 Message: Logged In: YES user_id=80475 Jack, are you still working on this one? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-01 00:12 Message: Logged In: YES user_id=80475 Great. I look forward to it. ---------------------------------------------------------------------- Comment By: Jack Diederich (jackdied) Date: 2003-06-27 13:33 Message: Logged In: YES user_id=591932 pushed to 2.4 I'll put up patches that incorporate rhettinger's feedback soon, and definitely in time for the 2.4 branch. ---------------------------------------------------------------------- Comment By: Jack Diederich (jackdied) Date: 2003-06-27 13:27 Message: Logged In: YES user_id=591932 added Lib/test/test_itertools.py patch here, deleted old item that just had that patch in it ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-18 15:11 Message: Logged In: YES user_id=80475 *Please post the tests to this patch and close the other patch. *Add a documentation patch to this patch *Let's drop the addition of window(). The C code for it is less than beautiful and offers only a minimal performance gain over the pure python equivalent. I've added the pure python version to the docs so folks can cut and paste it if they need it. Sorry for the wild goose chase (I had expected the C version to be much cleaner and faster and that the python verions would've been harder -- actual code was needed for me to see it). * In roundrobin_next(), replace the % operator with: if (lz->iternum==lz->itersize) lz-iternum=0; * In roundrobin_next(), remove the extra blank line following "long listsize;" * Fixup the indentation, currently it is a mix of spaces and tabs. It should be just pure tabs. * Replace the variable name 'lz' with 'rr'. I should have changed that in other places too but for new code it should be fixed. * 'unti' is mispelled in the docstring. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=756253&group_id=5470 From fednpbneyxbaml at yahoo.com Fri Apr 30 22:52:19 2004 From: fednpbneyxbaml at yahoo.com (Kim Harvey) Date: Fri Apr 30 21:10:28 2004 Subject: [Patches] Microsoft, Adobe, Macromedia all software on Sa.le $60 w/Fre.e Shipping demean arrear windbag Message-ID: <753126r6cbo2$an9j8s47$7668r2n5@GB036963526028> An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20040501/5e547947/attachment-0001.html