[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
[Python-Dev] Should TemporaryFile() return a wrapper like NamedTemporaryFile()?
Hi, I am looking into the issue http://python.org/sf/1615275 (suggested by Neal) and added a comment there. I would appreciate it if some one can check it out and comment on it. Basically, I am wondering if TemporaryFile() should return a wrapper instance (with "file" member) just like NamedTemporaryFile(). It shouldn't effect any existing code (unless I am missing something) but should help in cross-platform code. Thanks, Raghu. ___ 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] Possible bugs in test_struct
While converting test_struct to use unittest, I came across these two issues:
1) r51119 by Bob Ippolito added a test case for "SF bug 1530559:
struct.pack raises TypeError where it used to convert." (Handy diff at
http://svn.python.org/view/python/trunk/Lib/test/test_struct.py?rev=51119&r1=46679&r2=51119).
As far as I can tell, this test doesn't work, thanks to the lines
check_float_coerce = with_warning_restore(deprecated_err)
def test_1530559():
for endian in ('', '>', '<'):
for fmt in ('B', 'H', 'I', 'L', 'b', 'h', 'i', 'l'):
check_float_coerce(endian + fmt, 1.0)
check_float_coerce(endian + fmt, 1.5)
The problem is that the calls to check_float_coerce() attempt to call
the string produced by "endian + fmt", so a TypeError will always be
raised.
Fixing the test to do what was actually intended causes a TestFailed
error to be raised with the message "did not raise error for float
coerce". I'm confused as to why this is a test failure, when it seems
like "rais[ing an] error for float coerce" is exactly what we're
trying to avoid. Anyone know what's going on here?
2) test_705836() features the code
big = (1 << 25) - 1
big = math.ldexp(big, 127 - 24)
try:
packed = struct.pack(">f", big)
except OverflowError:
pass
else:
TestFailed("expected OverflowError")
Actually raising the TestFailed exception (as opposed to just
instantiating it) causes a test failure. Is this a bug in struct or a
bad test?
Thanks,
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] Should TemporaryFile() return a wrapper like NamedTemporaryFile()?
On 3/29/07, Raghuram Devarakonda <[EMAIL PROTECTED]> wrote: > Hi, > > I am looking into the issue http://python.org/sf/1615275 (suggested by > Neal) and added a comment there. I would appreciate it if some one can > check it out and comment on it. Basically, I am wondering if > TemporaryFile() should return a wrapper instance (with "file" member) > just like NamedTemporaryFile(). It shouldn't effect any existing code > (unless I am missing something) but should help in cross-platform On second thoughts, this change will break existing usages such as array.tofile(TemporaryFile()). Raghu ___ 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. ___ 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 3/29/07, Georg Brandl <[EMAIL PROTECTED]> wrote:
> Collin Winter schrieb:
> > 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.
In the interest of expanding the general level of latex fu, the
difference stems from \em version \emph: \em switches the current
font to emphasized in the current scope, whereas \emph is a command
that formats its argument emphasizedly.
Thus {\em ... } and \emph{...} achieve similar results, but \em{ ... }
switches the top-level font, which is followed by a grouping {} (which
likley does nothing).
-Mike
___
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. ___ 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] Get 2.5 changes in now, branch will be frozen soon
This is a reminder that the 2.5 branch will be frozen early next week. If there are changes you want to get into 2.5.1, they should be checked in within a few days. Be conservative! There will be a 2.5.2, it's better to wait than to have to make a new release for one rushed feature. If you don't believe, just wait until Anthony shows up at your doorstep. :-) n ___ 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
