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
(http://wiki
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 t
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
> > c
On Jun 2, 2005, at 4:50 PM, Guido van Rossum wrote:
> On 6/2/05, 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 always liked i
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 d
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
http://
[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
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 err
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
>
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 ob
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 b
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
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
> 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.5
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
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
> >
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,
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
[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
[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
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 th
[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.
If you're digging into the threadmodule.c could you take a look at
bug #1163563
(http://sourceforge.net/tracker/index.php?func=detail&aid=1163563&group_id=5470&atid=105470)
I've posted a patch
(http://sourceforge.net/tracker/index.php?
func=detail&aid=1203393&group_id=5470&atid=305470)
Regards,
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.co
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.
>
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 wh
> 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
>
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 my
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 somet
> ?!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
30 matches
Mail list logo
