On 2009-01-05 23:17, Mark Hammond wrote:
On 5/01/2009 11:13 PM, M.-A. Lemburg wrote:
See above. Assertions are not meant to be checked in a production
build. You use debug builds for debugging such low-level things.
Although ironically, assertions have been disabled in debug builds on
.-A.
Lemburg
Sent: 6. janúar 2009 13:23
To: mhamm...@skippinet.com.au
Cc: python-dev@python.org
Subject: Re: [Python-Dev] #ifdef __cplusplus?
On 2009-01-05 23:17, Mark Hammond wrote:
On 5/01/2009 11:13 PM, M.-A. Lemburg wrote:
See above. Assertions are not meant to be checked in a production
build
-dev@python.org
Subject: Re: [Python-Dev] #ifdef __cplusplus?
On 2009-01-05 23:17, Mark Hammond wrote:
On 5/01/2009 11:13 PM, M.-A. Lemburg wrote:
See above. Assertions are not meant to be checked in a production
build. You use debug builds for debugging such low-level things.
Although
for the whole process isn't
a particularly nice thing to do.
Kristján
-Original Message-
From: M.-A. Lemburg [mailto:m...@egenix.com]
Sent: 6. janúar 2009 14:43
To: Kristján Valur Jónsson
Cc: mhamm...@skippinet.com.au; python-dev@python.org
Subject: Re: [Python-Dev] #ifdef __cplusplus?
On 2009-01
On 2009-01-03 04:15, Adam Olsen wrote:
On Fri, Jan 2, 2009 at 9:05 AM, M.-A. Lemburg m...@egenix.com wrote:
On 2009-01-02 08:26, Adam Olsen wrote:
Python's malloc wrappers are pretty messy. Of your examples, only
unicode-str isn't obvious what the result is, as the rest are local
to that
On 5/01/2009 11:13 PM, M.-A. Lemburg wrote:
See above. Assertions are not meant to be checked in a production
build. You use debug builds for debugging such low-level things.
Although ironically, assertions have been disabled in debug builds on
Windows - http://bugs.python.org/issue4804
On Fri, Jan 2, 2009 at 4:51 PM, Alexander Belopolsky
alexander.belopol...@gmail.com wrote:
On Fri, Jan 2, 2009 at 2:26 AM, Adam Olsen rha...@gmail.com wrote:
..
Compiling as C++ is too obscure of a feature to warrant uglifying the
code.
Malloc casts may be hard to defend, but most of python
On Friday 02 January 2009 06:17:24 Alexander Belopolsky wrote:
Since that issue is closed, I have created
http://bugs.python.org/issue4805 with a patch that restores C++
compilability of the core and a few standard modules.
Looking at the patch, I see three main changes there:
1. Remove the
On 2009-01-02 08:26, Adam Olsen wrote:
On Thu, Jan 1, 2009 at 11:24 PM, Alexander Belopolsky
alexander.belopol...@gmail.com wrote:
On Fri, Jan 2, 2009 at 12:58 AM, Adam Olsen rha...@gmail.com wrote:
..
As C++ has more specific ways of allocating memory, they impose this
restriction to annoy
David Cournapeau schrieb:
Can't those errors be found simply using appropriate warning flags in
the C compiler ? C has stopped being a subset of C++ a long time ago
Python's C code still follow the ANSI C89 standard. The fact puts 'long
time ago' in a different perspective. :)
On Sat, Jan 3, 2009 at 1:35 AM, Christian Heimes li...@cheimes.de wrote:
David Cournapeau schrieb:
Can't those errors be found simply using appropriate warning flags in
the C compiler ? C has stopped being a subset of C++ a long time ago
Python's C code still follow the ANSI C89 standard.
Hi,
2009/1/2 Alexander Belopolsky alexander.belopol...@gmail.com:
First, by copying c++-sig, let me invite C++ experts to comment on
this thread and the tracker issue:
http://mail.python.org/pipermail/python-dev/2009-January/084685.html
http://bugs.python.org/issue4805
My patch highlights
Hi Matthis,
On Sat, Jan 3, 2009 at 3:31 AM, Matthieu Brucher
matthieu.bruc...@gmail.com wrote:
When I learnt C, I was always told to explicitely cast.
Maybe your professor was used to old C :) It is discouraged practice
to cast malloc - the only rationale I can think of nowadays is when
you
When I learnt C, I was always told to explicitely cast.
Maybe your professor was used to old C :)
That's more than likely :D
Matthieu
--
Information System Engineer, Ph.D.
Website: http://matthieu-brucher.developpez.com/
Blogs: http://matt.eifelle.com and http://blog.developpez.com/?blog=92
Alexander Belopolsky wrote:
4. Should exported symbols be always declared in headers or is it ok
to just declare them as extern in .c files where they are used?
Is the concern that moving them to a header makes them part of the API?
In other words, does replacing
PyObject *
Jim Jewett schrieb:
Is the concern that moving them to a header makes them part of the API?
In other words, does replacing
PyObject *
PyFile_FromString(char *name, char *mode)
{
extern int fclose(FILE *);
...
}
with
#include stdio.h
mean that the
On Fri, Jan 2, 2009 at 9:05 AM, M.-A. Lemburg m...@egenix.com wrote:
On 2009-01-02 08:26, Adam Olsen wrote:
Python's malloc wrappers are pretty messy. Of your examples, only
unicode-str isn't obvious what the result is, as the rest are local
to that function. Even that is obvious when you
Hi!
There are lots of files that are framed with an extern C stanza when
compiled under C++. Now, I appreciate that header files are made suitable for
use with C++ with that, but WTF are those doing in .c files???
puzzled greetings
Uli
___
Ulrich Eckhardt wrote:
Hi!
There are lots of files that are framed with an extern C stanza when
compiled under C++. Now, I appreciate that header files are made suitable for
use with C++ with that, but WTF are those doing in .c files???
I believe it is to allow building the Python source
The relevant revision is r45330:
http://svn.python.org/view?rev=45330view=rev.
Author: anthony.baxter
Date: Thu Apr 13 02:06:09 2006 UTC (2 years, 8 months ago)
Log Message:
spread the extern C { } magic pixie dust around. Python itself builds now
using a C++ compiler. Still lots and lots of
Alexander Belopolsky schrieb:
The relevant revision is r45330:
http://svn.python.org/view?rev=45330view=rev.
Author: anthony.baxter
Date: Thu Apr 13 02:06:09 2006 UTC (2 years, 8 months ago)
Log Message:
spread the extern C { } magic pixie dust around. Python itself builds now
On Thu, Jan 1, 2009 at 11:05 PM, Christian Heimes li...@cheimes.de wrote:
..
You might be interested in the bug report
http://bugs.python.org/issue4665. Skip pointed out that Python 2.6 no
longer compiles with a C++ compiler due to missing casts. C++ is more
restrict when it comes to implicit
On Thu, Jan 1, 2009 at 10:17 PM, Alexander Belopolsky
alexander.belopol...@gmail.com wrote:
On Thu, Jan 1, 2009 at 11:05 PM, Christian Heimes li...@cheimes.de wrote:
..
You might be interested in the bug report
http://bugs.python.org/issue4665. Skip pointed out that Python 2.6 no
longer
On Fri, Jan 2, 2009 at 12:58 AM, Adam Olsen rha...@gmail.com wrote:
..
As C++ has more specific ways of allocating memory, they impose this
restriction to annoy you into using them.
And so does Python API: see PyMem_NEW and PyMem_RESIZE macros.
We won't be using them, and the extra casts
On Thu, Jan 1, 2009 at 11:24 PM, Alexander Belopolsky
alexander.belopol...@gmail.com wrote:
On Fri, Jan 2, 2009 at 12:58 AM, Adam Olsen rha...@gmail.com wrote:
..
As C++ has more specific ways of allocating memory, they impose this
restriction to annoy you into using them.
And so does
On Fri, Jan 2, 2009 at 2:26 AM, Adam Olsen rha...@gmail.com wrote:
..
Compiling as C++ is too obscure of a feature to warrant uglifying the
code.
Malloc casts may be hard to defend, but most of python code base
already has them, there is little to be gained from having these casts
in some
26 matches
Mail list logo
