At 06:43 PM 1/21/2007 -0800, Brett Cannon wrote:
>But when something as obvious as moving
>the traceback to exceptions presents itself and it means that another
>way becomes antiquated we should take the chance to ditch the old way
>so we don't have this weird situation of supporting both and old w
On 1/22/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 06:43 PM 1/21/2007 -0800, Brett Cannon wrote:
> >But when something as obvious as moving
> >the traceback to exceptions ... should take the chance to ditch the old way
> How will this affect the __exit__ signature for context managers, whi
At 10:44 AM 1/22/2007 -0500, Jim Jewett wrote:
>On 1/22/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
>>At 06:43 PM 1/21/2007 -0800, Brett Cannon wrote:
>> >But when something as obvious as moving
>> >the traceback to exceptions ... should take the chance to ditch the old way
>
>>How will this affe
On 1/22/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> On 1/22/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> > At 06:43 PM 1/21/2007 -0800, Brett Cannon wrote:
> > >But when something as obvious as moving
> > >the traceback to exceptions ... should take the chance to ditch the old way
>
> > How will
On 1/22/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 06:43 PM 1/21/2007 -0800, Brett Cannon wrote:
> >But when something as obvious as moving
> >the traceback to exceptions presents itself and it means that another
> >way becomes antiquated we should take the chance to ditch the old way
> >so
with all the talk about enhancing exceptions and removing unnecessary
functions from the codebase, i think we can also drop
PyErr_NormalizeException and friends.
after all, since string exceptions are out, BDFL has mentioned
he prefered "raise Foo()" instead of "raise Foo" [1], and since the
trace
On 1/22/07, tomer filiba <[EMAIL PROTECTED]> wrote:
> with all the talk about enhancing exceptions and removing unnecessary
> functions from the codebase, i think we can also drop
> PyErr_NormalizeException and friends.
One argument in favor of keeping PyErr_NormalizeException() (as I've
learned f
On 1/12/07, Steven Bethard <[EMAIL PROTECTED]> wrote:
On 1/12/07, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> It's worth spending time thinking about how we can help ease the
> transition for each. There may be more thing too. I wonder if it
> doesn't make sense for all 3xxx PEPs to include a dis
On 1/22/07, Collin Winter <[EMAIL PROTECTED]> wrote:
> On 1/22/07, tomer filiba <[EMAIL PROTECTED]> wrote:
> > with all the talk about enhancing exceptions and removing unnecessary
> > functions from the codebase, i think we can also drop
> > PyErr_NormalizeException and friends.
>
> One argument i
On 1/22/07, Collin Winter <[EMAIL PROTECTED]> wrote:
> On 1/12/07, Steven Bethard <[EMAIL PROTECTED]> wrote:
> > On 1/12/07, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> > > It's worth spending time thinking about how we can help ease the
> > > transition for each. There may be more thing too. I won
On 1/22/07, Brett Cannon <[EMAIL PROTECTED]> wrote:
For the exception PEP:
"In addition, Python 3 will introduce a further incompatibility."
You have not even mentioned a Py3K incompatibility yet so this
statement is awkward.
This sentence has been cut.
"This PEP intends to resolve this issu
At 03:10 PM 1/22/2007 -0600, Collin Winter wrote:
>Is there a reason why these API could not be defined in terms of a
>single exception object? In Python 3, all the information from a
>sys.exc_info() tuple available from an exception instance: (type(e),
>e, e.__traceback__)
>
>As for documentation
At 04:45 PM 1/22/2007 -0600, Collin Winter wrote:
>On 1/12/07, Steven Bethard <[EMAIL PROTECTED]> wrote:
>>On 1/12/07, Barry Warsaw <[EMAIL PROTECTED]> wrote:
>> > It's worth spending time thinking about how we can help ease the
>> > transition for each. There may be more thing too. I wonder if i
"Phillip J. Eby" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| Um, you're not taking 2.6 into consideration here. Remember that there
has
| to be a way to spell all these APIs in 2.6 that will still work in 3.0.
| IMO, this seems sufficient reason to keep sys.exc_info() around,
14 matches
Mail list logo