[issue15806] Add context manager for the try: ... except: pass pattern
Raymond Hettinger added the comment: Yes, something along those lines would be *much* better: class Ignore: ''' Context manager to ignore particular exceptions''' def __init__(self, *ignored_exceptions): self.ignored_exceptions = ignored_exceptions def __enter__(self): return self def __exit__(self, exctype, excinst, exctb): return exctype and issubclass(exctype, self.ignored_exceptions) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15806 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15806] Add context manager for the try: ... except: pass pattern
Nick Coghlan added the comment: I'd just write it with @contextmanager. Making it easier to cleanly factor out exception handling is one of the main reasons that exists. @contextmanager def ignored(*exceptions): Context manager to ignore particular exceptions try: yield except exceptions: pass While the class based version would likely be fractionally faster, the generator based version is more obviously correct. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15806 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15806] Add context manager for the try: ... except: pass pattern
Changes by Chris Jerdonek chris.jerdo...@gmail.com: -- nosy: +cjerdonek ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15806 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15804] Feature request, implicit except : pass
Changes by Ezio Melotti ezio.melo...@gmail.com: -- stage: - committed/rejected ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15804 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15798] subprocess.Popen() fails if 0, 1 or 2 descriptor is closed
Ross Lagerwall added the comment:
It's caused by the following check in _posixsubprocess.c:
if (close_fds errpipe_write 3) { /* precondition */
PyErr_SetString(PyExc_ValueError, errpipe_write must be = 3);
return NULL;
}
which was written by Gregory P. Smith in 2010 (adding to nosy list).
I'm not entirely sure why this check is here, presumably its due to the way
close_fds=True is handled.
The close fds logic is also hardcoded to close fds from 3 upwards,.
--
nosy: +gregory.p.smith
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15798
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13405] Add DTrace probes
Ronald Oussoren added the comment:
The obvious workaround w.r.t. dtrace not finding the preprocessor is to install
the command-line tools for xcode, which you can do from Xcode's preferences.
something else to try (before installing the commandline tools): add $(dirname
$(xcrun -find cpp)) to the search path of the shell:
bash$ PATH=${PATH}:$(dirname $(xcrun -find cpp))
This adds the directory in the Xcode bundle that contains the command-line
tools to the search path of the shell, and might make it possible for dtrace to
find the preprocessor (depending on how dtrace is coded). If that works this
trick could be added to the build process, we already do something similar to
locate the compiler in the configure script.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13405
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15806] Add context manager for the try: ... except: pass pattern
Ezio Melotti added the comment: I think I'm -1 on this. This saves two lines, but makes the code less explicit, it can't be used for try/except/else or try/except/except, it requires an extra import, the implementation is simple enough that it doesn't necessary need to be in the stdlib, it might encourage bad style, and it's slower. Some of these downsides are indeed somewhat weak, but the upside of saving two lines is quite weak too IMHO. -- nosy: +ezio.melotti ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15806 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15573] Support unknown formats in memoryview comparisons
Stefan Krah added the comment: We overlooked one thing. Since hashing is defined in terms of tobytes(), the equality-hash invariant is now broken: from _testbuffer import ndarray x = ndarray([1,2,3], shape=[3], format='f') y = ndarray([1,2,3], shape=[3], format='B') a = memoryview(x) b = memoryview(y) a == b True hash(a) == hash(b) False This is one problem with the new equality definition. It puts memoryview firmly into array territory. I'm not saying that's wrong, I even think it was the intention of the PEP authors to have a zero copy arrayview. Both array.array and numpy.array sidestep the issue by not being hashable. I don't really see a way around all this except doing slow element-wise hashing. -- resolution: fixed - status: closed - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15573 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15806] Add context manager for the try: ... except: pass pattern
Martin v. Löwis added the comment: I think the zipfile example is really a bad example. IMO, it would best be written as try: return bool(EndRecData(fp)) except IOError: return False i.e. there shouldn't be a pass statement at all in this code, and the if can be dropped whether you use try-except or with. -- nosy: +loewis ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15806 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15802] Illegal test for mailbox
Ezio Melotti added the comment: +if int(groups[0]) == int(previous_groups[0]): +self.assertGreaterEqual(int(groups[1]), int(previous_groups[1]), This checks that int(groups[1]) = int(previous_groups[1]) if int(groups[0]) == int(previous_groups[0]) whereas the previous version (with the int() fixed) checked that int(groups[1]) = (previous_groups[1]) or groups[0] != groups[1]. Was the previous check nonsensical apart from the wrong usage of int()? Note that even the indexes you used are different (I haven't checked what those values actually are though). -- nosy: +ezio.melotti ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15802 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15798] subprocess.Popen() fails if 0, 1 or 2 descriptor is closed
Changes by Chris Rebert pyb...@rebertia.com: -- nosy: +cvrebert ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15798 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15806] Add context manager for the try: ... except: pass pattern
Changes by Chris Rebert pyb...@rebertia.com: -- nosy: +cvrebert ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15806 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15798] subprocess.Popen() fails if 0, 1 or 2 descriptor is closed
Gregory P. Smith added the comment: easy enough to reproduce... $ ./python.exe -c 'import os, subprocess as s; os.close(0); os.close(1); s.Popen([/bin/true])' Traceback (most recent call last): File string, line 1, in module File /Users/gps/python/hg/default/Lib/subprocess.py, line 818, in __init__ restore_signals, start_new_session) File /Users/gps/python/hg/default/Lib/subprocess.py, line 1363, in _execute_child restore_signals, start_new_session, preexec_fn) ValueError: errpipe_write must be = 3 Examining the code, it looks like that restriction is to prevent the dup2's for any passed in stdin, stdout or stderr pipes from overwriting errpipe_write in Modules/_posixsubprocess.c's child_exec() function. First guess at a fix: child_exec() needs to detect this situation and dup(errpipe_write) until it gets a fd not in the 0..2 range before the dup2(...) calls that could otherwise blindly clobber it. This could possibly be done by the parent process's _create_pipe() in Lib/subprocess.py when allocating the errpipe_read and errpipe_write fds. Suggested Workaround: for now for any code running into this (Python daemons launching subprocesses?) - Call os.pipe() twice at the start of your program to burn 4 fds. That'll guarantee 0, 1 and 2 will not be used for this pipe. -- assignee: - gregory.p.smith versions: +Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15798 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15802] Nonsensical test for mailbox
Serhiy Storchaka added the comment: Yes, the previous check nonsensical in two cases -- comparing strings and comparing with wrong value. groups[0] -- current seconds (str), groups[1] -- current milliseconds (str), previous_groups[0] -- previous seconds (str), previous_groups[1] -- previous milliseconds (str). As I understand sensible check should be: current seconds = previous seconds and if current seconds == previous seconds then current milliseconds = previous milliseconds. In other words, (int(groups[0]), int(groups[1])) = (int(previous_groups[0]), int(previous_groups[1])). -- title: Illegal test for mailbox - Nonsensical test for mailbox ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15802 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15751] Support subinterpreters in the GIL state API
Antoine Pitrou added the comment: Le mercredi 29 août 2012 à 02:19 +, Nick Coghlan a écrit : However, it *doesn't* work (at least, not easily) if the extension itself wants to call back into an interpreter other than the one already associated with the current thread: /* Embedding application (GIL always unlocked) */ gilstate = PyGILState_EnsureEx(interp_A); /* Python code and extension code happens */ /* Callback needs to reach back into a specific interpreter */ cb_gilstate = PyGILState_EnsureEx(interp_B); /* Callback runs */ PyGILState_Release(cb_gilstate); /* Python code and extension code unwinds */ PyGILState_Release(gilstate); Does that second call to EnsureEx fail? What would it fail? It should simply change the thread state to interp_B's thread state for the current thread. Then the nested PyGILState_Release changes the thread state back to its old value. (of course, I don't understand how an extension running from a given interpreter would have access to another interpreter's callback, but regardless, it's technically not a problem) If it succeeds, how does the client know which interpreter to use for the PyGILState_Release call? It could be made to work if PyGILState_STATE was changed from an enum to a struct that included in interpreter state pointer, or if EnsureEx returned a different type and was paired up with a new ReleaseEx pointer. Making PyGILState_STATE a struct sounds reasonable to me. However, that's starting to get very messy compared to a separate SwitchInterpreter call: Why messy? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15751 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15798] subprocess.Popen() fails if 0, 1 or 2 descriptor is closed
Ross Lagerwall added the comment: The attached patch + test seems to fix the issue. It's not very elegant. -- keywords: +patch Added file: http://bugs.python.org/file27042/issue15798.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15798 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15751] Support subinterpreters in the GIL state API
Nick Coghlan added the comment: Yeah, I eventually came around to agreeing that it's better to stick with the Ensure/Release model. SwitchInterpreter gets messy when it comes to managing the lifecycle of temporary thread states. So an EnsureEx/ReleaseEx pair with a new struct that includes both the GIL state info and either the previous thread state or an interpreter pointer sounds good to me. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15751 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13370] test_ctypes fails when building python with clang
Changes by Ronald Oussoren ronaldousso...@mac.com: -- status: pending - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13370 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14329] proxy_bypass_macosx_sysconf does not handle singel ip addresses correctly
Changes by Ronald Oussoren ronaldousso...@mac.com: -- status: open - pending type: - behavior ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14329 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15573] Support unknown formats in memoryview comparisons
Nick Coghlan added the comment: Perhaps the hash could just be based on a subset of the items? For example, hash the format, shape and the first and last items? Yes, such an approach means you're more likely to get collisions if you do start hashing these, but that seems better than making hashing itself excessively slow. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15573 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13405] Add DTrace probes
Samuel John added the comment: dtrace ignores PATH and CC and CPP. I tried that already :/ Of course I could just install the command line tools. But still it's a shame since all the tools are already there. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13405 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15806] Add context manager for the try: ... except: pass pattern
Nick Coghlan added the comment: (Note: I'm not yet convinced this is a good idea. I'm definitely considering it, though) As with many context managers, a key benefit here is in the priming effect for readers. In this code: try: # Whatever except (A, B, C): pass the reader doesn't know that (A, B, C) exceptions will be ignored until the end. The with statement form makes it clear before you start reading the code that certain exceptions won't propagate: with ignored(A, B, C): # Whatever I'm not worried that it makes things less explicit - it's pretty obvious what a context manager called ignored that accepts an arbitrary number of exceptions is going to do. One other thing it does is interact well with ExitStack - you can stick this in the stack of exit callbacks to suppress exceptions that you don't want to propagate. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15806 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15806] Add context manager for the try: ... except: pass pattern
Ezio Melotti added the comment: As with many context managers, a key benefit here is in the priming effect for readers. The focus is mostly on what it's being executed rather than what it's being ignored though. Do this operation and ignore these exceptions if they occur vs. Ignore these exceptions if they occur while doing this operation. I'm not worried that it makes things less explicit - it's pretty obvious what a context manager called ignored that accepts an arbitrary number of exceptions is going to do. It's still understandable, but while I'm familiar with the semantics of try/except, I wouldn't be sure if e.g. this just ignored those specific exceptions or even their subclasses without checking the doc/code. One other thing it does is interact well with ExitStack - you can stick this in the stack of exit callbacks to suppress exceptions that you don't want to propagate. This seems a good use case. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15806 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15751] Support subinterpreters in the GIL state API
Graham Dumpleton added the comment: If PyGILState_STATE is a struct, what happens if someone naively does: PyGILState_Release(PyGILState_UNLOCKED) I know they shouldn't, but I actually do this in mod_wsgi in one spot as it is otherwise a pain to carry around the state when I know for sure if was unlocked before the PyGILState_Ensure(). Or can PyGILState_UNLOCKED map to some a global struct instance with certain state in it that represents that without problem. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15751 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15807] Bogus versionchanged note in logging.handlers.MemoryHandler doc
New submission from Gunnlaugur Thor Briem: In logging.handlers.MemoryHandler documentation: “Changed in version 2.6: credentials was added.” There's no `credentials` anywhere nearby, and at first glance I can't see anything new in `MemoryHandler` when this was introduced. Presumably the `.. versionchanged::` note just landed there by copy-paste error in 6fb033af9310. -- assignee: docs@python components: Documentation messages: 169360 nosy: docs@python, gthb priority: normal severity: normal status: open title: Bogus versionchanged note in logging.handlers.MemoryHandler doc type: enhancement versions: Python 2.6, Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15807 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15807] Bogus versionchanged note in logging.handlers.MemoryHandler doc
Changes by Ezio Melotti ezio.melo...@gmail.com: -- nosy: +vinay.sajip stage: - needs patch versions: -Python 2.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15807 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13405] Add DTrace probes
Ronald Oussoren added the comment: It's rather annoying that dtrace doesn't honor the PATH variable, and when you run the strings command on /usr/lib/libdtrace.dylib you'll see that it hardcodes the use of gcc (not even cpp or clang). I've filed radar 12196604 in Apple's tracker, although it is unlikely that this will help. BTW. You (Samuel) could also file a bugreport with Apple, the more people do this the higher the change that they will fix this. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13405 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13405] Add DTrace probes
Changes by Robert Kern robert.k...@gmail.com: -- nosy: -robert.kern ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13405 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15802] Nonsensical test for mailbox
Chris Jerdonek added the comment: In other words, (int(groups[0]), int(groups[1])) = (int(previous_groups[0]), int(previous_groups[1])). Why not use a single self.assertGreaterEqual() on the pairs (with an appropriate change in the message)? It currently hand-codes the lexicographic comparison, which seems an unnecessary complication (and may have increased the likelihood of error). -- nosy: +cjerdonek ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15802 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15806] Add context manager for the try: ... except: pass pattern
Antoine Pitrou added the comment: If this is desirable then I think it would be better as a classmethod of Exception: with KeyError.trap(): do_something() -- nosy: +pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15806 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15806] Add context manager for the try: ... except: pass pattern
Eric V. Smith added the comment: While the classmethod version has some appeal, it doesn't extend well to handling multiple exception types. I'm -0 on this, in any event. I think the original code is more clear. Why force people to learn (or recognize) a second idiom for something so simple? -- nosy: +eric.smith ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15806 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15808] Possibility of setting custom key bindings for Additional help sources menu items
New submission from Rostyslav Dzinko: There's a possibility to add additional help sources in IDLE via Options - Configure IDLE... - General - Additional Help Sources Use case: If someone wants to download certain version of Python documentation in HTML and specify local index.html to be opened by custom menu item which appears the in Help menu. Problem: It's not possible to assign custom hot-key (Options - Configure IDLE... - Keys) for such menu items or reassign F1 to that new menu-item, which actually makes sense when talking in context of the use case specified above. This use case was taken from real life (stackoverflow site): http://stackoverflow.com/questions/12174255/linking-offline-documentation-to-idle-linux -- components: IDLE messages: 169365 nosy: Rostyslav.Dzinko priority: normal severity: normal status: open title: Possibility of setting custom key bindings for Additional help sources menu items type: enhancement versions: 3rd party, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15808 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15808] Possibility of setting custom key bindings for Additional help sources menu items
Changes by Rostyslav Dzinko rostislav.dzi...@gmail.com: -- versions: -3rd party ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15808 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15784] OSError.__str__() should distinguish between errno and winerror
Richard Oudkerk added the comment: The changeset is 2e587b9bae35. Georg, could you copy it to your release branch please. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15784 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15800] Closing of sys.std* files in gzip test.
Jesús Cea Avión added the comment: Test? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15800 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15475] Correct __sizeof__ support for itertools
Changes by Aaron Iles aaron.i...@gmail.com: -- nosy: +aliles ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15475 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15806] Add context manager for the try: ... except: pass pattern
Changes by Jesús Cea Avión j...@jcea.es: -- nosy: +jcea ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15806 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13266] Add inspect.unwrap(f) to easily unravel __wrapped__ chains
Changes by Aaron Iles aaron.i...@gmail.com: -- nosy: +aliles ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13266 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15510] textwrap.wrap('') returns empty list
Chris Jerdonek added the comment: Attaching an updated patch that improves the organization of the new test cases (test ordering, test names, and test comments, etc). -- Added file: http://bugs.python.org/file27043/issue-15510-4.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15510 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15490] Correct __sizeof__ support for StringIO
Changes by Aaron Iles aaron.i...@gmail.com: -- nosy: +aliles ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15490 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15436] __sizeof__ is not documented
Changes by Aaron Iles aaron.i...@gmail.com: -- nosy: +aliles ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15436 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15696] Correct __sizeof__ support for mmap
Changes by Aaron Iles aaron.i...@gmail.com: -- nosy: +aliles ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15696 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15695] Correct __sizeof__ support for StgDict
Changes by Aaron Iles aaron.i...@gmail.com: -- nosy: +aliles ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15695 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15513] Correct __sizeof__ support for pickle
Changes by Aaron Iles aaron.i...@gmail.com: -- nosy: +aliles ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15513 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15809] Строки из IDLE поступают в неверной кодировке.
New submission from alex hartwig:
Это из IDLE:
Python 2.7.2+ (default, Oct 4 2011, 20:03:08)
[GCC 4.6.1] on linux2
Type copyright, credits or license() for more information.
import sys
import locale
sys.getdefaultencoding()
'ascii'
locale.getpreferredencoding()
'UTF-8'
s = u'Русский текст'
print s.encode('utf_8')
Ð ÑÑÑкий ÑекÑÑ
print s.encode('latin1')
Русский текст
Это из консоли:
import sys
import locale
sys.getdefaultencoding()
'ascii'
locale.getpreferredencoding()
'UTF-8'
s = u'Русский текст'
print s.encode('utf_8')
Русский текст
--
components: IDLE
files: Снимок-2012-08-21 10:37:23.png
messages: 169369
nosy: alex.hartwig, asvetlov
priority: normal
severity: normal
status: open
title: Строки из IDLE поступают в неверной кодировке.
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file27044/Снимок-2012-08-21 10:37:23.png
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15809
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15809] Строки из IDLE поступают в неверной кодировке.
Ezio Melotti added the comment:
Looks like your IDLE is set to use latin-1, but s.encode('latin1') should have
failed with an UnicodeEncodeError. Are you sure you copied the snippet
correctly?
The default source encoding refers to the .py files you open with IDLE, and
doesn't affect the encoding used by IDLE itself while printing.
(Please use English to report issues.)
--
nosy: +ezio.melotti
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15809
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15809] IDLE console uses incorrect encoding.
Changes by Andrew Svetlov andrew.svet...@gmail.com: -- title: Строки из IDLE поступают в неверной кодировке. - IDLE console uses incorrect encoding. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15809 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15809] IDLE console uses incorrect encoding.
alex hartwig added the comment: Text is correct. See attachment. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15809 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15810] assertSequenceEqual should be fired when comparing sequences
New submission from Florent Xicluna: When writing unittest, I noticed that I need to uses assertSequenceEqual explicitly when comparing sequences of different kinds. If I only use the plain assertEqual, it does not generate pretty diffs. On second thought, I think it could be fixed in unittest to use assertSequenceEqual when isinstance(arg, (tuple, list)) or isinstance(arg, collections.Sequence) is True. -- components: Library (Lib), Tests messages: 169372 nosy: flox priority: normal severity: normal status: open title: assertSequenceEqual should be fired when comparing sequences type: behavior versions: Python 2.7, Python 3.2, Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15810 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15811] ElementTree.write() raises TypeError when xml_declaration = True and encoding is a unicode string
New submission from David Buxton: The problem is an inconsistency between the ElementTree.write() method on Python 2 and 3 when xml_declaration is True. For Python 2.7 the encoding argument MUST NOT be a unicode string. For Python 3.2 the encoding argument MUST be a unicode string. On Python 2.7.3 (ElementTree 1.3.0) you can only use byte strings as the encoding argument when including the xml declaration. If you use a unicode object you get TypeError thrown: from xml.etree import ElementTree as ET from io import BytesIO tree = ET.ElementTree(ET.Element(u'example')) tree.write(BytesIO(), xml_declaration=True, encoding='utf-8') tree.write(BytesIO(), xml_declaration=True, encoding=u'utf-8') Traceback (most recent call last): File stdin, line 1, in module File /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/xml/etree/ElementTree.py, line 813, in write write(?xml version='1.0' encoding='%s'?\n % encoding) TypeError: 'unicode' does not have the buffer interface So the encoding argument must be a byte string. However on Python 3.2.3 (ElementTree 1.3.0) the same argument must be a unicode string. If you pass a byte string in it raises TypeError. This only happens when you pass in an encoding and xml_declaration=True. This is a (small) problem when writing Py 2/3 compatible code since the version of ElementTree is supposed to be the same. -- components: XML messages: 169373 nosy: David.Buxton priority: normal severity: normal status: open title: ElementTree.write() raises TypeError when xml_declaration = True and encoding is a unicode string type: behavior versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15811 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15810] assertSequenceEqual should be fired when comparing sequences
R. David Murray added the comment: I think it works as it should (you shouldn't be asserting that a sequence and a tuple are equal, after all). Once you fix your test, you'll get the pretty print if there are still differences. -- nosy: +michael.foord, r.david.murray ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15810 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15765] test_getcwd_long_pathnames (in test_posix) kills NetBSD
Roundup Robot added the comment: New changeset bfa5d0ddfbeb by Trent Nelson in branch '2.7': Issue #15765: Fix quirky NetBSD getcwd() behaviour. http://hg.python.org/cpython/rev/bfa5d0ddfbeb -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15765 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9185] os.getcwd causes infinite loop on solaris
Roundup Robot added the comment: New changeset bfa5d0ddfbeb by Trent Nelson in branch '2.7': Issue #15765: Fix quirky NetBSD getcwd() behaviour. http://hg.python.org/cpython/rev/bfa5d0ddfbeb -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9185 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15811] ElementTree.write() raises TypeError when xml_declaration = True and encoding is a unicode string
Changes by Florent Xicluna florent.xicl...@gmail.com: -- components: +Library (Lib) nosy: +eli.bendersky, flox ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15811 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15807] Bogus versionchanged note in logging.handlers.MemoryHandler doc
Roundup Robot added the comment: New changeset 48f54b6bf0ef by Vinay Sajip in branch '2.7': Closes #15807: Removed incorrect directive from help. http://hg.python.org/cpython/rev/48f54b6bf0ef -- nosy: +python-dev resolution: - fixed stage: needs patch - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15807 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15710] logging module crashes in Python 2.7.3 for handler.setLevel(long)
Roundup Robot added the comment: New changeset 8ba6d8fc9740 by Vinay Sajip in branch '2.7': Closes #15710: accept long in _checkLevel. http://hg.python.org/cpython/rev/8ba6d8fc9740 -- nosy: +python-dev resolution: invalid - fixed stage: - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15710 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15810] assertSequenceEqual should be fired when comparing sequences
Florent Xicluna added the comment:
you're probably right.
I will continue to use assertSequenceEqual for my use cases.
Actually, what confused me is that these assertions are True:
class T(tuple): pass
class L(list): pass
assertEqual(T('ab'), tuple('ab'))
assertEqual(L('ab'), list('ab'))
And when these tests fail, the output is not pretty formatted.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15810
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15810] assertSequenceEqual should be fired when comparing sequence subclasses
R. David Murray added the comment: That sounds like a bug. -- title: assertSequenceEqual should be fired when comparing sequences - assertSequenceEqual should be fired when comparing sequence subclasses ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15810 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15803] Incorrect docstring on ConfigParser.items()
Changes by R. David Murray rdmur...@bitdance.com: -- nosy: +lukasz.langa ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15803 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15803] Incorrect docstring on ConfigParser.items()
Changes by R. David Murray rdmur...@bitdance.com: -- stage: - patch review type: enhancement - behavior ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15803 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15803] Incorrect docstring on ConfigParser.items()
Chris Jerdonek added the comment: This is a nit, but there should be two spaces after the period: +each option in the section. Otherwise, return a list of tuples with -- nosy: +cjerdonek ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15803 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15810] assertSequenceEqual should be fired when comparing sequence subclasses
Ezio Melotti added the comment: The assertSequenceEqual docs[0] say: This method is not called directly by assertEqual(), but it’s used to implement assertListEqual() and assertTupleEqual(). The asserEqual docs[1] say: In addition, if first and second are the exact same type and one of list, tuple, dict, set, frozenset or str or any type that a subclass registers with addTypeEqualityFunc() the type-specific equality function will be called in order to generate a more useful default error message (see also the list of type-specific methods). assertEqual[2] calls _getAssertEqualityFunc[3] that checks if type(first) is type(second), so in your case no specific assert function is called, and since you are not comparing objects of the same type, you are not able to use addTypeEqualityFunc() either. I think in this case using assertSequenceEqual() directly is ok. [0]: http://docs.python.org/py3k/library/unittest.html#unittest.TestCase.assertSequenceEqual [1]: http://docs.python.org/py3k/library/unittest.html#unittest.TestCase.assertEqual [2]: http://hg.python.org/cpython/file/124fb2b39ed9/Lib/unittest/case.py#l637 [3]: http://hg.python.org/cpython/file/124fb2b39ed9/Lib/unittest/case.py#l604 -- nosy: +ezio.melotti ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15810 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15803] Incorrect docstring on ConfigParser.items()
Ezio Melotti added the comment: While I like to have two spaces after the period, this convenction is not enforced, and it usually depends on the style used in the file. If the double space is used elsewhere in the same document, then it should be preserved, otherwise using a single space is OK too. -- nosy: +ezio.melotti ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15803 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15803] Incorrect docstring on ConfigParser.items()
Chris Jerdonek added the comment: If the double space is used elsewhere in the same document, You can see one above the change in the patch file. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15803 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15809] IDLE console uses incorrect encoding.
Martin v. Löwis added the comment: The problem is that IDLE passes an UTF-8 encoded source string to compile, and compile, in the absence of a source encoding, uses the PEP 263 default source encoding, i.e. Latin-1. As the consequence, the variable s has the value u'\\xd0\\xa0\\xd1\\x83\\xd1\\x81\\xd1\\x81\\xd0\\xba\\xd0\\xb8\\xd0\\xb9 \\xd1\\x82\\xd0\\xb5\\xd0\\xba\\xd1\\x81\\xd1\\x82' IDLE's Default Source Encoding is irrelevant - it only applies to editor windows. One solution for that is the attached patch. However, this patch isn't right, since it will cause all source to be interpreted as UTF-8. This would be wrong when the sys.stdin.encoding is not UTF-8, and byte string objects are created in interactive mode. Interactive mode manages to get it right by looking up sys.stdin.encoding during compilation, but it does so only when in interactive mode (i.e. when tok-prompt != NULL. I don't see any way to fix this problem in Python 2. It is fixed in Python 3, basically by always assuming that the source encoding is UTF-8, by making all string objects Unicode objects, and disallowing non-ASCII characters in bytes literals -- keywords: +patch nosy: +loewis Added file: http://bugs.python.org/file27045/compile_unicode.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15809 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15803] Incorrect docstring on ConfigParser.items()
Nathan Trapuzzano added the comment: Looks like the file has about an equal number of single- and double-spaces after periods. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15803 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15812] inspect.getframeinfo() cannot show first line
New submission from Richard Oudkerk: When inspect.getframeinfo() tries to collect lines of context it never shows the first line (unless context is as big as the number of lines in the file). The relevant code is start = lineno - 1 - context//2 try: lines, lnum = findsource(frame) except IOError: lines = index = None else: -- start = max(start, 1) start = max(0, min(start, len(lines) - context)) lines = lines[start:start+context] index = lineno - 1 - start I think that start = max(start, 1) should be replaced by start = max(start, 0) For some reason getframeinfo() (and the functions which use it) don't seem to be tested by the testsuite... -- messages: 169387 nosy: sbt priority: normal severity: normal status: open title: inspect.getframeinfo() cannot show first line ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15812 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9860] Building python outside of source directory fails
Changes by Trent Nelson tr...@snakebite.org: -- nosy: +trent ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9860 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15573] Support unknown formats in memoryview comparisons
Stefan Krah added the comment: I'm trying to think of an optimization for the native types. It should be possible to cast any native type element to unsigned char and use the truncated value for the bytes hash. Well, for double probably it's required to go from double - int64_t - unsigned char, otherwise the first cast is technically undefined for negative values, though it works with gcc. For non-native types and compound types, Nick's suggestion of hashing the shape and a couple of values seems to be the best solution. Should we do anything about this before 3.3.0? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15573 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15591] when building the extensions, stdout is lost when stdout is redirected
Changes by Barry A. Warsaw ba...@python.org: -- nosy: +barry ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15591 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15813] Python function decorator scope losing variable
New submission from V.E.O:
I just learned python @ decorator, it's cool, but soon I found my modified code
coming out weird problems.
def with_wrapper(param1):
def dummy_wrapper(fn):
print param1
param1 = 'new'
fn(param1)
return dummy_wrapper
def dummy():
@with_wrapper('param1')
def implementation(param2):
print param2
dummy()
I debug it, it throws out exception at print param1
UnboundLocalError: local variable 'param1' referenced before assignment
If I remove param1 = 'new' this line, without any modify operation(link to new
object) on variables from outer scope, this routine might working.
Is it meaning I only have made one copy of outer scope variables, then make
modification?
The policy of variable scope towards decorator is different?
--
components: Interpreter Core
messages: 169389
nosy: V.E.O
priority: normal
severity: normal
status: open
title: Python function decorator scope losing variable
type: compile error
versions: Python 2.7
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15813
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15813] Python function decorator scope losing variable
R. David Murray added the comment: When you assign a value to param1 it becomes a local variable, thus the error. You should ask for help on your scoping questions from the python-tutor list or the general python-list. -- nosy: +r.david.murray resolution: - invalid stage: - committed/rejected status: open - closed type: compile error - behavior ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15813 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15811] ElementTree.write() raises TypeError when xml_declaration = True and encoding is a unicode string
David Buxton added the comment: A patch against the current default branch to add tests for the xml_declaration keyword argument. This passes when applied to the 2.7 branch too. This does NOT test whether one can use both bytes/unicode for the encoding argument. It just uses the native string type for each interpreter. I don't know whether you would actually consider that part of things worth testing yet. -- keywords: +patch Added file: http://bugs.python.org/file27046/xml_declaration_test.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15811 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15811] ElementTree.write() raises TypeError when xml_declaration = True and encoding is a unicode string
Eli Bendersky added the comment: Thanks for the patch, David. Alas, due to personal reasons I will not be able to work on core Python in the next 2-3 months. I may throw in a review here and there, but that's not a promise ;-) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15811 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15798] subprocess.Popen() fails if 0, 1 or 2 descriptor is closed
Gregory P. Smith added the comment: Yes, something along the lines of that patch is what I was thinking. BTW, this is only necessary for the errpipe_write fd. errpipe_read is for the parent process. I'm going to do it within _create_pipe so that the optimal _posixsubprocess.cloexec_pipe pipe2() based implementation can be used when possible rather than needing to call _set_cloexec() on the dup'ed fd. There are some recent Linux specific possibilities such as fcntl with F_DUPFD, or better F_DUPFD_CLOEXEC, that would make this a single call. Using that may be overkill for this situation but it looks easy enough while I'm in there. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15798 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15573] Support unknown formats in memoryview comparisons
Martin v. Löwis added the comment: 1. I STRONGLY request to take hashing out of this issue. The only further action that this issue can have is complete reversal of the patch, starting over. Now that the issue has been resolved, a NEW issue arises, namely that hashing is inconsistent with equality. Please re-read the original issue: the objective of supporting unknown formats in memoryview comparisons is achieved. Remember that by reopening the issue, you are blocking the release (since it's still a release blocker). 2. Any significant change to the 3.3.0 code base should, IMO, require an additional release candidate (since the release candidate really ought to be what is going to be released, hence the name, so NO changes between candidate and release). Do you really want to delay the release of Python 3.3 until October because of hashing of memoryview objects (which, AFAICT, only affects bytes objects in the standard library)? 3. I don't think memoryview objects should be hashable at all. No matter what definition of hashing you chose, you likely won't manage to get it consistent with ==. Since a memoryview compares equal with its underlying object, it should also hash equal. 4. (unrelated to hashing, related to the original issue) I think it will be possible to create non-transitive equalities, where A==memoryview(A)==memoryview(B)==B, yet not (A==B) 5. I'm not sure whether the hash of a memoryview will surely be constant (as it should): isn't it possible to create a read-only buffer for a mutable memory block (not PyObject), so that any hashing considering the contents will result in changing hashes? Or, since the hash is cached, couldn't that cause the hash to deviate from ==? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15573 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15811] ElementTree.write() raises TypeError when xml_declaration = True and encoding is a unicode string
Amaury Forgeot d'Arc added the comment:
Why is it a problem? Encoding must be a text string:
encoding='utf-8'
works with both Python 2 and 3.
Or if you used from __future__ import unicode_literals,
str('utf-8')
works as well.
--
nosy: +amaury.forgeotdarc
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15811
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15811] ElementTree.write() raises TypeError when xml_declaration = True and encoding is a unicode string
David Buxton added the comment:
Only a problem because I am using unicode_literals and it didn't occur to me to
use `str('utf-8')` to get a native string on both 2+3. Much the best solution,
thank you.
But that is still a little smelly - I think what I want ideally is for
ElementTree to accept str or unicode on 2.7. Either way I appreciate this is
very low priority and indeed debatable as to whether it is wrong.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15811
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11776] Constructor signatures missing in types module documentation
Mike Hoy added the comment: This should be all the requested changes. I've gone over the table entries (at least the first one, CodeType, with bitdancer on IRC). I've removed the descriptive language from below the table and added it to the table. Leaving the text below the table to deal with args and some descriptive text that was just too large to really fit into the right column of the table. One question though, do you want: BuiltinFunctionType BuiltinMethodType FrameType GeneratorType GetSetDescriptorType MemberDescriptorType TracebackType To be in the table as well. I'm a bit confused on this part. Just let me know. -- Added file: http://bugs.python.org/file27047/complete-patch-with-table-issue-11776.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11776 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15814] memoryview: equality-hash invariant
New submission from Stefan Krah: The new PEP-3118 equality definition from #15573 that is based on element-wise comparisons breaks the equality-hash invariant: from _testbuffer import ndarray x = ndarray([1,2,3], shape=[3], format='f') y = ndarray([1,2,3], shape=[3], format='B') a = memoryview(x) b = memoryview(y) a == b True hash(a) == hash(b) False -- assignee: skrah messages: 169398 nosy: Arfrever, christian.heimes, georg.brandl, haypo, loewis, mark.dickinson, meador.inge, ncoghlan, pitrou, skrah priority: normal severity: normal stage: needs patch status: open title: memoryview: equality-hash invariant type: behavior versions: Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15814 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15573] Support unknown formats in memoryview comparisons
Stefan Krah added the comment: I agree that this isn't a blocker due to the limited use of memoryview hashing. Tracking this in #15814. -- status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15573 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15805] Add stdout redirection tool to contextlib
Brett Cannon added the comment:
So Alex's point is valid: the examples in the unittest.mock.patch docs shows
how to do this
(http://docs.python.org/dev/py3k/library/unittest.mock.html#patch). So this
could be simplified to:
def redirect_stdout(replacement=None):
return unittest.mock.patch('sys.stdout', replacement if replacement is not
None else io.StringIO())
Now that being said, this is extremely common, so Nick's point of just going
ahead and providing the helper makes sense. But I wouldn't put it in contextlib
but instead in unittest.mock since it is mocking out sys.stdout.
--
nosy: +brett.cannon
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15805
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15798] subprocess.Popen() fails if 0, 1 or 2 descriptor is closed
Aleksey Filippov added the comment: It may be implemented simplier. fcntl(fd, F_DUPFD_CLOEXEC, min_fd_number) will allocate new fd at least min_fd_number. So, it is not necessary to do a lot of dup() calls. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15798 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15573] Support unknown formats in memoryview comparisons
Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com: -- resolution: - fixed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15573 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15798] subprocess.Popen() fails if 0, 1 or 2 descriptor is closed
Gregory P. Smith added the comment: F_DUPFD_CLOEXEC appears exclusive to modern Linux kernels. Any idea how wide spread support for plain F_DUPFD is? If that is everywhere the code I've just whipped up could lose a lot of loops... -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15798 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15814] memoryview: equality-hash invariant
Martin v. Löwis added the comment: I think the proper solution is to make memoryview objects unhashable. Any other approach will have flaws of some kind. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15814 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15814] memoryview: equality-hash invariant
Antoine Pitrou added the comment: I think the proper solution is to make memoryview objects unhashable. Disagreed. If memoryviews are to be bytes-like objects they should be hashable (at least when readonly). Any other approach will have flaws of some kind. Not more so than equality between memoryviews. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15814 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15798] subprocess.Popen() fails if 0, 1 or 2 descriptor is closed
Gregory P. Smith added the comment: Here's my initial fix. If fcntl(errpipe_write, F_DUPFD, 3) is widely available this could be shrunk a bit to avoid the for loop potentially calling dup a few times and tracking the wasted fds to close later. Otherwise if it isn't I'd rather not bother with F_DUPFD as this code takes the optimal path when F_DUPFD_CLOEXEC is supported (true on all modern linux systems) and should cause no harm beyond a couple extra dup and close syscalls otherwise. Note: Linux pipe2() support appears in kernels a few revisions after F_DUPFD_CLOEXEC support so the good behavior when pipe2 exists will be kept in this situation as that also means F_DUPFD_CLOEXEC support should exist. The code will work regardless of that (incase someone has a frankenkernel, or other OSes choose to implement one but not the other). -- Added file: http://bugs.python.org/file27048/issue15798-fix-gps01.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15798 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13769] json.dump(ensure_ascii=False) return str instead of unicode
Petri Lehtinen added the comment: Attached an updated patch, which is more explicit on what ensure_ascii actually does. -- Added file: http://bugs.python.org/file27049/issue13769_v2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13769 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15800] Closing of sys.std* files in gzip test.
Serhiy Storchaka added the comment: I can not imagine how it can be tested. Correction does not affect the current behavior. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15800 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15814] memoryview: equality-hash invariant
Martin v. Löwis added the comment: Am 29.08.12 20:01, schrieb Antoine Pitrou: I think the proper solution is to make memoryview objects unhashable. Disagreed. If memoryviews are to be bytes-like objects they should be hashable (at least when readonly). So what specific hash algorithm do you propose? Any other approach will have flaws of some kind. Not more so than equality between memoryviews. Well, memoryviews now have a definition of equality as discussed in issue15573. You may disagree whether it's a useful definition, but I don't believe it has actual flaws (in the sense that it is incorrect or inconsistent). My claim is that any hash definition for memoryviews will have a *fundamental* flaw, failing to provide the basic property that A==B must imply hash(A)==hash(B), making it actually work incorrectly (when used for its primary application, namely keys in dictionaries). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15814 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15814] memoryview: equality-hash invariant
Antoine Pitrou added the comment: Am 29.08.12 20:01, schrieb Antoine Pitrou: I think the proper solution is to make memoryview objects unhashable. Disagreed. If memoryviews are to be bytes-like objects they should be hashable (at least when readonly). So what specific hash algorithm do you propose? The current algorithm works well in conjunction with bytes objects. My claim is that any hash definition for memoryviews will have a *fundamental* flaw, failing to provide the basic property that A==B must imply hash(A)==hash(B), making it actually work incorrectly Why is there such a fundamental flaw? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15814 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15815] Add numerator to ZeroDivisionError messages
New submission from Terry J. Reedy:
I propose that we add 'of ' to all ZeroDivisionError messagesso it is less
necessary to use a debugger to add print statements to recover the information
currently tossed away. (I also propose to change denominator from 'zero' to
'0', '0.0', '0+0j', as appropriate.)
3//0
...
ZeroDivisionError: integer division or modulo by zero
# augment to
ZeroDivisionError: integer division or modulo of 3 by 0
Similarly for
3 / 0
ZeroDivisionError: division by zero
# perhaps this should be 'true division of 3 by 0'
3.0 / 0.0
ZeroDivisionError: float division by zero
(3+3j) / (0+0j)
ZeroDivisionError: complex division by zero
In #7482 it was proposed to make float and complex messages same as int message
by adding 'or modulo'. I an not sure why not to do that, or if it was just
deferred.
Fractions currently print the numerator as part of an invalid numerator / 0
result from *either* construction or division.
from fractions import Fraction as F
F(3, 0)
Traceback (most recent call last):
File pyshell#20, line 1, in module
F(3, 0)
File C:\Programs\Python33\lib\fractions.py, line 167, in __new__
raise ZeroDivisionError('Fraction(%s, 0)' % numerator)
ZeroDivisionError: Fraction(3, 0)
# Here, 'Fraction(3, 0)' is invalid input.
F(3, 1) / F(0, 1)
Traceback (most recent call last):
File pyshell#19, line 1, in module
F(3, 1) / F(0, 1)
File C:\Programs\Python33\lib\fractions.py, line 367, in forward
return monomorphic_operator(a, b)
File C:\Programs\Python33\lib\fractions.py, line 417, in _div
a.denominator * b.numerator)
File C:\Programs\Python33\lib\fractions.py, line 167, in __new__
raise ZeroDivisionError('Fraction(%s, 0)' % numerator)
ZeroDivisionError: Fraction(3, 0)
# Here, 'Fraction(3, 0)' is invalid output.
I found this confusing until I worked out the dual meaning. I think
ZeroDevisionError: invalid Fraction(3, 0) from construction or division
might be a bit clearer.
I have not looked at decimals.
--
components: Interpreter Core
messages: 169410
nosy: ezio.melotti, mark.dickinson, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Add numerator to ZeroDivisionError messages
type: enhancement
versions: Python 3.4
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15815
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15814] memoryview: equality-hash invariant
Martin v. Löwis added the comment: Am 29.08.12 21:06, schrieb Antoine Pitrou: So what specific hash algorithm do you propose? The current algorithm works well in conjunction with bytes objects. That's about the only type if works for. My claim is that any hash definition for memoryviews will have a *fundamental* flaw, failing to provide the basic property that A==B must imply hash(A)==hash(B), making it actually work incorrectly Why is there such a fundamental flaw? The current algorithm is flawed as described in Stefan's original message: two objects compare equal, yet hash different. That means that if you use them as dictionary keys, you may end up with two different values for the same key, depending on the size of the dictionary (as the modulo operation in the dictionary still may map the different hashes to the same dictionary slot). In general, since memoryview(obj)==obj, it would be necessary that hash(memoryview(obj))==hash(obj). However, since memoryview cannot know what hashing algorithm obj uses, it cannot compute the hash value with the same algorithm. IOW, hashing is mutually exclusive with comparison with the underlying object, unless you know what the hash algorithm of the underlying object is. So restricting tp_hash to memoryview objects where the underlying object is the bytes type would work. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15814 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15816] pydoc.py uses a hack that depends on implementation details and breaks help() when __builtin__.__import__ is overwritten.
New submission from David Kreuter: help(compile) # this works import __builtin__ real_import = __import__ __builtin__.__import__ = lambda *a: real_import(*a) help(compile) # this fails The line responsible for this is in pydoc.py around line 300: ... elif exc is ImportError and extract_tb(tb)[-1][2]=='safeimport': ... -- components: Library (Lib) messages: 169412 nosy: dkreuter priority: normal severity: normal status: open title: pydoc.py uses a hack that depends on implementation details and breaks help() when __builtin__.__import__ is overwritten. versions: Python 2.7, Python 3.1, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15816 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15816] pydoc.py uses a hack that depends on implementation details and breaks help() when __builtin__.__import__ is overwritten.
R. David Murray added the comment: Replacing __import__ is not supported. That said, this is fixed in 3.3. -- nosy: +r.david.murray resolution: - out of date stage: - committed/rejected status: open - closed type: - behavior versions: +Python 3.3 -Python 2.7, Python 3.1, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15816 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14803] Add feature to allow code execution prior to __main__ invocation
Changes by Andrew Svetlov andrew.svet...@gmail.com: -- nosy: +asvetlov ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14803 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15808] Possibility of setting custom key bindings for Additional help sources menu items
Ned Deily added the comment: Actually, IDLE does have code to look for an on-disk copy of the html-formatted Python documentation set but the paths are platform-specific and, in the Linux case, are out-of-date for some distributions at least. For Linux platforms it looks for `index.html` in either `/var/www/html/python` or `/usr/share/doc/python-docs-x.y/Doc/`. On current Debian systems, for example, the Python doc package is installed in `/usr/share/doc/pythonx.y-doc/html`. If you install the doc packages and then create a link, IDLE should find the docs off-line when you select `Python Docs` from the `Help` manual. For example, for Python 3.3 you *could* do: sudo aptitude install python3.3-doc sudo mkdir -p /var/www/html/ sudo ln -s /usr/share/doc/python3.3-doc/html python That said, the default locations should be updated. And perhaps a more useful customization would be to add a user configuration option for where to look for the on-disk copy of the docs rather than adding another hot key. (Also, older versions of Python are in security fix mode only.) -- nosy: +ned.deily stage: - needs patch versions: -Python 2.6, Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15808 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15814] memoryview: equality-hash invariant
Stefan Krah added the comment: Martin v. L??wis rep...@bugs.python.org wrote: In general, since memoryview(obj)==obj, it would be necessary that hash(memoryview(obj))==hash(obj). However, since memoryview cannot know what hashing algorithm obj uses, it cannot compute the hash value with the same algorithm. In the memoryview-hash thread on python-dev [1] this objection was addressed by demanding from exporters that they all use: hash(x) == hash(x.tobytes()) Since the previous equality concept was also based on x.tobytes() == y.tobytes(), this wasn't a problem. The new equality definition and any possible new hash definition should probably also be part of the buffer API documentation, since they aren't memoryview specific. [1] http://mail.python.org/pipermail/python-dev/2011-November/114459.html -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15814 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15814] memoryview: equality-hash invariant
Stefan Krah added the comment: And since memory_richcompare() and any potentially compatible hash function are quite tricky to implement by now, perhaps the generally useful parts could be exposed as PyBuffer_RichCompareBool() and PyBuffer_Hash(). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15814 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
