[Python-Dev] Dealing with a desired change to warnings.showwarning()
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() implementations. That means something needs to change. One option is to introduce a new function. But what to name it? show_warning()? That small of a name change seems like asking for trouble, but showwarning_ex() just seems wrong to use in Python code. Another is that where showwarning() is called within the code, if a TypeError is raised or introspection proves the call can't work, then to try again without the 'line' argument, and raise a deprecation warning. Or try to re-architect _warnings.c to not use the 'line' argument (although it is handy for testing purposes). Anyway, people have any suggestions? -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Double specification of function signatures?
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() function already displays the signatures of Python functions. There's no need to put them in docstrings and risk having them out-of-date. For example: >>> help(tempfile.mkdtemp) Help on function mkdtemp in module tempfile: mkdtemp(suffix='', prefix='tmp', dir=None) mkdtemp([suffix, [prefix, [dir]]]) User-callable function to create and return a unique temporary directory. The return value is the pathname of the directory. Am I way off-base here? Let me know, as I have a couple minor tweaks to check in besides these. Thx, Skip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Doc-SIG] Double specification of function signatures?
[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-prone to me. The help() function already displays the signatures of Python functions. There's no need to put them in docstrings and risk having them out-of-date. For example: >>> help(tempfile.mkdtemp) Help on function mkdtemp in module tempfile: mkdtemp(suffix='', prefix='tmp', dir=None) mkdtemp([suffix, [prefix, [dir]]]) User-callable function to create and return a unique temporary directory. The return value is the pathname of the directory. Am I way off-base here? Let me know, as I have a couple minor tweaks to check in besides these. It seems that any documentation or help tool worth its salt should fetch the parameters from the definition and so including them in the docstring should be redundant duplication. Michael Foord Thx, Skip ___ Doc-SIG maillist - [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/doc-sig ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Doc-SIG] Double specification of function signatures?
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 the function signatures from C code on-the-fly or in a preprocessing step (might be a good GSoC project), but for functions written in Python I'm of the opinion the docstrings should not include function signatures. Skip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Doc-SIG] Double specification of function signatures?
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> duplication. > > That's my position as well. 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), but for functions written in Python I'm of the > opinion the docstrings should not include function signatures. They shouldn't. Maybe the tempfile module came from a third-party that had some internal doc rule of mentioning the call signature. Regardless, just rip it out. -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Warn about mktemp once again?
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 warning should be restored? We're 5+ years later. Hopefully many uses of mktemp have been removed. If we're not going to restore the warning perhaps the commented code should just be deleted. Skip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Doc-SIG] Double specification of function signatures?
[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?) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Doc-SIG] Double specification of function signatures?
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 the bad timing (maybe somebody will start > sponsoring a "Winter Coding Sprint" event?) > It can still go on the wiki, though, so we don't forget about it. -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Doc-SIG] Double specification of function signatures?
>> > 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 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Doc-SIG] Double specification of function signatures?
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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Is Py_WIN_WIDE_FILENAMES still alive?
> 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 open(2) > > - call ANSI Win32 APIs like MoveFileA > > Or maybe this macro is not used anymore? I believe the macro should be removed, as Python currently assumes Unicode APIs are available in a number of places. This consistent with the versions of Windows Python currently supports. It is possible that patches would be accepted which enable Python to be built without this functionality - in which case the next-best behavior would probably be to convert Unicode to MBCS encoded strings and call the *A versions of the API. Looking at the history for posixmodule.c etc will offer some clues as to how this could best be done. Cheers, Mark ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.6a2 execution times with various compilers
> 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% overall > time with 10-20% on some pybench tests). I haven't run benchmarks enough > times to be confident in my results yet, I'll report back with data once > I have it. I'm testing both pybench and regrtest as profiling training runs. It seems that profile guided optimization also offers some benefits on Windows (eg, http://mail.python.org/pipermail/python-dev/2007-May/072970.html), so it might be worth trying to coordinate such efforts between platforms (eg, a central document which holds results for all supported platforms sounds worthwhile, and maybe sharing the top-level script that generates the profile data, etc) Cheers, Mark ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Is Py_WIN_WIDE_FILENAMES still alive?
> 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. It is possible that patches would
be
> accepted which enable Python to be built without this functionality - in
> which case the next-best behavior would probably be to convert Unicode to
> MBCS encoded strings and call the *A versions of the API. Looking at the
> history for posixmodule.c etc will offer some clues as to how this could
> best be done.
One problem with removal, PyArg_ParseTuple doesn't have option to convert
to unicode (like "et" exists for unicode -> 8bit char buffer), so it's
harder to
report argument error.
>>> os.rename(4, 2)
Traceback (most recent call last):
File "", line 1, in
TypeError: rename() argument 1 must be string, not int
/* After removal of *A win32 APIs */
if (PyArg_ParseTuple("OO:rename", &o1, &o2)) {
convert_to_unicode(&o1); /* if these methods failed, should we report
same error above
convert_to_unicode(&o2); * by ourselves? */
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
