Re: [Python-Dev] bool conversion wart?
Guido van Rossum wrote: > How would this change be helpful? I'm utterly mystified by these > suggestions that bool would be more useful if it didn't behave like an > int in arithmetic. I don't think anyones really saying it would be more useful, it obviously wouldn't, since like Greg said, it wouldn't work in mapping access or set membership like it does now. I think it would be more readable though, since thinks like this: >>> True in set([1]) True or that 5+True is equal to 6 aren't necessarily obvious to someone who doesn't know that True evaluates to 1. >> The fact that bool is a subclass of int is more historic than necessary. If >> not for Python's long usage of 0 and 1 to be the canonical False and True, I >> suspect that bool might have been implemented as a new standalone type. > > Not necessarily. I really like the idea that bool is embedded in int, > just like int is embedded in float (real), and real is embedded in > complex. It is elegant to embed bool in int, but to me it screams C. To me, it makes more sense to use an int if you want an int, and to reserve boolean for logic. From an elegance/usefulness standpoint, maybe bool should evaluate to 0 and 1. But IMHO, it would eliminate some gotchas and improve readability if it didn't. -Jordan Greenberg, not a Py-Dev, just an interested luser^H^H^Hrker. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] microthreading vs. async io
Armin Rigo wrote: > I just realized that this is not really true in the present context. > If the goal is to support programs that "look like" they are > multi-threaded, i.e. don't use callbacks, as I think is Joachim's goal, > then most of the time the wait() function would be only called with a > *single* event, rarely two or three, never more. Indeed, in this model > a large server is implemented with many microthreads: at least one per > client. Each of them blocks in a separate call to wait(). In each such > call, only the events revelant to that client are mentioned. > Yes exactly. > In other words, the cost is O(n), but n is typically 1 or 2. It is not > the total number of events that the whole application is currently > waiting on. Indeed, the scheduler code doing the real OS call (e.g. to > select()) can collect the events in internal dictionaries, or in Poll > objects, or whatever, and update these dictionaries or Poll objects with > the 1 or 2 new events that a call to wait() introduces. In this > respect, the act of *calling* wait() already means "add these events to > the set of all events that need waiting for", without the need for a > separate API for doing that. > But as I'd like to make the event structure similar to the BSD-kevent structure, we could use a flag in the event structure that tells the schedular to consider it only once or keep it in its dictionary, than the task would not need to supply the event each time. > [I have experimented myself with a greenlet-based system giving wrapper > functions for os.read()/write() and socket.recv()/send(), and in this > style of code we tend to simply spawn new greenlets all the time. Each > one looks like an infinite loop doing a single simple job: read some > data, process it, write the result somewhere else, start again. (The > loops are not really infinite; e.g. if sockets are closed, an exception > is generated, and it causes the greenlet to exit.) So far I've managed > to always wait on a *single* event in each greenlet, but sometimes it > was a bit contrieved and being able to wait on 2-3 events would be > handy.] > I do not spawn new greenlets all the time. Instead, my tasks either wait() or call wrappers for read/write/send/recv... that implicitely call wait(...) until enough data is available, and the wait(...) does the yield to the scheduler that can either continue other tasks or call kevent/poll/select if no task is runnable. What I'd like to see in an API/library: * a standard schedular that is easily extensible * event structure/class that's easily extensible E.g. I've extended the kevent structure for the scheduler to also include channels similar to stackless. These are python only communication structures, so there is no OS support for blocking on them, but the scheduler can decide if there is something available for a task that waits on a channel, so the channels are checked first in the schedular to see if a task can continue and only if no channel event is available the schedular calls kevent/select/poll. While the scheluler blocks in kevent/select/poll, nothing happens on the channels as no task is running, so the scheduler never blocks (inside the OS) unnecessarily. Joachim ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] microthreading vs. async io
On 2/25/07, Armin Rigo <[EMAIL PROTECTED]> wrote: > Hi Adam, > > On Thu, Feb 15, 2007 at 06:17:03AM -0700, Adam Olsen wrote: > > > E.g. have a wait(events = [], timeout = -1) method would be sufficient > > > for most cases, where an event would specify > > > > I agree with everything except this. A simple function call would > > have O(n) cost, thus being unacceptable for servers with many open > > connections. Instead you need it to maintain a set of events and let > > you add or remove from that set as needed. > > I just realized that this is not really true in the present context. > If the goal is to support programs that "look like" they are > multi-threaded, i.e. don't use callbacks, as I think is Joachim's goal, > then most of the time the wait() function would be only called with a > *single* event, rarely two or three, never more. Indeed, in this model > a large server is implemented with many microthreads: at least one per > client. Each of them blocks in a separate call to wait(). In each such > call, only the events revelant to that client are mentioned. > > In other words, the cost is O(n), but n is typically 1 or 2. It is not > the total number of events that the whole application is currently > waiting on. Indeed, the scheduler code doing the real OS call (e.g. to > select()) can collect the events in internal dictionaries, or in Poll > objects, or whatever, and update these dictionaries or Poll objects with > the 1 or 2 new events that a call to wait() introduces. In this > respect, the act of *calling* wait() already means "add these events to > the set of all events that need waiting for", without the need for a > separate API for doing that. That would depend on whether Joachim's wait() refers to the individual tasks' calls or the scheduler's call. I assumed it referred to the scheduler. In the basic form it would literally be select.select(), which has O(n) cost and often fairly large n. -- Adam Olsen, aka Rhamphoryncus ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] microthreading vs. async io
Adam Olsen wrote: > That would depend on whether Joachim's wait() refers to the individual > tasks' calls or the scheduler's call. I assumed it referred to the > scheduler. In the basic form it would literally be select.select(), > which has O(n) cost and often fairly large n. The wait(events, timeout) call of a task would only mention the events that the task is interested in. The wait() call yields that list to the scheduler. The scheduler then analyzes the list of events that tasks are waiting for and compares it to it's last call to select/poll/kevent and continues tasks in a round robin fashion until all events have been scheduled to the waiting tasks. Only when the scheduler has no events to deliver (e.g. all tasks are waiting) a new select/poll/kevent OS call is made by the scheduler, with a computed timeout to the lowest timeout value of all the tasks, so that a timeout can be delivered at the right time. Joachim ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Renaming Include/object.h
On 2/25/07, Jeremy Hylton <[EMAIL PROTECTED]> wrote:
> On 1/3/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > In #1626545, Anton Tropashko requests that object.h should be
> > renamed, because it causes conflicts with other software.
> >
> > I would like to comply with this requests for 2.6, assuming there
> > shouldn't be many problems with existing software as object.h
> > shouldn't be included directly, anyway.
>
> I like the idea of renaming the header files, but I expect there is a
> lot more opportunity for breaking code that you estimate. I did a
> search on google.com/codesearch and found seven external packages that
> include Python.h and object.h (before I gave up).
So rather than a simple rename, we should probably rename, change all
references in the core to use the new name, and make a simple object.h
that only does:
#include "new_object.h"
> I assume we expect people won't include it, because it is also
> included in object.h. But they do it. Is there documentation that
> says you shouldn't import it?
I thought somewhere (embedding/extending doc?) it mentions that only
Python.h should be included, but if we have a naming
convention/directory structure, this becomes more obvious.
Doc/ext/extending.tex:
To support extensions, the Python API (Application Programmers
Interface) defines a set of functions, macros and variables that
provide access to most aspects of the Python run-time system. The
Python API is incorporated in a C source file by including the header
\code{"Python.h"}.
(But it may not say nothing else should be included.)
n
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Bug in PyErr_WriteUnraisable ?
Thanks! Hopefully someone will be able to get to it in the near future. -Brett On 2/26/07, Gabriel Becedillas <[EMAIL PROTECTED]> wrote: > Brett Cannon wrote: > > On 2/22/07, Gabriel Becedillas <[EMAIL PROTECTED]> wrote: > >> I'd hit an access violation inside PyErr_WriteUnraisable when a > >> non-exception instance was raised. The call to PyExceptionClass_Name > >> with a non-exception instance is yielding an invalid pointer. > >> We are embedding Python 2.5 and a string instance is raised using > >> PyThreadState_SetAsyncExc. I can fix that in my code, by raising an > >> appropiate exception instance, but I think PyErr_WriteUnraisable lacks > >> some checks. > >> > > > > Please use the the bug tracker at > > http://sourceforge.net/tracker/?group_id=5470&atid=105470 to report > > issues with Python. > > > > -Brett > > > >> -- > >> > >> > >> Gabriel Becedillas > >> Developer > >> CORE SECURITY TECHNOLOGIES > >> > >> ___ > >> Python-Dev mailing list > >> [email protected] > >> http://mail.python.org/mailman/listinfo/python-dev > >> Unsubscribe: > >> http://mail.python.org/mailman/options/python-dev/brett%40python.org > >> > > > > I've submitted the bug report with a snippet of code to reproduce the crash. > http://sourceforge.net/tracker/index.php?func=detail&aid=1669182&group_id=5470&atid=105470 > > -- > > > Gabriel Becedillas > Developer > CORE SECURITY TECHNOLOGIES > > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] bool conversion wart?
Jordan Greenberg <[EMAIL PROTECTED]> wrote: > Guido van Rossum wrote: > > How would this change be helpful? I'm utterly mystified by these > > suggestions that bool would be more useful if it didn't behave like an > > int in arithmetic. > > I don't think anyones really saying it would be more useful, it > obviously wouldn't, since like Greg said, it wouldn't work in mapping > access or set membership like it does now. I think it would be more > readable though, since thinks like this: > >>> True in set([1]) > True > > or that 5+True is equal to 6 aren't necessarily obvious to someone who > doesn't know that True evaluates to 1. Maybe, but 30-some years of C semantics and another 15 years of Python semantics die hard. a==b for builtin types used to return 1 or 0, now they return True or False. Changing such semantics because some users haven't ever used C or older Pythons would be a bit like changing 'def' to 'fcn' because some users have never used 'def' to define a function. Learn the semantic and move on. > It is elegant to embed bool in int, but to me it screams C. To me, it > makes more sense to use an int if you want an int, and to reserve > boolean for logic. You say "screams C" as if it were necessarily a bad thing. Certainly C isn't a perfect language (which is why I use Python), but there are many reasons why I (and others) use (or not) C, but I can just about guarantee you that the semantics of booleans in C *help* rather than hurt its adoption. > From an elegance/usefulness standpoint, maybe bool should evaluate to 0 > and 1. But IMHO, it would eliminate some gotchas and improve readability > if it didn't. You are, of course, entitled to your opinion. From what I understand, there is perhaps one major "gotcha" in the current semantics: bool(str()) isn't correct for anything except for '' and u''. Then again, that isn't a guarantee with str or bool (or list, tuple, dict, deque, set, etc.) - Josiah ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] with_traceback
Guido's talk at PyCon said:
> Use raise E(arg).with_traceback(tb)
> instead of raise E, arg, tb
That seems strange to me because of the mutability. Looking through
the back discussions on this list I see Guido commented:
http://mail.python.org/pipermail/python-3000/2007-February/005689.html
> Returning the mutated object is acceptable here
> because the *dominant* use case is creating and raising an exception
> in one go:
>
> raise FooException().with_traceback()
The 3 argument raise statement is rarely used, in my experience.
I believe most don't even know it exists, excepting mostly advanced
Python programmers and language lawyers.
My concern when I saw Guido's keynote was the worry that
people do/might write code like this
NO_END_OF_RECORD = ParserError("Cannot find end of record")
def parse_record(input_file):
...
raise NO_END_OF_RECORD
...
That is, create instances at the top of the module, to be used
later. This code assume that the NO_END_OF_RECORD
exception instance is never modified.
If the traceback is added to its __traceback__ attribute then
I see two problems if I were to write code like the above:
- the traceback stays around "forever"
- the code is no longer thread-safe.
As an example of code which is affected by this, see pyparsing,
which has code that looks like
class Token(ParserElement):
"""Abstract ParserElement subclass, for defining atomic matching patterns.""
"
def __init__( self ):
super(Token,self).__init__( savelist=False )
self.myException = ParseException("",0,"",self)
class Literal(Token):
def parseImpl( self, instring, loc, doActions=True ):
if (instring[loc] == self.firstMatchChar and
(self.matchLen==1 or instring.startswith(self.match,loc)) ):
return loc+self.matchLen, self.match
#~ raise ParseException( instring, loc, self.errmsg )
exc = self.myException
exc.loc = loc
exc.pstr = instring
raise exc
The "Literal" and other token classes are part of the
grammar definition and usually exist in module scope.
There's another question I came up with. If the exception
already has a __traceback__, will that traceback be
overwritten if the instance is reraised? Consider this code,
loosly derived from os._execvpe
import os, sys
_PATH = ["here", "there", "elsewhere"]
def open_file_on_path(name):
# If nothing exists, raises an exception based on the
# first attempt
saved_err = None
saved_tb = None
for dirname in _PATH:
try:
return open(os.path.join(dirname, name))
except Exception, err:
if not saved_err:
saved_err = err
saved_tb = sys.exc_info()[2]
raise saved_err.__class__, saved_err, saved_tb
open_file_on_path("spam")
which generates this
Traceback (most recent call last):
File "raise.py", line 19, in
open_file_on_path("spam")
File "raise.py", line 11, in open_file_on_path
return open(os.path.join(dirname, name))
IOError: [Errno 2] No such file or directory: 'here/spam'
What is the correct way to rewrite this for use
with "with_traceback"? Is it
def open_file_on_path(name):
# If nothing exists, raises an exception based on the
# first attempt
saved_err = None
for dirname in _PATH:
try:
return open(os.path.join(dirname, name))
except Exception, err:
if not saved_err:
saved_err = err
saved_tb = sys.exc_info()[2]
raise saved_err.with_traceback(saved_err.__traceback__)
One alternative, btw, is
raise saved_err.with_traceback()
to have it use the existing __traceback__ (and raising its
own exception if __traceback__ is None?)
Andrew
[EMAIL PROTECTED]
___
Python-Dev mailing list
[email protected]
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, Andrew Dalke <[EMAIL PROTECTED]> wrote:
My concern when I saw Guido's keynote was the worry that
people do/might write code like this
NO_END_OF_RECORD = ParserError("Cannot find end of record")
def parse_record(input_file):
...
raise NO_END_OF_RECORD
...
FWIW, you can remove 'might' from that sentence: I've seen more than a few
people use that kind of code (and I share your concerns.)
--
Thomas Wouters <[EMAIL PROTECTED]>
Hi! I'm a .signature virus! copy me into your .signature file to help me
spread!
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python-3000 upgrade path
Stephen J. Turnbull wrote: > RKN = reverse Knuth numbering? No, for RKN you'd have to start with 3141.5926... (an infinite number of digits following) and drop one off the end each time... although it would take rather a long time to get to the final release then. :-( -- Greg ___ Python-Dev mailing list [email protected] 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
At 03:38 PM 2/26/2007 -0700, Andrew Dalke wrote:
>Guido's talk at PyCon said:
>
> > Use raise E(arg).with_traceback(tb)
> > instead of raise E, arg, tb
>
>That seems strange to me because of the mutability. Looking through
>the back discussions on this list I see Guido commented:
> http://mail.python.org/pipermail/python-3000/2007-February/005689.html
>
> > Returning the mutated object is acceptable here
> > because the *dominant* use case is creating and raising an exception
> > in one go:
> >
> > raise FooException().with_traceback()
>
>The 3 argument raise statement is rarely used, in my experience.
>I believe most don't even know it exists, excepting mostly advanced
>Python programmers and language lawyers.
>
>My concern when I saw Guido's keynote was the worry that
>people do/might write code like this
>
>NO_END_OF_RECORD = ParserError("Cannot find end of record")
>
>def parse_record(input_file):
>...
> raise NO_END_OF_RECORD
>...
>
>
>That is, create instances at the top of the module, to be used
>later. This code assume that the NO_END_OF_RECORD
>exception instance is never modified.
>
>If the traceback is added to its __traceback__ attribute then
>I see two problems if I were to write code like the above:
>
> - the traceback stays around "forever"
> - the code is no longer thread-safe.
Then don't do that, as it's bad style for Python 3.x. ;-)
But do note that 3-argument raise should NOT be implemented this way in
Python 2.x. 2.6 and other 2.x revisions should still retain the existing
raise machinery, it's just that *catching* an exception using 3.x style
("except foo as bar:") should call with_traceback() at the time of the catch.
This does mean you won't be able to port your code to 3.x style until
you've gotten rid of shared exception instances from all your dependencies,
but 3.x porting requires all your dependencies to be ported anyway.
It should be sufficient in both 2.x and 3.x for with_traceback() to raise
an error if the exception already has a traceback -- this should catch any
exception instance reuse.
>What is the correct way to rewrite this for use
>with "with_traceback"? Is it
>
>def open_file_on_path(name):
> # If nothing exists, raises an exception based on the
> # first attempt
> saved_err = None
> for dirname in _PATH:
> try:
> return open(os.path.join(dirname, name))
> except Exception, err:
> if not saved_err:
> saved_err = err
> saved_tb = sys.exc_info()[2]
> raise saved_err.with_traceback(saved_err.__traceback__)
No, it's more like this:
try:
for dirname in ...
try:
return ...
except Exception as err:
saved_err = err
raise saved_err
finally:
del saved_err
I've added the outer try-finally block to minimize the GC impact of the
*original* code you showed, as the `saved_tb` would otherwise have created
a cycle. That is, the addition is not because of the porting, it's just
something that you should've had to start with.
Anyway, the point here is that in 3.x style, most uses of 3-argument raise
just disappear altogether. If you hold on to an exception instance, you
have to be careful about it for GC, but no more so than in current Python.
The "save one instance and use it forever" use case is new to me - I've
never seen nor written code that uses it before now. It's definitely
incompatible with 3.x style, though.
___
Python-Dev mailing list
[email protected]
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
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.
For me, this is casting serious doubt on the whole
idea of attaching the traceback to the exception.
--
Greg
___
Python-Dev mailing list
[email protected]
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
PJE:
> Then don't do that, as it's bad style for Python 3.x. ;-)
It's bad style for 3.x only if Python goes with this interface. If
it stays with the 2.x style then there's no problem. There
may also be solutions which are cleaner and which don't
mutate the exception instance.
I am not proposing such a syntax. I have ideas I am not a
language designer and have long given up the idea that I
might be good at it.
> This does mean you won't be able to port your code to 3.x style until
> you've gotten rid of shared exception instances from all your dependencies,
> but 3.x porting requires all your dependencies to be ported anyway.
What can be done to minimize the number of dependencies which
need to be changed?
> It should be sufficient in both 2.x and 3.x for with_traceback() to raise
> an error if the exception already has a traceback -- this should catch any
> exception instance reuse.
That would cause a problem in my example where I save then
reraise the exception, as
raise saved_err.with_traceback(saved_err.__traceback__)
> >What is the correct way to rewrite this for use
> >with "with_traceback"? Is it
[...]
> No, it's more like this:
>
> try:
> for dirname in ...
> try:
> return ...
> except Exception as err:
> saved_err = err
> raise saved_err
> finally:
> del saved_err
I don't get it. The "saved_err" has a __traceback__
attached to it, and is reraised. Hence it gets the old
stack, right?
Suppose I wrote
ERR = Exception("Do not do that")
try:
f(x)
except Exception:
raise ERR
try:
f(x*2)
except Exception:
raise ERR
Yes it's bad style, but people will write it. The ERR gets
the traceback from the first time there's an error, and
that traceback is locked in ... since raise won't change
the __traceback__ if one exists. (Based on what you
said it does.)
> I've added the outer try-finally block to minimize the GC impact of the
> *original* code you showed, as the `saved_tb` would otherwise have created
> a cycle. That is, the addition is not because of the porting, it's just
> something that you should've had to start with.
Like I said, I used code based on os._execvpe. Here's the code
saved_exc = None
saved_tb = None
for dir in PATH:
fullname = path.join(dir, file)
try:
func(fullname, *argrest)
except error, e:
tb = sys.exc_info()[2]
if (e.errno != ENOENT and e.errno != ENOTDIR
and saved_exc is None):
saved_exc = e
saved_tb = tb
if saved_exc:
raise error, saved_exc, saved_tb
raise error, e, tb
I see similar use in atexit._run_exitfuncs, though as Python
is about to exit it won't make a real difference.
doctest shows code like
>>> exc_info = failure.exc_info
>>> raise exc_info[0], exc_info[1], exc_info[2]
SimpleXMLRPCServer does things like
except:
# report exception back to server
exc_type, exc_value, exc_tb = sys.exc_info()
response = xmlrpclib.dumps(
xmlrpclib.Fault(1, "%s:%s" % (exc_type, exc_value)),
encoding=self.encoding, allow_none=self.allow_none,
)
I see threading.py gets it correctly.
My point here is that most Python code which uses the traceback
term doesn't break the cycle, so must be caught by the gc. While
there might be a more correct way to do it, it's too complicated
for most to get it right.
> Anyway, the point here is that in 3.x style, most uses of 3-argument raise
> just disappear altogether. If you hold on to an exception instance, you
> have to be careful about it for GC, but no more so than in current Python.
Where people already make a lot of mistakes. But my concern
is not in the gc, it's in the mutability of the exception causing hard
to track down problems in code which is written by beginning to
intermediate users.
> The "save one instance and use it forever" use case is new to me - I've
> never seen nor written code that uses it before now. It's definitely
> incompatible with 3.x style, though.
I pointed out an example in pyparsing. Thomas W. says he's
seen other code. I've been looking for another real example but
as this is relatively uncommon code, I don't have a wide enough
corpus for the search. I also don't know of a good tool for searching
for this sort of thing. (Eg, www.koders.com doesn't help.)
It's a low probability occurance. So is the use of the 3 arg raise.
Hence it's hard to get good intuition about problems which might
arise.
Andrew
[EMAIL PROTECTED]
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Bug in PyErr_WriteUnraisable ?
Brett Cannon wrote: > On 2/22/07, Gabriel Becedillas <[EMAIL PROTECTED]> wrote: >> I'd hit an access violation inside PyErr_WriteUnraisable when a >> non-exception instance was raised. The call to PyExceptionClass_Name >> with a non-exception instance is yielding an invalid pointer. >> We are embedding Python 2.5 and a string instance is raised using >> PyThreadState_SetAsyncExc. I can fix that in my code, by raising an >> appropiate exception instance, but I think PyErr_WriteUnraisable lacks >> some checks. >> > > Please use the the bug tracker at > http://sourceforge.net/tracker/?group_id=5470&atid=105470 to report > issues with Python. > > -Brett > >> -- >> >> >> Gabriel Becedillas >> Developer >> CORE SECURITY TECHNOLOGIES >> >> ___ >> Python-Dev mailing list >> [email protected] >> http://mail.python.org/mailman/listinfo/python-dev >> Unsubscribe: >> http://mail.python.org/mailman/options/python-dev/brett%40python.org >> > I've submitted the bug report with a snippet of code to reproduce the crash. http://sourceforge.net/tracker/index.php?func=detail&aid=1669182&group_id=5470&atid=105470 -- Gabriel Becedillas Developer CORE SECURITY TECHNOLOGIES ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
