Direct use of bytearray buffers with ctypes ?

[Pakal]

Hello

I'm having big trouble wrapping the win32 ReadFile() function with
ctypes.

I wanted to allow the user to give a bytearray to this function, so
that the writable buffer of this bytearray is directly used to receive
the data from the file ; thus, no temporary copy in a separate ctype
buffer would be required.

However, I've found no way to provide ReadFile with a pointer to the
inner buffer of the bytearray object. I get misc. TypeErrors and
ValueErrors all the time, by trying to use the from_buffer() method or
other ctypes functions.

Is that actually posisble to expose with ctypes the internals of a
python object to the system, or is that unsupported at the moment ?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Direct use of bytearray buffers with ctypes ?

[Pakal]

Oki, it seems I've found.
To directly use a bytearray buffer from ctypes, you must first create
a compatible ctypes type (I.E, a char array of same size), and only
then instanciate this new type with newtype.from_buffer
(bytearray_object).

The little danger is : you must NOT change the size of bytearray as
long as the ctypes array targets its inner buffer, else of cousre
memory reallocations occurs, and your ctypes array points to invalid
memory (awaiting a pretty segfault). But modifying chars or characters
ranges from the buffer, as well via the bytearray object than via the
ctypes array, is fine.

I don't think problems can occur if both sides are accessed
simultaneously, even though ctypes operations may release the GIL
while they execute... the only race condition is the access of a
memory segment, isn't it ? No crash shall occur with this...

IDLE 2.6.4
>>> import ctypes
>>> a = bytearray(3)
>>> mytype = ctypes.c_char * 3
>>> h = mytype.from_buffer(a)
>>> h
<__main__.c_char_Array_3 object at 0x02B06350>
>>> h[:] = "abc"
>>> a
bytearray(b'abc')
>>> h[0] = "k"
>>> a
bytearray(b'kbc')
-- 
http://mail.python.org/mailman/listinfo/python-list

Castrated traceback in sys.exc_info()

[Pakal]

Hello

I've just realized recently that sys.exc_info() didn't return a full
traceback for exception concerned : it actually only contains the
frame below the point of exception catching.

That's very annoying to me, because I planned to log such tracebacks
with logging.critical(*, exc_info=True), and these partial
tracebacks, like the one below, are clearly unsufficient to determine
where the problem comes from. A whole traceback, from program entry
point to exception raising point, would be much better.

2010-03-17 09:28:59,184 - pims - CRITICAL - This is just a test to
ensure critical emails are properly sent
Traceback (most recent call last):
<< HERE, lots of frames missing >>
  File "test_common.py", line 34, in test_email_sending
os.open("qsdsdqsdsdqsd", "r")
TypeError: an integer is required

Is there any workaround for this ? I've thought about a custom logging
formatter, which would take both the exc_info traceback AND its own
full backtrace, and to connect them together on their relevant part,
but it's awkward and error prone... why can't we just have all the
precious traceback info under the hand there (an additional attribute
might have pointed the precise frame in which the exception was
caught).

Tanks for the attention,
Regards,
Pascal
-- 
http://mail.python.org/mailman/listinfo/python-list

Sys.exit in secondary threads

[Pakal]

I've noticed that there is nothing in python's documentation regarding
the use of sys.exit(code) in a non-main thread.

As far as I've seen, the behaviour in this case is to simply exit the
thread, without caring about the return code. in the main thread
however, the return code becomes the official return code of the whole
process.

Is that all we have to say about sys.exit() in a multithreaded
program ? Or are there corner cases I've missed ? We'd better document
this anyway.

Regards,
Pascal
-- 
http://mail.python.org/mailman/listinfo/python-list