> [Guido van Rossum]
>
> > I've made a final pass over PEP 352, mostly fixing the __str__,
> > __unicode__ and __repr__ methods to behave more reasonably. I'm all
> > for accepting it now. Does anybody see any last-minute show-stopping
> > problems with it?
[François]
> I did not follow the thread
[Guido van Rossum]
> I've made a final pass over PEP 352, mostly fixing the __str__,
> __unicode__ and __repr__ methods to behave more reasonably. I'm all
> for accepting it now. Does anybody see any last-minute show-stopping
> problems with it?
I did not follow the thread, so maybe I'm out in
I've made a final pass over PEP 352, mostly fixing the __str__,
__unicode__ and __repr__ methods to behave more reasonably. I'm all
for accepting it now. Does anybody see any last-minute show-stopping
problems with it?
As always, http://python.org/peps/pep-0352.html
--
--Guido van Rossum (home pa
On 10/29/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Another point in PEP 352's favour, is that it makes it far more feasible to
> implement something like PEP 344 by providing "__traceback__" and
> "__prev_exc__" attributes on BaseException.
Not sure if I'm fully in-context here, but watch out
On 10/28/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Brett Cannon wrote:
> > Interesting point, but I think that chaining should have more concrete
> > support ala PEP 344 or some other mechanism. I think most people
> > agree that exception chaining is important enough to have better
> > suppor
[Nick Coghlan]
> Another point in PEP 352's favour, is that it makes it far more
feasible
> to
> implement something like PEP 344 by providing "__traceback__" and
> "__prev_exc__" attributes on BaseException.
>
> The 'raise' statement could then take care of setting them
appropriately
> if it
> wa
Brett Cannon wrote:
> Interesting point, but I think that chaining should have more concrete
> support ala PEP 344 or some other mechanism. I think most people
> agree that exception chaining is important enough to have better
> support than some implied way of a causing exception to be passed
> a
On 10/28/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> > > Why would a
> > > release allow catching something that cannot be raised? I must be
> > > missing something here.
> >
> > So conforming code can catch exceptions raised by not-yet conforming
> code.
>
> That makes sense.
>
> What was
> > Why would a
> > release allow catching something that cannot be raised? I must be
> > missing something here.
>
> So conforming code can catch exceptions raised by not-yet conforming
code.
That makes sense.
What was the rationale for pushing the deprecation of __getitem__ and
args back to P
On 10/28/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> I don't follow why the PEP deprecates catching a category of exceptions
> in a different release than it deprecates raising them. Why would a
> release allow catching something that cannot be raised? I must be
> missing something here.
On 10/28/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> I don't follow why the PEP deprecates catching a category of exceptions
> in a different release than it deprecates raising them. Why would a
> release allow catching something that cannot be raised? I must be
> missing something here.
11 matches
Mail list logo
