Re: [Python-Dev] [Python-checkins] r83763 - in python/branches/py3k: Doc/library/signal.rst Lib/test/test_signal.py Misc/NEWS Modules/signalmodule.c
This is the idea just popped up. :-)
#define SIG(name) if (sig_num != SIG##name)
SIG(ABRT) SIG(FPE) SIG(ILL) SIG(INT) SIG(SEGV) SIG(TERM) {
PyErr_SetString(PyExc_ValueError, "signal number out of range");
return NULL;
}
#undef SIG
___
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-checkins] r83763 - in python/branches/py3k: Doc/library/signal.rst Lib/test/test_signal.py Misc/NEWS Modules/signalmodule.c
+valid_sig |= (sig_num == valid_sigs[cur_sig]); I think ||= is more appropriate here. ___ 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] builtin round 2.7
Hi there. I just hit a problem in my company, in the process of upgrading from stackless 2.5 to 2.7. Some rounding code, that was (foolishly) using "%.*f" string formatting to achieve floating point rounding started providing different results from before. I explained this away to QA and Developement as a) you shouldn't do that, and b) string representation of floats became better and "more correct" in 2.7. For UI rounding, I directed them to the Decimal module. So far so good. But it appears that the builtin round() method also changed. Whereas I see the changing of floating point representation in string formatting as not being very serious, why did the arithmetic function round() have to change? I don't see this mentioned in the release notes and was initially a bit puzzled by it. Hasn't anyone else been hit by the discrepancy? (and, yes, I know it is now more correct, as seen by round(5.55, 1) (5.6 in py2.5, 5.5 in py 2.7 which is correct since 5.55 is actually 5.54... ) Perhaps the release notes need updating? K ___ 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-checkins] r83763 - in python/branches/py3k: Doc/library/signal.rst Lib/test/test_signal.py Misc/NEWS Modules/signalmodule.c
Hirokazu Yamamoto wrote:
#define SIG(name) if (sig_num != SIG##name)
SIG(ABRT) SIG(FPE) SIG(ILL) SIG(INT) SIG(SEGV) SIG(TERM) {
PyErr_SetString(PyExc_ValueError, "signal number out of range");
"Out of range" doesn't seem like quite the right message here,
because it suggests a contiguous range of legal values, which
isn't the case.
--
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] [Python-checkins] r83763 - in python/branches/py3k: Doc/library/signal.rst Lib/test/test_signal.py Misc/NEWS Modules/signalmodule.c
On 7 Aug, 2010, at 10:24, Hirokazu Yamamoto wrote:
> This is the idea just popped up. :-)
>
> #define SIG(name) if (sig_num != SIG##name)
>SIG(ABRT) SIG(FPE) SIG(ILL) SIG(INT) SIG(SEGV) SIG(TERM) {
> PyErr_SetString(PyExc_ValueError, "signal number out of range");
> return NULL;
> }
> #undef SIG
What's wrong with:
switch (sig_num) {
case SIGABRT:
case SIGFPE:
...
case SIGTERM:
break;
default:
PyErr_SetString(...)
return NULL;
}
That would IMO be clearer than the macro you propose.
Ronald
>
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/ronaldoussoren%40mac.com
smime.p7s
Description: S/MIME cryptographic signature
___
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-checkins] r83763 - in python/branches/py3k: Doc/library/signal.rst Lib/test/test_signal.py Misc/NEWS Modules/signalmodule.c
On 7 August 2010 04:57, Brian Curtin wrote:
>>> -if sys.platform[:3] in ('win', 'os2') or sys.platform == 'riscos':
> The sliced check was to make it more convenient to also check "os2" at the
> same time in the first hunk of the change. Windows is "win32" regardless of
> 32 or 64-bit so that check works.
Wouldn't
if sys.platform in ('win32', 'os2', 'riscos'):
work just as well?
Paul
___
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] builtin round 2.7
2010/8/7 Kristján Valur Jónsson : > Hi there. > [...] > But it appears that the builtin round() method also changed. Whereas I see > the changing of floating point representation in string formatting as not > being very serious, why did the arithmetic function round() have to change? This was part of the short float repr changes that were backported from 3.1. The round function in 2.7 (on most platforms; barring bugs) always gives correctly rounded results; in 2.6 it was a bit less predictable in halfway cases. One reason to want round to be correctly rounded is to ensure that the repr of the result is always the 'short' one; this means that repr(round(x, 2)) will never produce results like '0.23001'. If the round function hadn't been updated to be correctly rounded then this wouldn't be true. Another reason is to make sure that string formatting and the round function finally agree with each other: both are doing the same job of rounding to some nearest decimal representation (except that one returns a float, while the other returns a string), so the results should be comparable; the discrepancy between these two operations has confused users in the past. Unfortunately, the agreement isn't quite complete, since round in 2.7 continues to use round-half-away-from-zero for actual exact halfway cases, while string formatting uses round-half-to-even (so e.g. round(0.125, 2) gives (a binary approximation to) 0.13, while format(0.125, '.2f') gives '0.12'). In 3.x they both use round-half-to-even. The only place where people are likely to notice that the round result has changed is in halfway cases, for example round(12.385, 2) (which, of course, thanks to the usual binary floating-point issues, is only actually an approximation to a halfway case). In general, if you're expecting predictable results from *decimal* rounding of *binary* approximations to *decimal* halfway cases then you're asking for trouble. For predictable rounding, use the decimal module. I recently added some text to the floating-point section of the 2.7 tutorial to help explain these round problems. > I don‘t see this mentioned in the release notes and was initially a bit > puzzled by it. True; I don't see it in the whatsnew document either. It's in Misc/NEWS, though. (Search for Issue 7117; there are several entries). Mark ___ 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-checkins] r83778 - in python/branches/py3k/Lib/test: test_import.py test_sax.py test_sys.py test_urllib.py test_urllib2.py test_xml_etree.py
Hi,
On 07/08/2010 13.09, victor.stinner wrote:
Author: victor.stinner
Date: Sat Aug 7 12:09:35 2010
New Revision: 83778
Log:
Issue #9425: skip tests if a filename is not encodable
Modified:
python/branches/py3k/Lib/test/test_import.py
python/branches/py3k/Lib/test/test_sax.py
python/branches/py3k/Lib/test/test_sys.py
python/branches/py3k/Lib/test/test_urllib.py
python/branches/py3k/Lib/test/test_urllib2.py
python/branches/py3k/Lib/test/test_xml_etree.py
Modified: python/branches/py3k/Lib/test/test_import.py
==
--- python/branches/py3k/Lib/test/test_import.py(original)
+++ python/branches/py3k/Lib/test/test_import.pySat Aug 7 12:09:35 2010
@@ -291,6 +291,11 @@
def test_import_by_filename(self):
path = os.path.abspath(TESTFN)
+encoding = sys.getfilesystemencoding()
+try:
+path.encode(encoding)
+except UnicodeEncodeError:
+self.skipTest('path is not encodable to {}'.format(encoding))
with self.assertRaises(ImportError) as c:
__import__(path)
self.assertEqual("Import by filename is not supported.",
Modified: python/branches/py3k/Lib/test/test_sax.py
==
--- python/branches/py3k/Lib/test/test_sax.py (original)
+++ python/branches/py3k/Lib/test/test_sax.py Sat Aug 7 12:09:35 2010
@@ -18,6 +18,11 @@
TEST_XMLFILE = findfile("test.xml", subdir="xmltestdata")
TEST_XMLFILE_OUT = findfile("test.xml.out", subdir="xmltestdata")
+try:
+TEST_XMLFILE.encode("utf8")
+TEST_XMLFILE_OUT.encode("utf8")
+except UnicodeEncodeError:
+raise unittest.SkipTest("filename is not encodable to utf8")
ns_uri = "http://www.python.org/xml-ns/saxtest/";
Modified: python/branches/py3k/Lib/test/test_sys.py
==
--- python/branches/py3k/Lib/test/test_sys.py (original)
+++ python/branches/py3k/Lib/test/test_sys.py Sat Aug 7 12:09:35 2010
@@ -509,8 +509,10 @@
p = subprocess.Popen([sys.executable, "-c", code],
stderr=subprocess.PIPE)
stdout, stderr = p.communicate()
self.assertEqual(p.returncode, 1)
-self.assert_(b"UnicodeEncodeError:" in stderr,
-"%r not in %s" % (b"UniodeEncodeError:", ascii(stderr)))
+self.assertIn(
+br"UnicodeEncodeError: 'utf-8' codec can't encode character "
+br"'\udcff' in position 7: surrogates not allowed",
+stderr)
This caused some failures in the buildbots:
test test_sys failed -- Traceback (most recent call last):
File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/test/test_sys.py", line
515, in test_main_invalid_unicode
stderr)
AssertionError:
b"UnicodeEncodeError: 'utf-8' codec can't encode character '\\udcff' in position 7:
surrogates not allowed" not found in
b'Traceback (most recent call last):\n File "", line 1,
in\nUnicodeEncodeError: \'ascii\' codec can\'t encode character \'\\xff\' in position
0: ordinal not in range(128)\n[32513 refs]\n'
See
http://www.python.org/dev/buildbot/all/builders/sparc%20solaris10%20gcc%203.x/builds/1338/steps/test/logs/stdio
def test_sys_flags(self):
self.assertTrue(sys.flags)
Modified: python/branches/py3k/Lib/test/test_urllib.py
==
--- python/branches/py3k/Lib/test/test_urllib.py(original)
+++ python/branches/py3k/Lib/test/test_urllib.pySat Aug 7 12:09:35 2010
@@ -232,8 +232,12 @@
except: pass
def constructLocalFileUrl(self, filePath):
-return "file://%s" % urllib.request.pathname2url(
-os.path.abspath(filePath))
+filePath = os.path.abspath(filePath)
+try:
+filePath.encode("utf8")
+except UnicodeEncodeError:
+raise unittest.SkipTest("filePath is not encodable to utf8")
+return "file://%s" % urllib.request.pathname2url(filePath)
def createNewTempFile(self, data=b""):
"""Creates a new temporary file containing the specified data,
Modified: python/branches/py3k/Lib/test/test_urllib2.py
==
--- python/branches/py3k/Lib/test/test_urllib2.py (original)
+++ python/branches/py3k/Lib/test/test_urllib2.py Sat Aug 7 12:09:35 2010
@@ -597,6 +597,10 @@
def sanepathname2url(path):
+try:
+path.encode("utf8")
+except UnicodeEncodeError:
+raise unittest.SkipTest("path is not encodable to utf8")
urlpath = urllib.request.pathname2url(path)
if os.name == "nt" and urlpath.startswith("///"):
urlpath = urlpath[2:]
Modified: python/branches/py3k/Lib/test/test_xml_etree.py
==
Re: [Python-Dev] [Python-checkins] r83763 - in python/branches/py3k: Doc/library/signal.rst Lib/test/test_signal.py Misc/NEWS Modules/signalmodule.c
On 2010/08/07 19:09, Greg Ewing wrote:
Hirokazu Yamamoto wrote:
#define SIG(name) if (sig_num != SIG##name)
SIG(ABRT) SIG(FPE) SIG(ILL) SIG(INT) SIG(SEGV) SIG(TERM) {
PyErr_SetString(PyExc_ValueError, "signal number out of range");
"Out of range" doesn't seem like quite the right message here,
because it suggests a contiguous range of legal values, which
isn't the case.
I agree, I suppose "invalid signal number" or something is better.
___
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-checkins] r83763 - in python/branches/py3k: Doc/library/signal.rst Lib/test/test_signal.py Misc/NEWS Modules/signalmodule.c
On 2010/08/07 19:18, Ronald Oussoren wrote:
On 7 Aug, 2010, at 10:24, Hirokazu Yamamoto wrote:
This is the idea just popped up. :-)
#define SIG(name) if (sig_num != SIG##name)
SIG(ABRT) SIG(FPE) SIG(ILL) SIG(INT) SIG(SEGV) SIG(TERM) {
PyErr_SetString(PyExc_ValueError, "signal number out of range");
return NULL;
}
#undef SIG
What's wrong with:
switch (sig_num) {
case SIGABRT:
case SIGFPE:
...
case SIGTERM:
break;
default:
PyErr_SetString(...)
return NULL;
}
That would IMO be clearer than the macro you propose.
Ronald
Hmm... I liked the macro idea, but nothing is wrong with switch
statement.
___
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-checkins] r83763 - in python/branches/py3k: Doc/library/signal.rst Lib/test/test_signal.py Misc/NEWS Modules/signalmodule.c
On Sat, Aug 7, 2010 at 08:21, Hirokazu Yamamoto
wrote:
> On 2010/08/07 19:18, Ronald Oussoren wrote:
>
>>
>> On 7 Aug, 2010, at 10:24, Hirokazu Yamamoto wrote:
>>
>> This is the idea just popped up. :-)
>>>
>>> #define SIG(name) if (sig_num != SIG##name)
>>>SIG(ABRT) SIG(FPE) SIG(ILL) SIG(INT) SIG(SEGV) SIG(TERM) {
>>> PyErr_SetString(PyExc_ValueError, "signal number out of range");
>>> return NULL;
>>> }
>>> #undef SIG
>>>
>>
>> What's wrong with:
>>
>> switch (sig_num) {
>> case SIGABRT:
>> case SIGFPE:
>> ...
>> case SIGTERM:
>>break;
>> default:
>> PyErr_SetString(...)
>> return NULL;
>> }
>>
>> That would IMO be clearer than the macro you propose.
>>
>> Ronald
>>
>
> Hmm... I liked the macro idea, but nothing is wrong with switch
> statement.
I had thought about doing this via switch statement. I'll propose a patch
and post it on #9324.
As for the "out of range" comment -- true, it's not technically a range on
Windows, but it matches the exception wording when we raise on Mac/Linux for
the same reason. I can change that.
___
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] mingw support?
Dear list, I was wondering whether there would ever be support for python to be build by the mingw compiler suite. I found a few patches in the internet but there were disagreeing comments on whether they are functional or not. So I would like to ask the list whether there are any technical reasons that this is so. I did a search on the python site for mingw, but all I found are explanations how to compile python modules, but not python itself. I know the question is why anybody should want to do so, but I do think that a project which depends on a non-free compiler is not free after all. Regards, Gabriel ___ 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] mingw support?
On 8/7/2010 3:55 PM, [email protected] wrote: > Dear list, > > I was wondering whether there would ever be support for python to be > build by the mingw compiler suite. I found a few patches in the > internet but there were disagreeing comments on whether they are > functional or not. > > So I would like to ask the list whether there are any technical > reasons that this is so. I did a search on the python site for mingw, > but all I found are explanations how to compile python modules, but > not python itself. > > I know the question is why anybody should want to do so, but I do > think that a project which depends on a non-free compiler is not free > after all. > There have certainly been demonstrations that Python can be compiled with mingw, but as far as I am aware what's missing is a developer sufficiently motivated to integrate that build system into the distributions and maintain it. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 DjangoCon US September 7-9, 2010http://djangocon.us/ See Python Video! http://python.mirocommunity.org/ Holden Web LLC http://www.holdenweb.com/ ___ 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] builtin round 2.7
2010/8/7 Mark Dickinson : > 2010/8/7 Kristján Valur Jónsson : >> Hi there. >> [...] >> But it appears that the builtin round() method also changed. Whereas I see >> the changing of floating point representation in string formatting as not >> being very serious, why did the arithmetic function round() have to change? > > One reason to want round to be correctly rounded is to ensure that the > repr of the result is always the 'short' one; this means that > repr(round(x, 2)) will never produce results like > '0.23001'. If the round function hadn't been updated to > be correctly rounded then this wouldn't be true. > [...] I should also point out that the pre-2.7 round function isn't consistent across common platforms, so it was already dangerous to rely on round results for halfway cases; the 2.7 version of round should be an improvement in that respect. For example, with Python 2.6.6rc1 on OS X 10.6.4, I get the (correct) result: >>> round(1.0007605, 6) 1.00076001 I'd expect to see the same result on OS X 10.5, on Windows and on 64-bit Linux boxes. But on a 32-bit installation of Ubuntu maverick (32-bit), I get the following instead: >>> round(1.0007605, 6) 1.000761 The discrepancy is due to the usual problem of the x87 FPU computing internally with 64-bit precision and then rounding the result to 53-bit precision afterwards, which can give different results from computing directly using 53-bit precision. Mark ___ 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] mingw support?
On Sun, Aug 8, 2010 at 5:55 AM, wrote: > I know the question is why anybody should want to do so, but I do > think that a project which depends on a non-free compiler is not free > after all. It's a philosophical question - Python is under a BSD style license, so the core devs (taken as a group) don't have a fundamental objection to the idea of closed source software, just a pragmatic view that open source is simply a better approach most of the time (both as a developer and as a user). This used to be more of an issue because MS didn't provide a decent free compiler for their platform. These days (since the release of Visual Studio Express), we expect that people willing to use (or support) a closed OS can cope with also using the free-as-in-beer closed compiler provided by the vendor of that OS. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ 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] mingw support?
Am 08.08.2010 02:12, schrieb Nick Coghlan: > On Sun, Aug 8, 2010 at 5:55 AM, wrote: >> I know the question is why anybody should want to do so, but I do >> think that a project which depends on a non-free compiler is not free >> after all. > > It's a philosophical question It's also a technical question. Supporting mingw on an ongoing basis is fairly difficult, for various reasons. There would be nothing inherently wrong with supporting mingw - it's just that none of the committers has found enough time and motivation to work on this (either using one of the contributed patches, or starting from scratch). Regards, Martin ___ 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] mingw support?
Nick Coghlan wrote: This used to be more of an issue because MS didn't provide a decent free compiler for their platform. These days (since the release of Visual Studio Express), we expect that people willing to use (or support) a closed OS can cope with also using the free-as-in-beer closed compiler provided by the vendor of that OS. The problem with the MS "free" compilers is that it's only a *temporary* freedom. They have a habit of withdrawing older versions when newer ones become available. Together with their other obnoxious habit of changing the C runtime in incompatible ways with every release, the result is that extensions for versions of Python older than N years can no longer be compiled with any legally-available free MS compiler. If you're talking about pragmatism, I think this situation causes very pragmatic difficulties. -- 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
[Python-Dev] Adding a token
I'm trying to add a '?' token to the parser, and weird things are happening. I've added a #define to token.h, an entry to _PyParser_TokenNames in tokenizer.c and case for it in PyToken_OneChar(). But it's behaving as though the tokenizer is not recognising my token. I put in some printfs to find out whether PyToken_OneChar() is recognising it. The results are confusing: while running pgen, PyToken_OneChar() is being called and recognising the new token correctly. However, it doesn't seem to be getting called *at all* when parsing Python code. I don't see how this can happen, because pgen seems to use the same tokenizing code as Python itself. Is there anything else I need to do? Does some file need to be manually re-made? -- 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] Adding a token
2010/8/7 Greg Ewing : > I'm trying to add a '?' token to the parser, and weird things > are happening. Why do you even have to add a new token? You can just put the literal '?' in the grammar. -- Regards, Benjamin ___ 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] Adding a token
Benjamin Peterson wrote: Why do you even have to add a new token? You can just put the literal '?' in the grammar. I don't see how that can be sufficient. All the other tokens have entries in the three places I mentioned, and there's no way that pgen can generate those automatically just from seeing a '?' in the grammar. I just tried an experiment -- I changed the grammar to accept '?' as an alternative to '+', and tried to use the parser module to parse "1?2". It reported a SyntaxError. -- 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] mingw support?
On 8/7/2010 9:27 PM, Greg Ewing wrote: > Nick Coghlan wrote: > >> This used to be more of an issue because MS didn't provide a decent >> free compiler for their platform. These days (since the release of >> Visual Studio Express), we expect that people willing to use (or >> support) a closed OS can cope with also using the free-as-in-beer >> closed compiler provided by the vendor of that OS. > > The problem with the MS "free" compilers is that it's only a > *temporary* freedom. They have a habit of withdrawing older > versions when newer ones become available. Together with their > other obnoxious habit of changing the C runtime in incompatible > ways with every release, the result is that extensions for > versions of Python older than N years can no longer be compiled > with any legally-available free MS compiler. > > If you're talking about pragmatism, I think this situation > causes very pragmatic difficulties. > +0.5 Using the MS stuff is a pragmatic solution in the first place, since it allows the software to be released. It's true that there may be problems down the line. Microsoft's recent apparent reduction of support for dynamic languages represents a disturbing trend to me, though that is not directly related to the question raised by this thread. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 DjangoCon US September 7-9, 2010http://djangocon.us/ See Python Video! http://python.mirocommunity.org/ Holden Web LLC http://www.holdenweb.com/ ___ 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] Adding a token
Aaargh, I think I've found out what the problem is. I'm using framework builds on MacOSX. I have two experimental builds of Python 3.1 around, plus a standard one installed in /Library. It's picking up the version of Python.framework in /Library/Frameworks instead of the one in the local build directory that python.exe was explicitly linked with. Now I'm confused about why my *other* experimental build worked -- the one I've been using for yield-from and codef -- because it should have suffered from the same problem. And when I tried to use it again just now, it did indeed not work. Does anyone know if there's a way to tell Apple's linker to use a framework from a specific location and not go looking anywhere else? In the meantime, I think I'll switch to a non-framework build for this project. -- 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] Adding a token
On Aug 7, 2010, at 9:15 PM, Greg Ewing wrote: > Does anyone know if there's a way to tell Apple's linker to > use a framework from a specific location and not go looking > anywhere else? $ DYLD_FRAMEWORK_PATH= See dyld(1) for other relevant magic. Cheers, -- Ivan Krstić, via mobile > ___ 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] Adding a token
In article <[email protected]>, Greg Ewing wrote: > Does anyone know if there's a way to tell Apple's linker to > use a framework from a specific location and not go looking > anywhere else? I haven't tested it myself but you should be able to prevent problems like that by specifying a non-default framework name with the --with-framework-name= option to configure. See Mac/README. -- Ned Deily, [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
