From noreply at sourceforge.net Thu Jan 1 00:01:28 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 1 00:01:33 2004 Subject: [ python-Bugs-816476 ] Fatal Python error: GC object already tracked Message-ID: Bugs item #816476, was opened at 2003-10-02 06:42 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=816476&group_id=5470 Category: Python Interpreter Core >Group: 3rd Party >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Thorsten Henninger (thenninger) Assigned to: Nobody/Anonymous (nobody) Summary: Fatal Python error: GC object already tracked Initial Comment: Fatal Python error: GC object already tracked OS: Windows 2000 Server (Service Pack 4) Python: 2.3.1 (#47) pycurl: 7.10.6 I got this Fatal Error while fetching Webpages with pycurl. I do not have any other addiotional information. This error is reproducible and did not occur with Python2.2. Please contact me, if you need further information ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2004-01-01 00:01 Message: Logged In: YES user_id=31435 Closed as (presumed) 3rd-party, won't fix. There's been no followup for 3 months; no other report of this symptom has been filed; and someone on c.l.py today reported what appears to be exactly the same problem *again* coming from use of pycurl. So all the evidence points to pycurl, and none so far to Python. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-10-04 13:18 Message: Logged In: YES user_id=31435 Reopening until we know more. ---------------------------------------------------------------------- Comment By: Thorsten Henninger (thenninger) Date: 2003-10-02 14:07 Message: Logged In: YES user_id=878819 thank you, that makes sense! i will notice pycurl and have a look in th pycurl source! ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-10-02 12:25 Message: Logged In: YES user_id=31435 You should report this to the pycurl project. The specific error message you report is new in Python 2.3, doing a check for errnoneous usage of the Python C API. That check didn't exist in Python 2.2. While it's possible there's a previously unreported error in Python 2.3 here, it's much more likely that the problem is in pycurl's C code, and that the error there simply went undetected before Python 2.3, appearing to work by luck. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-10-02 06:51 Message: Logged In: YES user_id=6656 Why do you think this is a bug in Python and not pycurl? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=816476&group_id=5470 From noreply at sourceforge.net Thu Jan 1 00:28:44 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 1 00:31:50 2004 Subject: [ python-Bugs-852532 ] ^$ won't split on empty line Message-ID: Bugs item #852532, was opened at 2003-12-02 05:01 Message generated for change (Comment added) made by mkc You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=852532&group_id=5470 Category: Regular Expressions Group: Python 2.3 Status: Open Resolution: Postponed Priority: 5 Submitted By: Jan Burgy (jburgy) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: ^$ won't split on empty line Initial Comment: Python 2.3.2 (#49, Oct 2 2003, 20:02:00) [MSC v.1200 32 bit (Intel)] on win32 >>> import re >>> re.compile('^$', re.MULTILINE).split('foo\n\nbar') ['foo\n\nbar'] I expect ['foo\n', '\nbar'], since, according to the documentation $ "in MULTILINE mode also matches before a newline". Thanks, Jan ---------------------------------------------------------------------- Comment By: Mike Coleman (mkc) Date: 2003-12-31 23:28 Message: Logged In: YES user_id=555 Hi, I was going to file this bug just now myself, as this seems like a really useful feature. For example, I've several times wanted to split on '^' or '^(?=S)' (to split up a data file into paragraphs that start with an initial S). Instead I have to do something like '\n(?=S)', which is rather more hideous. To answer tim_one's challenge, yes, I *do* expect splitting by 'x*' to break a string into letters, now that I've thought about it. To not do so is a bizarre and surprising behavior, IMO. (Patient: Doctor, when I split on this nonsense pattern I get nonsense! Doctor: Then don't do that.) The fix should be near this line in _sre.c, I think. if (state.start == state.ptr) { I could work on a patch if you'll take it... Mike ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2003-12-11 07:42 Message: Logged In: YES user_id=38376 Split never splits on empty substrings; see Tim's answer for a brief discussion. Fred, can you perhaps add something to the documentation? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-12-02 09:20 Message: Logged In: YES user_id=31435 Confirmed on Pythons 2.1.3, 2.2.3, 2.3.2, and current CVS. More generally, split() doesn't appear to split on any empty (0-length) match. For example, >>> pat = re.compile(r'\b') >>> pat.split('(a b)') ['(a b)'] >>> pat.findall('(a b)') # but the pattern matches 4 places ['', '', '', ''] >>> That's probably a design constraint, but isn't documented. For example, if you split "abc" by the pattern x*, what do you expect? The pattern matches (with length 0) at 4 places, but I bet most people would be surprised to get ['', 'a', 'b', 'c', ''] back instead of (as they do get) ['abc'] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=852532&group_id=5470 From noreply at sourceforge.net Thu Jan 1 00:47:23 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 1 00:47:27 2004 Subject: [ python-Bugs-820344 ] Ref Man Index: Symbols -- Latex leak Message-ID: Bugs item #820344, was opened at 2003-10-08 19:39 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=820344&group_id=5470 Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Terry J. Reedy (tjreedy) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Ref Man Index: Symbols -- Latex leak Initial Comment: Current online Ref Manual, Index, Symbols section has following text which looks like untranslated Latex: \textttNone object \textttNotImplemented object ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2004-01-01 00:47 Message: Logged In: YES user_id=3066 Fixed this and a similar occurance in the Python/C API Reference in CVS: Doc/api/concrete.tex revisions 1.37, 1.25.10.4 Doc/ref/ref3.tex revisions 1.118, 1.114.4.4 Doc/ref/ref6.tex revisions 1.70, 1.68.8.2 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=820344&group_id=5470 From noreply at sourceforge.net Thu Jan 1 00:48:47 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 1 00:48:50 2004 Subject: [ python-Bugs-817742 ] Need "new style" note regarding descriptors Message-ID: Bugs item #817742, was opened at 2003-10-04 11:26 Message generated for change (Settings changed) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=817742&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: David Abrahams (david_abrahams) Assigned to: Fred L. Drake, Jr. (fdrake) >Summary: Need "new style" note regarding descriptors Initial Comment: When you split my patch into http://www.python.org/doc/current/ref/new-style- attribute-access.html and http://www.python.org/doc/current/ref/descriptors.html, the descriptors info doesn't say "new style classes only anymore" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=817742&group_id=5470 From noreply at sourceforge.net Thu Jan 1 01:01:59 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 1 01:02:07 2004 Subject: [ python-Feature Requests-852222 ] builtin save() function available interactively only Message-ID: Feature Requests item #852222, was opened at 2003-12-01 13:13 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=852222&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gerrit Holl (gerrit) Assigned to: Nobody/Anonymous (nobody) Summary: builtin save() function available interactively only Initial Comment: I think that for learning python, it would be nice to save the current namespace to a file using a builtin save() function (and corresponding load(). For beginning programmers, it would be nice to be able to tinker interactively with the shell, defining functions and maybe even classes, with which they can continue later on. save() is easily implemented with pickling locals(); load() is easily implemented with updating locals() while unpickling it. The functions would take a filename (string) as an argument. In Idle, they are in the menu. Like the _ variable, load() and save() are only present in the interactive shell (some global .pythonrc?). I think it would be a useful addition to Python 2.4. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-01-01 01:01 Message: Logged In: YES user_id=80475 Yes, that would be nice but it exceeds the capabilities of pickle which only saves function and class names rather than values: >>> def f(x, y, z): m = min([x, y, z]) n = max([x, y, z]) p = m * n q = p ** 0.5 return q / y >>> pickle.dumps(f) 'c__main__\nf\np0\n.' It may be possible to save the interpreter window as a text file to be replayed later after the prompts and results have been stripped. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=852222&group_id=5470 From noreply at sourceforge.net Thu Jan 1 01:22:37 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 1 01:22:42 2004 Subject: [ python-Feature Requests-846568 ] All numbers are bitarrays too Message-ID: Feature Requests item #846568, was opened at 2003-11-21 08:18 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=846568&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alexander R?dseth (alexanro) Assigned to: Nobody/Anonymous (nobody) Summary: All numbers are bitarrays too Initial Comment: It would be nice if all numbers could be used as arrays of bits as well. Example: >>> i = 10 >>> i[0] = 1 >>> print i 11 >>> print list(i) [1, 1, 0, 1] >>> "".join(map(lambda b:str(b), l)) '1101' >>> for bit in i: print bit 1 1 0 1 ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-01-01 01:22 Message: Logged In: YES user_id=80475 Allowing assignments like i[o]=1 can only work for mutable objects. Since int is immutable, your idea would need to be implemented as a separate extension class. I recommend writing it first in pure python and posting it as a cookbook recipe. After it matures (possibly growing other bit twiddling methods such as countbits) and has a fan club (with some real world applications), it might warrant coding in C. >From my experience with the setmodule, I can say that this is not a trivial understanding, so you really have to be sure you've worked out the API and that it meets real needs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=846568&group_id=5470 From noreply at sourceforge.net Thu Jan 1 01:35:47 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 1 01:35:52 2004 Subject: [ python-Feature Requests-829370 ] math.signum(int) Message-ID: Feature Requests item #829370, was opened at 2003-10-23 21:44 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=829370&group_id=5470 Category: Python Library Group: None >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Konrad Voelkel (gekonntde) Assigned to: Nobody/Anonymous (nobody) Summary: math.signum(int) Initial Comment: python needs a signum function, def signum(self, int): if(int < 0): return -1; elif(int > 0): return 1; else: return int; ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-01-01 01:35 Message: Logged In: YES user_id=80475 Closed due to lack of further interest or development. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-11-28 12:56 Message: Logged In: YES user_id=80475 With the use cases being infrequent and the pure python version being so easy, I think we ought to pass on this one. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=829370&group_id=5470 From noreply at sourceforge.net Thu Jan 1 01:39:28 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 1 01:39:38 2004 Subject: [ python-Feature Requests-816628 ] request for bugs.python.org Message-ID: Feature Requests item #816628, was opened at 2003-10-02 10:55 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=816628&group_id=5470 Category: Documentation Group: None Status: Open Resolution: Later Priority: 5 Submitted By: Philippe Fremy (pfremy) Assigned to: Nobody/Anonymous (nobody) Summary: request for bugs.python.org Initial Comment: Many projects (gentoo, gnome, kde...) have the conveninent url for accessing the bug database: bugs.python.org That would be cool. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-01-01 01:39 Message: Logged In: YES user_id=80475 We now own the domain, but I don't see an advantage to duplicating what is on SF. The main website at www.python.org has a direct link on the main page. IMO, that is enough. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-10-02 11:15 Message: Logged In: YES user_id=12800 Even if it's a good idea, we can't do this until the PSF controls the python.org domain. I don't know what the status of that is, but I believe a transfer is in the works. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=816628&group_id=5470 From noreply at sourceforge.net Thu Jan 1 01:50:15 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 1 01:50:20 2004 Subject: [ python-Feature Requests-740495 ] API enhancement: poplib.MailReader() Message-ID: Feature Requests item #740495, was opened at 2003-05-20 09:35 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=740495&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Hartmut Goebel (htgoebel) Assigned to: Nobody/Anonymous (nobody) Summary: API enhancement: poplib.MailReader() Initial Comment: When retrieving POP3 mails using poplib, messages are returned as list of lines. Converting them to a email.Messages requires concatinating them into a single string. I suggest writing a little file-like class wrapper which may be used for parsing these type of messages without concatinating the lines first. This wrapper may be exposed in the poplib module. I suggest calling this class 'MailReader', but I would appreciate better naeming :-) If this is of interest, I may volunteer writing this wrapper. See also: Feature Requests item #736494, was opened at 2003-05-12 11:17 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=384681&aid=736494&group_id=25568 ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-01-01 01:50 Message: Logged In: YES user_id=80475 Perhaps the adaptor should be part of the email package rather than a part of poplib. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=740495&group_id=5470 From noreply at sourceforge.net Thu Jan 1 01:53:36 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 1 01:53:41 2004 Subject: [ python-Feature Requests-727898 ] Support for sending multipart form data Message-ID: Feature Requests item #727898, was opened at 2003-04-26 01:37 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=727898&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Hunter Peress (hfastedge) >Assigned to: Barry A. Warsaw (bwarsaw) Summary: Support for sending multipart form data Initial Comment: This is necessary, and simple. See:http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/146306 There should be 0 politics about the lack of this. In response to this if there is some reason you cannot include this code directly into urllib (most likely), please tell me what I can do within the time frame of my reply to 1 email response to get this code included into the python libraries immediately. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-01-01 01:53 Message: Logged In: YES user_id=80475 Barry, what do you think about this one? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-06 20:10 Message: Logged In: YES user_id=33168 The best way to get anything included into python is to submit a patch. The patch needs to be complete and tested with all source code, documentation and tests in a single patch file. The patch should be relative to current cvs. See http://www.python.org/dev/ for more information. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=727898&group_id=5470 From noreply at sourceforge.net Thu Jan 1 01:59:48 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 1 01:59:54 2004 Subject: [ python-Feature Requests-694339 ] Dedenting with Shift+Tab Message-ID: Feature Requests item #694339, was opened at 2003-02-27 08:08 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=694339&group_id=5470 Category: IDLE Group: None Status: Open Resolution: None Priority: 5 Submitted By: Daniel (kamek) >Assigned to: Kurt B. Kaiser (kbk) Summary: Dedenting with Shift+Tab Initial Comment: IDLE already provides quick block indenting, by selecting one or more lines and pressing Tab. So, it would make sense to have Shift+Tab to do the opposite work. While there's already Alt+[ (and Alt+] to indent), Shift+Tab is more intuitive, especially to those who are used to other Windows developer tools, like Visual Studio or TextPad. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-19 20:20 Message: Logged In: YES user_id=80475 While you get used to it quickly, I've bumped in to this also. It is nice to have the control keys work the same across applications. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=694339&group_id=5470 From noreply at sourceforge.net Thu Jan 1 02:01:48 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 1 02:01:51 2004 Subject: [ python-Feature Requests-708125 ] Requesting Mock Object support for unittest.TestCase Message-ID: Feature Requests item #708125, was opened at 2003-03-22 15:05 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=708125&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthew Russell (mattruss) >Assigned to: Steve Purcell (purcell) Summary: Requesting Mock Object support for unittest.TestCase Initial Comment: I previously submitted a patch (sf id 706590), since I was following www.python.com's notes on how to contribute - since using sf more i think i should of added it to this RFE. Since posting the orignal patch I have updated the code based upon sugestions from python-dev and others. please view my origanal patch here: https://sourceforge.net/tracker/index.php? func=detail&aid=706590&group_id=5470&atid=305470 This patch adds one method - createMockInstance (classDef, overrides, *initArgs, **initKwds) to unittest.TestCase, and two classes MockFactory and MockMethod. Since both these classes should never really be used outside the scope of a unittest, I thought it best to add them to the unittest module (allthough it is getting rather big - should be split into a package?) ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-01-01 02:01 Message: Logged In: YES user_id=80475 Steve, do you can to pronounce on this one? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-19 19:16 Message: Logged In: YES user_id=80475 Matthew, thanks for the patch. It gets a little better with each update (though it is still in dire need of a spell-check). The cost/benefit of adding this to the unittest module is not clear. Perhaps, it would be worthwhile to present it on the newsgroup to tease out the idea, build a fan club for it, or come up with a simpler API. My biggest issue with the unittest module is that it is already too extensive. One has to read a small book on the subject to get started. The number of doc pages, classes, and methods rank it as more complex than most of the net modules (with the notable exception of the email package). In Beck's TDD book (p. 119), he comments that some unittest packages are already too complicated for his tastes. This patch would make the complexity issue worse. It takes longer to figure out how the use the patch that it does to create a small, easy-to-read, special purpose mock object. Also, I'm concerned that MockObjects tend to create a false sense of security in a situation where the actual object behavior diverges from the simulated behavior. Also, to the extent that a simulation is simple, it tends to discourage adding tests that exercise all the nuances of a real object. For example, a MockDatabase may simulate the expected replies to some queries but doesn't behave enough like the real thing to encourge tests on commits, rollbacks, cache flushing, re-ordered tables, etc. If this doesn't get added to the unittest module, it would certainly be worthwhile to post it to the Python Cookbook so that advanced users can get to it when they need it. ---------------------------------------------------------------------- Comment By: Matthew Russell (mattruss) Date: 2003-04-09 19:32 Message: Logged In: YES user_id=737261 I wrote these unittests first before i wrote the code. Hopefully proves that it works for new style classes and old (allthought tests are now a little out of date as the updated diff uses sets, therefore is 2.3 specific) ---------------------------------------------------------------------- Comment By: Matthew Russell (mattruss) Date: 2003-04-09 17:53 Message: Logged In: YES user_id=737261 I have made some changes to my patch - i hope it's made things clearer (?) have also replaced 0/1's with False/True where appropriate added boolean kwd arg to main - exitsOnResult which if set to false will not do sys.exit (now you can run python -i test_mystuff.py using this and not be thrown back out to the command line) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=708125&group_id=5470 From noreply at sourceforge.net Thu Jan 1 02:04:34 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 1 02:04:39 2004 Subject: [ python-Feature Requests-778859 ] Make the generators working like Sather iterator Message-ID: Feature Requests item #778859, was opened at 2003-07-28 05:52 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=778859&group_id=5470 Category: Parser/Compiler Group: None >Status: Closed >Resolution: Rejected Priority: 2 Submitted By: Lionel Thiry (shasckaw) Assigned to: Nobody/Anonymous (nobody) Summary: Make the generators working like Sather iterator Initial Comment: Primarly, it would only be a syntaxic sugar. But it can lead to some unexpected opitmisations. The feature would allow this: def upto(first, last): x=first while x<=last: yield x x=x+1 x=upto(1, 10) try: while 1: print x.next() except StopIteration: print "End of loop" To be written like in Sather or something near it: def upto(first, last): #same definition as above loop: print upto!(1, 10) finally: print "End of loop" As you can see, it's shorter, smarter, and more easy to understand. The '!' in upto!(1, 10) is important to emphasize its r?le as a generator. The creators of Sather tell that this technique can lead to a very high optimisation of loops. I hope that this request will be deeply studied because it is really worth of it. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-01-01 02:04 Message: Logged In: YES user_id=80475 Closing due to lack of further development. If it needs to be brought up again, I recommend starting in the newsgroup and then following up with a PEP. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-11 20:36 Message: Logged In: YES user_id=80475 For a change of this magnitude, you would need to write up a PEP that summarizes the idea, lists advantages, presents use cases, and discusses implementation issues. The first step is to introduce the idea on comp.lang.python to tease out the issues. The satheric approach does not fit well with existing python generators or with pythonic style. There would need to be a new LOOP statement that functions as: try: while 1: except StopIteration: pass There would also need to be a new keyword for turning regular iterators into satheric iterators, so that "sather(xrange (20))" would have the effect of 1) On the first pass, calling: it = iter(xrange(20)) 2) On each pass, calling and returning it.next() 3) Passing through the StopIteration on the last pass Besides the implementation demands, there are conflicts with python style programming. Controlling loops from the inside runs contrary to most current approaches to python programming -- a notable exception is the use of callback functions in GUI programming. Other considerations are: * do we want to have one more way of implementing iterators * does it fit with pythons goals for being easily readable and friendly to first time programmers -- I think the answer is no because I find your satheric loop example difficult to follow (and the same is doubly true for the sather tutorial's bubble sort example). Without some darned compelling use cases, I believe your feature request is doomed. ---------------------------------------------------------------------- Comment By: Lionel Thiry (shasckaw) Date: 2003-07-28 08:23 Message: Logged In: YES user_id=824691 My example was too simple, sorry. Here is a doc page about satheric iterators: http://www.gnu.org/software/sather/Doc/tutorial.html/iterators873.html And the next one is also pretty interesting. With the satheric way to write it, one would be able to do this: loop: a=range!(1,10) if test(a): b=range!(1,10) print "("+ a + "," + "b" + ")" My error is repaired now! :) The first iterator to stop stop the loop. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-07-28 07:22 Message: Logged In: YES user_id=12800 The Pythonic way to write the latter (after the def) is: for x in upto(1, 10): print x else: print 'end of loop' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=778859&group_id=5470 From noreply at sourceforge.net Thu Jan 1 02:10:42 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 1 02:10:48 2004 Subject: [ python-Feature Requests-668905 ] logging module documentation Message-ID: Feature Requests item #668905, was opened at 2003-01-16 00:07 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=668905&group_id=5470 Category: Documentation Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Richard Jones (richard) >Assigned to: Vinay Sajip (vsajip) Summary: logging module documentation Initial Comment: I believe the logging module documentation needs to give an example of how to simply log to a file. The following example snippet could be appropriate: import logging logger = logging.getLogger('myapp') hdlr = FileHandler('/var/myapp/debug.log') hdlr.setFormatter(Formatter('%(asctime)s %(level)s %(message)s')) logger.addHandler(hdlr) logger.setLevel(DEBUG) ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-01-01 02:10 Message: Logged In: YES user_id=80475 I would also like to see a more thorough set of introductory examples. The second page of the unittest documentation could serve as a model -- it attempts to cover the 90% of what you need to know in a single page of examples. As it stands now, the documentation for the logging module is formidable. Those wanting to take advantage of the module face a steep learning curve from rather heavyweight documentation -- it's complexity exceeds that of almost all modules except for the email and xml packages. Assigning to Vinay Sajip to work with Anthony to improve the docs. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-07-08 01:32 Message: Logged In: YES user_id=29957 Why was this closed? nnorwitz's doc fixes, as seen in CVS or http://www.python.org/dev/doc/devel/lib/module-logging.html have no examples section. Running the current logging module docs past a number of python coders here produced a consistent "what the heck?" response - the opening introduction provides no indications of how to use the package. This is a problem for me, right now, so I'm re-opening and assigning to myself to fix. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-28 01:37 Message: Logged In: YES user_id=80475 Reviewed. Closing RFE. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-25 16:36 Message: Logged In: YES user_id=33168 I just updated the logging documentation. Could you please review for accuracy and completeness? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=668905&group_id=5470 From noreply at sourceforge.net Thu Jan 1 02:12:14 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 1 02:12:33 2004 Subject: [ python-Feature Requests-588825 ] unittest.py, better error message Message-ID: Feature Requests item #588825, was opened at 2002-07-30 17:29 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=588825&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stefan Heimann (stefanheimann) >Assigned to: Steve Purcell (purcell) Summary: unittest.py, better error message Initial Comment: These two methods of the class TestCase are not very good: def failUnlessEqual(self, first, second, msg=None): """Fail if the two objects are unequal as determined by the '!=' operator. """ if first != second: raise self.failureException, (msg or '%s != %s' % (`first`, `second`)) def failIfEqual(self, first, second, msg=None): """Fail if the two objects are equal as determined by the '==' operator. """ if first == second: raise self.failureException, (msg or '%s == %s' % (`first`, `second`)) The first thing is that you should print the difference of the given values like that: '<%s> == <%s>' % (`first`, `second`) The < and > delimits the string and so is is easier to detect where the string starts and where it ends. The second thing is that I would really like to see the two values that are (not) equal even if I provide a message. Maybe its better to raise the exception like that: if msg is not None: msg += ' Expected: <%s>, is: <%s>' % (first, second) raise self.failureException, (msg or '%s != %s' % (`first`, `second`)) bye Stefan ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-20 23:47 Message: Logged In: YES user_id=357491 I am making this an RFE since it is just a suggestion and not a bug. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-08-18 17:19 Message: Logged In: YES user_id=80475 Steve, would you like these implemented or left as is? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=588825&group_id=5470 From noreply at sourceforge.net Thu Jan 1 02:17:27 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 1 02:17:34 2004 Subject: [ python-Feature Requests-558238 ] Pickling bound methods Message-ID: Feature Requests item #558238, was opened at 2002-05-20 06:17 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=558238&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Konrad Hinsen (hinsen) Assigned to: Martin v. L?wis (loewis) Summary: Pickling bound methods Initial Comment: Last week I noticed that the pickle and cPickle modules cannot handle bound methods. I found a solution that is simple and (I think) general, so perhaps it should become part of the standard library. Here is my code: import copy_reg def pickle_bound_method(method): return getattr, (method.im_self, method.__name__) class _Foo: def bar(self): pass _foo = _Foo() copy_reg.constructor(getattr) copy_reg.pickle(type(_foo.bar), pickle_bound_method) ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-01-01 02:17 Message: Logged In: YES user_id=80475 Any progress on this one? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-09-30 10:35 Message: Logged In: YES user_id=21627 My concern is that the getattr call already creates a danger, since you just have to find a 'suitable' object whose __getattr__ does funny things. In the revised form, this object would also have to appear as the __class__ of some other object, so I guess this is pretty safe. I'll ask python-dev. ---------------------------------------------------------------------- Comment By: Konrad Hinsen (hinsen) Date: 2002-09-30 08:36 Message: Logged In: YES user_id=11850 True. Would it be a security problem to use getattr inside a specialized constructor? For example, def get_method(object, name): klass = object.__class__ fn = getattr(klass, name) return new.instancemethod(fn, object, klass) This would be difficult to abuse as a general getattr replacement, because new.instancemethod would fail in most cases other than the intended one. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-09-30 05:03 Message: Logged In: YES user_id=21627 Reconsidering: It fails to work in the presence of inheritance, right? >>> class B: ... def foo(self):pass ... >>> class D(B):pass ... >>> d = D() >>> m = d.foo >>> m.im_self <__main__.D instance at 0x1ccb28> >>> m.__name__ 'foo' >>> D.__dict__['foo'] Traceback (most recent call last): File "", line 1, in ? KeyError: foo >>> ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-09-24 13:12 Message: Logged In: YES user_id=21627 That sounds good to me; I'm going to install it. ---------------------------------------------------------------------- Comment By: Konrad Hinsen (hinsen) Date: 2002-09-24 12:54 Message: Logged In: YES user_id=11850 Of course: import copy_reg def get_method(object, name): klass = object.__class__ fn = klass.__dict__[name] return new.instancemethod(fn, object, klass) def pickle_bound_method(method): return get_method, (method.im_self, method.__name__) class _Foo: def bar(self): pass _foo = _Foo() copy_reg.constructor(get_method) copy_reg.pickle(type(_foo.bar), pickle_bound_method) ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-09-22 08:08 Message: Logged In: YES user_id=21627 Can you perhaps rewrite this to use new.instancemethod? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-06-09 12:14 Message: Logged In: YES user_id=21627 Making getattr a safe_constructor has security implictions which make this approach dangerous. It seems that unpickling might invoke arbitrary __getattr__ implementations. Adding a protocol to declare classes as "safe for getattr" might help. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=558238&group_id=5470 From noreply at sourceforge.net Thu Jan 1 02:23:08 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 1 02:23:13 2004 Subject: [ python-Bugs-563298 ] Fuzziness in inspect module documentatio Message-ID: Bugs item #563298, was opened at 2002-06-01 10:03 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=563298&group_id=5470 Category: Documentation Group: Not a Bug >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Franc,ois Pinard (pinard) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Fuzziness in inspect module documentatio Initial Comment: Hello, Fred. I'm looking at Web pages about the `inspect' module, and more precisely `inspect-stack.html'. The text speaks about "higher" and "lower", "above" and "below", and this is ambiguous as people would draw the stack top up, and other would draw the stack top down. Do you agree that this could be clarified? The text could rather stick with words like "recent" or "older", or "near the top" or "away from the top", maybe. Beware that the word "deeper" is ambiguous too. Or else, the text could explain the drawing convention for stacks used in the text, so people could interpret what is written. One might try to guess the drawing conventions from the fact functions have "outer" and "inner" in their name, but this is too difficult. Maybe the text could use "outer" and "inner" more systematically, all over? It would most probably create more clarity. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2004-01-01 02:23 Message: Logged In: YES user_id=3066 Fixed in Doc/lib/libinspect.tex revisions 1.15, 1.13.10.2. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=563298&group_id=5470 From noreply at sourceforge.net Thu Jan 1 02:30:04 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 1 02:30:10 2004 Subject: [ python-Bugs-833957 ] Ctrl+key combos stop working in IDLE Message-ID: Bugs item #833957, was opened at 2003-10-31 19:27 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=833957&group_id=5470 Category: IDLE Group: None Status: Open Resolution: None Priority: 5 Submitted By: Kirby Urner (urnerk) Assigned to: Kurt B. Kaiser (kbk) Summary: Ctrl+key combos stop working in IDLE Initial Comment: After awhile using Python 2.3 IDLE in Windows, the control keys such as Ctrl+C (copy) and Ctrl+V (paste) stop having any effect. Menu pulldowns continue to work. I have yet to notice what circumstances might trigger this behavior. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-01-01 02:30 Message: Logged In: YES user_id=80475 FWIW, I've had this happen also. Unfortunately, I usually have so much going on that I haven't been able to relate it to a specific cause. ---------------------------------------------------------------------- Comment By: Kirby Urner (urnerk) Date: 2003-11-17 11:04 Message: Logged In: YES user_id=191709 I'm using WinXP Pro. Given this has not previously been reported, I will do my best to gather data on your questions as I continue to use IDLE. Ideally, I will be able to duplicate it at will. We shall see. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-11-16 23:56 Message: Logged In: YES user_id=149084 I haven't observed this behavior, nor heard of it before. What version of Windows are you using? The keybindings are established in Tk just after IDLE starts and are subsequently intercepted and handled by the Tk library. Do all the Ctrl bindings fail? Even Tk defaults like Ctrl-E, which goes to end of line? What about Alt bindings? Do the Ctrl keys work in other applications after they stop working in IDLE? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=833957&group_id=5470 From noreply at sourceforge.net Thu Jan 1 05:29:38 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 1 05:29:43 2004 Subject: [ python-Bugs-868743 ] os.tmpfile seek(0) fails on cygwin Message-ID: Bugs item #868743, was opened at 2004-01-01 12:29 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=868743&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Miki Tebeka (tebeka) Assigned to: Nobody/Anonymous (nobody) Summary: os.tmpfile seek(0) fails on cygwin Initial Comment: [12:25] $python Python 2.3.3 (#1, Dec 22 2003, 11:56:28) [GCC 3.3.1 (cygming special)] on cygwin Type "help", "copyright", "credits" or "license" for more information. >>> from os import tmpfile >>> f = tmpfile() >>> f.seek(0) Traceback (most recent call last): File "", line 1, in ? IOError: [Errno 29] Illegal seek >>> ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=868743&group_id=5470 From noreply at sourceforge.net Thu Jan 1 07:48:53 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 1 07:48:58 2004 Subject: [ python-Feature Requests-558238 ] Pickling bound methods Message-ID: Feature Requests item #558238, was opened at 2002-05-20 13:17 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=558238&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Konrad Hinsen (hinsen) Assigned to: Martin v. L?wis (loewis) Summary: Pickling bound methods Initial Comment: Last week I noticed that the pickle and cPickle modules cannot handle bound methods. I found a solution that is simple and (I think) general, so perhaps it should become part of the standard library. Here is my code: import copy_reg def pickle_bound_method(method): return getattr, (method.im_self, method.__name__) class _Foo: def bar(self): pass _foo = _Foo() copy_reg.constructor(getattr) copy_reg.pickle(type(_foo.bar), pickle_bound_method) ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-01-01 13:48 Message: Logged In: YES user_id=21627 There was some discussion on python-dev (initiated by Christian) on whether bound methods should provide an __reduce__. Apart from that, no progress. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-01-01 08:17 Message: Logged In: YES user_id=80475 Any progress on this one? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-09-30 17:35 Message: Logged In: YES user_id=21627 My concern is that the getattr call already creates a danger, since you just have to find a 'suitable' object whose __getattr__ does funny things. In the revised form, this object would also have to appear as the __class__ of some other object, so I guess this is pretty safe. I'll ask python-dev. ---------------------------------------------------------------------- Comment By: Konrad Hinsen (hinsen) Date: 2002-09-30 15:36 Message: Logged In: YES user_id=11850 True. Would it be a security problem to use getattr inside a specialized constructor? For example, def get_method(object, name): klass = object.__class__ fn = getattr(klass, name) return new.instancemethod(fn, object, klass) This would be difficult to abuse as a general getattr replacement, because new.instancemethod would fail in most cases other than the intended one. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-09-30 12:03 Message: Logged In: YES user_id=21627 Reconsidering: It fails to work in the presence of inheritance, right? >>> class B: ... def foo(self):pass ... >>> class D(B):pass ... >>> d = D() >>> m = d.foo >>> m.im_self <__main__.D instance at 0x1ccb28> >>> m.__name__ 'foo' >>> D.__dict__['foo'] Traceback (most recent call last): File "", line 1, in ? KeyError: foo >>> ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-09-24 20:12 Message: Logged In: YES user_id=21627 That sounds good to me; I'm going to install it. ---------------------------------------------------------------------- Comment By: Konrad Hinsen (hinsen) Date: 2002-09-24 19:54 Message: Logged In: YES user_id=11850 Of course: import copy_reg def get_method(object, name): klass = object.__class__ fn = klass.__dict__[name] return new.instancemethod(fn, object, klass) def pickle_bound_method(method): return get_method, (method.im_self, method.__name__) class _Foo: def bar(self): pass _foo = _Foo() copy_reg.constructor(get_method) copy_reg.pickle(type(_foo.bar), pickle_bound_method) ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-09-22 15:08 Message: Logged In: YES user_id=21627 Can you perhaps rewrite this to use new.instancemethod? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-06-09 19:14 Message: Logged In: YES user_id=21627 Making getattr a safe_constructor has security implictions which make this approach dangerous. It seems that unpickling might invoke arbitrary __getattr__ implementations. Adding a protocol to declare classes as "safe for getattr" might help. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=558238&group_id=5470 From noreply at sourceforge.net Thu Jan 1 10:15:34 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 1 10:15:42 2004 Subject: [ python-Feature Requests-816628 ] request for bugs.python.org Message-ID: Feature Requests item #816628, was opened at 2003-10-02 17:55 Message generated for change (Comment added) made by pfremy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=816628&group_id=5470 Category: Documentation Group: None Status: Open Resolution: Later Priority: 5 Submitted By: Philippe Fremy (pfremy) Assigned to: Nobody/Anonymous (nobody) Summary: request for bugs.python.org Initial Comment: Many projects (gentoo, gnome, kde...) have the conveninent url for accessing the bug database: bugs.python.org That would be cool. ---------------------------------------------------------------------- >Comment By: Philippe Fremy (pfremy) Date: 2004-01-01 16:15 Message: Logged In: YES user_id=233844 The goal is not to duplicate the sf page, just to provide an easier way to find it. bugs.python.org is very convenient and easy to remember. It saves time for the people reporting bugs because one does not have to skim through the 100 links of www.python.org to find where to report bugs. Other projects have adpoted it with success. There is nothing to lose by providing this shortcut. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-01-01 07:39 Message: Logged In: YES user_id=80475 We now own the domain, but I don't see an advantage to duplicating what is on SF. The main website at www.python.org has a direct link on the main page. IMO, that is enough. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-10-02 18:15 Message: Logged In: YES user_id=12800 Even if it's a good idea, we can't do this until the PSF controls the python.org domain. I don't know what the status of that is, but I believe a transfer is in the works. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=816628&group_id=5470 From noreply at sourceforge.net Thu Jan 1 11:28:37 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 1 11:28:39 2004 Subject: [ python-Bugs-868845 ] Need unit tests for <...> reprs Message-ID: Bugs item #868845, was opened at 2004-01-01 11:28 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=868845&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Nobody/Anonymous (nobody) Summary: Need unit tests for <...> reprs Initial Comment: Samuele Pedroni points out in python-dev that the <...> style reprs of Python objects are not documented, standardized or even consistent (e.g. compare old-style and new-style classes). Yet there is plenty of code out there that for various reasons parses these things or a least depends on what they look like (the parrot benchmark being only the latest example). So it would behoove us to standardize these. An easy way would be unit tests. Any takers? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=868845&group_id=5470 From noreply at sourceforge.net Thu Jan 1 12:30:32 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 1 12:30:35 2004 Subject: [ python-Bugs-868864 ] 8-bit string literal with is8859 coding => crash Message-ID: Bugs item #868864, was opened at 2004-01-01 09:30 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=868864&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: L. Peter Deutsch (lpd) Assigned to: Nobody/Anonymous (nobody) Summary: 8-bit string literal with is8859 coding => crash Initial Comment: Environment: Python 2.3.3, built from unmodified out-of-the-tarball sources (./configure, make, make install) Red Hat Linux 7.3, SMP build from source (2 Athlon CPUs) Symptom: python out.py Segmentation fault ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=868864&group_id=5470 From noreply at sourceforge.net Thu Jan 1 12:32:28 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 1 12:32:36 2004 Subject: [ python-Bugs-868864 ] 8-bit string literal with is8859 coding => crash Message-ID: Bugs item #868864, was opened at 2004-01-01 09:30 Message generated for change (Comment added) made by lpd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=868864&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: L. Peter Deutsch (lpd) Assigned to: Nobody/Anonymous (nobody) >Summary: 8-bit string literal with is8859 coding => crash Initial Comment: Environment: Python 2.3.3, built from unmodified out-of-the-tarball sources (./configure, make, make install) Red Hat Linux 7.3, SMP build from source (2 Athlon CPUs) Symptom: python out.py Segmentation fault ---------------------------------------------------------------------- >Comment By: L. Peter Deutsch (lpd) Date: 2004-01-01 09:32 Message: Logged In: YES user_id=8861 'make test' ran with no problems. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=868864&group_id=5470 From noreply at sourceforge.net Thu Jan 1 12:41:47 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 1 12:41:52 2004 Subject: [ python-Bugs-868864 ] 8-bit string literal with iso8859 coding => crash Message-ID: Bugs item #868864, was opened at 2004-01-01 09:30 Message generated for change (Settings changed) made by lpd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=868864&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: L. Peter Deutsch (lpd) Assigned to: Nobody/Anonymous (nobody) >Summary: 8-bit string literal with iso8859 coding => crash Initial Comment: Environment: Python 2.3.3, built from unmodified out-of-the-tarball sources (./configure, make, make install) Red Hat Linux 7.3, SMP build from source (2 Athlon CPUs) Symptom: python out.py Segmentation fault ---------------------------------------------------------------------- Comment By: L. Peter Deutsch (lpd) Date: 2004-01-01 09:32 Message: Logged In: YES user_id=8861 'make test' ran with no problems. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=868864&group_id=5470 From noreply at sourceforge.net Thu Jan 1 13:44:03 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 1 13:44:08 2004 Subject: [ python-Bugs-833957 ] Ctrl+key combos stop working in IDLE Message-ID: Bugs item #833957, was opened at 2003-10-31 19:27 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=833957&group_id=5470 Category: IDLE Group: None Status: Open Resolution: None Priority: 5 Submitted By: Kirby Urner (urnerk) Assigned to: Kurt B. Kaiser (kbk) Summary: Ctrl+key combos stop working in IDLE Initial Comment: After awhile using Python 2.3 IDLE in Windows, the control keys such as Ctrl+C (copy) and Ctrl+V (paste) stop having any effect. Menu pulldowns continue to work. I have yet to notice what circumstances might trigger this behavior. ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2004-01-01 13:44 Message: Logged In: YES user_id=149084 By any chance did NumLk get switched on? I've heard that can cause problems. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-01-01 02:30 Message: Logged In: YES user_id=80475 FWIW, I've had this happen also. Unfortunately, I usually have so much going on that I haven't been able to relate it to a specific cause. ---------------------------------------------------------------------- Comment By: Kirby Urner (urnerk) Date: 2003-11-17 11:04 Message: Logged In: YES user_id=191709 I'm using WinXP Pro. Given this has not previously been reported, I will do my best to gather data on your questions as I continue to use IDLE. Ideally, I will be able to duplicate it at will. We shall see. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-11-16 23:56 Message: Logged In: YES user_id=149084 I haven't observed this behavior, nor heard of it before. What version of Windows are you using? The keybindings are established in Tk just after IDLE starts and are subsequently intercepted and handled by the Tk library. Do all the Ctrl bindings fail? Even Tk defaults like Ctrl-E, which goes to end of line? What about Alt bindings? Do the Ctrl keys work in other applications after they stop working in IDLE? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=833957&group_id=5470 From noreply at sourceforge.net Thu Jan 1 14:00:53 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 1 14:00:56 2004 Subject: [ python-Bugs-868896 ] Miscellaneous problems with GC in 2.3.3 Message-ID: Bugs item #868896, was opened at 2004-01-01 19:00 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=868896&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: washington irving (washirv) Assigned to: Nobody/Anonymous (nobody) Summary: Miscellaneous problems with GC in 2.3.3 Initial Comment: Hi. We're running a multithreaded application that spiders some web pages, and parses them. We've had 2 types of problems: one where we have the python process segfault. Another where python spins in an infinite loop. We are running on FreeBSD 4.8-RELEASE. We have not had this problem with 2.2. We have this problem with both 2.3.2 and 2.3.3. This is repeatable, and we're willing to help in every way to fix this. I've attached the gdb stack trace for the process that segfaulted, and the process that spins in an infinte loop. We attached to it in gdb and ctrl-c'ed to check the status. There are 2 separate gdb traces in the attached file. Thanks ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=868896&group_id=5470 From noreply at sourceforge.net Thu Jan 1 14:04:40 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 1 14:04:43 2004 Subject: [ python-Bugs-868896 ] Multiple problems with GC in 2.3.3 Message-ID: Bugs item #868896, was opened at 2004-01-01 19:00 Message generated for change (Settings changed) made by washirv You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=868896&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: washington irving (washirv) Assigned to: Nobody/Anonymous (nobody) >Summary: Multiple problems with GC in 2.3.3 Initial Comment: Hi. We're running a multithreaded application that spiders some web pages, and parses them. We've had 2 types of problems: one where we have the python process segfault. Another where python spins in an infinite loop. We are running on FreeBSD 4.8-RELEASE. We have not had this problem with 2.2. We have this problem with both 2.3.2 and 2.3.3. This is repeatable, and we're willing to help in every way to fix this. I've attached the gdb stack trace for the process that segfaulted, and the process that spins in an infinte loop. We attached to it in gdb and ctrl-c'ed to check the status. There are 2 separate gdb traces in the attached file. Thanks ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=868896&group_id=5470 From noreply at sourceforge.net Thu Jan 1 14:14:33 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 1 14:14:35 2004 Subject: [ python-Bugs-868896 ] Multiple problems with GC in 2.3.3 Message-ID: Bugs item #868896, was opened at 2004-01-01 14:00 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=868896&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: washington irving (washirv) Assigned to: Nobody/Anonymous (nobody) Summary: Multiple problems with GC in 2.3.3 Initial Comment: Hi. We're running a multithreaded application that spiders some web pages, and parses them. We've had 2 types of problems: one where we have the python process segfault. Another where python spins in an infinite loop. We are running on FreeBSD 4.8-RELEASE. We have not had this problem with 2.2. We have this problem with both 2.3.2 and 2.3.3. This is repeatable, and we're willing to help in every way to fix this. I've attached the gdb stack trace for the process that segfaulted, and the process that spins in an infinte loop. We attached to it in gdb and ctrl-c'ed to check the status. There are 2 separate gdb traces in the attached file. Thanks ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2004-01-01 14:14 Message: Logged In: YES user_id=33168 Have you tried building python --with-pydebug? That may lead to an assert or some other indication of the problem. Do you have a test case to reproduce this problem? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=868896&group_id=5470 From noreply at sourceforge.net Thu Jan 1 14:16:53 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 1 14:16:58 2004 Subject: [ python-Feature Requests-694339 ] Dedenting with Shift+Tab Message-ID: Feature Requests item #694339, was opened at 2003-02-27 09:08 Message generated for change (Comment added) made by kamek You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=694339&group_id=5470 Category: IDLE Group: None Status: Open Resolution: None Priority: 5 Submitted By: Daniel (kamek) Assigned to: Kurt B. Kaiser (kbk) Summary: Dedenting with Shift+Tab Initial Comment: IDLE already provides quick block indenting, by selecting one or more lines and pressing Tab. So, it would make sense to have Shift+Tab to do the opposite work. While there's already Alt+[ (and Alt+] to indent), Shift+Tab is more intuitive, especially to those who are used to other Windows developer tools, like Visual Studio or TextPad. ---------------------------------------------------------------------- >Comment By: Daniel (kamek) Date: 2004-01-01 15:16 Message: Logged In: YES user_id=539453 This can be considered solved in the newest IDLE versions, as you can set custom shortcuts. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-19 21:20 Message: Logged In: YES user_id=80475 While you get used to it quickly, I've bumped in to this also. It is nice to have the control keys work the same across applications. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=694339&group_id=5470 From noreply at sourceforge.net Thu Jan 1 14:31:49 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 1 14:31:54 2004 Subject: [ python-Bugs-868896 ] Multiple problems with GC in 2.3.3 Message-ID: Bugs item #868896, was opened at 2004-01-01 14:00 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=868896&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: washington irving (washirv) Assigned to: Nobody/Anonymous (nobody) Summary: Multiple problems with GC in 2.3.3 Initial Comment: Hi. We're running a multithreaded application that spiders some web pages, and parses them. We've had 2 types of problems: one where we have the python process segfault. Another where python spins in an infinite loop. We are running on FreeBSD 4.8-RELEASE. We have not had this problem with 2.2. We have this problem with both 2.3.2 and 2.3.3. This is repeatable, and we're willing to help in every way to fix this. I've attached the gdb stack trace for the process that segfaulted, and the process that spins in an infinte loop. We attached to it in gdb and ctrl-c'ed to check the status. There are 2 separate gdb traces in the attached file. Thanks ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2004-01-01 14:31 Message: Logged In: YES user_id=31435 Are you using the pycurl extension module? If so, you should report your problems to the pycurl project too. I don't know whether the problem *is* in pycurl, but the only reports of this type ever seen before have come from people using pycurl. If you're not using pycurl, it would be good to know that too. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2004-01-01 14:14 Message: Logged In: YES user_id=33168 Have you tried building python --with-pydebug? That may lead to an assert or some other indication of the problem. Do you have a test case to reproduce this problem? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=868896&group_id=5470 From noreply at sourceforge.net Thu Jan 1 14:53:04 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 1 14:53:20 2004 Subject: [ python-Bugs-868864 ] 8-bit string literal with iso8859 coding => crash Message-ID: Bugs item #868864, was opened at 2004-01-01 12:30 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=868864&group_id=5470 >Category: Parser/Compiler Group: None Status: Open Resolution: None Priority: 5 Submitted By: L. Peter Deutsch (lpd) >Assigned to: Martin v. L?wis (loewis) Summary: 8-bit string literal with iso8859 coding => crash Initial Comment: Environment: Python 2.3.3, built from unmodified out-of-the-tarball sources (./configure, make, make install) Red Hat Linux 7.3, SMP build from source (2 Athlon CPUs) Symptom: python out.py Segmentation fault ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2004-01-01 14:53 Message: Logged In: YES user_id=33168 Looks like there may be an off-by-1 error in the implementation of PEP263. Attached is a valgrind report. Martin, do you have any ideas? ---------------------------------------------------------------------- Comment By: L. Peter Deutsch (lpd) Date: 2004-01-01 12:32 Message: Logged In: YES user_id=8861 'make test' ran with no problems. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=868864&group_id=5470 From noreply at sourceforge.net Thu Jan 1 15:01:50 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 1 15:01:53 2004 Subject: [ python-Feature Requests-868908 ] getpos() for sgmllib Message-ID: Feature Requests item #868908, was opened at 2004-01-01 21:01 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=868908&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dan Wiklund (d98dzone) Assigned to: Nobody/Anonymous (nobody) Summary: getpos() for sgmllib Initial Comment: Placed here instead of in Bugs since it really isn't a bug. During the process of making my masters thesis I discovered the need for a working getpos() in sgmllib.py. As it is now you can successfully call it since it is inherited from markupbase.py but you will always get the answer (1,0) since it is never updated. To fix this one needs to change the goahead function. This is my own implementation of this change, in part influenced by the "sister" goahead-function in HTLMParser.py: ************************************ def goahead(self, end): rawdata = self.rawdata i = 0 k = 0 n = len(rawdata) tmp=0 while i < n: if self.nomoretags: self.handle_data(rawdata[i:n]) i = n break match = interesting.search(rawdata, i) if match: j = match.start() else: j = n if i < j: self.handle_data(rawdata[i:j]) tmp = self.updatepos(i, j) i = j if i == n: break startswith = rawdata.startswith if rawdata[i] == '<': if starttagopen.match(rawdata, i): if self.literal: self.handle_data(rawdata[i]) tmp = self.updatepos(i, i+1) i = i+1 continue k = self.parse_starttag(i) if k < 0: break tmp = self.updatepos(i, k) i = k continue if rawdata.startswith(" (i + 1): self.handle_data("<") i = i+1 tmp = self.updatepos(i, k) else: # incomplete break continue if rawdata.startswith(" 7 bcdreg.multiply(1000) --> 97000 None of this is for the mainstream user and it would be unlikely to ever be included in the standard library. The best approach would be to experiment with an API in pure python, perhaps publish it as a recipe, and if it is well received, put a C version on the vaults of parnassus. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=887237&group_id=5470 From noreply at sourceforge.net Thu Jan 29 19:42:23 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 29 19:42:42 2004 Subject: [ python-Feature Requests-882171 ] Enable command line exit in IDLE. Message-ID: Feature Requests item #882171, was opened at 2004-01-22 10:16 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=882171&group_id=5470 Category: IDLE Group: None Status: Open Resolution: None >Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Guido van Rossum (gvanrossum) Summary: Enable command line exit in IDLE. Initial Comment: Currently, typing 'exit' in the interactive shell produces the message, "Use File/Exit or your end-of-file key to quit IDLE". It would be nice if it actually quit instead of telling you another way to do it. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-01-29 19:42 Message: Logged In: YES user_id=80475 In those days, we didn't have color monitors, mouse pads, or expect that our code would still be running when our hair turned gray. I'm bumping this one back up to five because improving the user experience ought to be a priority for us. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2004-01-22 11:57 Message: Logged In: YES user_id=149084 Currently, typing 'exit' in the Python interactive shell produces Python 2.4a0 (#64, Jan 22 2004, 00:54:11) [GCC 2.95.3 20010125 (prerelease, propolice)] on openbsd3 Type "help", "copyright", "credits" or "license" for more information. >>> exit 'Use Ctrl-D (i.e. EOF) to exit.' >>> It would be nice...etc. I don't know why Guido chose to do this. IDLE's shell tries to mimic the Python shell. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=882171&group_id=5470 From noreply at sourceforge.net Thu Jan 29 21:23:51 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 29 21:23:56 2004 Subject: [ python-Bugs-883604 ] locale specific problem in test_strftime.py Message-ID: Bugs item #883604, was opened at 2004-01-24 05:21 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=883604&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: George Yoshida (quiver) Assigned to: Nobody/Anonymous (nobody) Summary: locale specific problem in test_strftime.py Initial Comment: test/test_strftime.py compares an expectation and a result by regular expressions, but the pattern isn't escaped. So if the expectation includes a metacharacter, expectation == result and re.match(expectation, result) do not always return the same value. In my case on Japanese Windows, time.tzname returns ('\x93\x8c\x8b\x9e (\x95W\x8f\x80\x8e\x9e)', '\x93 \x8c\x8b\x9e (\x95W\x8f\x80\x8e\x9e)') The output contains parentheses. This resuls in a message: Conflict for nonstandard '%Z' format (time zone name): Expected ???? (?W????), but got ???? (?W????) re.match(foo, bar) != (foo == bar) One workaround I can think of is changing re.match(e [1], result) back to result == e[1]. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2004-01-29 18:23 Message: Logged In: YES user_id=357491 That's not what I meant by the comment; sorry for not being clearer. I meant is whether test_strftime's existence is because of Jython. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2004-01-29 03:54 Message: Logged In: YES user_id=671362 > Is this for Jython or something? No, it's Python 2.3.3 on Windows 2000. time zone is classified as non standard(unpredictable) so it might be difficult to make test_stftime.py to support all locales. There are so many issues. FYI, I checked time.tzname on other platforms. # Jython Jython 2.1 on java1.4.2 (JIT: null) Type "copyright", "credits" or "license" for more information. >>> import time >>> time.tzname ('JST', 'JST') # Japanese Standard Time # Linux On RHL 9.0(Python 2.2/2.3), time.tzname returns ('JST', 'JST'). They pass the test. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-01-27 00:28 Message: Logged In: YES user_id=357491 Does anyone know why we even have test_strftime? It isn't like we have our own implementation and there are basic tests in test_time to make sure the wrapper around the C function works. I know the test module says it is for sanity checks, but if it fails legitimately on a platform there is not much we can do about it. Is this for Jython or something? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=883604&group_id=5470 From noreply at sourceforge.net Fri Jan 30 09:08:05 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jan 30 09:08:11 2004 Subject: [ python-Feature Requests-887237 ] Machine integers Message-ID: Feature Requests item #887237, was opened at 2004-01-29 20:34 Message generated for change (Comment added) made by fredrik_j You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=887237&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Fredrik Johansson (fredrik_j) Assigned to: Nobody/Anonymous (nobody) Summary: Machine integers Initial Comment: I think it'd be useful with a built-in module (I propose the name 'mint' :), providing classes for emulating machine ints. There should be support for ints of different sizes (at least 8, 16, 32, 64), signedness and endianness. The machine ints would react to overflow (negative values) and bit-level operations in the same way their C equivalents would. One idea for a feature would be a intobj.pack() (or str() or whatever) method that could be used instead of the struct module's pack(). int16(12345).pack() -> "\x30\x39". int32(-1).pack() -> "\0xff\0xff\0xff\0xff", etc. A related idea is that these ints could provide slicing to extract individual sets of bits or bytes. For example, uint32()[8:16] could return an int (uint8?) made from the bits in the int's second byte (whether it's the second from the left or the right might be fuzzy, I do realize). Applications for this would be algorithmic code involving bit fiddling (useful for cryptographic applications, perhaps) and, obviously, programs that have to operate on any binary data. It might also resolve some issues related to the unification of longs and ints. ---------------------------------------------------------------------- >Comment By: Fredrik Johansson (fredrik_j) Date: 2004-01-30 14:08 Message: Logged In: YES user_id=756835 As for mainstream uses, I think replacing struct.pack would be one. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-01-30 00:35 Message: Logged In: YES user_id=80475 FTI, there was a related feature request, www.python.org/sf/846568 for treating numbers as bitarrays. As proposed, it was invalid because numbers in Python are immutable (no bit assignments allowed). That could be combined with this idea generic numeric register class that optionally specifies size (if bound), base, endianess, etc. bcdreg = register(places=5, base=10) bcdreg.assign(697) bcdreg[-1] --> 7 bcdreg.multiply(1000) --> 97000 None of this is for the mainstream user and it would be unlikely to ever be included in the standard library. The best approach would be to experiment with an API in pure python, perhaps publish it as a recipe, and if it is well received, put a C version on the vaults of parnassus. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=887237&group_id=5470 From noreply at sourceforge.net Fri Jan 30 09:16:11 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jan 30 09:16:15 2004 Subject: [ python-Feature Requests-887237 ] Machine integers Message-ID: Feature Requests item #887237, was opened at 2004-01-29 21:34 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=887237&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Fredrik Johansson (fredrik_j) Assigned to: Nobody/Anonymous (nobody) Summary: Machine integers Initial Comment: I think it'd be useful with a built-in module (I propose the name 'mint' :), providing classes for emulating machine ints. There should be support for ints of different sizes (at least 8, 16, 32, 64), signedness and endianness. The machine ints would react to overflow (negative values) and bit-level operations in the same way their C equivalents would. One idea for a feature would be a intobj.pack() (or str() or whatever) method that could be used instead of the struct module's pack(). int16(12345).pack() -> "\x30\x39". int32(-1).pack() -> "\0xff\0xff\0xff\0xff", etc. A related idea is that these ints could provide slicing to extract individual sets of bits or bytes. For example, uint32()[8:16] could return an int (uint8?) made from the bits in the int's second byte (whether it's the second from the left or the right might be fuzzy, I do realize). Applications for this would be algorithmic code involving bit fiddling (useful for cryptographic applications, perhaps) and, obviously, programs that have to operate on any binary data. It might also resolve some issues related to the unification of longs and ints. ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2004-01-30 15:16 Message: Logged In: YES user_id=11105 You might look at the ctypes module (google for it) - it implements mutable C compatible data types. ---------------------------------------------------------------------- Comment By: Fredrik Johansson (fredrik_j) Date: 2004-01-30 15:08 Message: Logged In: YES user_id=756835 As for mainstream uses, I think replacing struct.pack would be one. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-01-30 01:35 Message: Logged In: YES user_id=80475 FTI, there was a related feature request, www.python.org/sf/846568 for treating numbers as bitarrays. As proposed, it was invalid because numbers in Python are immutable (no bit assignments allowed). That could be combined with this idea generic numeric register class that optionally specifies size (if bound), base, endianess, etc. bcdreg = register(places=5, base=10) bcdreg.assign(697) bcdreg[-1] --> 7 bcdreg.multiply(1000) --> 97000 None of this is for the mainstream user and it would be unlikely to ever be included in the standard library. The best approach would be to experiment with an API in pure python, perhaps publish it as a recipe, and if it is well received, put a C version on the vaults of parnassus. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=887237&group_id=5470 From noreply at sourceforge.net Fri Jan 30 14:20:29 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jan 30 14:21:25 2004 Subject: [ python-Feature Requests-882171 ] Enable command line exit in IDLE. Message-ID: Feature Requests item #882171, was opened at 2004-01-22 10:16 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=882171&group_id=5470 Category: IDLE Group: None Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Guido van Rossum (gvanrossum) Summary: Enable command line exit in IDLE. Initial Comment: Currently, typing 'exit' in the interactive shell produces the message, "Use File/Exit or your end-of-file key to quit IDLE". It would be nice if it actually quit instead of telling you another way to do it. ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2004-01-30 14:20 Message: Logged In: YES user_id=149084 We have three ways to leave IDLE: File/Exit, the accelerator key associated with that, and ctrl-D/-Z. Typing "quit" or "exit" at the shell prompt gives the user a hint on how to leave the shell the Pythonic way, and that's different on various platforms. I'm -1 on this since IMO the IDLE shell should educate users on how to use command line Python. GvR has the decision. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-01-29 19:42 Message: Logged In: YES user_id=80475 In those days, we didn't have color monitors, mouse pads, or expect that our code would still be running when our hair turned gray. I'm bumping this one back up to five because improving the user experience ought to be a priority for us. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2004-01-22 11:57 Message: Logged In: YES user_id=149084 Currently, typing 'exit' in the Python interactive shell produces Python 2.4a0 (#64, Jan 22 2004, 00:54:11) [GCC 2.95.3 20010125 (prerelease, propolice)] on openbsd3 Type "help", "copyright", "credits" or "license" for more information. >>> exit 'Use Ctrl-D (i.e. EOF) to exit.' >>> It would be nice...etc. I don't know why Guido chose to do this. IDLE's shell tries to mimic the Python shell. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=882171&group_id=5470 From noreply at sourceforge.net Fri Jan 30 18:50:45 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jan 30 18:51:03 2004 Subject: [ python-Feature Requests-882171 ] Enable command line exit in IDLE. Message-ID: Feature Requests item #882171, was opened at 2004-01-22 10:16 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=882171&group_id=5470 Category: IDLE Group: None Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) >Assigned to: Raymond Hettinger (rhettinger) Summary: Enable command line exit in IDLE. Initial Comment: Currently, typing 'exit' in the interactive shell produces the message, "Use File/Exit or your end-of-file key to quit IDLE". It would be nice if it actually quit instead of telling you another way to do it. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2004-01-30 18:50 Message: Logged In: YES user_id=6380 You have two choices. (1) typing exit or quit raises a NameError exception. (2) typing exit ot quit prints the error message that it currently prints. Pick the one that is least confusing. Having exit or quit actually cause IDLE to exit is not an option. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2004-01-30 14:20 Message: Logged In: YES user_id=149084 We have three ways to leave IDLE: File/Exit, the accelerator key associated with that, and ctrl-D/-Z. Typing "quit" or "exit" at the shell prompt gives the user a hint on how to leave the shell the Pythonic way, and that's different on various platforms. I'm -1 on this since IMO the IDLE shell should educate users on how to use command line Python. GvR has the decision. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-01-29 19:42 Message: Logged In: YES user_id=80475 In those days, we didn't have color monitors, mouse pads, or expect that our code would still be running when our hair turned gray. I'm bumping this one back up to five because improving the user experience ought to be a priority for us. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2004-01-22 11:57 Message: Logged In: YES user_id=149084 Currently, typing 'exit' in the Python interactive shell produces Python 2.4a0 (#64, Jan 22 2004, 00:54:11) [GCC 2.95.3 20010125 (prerelease, propolice)] on openbsd3 Type "help", "copyright", "credits" or "license" for more information. >>> exit 'Use Ctrl-D (i.e. EOF) to exit.' >>> It would be nice...etc. I don't know why Guido chose to do this. IDLE's shell tries to mimic the Python shell. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=882171&group_id=5470 From noreply at sourceforge.net Fri Jan 30 19:42:27 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jan 30 19:42:30 2004 Subject: [ python-Bugs-887946 ] segfault if redirecting directory Message-ID: Bugs item #887946, was opened at 2004-01-31 00:42 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=887946&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Inyeol Lee (inyeol) Assigned to: Nobody/Anonymous (nobody) Summary: segfault if redirecting directory Initial Comment: If redirecting directory, python crashes. $ uname -a SunOS xxxxx 5.8 Generic_108528-18 sun4u sparc SUNW,Sun-Blade-1000 $ python Python 2.3.2 (#1, Oct 9 2003, 18:59:04) [GCC 2.95.3 20010315 (release)] on sunos5 Type "help", "copyright", "credits" or "license" for more information. >>> ^D $ mkdir foo $ ls -F foo/ $ python < foo Segmentation Fault -Inyeol Lee ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=887946&group_id=5470 From noreply at sourceforge.net Fri Jan 30 23:43:29 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jan 30 23:43:36 2004 Subject: [ python-Feature Requests-882171 ] Enable command line exit in IDLE. Message-ID: Feature Requests item #882171, was opened at 2004-01-22 10:16 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=882171&group_id=5470 Category: IDLE Group: None >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Raymond Hettinger (rhettinger) Summary: Enable command line exit in IDLE. Initial Comment: Currently, typing 'exit' in the interactive shell produces the message, "Use File/Exit or your end-of-file key to quit IDLE". It would be nice if it actually quit instead of telling you another way to do it. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2004-01-30 18:50 Message: Logged In: YES user_id=6380 You have two choices. (1) typing exit or quit raises a NameError exception. (2) typing exit ot quit prints the error message that it currently prints. Pick the one that is least confusing. Having exit or quit actually cause IDLE to exit is not an option. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2004-01-30 14:20 Message: Logged In: YES user_id=149084 We have three ways to leave IDLE: File/Exit, the accelerator key associated with that, and ctrl-D/-Z. Typing "quit" or "exit" at the shell prompt gives the user a hint on how to leave the shell the Pythonic way, and that's different on various platforms. I'm -1 on this since IMO the IDLE shell should educate users on how to use command line Python. GvR has the decision. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-01-29 19:42 Message: Logged In: YES user_id=80475 In those days, we didn't have color monitors, mouse pads, or expect that our code would still be running when our hair turned gray. I'm bumping this one back up to five because improving the user experience ought to be a priority for us. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2004-01-22 11:57 Message: Logged In: YES user_id=149084 Currently, typing 'exit' in the Python interactive shell produces Python 2.4a0 (#64, Jan 22 2004, 00:54:11) [GCC 2.95.3 20010125 (prerelease, propolice)] on openbsd3 Type "help", "copyright", "credits" or "license" for more information. >>> exit 'Use Ctrl-D (i.e. EOF) to exit.' >>> It would be nice...etc. I don't know why Guido chose to do this. IDLE's shell tries to mimic the Python shell. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=882171&group_id=5470 From noreply at sourceforge.net Fri Jan 30 23:48:38 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jan 30 23:48:44 2004 Subject: [ python-Bugs-867556 ] latex2html convert bug Message-ID: Bugs item #867556, was opened at 2003-12-30 18:15 Message generated for change (Settings changed) made by quiver You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=867556&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None >Priority: 3 Submitted By: George Yoshida (quiver) Assigned to: Nobody/Anonymous (nobody) >Summary: latex2html convert bug Initial Comment: The document of mailbox has an odd hyperlink. http://www.python.org/doc/current/lib/module- mailbox.html For more information, see Unix: Why the Content- Length Format is Bad" >Configuring Netscape Mail on Unix: Why the Content-Length Format is Bad. The site title is duplicated and includes a '>'. The link should look like this: For more information, see Configuring Netscape Mail on Unix: Why the Content-Length Format is Bad. Probably UNIX in libmailbox.tex causes the problem and fails to convert to a valid html markup. In Python 2.2, I can't see this bug. http://www.python.org/doc/2.2.3/lib/module- mailbox.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=867556&group_id=5470 From noreply at sourceforge.net Sat Jan 31 13:58:24 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 31 13:58:29 2004 Subject: [ python-Bugs-751279 ] cPickle doesn't raise error, pickle does (UnpicklingError) Message-ID: Bugs item #751279, was opened at 2003-06-09 13:21 Message generated for change (Settings changed) made by irmen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=751279&group_id=5470 Category: None Group: Python 2.2.3 >Status: Deleted Resolution: None Priority: 5 Submitted By: Irmen de Jong (irmen) Assigned to: Nobody/Anonymous (nobody) Summary: cPickle doesn't raise error, pickle does (UnpicklingError) Initial Comment: I have this object with a __getinitargs__ method. When I try to unpickle it using pickle, it raises an UnpicklingError: not safe for unpickling. When unpickling with cPickle, everything appears to work (no error is raised). Tested on Python 2.2.3. This issue doesn't appear on Python 2.3b1. The output of the attached test script is: ***pickle*** Creating t... Pickle t... Restore t... FAIL!!! __main__.Thing is not safe for unpickling ***cPickle*** Creating t... Pickle t... Restore t... SUCCESS!!! name= myname ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=751279&group_id=5470