On Wed, 28 Feb 2007 18:10:21 -0800, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>I am beginning to think that there are serious problems with attaching
>the traceback to the exception; I really don't like the answer that
>pre-creating an exception is unpythonic in Py3k.
In Twisted, to deal with a
Chris AtLee schrieb:
>> I would guess it is more an issue of 32bit + 64bit dynamic linking
>> having issues, but I could certainly be wrong.
>
> I don't think so, this was the 64bit version of Python 2.5. When I
> recompiled with the 2003 compiler it worked fine.
Again, what 2003 compiler did yo
Andrew Dalke wrote:
> On 2/28/07, James Y Knight <[EMAIL PROTECTED]> wrote:
>
>> It seems to me that a stack trace should always be attached to an
>> exception object at creation time of the exception, and never at any
>> other time.
Sounds good in principle - but don't forget that normally the
On 2/28/07, James Y Knight <[EMAIL PROTECTED]> wrote:
> It seems to me that a stack trace should always be attached to an
> exception object at creation time of the exception, and never at any
> other time. Then, if someone pre-creates an exception object, they
> get consistent and easily explainab
On Feb 28, 2007, at 9:10 PM, Guido van Rossum wrote:
> I am beginning to think that there are serious problems with attaching
> the traceback to the exception; I really don't like the answer that
> pre-creating an exception is unpythonic in Py3k.
I'll say up front that I haven't been paying as muc
Patch / Bug Summary
___
Patches : 416 open ( +8) / 3593 closed ( +8) / 4009 total (+16)
Bugs: 974 open ( +6) / 6520 closed (+15) / 7494 total (+21)
RFE : 268 open ( +1) / 251 closed ( +0) / 519 total ( +1)
New / Reopened Patches
__
Allow spe
On 2/28/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Adam Olsen wrote:
>
> > How plausible would it be to optimize all exception instantiation?
> > Perhaps use slots and a freelist for everything inheriting from
> > BaseException and not inheriting from other builtin types?
>
> I'm not sure a free l
Adam Olsen wrote:
> How plausible would it be to optimize all exception instantiation?
> Perhaps use slots and a freelist for everything inheriting from
> BaseException and not inheriting from other builtin types?
I'm not sure a free list would help much for instances
of user define classes, sinc
Jean-Paul Calderone wrote:
> And the new behavior? Every raise statement copies an exception instance,
> some code will create a new exception instance for each raise statement,
> some code will create a single exception and re-raise it repeatedly.
Make that "most code will create a new exceptio
On 2/28/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> I am beginning to think that there are serious problems with attaching
> the traceback to the exception; I really don't like the answer that
> pre-creating an exception is unpythonic in Py3k.
How plausible would it be to optimize all except
Adam Olsen wrote:
> Exceptions aren't arbitrary objects though. The requirement that they
> inherit from BaseException is specifically to create a common
> interface.
But that doesn't tell you enough. If the exception
references some other object, should you copy it?
You can't tell just from the
I am beginning to think that there are serious problems with attaching
the traceback to the exception; I really don't like the answer that
pre-creating an exception is unpythonic in Py3k.
On 2/28/07, Jean-Paul Calderone <[EMAIL PROTECTED]> wrote:
> On Wed, 28 Feb 2007 18:29:11 -0700, Adam Olsen <[
On Wed, 28 Feb 2007 18:29:11 -0700, Adam Olsen <[EMAIL PROTECTED]> wrote:
>On 2/28/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
>> Adam Olsen wrote:
>>
>> > It sounds like we should always copy the exception given to raise,
>>
>> I don't like that either, for all the reasons that
>> make it infeasible
On 2/28/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Adam Olsen wrote:
>
> > It sounds like we should always copy the exception given to raise,
>
> I don't like that either, for all the reasons that
> make it infeasible to copy an arbitrary object in a
> general way.
Exceptions aren't arbitrary obj
Adam Olsen wrote:
> It sounds like we should always copy the exception given to raise,
I don't like that either, for all the reasons that
make it infeasible to copy an arbitrary object in a
general way.
--
Greg
___
Python-Dev mailing list
Python-Dev@p
[EMAIL PROTECTED] wrote:
> Or modify __new__ on your particular heavily-optimized
> exception to have a free-list,
Doing that in Python is likely to have as much overhead as
creating an instance.
The simple and obvious optimisation is to pre-create the
instance, but we're proposing to make the o
On 2/26/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Phillip J. Eby wrote:
> > At 03:38 PM 2/26/2007 -0700, Andrew Dalke wrote:
> >
> > > NO_END_OF_RECORD = ParserError("Cannot find end of record")
> >
> > Then don't do that, as it's bad style for Python 3.x. ;-)
>
> I don't like that answer. I can
Chris AtLee schrieb:
> I just got bitten by the runtime library incompatibility problem on
> windows when I tried to load a C extension compiled with MSVC 2005
> (64-bit) into Python 2.5.
>
> I realize that Python2.5 will continue to use MSVC 2003 for
> compatibility reasons, but I was curious if
On 2/28/07, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> "Chris AtLee" <[EMAIL PROTECTED]> wrote:
> > I just got bitten by the runtime library incompatibility problem on
> > windows when I tried to load a C extension compiled with MSVC 2005
> > (64-bit) into Python 2.5.
>
> I would guess it is more
"Chris AtLee" <[EMAIL PROTECTED]> wrote:
> I just got bitten by the runtime library incompatibility problem on
> windows when I tried to load a C extension compiled with MSVC 2005
> (64-bit) into Python 2.5.
I would guess it is more an issue of 32bit + 64bit dynamic linking
having issues, but I c
Also consider this example:
>>> 7.2 // 0.5
14.0
>>>
On 2/28/07, Facundo Batista <[EMAIL PROTECTED]> wrote:
> Greg Ewing wrote:
>
> > Is this intentional? I would have expected the
> > // operator to always give an integer result.
> >
> > Python 2.3 (#1, Aug 5 2003, 15:52:30)
> > [GCC 3.1 2002042
I just got bitten by the runtime library incompatibility problem on
windows when I tried to load a C extension compiled with MSVC 2005
(64-bit) into Python 2.5.
I realize that Python2.5 will continue to use MSVC 2003 for
compatibility reasons, but I was curious if any thought had been given
to the
As I found when writing the class decorator patch PEP 306 hasn't been
updated since the new AST was added. Here is a suggested replacement
block for the Checklist section. AST hackers feel free to make
suggestions.
Checklist
__ Grammar/Grammar: OK, you'd probably worked this one out :)
"Phillip J. Eby" <[EMAIL PROTECTED]> wrote:
>
> Well, you could use a custom metaclass with a tp_dealloc or whatever.
Yes, I thought of that, but a custom metaclass to provide one callback
is pretty fair overkill!
> But I just mainly meant that a PyCObject is almost as good as a weakref
> for cer
On Feb 28, 2007, at 1:50 AM, Andrew Dalke wrote:
> Glyph:
>> This seems like kind of a strange micro-optimization to have an
>> impact
>> on a language change discussion.
>
> Just as a reminder, my concern is that people reuse exceptions
> (rarely)
> and that the behavior of the "with_excepti
At 05:24 PM 2/28/2007 +, Nick Maclaren wrote:
>I suppose that I could add a C object as an attribute that points to
>a block of memory that contains copies of all my workspace pointers,
>and use the object deallocator to clean up. If all else fails, I
>will try that, but it seems a hell of a l
"Phillip J. Eby" <[EMAIL PROTECTED]> wrote:
>
> >But I need to clean up workspace when a class (not object) is
> >deallocated. I can't easily use attributes, as people suggested,
> >because there is no anonymous storage built-in type. I could subvert
> >one of the existing storage types (buffer,
At 09:00 AM 2/28/2007 +, Nick Maclaren wrote:
>I am gradually making progress with my binary floating-point software,
>but have had to rewrite several times as I have forgotten most of the
>details of how to do it! After 30 years, I can't say I am surprised.
>
>But I need to clean up workspace
On 2/27/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> On Tue, 27 Feb 2007 13:37:21 +1300, Greg Ewing <[EMAIL PROTECTED]> wrote:
>
> >I don't like that answer. I can think of legitimate
> >reasons for wanting to pre-create exceptions, e.g. if
> >I'm intending to raise and catch a particular exc
Greg Ewing wrote:
> Is this intentional? I would have expected the
> // operator to always give an integer result.
>
> Python 2.3 (#1, Aug 5 2003, 15:52:30)
> [GCC 3.1 20020420 (prerelease)] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
> >>> 7.0 // 2
> 3.0
I am gradually making progress with my binary floating-point software,
but have had to rewrite several times as I have forgotten most of the
details of how to do it! After 30 years, I can't say I am surprised.
But I need to clean up workspace when a class (not object) is
deallocated. I can't eas
Glyph:
> This seems like kind of a strange micro-optimization to have an impact
> on a language change discussion.
Just as a reminder, my concern is that people reuse exceptions (rarely)
and that the behavior of the "with_exceptions()" method is ambiguous
when that happens. It has nothing to do w
32 matches
Mail list logo
