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
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 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
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
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
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
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
> 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://
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
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
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
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
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
>> 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
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
>> 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
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
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. (
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
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
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 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
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
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
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
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 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
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 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
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 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 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
32 matches
Mail list logo
