In article <4c5e2f7d.5080...@canterbury.ac.nz>,
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 speci
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
>
__
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
di
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 ca
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
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
Python-
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
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 com
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
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)
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 roun
On 8/7/2010 3:55 PM, li...@gabriel-striewe.de 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.
>
>
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
reas
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
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 num
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
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
pyt
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 par
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 che
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 NU
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 con
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 Develo
+valid_sig |= (sig_num == valid_sigs[cur_sig]);
I think ||= is more appropriate here.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/pyth
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
__
24 matches
Mail list logo
