At 08:13 PM 3/24/2006 -0800, Guido van Rossum wrote:
>I think that the code you added:
>
>+except:
>+if sys.exc_info()[1] is not value:
>+raise
>
>could use a comment explaining what's going on;
Done.
> the difference between
>returning None and r
On 3/24/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 04:34 PM 3/24/2006 -0800, Guido van Rossum wrote:
> >You could probably tell the difference by comparing the exception it
> >raises to the exception you pass it.
>
> That's what I changed @contextmanager to do, because it's the only place
>
Chris Barker wrote:
> I'm still a tiny bit confused about the proposed individual pieces
> involved, but I'd like to see, in order of priority (and difficulty):
>
> 1) A standard n-d array interface (numpy already defines this, but
> outside of the numpy community, who knows about it?)
This is
At 04:34 PM 3/24/2006 -0800, Guido van Rossum wrote:
>You could probably tell the difference by comparing the exception it
>raises to the exception you pass it.
That's what I changed @contextmanager to do, because it's the only place
where you have a good reason to re-raise (i.e., the generator r
On 3/24/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 03:50 PM 3/24/2006 -0800, Guido van Rossum wrote:
> >I'm not against recommending in the PEP that __exit__ shouldn't
> >re-raise but instead should return False to signal a re-raise, and
> >fixing any existing code that re-raises in __exit_
At 03:58 PM 3/24/2006 -0800, Guido van Rossum wrote:
>OK, I give up. I'm giving you a -1 on the test for a non-empty
>traceback without explaining it further.
Not a problem; I just wanted to make sure you were rejecting the same thing
that I was proposing. :) I've checked in the "your way" vers
At 03:50 PM 3/24/2006 -0800, Guido van Rossum wrote:
>I'm not against recommending in the PEP that __exit__ shouldn't
>re-raise but instead should return False to signal a re-raise, and
>fixing any existing code that re-raises in __exit__. But I'm still
>questioning your use case; why is it importa
OK, I give up. I'm giving you a -1 on the test for a non-empty
traceback without explaining it further.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/list
At 03:23 PM 3/24/2006 -0800, Guido van Rossum wrote:
>And I see no reason to complicate the code with an additional check
>that doesn't serve a purpose. The purpose of reminding people not to
>write g.throw("abc") seems artificial to me. I'd rather see less code,
>meaning less maintenance, and no n
On 3/24/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 03:27 PM 3/24/2006 -0800, Guido van Rossum wrote:
> >I guess I like the ambiguity -- to the outer __exit__, it shouldn't
> >make any difference whether the exception was re-raised by the inner
> >__exit__ or by the finally clause containing
At 03:27 PM 3/24/2006 -0800, Guido van Rossum wrote:
>I guess I like the ambiguity -- to the outer __exit__, it shouldn't
>make any difference whether the exception was re-raised by the inner
>__exit__ or by the finally clause containing it. After all, if there
>*wasn't* an outer __exit__, there wo
On 3/24/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 03:05 PM 3/24/2006 -0800, Guido van Rossum wrote:
> >Oops, that's definitely a bug. Please go ahead and fix in both places.
>
> Will do.
>
>
> >(I'm still trying to fathom the other PEP 343 issue you brought up.)
>
> Here's the paragraph I'
On 3/24/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> Okay - so allow them without warning or error, even if somebody does
> 'gen.throw("abc")'?
Correct. There's no current code that does this, and I doubt that few
people will write any, so I don't see the value of trying to trap or
warn for thi
At 03:05 PM 3/24/2006 -0800, Guido van Rossum wrote:
>Oops, that's definitely a bug. Please go ahead and fix in both places.
Will do.
>(I'm still trying to fathom the other PEP 343 issue you brought up.)
Here's the paragraph I'm proposing to add to the PEP to explain that issue:
NOTE: to
At 03:06 PM 3/24/2006 -0800, Guido van Rossum wrote:
>On 3/24/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> > At 03:04 PM 3/24/2006 -0800, Guido van Rossum wrote:
> > >The current state is that it always allows them, right?
> >
> > No. It doesn't allow them. Support for string exceptions was ne
On 3/24/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 03:04 PM 3/24/2006 -0800, Guido van Rossum wrote:
> >The current state is that it always allows them, right?
>
> No. It doesn't allow them. Support for string exceptions was never
> actually implemented; I'm trying to implement it now.
O
Oops, that's definitely a bug. Please go ahead and fix in both places.
(I'm still trying to fathom the other PEP 343 issue you brought up.)
--Guido
On 3/24/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> It appears that the contextmanager implementation (both in the stdlib and
> as described in
At 03:04 PM 3/24/2006 -0800, Guido van Rossum wrote:
>The current state is that it always allows them, right?
No. It doesn't allow them. Support for string exceptions was never
actually implemented; I'm trying to implement it now.
___
Python-Dev mail
On 3/24/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 02:36 PM 3/24/2006 -0800, Guido van Rossum wrote:
> >I think it's overkill to warn for any string exceptions thrown this
> >way. Since the only use case for using throw() is to pass an exception
> >you just caught, I don't see that putting
At 02:36 PM 3/24/2006 -0800, Guido van Rossum wrote:
>I think it's overkill to warn for any string exceptions thrown this
>way. Since the only use case for using throw() is to pass an exception
>you just caught, I don't see that putting the warning is useful --
>it's just more code that in practice
It appears that the contextmanager implementation (both in the stdlib and
as described in the PEP) doesn't correctly handle the case where the
generator yields a new value in response to throw(). It responds by
suppressing the original exception, but IIRC earlier versions of the PEP
threw a Ru
On 3/24/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> Should geniter.throw() issue a deprecation warning for string exceptions?
>
> My first thought was yes, since that's what raise() does.
>
> On the other hand, one of the key motivating uses for throw() is to allow
> exception propagation on a
Should geniter.throw() issue a deprecation warning for string exceptions?
My first thought was yes, since that's what raise() does.
On the other hand, one of the key motivating uses for throw() is to allow
exception propagation on a coroutine stack. In this use case, the original
"raise" of th
I was just updating an experimental context library for the latest PEP 343
protocol, and I ran into a rather messy situation with the recently added
error-suppression feature, when used in combination with @contextmanager,
that caused some of my tests to fail.
Basically, the problem is this. T
Guido van Rossum wrote:
> On 3/24/06, Thomas Heller <[EMAIL PROTECTED]> wrote:
>> I'm astonished that our BDFL doesn't speak up on this issue. IIRC,
>> it was the (his?) plan to let the numpy community develop an interface,
>> which would then be included into Python.
>
> Where's the PEP? You don
On 3/24/06, Thomas Heller <[EMAIL PROTECTED]> wrote:
> I'm astonished that our BDFL doesn't speak up on this issue. IIRC,
> it was the (his?) plan to let the numpy community develop an interface,
> which would then be included into Python.
Where's the PEP? You don't expect me to argue the point f
Travis E. Oliphant wrote:
> Last year, during development of NumPy, the concept of the array
> interface was developed as a means to share array_like data. It was
> realized that it is this concept that needs to be explored further and
> pushed into Python itself, rather than a particular incar
On Wed, Mar 22, 2006, Uwe Mayer wrote:
>
> I am wrapping libsndfile to Python, using SWIG and don't know howto
> return a malloc()ed memory area back to Python.
Please post this question to comp.lang.python; it's not appropriate for
python-dev. Note that you're unlikely to get many useful respons
On 2006-03-22 at 20:22:58 [+0100], M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> Charlie,
>
> you might want to reply to this one...
>
> Original Message
> Subject: Re: [Python-Dev] r43214 - peps/trunk/pep-3000.txt
> Date: Wed, 22 Mar 2006 19:37:45 +0100
> From: "Martin v. Löwis"
Hi,
I am wrapping libsndfile to Python, using SWIG and don't know howto return a
malloc()ed memory area back to Python.
I've found CObjects, which would let me pass free() as cleanup function, but
I'd rather return a buffer object (PyBuffer_FromReadWriteMemory) so that I
could prevent copying
[bcc python-dev to move to python-3000]
On 3/22/06, Michael Hudson <[EMAIL PROTECTED]> wrote:
> "Fredrik Lundh" <[EMAIL PROTECTED]> writes:
>
> > neal.norwitz wrote:
> >
> >> +Outstanding Issues
> >> +==
> >> +
> >> +* Require C99, so we can use // comments, named initializers, dec
On 3/17/06, Thomas Heller python.net> wrote:
> Accessing Python arrays (Numeric arrays, Numeric array, or Numpy
> array) as ctypes arrays, and vice versa, without copying any memory,
> would be a good thing.
This does bring up a point. I was thinking that a really bare-bones
nd-array type wou
On 3/24/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> I do find it somewhat interesting that we're considering moving the standard
> containers to a more numpy-ish view of the world, though (i.e. one where
> multiple mutable views of a data structure are common in order to avoid
> unnecessary copyi
Greg Ewing wrote:
> Guido van Rossum wrote:
>
>> Its maps have methods to
>> return keys, values and items, but these return neither new lists nor
>> iterators; they return "views" which obey set (or multiset, in the
>> case of items) semantics.
>
>> I'd like to explore this as an alternative to
34 matches
Mail list logo
