[Python-Dev] Distutils and -framework on MacOSX
Has anyone found a way of persuading distutils to pass MacOSX -framework options properly when linking? Using extra_link_args doesn't work, because they need to be at the beginning of the command line to work properly, but extra_link_args gets put at the end. And extra_compile_args is only used when compiling, not linking. -- 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] Distutils and -framework on MacOSX
On 29 Mar, 2007, at 11:37, Greg Ewing wrote: Has anyone found a way of persuading distutils to pass MacOSX -framework options properly when linking? Using extra_link_args doesn't work, because they need to be at the beginning of the command line to work properly, but extra_link_args gets put at the end. And extra_compile_args is only used when compiling, not linking. What's wrong with adding -framework flags to the end? I do this all the time and have yet to run into problems. Ronald smime.p7s Description: S/MIME cryptographic signature ___ 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] A simplified extended buffer PEP
Greg Ewing wrote: Carl Banks wrote: /* don't define releasebuffer or lockbuffer */ /* only objects that manage buffers themselves would define these */ That's an advantage, but it's a pretty small one ... the releaser field makes the protocol asymmetrical and thus harder to reason about. Instead of releaser, how about an owner field, that points to a PyObject? PyObject_GetBuffer will create a new reference to owner, and unlock/release is just a DECREF on that same object. (Or does redirecting the DECREF target like this look too magical?) If a buffer exporter want to keep things simple, it can just set owner to self. If it has fancier needs (such as mutating the buffer without mutating the view), then it can create a manager to do whatever it wants, and set that as the owner. Note that the PyBufferProcs structure isn't needed any more -- from a consumer/requestor's perspective, the unlock/release is just DECREFing the owner. Looking at http://projects.scipy.org/scipy/numpy/browser/trunk/numpy/doc/pep_buffer.txt (Other than utility functions like PyObject_SizeFromFormat,) I think the entire protocol can then collapse to the bufferinfo struct and either // might set an error and return NULL struct bufferinfo *PyObject_GetBuffer(PyObject *obj, int flags) or // Replace the *view elements with the actual buffers metadata // (return = 0) == success // (return 0) == modified (perhaps rejecting the RO argument)? // (return 0) == failure int PyObject_GetBuffer(PyObject *obj, struct bufferinfo *view) -jJ ___ 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] Italic text in the manual
On Thursday 08 March 2007 08:42, Martin v. Löwis wrote: Certainly not. In today's copy (8.3.07, 13:30 GMT), this starts between 18.17 and 18.17.1. However, looking at the tex, I cannot find anything suspicious. texcheck complains about a missing ), which I added, but it only was a problem of the text, not of the markup. This doesn't seem to be a problem any more, so I'm going to presume Martin fixed it. ;-) -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ 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] Italic text in the manual
On 3/29/07, Fred L. Drake, Jr. [EMAIL PROTECTED] wrote: On Thursday 08 March 2007 08:42, Martin v. Löwis wrote: Certainly not. In today's copy (8.3.07, 13:30 GMT), this starts between 18.17 and 18.17.1. However, looking at the tex, I cannot find anything suspicious. texcheck complains about a missing ), which I added, but it only was a problem of the text, not of the markup. This doesn't seem to be a problem any more, so I'm going to presume Martin fixed it. ;-) The docs for atexit in py3k [1] are mostly (though not all) in italics; I can't figure out why, and I'd appreciate if anyone with stronger latex-foo could take a look. Thanks, Collin Winter [1] - http://docs.python.org/dev/3.x/lib/module-atexit.html ___ 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] Italic text in the manual
Collin Winter schrieb: On 3/29/07, Fred L. Drake, Jr. [EMAIL PROTECTED] wrote: On Thursday 08 March 2007 08:42, Martin v. Löwis wrote: Certainly not. In today's copy (8.3.07, 13:30 GMT), this starts between 18.17 and 18.17.1. However, looking at the tex, I cannot find anything suspicious. texcheck complains about a missing ), which I added, but it only was a problem of the text, not of the markup. This doesn't seem to be a problem any more, so I'm going to presume Martin fixed it. ;-) The docs for atexit in py3k [1] are mostly (though not all) in italics; I can't figure out why, and I'd appreciate if anyone with stronger latex-foo could take a look. This is still the same error as in the trunk; the fix hasn't been forward-ported yet. Georg ___ 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] Italic text in the manual
On Thursday 29 March 2007 17:48, Collin Winter wrote: The docs for atexit in py3k [1] are mostly (though not all) in italics; I can't figure out why, and I'd appreciate if anyone with stronger latex-foo could take a look. This is now fixed in Py3K, and there are no further occurrances of \em on the trunk of in Py3K. The online build will catch up when the automated build runs again. -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ 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] Distutils and -framework on MacOSX
Ronald Oussoren wrote: What's wrong with adding -framework flags to the end? I do this all the time and have yet to run into problems. I don't know what's wrong. Sometimes it works for me too, but often it doesn't, and when it doesn't, putting them at the front seems to fix it. Apple's man page for ld says that placement of the -framework options is important... but doesn't say anything about where they're supposed to be. Not very helpful. I'd be very grateful if anyone could shed some light on this. It causes me no end of hassles whenever I try to compile an extension. -- 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
[Python-Dev] p2p vpn in python?
Is anyone in the Python world considering writing a P2P VPN application in Python (a la Hamachi)? -- Shane Geiger IT Director National Council on Economic Education [EMAIL PROTECTED] | 402-438-8958 | http://www.ncee.net Leading the Campaign for Economic and Financial Literacy begin:vcard fn:Shane Geiger n:Geiger;Shane org:National Council on Economic Education (NCEE) adr:Suite 215;;201 N. 8th Street;Lincoln;NE;68508;United States email;internet:[EMAIL PROTECTED] title:IT Director tel;work:402-438-8958 x-mozilla-html:FALSE url:http://www.ncee.net version:2.1 end:vcard ___ 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
