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
+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:
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
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
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;
On 7 August 2010 04:57, Brian Curtin brian.cur...@gmail.com 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
2010/8/7 Kristján Valur Jónsson krist...@ccpgames.com:
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
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
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,
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
On Sat, Aug 7, 2010 at 08:21, Hirokazu Yamamoto
ocean-c...@m2.ccsnet.ne.jpwrote:
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)
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
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.
So I
2010/8/7 Mark Dickinson dicki...@gmail.com:
2010/8/7 Kristján Valur Jónsson krist...@ccpgames.com:
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
On Sun, Aug 8, 2010 at 5:55 AM, li...@gabriel-striewe.de 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
Am 08.08.2010 02:12, schrieb Nick Coghlan:
On Sun, Aug 8, 2010 at 5:55 AM, li...@gabriel-striewe.de 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
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
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
2010/8/7 Greg Ewing greg.ew...@canterbury.ac.nz:
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
___
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
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
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
On Aug 7, 2010, at 9:15 PM, Greg Ewing greg.ew...@canterbury.ac.nz 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=path command
See dyld(1) for other relevant magic.
Cheers,
23 matches
Mail list logo
