I am wrapping libsndfile to Python, using SWIG and don't know howto return a
malloc()ed memory area back to Python.
I've found CObjects, which would let me pass free() as cleanup function, but
I'd rather return a buffer object (PyBuffer_FromReadWriteMemory) so that I
could prevent copying of data, but I don't know how to prevent the memory
Can I install some kind of cleanup hook?
Please also reply to me personally, as I am not on the python-dev list.
In any organization there will always be one person who knows
what is going on.
This person must be fired.
Greg Ewing wrote:
> Guido van Rossum wrote:
>> Its maps have methods to
>> return keys, values and items, but these return neither new lists nor
>> iterators; they return "views" which obey set (or multiset, in the
>> case of items) semantics.
>> I'd like to explore this as an alternative to making keys() etc.
>> return iterators.
> This sounds like a really really good idea!
> It would solve Jim's problem, because the result of
> d.keys() would print out just like a real list, and
> then he could backspace over the .keys() and do
> something else.
If these things returned iterables rather than actual iterators (i.e. similar
to what xrange currently does), it would also address the fact that caching
references to iterators just doesn't work.
keys = d.keys()
big_key = max(keys)
little_key = max(keys)
If keys() returns a list or other iterable, all is good. If it returns an
actual iterator though. . .
I do find it somewhat interesting that we're considering moving the standard
containers to a more numpy-ish view of the world, though (i.e. one where
multiple mutable views of a data structure are common in order to avoid
Would that philosophy be extended to slicing operations, though?
Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia
I have been looking into the (seemingly random) test_popen2
failures today, and found that it fails when the tests
are run in the order given in the subject.
Here is what happens:
- test_quopri uses os.popen2, which in turn creates a popen2.Popen3
object. It processes stdin/stdout, but never calls wait on that
the process (it can't: os.popen2 doesn't return the pid).
This is a flaw (the process should be waited for) which I fixed.
- test_wait3 has a loop to wait for child processes, which invokes
wait repeatedly until the expected child pid is returned. In
the process, it might receive the wait status from processes it
didn't start. This is a flaw which I didn't address - I wonder
why there is a loop, instead of just waiting once, and expecting
the PID of the process that had been created just before.
- test_popen2 invokes _cleanup at the end, which waits for all
_active processes. Now, since test_quopri added an active process,
and test_wait3 deleted its pid, _cleanup fails with the error that
the pid is no longer valid.
I made that failure more obvious.
So here is what I did to address these:
- I changed test_quopri to use subprocess.Popen().communicate()
to invoke quopri as a program. communicate will wait() for the
- I changed test_popen2 to check at the beginning that there are
no active processes. To print out the commands that are still
active, I added the cmd string to the Popen objects.
It turned out that this broke the Windows builds, which, in turn,
resolves as a hidden bug/feature of quopri command line mode.
When "python -mquopri <foo.txt" is invoked, the output will
contain CRLF even if the input doesn't, this is likely because
stdout is in text mode on Windows. Now, subprocess.py is not
in text mode (unlike os.popen2), so when reading the results,
we see CRLF on Windows, but LF elsewhere.
I fixed this by making the result check line-ending-independent,
because I think using CRLF in quoted-unreadable is compliant
with the relevant RFC. Alternatively, the quopri.py command
line mode could be put into binary mode, so that it produces
identical outputs on all systems.
> +Outstanding Issues
> +* Require C99, so we can use // comments, named initializers, declare variables
> + without introducing a new scope, among other benefits.
gcc only, in other words ?
> +* Remove support for old systems, including: OS2, BeOS, RISCOS, (SGI) Irix, Tru64
what's old with tru64 ? it's not that uncommon in places where Python
has a strong presence, you can still buy AXP hardware throughout 2006,
and HP says they'll keep developing and supporting the software platform
at least through 2011.
I've just submitted patch #1457227 which adds a convenience method to
datetime objects to get the timestamp. It's equivalent to
time.mktime(d.timetuple()), I just wanted to save myself some typing
and be able to write d.timestamp() instead.
I hope I have the dst code right. Would d.utctimestamp() be useful as well?