Re: [Python-Dev] Closing old bugs
"Raymond Hettinger" <[EMAIL PROTECTED]> writes: > There should be some greater care exercised in closing old bugs. Possibly. OTOH, we have something like 900 open bugs to work on, and it's not like bug reporters can't re-open a bug report if they think it's been closed in error (this has happened a few times already, and it's a good thing, IMHO). > Marking them "deprecated" and then erasing them is only a good strategy > if we have no means of reproducing the error or ascertaining what the OP > was talking about. > > For instance, in www.python.org/sf/640553 , it was possible for a > reviewer to directly verify whether usr/local local was still being used > in setup.py. Well, that one in particular was always in the "is it really a bug?" category. > Likewise, www.python.org/sf/728515 should not have been > closed (Martin's post could have been taken as a clue that the bug was > valid and simply waiting for some volunteer to submit a patch). > > Old age and a missing OP is not sufficient reason to close a bug. But if closing a bug is an effective way of kicking things into life again... Cheers, mwh -- ARTHUR: Don't ask me how it works or I'll start to whimper. -- The Hitch-Hikers Guide to the Galaxy, Episode 11 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PEP 343 rewrite complete
I hope that I've got the rewrite of PEP 343 to include generator extensions right now. I've chosen the 'with' keyword. Please review here; I think this is ready for review by the unwashed masses. :-) http://www.python.org/peps/pep-0343.html -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 343 rewrite complete
> http://www.python.org/peps/pep-0343.html I should add that IMO this obsoletes PEP 288 and PEP 325; I plan to reject those when PEP 343 is accepted. I've already withdrawn PEP 340. PEP 342 is separate (but I'll probably present it together with PEP 343). -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 343 rewrite complete
At 08:16 AM 6/1/2005 -0700, Guido van Rossum wrote: >I hope that I've got the rewrite of PEP 343 to include generator >extensions right now. I've chosen the 'with' keyword. Please review >here; I think this is ready for review by the unwashed masses. :-) > > http://www.python.org/peps/pep-0343.html Looks great. A few questions/comments: * What's the rationale for raising TypeError from close()? Wasn't RuntimeError discussed previously for that role? (and it's also used by the with_template example) OTOH, maybe that means we want a ControlFlowError or some such that can be used for both. * The "opening" example under "Generator Decorator" seems to be missing a try/finally block. * The transaction handler could also be written as: @with_template def transactional(db): db.begin() try: yield db except: db.rollback() else: db.commit() at least, if I understand it correctly. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 343 rewrite complete
[Guido van Rossum] > > http://www.python.org/peps/pep-0343.html [Phillip J. Eby] > Looks great. A few questions/comments: > > * What's the rationale for raising TypeError from close()? Wasn't > RuntimeError discussed previously for that role? (and it's also used by > the with_template example) OTOH, maybe that means we want a > ControlFlowError or some such that can be used for both. I really don't want a new exception for this, since it's just a bug in the generator's code. I could go with RuntimeError here too, but I figured TypeError's meaning in a wider sense applies: the generator doesn't respond appropriately to the throw() call, which is similar to not handling a particular argument (list) correctly. > * The "opening" example under "Generator Decorator" seems to be missing a > try/finally block. Good catch. I've fixed this in the PEP. > * The transaction handler could also be written as: > > @with_template > def transactional(db): > db.begin() > try: > yield db > except: > db.rollback() > else: > db.commit() > > at least, if I understand it correctly. Ah, of course. I've updated the PEP. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 343 rewrite complete
Nice going! But ... Could we extend the 'try' syntax for this instead of introducing 'with'? If I look at the translation it an augmented 'try'. with EXPR as VAR: BLOCK1 except EXCEPTION: BLOCK2 could then be translated to abc = EXPR exc = (None, None, None) VAR = abc.__enter__() try: try: BLOCK1 except EXCEPTION: BLOCK2 except: exc = sys.exc_info() raise finally: abc.__exit__(*exc) Can the 'throw()' method be renamed 'raise()'? IMHO that makes much clearer what happens. Same thing with 'GeneratorExit', 'StopGeneration' more closely matches 'StopIteration'. --eric ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 343 rewrite complete
Eric Nieuwland wrote: > If I look at the translation it an augmented 'try'. > with EXPR as VAR: > BLOCK1 > except EXCEPTION: > BLOCK2 Oops, that should read: try EXPR as VAR: BLOCK1 except EXCEPTION: BLOCK2 --eric ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 343 rewrite complete
At 08:46 PM 6/1/2005 +0200, Eric Nieuwland wrote: >Nice going! But ... > >Could we extend the 'try' syntax for this instead of introducing >'with'? If I look at the translation it an augmented 'try'. > with EXPR as VAR: > BLOCK1 > except EXCEPTION: > BLOCK2 >could then be translated to -1, too confusing. >Can the 'throw()' method be renamed 'raise()'? IMHO that makes much >clearer what happens. No, 'raise' is a reserved word. It would have to be 'raise_()'. -0. >Same thing with 'GeneratorExit', 'StopGeneration' more closely matches >'StopIteration'. StopIteration is raised the *other* way, so closely matching isn't really a benefit. -1. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adventures with Decimal
> Raymond Hettinger wrote: > > IMO, user input (or > > the full numeric strings in a text data file) is sacred and presumably > > done for a reason -- the explicitly requested digits should not be > > throw-away without good reason. > > I still don't understand what's so special about the > input phase that it should be treated sacredly, while > happily desecrating the result of any *other* operation. The 'difference' here is, with unlimited precision decimal representations, there is no "input phase". The decimal number can represent the value, sign, and exponent in the character string the user provided _exactly_, and indeed it could be implemented using strings as the internal representation -- in which case the 'construction' of a new number is simply a string copy operation. There is no operation taking place as there is no narrowing necessary. This is quite unlike (for example) converting an ASCII string "1.01" to a binary floating-point double which has a fixed precision and no base-5 component. mfc ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 343 rewrite complete
Phillip J. Eby wrote: > At 08:46 PM 6/1/2005 +0200, Eric Nieuwland wrote: >> If I look at the translation it an augmented 'try'. >> with EXPR as VAR: >> BLOCK1 >> except EXCEPTION: >> BLOCK2 >> could then be translated to > > -1, too confusing. A matter of taste, I guess. IMHO 'with' secretly handling exceptions is confusing. >> Can the 'throw()' method be renamed 'raise()'? IMHO that makes much >> clearer what happens. > > No, 'raise' is a reserved word. It would have to be 'raise_()'. -0. My bad. Should have thought about that. >> Same thing with 'GeneratorExit', 'StopGeneration' more closely matches >> 'StopIteration'. > > StopIteration is raised the *other* way, so closely matching isn't > really a benefit. -1. Yep! Misread that one. --eric ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 343 rewrite complete
At 10:00 PM 6/1/2005 +0200, Eric Nieuwland wrote: >Phillip J. Eby wrote: > > At 08:46 PM 6/1/2005 +0200, Eric Nieuwland wrote: > >> If I look at the translation it an augmented 'try'. > >> with EXPR as VAR: > >> BLOCK1 > >> except EXCEPTION: > >> BLOCK2 > >> could then be translated to > > > > -1, too confusing. > >A matter of taste, I guess. IMHO 'with' secretly handling exceptions is >confusing. It doesn't secretly handle them; it simply gets access to them, which is an entirely different thing. By confusing, I mean that it is not clear from your construct what exceptions are caught by the 'except' clause, due to its structural layout. It's also not clear whether the __enter__/__exit__ of EXPR wrap BLOCK1 only, or both BLOCK1 and BLOCK2. These aspects are "confusing" because whatever decision you make about the semantics, someone will have to *remember* them, as opposed to being unambiguously represented by the block structure. By contrast, if you remove the except: clause from your construct, it is clear that BLOCK1 is what is wrapped, and there is no possible confusion about who sees what exceptions. Exceptions inside the block are communicated to __exit__, exceptions outside (including those in the 'with' statement itself) are not. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Closing old bugs
On 6/1/05, Michael Hudson <[EMAIL PROTECTED]> wrote: > > Old age and a missing OP is not sufficient reason to close a bug. > > But if closing a bug is an effective way of kicking things into life > again... I'm seeing this effect in a lot of bugs I closed as old ones. I think that using the mail-OP-and-commenters property of the SF bug tracking is a good thing here, and that that mail is enough alert to the interested people for them to reopen the bug if not closed correctly. Take note that for closing it, first there's a warning, and if in a *month* (which really happens to delay into several months, my fault) the interested people don't take care again of that bug... However, I'm not opposing myself to a change in our behaviour about this old bugs. Let's just define a new procedure (if we want to) and then I'll follow it. Thanks. .Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Weekly Python Patch/Bug Summary
Patch / Bug Summary ___ Patches : 344 open ( +2) / 2845 closed ( +6) / 3189 total ( +8) Bugs: 916 open (-20) / 5014 closed (+40) / 5930 total (+20) RFE : 191 open ( +2) / 163 closed ( +4) / 354 total ( +6) New / Reopened Patches __ Optimization for textwrap (2005-05-26) http://python.org/sf/1209527 opened by Connelly Build Python2.4.1 on AIX5 using xlc v6 (2005-05-27) http://python.org/sf/1209781 opened by Gangadhar NPK Split email headers near a space (2005-05-29) http://python.org/sf/1210680 opened by Noam Raphael Add st_flags support to (l)stat function (2005-05-31) http://python.org/sf/1212117 opened by Diego Pettenò mode argument for fileinput class (2005-05-31) http://python.org/sf/1212287 opened by Reinhold Birkenfeld Improved profiler (2005-06-01) http://python.org/sf/1212837 opened by Brett Rosen option to allow reload to affect existing instances (2005-06-01) http://python.org/sf/1212921 opened by Brett Rosen new patch for fixing skipitem() in getargs.c (2005-06-01) http://python.org/sf/1212928 opened by Reinhold Birkenfeld note that os.chown can have -1 as an argument (2005-06-01) http://python.org/sf/1213031 opened by Reinhold Birkenfeld Patches Closed __ updates for the compiler package (2005-05-21) http://python.org/sf/1206077 closed by sxanth make float packing copy bytes when they can (2005-04-12) http://python.org/sf/1181301 closed by mwh webbrowser.Netscape.open bug fix (2005-02-20) http://python.org/sf/1144816 closed by birkenfeld cgitb: make more usable for 'binary-only' software (2003-06-10) http://python.org/sf/751943 closed by birkenfeld bug skipping optional keyword arguments of type "w#" (2004-07-06) http://python.org/sf/985713 closed by birkenfeld Optional keyword unicode args not handled correctly (2003-12-04) http://python.org/sf/853890 closed by birkenfeld New / Reopened Bugs ___ urllib2's urlopen() method causes a memory leak (2005-05-25) http://python.org/sf/1208304 opened by Petr Toman no CoreGraphics library under Python 2.4 (2005-05-25) CLOSED http://python.org/sf/1208468 opened by Jurjen N.E. Bos longs should be pickled in hexadecimal (2005-05-26) CLOSED http://python.org/sf/1209324 opened by Fredrik Johansson divmod documentation shd reference // not / (2005-05-26) CLOSED http://python.org/sf/1209411 opened by Alan os.path.join() fails if 2nd arg is a UNC path (2005-05-26) http://python.org/sf/1209447 opened by John Ehresman spurious blank page in dist.pdf (2005-05-27) http://python.org/sf/1209560 opened by paul rubin dict.popitem documentation should mention empty dict case (2005-05-27) CLOSED http://python.org/sf/1209671 opened by William Chang doc bug in Lock.acquire (2005-05-27) http://python.org/sf/1209880 opened by Chris Perkins Typo in "Differences from mimelib" (2005-05-27) http://python.org/sf/1210001 opened by Zumi comma separated cookie values (2005-05-28) http://python.org/sf/1210326 opened by tvogt Cursors not correctly closed after exception. (2005-05-28) http://python.org/sf/1210377 opened by Ragnar Ouchterlony An error in Python Tutorial (2005-05-29) CLOSED http://python.org/sf/1210832 opened by Gene mmap's resize method resizes the file in win32 but not unix (2003-04-27) CLOSED http://python.org/sf/728515 reopened by facundobatista parser tells invalid syntax with correct code (2005-05-31) CLOSED http://python.org/sf/1211639 opened by ntrunk itertools.groupby ungraceful, un-Pythonic (2005-05-31) CLOSED http://python.org/sf/1212077 opened by Mike Coleman str.lower() to have an IMPORTANT NOTE or it's for magicians (2005-05-31) http://python.org/sf/1212195 opened by Nikos Kouremenos anydbm and 'n' flag (2005-05-31) CLOSED http://python.org/sf/1212223 opened by Jack Moffitt Incorrect result for regular expression - "|(hello)|(world)" (2005-06-01) http://python.org/sf/1212411 opened by Vijay Kumar Python 2.5 CVS broken for HP-UX platform? (2005-06-01) http://python.org/sf/1212703 opened by Vincent Jamart Python segfaults on OpenBSD (tested 3.4 and 3.5) (2005-06-01) http://python.org/sf/1212900 opened by Fabien Devaux Bugs Closed ___ bug in unichr() documentation (2005-02-11) http://python.org/sf/1120777 closed by fdrake Line ending documentation is misleading (2005-03-21) http://python.org/sf/1167922 closed by fdrake no CoreGraphics library under Python 2.4 (2005-05-25) http://python.org/sf/1208468 closed by mwh Issue in grammar (2005-05-24) http://python.org/sf/1207501 closed by mwh Problem with abs function (2005-05-16) http://python.org/sf/1202946 closed by rhettinger longs should be pickled
[Python-Dev] Closing old bugs
> > Old age and a missing OP is not sufficient reason to close a bug. > > > > But if closing a bug is an effective way of kicking things into life > > again... > > I'm seeing this effect in a lot of bugs I closed as old ones. That means they shouldn't have been closed and that we almost lost a valid report. Also, for the most part, "kicking to life" means getting a qualified reviewer to take time to decide an appropriate course of action. Typically, the OP is not that person. Usually, the only "kick to life" we need from an OP is clarification if their post was not sufficiently specific; otherwise, they usually shouldn't have to do anything. > Take note that for closing it, first there's a warning, and if in a > *month* (which really happens to delay into several months, my fault) > the interested people don't take care again of that bug... A better use of time is to BE one of the interested people and take care of the bug. Just closing it doesn't make the problem go away. Also, inactivity does not imply that a bug is not a recurring irritant. We encourage posters to scan existing bug reports before filing a new one. Likewise, we immediately close duplicates. If the original report then disappears without having been cleared, then we've broken our promises to the othesr who did or would have posted a more current report. The existence of an old report means the problem has been registered and is awaiting a thoughtful response. Because of the way SF is setup, the other interested people are not likely to receive your "one month warnings". Closing reports without analyzing their contents is not progress. AFAICT, that has never been our policy. Is there anyone else on python-dev who thinks it's a bad idea to automatically close reports without checking whether the issue is real? Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
