[issue12042] What's New multiprocessing example error
Ezio Melotti ezio.melo...@gmail.com added the comment: The workflow to prepare a patch using Mercurial is pretty much the same as SVN: # get a clone (checkout) of the repository hg clone http://hg.python.org/cpython # select the branch where you want to fix the issue hg update 2.7 # make changes on the file(s) and make a patch hg diff issue12042.diff See also http://docs.python.org/devguide/setup.html Also note that 2.6 only receives security fixes, so it can't be fixed there. All the whatsnew files are also included in the following versions though, so it might be worth preparing a patch against 2.7. -- nosy: +ezio.melotti versions: +Python 2.7 -Python 2.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12042 ___ ___ 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: Thanks, Victor. -- ___ 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
[issue9971] Optimize BufferedReader.readinto
STINNER Victor victor.stin...@haypocalc.com added the comment: You don't want to backport the optimization to at least 3.2? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9971 ___ ___ 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: Just adding more notes on that by reactivating one of haypo's links from #8604. (And: maybe some Linux documentation should be updated?) From Theodore Ts'o, http://www.linuxfoundation.org/news-media/blogs/browse/2009/03/don’t-fear-fsync: As the Eat My Data presentation points out very clearly, the only safe way according that POSIX allows for requesting data written to a particular file descriptor be safely stored on stable storage is via the fsync() call. Linux’s close(2) man page makes this point very clearly: A successful close does not guarantee that the data has been successfully saved to disk, as the kernel defers writes. It is not common for a file system to flush the buffers when the stream is closed. If you need to be sure that the data is physically stored use fsync(2). Why don’t application programmers follow these sage words? These three reasons are most often given as excuses: - (Perceived) performance problems with fsync() - The application only needs atomicity, but not durability - The fsync() causing the hard drive to spin up unnecessarily in laptop_mode (Don't ask me why i'm adding this note though. I should have searched for it once i've opened that issue? Bah!!! Ts'o did not write that article for me. He'd better hacked.) -- ___ 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
[issue12060] Python doesn't support real time signals
Steffen Daode Nurpmeso sdao...@googlemail.com added the comment: Dunno. The patch is not completely safe. Yeah it will not work without atomic ops. Unfortunately the C standart seems to go into a direction noone understands - as if a atomic_compare_and_swap() would not suffice! Do you know any machine language which reflects what that standart draft describes? I don't. The NSIG detection of Modules/signalmodule.c uses 64 as a fallback. 32 seems to be more reasonable. And you test against it instead of RTMAX in the patch. (signalmodule.c also exports Python constants RTMIN and RTMAX even though the standart explicitely allows these values to be non-constants; http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/signal.h.html; last time i've done anything on signals - in 2005 - that was used nowhere - Linux, FreeBSD - though.) Often there is a huge whole in between NSIG and RTMIN, but struct Handlers is 8 or 12 bytes (unless the compiler does the alignment - ouuh), so 32 unused members in Handlers[] will not cost the world anyway; on Mac OS X (no RTSIG support?!? ;) Python is at least 6 megabytes of memory anyway. And does anyone actually know why the last time i looked after this (on Linux, then) realtime signals had a default action EQ SIGABRT? Armchair crouchers... -- nosy: +sdaoden ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12060 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5723] Incomplete json tests
Antoine Pitrou pit...@free.fr added the comment: Comments: - I don't like the fact that skip_unless_cjson() uses unittest internals. Why can't you write something like: skip_unless_cjson = skipUnless(...) - instead of self.mod, self.json would be nicer - you could also export self.loads, self.dumps for easier access - you could also have two base classes exporting all this instead of repeating the attribute-setting for every test class -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5723 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12059] hashlib does not handle missing hash functions correctly
Changes by Antoine Pitrou pit...@free.fr: -- nosy: +gregory.p.smith ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12059 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12060] Python doesn't support real time signals
Antoine Pitrou pit...@free.fr added the comment: Is it a theoretical concern or does it affect real software? -- nosy: +pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12060 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12060] Python doesn't support real time signals
STINNER Victor victor.stin...@haypocalc.com added the comment: Is it a theoretical concern or does it affect real software? It's more theoretical. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12060 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12060] Python doesn't support real time signals
STINNER Victor victor.stin...@haypocalc.com added the comment: Yeah it will not work without atomic ops. ... Or we can maybe block the signals (all signals or just one signal?) using pthread_sigmask(SIG_BLOCK) while we access the Handlers array. But pthread_sigmask() is not available on all OSes. On my Linux box, Python 3.3 says that signal.NSIG is equal to 65 which looks correct. does anyone actually know why the last time i looked after this (on Linux, then) realtime signals had a default action EQ SIGABRT? The manpage says The default action for an unhandled real-time signal is to terminate the receiving process. It is an arbitrary choice. Why do you care about the default action? The NSIG detection of Modules/signalmodule.c uses 64 as a fallback. 32 seems to be more reasonable. And you test against it instead of RTMAX in the patch. I don't understand: I don't use RTMAX in my patch. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12060 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12062] Buffered I/O inconsistent with unbuffered I/O in certain cases
New submission from Genstein python...@genstein.net: Reporting this as requested by Antoine Pitrou: Under certain circumstances in Python 3.2 (r32:88445) it's possible for buffered I/O to lose data before it is written and/or return the wrong results when reading. I tripped over this issue whilst writing an assembler which first writes out a bunch of binary data and then goes back over it in a somewhat arbitrary order patching addresses. The following code demonstrates the issue: [code] START = 0 MID = 1 LENGTH = 4 def test(buffering): f = open(test.bin, w+b, buffering = buffering) for i in range(LENGTH): f.write(b'\x00') f.seek(MID) f.read(1) f.write(b'\x00') f.seek(MID) f.write(b'\x01') f.seek(START) f.seek(MID) print(f.read(1)) f.close() print(Buffered result: ) test(-1) print(Unbuffered result:) test(0) [end code] Output on both Gentoo and Vista is: Buffered result: b'\x00' Unbuffered result: b'\x01' Expected output is b'\x01' in both cases. The issue is reproducible with larger files provided that the constants are increased ~proportionally (START 0, MID 500, LENGTH 1000 for example). Transposing the buffered/unbuffered tests and/or using different buffer sizes for the buffered test seem have no effect. The lengthy code at this URL also demonstrates the issue: http://pastebin.com/xqrzKr5D The above was produced from this code, which was autogenerated by intercepting my assembler's output. -- components: IO messages: 135830 nosy: genstein priority: normal severity: normal status: open title: Buffered I/O inconsistent with unbuffered I/O in certain cases type: behavior versions: Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12062 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12062] Buffered I/O inconsistent with unbuffered I/O in certain cases
STINNER Victor victor.stin...@haypocalc.com added the comment: If you add from _pyio import open to the example, unbuffered and buffered tests give the same result :-) -- nosy: +haypo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12062 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12060] Python doesn't support real time signals
Steffen Daode Nurpmeso sdao...@googlemail.com added the comment:
On my Linux box, Python 3.3 says that signal.NSIG is equal to 65
which looks correct.
On FreeBSD NSIG only counts old signals (32, one 32 bit mask),
SIGRTMIN is 65 and SIGRTMAX is 126.
Our internal old signal.h states
* If we do have realtime signals, #rtmin is 35 (i.e.,
* #nsig, FreeBSD+) or something like 38 or even 40 (Linux),
* and #rtmax is most likely 64 (Linux) or 128 (FreeBSD+).
so that this seems to be somewhat constant in time.
(#rtmin: we take some of those RT sigs for internal purposes if
possible. This was maybe a bad and expensive design decision.)
Why do you care about the default action?
* \brief Hooking program crashes (\psa crash.h crash.h\epsa).
* \note
* Installed hooks (normally) execute from within an internal
* signal handler!
So many syscalls for things which don't matter almost ever.
And that may even cost context-switches sometimes.
I don't understand: I don't use RTMAX in my patch.
+for (signum = 1; signum NSIG; signum++) {
This will not catch the extended signal range on FreeBSD.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12060
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12062] Buffered I/O inconsistent with unbuffered I/O in certain cases
Antoine Pitrou pit...@free.fr added the comment: Here is a patch with assorted tests. -- keywords: +patch nosy: +barry, benjamin.peterson, georg.brandl, pitrou priority: normal - release blocker stage: - patch review versions: +Python 2.7, Python 3.1, Python 3.3 Added file: http://bugs.python.org/file21980/bufbug.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12062 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12062] Buffered I/O inconsistent with unbuffered I/O in certain cases
STINNER Victor victor.stin...@haypocalc.com added the comment: open(test.bin, w+b, buffering=-1) creates a BufferedRandom object. In the _pyio module, BufferedRandom overrides the write() method to undo readahead, whereas the _io module reuses bufferedwriter_write() for bufferedrandom_methods and bufferedwriter_methods. I suppose that the problem is just that _io.BufferedRandom.write() doesn't undo readahead. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12062 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3974] collections.namedtuple uses exec to create new classes
Kristján Valur Jónsson krist...@ccpgames.com added the comment: Yes, exec is unholy:) For embedding Python into a console game we have removed the python compiler. exec and eval don't work. This saves space and is also a security feature. I had to modify the collections module so that namedtuple() just returns tuple. Fortunately, no part of the standard library that uses namedtuple actually uses the actual names, everyone just uses it as a tuple. So that approach works. Another problem with the Eval approach is code duplication. A third could arguably be that there is no namedtuple base class. Now, replacing namedtuples with tuples works in the standardlib _currentlyt_, but I'm happy to have found an alternative implementation, for future safety. I only wish it were not hidden away as a diff in a feature request. -- nosy: +krisvale ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3974 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12062] Buffered I/O inconsistent with unbuffered I/O in certain cases
Changes by Nadeem Vawda nadeem.va...@gmail.com: -- nosy: +nadeem.vawda ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12062 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12063] tokenize module appears to treat unterminated single and double-quoted strings inconsistently
New submission from Devin Jeanpierre jeanpierr...@gmail.com:
Tokenizing `' 1 2 3` versus `''' 1 2 3` yields different results.
Tokenizing `' 1 2 3` gives:
1,0-1,1:ERRORTOKEN '
1,2-1,3:NUMBER '1'
1,4-1,5:NUMBER '2'
1,6-1,7:NUMBER '3'
2,0-2,0:ENDMARKER ''
while tokenizing `''' 1 2 3` yields:
Traceback (most recent call last):
File prog.py, line 4, in module
tokenize.tokenize(iter([''' 1 2 3]).next)
File /usr/lib/python2.6/tokenize.py, line 169, in tokenize
tokenize_loop(readline, tokeneater)
File /usr/lib/python2.6/tokenize.py, line 175, in tokenize_loop
for token_info in generate_tokens(readline):
File /usr/lib/python2.6/tokenize.py, line 296, in generate_tokens
raise TokenError, (EOF in multi-line string, strstart)
tokenize.TokenError: ('EOF in multi-line string', (1, 0))
Apparently tokenize decides to re-tokenize after the erroneous quote in the
case of a single-quote, but not a triple-quote. I guess that this is because
retokenizing the rest of the file after an unclosed triple-quote would be
expensive; however, I've also been told it's very strange and possibly wrong
for tokenize to be inconsistent this way.
If this is the right behavior, I guess I'd like it if it were documented. This
sort of thing is confusing / potentially misleading for users of the tokenize
module. Or at least, when I saw how single quotes were handled, I assumed
incorrectly that all quotes were handled that way.
--
messages: 135836
nosy: Devin Jeanpierre
priority: normal
severity: normal
status: open
title: tokenize module appears to treat unterminated single and double-quoted
strings inconsistently
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12063
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12048] Python 3, ZipFile Bug In Chinese
Changes by Antoine Pitrou pit...@free.fr: -- nosy: +haypo versions: +Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12048 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12048] Python 3, ZipFile Bug In Chinese
STINNER Victor victor.stin...@haypocalc.com added the comment: This is a duplicate of #10801, issue fixed in Python 3.2 or later by 33543b4e0e5d. Should we backport the fix to Python 3.1, or you can upgrade to Python 3.2? Output with Python 3.2: ╕┤╝■ test.txt. -- versions: -Python 3.2, Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12048 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12048] Python 3, ZipFile Bug In Chinese
Changes by STINNER Victor victor.stin...@haypocalc.com: -- components: +Library (Lib), Unicode ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12048 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12048] Python 3, ZipFile Bug In Chinese
Changes by STINNER Victor victor.stin...@haypocalc.com: -- nosy: +georg.brandl ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12048 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10801] zipfile.ZipFile().extractall() header mismatch for non-ASCII characters
STINNER Victor victor.stin...@haypocalc.com added the comment: Issue #12048 is a duplicate of this bug, but with Python 3.1. Should we backport the fix to Python 3.1? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10801 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12057] HZ codec has no test
STINNER Victor victor.stin...@haypocalc.com added the comment: I wanted for them to be treated as text files which are trackable in CVS or subversion and to keep Python source codes free of any non-ASCII characters Mercurial supports binary file, I plan to mark the CJK testcases as binary using .hgeol. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12057 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12048] Python 3, ZipFile Bug In Chinese
Amaury Forgeot d'Arc amaur...@gmail.com added the comment: But according to the initial report, 3.2 does not give the expected behavior. This zip file actually stores the filename encoded with cp932, which is incorrect according to the specifications of the ZIP format (only cp437 and utf8 are valid) See issue10614 for a possible solution: allow users to specify an alternate encoding to handle such invalid files. -- nosy: +amaury.forgeotdarc ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12048 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12044] subprocess.Popen.__exit__ doesn't wait for process end
Roundup Robot devnull@devnull added the comment: New changeset 361f87c8f36a by Łukasz Langa in branch 'default': Cleaned up a backward merge after fixes issue #12044. http://hg.python.org/cpython/rev/361f87c8f36a -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12044 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12048] Python 3, ZipFile Bug In Chinese
STINNER Victor victor.stin...@haypocalc.com added the comment:
Oh, right.
Note: the encoding looks to be GBK, not CP932:
'\u590d\u4ef6'.encode('gbk')
b'\xb8\xb4\xbc\xfe'
'\u590d\u4ef6'.encode('gbk').decode('cp437')
'╕┤╝■'
'\u590d\u4ef6'.encode('cp932')
...
UnicodeEncodeError: 'cp932' codec can't encode character '\u590d' ...
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12048
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8824] Improve documentation of exec
Changes by Jordan Stadler jordan.stad...@gmail.com: Removed file: http://bugs.python.org/file21961/exec_doc_touchup_3_x.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8824 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8824] Improve documentation of exec
Changes by Jordan Stadler jordan.stad...@gmail.com: Added file: http://bugs.python.org/file21981/exec_doc_touchup_3.x.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8824 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8824] Improve documentation of exec
Changes by Jordan Stadler jordan.stad...@gmail.com: Added file: http://bugs.python.org/file21982/exec_doc_touchup_2.x.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8824 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8824] Improve documentation of exec
Jordan Stadler jordan.stad...@gmail.com added the comment: I've updated the 3.x patch, should be correct now. I also updated the 2.x patch to use ``in``. :keyword:`in` was used in an earlier part of the paragraph I modified, so I have changed both for consistency. This is the paragraph before modification: In all cases, if the optional parts are omitted, the code is executed in the current scope. If only the first expression after :keyword:`in` is specified, it should be a dictionary, which will be used for both the global and the local variables. If two expressions are given, they are used for the global and local variables, respectively. If provided, *locals* can be any mapping object. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8824 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8824] Improve documentation of exec
Changes by Jordan Stadler jordan.stad...@gmail.com: Removed file: http://bugs.python.org/file21960/exec_doc_touchup_2_x.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8824 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12040] Expose a Process.sentinel property (and fix polling loop in Process.join())
Antoine Pitrou pit...@free.fr added the comment: Here is a new patch addressing Gregory's comment (retry select() on EINTR). -- Added file: http://bugs.python.org/file21983/process_sentinel2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12040 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10713] re module doesn't describe string boundaries for \b
Changes by Ron Ridley ronste...@gmail.com: -- nosy: +Ron.Ridley ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10713 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12062] Buffered I/O inconsistent with unbuffered I/O in certain cases
Changes by John O'Connor tehj...@gmail.com: -- nosy: +jcon ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12062 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12064] unexpected behavior with exception variable
New submission from Mathias Svensson frea...@freaken.dk: Current behavior: In the very simple attached example an existing variable-name is used as the target in the except-part of a try-statement. The existing variable is deleted if an exception is throw. Excepted behavior: The only reasonable behaviors are keeping the original variable or keeping the exception. The current behavior is very unintuitive. -- components: Interpreter Core files: test.py messages: 135845 nosy: Mathias.Svensson priority: normal severity: normal status: open title: unexpected behavior with exception variable type: behavior versions: Python 3.2 Added file: http://bugs.python.org/file21984/test.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12064 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12018] No tests for ntpath.samefile, ntpath.sameopenfile
Santoso Wijaya santoso.wij...@gmail.com added the comment: Attaching a patch to test a use case for ntpath.samefile (looks like sameopenfile is already tested--or at least a use case of it). -- components: +Library (Lib) keywords: +patch nosy: +santa4nt versions: -Python 3.4 Added file: http://bugs.python.org/file21985/test_samefile.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12018 ___ ___ 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-François Natali neolo...@free.fr added the comment: Calling fsync on a file descriptor referring to a tty doesn't make much sense. On Linux, this fails with EINVAL: $ python -c 'import os; os.fsync(1)' Traceback (most recent call last): File string, line 1, in module OSError: [Errno 22] Invalid argument So if the full sync fails on ttys, it shouldn't be a problem: since the default performs a classical fsync, this won't break compatibility with existing code anyway. So I think you should stick with the previous version (well, if the full sync fails on other FDs, then it's another story, but in that case it should just be dropped altogether if it's not reliable...). By the way, it's appropriate, not approbiate. You made the same typo in your patch. -- ___ 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
[issue12064] unexpected behavior with exception variable
Eric Snow ericsnowcurren...@gmail.com added the comment: Duplicate of issue8130. When an exception has been assigned using as target, it is cleared at the end of the except clause. [1] See: [1] http://docs.python.org/py3k/reference/compound_stmts.html#the-try-statement [2] http://www.python.org/dev/peps/pep-3110/#semantic-changes (discussed in issue4617) -- nosy: +ericsnow ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12064 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12064] unexpected behavior with exception variable
Santoso Wijaya santoso.wij...@gmail.com added the comment: Looks like a regression from 2.x. On 2.7: Python 2.7.1 (r271:86832, Nov 27 2010, 17:19:03) [MSC v.1500 64 bit (AMD64)] on win32 Type help, copyright, credits or license for more information. e = True try: raise Exception() ... except Exception as e: pass ... print repr(e) Exception() On 3.2: Python 3.2 (r32:88445, Feb 20 2011, 21:30:00) [MSC v.1500 64 bit (AMD64)] on win 32 Type help, copyright, credits or license for more information. e = True try: raise Exception() ... except Exception as e: pass ... print(repr(e)) Traceback (most recent call last): File stdin, line 1, in module NameError: name 'e' is not defined -- nosy: +santa4nt versions: +Python 3.1, Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12064 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6727] ImportError when package is symlinked on Windows
Changes by Santoso Wijaya santoso.wij...@gmail.com: -- nosy: +santa4nt ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6727 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8604] Adding an atomic FS write API
Milko Krachounov pyt...@milko.3mhz.net added the comment: I have a class for overwriting files properly that I use in three of my projects. It aims to be atomic as possible, supports creating backups, but it doesn't have functions to set or retain permissions when requested (which might be desirable if such a function is added to stdlib). I'd give it here for reference and ideas. - It's a context manager acting like a normal file object so you can use it with e.g. json.dump. In CM mode, if an error is caught, you end up with the old file automatically. If you use it as a file, the 'close' method has a 'cancel' argument to achieve the same. - Normal overwrite on POSIX uses flush, fsync, rename as it should. - Since fsync doesn't work on Mac OS X, it takes care of calling the Mac OS X specific F_FULLFSYNC fcntl. - On POSIX, if a backup is requested, an attempt is made to do it with a hardlink, otherwise do two renames (killing the atomicity). Maybe a copy with shutil would be a better choice though. - On Windows it uses two renames - the old file is backed up to a temporary name, and then the new file is renamed over it. If a backup wasn't requested, the temporary name is deleted. I also have a simple unit test for it, but I've ran it on POSIX only. Here's the part of the code that does the open/close part: http://bazaar.launchpad.net/~exabyte/blackherd/async-refactor/view/61/blackherd/misc.py#L498 And the unit test: http://bazaar.launchpad.net/~exabyte/blackherd/async-refactor/view/61/tests/test_misc.py#L473 I hope that's useful. -- nosy: +milko.krachounov ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8604 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12064] unexpected behavior with exception variable
Ezio Melotti ezio.melo...@gmail.com added the comment: Closing as duplicate. -- nosy: +ezio.melotti resolution: - duplicate stage: - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12064 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8604] Adding an atomic FS write API
Milko Krachounov pyt...@milko.3mhz.net added the comment: Well, since I had a typo in the main method which called the Windows implementation on POSIX, the unit test works on the code for Windows when ran on POSIX. Heh, I'm sorry for the noise, but it seems that re-reading the code four times and running the unit tests is not enough, corrected revision: http://bazaar.launchpad.net/~exabyte/blackherd/async-refactor/view/62/blackherd/misc.py#L498 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8604 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12065] test_ssl failure when svn.python.org fails to resolve
New submission from R. David Murray rdmur...@bitdance.com: See http://www.python.org/dev/buildbot/all/builders/x86%20Gentoo%203.2/builds/34/steps/test/logs/stdio Antoine says that connect_ex should be returning an error, not None, in that situation. -- components: Tests keywords: buildbot messages: 135853 nosy: r.david.murray priority: normal severity: normal stage: needs patch status: open title: test_ssl failure when svn.python.org fails to resolve type: behavior versions: Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12065 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12065] test_ssl failure when svn.python.org fails to resolve
Changes by Antoine Pitrou pit...@free.fr: -- nosy: +pitrou versions: +Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12065 ___ ___ 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
Roundup Robot devnull@devnull added the comment: New changeset da7a120c0478 by Kurt B. Kaiser in branch '3.1': Issue #11896: Save on Close failed despite selecting Yes in dialog. http://hg.python.org/cpython/rev/da7a120c0478 New changeset 87196154dec8 by Kurt B. Kaiser in branch 'default': Merge from 3.2 http://hg.python.org/cpython/rev/87196154dec8 -- nosy: +python-dev ___ 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
[issue12065] test_ssl failure when svn.python.org fails to resolve
Antoine Pitrou pit...@free.fr added the comment: Judging by ssl.connect_ex's source code, this can only mean that socket.connect raised a socket error with a None errno... -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12065 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12065] test_ssl failure when svn.python.org fails to resolve
Antoine Pitrou pit...@free.fr added the comment: Which probably means it was a socket.timeout. When called on a non-SSL socket, connect_ex() returns 11 (EAGAIN) for timeout errors: s = socket.socket() s.settimeout(0.1) s.connect_ex((svn.python.org, 443)) 11 But on SSL sockets, connect_ex() loses the errno (because it calls connect() on the underlying socket, not connect_ex(), and socket.timeout isn't raised with an errno): s = ssl.wrap_socket(socket.socket()) s.settimeout(0.1) print(s.connect_ex((svn.python.org, 443))) None -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12065 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6721] Locks in python standard library should be sanitized on fork
Nir Aides n...@winpdb.org added the comment: Hi, There seem to be two alternatives for atfork handlers: 1) acquire locks during prepare phase and unlock them in parent and child after fork. 2) reset library to some consistent state in child after fork. http://pubs.opengroup.org/onlinepubs/009695399/functions/pthread_atfork.html Option (2) makes sense but is probably not always applicable. Option (1) depends on being able to acquire locks in locking order, but how can we determine correct locking order across libraries? Initializing locks in child after fork without acquiring them before the fork may result in corrupted program state and so is probably not a good idea. On a positive note, if I understand correctly, Python signal handler functions are actually run in the regular interpreter loop (as pending calls) after the signal has been handled and so os.fork() atfork handlers will not be restricted to async-signal-safe operations (since a Python fork is never done in a signal handler). http://pubs.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_04.html http://pubs.opengroup.org/onlinepubs/009695399/functions/fork.html It is therefore undefined for the fork handlers to execute functions that are not async-signal-safe when fork() is called from a signal handler. Opinion by Butenhof who was involved in the standardization effort of POSIX threads: http://groups.google.com/group/comp.programming.threads/msg/3a43122820983fde ...so how can we establish correct (cross library) locking order during prepare stage? Nir -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6721 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5723] Incomplete json tests
Ezio Melotti ezio.melo...@gmail.com added the comment: Why can't you write something like:skip_unless_cjson = skipUnless(...) This indeed works -- using unittest internals was just a temporary workaround because the example in the unittest doc didn't seem to work. - instead of self.mod, self.json would be nicer I thought about using self.json, but then opted for 'mod' because is what the other modules seem to use, but I will fix it. - you could also export self.loads, self.dumps for easier access Usually they are not called more than a couple of times for each test, and each test class usually has 1-2 tests methods, so I'm not sure it's worth it. - you could also have two base classes exporting all this instead of repeating the attribute-setting for every test class I considered this too, but since the C test classes currently inherit from the Python classes, the C base class would have to be a mixin that overrides the effect of the Python base class -- unless I move all the tests in separate base classes and create two separate subclasses for each C/Python test that inherit from the base test classes and either the C or Python base classes. So the two base test classes will be in __init__: class CTest(TestCase): self.json = cjson; self.loads = cjson.loads; ... class PyTest(TestCase): self.json = pyjson; self.loads = pyjson.loads; ... and the other test files will use either: class TestPySomething(PyTest): def test_something(self): ... class TestCSomething(TestPySomething, CTest): pass or: class TestSomething(TestCase): def test_something(self): ... class TestPySomething(TestSomething, PyTest): pass class TestCSomething(TestSomething, CTest): pass Another option is to have a single base class that sets self.loads/dumps in the __init__ but that will still require the module to be set in the subclasses, something like: class JsonTestCase(TestCase): def __init__(self): self.loads = self.json.loads self.dumps = self.json.dumps and then use: class TestPySomething(JsonTestCase): json = pyjson def test_something(self): ... class TestCSomething(TestPySomething): json = cjson I'm not sure any of these options is better than what we have now though. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5723 ___ ___ 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
Kurt B. Kaiser k...@shore.net added the comment: tkinter.messagebox.Message sending class '_tkinter.Tcl_Obj' rather than str, so comparison with str failed. Always for cancel, (almost?) always for yes. Use the helper functions in tkinter.messagebox, which correct for that. This hasn't worked for a long time, I'm surprised it just came up. Will backport to 2.7. -- assignee: ned.deily - kbk nosy: +kbk resolution: - fixed stage: needs patch - committed/rejected status: open - closed versions: +Python 3.1, Python 3.3 -Python 2.6 ___ 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
[issue11614] import __hello__ is broken in Python 3
Georg Brandl ge...@python.org added the comment: Why is this still open, and more importantly, why is it a release blocker? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11614 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12046] Windows build identification incomplete
Georg Brandl ge...@python.org added the comment: Martin, you're probably the only one who can fix this in reasonable time anyway. So I'd not let it block 3.2.1. (If all else fails, you can give the Windows build the correct identification manually, right?) -- priority: release blocker - deferred blocker ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12046 ___ ___ 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: [.] OSError: [Errno 22] Invalid argument Sorry, i didn't know that. Mac OS X (2.5 and 2.6 Apple shipped): 21:43 ~/tmp $ python2.5 -c 'import os; os.fsync(1)'; echo $? 0 21:43 ~/tmp $ python2.6 -c 'import os; os.fsync(1)'; echo $? 0 21:43 ~/tmp $ python2.7 -c 'import os; os.fsync(1)'; echo $? 0 21:43 ~/tmp $ python3 -c 'import os; os.fsync(1)'; echo $? 0 -- ___ 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
[issue9516] sysconfig: $MACOSX_DEPLOYMENT_TARGET mismatch: now 10.3 but 10.5 during configure
Georg Brandl ge...@python.org added the comment: I trust this patch does the right thing -- can you apply it before the rc this weekend? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9516 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11614] import __hello__ is broken in Python 3
STINNER Victor victor.stin...@haypocalc.com added the comment: Why is this still open Because import __hello__ doesn't print hello. and more importantly, why is it a release blocker? Because it is a very important issue! -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11614 ___ ___ 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:
So I think you should stick with the previous version (well, if the
full sync fails on other FDs, then it's another story, but in that
case it should just be dropped altogether if it's not reliable...).
Strong stuff.
*This* is the version which should have been implemented from the
beginning, but Apple states
F_FULLFSYNC Does the same thing as fsync(2) then asks the drive to
flush all buffered data to the permanent storage
device (arg is ignored). This is currently
implemented on HFS, MS-DOS (FAT), and Universal Disk
Format (UDF) file systems.
and i thought
- fsync (maybe move buffers to Queue; do reorder Queue as approbiate)
- do call fsys impl. to .. whatever
That's why i had a version of the patch which did 'fsync();fcntl();'
because it would have been an additional syscall but the fsync()
part would possibly have been essentially skipped over ..unless..
Linux RC scripts had 'sync sync sync' but it does not seem
to be necessary any more (was it ever - i don't know).
But who knows if that fcntl will fail on some non-noted fsys?
I think it's better to be on the safe side.
Quoting you, Charles-François
People requiring write durability will probably manage to find
this full_sync parameter
and if they do they thus really strive for data integrity, so call
fsync() as a fallback for the security which Apple provides.
Also: we cannot let os.fsync() fail with ENOTTY!?
By the way, it's appropriate, not approbiate. You made the same
typo in your patch.
8~I That was not a typo. Thanks.
I'll changed that.
--
Added file: http://bugs.python.org/file21986/11877.8.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,15 @@
``f.flush()``, and then do ``os.fsync(f.fileno())``, to ensure that all
internal
buffers associated with *f* are written to disk.
+ The POSIX standart requires that :c:func:`fsync` must transfer the buffered
+ data to the storage device, not that the data is actually written by the
+ device itself. It explicitely leaves it up to operating system implementors
+ wether users are given stronger guarantees on data integrity or not. Some
+ systems also offer special functions which overtake the part of making such
+ stronger guarantees, i.e., Mac OS X and NetBSD. The optional *full_fsync*
+ argument can be used to enforce usage of these special functions if that is
+ appropriate for the *fd* in question.
+
Availability: Unix, and Windows.
diff --git a/Modules/posixmodule.c b/Modules/posixmodule.c
--- a/Modules/posixmodule.c
+++ b/Modules/posixmodule.c
@@ -2121,13 +2121,50 @@
#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
+full_fsync forces flush of disk caches in case fsync() alone is not enough.);
+
+static PyObject *
+posix_fsync(PyObject *self, PyObject *args, PyObject *kwargs)
+{
+PyObject *fdobj;
+int full_fsync = 0;
+static char *keywords[] = {fd, full_fsync, NULL };
+
+if (!PyArg_ParseTupleAndKeywords(args, kwargs, O|i, keywords,
+ fdobj, full_fsync))
+return NULL;
+
+/* See issue 11877 discussion */
+# if ((defined __APPLE__ defined F_FULLFSYNC) || \
+ (defined __NetBSD__ defined FDISKSYNC))
+if (full_fsync != 0) {
+int res, fd = PyObject_AsFileDescriptor(fdobj);
+if (fd 0)
+return NULL;
+if (!_PyVerify_fd(fd))
+return posix_error();
+
+Py_BEGIN_ALLOW_THREADS
+# if defined __APPLE__
+/* F_FULLFSYNC is not supported for all types of FDs/FSYSs;
+ * be on the safe side and test for inappropriate ioctl errors */
+res = fcntl(fd, F_FULLFSYNC);
+if (res 0 errno == ENOTTY)
+res = fsync(fd);
+# elif defined __NetBSD__
+res = fsync_range(fd, FFILESYNC|FDISKSYNC, 0, 0);
+# endif
+Py_END_ALLOW_THREADS
+
+if (res 0)
+return posix_error();
+Py_INCREF(Py_None);
+return Py_None;
+} else
+# endif
+return posix_fildes(fdobj, fsync);
}
#endif /* HAVE_FSYNC */
@@ -9472,7 +9509,8 @@
{fchdir,
[issue11877] Change os.fsync() to support physical backing store syncs
Changes by Steffen Daode Nurpmeso sdao...@googlemail.com: Removed file: http://bugs.python.org/file21973/11877.7.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
[issue6721] Locks in python standard library should be sanitized on fork
Steffen Daode Nurpmeso sdao...@googlemail.com added the comment: @Nir Aides: *thanks* for this link: http://groups.google.com/group/comp.programming.threads/msg/3a43122820983fde You made my day! -- nosy: +sdaoden ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6721 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12066] Empty ('') xmlns attribute is not properly handled by xml.dom.minidom
New submission from Atamurad Hezretkuliyev atamy...@gmail.com:
Parsing test xmlns=''/test with minidom and converting back to string
raises an exception.
import xml.dom.minidom
xml.dom.minidom.parseString(test xmlns=''/test).toxml()
Traceback (most recent call last):
File stdin, line 1, in module
File
/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/xml/dom/minidom.py,
line 45, in toxml
return self.toprettyxml(, , encoding)
File
/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/xml/dom/minidom.py,
line 57, in toprettyxml
self.writexml(writer, , indent, newl, encoding)
File
/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/xml/dom/minidom.py,
line 1749, in writexml
node.writexml(writer, indent, addindent, newl)
File
/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/xml/dom/minidom.py,
line 812, in writexml
_write_data(writer, attrs[a_name].value)
File
/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/xml/dom/minidom.py,
line 301, in _write_data
data = data.replace(, amp;).replace(, lt;)
AttributeError: 'NoneType' object has no attribute 'replace'
Ii am not familiar with the XML spec so I've no idea if ignoring or accepting
empty namespace is the right thing to do. If someone advices me on how it
should be handled, I'd like to write a patch.
--
components: Library (Lib)
messages: 135867
nosy: atamyrat
priority: normal
severity: normal
status: open
title: Empty ('') xmlns attribute is not properly handled by xml.dom.minidom
type: behavior
versions: Python 2.6
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12066
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11614] import __hello__ is broken in Python 3
Andreas Stührk andy-pyt...@hammerhartes.de added the comment:
A patch against 3.1. The new bytecode is now:
1 0 LOAD_CONST 2 (True)
3 STORE_NAME 1 (initialized)
2 6 LOAD_NAME2 (print)
9 LOAD_CONST 0 ('Hello world...')
12 CALL_FUNCTION1
15 POP_TOP
16 LOAD_CONST 1 (None)
19 RETURN_VALUE
--
keywords: +patch
Added file: http://bugs.python.org/file21987/issue11614.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11614
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11614] import __hello__ is broken in Python 3
STINNER Victor victor.stin...@haypocalc.com added the comment: +print(Hello world...) I would prefer a more positive Hello World!, but thanks for the patch. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11614 ___ ___ 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-François Natali neolo...@free.fr added the comment: and if they do they thus really strive for data integrity, so call fsync() as a fallback for the security which Apple provides. Why? If I ask a full sync and it fails, I'd rather have an error returned so that I can take the appropriate decision (abort, roll-back, try a standard fsync) rather than have Python silently replace it by an fsync. Also: we cannot let os.fsync() fail with ENOTTY!? Why not, since that's what the kernel returns? Once again, since the default behaviour doesn't change, this won't break any existing application. -- ___ 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
[issue12060] Python doesn't support real time signals
Charles-François Natali neolo...@free.fr added the comment: If the C signal handler is called twice, the Python signal handler is only called once. It's not the only shortage with the current implementation regarding (real-time) signals. Another one is that they're delivered out-of-order (lowest-numbered signal first), and the most important one - especially for real-time signals - is that the handlers are executed synchronously, when Py_CheckSignals() is called. While we can't do much about the the later, there's at least a way to handle the other issues, a small variant of the self-pipe trick: - in the signal module initialization code, create a pipe with both ends set to non-blocking - in the signal handler, write the signal received to the pipe (just like what's done for wakeup_fd) - in Py_CheckSignals(), read from the pipe: the signals will be read in order, as many times as they were received. Call the handler for each signal read from the pipe. advantages: - it's async-safe - signals are handled in order - signal handlers are called the correct number of times - you don't have to walk through the whole array of signal handlers, since you know exatly what signals have been received drawbacks: - might be a bit slower, because of the read syscall - consumes 2 FDs - have to reinit the pipe on fork - does Windows have pipe/read/write? - maybe overkill But I'm really not sure that fixing this is worth it... By the way, to be pedantic, in the current code, wakeup_fd and Handlers should be volatile, and tripped should be sig_atomic_t. -- nosy: +neologix ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12060 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5723] Incomplete json tests
Antoine Pitrou pit...@free.fr added the comment: class TestSomething(TestCase): def test_something(self): ... class TestPySomething(TestSomething, PyTest): pass class TestCSomething(TestSomething, CTest): pass I was thinking about that. That looks clean and explicit to me. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5723 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12067] Doc: remove errors about mixed-type comparisons.
New submission from Terry J. Reedy tjre...@udel.edu:
Current 3.2 doc, 5.9. Comparisons, has this paragraph about mixed-type
comparisons.
The operators , , ==, =, =, and != compare the values of two objects. The
objects need not have the same type. If both are numbers, they are converted to
a common type. Otherwise, the == and != operators *always* consider objects of
different types to be unequal, while the , , = and = operators raise a
TypeError when comparing objects of different types that do not implement these
operators for the given pair of types. You can control comparison behavior of
objects of non-built-in types by defining rich comparison methods like
__gt__(), described in section Basic customization.
Sentence 3: If both are numbers, they are converted to a common type. I
suspect it would be more true to say 'common internal type' as I would not
think it a language requirement to produce Python objects.
In any case, I think it is only true for built-in number types, and I do not
see that qualification anywhere previously.
That aside, it does not appear to be true for Decimals and Fractions in 2.7.1.
Sentence 4: first clause is only true for built-in types. That qualification is
not obvious to everyone, as evidenced by a current python-list sub thread.
For 2.7, which has a different continuation, I suggest adding 'built-in' before
'objects of'.
For 3.2/3, I suggest deleting '*always*' and adding a comma after 'TypeError'
so that the 'when' condition applies to equality comparisons also.
After discussion about same-type comparisons, there is another paragraph about
mixed-type comparison:
Comparison of objects of the differing types depends on whether either of the
types provide explicit support for the comparison. Most numeric types can be
compared with one another, but comparisons of float and Decimal are not
supported to avoid the inevitable confusion arising from representation issues
such as float('1.1') being inexactly represented and therefore not exactly
equal to Decimal('1.1') which is. When cross-type comparison is not supported,
the comparison method returns NotImplemented. This can create the illusion of
non-transitivity between supported cross-type comparisons and unsupported
comparisons. For example, Decimal(2) == 2 and 2 == float(2) but Decimal(2) !=
float(2).
I suggest deleting this entirely. The first sentence and first clause of the
second repeat what was said above. The rest is obsolete as float/decimal
comparisons *are* implemented in 2.7.1 and 3.2.0.
--
assignee: docs@python
components: Documentation
keywords: easy
messages: 135873
nosy: docs@python, rhettinger, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Doc: remove errors about mixed-type comparisons.
versions: Python 2.7, Python 3.2, Python 3.3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12067
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12068] test_logging failure in test_rollover
New submission from Antoine Pitrou pit...@free.fr: This has started popping up on several buildbots: == FAIL: test_rollover (test.test_logging.TimedRotatingFileHandlerTest) -- Traceback (most recent call last): File /var/lib/buildslave/3.x.murray-gentoo/build/Lib/test/test_logging.py, line 3529, in test_rollover self.assertTrue(found, msg=msg) AssertionError: False is not true : No rotated files found, went back 1 seconds (http://www.python.org/dev/buildbot/all/builders/x86%20Gentoo%203.x/builds/101/steps/test/logs/stdio) -- assignee: vinay.sajip components: Tests messages: 135874 nosy: pitrou, vinay.sajip priority: high severity: normal stage: needs patch status: open title: test_logging failure in test_rollover type: behavior versions: Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12068 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12067] Doc: remove errors about mixed-type comparisons.
Changes by Chris Rebert pyb...@rebertia.com: -- nosy: +cvrebert ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12067 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11614] import __hello__ is broken in Python 3
Changes by Andreas Stührk andy-pyt...@hammerhartes.de: Added file: http://bugs.python.org/file21988/issue11614_!.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11614 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12067] Doc: remove errors about mixed-type comparisons.
Ezio Melotti ezio.melo...@gmail.com added the comment: Can you provide a patch? -- nosy: +ezio.melotti ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12067 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12062] Buffered I/O inconsistent with unbuffered I/O in certain cases
Roundup Robot devnull@devnull added the comment: New changeset 89f77afac947 by Antoine Pitrou in branch '3.1': Issue #12062: Fix a flushing bug when doing a certain type of I/O sequence http://hg.python.org/cpython/rev/89f77afac947 New changeset 47ca1244a929 by Antoine Pitrou in branch '3.2': Issue #12062: Fix a flushing bug when doing a certain type of I/O sequence http://hg.python.org/cpython/rev/47ca1244a929 New changeset 05e0227e3879 by Antoine Pitrou in branch 'default': Issue #12062: Fix a flushing bug when doing a certain type of I/O sequence http://hg.python.org/cpython/rev/05e0227e3879 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12062 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12062] Buffered I/O inconsistent with unbuffered I/O in certain cases
Roundup Robot devnull@devnull added the comment: New changeset 0d24d4c537a6 by Antoine Pitrou in branch '2.7': Issue #12062: In the `io` module, fix a flushing bug when doing a certain http://hg.python.org/cpython/rev/0d24d4c537a6 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12062 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12062] Buffered I/O inconsistent with unbuffered I/O in certain cases
Antoine Pitrou pit...@free.fr added the comment: Should be fixed now. Again, thank you reporting this bug! -- resolution: - fixed stage: patch review - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12062 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12060] Python doesn't support real time signals
STINNER Victor victor.stin...@haypocalc.com added the comment: It's not the only shortage with the current implementation regarding (real-time) signals. Another one is that they're delivered out-of-order (lowest-numbered signal first), Oh yes, it can be a problem. and the most important one - especially for real-time signals - is that the handlers are executed synchronously, when Py_CheckSignals() is called. Evaluate Python code in a signal handler is really not a good idea! And because of the GIL, I don't think that we can do better. But with the GIL of Python 3.3, the Python signal handler will be called immediatly before the next instruction, instead of having to wait something like 100 Python instructions (sys.getcheckinterval()). On this point, Python 3.3 is better than all previous versions. While we can't do much about the the later, there's at least a way to handle the other issues, a small variant of the self-pipe trick: (...) drawbacks: - might be a bit slower, because of the read syscall - consumes 2 FDs Consume 2 FDs can be surprising. We cannot do that by default (just to have in-order or real time signals). - have to reinit the pipe on fork Oh yes, it can be a problem. - does Windows have pipe/read/write? Do you really think that Windows supports real time signals? :) Windows has pipes: see the Connection object of the multiprocessing module (Antoine is working on this topic). But I don't remember if they can be used as POSIX files (using file descriptors). - maybe overkill But I'm really not sure that fixing this is worth it... It looks like your reimplements the whole signal machinery between the kernel and the application... But anyway, we need something between the C signal handler and the Python signal handler (because we cannot execute Python code in a C signal handler). Well, we can imagine to have an option/function to enable real time and/or in-order signals (e.g. using pipes). Can we call this mode real time? Real time means that we warranty a maximum response time. By the way, to be pedantic, in the current code, wakeup_fd and Handlers should be volatile, and tripped should be sig_atomic_t. Yes. Can you please write a patch for this? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12060 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5723] Incomplete json tests
Ezio Melotti ezio.melo...@gmail.com added the comment: With this approach is necessary to exclude the base class from the tests, either by listing all the Python/C tests explicitly or doing some automatic check to find these base classes. Listing all the tests is a bad idea because it needs to be updated manually and it's easy to forget about that and end up with tests that are never run. Checking and skipping the base classes is not very elegant IMHO. It also requires an extra base class, and even if it's more flexible because it makes possible to add Python-specific tests easily, that's not necessary with json because all the tests run unchanged on both pyjson and cjson. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5723 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5723] Incomplete json tests
Antoine Pitrou pit...@free.fr added the comment: With this approach is necessary to exclude the base class from the tests, either by listing all the Python/C tests explicitly or doing some automatic check to find these base classes. It just needs a small change then: class PyTest(TestCase): ... class CTest(TestCase): ... class TestSomething: def test_something(self): ... class TestPySomething(TestSomething, PyTest): pass class TestCSomething(TestSomething, CTest): pass -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5723 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12069] test_signal.test_without_siginterrupt() failure on AMD64 OpenIndiana 3.x
New submission from STINNER Victor victor.stin...@haypocalc.com: test_signal fails sometimes on the AMD64 OpenIndiana 3.x buildbot: Traceback (most recent call last): File /export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/test/test_signal.py, line 358, in test_without_siginterrupt self.assertTrue(i) AssertionError: False is not true http://www.python.org/dev/buildbot/all/builders/AMD64%20OpenIndiana%203.x/builds/1188/steps/test/logs/stdio This failure may be related to my recent work on signals, see #8407. -- messages: 135882 nosy: haypo, pitrou priority: normal severity: normal status: open title: test_signal.test_without_siginterrupt() failure on AMD64 OpenIndiana 3.x versions: Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12069 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5723] Incomplete json tests
R. David Murray rdmur...@bitdance.com added the comment: My usual pattern (adopted from examples in the stdlib tests) is this: TestSomethingBase: tests PyTestSomething(TestSomethingBase, TestCase): stuff CTestSomething(TestSomethingBase, TestCase): stuff Is there a reason that won't work in your case? -- nosy: +r.david.murray ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5723 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5723] Incomplete json tests
Ezio Melotti ezio.melo...@gmail.com added the comment: Technically they both work, they are just two different approaches that offer more or less the same compromise between features and verbosity. Your approach requires an extra class for each test but saves you from setting the module attribute and the skip, mine is the other way around. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5723 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12060] Python doesn't support real time signals
Charles-François Natali neolo...@free.fr added the comment:
Evaluate Python code in a signal handler is really not a good idea!
I know, you're limited to async-safe functions, among other things :-)
because of the GIL, I don't think that we can do better. But with the
GIL of Python 3.3, the Python signal handler will be called immediatly
before the next instruction, instead of having to wait something like
100 Python instructions (sys.getcheckinterval()). On this point, Python
3.3 is better than all previous versions.
Nice.
Well, we can imagine to have an option/function to enable real time
and/or in-order signals (e.g. using pipes).
Can we call this mode real time? Real time means that we warranty a
maximum response time.
Well, I think that we should either make this the default behaviour
(that's why I was asking whether it's possible on Windows), or not
implement it. Having two modes for signal handling is confusing.
But given that this behaviour has never been noticed before and that I
doubt that people needing real-time signals use Python (and
vice-versa), maybe we should just stick with the current
implementation, which is safe and simple (see Antoine's question, Is
it a theoretical concern or does it affect real software?).
On the other hand, if it turns out to be interesting to some people,
I'd be happy to work on a patch.
By the way, to be pedantic, in the current code, wakeup_fd and
Handlers should be volatile, and tripped should be sig_atomic_t.
Yes. Can you please write a patch for this?
Patch attached.
--
Added file: http://bugs.python.org/file21989/signal_pedantic.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12060
___diff -r 3ebe2d261920 Modules/signalmodule.c
--- a/Modules/signalmodule.cThu May 12 16:18:29 2011 +0100
+++ b/Modules/signalmodule.cFri May 13 01:11:27 2011 +0200
@@ -88,12 +88,12 @@
static pid_t main_pid;
#endif
-static struct {
-int tripped;
+static volatile struct {
+sig_atomic_t tripped;
PyObject *func;
} Handlers[NSIG];
-static sig_atomic_t wakeup_fd = -1;
+static volatile sig_atomic_t wakeup_fd = -1;
/* Speed up sigcheck() when none tripped */
static volatile sig_atomic_t is_tripped = 0;
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12069] test_signal.test_without_siginterrupt() failure on AMD64 OpenIndiana 3.x
Changes by Jesús Cea Avión j...@jcea.es: -- nosy: +jcea ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12069 ___ ___ 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
Roundup Robot devnull@devnull added the comment: New changeset ac14158462cf by Kurt B. Kaiser in branch '2.7': Issue #11896: Save on Close failed despite selecting Yes in dialog. http://hg.python.org/cpython/rev/ac14158462cf -- ___ 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
[issue5559] IDLE Output Window 's goto fails when path has spaces
Kurt B. Kaiser k...@shore.net added the comment: Backported to 2.6 4Oct09 56387:490190cb4a57 -- stage: commit review - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5559 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7738] IDLE hang when tooltip comes up in Linux
Kurt B. Kaiser k...@shore.net added the comment: Linux trader 2.6.38-2-686 #1 SMP Thu Apr 7 05:24:21 UTC 2011 i686 GNU/Linux kbk@trader:~/Python/Py27$ aptitude show tk8.5 Package: tk8.5 ... Version: 8.5.9-2 Debian Linux Wheezy Can't reproduce on 2.7.1+ 3.1.4+ 3.2.1beta 3.3alpha0 with Tk8.4 Tk8.5 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7738 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5723] Incomplete json tests
Ezio Melotti ezio.melo...@gmail.com added the comment: Attached patch uses the approach described in msg135881. -- Added file: http://bugs.python.org/file21990/issue5723-2.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5723 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
