[issue11896] Save on Close fails in IDLE, from Linux system
New submission from marcus harris harrismh...@charter.net: Under some circumstances, which I will detail later down the note, if I click File -- Close without explicitly saving, and without running the module with Run -- Run Module , then the last changes I made to the file do not get saved. The save dialogue pop-up does appear, and I do select YES--- I want to save before closing--- but when I re-open the file (IDLE or vi) the changes are not there... as though the save binding did not work, or like there was some timing glitch that prevented the save somehow before the edit window closed down. The error is not solid, in that, if the file is larger (significantly) then the File -- Close (select Yes on the dialogue) does work... ?? The work around is to do either 1) run the module, or 2) explicitly click File -- Save. The alleged bug can be reproduced on both of my primary desk machines, Linux systems, using IDLE on 2.6, 2.7, and 3.2/ These are the instructions for reproducing this little snag: 1) Open a new edit window with File -- New Window 2) Enter the following code on the first two lines: def testfunc(): return None 3) Click File -- Save( testit.py ) 4) Click File -- Close 5) Open the file with File -- Recent Files ( select testit.py ) 6) Use the edit window to place these three lines above testfunc: # comment block ## 7) ClickFile -- Close 8) When the Save on Close dialogue appears select Yes 9) Re-open the file with File -- Recent Files ( select testit.py ) 10) The comment block will not be there... didn't save. Running on Ubuntu 9.10 (all updates) Tk 8.5.x reproduced on built-in 2.6 compiled from sources... 2.73.2 kind regards, m harris -- components: IDLE, Library (Lib), Tkinter messages: 134194 nosy: marcus777, terry.reedy priority: normal severity: normal status: open title: Save on Close fails in IDLE, from Linux system type: behavior versions: Python 2.6, Python 2.7, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11896 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11896] Save on Close fails in IDLE, from Linux system
marcus harris harrismh...@charter.net added the comment: Terry Reedy was not able to reproduce this snag on an XP system; however, suggested there might be a real save on close error on the linux side... also requested to be place on the nosy list... -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11896 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11896] Save on Close fails in IDLE, from Linux system
Ned Deily n...@acm.org added the comment: Thanks for the precise test case. I am able to reproduce the failure on OS X using the MacPorts X11-Tk Tkinter but not with the standard OS X AquaTk Tkinter. -- assignee: - ned.deily nosy: +ned.deily stage: - needs patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11896 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11888] Add C99's log2() function to the math library
Mark Dickinson dicki...@gmail.com added the comment: See also issue 3724. I'm -0 on this: between log(x, 2) and int.bit_length, there's not much need for log2. log(x, 2) should be plenty accurate enough for most numerical needs; the exception is when you're taking log base 2 of an integer and need a guarantee of exact results for powers of 2, and int.bit_length generally solves that problem. The main issue is that we'd have to provide (and maintain) our own implementation of log2 for Windows (and other OSs that don't have all the C99 support. Solaris?) That implementation should, ideally: - provide exact values for powers of 2, and - be monotonic. and that's not trivial. As Raymond points out, on x86 / x64 we might be able to use inline assembly directly; that would probably cover us for Windows. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11888 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11888] Add C99's log2() function to the math library
STINNER Victor victor.stin...@haypocalc.com added the comment: The main issue is that we'd have to provide (and maintain) our own implementation of log2 for Windows (and other OSs that don't have all the C99 support. Solaris?) No, we don't have to. Python has already a lot of optional functions, see for example the os module. We can provide log2() only if the C library has this function. -- nosy: +haypo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11888 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10596] modulo operator bug
Mark Dickinson dicki...@gmail.com added the comment: Raymond: just curious---why do you ask? Did this fix break something? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10596 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11888] Add C99's log2() function to the math library
Mark Dickinson dicki...@gmail.com added the comment: We can provide log2() only if the C library has this function. Big -1 from me: I'd hate to see working Python scripts written on Unix fail on Windows because of a missing log2. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11888 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11888] Add C99's log2() function to the math library
Mark Dickinson dicki...@gmail.com added the comment: Rather than reinventing the wheel, it may be worth looking at what numpy does here. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11888 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11888] Add C99's log2() function to the math library
Mark Dickinson dicki...@gmail.com added the comment: it may be worth looking at what numpy does here. ... or it may not. NumPy just uses (approximation to 1/log(2)) * log(x) when log2 doesn't already exist. And indeed, on Windows: Python 2.7.1 |EPD 7.0-2 (64-bit)| (r271:86832, Dec 2 2010, 10:23:25) [MSC v.1500 64 bit (AMD64)] on win32 Type help, copyright, credits or license for more information. import numpy numpy.log2(8.0) 2.9996 I think we should be able to do better than this. :-) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11888 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11895] pybench prep_times calculation error
Marc-Andre Lemburg m...@egenix.com added the comment: Mikhail Terekhov wrote: New submission from Mikhail Terekhov ter...@gmail.com: For some time now my builds of python 3.2 on x86_64 platform in SuSE OBS are failing depending on the phase of the moon. The spec file for the python3-base package uses 'make profile-opt' command to build and Makefile.pre.in uses pybench.py for profile guided optimization. The pybench.py fails sometimes with the '* Internal Error (use --debug to display the traceback)' error. Adding --debug gives 'calibration setup did not work' i.e. some of the self.overhead_times values in the Test.calibrate_test method became negative. It happens for the NestedForLoops test. The source inspection shows that most probably it was forgotten to divide by CALIBRATION_LOOPS when calculating prep_times. The patch against current head is attached, it solves the problem. Good catch. Your analysis is correct. Interesting that it took more than 6 years to discover this bug... looks like CPUs got more than 20 times faster since back then. -- nosy: +lemburg ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11895 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11892] Compiler warning: warning: implicit declaration of function 'finite'
Changes by Mark Dickinson dicki...@gmail.com: -- nosy: +mark.dickinson ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11892 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10042] total_ordering
Francesco Ricciardi francescor2...@yahoo.it added the comment: On the one hand, it's not just a matter of total_ordering and rich comparison operators, because all user defined operators may return NotImplemented when they get types that they don't know how to handle. On the other hand, if such a decision is taken, a long path should be planned to move handling of unknown types from one way to the other. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10042 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11897] [PATCH] Documentation: fix typo, absolute_import not absolute_imports
New submission from intgr ma...@juffo.org: The Porting Python 2 Code to Python 3 guide currently says: from __future__ import absolute_imports However it should be singular: from __future__ import absolute_import -- assignee: docs@python components: Documentation files: absolute_import_singular.patch keywords: patch messages: 134206 nosy: docs@python, intgr priority: normal severity: normal status: open title: [PATCH] Documentation: fix typo, absolute_import not absolute_imports versions: Python 3.2 Added file: http://bugs.python.org/file21746/absolute_import_singular.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11897 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11897] [PATCH] Documentation: fix typo, absolute_import not absolute_imports
Roundup Robot devnull@devnull added the comment: New changeset 05a7d3048c49 by Ezio Melotti in branch '3.2': #11897: Fix typo in porting howto. Patch by Marti Raudsepp. http://hg.python.org/cpython/rev/05a7d3048c49 New changeset 968fba3f34b3 by Ezio Melotti in branch 'default': #11897: Merge with 3.2. http://hg.python.org/cpython/rev/968fba3f34b3 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11897 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11897] [PATCH] Documentation: fix typo, absolute_import not absolute_imports
Ezio Melotti ezio.melo...@gmail.com added the comment: Fixed, thanks for the patch! -- assignee: docs@python - ezio.melotti nosy: +ezio.melotti resolution: - fixed stage: - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11897 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11885] argparse docs needs fixing
Roundup Robot devnull@devnull added the comment: New changeset 0f084f150198 by Ezio Melotti in branch '2.7': #11885: capitalize Python. http://hg.python.org/cpython/rev/0f084f150198 New changeset fb6affc7b973 by Ezio Melotti in branch '3.2': #11885: capitalize Python. http://hg.python.org/cpython/rev/fb6affc7b973 New changeset 9fece8c3a1a9 by Ezio Melotti in branch 'default': #11885: Merge with 3.2. http://hg.python.org/cpython/rev/9fece8c3a1a9 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11885 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11885] argparse docs needs fixing
Ezio Melotti ezio.melo...@gmail.com added the comment: Fixed, thanks for the report. -- resolution: - fixed stage: - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11885 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11885] argparse docs needs fixing
Changes by Ezio Melotti ezio.melo...@gmail.com: -- assignee: docs@python - ezio.melotti ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11885 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11898] Sending binary data with a POST request in httplib can cause Unicode exceptions
New submission from Bernhard Rosenkraenzer b...@arklinux.org: Sending e.g. a JPEG file with a httplib POST request (e.g. through mechanize) can result in an error like this: File /usr/lib64/python2.7/httplib.py, line 947, in request self._send_request(method, url, body, headers) File /usr/lib64/python2.7/httplib.py, line 988, in _send_request self.endheaders(body) File /usr/lib64/python2.7/httplib.py, line 941, in endheaders self._send_output(message_body) File /usr/lib64/python2.7/httplib.py, line 802, in _send_output msg += message_body UnicodeDecodeError: 'ascii' codec can't decode byte 0xff in position 2566: invalid start byte The code triggering this is the attempt to merge the msg and message_body into a single request in httplib.py lines 791+ The patch I'm attaching treats an invalid string of unknown encoding (e.g. binary data wrapped as string) like something that isn't a string. Works for me with the patch. -- components: Library (Lib) files: python-2.7.1-fix-httplib-UnicodeDecodeError.patch keywords: patch messages: 134211 nosy: bero priority: normal severity: normal status: open title: Sending binary data with a POST request in httplib can cause Unicode exceptions type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file21747/python-2.7.1-fix-httplib-UnicodeDecodeError.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11898 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11898] Sending binary data with a POST request in httplib can cause Unicode exceptions
Changes by Ezio Melotti ezio.melo...@gmail.com: -- nosy: +ezio.melotti, orsenthil ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11898 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1294232] Error in metaclass search order
Nick Coghlan ncogh...@gmail.com added the comment: I think PEP 3115 is OK - the error about all metaclasses inheriting from type was a mistake on my part (I thought the ability to create non-type metaclasses went away along with old-style classes, but I was simply wrong on that point). That got me curious as to how the explicit inheritance from object + explicit non-type metaclass case was working in 2.7, and it turns out it *does* share the same initial metaclass determination error as 3.x - it is just that build_class() is embedded in ceval.c rather than being published as a builtin. So I have two conclusions: - to match existing behaviour when __metaclass__ is not an instance of type(), __build_class__ still needs one special case where it bypasses the normal metaclass calculation: when an explicit metaclass exists and is *not* an instance of type. - after we get 3.x sorted, we will want to backport this to the ceval version of build_class() in 2.7 -- versions: +Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1294232 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11877] Change os.fsync() to support physical backing store syncs
Steffen Daode Nurpmeso sdao...@googlemail.com added the comment:
I'm convinced. And i've rewritten the patch.
Now fsync(2) is always called first *regardless* of the new
optional argument. The documentation is (a little bit) better
now. And i've added support for NetBSD, AIX and Linux; though:
- for AIX i'm testing (O_SYNC O_DSYNC) which is almost
definitely the wrong test for this, but (a) i don't know when
fsync_range() has been introduced (seems to be many years) and
(b) i've never really worked on AIX.
(I only have the documentation:
http://www.filibeto.org/unix/aix/lib/rel/5.3/basetrf1.pdf.)
- i've added sync_file_range() on Linux because of
SYNC_FILE_RANGE_WAIT_AFTER in the hope that it means something
even though the manual page says something else - but Linux and
documentation is something by itself.
http://lwn.net/Articles/178199/ states
Providing all three flags guarantees that those pages are
actually on disk when the call returns.
- it seems OpenBSD, FreeBSD, Solaris 11 and HP/UX provide data
reliability through fsync(2) alone, see e.g. the notes near EOF
of the following Solaris 11 file:
http://www.filibeto.org/sun/lib/solaris11-express-docs/2010.11/E19963_01/html/821-1464/fcntl.h-3head.html#fcntl.h-3head
--
title: Mac OS X fsync() should really be fcntl(F_FULLFSYNC) - Change
os.fsync() to support physical backing store syncs
Added file: http://bugs.python.org/file21748/11877.2.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11877
___diff --git a/Doc/library/os.rst b/Doc/library/os.rst
--- a/Doc/library/os.rst
+++ b/Doc/library/os.rst
@@ -798,7 +798,7 @@
Availability: Unix.
-.. function:: fsync(fd)
+.. function:: fsync(fd, full_fsync=False)
Force write of file with filedescriptor *fd* to disk. On Unix, this calls
the
native :c:func:`fsync` function; on Windows, the MS :c:func:`_commit`
function.
@@ -807,6 +807,14 @@
``f.flush()``, and then do ``os.fsync(f.fileno())``, to ensure that all
internal
buffers associated with *f* are written to disk.
+ Note that on most operating systems :c:func:`fsync` only ensures that
+ the data is flushed to the disk device, *not* that it has been written
+ by the device itself. The optional *full_fsync* argument can be used to
+ issue a physical backing store synchronization request on operating
+ systems which do support such an operation, e.g. on NetBSD by calling
+ :c:func:`fsync_range` with the :data:`FDISKSYNC` flag, or on Mac OS X by
+ calling :c:func:`fcntl` with the :data:`F_FULLFSYNC` command.
+
Availability: Unix, and Windows.
diff --git a/Modules/posixmodule.c b/Modules/posixmodule.c
--- a/Modules/posixmodule.c
+++ b/Modules/posixmodule.c
@@ -13,6 +13,9 @@
/* See also ../Dos/dosmodule.c */
+#ifdef __linux__
+# define _GNU_SOURCE
+#endif
#ifdef __APPLE__
/*
* Step 1 of support for weak-linking a number of symbols existing on
@@ -2119,13 +2122,74 @@
#ifdef HAVE_FSYNC
PyDoc_STRVAR(posix_fsync__doc__,
-fsync(fildes)\n\n\
-force write of file with filedescriptor to disk.);
-
-static PyObject *
-posix_fsync(PyObject *self, PyObject *fdobj)
-{
-return posix_fildes(fdobj, fsync);
+fsync(fildes, full_fsync=False)\n\n
+force write of file buffers with fildes to disk;\n
+if full_fsync is True it is tried to synchronize physical backing store.);
+
+static PyObject *
+posix_fsync(PyObject *self, PyObject *args, PyObject *kwargs)
+{
+PyObject *retval;
+auto PyObject *fdobj;
+auto int full_fsync = 1;
+static char *keywords[] = {fd, full_fsync, NULL };
+
+retval = NULL;
+if (!PyArg_ParseTupleAndKeywords(args, kwargs, O|i, keywords,
+ fdobj, full_fsync))
+goto jleave;
+
+retval = posix_fildes(fdobj, fsync);
+if (retval != Py_None)
+goto jleave;
+
+/* See issue 11877 discussion (and issue 11277 for OS X sparse file bug) */
+# if (((defined __AIX || defined _AIX) \
+ defined O_SYNC defined O_DSYNC) || \
+ (defined __APPLE__ defined F_FULLFSYNC) || \
+ (defined __NetBSD__ defined FDISKSYNC) || \
+ (defined __linux__ defined SYNC_FILE_RANGE_WAIT_AFTER))
+if (full_fsync != 0) {
+int res, fd;
+Py_DECREF(retval);
+
+retval = NULL;
+fd = PyObject_AsFileDescriptor(fdobj);
+if (fd 0)
+goto jleave;
+if (!_PyVerify_fd(fd)) {
+retval = posix_error();
+goto jleave;
+}
+
+Py_BEGIN_ALLOW_THREADS
+# if defined __AIX || defined _AIX
+res = fsync_range(fd, O_SYNC, 0, 0);
+# endif
+# ifdef __APPLE__
+res = fcntl(fd, F_FULLFSYNC);
+# endif
+# ifdef __NetBSD__
+res = fsync_range(fd, FFILESYNC|FDISKSYNC, 0, 0);
+# endif
+# ifdef __linux__
+res = sync_file_range(fd, 0, 0, (SYNC_FILE_RANGE_WAIT_BEFORE |
+
[issue11877] Change os.fsync() to support physical backing store syncs
Steffen Daode Nurpmeso sdao...@googlemail.com added the comment: P.S.: dito Linux and NetBSD. I've reused preprocessor tests we've discovered internally over the past years, but i cannot test this here. I could test Linux next Tuesday, though. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11877 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11877] Change os.fsync() to support physical backing store syncs
STINNER Victor victor.stin...@haypocalc.com added the comment: 11877.2.diff: On Mac OS X, fsync(fd, full_sync=True); fsync(fd) do a full sync twice. You should restore the old file flags at fsync() exit. Or this surprising behaviour should be documented. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11877 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11885] argparse docs needs fixing
Éric Araujo mer...@netwok.org added the comment: most of optparse* -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11885 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11584] email.decode_header fails if msg.__getitem__ returns Header object
R. David Murray rdmur...@bitdance.com added the comment: My fix (and the tests) for this are wrong. decode_header returns (binary, charset) pairs, but the chunks list is (string, charset) pairs. -- stage: committed/rejected - needs patch status: closed - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11584 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1322] platform.dist() has unpredictable result under Linux
Éric Araujo mer...@netwok.org added the comment: [Zooko] I just read back through this ticket, but I didn't understand exactly what MAL wanted to have different from what this Python function currently does: It may be this: It's better to follow the approach taken by lsb_release and then add calling lsb_release as one of the methods taken by _dist_try_harder() (using platform.popen()) should the parsers fail. This avoids spawning a process in most cases. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1322 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11899] TarFile.gettarinfo modifies self.inodes
New submission from Michael Gold mg...@qnx.com: When I call tar.gettarinfo (where tar is a TarFile instance), the inode information is inserted into tar.inodes. If I later call tar.gettarinfo on a linked file, the returned TarInfo will have type LNKTYPE. I think it's incorrect to store this information in gettarinfo. It should be done in addfile. A comment in gettarinfo states Is it a hardlink to an already archived file?. But tar.inodes is modified in gettarinfo, and there's no reason to expect that the file will actually be archived, or will be archived with the same properties. Bad links could result if the returned tarinfo object were modified before calling addfile. I suggest changing the code as follows: - Create a static method (or non-member function) to fill in a given TarInfo object with stat/lstat/fstat results. This would need a boolean dereference parameter. (No TarFile instance should be required to create a TarInfo.) - Have tar.gettarinfo call the above function; then fill in tarinfo.tarfile, and modify tarinfo.type to LNKNAME if applicable. Don't modify self.inodes. - In tar.addfile, call fstat, and store the inode info into self.inodes. -- components: Library (Lib) messages: 134220 nosy: lars.gustaebel, mgold-qnx priority: normal severity: normal status: open title: TarFile.gettarinfo modifies self.inodes type: behavior versions: Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11899 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11877] Change os.fsync() to support physical backing store syncs
Steffen Daode Nurpmeso sdao...@googlemail.com added the comment:
Ok, 11877.3.diff uses either-or.
--
Added file: http://bugs.python.org/file21749/11877.3.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11877
___diff --git a/Doc/library/os.rst b/Doc/library/os.rst
--- a/Doc/library/os.rst
+++ b/Doc/library/os.rst
@@ -798,7 +798,7 @@
Availability: Unix.
-.. function:: fsync(fd)
+.. function:: fsync(fd, full_fsync=False)
Force write of file with filedescriptor *fd* to disk. On Unix, this calls
the
native :c:func:`fsync` function; on Windows, the MS :c:func:`_commit`
function.
@@ -807,6 +807,14 @@
``f.flush()``, and then do ``os.fsync(f.fileno())``, to ensure that all
internal
buffers associated with *f* are written to disk.
+ Note that on most operating systems :c:func:`fsync` only ensures that
+ the data is flushed to the disk device, *not* that it has been written
+ by the device itself. The optional *full_fsync* argument can be used to
+ issue a physical backing store synchronization request on operating
+ systems which do support such an operation, e.g. on NetBSD by calling
+ :c:func:`fsync_range` with the :data:`FDISKSYNC` flag, or on Mac OS X by
+ calling :c:func:`fcntl` with the :data:`F_FULLFSYNC` command.
+
Availability: Unix, and Windows.
diff --git a/Modules/posixmodule.c b/Modules/posixmodule.c
--- a/Modules/posixmodule.c
+++ b/Modules/posixmodule.c
@@ -13,6 +13,9 @@
/* See also ../Dos/dosmodule.c */
+#ifdef __linux__
+# define _GNU_SOURCE
+#endif
#ifdef __APPLE__
/*
* Step 1 of support for weak-linking a number of symbols existing on
@@ -2119,13 +2122,66 @@
#ifdef HAVE_FSYNC
PyDoc_STRVAR(posix_fsync__doc__,
-fsync(fildes)\n\n\
-force write of file with filedescriptor to disk.);
-
-static PyObject *
-posix_fsync(PyObject *self, PyObject *fdobj)
-{
-return posix_fildes(fdobj, fsync);
+fsync(fildes, full_fsync=False)\n\n
+force write of file buffers with fildes to disk;\n
+if full_fsync is True it is tried to synchronize physical backing store.);
+
+static PyObject *
+posix_fsync(PyObject *self, PyObject *args, PyObject *kwargs)
+{
+PyObject *retval = NULL;
+auto PyObject *fdobj;
+auto int full_fsync = 1;
+static char *keywords[] = {fd, full_fsync, NULL };
+
+if (!PyArg_ParseTupleAndKeywords(args, kwargs, O|i, keywords,
+ fdobj, full_fsync))
+goto jleave;
+
+/* See issue 11877 discussion (and issue 11277 for OS X sparse file bug) */
+# if (((defined __AIX || defined _AIX) \
+ defined O_SYNC defined O_DSYNC) || \
+ (defined __APPLE__ defined F_FULLFSYNC) || \
+ (defined __NetBSD__ defined FDISKSYNC) || \
+ (defined __linux__ defined SYNC_FILE_RANGE_WAIT_AFTER))
+if (full_fsync != 0) {
+int res, fd = PyObject_AsFileDescriptor(fdobj);
+if (fd 0)
+goto jleave;
+if (!_PyVerify_fd(fd)) {
+retval = posix_error();
+goto jleave;
+}
+
+Py_BEGIN_ALLOW_THREADS
+# if defined __AIX || defined _AIX
+res = fsync_range(fd, O_SYNC, 0, 0);
+# endif
+# ifdef __APPLE__
+res = fcntl(fd, F_FULLFSYNC);
+# endif
+# ifdef __NetBSD__
+res = fsync_range(fd, FFILESYNC|FDISKSYNC, 0, 0);
+# endif
+# ifdef __linux__
+res = sync_file_range(fd, 0, 0, (SYNC_FILE_RANGE_WAIT_BEFORE |
+ SYNC_FILE_RANGE_WRITE |
+ SYNC_FILE_RANGE_WAIT_AFTER));
+# endif
+Py_END_ALLOW_THREADS
+
+if (res 0) {
+retval = posix_error();
+goto jleave;
+}
+Py_INCREF(Py_None);
+retval = Py_None;
+} else
+# endif
+retval = posix_fildes(fdobj, fsync);
+
+jleave:
+return retval;
}
#endif /* HAVE_FSYNC */
@@ -9484,7 +9540,8 @@
{fchdir, posix_fchdir, METH_O, posix_fchdir__doc__},
#endif
#ifdef HAVE_FSYNC
-{fsync, posix_fsync, METH_O, posix_fsync__doc__},
+{fsync, (PyCFunction)posix_fsync, METH_VARARGS|METH_KEYWORDS,
+posix_fsync__doc__},
#endif
#ifdef HAVE_SYNC
{sync,posix_sync, METH_NOARGS, posix_sync__doc__},
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11877] Change os.fsync() to support physical backing store syncs
Changes by Steffen Daode Nurpmeso sdao...@googlemail.com: Removed file: http://bugs.python.org/file21742/11877.optarg-1.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11877 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11877] Change os.fsync() to support physical backing store syncs
Changes by Steffen Daode Nurpmeso sdao...@googlemail.com: Removed file: http://bugs.python.org/file21748/11877.2.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11877 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9742] Python 2.7: math module fails to build on Solaris 9
David Schnur david.sch...@dartware.com added the comment: I encountered this problem when updating from 2.6.4 to 2.7.1 on Solaris 8, which also doesn't have 'round'. I tried srmadsen's --whole-archive option, but it wasn't recognized by the (somewhat ancient) tools on that machine. I solved the problem by just editing the $(BUILDPYTHON) target to include Python/pymath.o, as Jerzy Kozera did. Should configure perhaps take care of this when it detects no round? It seems like this has slipped in simply because very few people still use systems without round. -- nosy: +dschnur ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9742 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11777] Executor.map does not submit futures until iter.next() is called
Éric Araujo mer...@netwok.org added the comment: Just a bystander remark: when you use present in the commit message and Misc/NEWS entry (like in “Executor.map does not submit futures until iter.next() is called”), I don’t know whether it is the behavior being fixed (“X used to do Y”) or the new, correct behavior (“X now does Z”). -- nosy: +eric.araujo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11777 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11899] TarFile.gettarinfo modifies self.inodes
Michael Gold mg...@qnx.com added the comment: Actually, TarFile should also have a separate method to take a TarInfo instance and modify its type to LNKTYPE if applicable. gettarinfo can call that. This way the user can use a TarInfo object created before any files are added, and can easily get this linking behaviour if desired. (Note: In my initial message, I had LNKNAME where I meant LNKTYPE.) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11899 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1294232] Error in metaclass search order
Guido van Rossum gu...@python.org added the comment: Thanks for diving deep! How much of this can we claim as a bug and how much as a feature? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1294232 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10932] distutils.core.setup - data_files misbehaviour ?
Éric Araujo mer...@netwok.org added the comment:
Patch looks good. Detail: I’d find a call to basename more readable than
i.split('/')[-1:][0].
Does this need a test in test_manifest too? A doc update?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10932
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1294232] Error in metaclass search order
Nick Coghlan ncogh...@gmail.com added the comment: As near as I can tell, the only visible behavioural change with Daniel's patch (updated as per my last comment) will be that the two error cases noted above (i.e. when an explicit metaclass or the first parent type's metaclass is not the most derived metaclass) will now correctly invoke the real metaclass immediately, instead of first traversing up the chain to type(), which then jumps all the way back down to the most derived metaclass. The new special case is actually just a matter of preserving the current behaviour in the one situation where that is the right thing to do. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1294232 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1294232] Error in metaclass search order
Nick Coghlan ncogh...@gmail.com added the comment: Commenting on the latest patch here, since the Rietveld integration isn't coping with the hg extdiff output (I would guess that the revision numbers in the pathnames are confusing the script that attempts to determine the base revision). Aside from the note above about needing to restore the special case handling for non-type metaclasses, the only other recommendation I have is for the new metaclass invocation tests to add a second metaclass to the hierarchy and explicitly check the order of the __new__ calls, as in the original examples above that invoked the wrong M_A/M_B/M_A sequence. Those tests will then also be applicable to Python 2.7 (which doesn't have __prepare___). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1294232 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6191] HTMLParser attribute parsing - 2 test cases when it fails
Paweł Widera mo...@man.poznan.pl added the comment: No. As the value of the href attribute is not suppose to contain spaces, I'd rather expect the parser to assume that there is an ending missing before the space. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6191 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11877] Change os.fsync() to support physical backing store syncs
Changes by Santoso Wijaya santoso.wij...@gmail.com: -- nosy: +santa4nt ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11877 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11898] Sending binary data with a POST request in httplib can cause Unicode exceptions
Changes by Santoso Wijaya santoso.wij...@gmail.com: -- nosy: +santa4nt ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11898 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11382] some posix module functions unnecessarily release the GIL
Charles-Francois Natali neolo...@free.fr added the comment: Is there anything I can do to help this move forward ? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11382 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11900] 2.7.1 unicode subclasses not calling __str__() for print statement
New submission from Dave Opstad dave.ops...@monotypeimaging.com:
Python 2.7.1 doesn't appear to do the usual implicit call to str() for
subclasses of unicode. In the following snippet, I would have expected print
myTest and print str(myTest) to behave the same:
class Test(unicode):
... def __str__(self):
... print In __str__
... return (u*** + self + u ***).encode('utf-8')
... def __unicode__(self):
... print In __unicode__
... return u*** + self + u ***
...
myTest = Test(uabc)
print myTest
abc
print str(myTest)
In __str__
*** abc ***
print unicode(myTest)
In __unicode__
*** abc ***
--
components: Unicode
messages: 134231
nosy: opstad
priority: normal
severity: normal
status: open
title: 2.7.1 unicode subclasses not calling __str__() for print statement
type: behavior
versions: Python 2.7
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11900
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11901] Docs for sys.hexversion should give the algorithm
New submission from R. David Murray rdmur...@bitdance.com: I went to write a test that would trigger something if it was run on 3.3.0, and had to look in the source code to figure out what the hexversion for that would be. I think the hexversion algorithm should be documented in its sys entry. -- assignee: docs@python components: Documentation messages: 134232 nosy: docs@python, r.david.murray priority: normal severity: normal stage: needs patch status: open title: Docs for sys.hexversion should give the algorithm type: feature request ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11901 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11900] 2.7.1 unicode subclasses not calling __str__() for print statement
R. David Murray rdmur...@bitdance.com added the comment: You subclassed unicode. So print printed the value of your unicode object, which didn't need coercion. -- nosy: +r.david.murray resolution: - invalid stage: - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11900 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11885] argparse docs needs fixing
Boštjan Mejak bostjan.me...@gmail.com added the comment: Eric, you are great! Thanks for fixing the docs. ;) -- Added file: http://bugs.python.org/file21750/unnamed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11885 ___Eric, you are great! Thanks for fixing the docs. ;) ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11900] 2.7.1 unicode subclasses not calling __str__() for print statement
R. David Murray rdmur...@bitdance.com added the comment: For the record, this isn't as simple as I made it sound. See, for example, issue 9196. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11900 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11877] Change os.fsync() to support physical backing store syncs
Charles-Francois Natali neolo...@free.fr added the comment: I'm -10 on sync_file_range on Linux: - it doesn't update the file metadata, so there's a high chance of corruption after a crash - last time I checked, it didn't flush the disk cache (well, it probably does if barriers are enabled, but that's also the case with fsync) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11877 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11902] typo in argparse doc's: action..
New submission from Vladimir Rutsky altsy...@gmail.com: There is a typo in argparse module documentation: The ``nargs`` keyword argument associates a different number of command-line arguments with a single action.. (two dots at end). Patch based on official http://svn.python.org/projects/python/branches/py3k/ repository, but typo is also noted in Python 2.7 documentation. -- assignee: docs@python components: Documentation files: argparse_typo_action_dot_dot.patch keywords: patch messages: 134237 nosy: docs@python, rutsky priority: normal severity: normal status: open title: typo in argparse doc's: action.. versions: Python 2.7, Python 3.4 Added file: http://bugs.python.org/file21751/argparse_typo_action_dot_dot.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11902 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11900] 2.7.1 unicode subclasses not calling __str__() for print statement
Dave Opstad dave.ops...@monotypeimaging.com added the comment: I guess I was confused by the inconsistency with Python 3, which *does* call the __str__ method, even though, again, no coercion is needed: Python 3.2 (r32:88452, Feb 20 2011, 10:19:59) [GCC 4.0.1 (Apple Inc. build 5493)] on darwin Type help, copyright, credits or license for more information. class X(str): ... def __str__(self): ... print(In __str__) ... return *** + self + *** ... x = X(abcde) print(x) In __str__ *** abcde *** print(str(x)) In __str__ *** abcde *** -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11900 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11903] Incorrect test code in test_logging.py
New submission from Stefan Behnel sco...@users.sourceforge.net: In test file test_logging.py, around line 2359, list.append() is called with two arguments instead of one. I suppose it is meant to be called with a tuple. class ModuleLevelMiscTest(BaseTest): [...] def _test_log(self, method, level=None): called = [] patch(self, logging, 'basicConfig', lambda *a, **kw: called.append(a, kw)) # -- components: Tests messages: 134239 nosy: scoder priority: normal severity: normal status: open title: Incorrect test code in test_logging.py versions: Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11903 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11904] incorrect reStructuredText formatting in argparse module
New submission from Vladimir Rutsky altsy...@gmail.com: In Python 2.7 and 3 branch at http://svn.python.org/projects/python/branches/py3k/ file Doc/library/argparse.rst has incorrectly formatted list at line 648: * ``'store'`` - This just stores the argument's value. This is the default action. For example:: Second line must be indented according to first line. Next item at line 656 has invalid indentation too. -- assignee: docs@python components: Documentation messages: 134240 nosy: docs@python, rutsky priority: normal severity: normal status: open title: incorrect reStructuredText formatting in argparse module versions: Python 2.7, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11904 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11905] typo in argparse doc's: missing dot at end of sentence
New submission from Vladimir Rutsky altsy...@gmail.com: There is missed dot at end of sentence in argparse module documentation. Please see attached patch for details. Patch based on official http://svn.python.org/projects/python/branches/py3k/ repository, but typo is also noted in Python 2.7 documentation. -- assignee: docs@python components: Documentation files: argparse_typo_missing_dot.patch keywords: patch messages: 134241 nosy: docs@python, rutsky priority: normal severity: normal status: open title: typo in argparse doc's: missing dot at end of sentence versions: Python 2.7, Python 3.4 Added file: http://bugs.python.org/file21752/argparse_typo_missing_dot.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11905 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11902] typo in argparse doc's: action..
Roundup Robot devnull@devnull added the comment: New changeset e8464256b4d7 by Ezio Melotti in branch '2.7': #11902: Fix typo in argparse doc. Noticed by Vladimir Rutsky. http://hg.python.org/cpython/rev/e8464256b4d7 New changeset 88df1ef4eec8 by Ezio Melotti in branch '3.2': #11902: Fix typo in argparse doc. Noticed by Vladimir Rutsky. http://hg.python.org/cpython/rev/88df1ef4eec8 New changeset 56825d54dc84 by Ezio Melotti in branch 'default': #11902: Merge with 3.2. http://hg.python.org/cpython/rev/56825d54dc84 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11902 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11903] Incorrect test code in test_logging.py
Santoso Wijaya santoso.wij...@gmail.com added the comment: Introduced in changeset c7f7672b70a9. -- nosy: +santa4nt ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11903 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11902] typo in argparse doc's: action..
Ezio Melotti ezio.melo...@gmail.com added the comment: Fixed, thanks for the report. BTW we are using HG now (http://hg.python.org/cpython) and patches should be submitted against the oldest applicable branch (either 2.7 or 3.2 is fine in this case). More info at http://docs.python.org/devguide/. -- assignee: docs@python - ezio.melotti nosy: +ezio.melotti resolution: - fixed stage: - committed/rejected status: open - closed versions: +Python 3.2, Python 3.3 -Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11902 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11584] email.decode_header fails if msg.__getitem__ returns Header object
R. David Murray rdmur...@bitdance.com added the comment: Note that when this is fixed, make_header on the return value from decode_header will fail because it doesn't know now to handle unknown-8bit. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11584 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11903] Incorrect test code in test_logging.py
Santoso Wijaya santoso.wij...@gmail.com added the comment: Simple fix. -- keywords: +patch Added file: http://bugs.python.org/file21753/issue11903_py33.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11903 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11904] incorrect reStructuredText formatting in argparse module
Roundup Robot devnull@devnull added the comment: New changeset 79f3ae389dae by Ezio Melotti in branch '2.7': #11904: fix indentation in argparse doc. Noticed by Vladimir Rutsky. http://hg.python.org/cpython/rev/79f3ae389dae New changeset 473fada5f1b7 by Ezio Melotti in branch '3.2': #11904: fix indentation in argparse doc. Noticed by Vladimir Rutsky. http://hg.python.org/cpython/rev/473fada5f1b7 New changeset 8568762381b4 by Ezio Melotti in branch 'default': #11904-#11905: Merge typo fixes with 3.2. http://hg.python.org/cpython/rev/8568762381b4 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11904 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11905] typo in argparse doc's: missing dot at end of sentence
Roundup Robot devnull@devnull added the comment: New changeset f6ea7abc4eb2 by Ezio Melotti in branch '2.7': #11905: fix missing full stop in argparse doc. Noticed by Vladimir Rutsky. http://hg.python.org/cpython/rev/f6ea7abc4eb2 New changeset 15f482996880 by Ezio Melotti in branch '3.2': #11905: fix missing full stop in argparse doc. Noticed by Vladimir Rutsky. http://hg.python.org/cpython/rev/15f482996880 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11905 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11905] typo in argparse doc's: missing dot at end of sentence
Ezio Melotti ezio.melo...@gmail.com added the comment: Fixed, thanks for the report! -- assignee: docs@python - ezio.melotti nosy: +ezio.melotti resolution: - fixed stage: - committed/rejected status: open - closed versions: +Python 3.2, Python 3.3 -Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11905 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11904] incorrect reStructuredText formatting in argparse module
Ezio Melotti ezio.melo...@gmail.com added the comment: Fixed, thanks for the report! -- assignee: docs@python - ezio.melotti nosy: +ezio.melotti resolution: - fixed stage: - committed/rejected status: open - closed versions: +Python 3.2, Python 3.3 -Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11904 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11900] 2.7.1 unicode subclasses not calling __str__() for print statement
R. David Murray rdmur...@bitdance.com added the comment: Well, it's possible I'm wrong and you've found a bug. There are numerous differences between 2 and 3 in both string handling and special method handling, though, so it may be hard to pin down. If you poke around a bit more and still think it is a bug, please reopen. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11900 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11877] Change os.fsync() to support physical backing store syncs
Steffen Daode Nurpmeso sdao...@googlemail.com added the comment:
Charles-Francois Natali wrote:
I'm -10 on sync_file_range on Linux:
[...] last time I checked [...]
I just looked at
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=fs/sync.c;h=c38ec163da6ccba00a0146c75606c1b548b31343;hb=HEAD
and it seems - as far as i understand what i read - that you're
still right; and, furthermore, that fsync() does everything
anyway. (But here an idiot is talking about *very* complicated
stuff.)
I've also searched for the called filemap_write_and_wait_range()
and found the commit message for
2daea67e966dc0c42067ebea015ddac6834cef88 as part of that;
very interesting in respect to our issue here.
I will wait before i update the patch though, just in case some
experienced NetBSD or AIX user posts some message. For OpenBSD
i think i can confirm that fsync(2) alone is enough after taking
a (shallow, all shallow) look into kernel/vfs_syscalls.c and
ufs/ffs/{ffs_softdep.c,softdep.h}.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11877
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11877] Change os.fsync() to support physical backing store syncs
Charles-Francois Natali neolo...@free.fr added the comment: and it seems - as far as i understand what i read - that you're still right; and, furthermore, that fsync() does everything anyway. (But here an idiot is talking about *very* complicated stuff.) I just double-checked, and indeed, fsync does flush the disk cache when barriers are enabled on several FS, while sync_file_range does not. So sync_file_range should definitely not be used on Linux. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11877 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1294232] Error in metaclass search order
Daniel Urban urban.dani...@gmail.com added the comment: I'm attaching the updated patch. Changes: - Special casing objects we can't do the metaclass computation for. - Tests for these. - Adding tests for the order of __new__ calls. The special case isn't just checking if the object is a class, but instead checking if isinstance(obj, type) and issubclass(obj, type), because I think only these are the objects we can do the metaclass calculation for. All other objects (including classes which are not real metaclasses (they do not derive from type) and functions) are used as is, without any metaclass calculation. (It's late here, so it is quite possible that I've overlooked someting in this part.) (I'm using hg extdiff because the normal hg diff results in a longer and harder to read patch, but if it's needed I will send a normal diff.) -- Added file: http://bugs.python.org/file21754/issue_1294232_3.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1294232 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1322] platform.dist() has unpredictable result under Linux
Marc-Andre Lemburg m...@egenix.com added the comment: Éric Araujo wrote: Éric Araujo mer...@netwok.org added the comment: [Zooko] I just read back through this ticket, but I didn't understand exactly what MAL wanted to have different from what this Python function currently does: It may be this: It's better to follow the approach taken by lsb_release and then add calling lsb_release as one of the methods taken by _dist_try_harder() (using platform.popen()) should the parsers fail. This avoids spawning a process in most cases. Indeed. You also need to make sure that the function doesn't suddenly return different output for setups that are supported and work as advertised. Note that the Debian mention in the string output is not really incorrect, given that Ubuntu and other distros are based on the work done by the Debian project. Looking back, I shouldn't have added the function to begin with and just use Linux in the platform string. It's causing too much maintenance overhead. Perhaps deprecating it altogether is more appropriate. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1322 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1294232] Error in metaclass search order
Daniel Urban urban.dani...@gmail.com added the comment:
I've just realized, that my patch still breaks a case, that previously worked:
when the bases are not classes.
This works in 3.2, but not with my patch:
class Foo: # not a subclass of type!
... def __new__(mcls, name='foo', bases=(), namespace={}):
... self = super().__new__(mcls)
... self.name = name
... return self
...
foo1 = Foo('foo1')
foo1.name
'foo1'
foo2 = Foo('foo2')
foo2.name
'foo2'
class foo3(foo1, foo2):pass
...
foo3
__main__.Foo object at 0xb74aa96c
foo3.name
'foo3'
This raises a TypeError: metaclass conflict: the metaclass of a derived class
must be a (non-strict) subclass of the metaclasses of all its bases. In this
case the *type* of all of its bases is the same (Foo), but that type is not a
metaclass, but a regular class.
Right now I don't know if this is a real problem, or how to solve it.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1294232
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11903] Incorrect test code in test_logging.py
Vinay Sajip vinay_sa...@yahoo.co.uk added the comment: Checked in, see changeset fecf9e6d7630 - thanks. -- assignee: - vinay.sajip nosy: +vinay.sajip resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11903 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9196] Improve docs for string interpolation %s re Unicode strings
Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com: -- nosy: +Arfrever ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9196 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11846] Remove non-guaranteed implementation details from docs.
Anthony Long antl...@gmail.com added the comment: I'll have a doc patch shortly. Also, I am working on defining a solid range. Memory is not an issue like it was back in 1991 when this range was originally implemented, so we can go higher and get a bigger performance boost. This will be very important (to some, admittedly) in Python 3, where there is no distinction between PyInts and PyLongs (more processing req'd), which could benefit from further optimization of the range. Going to be doing benchmarking, -256 to 256 seems like a good place to start. If anyone has app's i should benchmark with in mind, feel free to let me know. -- resolution: - accepted title: Implementation question for (-5) - 256 caching, and doc update for c-api/int.html - Remove non-guaranteed implementation details from docs. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11846 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11906] Test_argparse failure but only in interactive mode
New submission from Terry J. Reedy tjre...@udel.edu: (3.1 not checked because it seems not to have test_argparse) Python 2.7 or 3.2, WinXP these pass: C:\Programs\Python27python -m test.regrtest test_argparse C:\Programs\Python32python -m test test_argparse [1/1] test_argparse 1 test OK. C:\Programs\Python32python -m test -v test_argparse C:\Programs\Python32python -c from test import test_argparse as t; t.test_main() Ran 1536 tests in 6.188s OK but interactively (command window interpreter or IDLE shell, 3.2 or 2.7) from test import test_argparse as t; t.test_main() gives two failures related to extra spaces in usage string (I added a couple of newlines for clarity). I have no idea if problem is with argparse, test_argparse, regrtest, unittest, or interactive versus batch mode. == FAIL: test_groups_parents (test.test_argparse.TestParentParsers) -- Traceback (most recent call last): File C:\Programs\Python32\lib\test\test_argparse.py, line 2217, in test_groups_parents '''.format(self.main_program))) File C:\Programs\Python32\lib\test\test_argparse.py, line 29, in assertEqual super(TestCase, self).assertEqual(obj1, obj2) AssertionError: 'usage: [-h] [-w W] [-x X] [-y Y | -z Z]\n\noptional arguments:\n -h, --help s [truncated]... != 'usage: [-h] [-w W] [-x X] [-y Y | -z Z]\n\noptional arguments:\n -h, --help [truncated]... - usage: [-h] [-w W] [-x X] [-y Y | -z Z] + usage: [-h] [-w W] [-x X] [-y Y | -z Z] ?+ optional arguments: -h, --help show this help message and exit -y Y -z Z g: gd -w W -x X == FAIL: test_parent_help (test.test_argparse.TestParentParsers) -- Traceback (most recent call last): File C:\Programs\Python32\lib\test\test_argparse.py, line 2188, in test_parent_help '''.format(self.main_program))) File C:\Programs\Python32\lib\test\test_argparse.py, line 29, in assertEqual super(TestCase, self).assertEqual(obj1, obj2) AssertionError: 'usage: [-h] [-b B] [--d D] [--w W] [-y Y] a z\n\npositional arguments:\n a\n [truncated]... != 'usage: [-h] [-b B] [--d D] [--w W] [-y Y] a z\n\npositional arguments:\n a\n [truncated]... - usage: [-h] [-b B] [--d D] [--w W] [-y Y] a z + usage: [-h] [-b B] [--d D] [--w W] [-y Y] a z ?+ positional arguments: a z optional arguments: -h, --help show this help message and exit -b B --w W c: --d D x: -y Y -- Ran 1536 tests in 29.438s FAILED (failures=2) Traceback (most recent call last): File pyshell#11, line 1, in module from test import test_argparse as t; t.test_main() File C:\Programs\Python32\lib\test\test_argparse.py, line 4423, in test_main support.run_unittest(__name__) File C:\Programs\Python32\lib\test\support.py, line 1145, in run_unittest _run_suite(suite) File C:\Programs\Python32\lib\test\support.py, line 1128, in _run_suite raise TestFailed(err) test.support.TestFailed: multiple errors occurred -- components: Library (Lib) messages: 134259 nosy: bethard, terry.reedy priority: normal severity: normal status: open title: Test_argparse failure but only in interactive mode type: behavior versions: Python 2.7, Python 3.2, Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11906 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9228] Make changes in the PATH and PATHEXT on installation
Nick Coghlan ncogh...@gmail.com added the comment: That's not correct - we've merely pointed out that it isn't as easy as most people seem to think. For the POSIX world, there is a version management scheme based on symlinks in /usr/bin (or /usr/local/bin) and it is easy to add and remove entries independently. PATH on windows, on the other hand, is a size limited string that can easily exceed the bounds on development machines due to the absurdly long installation paths used by many Windows development tools (with Visual Studio itself being one of the worst offenders). PEP 397 goes into some detail as to how the (lack of) version management is an issue for the automatically created file associations, and similar problems exist for the command line equivalents. Batch files that launch development environments with changes to set PATH/PATHEXT/INCLUDES/LIBS etc correctly are not an uncommon sight in Windows development, so including the correct Python directory just becomes one more line in the launch scripts. Non-command line users simply rely on the existing start menu shortcuts and the file associations to launch double-clicked files. That limits the beneficiaries of this change to people that: 1. Want to use the command line; and 2. Do not already have a custom Development Environment command line launch script. Fixing this is NOT trivial, and, to my knowledge, we have never been offered a patch that implements it. -- nosy: +ncoghlan resolution: rejected - stage: committed/rejected - status: pending - open title: Make changes in the path and pathext on installation - Make changes in the PATH and PATHEXT on installation ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9228 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11846] Remove non-guaranteed implementation details from docs.
Raymond Hettinger raymond.hettin...@gmail.com added the comment: Memory is not an issue like it was back in 1991 when this range was originally implemented, so we can go higher and get a bigger performance boost. Please don't do this. Memory is still important to a lot of people. Also, there is *very* little payoff for numbers outside the -5 to 256 range. If we're to spend memory, we can do it in other places (like bigger freelists or somesuch). We should remove the documentation entries that discuss non-guaranteed implementation details FWIW, I've changed my thinking on this. With documentation, these details are very difficult to find-out about. Instead of removing them, they should be marked as non-guaranteed implementation specific details or they can be moved to a separate section. -- assignee: - rhettinger ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11846 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11846] Remove non-guaranteed implementation details from docs.
Anthony Long antl...@gmail.com added the comment: My plan is to document it, as it exists, in the current implementation. That's a start atleast, and will provide an entry point for further documentation in the future should it be changed again. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11846 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1294232] Error in metaclass search order
Daniel Urban urban.dani...@gmail.com added the comment: Okay, probably the check in my previous patch was too strict (sorry for the noise). I'm attaching an updated patch again. Now the algorithm in __build_class__ is this: 1. If an object is explicitly given with the metaclass keyword, that is the starting metaclass. 2. Else if there are bases, the type of the first base is the starting metaclass (note, that this possibly will be replaced later, but before the __prepare__ call). 3. Else the starting metaclass is type. 4. If the starting metaclass is a class, do the metaclass calculation, so the starting metaclass may be replaced with its most derived descendant. 5. Else we cannot do the metaclass calculation, so use the starting metaclass as is. There are also tests for these cases, and the example in msg134256 now works too. -- Added file: http://bugs.python.org/file21755/issue11256_4.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1294232 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1294232] Error in metaclass search order
Changes by Daniel Urban urban.dani...@gmail.com: Removed file: http://bugs.python.org/file21755/issue11256_4.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1294232 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1294232] Error in metaclass search order
Changes by Daniel Urban urban.dani...@gmail.com: Added file: http://bugs.python.org/file21756/issue_1294232_4.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1294232 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
