On Fri, Jan 2, 2009 at 4:51 PM, Alexander Belopolsky
wrote:
> On Fri, Jan 2, 2009 at 2:26 AM, Adam Olsen 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
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
Hi!
I'm looking at NullImporter_init in import.c and especially at the call to
PyArg_ParseTuple there. What I'm wondering is what that call will do when I
call the function with a Unicode object. Will it convert the Unicode to a
char string first, will it return the Unicode object in a certain
On Wed, 2008-12-31 at 12:51 -0600, Jason Orendorff wrote:
> On Wed, Dec 31, 2008 at 11:44 AM, Christian Heimes wrote:
> > The patch makes use of a GCC feature where labels can be used as values:
> > http://gcc.gnu.org/onlinedocs/gcc/Labels-as-Values.html . I didn't know
> > about the feature and g
On 2009-01-02 00:54, Nick Coghlan wrote:
> 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
On 2009-01-02 08:26, Adam Olsen wrote:
> On Thu, Jan 1, 2009 at 11:24 PM, Alexander Belopolsky
> wrote:
>> On Fri, Jan 2, 2009 at 12:58 AM, Adam Olsen wrote:
>> ..
>>> As C++ has more specific ways of allocating memory, they impose this
>>> restriction to annoy you into using them.
>> And so does
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 Fri, Jan 2, 2009 at 8:35 AM, Christian Heimes 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. The fact p
ACTIVITY SUMMARY (12/26/08 - 01/02/09)
Python tracker at http://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue
number. Do NOT respond to this message.
2261 open (+32) / 14372 closed (+27) / 16633 total (+59)
Open issues with patches: 771
Average
I propose a different solution to this commonprefix mess: eliminate
the function altogether. It is apparently too confusing to get right.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-de
On Sat, Jan 3, 2009 at 1:35 AM, Christian Heimes 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. The fact put
On 30 Dec, 2008, at 22:59, Benjamin Peterson wrote:
Seems that there are two ways to go.
Put back the Carbon and MacOS modules into 3.0.
Use Python 2 to build the python 3 package.
I've converted it back to 2.x for the time being. Eventually, I think
some 3.x bindings should be released.
Fo
On Fri, Jan 2, 2009 at 12:29 PM, "Martin v. Löwis" wrote:
> I propose a different solution to this commonprefix mess: eliminate
> the function altogether. It is apparently too confusing to get right.
+1
___
Python-Dev mailing list
Python-Dev@python.org
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 several issues:
1. (OP's issue.) Do we need #ifdef __cplusplus wrapper
Hi,
2009/1/2 Alexander Belopolsky :
> 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 several issues:
>
> 1. (
Hi Matthis,
On Sat, Jan 3, 2009 at 3:31 AM, Matthieu Brucher
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 have to compile the sourc
>> 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
Nicko van Someren wrote:
> On 30 Dec 2008, at 13:45, Barry Scott wrote:
> ...
> > Since I've been building 3.0 for a while now I looked at the script.
> >
> > build-install.py seems to have been half converted to py 3.0.
> > Going full 3.0 was not hard but then there is the problem of
> > the imp
>> As far as I can tell the Carbon and MacOS modules are _only_ used in
>> the setIcon() function, which is used to give pretty icon to the
>> python folder. Perhaps it might be better to have a fully Python 3
>> build system and loose the prettiness for the time being.
>
> +1
-1. I think it is
On 2 Jan, 2009, at 20:51, Bill Janssen wrote:
Nicko van Someren wrote:
On 30 Dec 2008, at 13:45, Barry Scott wrote:
...
Since I've been building 3.0 for a while now I looked at the script.
build-install.py seems to have been half converted to py 3.0.
Going full 3.0 was not hard but then th
On Wed, Dec 31, 2008 at 4:34 PM, Nicko van Someren wrote:
>
> As far as I can tell the Carbon and MacOS modules are _only_ used in the
> setIcon() function, which is used to give pretty icon to the python folder.
> Perhaps it might be better to have a fully Python 3 build system and loose
> the p
Hi!
The function PyOS_GetLastModificationTime() is documented in sys.rst as taking
a "char*". However, in reality, it takes a "char*" and a "FILE*". Actually,
it should take a "char const*", as it doesn't and shouldn't modify the path.
Further, the normal version doesn't use the path at all, th
Martin v. Löwis wrote:
> >> As far as I can tell the Carbon and MacOS modules are _only_ used in
> >> the setIcon() function, which is used to give pretty icon to the
> >> python folder. Perhaps it might be better to have a fully Python 3
> >> build system and loose the prettiness for the time b
Bill Janssen wrote:
> Martin v. Löwis wrote:
>
> > >> As far as I can tell the Carbon and MacOS modules are _only_ used in
> > >> the setIcon() function, which is used to give pretty icon to the
> > >> python folder. Perhaps it might be better to have a fully Python 3
> > >> build system and l
> Any suggestions how to deal with that issue?
Correct me if I'm wrong: it seems that the function isn't called
anymore. So I propose to just remove it (and the file it lives
in).
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://
On Friday 02 January 2009 22:30:39 Ulrich Eckhardt wrote:
> The function PyOS_GetLastModificationTime() is documented in sys.rst as
> taking a "char*". However, in reality, it takes a "char*" and a "FILE*".
> Actually, it should take a "char const*", as it doesn't and shouldn't
> modify the path. F
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 *
PyFile_From
Le Wednesday 31 December 2008 22:20:54, vous avez écrit :
> When it comes to commit privs in general, I am of the school that they
> should be handed out carefully. I for one do not want to have to
> babysit other committers to make sure that they did something
> correctly.
Last time I asked if an
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
>
> mean that th
On Fri, Jan 2, 2009 at 9:05 AM, M.-A. Lemburg 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 glance at
Hi,
Python 3.0 is released and supports unicode everywhere, great! But as pointed
by different people, bytes are required on non-Windows OS for backward
compatibility. This email is just a sum up all many issues/email threads.
Problems with Python 3.0:
(1) Invalid unicode string on the comman
On Fri, Jan 2, 2009 at 18:53, Victor Stinner
wrote:
> Le Wednesday 31 December 2008 22:20:54, vous avez écrit :
>> When it comes to commit privs in general, I am of the school that they
>> should be handed out carefully. I for one do not want to have to
>> babysit other committers to make sure tha
32 matches
Mail list logo
