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
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 li...@cheimes.de 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
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. :)
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
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
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.
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.
On Fri, Jan 2, 2009 at 12:29 PM, Martin v. Löwis mar...@v.loewis.de 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
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
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 a good
On Wed, Dec 31, 2008 at 4:34 PM, Nicko van Someren ni...@nicko.org 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
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, the
Bill Janssen jans...@parc.com wrote:
Martin v. Löwis mar...@v.loewis.de 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
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
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. Further, the
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,
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
On Fri, Jan 2, 2009 at 18:53, Victor Stinner
victor.stin...@haypocalc.com 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
25 matches
Mail list logo
