Re: [Python-Dev] with_traceback
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 with optimization.
The two solutions of:
1. always replace an existing __traceback__
2. never replace an existing __traceback__
both seem to lead to problems.
Here are minimal examples for thought:
# I know PJE says this is bad style for 3.0. Will P3K help
# identify this problem? If it's allowable, what will it do?
# (Remember, I found existing code which reuses exceptions
# so this isn't purely theoretical, only rare.)
BAD = Exception("that was bad")
try:
raise BAD
except Exception:
pass
raise BAD # what traceback will be shown here?
(Oh, and what would a debugger report?)
# 2nd example; reraise an existing exception instance.
# It appears that any solution which reports a problem
# for #1 will not allow one or both of the following.
try:
raise Exception("bad")
except Exception as err:
first_err = err
try:
raise Exception("bad")
except Exception:
raise first_err # what traceback will be shown here?
# 3rd example, like the 2nd but end it with
raise first_err.with_exception(first_err.__traceback__) # what
traceback will be shown here?
> I'm sorry if this has been proposed already in this discussion (I
> searched around but did not find it),
I saw references to a PEP about it but could not find the PEP.
Nor could I find much discussion either. I would like to know
the details. I assume that "raise" adds the __traceback__ if
it's not None, hence there's no way it can tell if the __traceback__
on the instance was created with "with_traceback()" from an
earlier "raise" or from the with_traceback.
But in the current examples it appears that the Exception class
could attach a traceback during instantiation and "with_traceback"
simply replaces that. I doubt this version, but cannot be definitive.
While variant method/syntax may improve matters, I think people
will write code as above -- all of which are valid Python 2.x and
3.x -- and end up with strange and hard to interpret tracebacks.
Andrew
[EMAIL PROTECTED]
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Class destructor
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 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, string etc.), but that is unclean. And I could write one, but that is excessive. So far, I have been unable to track down how to get something called when a class is destroyed. The obvious attempts all didn't work, in a variety of ways. Surely there must be a method? This could be in either Python or C. Thanks. Regards, Nick Maclaren, University of Cambridge Computing Service, New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email: [EMAIL PROTECTED] Tel.: +44 1223 334761Fax: +44 1223 334679 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Integer division operator can give float result?
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 >From the Language Reference: The / (division) and // (floor division) operators yield the quotient of their arguments. The numeric arguments are first converted to a common type. Plain or long integer division yields an integer of the same type; the result is that of mathematical division with the `floor' function applied to the result. So, first the arguments are converted to a common type, in this case float. Then the division is made. Then the 'floor' function is applied. Result: 3.0. So yes, it's intentional. Regards, -- . Facundo . Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] with_traceback
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 exception > >frequently and I don't want the overhead of creating > >a new instance each time. > > This seems like kind of a strange micro-optimization to have an impact on a > language change discussion. Wouldn't it be better just to optimize instance > creation overhead? Or modify __new__ on your particular heavily-optimized > exception to have a free-list, so it can be both correct (you can still > mutate exceptions) and efficient (you'll only get a new exception object if > you really need it). It sounds like we should always copy the exception given to raise, and that not doing so is an optimization (albeit a commonly hit one). Not arguing for or against, just making an observation. On second thought, we could check that the refcount is 1 and avoid copying in the common case of "raise Foo()". Is reraising common enough that we need to optimize it? -- Adam Olsen, aka Rhamphoryncus ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Class destructor
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 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, string etc.), but that is >unclean. And I could write one, but that is excessive. > >So far, I have been unable to track down how to get something called >when a class is destroyed. The obvious attempts all didn't work, in >a variety of ways. Surely there must be a method? This could be in >either Python or C. Have you tried a PyCObject? This is pretty much what they're for: http://www.python.org/doc/1.5.2/api/cObjects.html And yes, they're still around today: http://www.python.org/doc/2.5/api/cObjects.html (with an extra PyCObject_SetVoidPtr API added in in 2.4). ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Class destructor
"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, string etc.), but that is > >unclean. And I could write one, but that is excessive. > > > >So far, I have been unable to track down how to get something called > >when a class is destroyed. The obvious attempts all didn't work, in > >a variety of ways. Surely there must be a method? This could be in > >either Python or C. > > Have you tried a PyCObject? This is pretty much what they're for: Oh, yes, I use them in several places, but they don't really help. Their first problem is that they take a 'void *' and not a request for space, so I have to allocate and deallocate the space manually. Now, I could add a destructor to each of them and do that, but it isn't really much prettier than subverting one of the semi-generic storage types for an improper purpose! It would be a heck of a lot cleaner to deallocate all of my space in exactly the converse way that I allocate and initialise it. It would also all me to collect and log statistics, should I so choose. This could be VERY useful for tuning! I haven't done that, yet, but might well do so. All in all, what I need is some way to get a callback when a class object is destroyed. Well, actually, any time from its last use for object work and the time that its space is reclaimed - I don't need any more precise time than that. 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 long way round for what I would have thought was a basic requirement. Regards, Nick Maclaren, University of Cambridge Computing Service, New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email: [EMAIL PROTECTED] Tel.: +44 1223 334761Fax: +44 1223 334679 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Class destructor
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 long way round for what I >would have thought was a basic requirement. Well, you could use a custom metaclass with a tp_dealloc or whatever. But I just mainly meant that a PyCObject is almost as good as a weakref for certain purposes -- i.e. it's got a pointer and a callback. You could of course also use weak references, but that's a bit more awkward as well. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] with_traceback
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_exceptions()" method is ambiguous > when that happens. It has nothing to do with optimization. > > The two solutions of: > 1. always replace an existing __traceback__ > 2. never replace an existing __traceback__ > both seem to lead to problems. I may be strange, or in left field, or both. Since the traceback is the object that is always created, it would seem natural to me that the traceback have a reference to the exception and not the other way around. It would also seem to be a good place to attach a nested traceback which intern has it's own reference to its exception. I never really thought about it when they were just peer objects traveling up the stack. Just an idea from a different seat ;) -Shane Holloway ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Class destructor
"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 certain purposes -- i.e. it's got a pointer and a callback. Ah. Yes. Thanks for suggesting it - if it is the simplest way, I may as well do it. > You could of course also use weak references, but that's a bit more > awkward as well. Yes. And they aren't a technology I have used (in Python), so I would have to find out about them. Attributes etc. I have already played with. Regards, Nick Maclaren, University of Cambridge Computing Service, New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email: [EMAIL PROTECTED] Tel.: +44 1223 334761Fax: +44 1223 334679 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PEP 306 changes (How to Change Python's Grammar)
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 :) __ Parser/Python.asdl may need changes to match the Grammar. Use Parser/asdl_c.py to regenerate Include/Python-ast.h __ Python/Python-ast.c may need changes to create the AST objects involved with the Grammar change. Lib/compiler/ast.py will need matching changes to the pure-python AST objects. __ Parser/pgen needs to be rerun to regenerate Include/graminit.h and Include/graminit.c __ Python/compile.c: You will need to create or modify the compiler_* functions for your productions. __ You may need to regenerate Lib/symbol.py and/or Lib/token.py and/or Lib/keyword.py __ The parser module. Add some of your new syntax to test_parser, bang on parsermodule.c until it passes. __ The compiler package. A good test is to compile the standard library and test suite with the compiler package and then check it runs. You did add some of your new syntax to the test suite, didn't you? There's a script in Tools/compiler that does this. __ If you've gone so far as to change the token structure of Python, then the tokenizer library module will need to be changed. __ Certain changes may require tweaks to the library module pyclbr. __ Documentation must be written! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Windows compiler for Python 2.6+
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 future of the 2.x series. Cheers, Chris ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Integer division operator can give float result?
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 20020420 (prerelease)] on darwin > > Type "help", "copyright", "credits" or "license" for more information. > > >>> 7.0 // 2 > > 3.0 > > >From the Language Reference: > > The / (division) and // (floor division) operators yield the quotient > of their arguments. The numeric arguments are first converted to a > common type. Plain or long integer division yields an integer of the > same type; the result is that of mathematical division with the > `floor' function applied to the result. > > So, first the arguments are converted to a common type, in this case > float. Then the division is made. Then the 'floor' function is applied. > Result: 3.0. > > So yes, it's intentional. > > Regards, > > -- > . Facundo > . > Blog: http://www.taniquetil.com.ar/plog/ > PyAr: http://www.python.org/ar/ > > > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Windows compiler for Python 2.6+
"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 could certainly be wrong. > 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 future of the 2.x series. IIUC, there exists a project file in PCBUILD8 for compiling with MSVC 2005. You should be able to recompile Python 2.5 with that compiler, though you may need to change some things (I've never tried myself). - Josiah ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Windows compiler for Python 2.6+
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 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. > > 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 future of the 2.x series. > > IIUC, there exists a project file in PCBUILD8 for compiling with MSVC > 2005. You should be able to recompile Python 2.5 with that compiler, > though you may need to change some things (I've never tried myself). That is kind of a last-resort for me...I'd like for my code to work with all the other python extensions out there, which is why I switched to the 2003 compiler for now. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Windows compiler for Python 2.6+
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 any thought had been given > to the future of the 2.x series. You are mistaken. The 64-bit versions (AMD64 and Itanium) are not compiled using MSVC 2003 - this product does not even include compilers for this platform. Instead, they are compiled with the SDK compilers. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] with_traceback
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 think of legitimate
> reasons for wanting to pre-create exceptions, e.g. if
> I'm intending to raise and catch a particular exception
> frequently and I don't want the overhead of creating
> a new instance each time.
Is this really the problem it's being made out to be? I'm guessing the
use-case you're suggesting is where certain exceptions are raised and
caught inside a library or application, places where the exceptions
will never reach the user. If that's the case, does it really matter
what the traceback looks like?
> For me, this is casting serious doubt on the whole
> idea of attaching the traceback to the exception.
If attaching the traceback to the exception is bothering you, you
should take a look at the other attributes PEP 344 introduces:
__cause__ and __context__. I'd say what needs another look is the idea
of pre-creating a single exception instance and repeatedly raising it.
Collin Winter
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] with_traceback
[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 obvious way wrong for subtle reasons. That doesn't seem pythonic to me. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] with_traceback
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@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] with_traceback
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 objects though. The requirement that they inherit from BaseException is specifically to create a common interface. Copying would be an extension of that interface. I believe calling copy.copy() would be sufficient. -- Adam Olsen, aka Rhamphoryncus ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] with_traceback
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 to copy an arbitrary object in a >> general way. > >Exceptions aren't arbitrary objects though. The requirement that they >inherit from BaseException is specifically to create a common >interface. Copying would be an extension of that interface. > >I believe calling copy.copy() would be sufficient. > Does copying every exception given to `raise' solve the problem being discussed here? Consider the current Python behavior: no copying is performed, most code instantiates a new exception instance for each raise statement, some code creates a single exception and re-raises it repeatedly. 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. That doesn't sound like an improvement to me. Normal code will be more wasteful. Code which the author has gone out of his way to tune will be as wasteful as /average/ code currently is, and more wasteful than tuned code now is. Plus you now have the added mental burden of keeping track of which objects are copies of what (and if you throw in the refcount=1 optimization, then this burden is increased - was something accidentally relying on copying or non-copying? Did a debugger grab a reference to the exception object, thus changing the programs behavior? Did a third-party hang on to an exception for longer than the raising code expected? etc). Jean-Paul ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] with_traceback
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 <[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 to copy an arbitrary object in a > >> general way. > > > >Exceptions aren't arbitrary objects though. The requirement that they > >inherit from BaseException is specifically to create a common > >interface. Copying would be an extension of that interface. > > > >I believe calling copy.copy() would be sufficient. > > > > Does copying every exception given to `raise' solve the problem being > discussed here? > > Consider the current Python behavior: no copying is performed, most code > instantiates a new exception instance for each raise statement, some code > creates a single exception and re-raises it repeatedly. > > 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. > > That doesn't sound like an improvement to me. Normal code will be more > wasteful. Code which the author has gone out of his way to tune will be > as wasteful as /average/ code currently is, and more wasteful than tuned > code now is. > > Plus you now have the added mental burden of keeping track of which objects > are copies of what (and if you throw in the refcount=1 optimization, then > this burden is increased - was something accidentally relying on copying or > non-copying? Did a debugger grab a reference to the exception object, thus > changing the programs behavior? Did a third-party hang on to an exception > for longer than the raising code expected? etc). > > Jean-Paul > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] with_traceback
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 fact that it inherits from BaseException. Besides, making a copy of the exception seems just as expensive as creating a new instance, so it does nothing to address the efficiency issue. Maybe it's not as important as I feel it is, but I like the way that exception raising is lightweight enough to use for flow control. When used that way, creating a new instance each time seems wasteful. I accept the overhead because I know that if it were ever a problem I could eliminate it by pre-creating the instance. I'd be disappointed to lose that ability. > I believe calling copy.copy() would be sufficient. I never use that, because I have no confidence that it would DWIM. I'd be unhappy if the system started relying on it anywhere fundamental. -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | Carpe post meridiem! | Christchurch, New Zealand | (I'm not a morning person.) | [EMAIL PROTECTED] +--+ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] with_traceback
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 exception instantiation? Perhaps use slots and a freelist for everything inheriting from BaseException and not inheriting from other builtin types? > On 2/28/07, Jean-Paul Calderone <[EMAIL PROTECTED]> wrote: > > On Wed, 28 Feb 2007 18:29:11 -0700, Adam Olsen <[EMAIL PROTECTED]> wrote: > > > > > >I believe calling copy.copy() would be sufficient. > > > > > That doesn't sound like an improvement to me. Normal code will be more > > wasteful. Code which the author has gone out of his way to tune will be > > as wasteful as /average/ code currently is, and more wasteful than tuned > > code now is. > > -- Adam Olsen, aka Rhamphoryncus ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] with_traceback
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 exception instance and then make a copy of it", unless this can be optimised away somehow, and it's not necessarily obvious that the refcount == 1 trick will work (it depends on the exact details of how the references flow through the exception raising machinery). -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | Carpe post meridiem! | Christchurch, New Zealand | (I'm not a morning person.) | [EMAIL PROTECTED] +--+ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] with_traceback
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, since creating one involves setting up a dict, etc. And if you use __slots__ you end up with objects of different sizes, which isn't free-list-friendly. -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | Carpe post meridiem! | Christchurch, New Zealand | (I'm not a morning person.) | [EMAIL PROTECTED] +--+ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] with_traceback
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 list would help much for instances > of user define classes, since creating one involves setting > up a dict, etc. And if you use __slots__ you end up with > objects of different sizes, which isn't free-list-friendly. Not easy, but doable. Perhaps a plan B if nobody comes up with a plan A. -- Adam Olsen, aka Rhamphoryncus ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] with_traceback
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 much attention to the topic of exception behavior as perhaps I should before attempting to contribute to a thread about it...but... 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 explainable behavior (the traceback to the creation point). The traceback won't necessarily be *useful*, but presumably someone pre-creating an exception object did so to save run-time, and creating the traceback is generally very expensive, so doing that only once, too, seems like a win to me. FWIW, that's basically how exceptions work in Java. From http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Throwable.html: > Instances of two subclasses, Error and Exception, are > conventionally used to indicate that exceptional situations have > occurred. Typically, these instances are freshly created in the > context of the exceptional situation so as to include relevant > information (such as stack trace data). > A throwable contains a snapshot of the execution stack of its > thread at the time it was created. It can also contain a message > string that gives more information about the error. Finally, it can > contain a cause: another throwable that caused this throwable to > get thrown. The cause facility is new in release 1.4. It is also > known as the chained exception facility, as the cause can, itself, > have a cause, and so on, leading to a "chain" of exceptions, each > caused by another. There's probably a million reasons why this doesn't work for python, but they don't immediately jump out at me. :) Migration from 2.X to 3.X would consist of recommending not to create an exception outside of a raise line, unless you're okay with the traceback location changing from the raise point to the creation point. James ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Weekly Python Patch/Bug Summary
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 specifying headers for MIME parts (2007-02-23) http://python.org/sf/125 opened by Jörg Sonnenberger Time zone-capable variant of time.localtime (2007-02-24) http://python.org/sf/1667546 opened by Paul Boddie urllib2 raises an UnboundLocalError if "auth-int" is the qop (2007-02-24) http://python.org/sf/1667860 opened by Atul Varma urllib2.urlopen() raises OSError instead of URLError (2007-02-24) http://python.org/sf/1668100 opened by Jerry Seutter Fix for 767111, 'AttributeError thrown by urllib.open_http' (2007-02-25) http://python.org/sf/1668132 opened by Atul Varma don't use '-' and '_' in mkstemp (2007-02-25) http://python.org/sf/1668482 opened by Arvin Schnell bytes.fromhex() (2007-02-26) CLOSED http://python.org/sf/1669379 opened by Georg Brandl subprocess: Support close_fds on Win32 (2007-02-26) http://python.org/sf/1669481 opened by Jon Foster Change (fix!) os.path.isabs() semantics on Win32 (2007-02-26) http://python.org/sf/1669539 opened by Jon Foster methods for bytes (2007-02-27) CLOSED http://python.org/sf/1669633 opened by Pete Shinners Remove Py_PROTO from socket in py3k (2007-02-27) CLOSED http://python.org/sf/1670209 opened by Pete Shinners email.Generator: no header wrapping for multipart/signed (2007-02-28) http://python.org/sf/1670765 opened by Martin von Gagern Refactor test_threadedtempfile.py to use unittest. (2007-02-28) http://python.org/sf/1670993 opened by Jerry Seutter Class Decorators (2007-02-28) http://python.org/sf/1671208 opened by Jack Diederich Refactor test_class to use unittest lib (2007-02-28) http://python.org/sf/1671298 opened by Mike Verdone New File I/O type for Python 3000, plus .h and unit tests (2007-02-28) http://python.org/sf/1671314 opened by Daniel Stutzbach Patches Closed __ setuptools: avoid sets module for python>2.3 (2007-02-19) http://python.org/sf/1663226 closed by pje documentation for element interface (2007-02-11) http://python.org/sf/1657613 closed by fdrake fast subclasses of builtin types (2006-12-28) http://python.org/sf/1624059 closed by nnorwitz bytes.fromhex() (2007-02-26) http://python.org/sf/1669379 closed by gbrandl Optional Argument Syntax (2006-12-02) http://python.org/sf/1607548 closed by gvanrossum methods for bytes (2007-02-26) http://python.org/sf/1669633 closed by nnorwitz Remove Py_PROTO from socket in py3k (2007-02-27) http://python.org/sf/1670209 closed by nnorwitz The Unicode "lazy strings" patches (2007-01-06) http://python.org/sf/1629305 closed by gvanrossum New / Reopened Bugs ___ Calling tparm from extension lib fails in Python 2.5 (2007-02-13) http://python.org/sf/1659171 reopened by richyk shutil.copytree doesn't preserve directory permissions (2007-02-22) http://python.org/sf/1666318 opened by Jeff McNeil Incorrect file path reported by inspect.getabsfile() (2007-02-23) http://python.org/sf/1666807 opened by Fernando Pérez terminalcommand doesn't work under Darwin (2007-02-23) http://python.org/sf/1666952 opened by Jurjen N.E. Bos Install fails with no error (2007-02-24) http://python.org/sf/1667877 reopened by widgeteye Install fails with no error (2007-02-24) http://python.org/sf/1667877 opened by larry PyMem_Realloc docs don't specifiy out-of-mem behavior (2007-02-24) http://python.org/sf/1668032 opened by Daniel Stutzbach PyMem_Resize docs don't specify that it modifies an argument (2007-02-24) http://python.org/sf/1668036 opened by Daniel Stutzbach python-2.4.4 on freebsd-6: _curses extension doesn't build (2007-02-25) CLOSED http://python.org/sf/1668133 opened by clemens fischer Strange unicode behaviour (2007-02-25) CLOSED http://python.org/sf/1668295 reopened by sgala Strange unicode behaviour (2007-02-25) CLOSED http://python.org/sf/1668295 opened by Santiago Gala I can't change attribute __op__ in new-style classes (2007-02-25) CLOSED http://python.org/sf/1668540 opened by netimen inspect.getargspec() fails with keyword-only arguments (2007-02-25) http://python.org/sf/1668565 opened by Brett Cannon distutils chops the first character of filenames (2007-02-25) http://python.org/sf/1668596 opened by Sam Pointon PyErr_WriteUnraisable lacks exception type check (2007-02-26) CLOSED http://python.org/sf/1669182 opened by Gabriel Becedillas Clarify PyMem_Realloc and PyMem_Resize docs (2007-02-26) http://python.org/sf/16693
Re: [Python-Dev] with_traceback
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 explainable behavior (the traceback to the > creation point). The traceback won't necessarily be *useful*, but > presumably someone pre-creating an exception object did so to save > run-time, and creating the traceback is generally very expensive, so > doing that only once, too, seems like a win to me. The only example I found in about 2 dozen packages where the exception was precreated was in pyparsing. I don't know the reason why it was done that way, but I'm certain it wasn't for performance. The exception is created as part of the format definition. In that case if the traceback is important then it's important to know which code was attempting the parse. The format definition was probably certainly done at module import time. In any case, reraising the same exception instance is a rare construct in current Python code. PJE had never seen it before. It's hard to get a good intuition from zero data points. :) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] with_traceback
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 exception will be instantiated and *then* passed to the raise statement. I've never seen a module level exception instance before. With the proposed changes, modules that do this would *continue* to work, surely ? So they lose nothing (compared to the current situation) by having the traceback information overwritten, they just can't take direct advantage of the new attribute. Michael Foord ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Windows compiler for Python 2.6+
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 you recompile with? There is none. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] with_traceback
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 asynchronous exceptions, we needed an object to specifically represent a "raised exception", i.e. an Exception instance with its attached traceback and methods to manipulate it. You can find its API here: http://twistedmatrix.com/documents/current/api/twisted.python.failure.Failure.html Perhaps the use-cases for attaching the traceback object to the exception would be better satisfied by simply having sys.exc_info() return an object with methods like Failure? Reading the "motivation" section of PEP 344, it describes "passing these three things in parallel" as "tedious and error-prone". Having one object one could call methods on instead of a 3-tuple which needed to be selectively passed on would simplify things. For example, chaining could be accomplished by doing something like this: sys.current_exc_thingy().chain() I can't think of a good name for the new object type, since "traceback", "error", "exception" and "stack" all already mean things in Python. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
