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
?!ng: Well, i should refine that a bit to say that the Lisp macro system
is a little more specific. Whereas AST transformations in Python
are open-ended (you could generate any result you want), the key
interesting property of Lisp macros is that they are constrained
to be safe, in the sense
Raymond writes:
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:
I'm speaking up with some trepidation here, since I am NOT one of those
who frequently closes bugs. But I think that at least
Looking at bug #1209880, the following function from threadmodule.c is
referenced. I think the args==NULL case, which can return None
instead of a Boolean value, can never be reached because
PyArg_ParseTuple() will fail if args==NULL.
Before ripping the args==NULL code out, I wanted to be sure
I've seen some systems that solve this problem by allowing users to
vote
for favorite bugs... then you can tell the important bugs because
they
are more likely to have lots of votes. As I see it, Facundo is using a
variant of that system. He is asking whether there is *ONE PERSON* out
there
Raymond Hettinger wrote:
I've seen some systems that solve this problem by allowing users to
vote
for favorite bugs... then you can tell the important bugs because
they
are more likely to have lots of votes. As I see it, Facundo is using a
variant of that system. He is asking whether there
On 6/2/05, A.M. Kuchling [EMAIL PROTECTED] wrote:
Looking at bug #1209880, the following function from threadmodule.c is
referenced. I think the args==NULL case, which can return None
instead of a Boolean value, can never be reached because
PyArg_ParseTuple() will fail if args==NULL.
Guido van Rossum wrote:
[Phillip J. Eby]
* 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
If you're digging into the threadmodule.c could you take a look at
bug #1163563
(http://sourceforge.net/tracker/index.php?func=detailaid=1163563group_id=5470atid=105470)
I've posted a patch
(http://sourceforge.net/tracker/index.php?
func=detailaid=1203393group_id=5470atid=305470)
Regards,
Max
[A.M. Kuchling]
Looking at bug #1209880, the following function from threadmodule.c is
referenced. I think the args==NULL case, which can return None
instead of a Boolean value, can never be reached because
PyArg_ParseTuple() will fail if args==NULL.
It would assert-fail in a debug build.
Arnold deVos wrote:
This template eats eats the exception, which will cause a RuntimeError
in the proposed Wrapper, I think. A raise after rollback is needed.
Actually, the Wrapper as written in the PEP does not raise RuntimeError
if the generator catches a block's exception.
Shouldn't the
[Arnold deVos, responding to himself]
This template eats eats the exception, which will cause a RuntimeError
in the proposed Wrapper, I think. A raise after rollback is needed.
No, the generator returns after rolling back, which causes throw() to
raise StopIteration, which is good enough for
[me]
I'll summarize this discussion in the PEP.
I've added this section to the PEP. Is anyone dead set against the
tentative resolutions here?
Open Issues
Discussion on python-dev has revealed some open issues. I list
them here, with my preferred resolution and its motivation. The
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 pretty good to
At 01:08 AM 6/3/2005 +1000, Nick Coghlan wrote:
Also, I'm wondering if it would be useful to have a 'closing' template
that looked like:
@with_template
def closing(obj):
try:
yield obj
finally:
obj.close()
+1 if you make it 'if hasattr(obj,close):
On 6/2/05, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 01:08 AM 6/3/2005 +1000, Nick Coghlan wrote:
Also, I'm wondering if it would be useful to have a 'closing' template
that looked like:
@with_template
def closing(obj):
try:
yield obj
finally:
At 09:20 AM 6/2/2005 -0700, Guido van Rossum wrote:
On 6/2/05, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 01:08 AM 6/3/2005 +1000, Nick Coghlan wrote:
Also, I'm wondering if it would be useful to have a 'closing' template
that looked like:
@with_template
def closing(obj):
Index: sre_compile.py
===
RCS file: /cvsroot/python/python/dist/src/Lib/sre_compile.py,v
retrieving revision 1.57
retrieving revision 1.58
diff -u -d -r1.57 -r1.58
--- sre_compile.py28 Feb 2005 19:27:52 - 1.57
+++
On Thu, Jun 02, 2005 at 03:34:17PM -0400, Raymond Hettinger wrote:
The times two operation also occurs twice in nearby code. Are those
also incorrect?
I believe they're correct.
EXPN: The regex engine refers to both 'groups', where group #N means
the corresponding group in the pattern, and
Phillip J. Eby wrote:
At 10:00 PM 6/1/2005 +0200, Eric Nieuwland wrote:
Phillip J. Eby wrote:
-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
At 10:04 PM 6/2/2005 +0200, Eric Nieuwland wrote:
I was thinking about 'try EXPR [as VAR]:' as a 'try' that handles uncaught
exceptions by forwarding it to EXPR's __exit__ method. No confusion with me.
No doubt. However, it's not obvious what happens to an exception in EXPR;
surely it can't be
On 2 jun 2005, at 22:12, Phillip J. Eby wrote:
At 10:04 PM 6/2/2005 +0200, Eric Nieuwland wrote:
I was thinking about 'try EXPR [as VAR]:' as a 'try' that handles
uncaught exceptions by forwarding it to EXPR's __exit__ method. No
confusion with me.
No doubt. However, it's not obvious
At 10:16 PM 6/2/2005 +0200, Eric Nieuwland wrote:
On 2 jun 2005, at 22:12, Phillip J. Eby wrote:
At 10:04 PM 6/2/2005 +0200, Eric Nieuwland wrote:
I was thinking about 'try EXPR [as VAR]:' as a 'try' that handles
uncaught exceptions by forwarding it to EXPR's __exit__ method. No
Phillip J. Eby wrote:
That's not a bug, it's a feature. If the object doesn't have a
'close()'
method, clearly it doesn't need to be closed. If it's the wrong
object
for what you're using it for in the body of the 'with' block, it'll
show up
there, so this doesn't hide any errors.
[Nick Coghlan]
Also, I'm wondering if it would be useful to have a 'closing' template
that looked like:
@with_template
def closing(obj):
try:
yield obj
finally:
obj.close()
That can be used to deterministically close anything with a close
While looking at bug #779191, I saw that sys.path's first element
is '' in interactive sessions, but the current dir otherwise. Is this
intentional?
Reinhold
--
Mail address is perfectly valid!
___
Python-Dev mailing list
Python-Dev@python.org
I've always liked it this way; using instead of . means that if
you os.path.join() it with a script name you don't get a spurious ./
prepended.
I think that the absolutizing of sys.path entries is relatively new
(seems to have started in 2.3).
Also note that it's not really the current
On Jun 2, 2005, at 4:50 PM, Guido van Rossum wrote:
On 6/2/05, Reinhold Birkenfeld reinhold-birkenfeld-
[EMAIL PROTECTED] wrote:
While looking at bug #779191, I saw that sys.path's first element
is '' in interactive sessions, but the current dir otherwise. Is this
intentional?
I've
At 05:08 PM 6/2/2005 -0700, Bob Ippolito wrote:
On Jun 2, 2005, at 4:50 PM, Guido van Rossum wrote:
I think that the absolutizing of sys.path entries is relatively new
(seems to have started in 2.3).
Also note that it's not really the current directory but the directory
containing the
Guido van Rossum wrote:
[...] a generator doing cleanup depending on the
exception thrown (like the transactional() example below) can
*catch* the exception thrown if it wants to and doesn't have to
worry about re-raising it. I find this more convenient for the
After many rounds of discussion on python-dev, I'm inviting public
comments for PEP 343. Rather than posting the entire PEP text here,
I'm inviting everyone to read it on line
(http://www.python.org/peps/pep-0343.html) and then post comments on a
Wiki page I've created for this purpose
31 matches
Mail list logo
