> I believe the macro should be removed, as Python currently assumes Unicode
> APIs are available in a number of places.
My +1 for removal. Even 2.5 cannot be compiled without this macro, probably
no one is using this.
> This consistent with the versions
> of Windows Python currently supports. I
> Profile-guided optimization did not help much, as might be expected, it
> pushed about the same kind of optimization as the mtune/march combination.
> With gcc 4.1.3 i'm finding that profile guided optimization when trained
> on pybench or regrtest does make a measurable difference (2-5% overal
> Hello. I noticed when I removes following line in trunk/PC/pyconfig.h
>
> #define Py_WIN_WIDE_FILENAMES
>
> _fileio.c and posixmodule.c (and maybe more) cannot be compiled on
> Windows.
>
> When Py_WIN_WIDE_FILENAMES is not defined, how should python behave?
>
> - call posix functions like
Brett> They shouldn't. Maybe the tempfile module came from a third-party
Brett> that had some internal doc rule of mentioning the call signature.
Brett> Regardless, just rip it out.
Done.
Skip
___
Python-Dev mailing list
Python-Dev@python.o
>> > Currently we have no way to extract the function signatures from C
>> > code on-the-fly or in a preprocessing step (might be a good GSoC
>> > project),
Brett> It can still go on the wiki, though, so we don't forget about it.
Done.
Skip
__
On Sun, Apr 27, 2008 at 4:40 PM, Stephen J. Turnbull <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] writes:
>
> > Currently we have no way to extract the function signatures from C
> > code on-the-fly or in a preprocessing step (might be a good GSoC
> > project),
>
> +1 on GSoC, except for t
[EMAIL PROTECTED] writes:
> Currently we have no way to extract the function signatures from C
> code on-the-fly or in a preprocessing step (might be a good GSoC
> project),
+1 on GSoC, except for the bad timing (maybe somebody will start
sponsoring a "Winter Coding Sprint" event?)
__
Back in r29829, Guido commented out the security hole warning for
tempfile.mktemp:
r29829 | gvanrossum | 2002-11-22 09:56:29 -0600 (Fri, 22 Nov 2002) | 3 lines
Comment out the warnings about mktemp(). These are too annoying, and
often unavoidable.
Any thought about whether this warn
On Sun, Apr 27, 2008 at 3:29 PM, <[EMAIL PROTECTED]> wrote:
>
> Michael> It seems that any documentation or help tool worth its salt
> Michael> should fetch the parameters from the definition and so
> Michael> including them in the docstring should be redundant
> Michael> duplicati
Michael> It seems that any documentation or help tool worth its salt
Michael> should fetch the parameters from the definition and so
Michael> including them in the docstring should be redundant
Michael> duplication.
That's my position as well. Currently we have no way to extract
[EMAIL PROTECTED] wrote:
While cleaning up the documentation for the tempfile module I noticed that
the docstrings for the mk*temp functions in the module itself list their
signatures (incompletely) in the first line. I don't know if that was
intentional, but it seems both redundant and error-pr
While cleaning up the documentation for the tempfile module I noticed that
the docstrings for the mk*temp functions in the module itself list their
signatures (incompletely) in the first line. I don't know if that was
intentional, but it seems both redundant and error-prone to me. The help()
func
As part of my rewrite of warnings into C, I added a new, optional
argument to showwarning(): line, which defaults to None.
As http://bugs.python.org/issue2705 points out, though, since the
function has been documented as being allowed to be overridden, this
potentially breaks existing showwarning(
13 matches
Mail list logo
