[issue15821] PyMemoryView_FromBuffer() behavior change (possible regression)
Stefan Krah added the comment:
In general, the number of calls to PyObject_GetBuffer() must be equal to
the number of calls to PyBuffer_Release(), otherwise bad things will happen
in the same way as with malloc()/free().
Now, in my test case I omitted the call to PyObject_GetBuffer() *with*
the internal knowledge that in the case of the bytes object it does
not matter: The releasebufferproc is NULL, so PyBuffer_Release()
is just a way of decrementing the reference count of the bytes object.
No matter how you turn it, if info.obj != NULL you need some internal
knowledge what the obj's releasebufferproc will do. For example, I
suspect that many existing releasebufferprocs do not account for
the fact that a consumer may change shape, strides and suboffsets.
So you need to know the exporter really well.
My strategy here is this: I want to keep backwards compatibility
for PyMemoryView_FromBuffer(), which I think should be deprecated
at some point.
A proper function that returns a memoryview with automatic cleanup
would not involve getbuffer/releasebuffer at all and could look like
this:
Flags:
--
PyManagedBuffer_FreeBuf
PyManagedBuffer_FreeFormat
PyManagedBuffer_FreeArrays // shape, strides, suboffsets
PyMemoryView_FromBufferWithCleanup(info, flags)
{
/* info should never have been obtained by a call to PyObject_GetBuffer().
Hence it should never be released. */
assert(info.obj == NULL);
/* buf, format, shape, strides and suboffsets MUST stay valid
for the lifetime of the returned memoryview. Usually they
will be dynamically allocated using PyMem_Malloc(). This is
no problem, since there is automatic cleanup in mbuf_dealloc(). */
mbuf = mbuf_alloc();
mbuf-master = *info;
mbuf-flags |= flags;
...
return new memoryview
}
mbuf_dealloc(self)
{
if (self-flagsPyManagedBuffer_FreeBuf)
PyMem_Free(self-master.buf);
...
}
This is much more flexible than the existing function and does not suffer
from any abuse of getbuffer/releasebuffer.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15821
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15837] Added test to test_random.py testing Random.shuffle
Serhiy Storchaka added the comment: The int=int is probably some sort of micro-optimization and perhaps should be removed. Agree, this micro-optimization has no effect here. -- nosy: +storchaka ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15837 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15837] Added test to test_random.py testing Random.shuffle
Alessandro Moura added the comment: Sorry, here it is the patch. -- keywords: +patch Added file: http://bugs.python.org/file27082/random.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15837 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14783] Make int() and str() docstrings correct
Ezio Melotti added the comment: The issues about weird signatures are being discussed on #15831. However, this issue is about the docstring. Leave it incorrect? Change it to the hard-to-parse one liner? Change it to a two-line signature also? For the docstring it's ok to use the double signature too. The description, while not too comprehensive, is understandable. The description of int() in the docs is instead a bit complicated. The content is good, but IMHO it would be more understandable if it was broken down into paragraphs or into a list. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14783 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15826] Increased test coverage of test_glob.py
Alessandro Moura added the comment: test_bytes_glob_directory_with_trailing_slash already has a counterpart in the main class, but it is not easily handled by overriding self.glob and self.norm. Since it is only a single test, I just decided to override test_glob_directory_with_trailing_slash from the main class. But looking at this now I realize that I actually created another method with a different name by mistake; so the attached patch changes that. -- Added file: http://bugs.python.org/file27083/test_glob.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15826 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14042] json.dumps() documentation is slightly incorrect.
Petri Lehtinen added the comment: Fixed, see #13769. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14042 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15822] installed python may fail incorrectly trying to rebuild lib2to3 grammar pickles
Ned Deily added the comment: The problem here is in the libinstall Makefile target and that hidden dependency within lib2to3 that, as Tomi notes, causes lib2to3 to try to recreate the pickles anytime it runs if it thinks they are out of date. The fixes for Issue15645 cause the recipes for that target to create the two grammar pickles in the source Lib directory before files are copied and installed into the destination lib directories. But there is no guarantee that the source files, Grammar.txt and PatternGrammar.txt, are installed into the destination lib before the corresponding pickle files are. lib2to3/pgen2/driver compares the value of os.path.getmtime() for the txt and pickle files (assuming both exist). On many (most) file systems, the copies happen fast enough and the resolution of getmtime is coarse enough that the files are created with the same time value so post-installation use of lib2to3 works OK. But on file systems like ext4 with high-resolution time values, it may happen that one or both o f the pickle files is copied first and ends up with a slightly older time value than its corresponding txt file. In that case the first use of lib2to3 will try to recreate the pickle which will most likely fail with a file permission error since the install directories are typically read-only to non-root users. The attached patch tries to work around around the problem by touching the two pickle files after they and all the other relevant lib files have been installed. Since any user could run into this problem on the right configuration, I think the fix (assuming reviewers concur with it) should be cherry-picked for 3.3.0rc2. -- components: +Installation keywords: +patch nosy: +ronaldoussoren priority: high - release blocker stage: - patch review title: Python 3.3 creates lib2to3 grammar in wrong order - installed python may fail incorrectly trying to rebuild lib2to3 grammar pickles versions: +Python 2.7, Python 3.2 Added file: http://bugs.python.org/file27084/issue15822_33.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15822 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15748] Various symlink test failures in test_shutil on FreeBSD
Trent Nelson added the comment: Not really... the problem is that the chmod 0007 actually corrupts the ZFS metadata regarding the symlink by always setting the length to 24. Andriy did some debugging here: http://lists.freebsd.org/pipermail/freebsd-fs/2012-August/015005.html So, the link basically becomes invalid once the bug hits. Here's another option I just thought of: change the tests to use something other than 0007, then add another test specifically for this issue. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15748 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15802] Nonsensical test for mailbox
Petri Lehtinen added the comment: Techincally, converting to int is not necessary, because the number of digits in the unix timestamp doesn't change until year 2286 :) The patch looks good to me. I don't think comparing pairs would be any more readable than what the proposed patch does. -- assignee: - petri.lehtinen stage: - commit review ___ 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
[issue15814] memoryview: equality-hash invariant
Stefan Krah added the comment: Here's a patch that enforces byte formats. Does everyone agree on (or tolerate at least) allowing 'B', 'b' and 'c'? I think we should at least commit the doc patch for 3.3.0. Otherwise implementors of exporting objects might waste time on a feature that's deprecated. -- Added file: http://bugs.python.org/file27085/issue15814-2.diff ___ 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
[issue15838] make install tries to create lib2to3 grammar pickles in source directory
New submission from Ned Deily: With the recent activity around making out-of-tree builds work, while investigating Issue15822 I realized that the lib2to3 grammar pickle files are being built in the source directory by the libinstall target step of the main Makefile rather than in the build directory or just in the install location. The fixes for Issue15645 moved the pickle building to the start of the target recipes: libinstall: build_all $(srcdir)/Lib/$(PLATDIR) $(srcdir)/Modules/xxmodule.c -PYTHONPATH=$(DESTDIR)$(LIBDEST) $(RUNSHARED) \ $(PYTHON_FOR_BUILD) -Wi -c import lib2to3.pygram, lib2to3.patcomp;lib2to3.patcomp.PatternCompiler() On reflection, I think the PYTHONPATH definition is bogus here since LIBDEST is populated immediately after this step. More importantly, lib2to3/pgen2/driver:load_grammar ends up writing the pickle files into the source directory. Unlike some other cases in the Makefile, if the source directory is read-only, the failure to create the pickle files is not an error during installation but it may likely cause problems for later users of the installed lib2to3 (like in the Issue15822 scenario), i.e. when the missing pickles are attempted to be created in the read-only install directories. -- components: 2to3 (2.x to 3.x conversion tool), Build, Installation messages: 169623 nosy: benjamin.peterson, ned.deily, ronaldoussoren, trent priority: normal severity: normal stage: needs patch status: open title: make install tries to create lib2to3 grammar pickles in source directory versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15838 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15802] Nonsensical test for mailbox
Roundup Robot added the comment: New changeset aef4a2ba3210 by Petri Lehtinen in branch '3.2': #15802: Fix test logic in TestMaildir.test_create_tmp http://hg.python.org/cpython/rev/aef4a2ba3210 New changeset 2370e331241b by Petri Lehtinen in branch '2.7': #15802: Fix test logic in TestMaildir.test_create_tmp http://hg.python.org/cpython/rev/2370e331241b New changeset e2fec0144bf8 by Petri Lehtinen in branch 'default': #15802: Fix test logic in TestMaildir.test_create_tmp http://hg.python.org/cpython/rev/e2fec0144bf8 -- nosy: +python-dev ___ 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
[issue15802] Nonsensical test for mailbox
Petri Lehtinen added the comment: Fixed, thanks. -- resolution: - fixed stage: commit review - committed/rejected status: open - closed ___ 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
[issue15814] memoryview: equality-hash invariant
Nick Coghlan added the comment: +1 for docs patch for 3.3.0 and then enforcing the format restriction for 3.3.1. -- ___ 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
[issue15795] Zipfile.extractall does not preserve file permissions
Changes by Alexey Boriskin sun.v...@gmail.com: -- hgrepos: +147 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15795 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15814] memoryview: equality-hash invariant
Roundup Robot added the comment: New changeset 895e123d9476 by Stefan Krah in branch 'default': Issue #15814: Document planned restrictions for memoryview hashes in 3.3.1. http://hg.python.org/cpython/rev/895e123d9476 -- nosy: +python-dev ___ 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
[issue14223] curses addch broken on Python3.3a1
Roundup Robot added the comment: New changeset 27b5bd5f0e4c by Victor Stinner in branch 'default': Close #14223: Fix window.addch(curses.ACS_HLINE) http://hg.python.org/cpython/rev/27b5bd5f0e4c -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14223 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15795] Zipfile.extractall does not preserve file permissions
Changes by R. David Murray rdmur...@bitdance.com: -- hgrepos: -147 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15795 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15795] Zipfile.extractall does not preserve file permissions
Alexey Boriskin added the comment: I'm attaching a patch, which solves the issue. Patch intoduces new argument preserve_permissions for extract and extractall methods. That argument may accept one of the three values: do not preserve permissions, preserve a safe subset of them or preserve all permissions. Three constants introduced for these options. Patch also contains test and docs. Tests pass for me on OS X 10.5, but I'm not sure if they'll pass on other operating systems. -- keywords: +patch Added file: http://bugs.python.org/file27086/issue15795.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15795 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14223] curses addch broken on Python3.3a1
STINNER Victor added the comment: I'm reopening this bug because I've noticed that in Python3.3rc1, although trying to print curses.ACS_HLINE and other such characters no long cause an Exception, only blank characters are printed to the screen. If the Python curses module is compiled in Unicode mode (if curses.unget_wch() is present), addch(int) calls the C function wadd_wch() or mvwadd_wch(), instead of waddch() or mvwaddch(). It looks like the *_wch() family does not support characters like curses.ACS_HLINE. My commit fixes the issue. @Nicholas.Cole: Can you please try the last development version (default branch)? @georg.brandl: Can you please include the important fix 27b5bd5f0e4c in Python 3.3 final? -- nosy: +georg.brandl ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14223 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14223] curses addch broken on Python3.3a1
STINNER Victor added the comment: (keep the issue open until the fix is included in Georg's repository) -- resolution: fixed - status: closed - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14223 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15785] curses.get_wch() returns keypad codes incorrectly
STINNER Victor added the comment: @georg.brandl: Can you please include the important fix c58789634d22 into Python 3.3 final? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15785 ___ ___ 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 01.09.12 13:22, schrieb Stefan Krah: Does everyone agree on (or tolerate at least) allowing 'B', 'b' and 'c'? Why be more permissive than necessary? -0 on the committed version; it should IMO further restrict it to 1D contiguous byte arrays. -- ___ 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
[issue15839] SystemError raised by super() should be NameError or RuntimeError
New submission from Ramchandra Apte: Running the erronous code: class X: super_object = super() fails with a SystemError(super(): __class__ cell not found) The exception should be a NameError or SystemError. -- components: None messages: 169634 nosy: ramchandra.apte priority: normal severity: normal status: open title: SystemError raised by super() should be NameError or RuntimeError type: behavior versions: Python 2.7, Python 3.2, Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15839 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15839] SystemError raised by super() in erronous class should be NameError or RuntimeError
Changes by Ramchandra Apte maniandra...@gmail.com: -- title: SystemError raised by super() should be NameError or RuntimeError - SystemError raised by super() in erronous class should be NameError or RuntimeError ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15839 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15599] test_circular_imports() of test_threaded_import fails on FreeBSD 9.0
Stefan Krah added the comment: The FreeBSD machine decided to hang for 1h: http://buildbot.python.org/all/builders/AMD64%20FreeBSD%209.0%203.x/builds/3340/steps/test/logs/stdio If I'm running the tests manually, they take over half an hour and I get: == FAIL: test_parallel_meta_path (test.test_threaded_import.ThreadedImportTests) -- Traceback (most recent call last): File /usr/home/stefan/cpython/Lib/test/test_threaded_import.py, line 133, in test_parallel_meta_path self.assertEqual(finder.x, finder.numcalls) AssertionError: 41 != 42 -- Ran 6 tests in 2090.042s [I hope this is not a threading bug in FreeBSD that appears under high load.] -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15599 ___ ___ 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: Why be more permissive than necessary? -0 on the committed version; it should IMO further restrict it to 1D contiguous byte arrays. Does byte arrays include 'b' and 'c' or just 'B'? I don't see a reason to allow 'B' but not the others. I'm +-0 on allowing multi-dimensional arrays, but it would be odd to restrict hashing to contiguous arrays: b = b'abcdefhhijkl' m = memoryview(b) b[::-1] b'lkjihhfedcba' bytes(m[::-1]) b'lkjihhfedcba' hash(b[::-1]) == hash(m[::-1]) True My reasoning was: If non-contiguous arrays are allowed (and I think they should be), why not allow multi-dimensional arrays, too? The definition hash(m) == hash(m.tobytes()) is pretty straightforward. -- ___ 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
[issue15599] test_circular_imports() of test_threaded_import fails on FreeBSD 9.0
Stefan Krah added the comment: I see that in the following build test_threading also fails, so I wouldn't spend too much time on debugging test_threaded_import: == FAIL: test_waitfor_timeout (test.test_threading.ConditionTests) -- Traceback (most recent call last): File /usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/test/lock_tests.py, line 531, in test_waitfor_timeout self.assertEqual(len(success), 1) AssertionError: 0 != 1 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15599 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15814] memoryview: equality-hash invariant
Alexander Belopolsky added the comment: On Sep 1, 2012, at 10:24 AM, Stefan Krah rep...@bugs.python.org wrote: The definition hash(m) == hash(m.tobytes()) is pretty straightforward. I probably missed something from the early discussion, but doesn't this definition only work for 1d (or 0d) views? Shouldn't shape come into calculation for multidimensional views? -- nosy: +Alexander.Belopolsky ___ 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
[issue15599] test_circular_imports() of test_threaded_import fails on FreeBSD 9.0
Antoine Pitrou added the comment: I see that in the following build test_threading also fails, so I wouldn't spend too much time on debugging test_threaded_import: Did something change recently on that machine? It's supposed to be a stable buildbot. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15599 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15599] test_circular_imports() of test_threaded_import fails on FreeBSD 9.0
Stefan Krah added the comment: Nothing changed on the buildbot. -- It appears that FreeBSD is unable to handle the low switchinterval. With the patch test_threaded_import runs in 10s. Since Linux has no problems whatsoever, I'm inclined to think that's a FreeBSD issue. I've yet to check if the other problem in test_threading is related. -- keywords: +patch Added file: http://bugs.python.org/file27087/issue15599.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15599 ___ ___ 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: tobytes() is the same as the flattened multi-dimensional list representation with all elements converted to bytes. If I'm not mistaken, that's how NumPy's tostring() behaves. -- ___ 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
Alexander Belopolsky added the comment: On Sep 1, 2012, at 11:06 AM, Stefan Krah rep...@bugs.python.org wrote: tobytes() is the same as the flattened multi-dimensional list representation with all elements converted to bytes. This is correct, but why is it desirable to have deliberate hash collisions between views with different shapes? -- ___ 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
Nick Coghlan added the comment: Keep in mind that its OK if hash(m) == hash(m.tobytes()) in some cases where m != m.tobytes(). The only cases we really need to kill are those that break the hash invariant. I don't like the idea of making the definition of hash more complicated just to rule out cases that aren't actually broken. -- ___ 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: why is it desirable to have deliberate hash collisions between views with different shapes? Since we're now restricting everything to bytes, the multi-dimensional case is probably not useful at all. As I said above, I would leave it in because it actually saves one check for ndim and as Nick said, the definition is simpler. Now the user only has to remember that hashing works for 'B', 'b' and 'c'. -- ___ 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
Martin v. Löwis added the comment: Am 01.09.12 16:24, schrieb Stefan Krah: Does byte arrays include 'b' and 'c' or just 'B'? I don't see a reason to allow 'B' but not the others. Either type is fine with me. It's the multi-dimensional aspect I'd like to ban. My reasoning was: If non-contiguous arrays are allowed (and I think they should be), why not allow multi-dimensional arrays, too? I think neither should be allowed. The explicit request (from Antoine) was that memoryviews of bytes objects should be hashable. I haven't heard anybody asking for something more general (but I could see that people want to hash other memory blocks as well, such as mmap views). I can see that it is tempting to provide the most general definition, but see where this approach got us. It's always easier to widen an interface later than to narrow it. -- ___ 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
[issue15523] Block on close TCP socket in SocketServer.py
Charles-François Natali added the comment: So when calling close_request to deallocate the socket, it will always be waiting to read response until response data is available. It seems like an issue in SokcetServer.py library. Hum, I don't see what you mean. Even if there is still data in the receive socket buffer, socket.clos() shouldn't block. Actually, it should result in a RST being sent. Could you describe your problem more precisely (with a code snippet it would be better)? -- nosy: +neologix ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15523 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15831] comma after leading optional argument is after bracket in docs
Georg Brandl added the comment: +1 for multiple signatures. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15831 ___ ___ 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:
Disallowing non-contiguous arrays leads to very strange situations though.
I'm positive that there will be a bug report about this:
x = memoryview(b'abc')[::-1]
b = b'cba'
d = {b'cba': 101}
b in d
True
x == b
True
x in d
Traceback (most recent call last):
File stdin, line 1, in module
ValueError: memoryiew: hashing is restricted to C-contiguous arrays
Could we perhaps take a small poll? My own vote is:
1) Allow bytes hashing at all: +0.5
2) If 1) is allowed, then also non-contiguous hashing is allowed: +1
3) Allow multi-dimensional hashing: +-0
--
___
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
[issue15831] comma after leading optional argument is after bracket in docs
Chris Jerdonek added the comment: (The double signature might be easier to understand, but the original issue should probably be fixed in Sphinx, even if we decide to stop using this kind of signature.) I filed an issue for this in the Sphinx tracker here: https://bitbucket.org/birkenfeld/sphinx/issue/1001/comma-after-leading-optional-argument-in -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15831 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14385] Support other types than dict for __builtins__
Martijn Pieters added the comment: I note that the documentation still states a dictionary is required for globals. Should that not be updated as well? See http://docs.python.org/py3k/library/functions.html#exec -- nosy: +mjpieters ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14385 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14385] Support other types than dict for __builtins__
Martijn Pieters added the comment: Apologies, I meant to link to the dev docs: http://docs.python.org/dev/library/functions.html#exec -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14385 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15831] comma after leading optional argument is after bracket in docs
Chris Jerdonek added the comment: I will prepare a patch (multiple signatures, for the Python fix). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15831 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15836] unittest assertRaises should verify excClass is actually a BaseException class
Michael Foord added the comment: Yep, certainly worth fixing. When 3.3 is out the door I will look at applying this to all branches. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15836 ___ ___ 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 01.09.12 19:20, schrieb Stefan Krah:
Disallowing non-contiguous arrays leads to very strange situations though.
I don't find that strange. That two object compare equal doesn't imply
that they both hash - only that *if* they hash, they should hash equal.
In any case, this can happen already:
py x = memoryview(array.array('B',b'cba'))
py b = b'cba'
py d = {b'cba': 101}
py b in d
True
py x == b
True
py x in d
Traceback (most recent call last):
File stdin, line 1, in module
ValueError: cannot hash writable memoryview object
It can also happen with other types (although I had to look around
a bit):
py x=set((1,2,3))
py b=frozenset(x)
py d={b:101}
py b in d
True
py x==b
True
py x in d
Traceback (most recent call last):
File stdin, line 1, in module
TypeError: unhashable type: 'set'
1) Allow bytes hashing at all: +0.5
+0
2) If 1) is allowed, then also non-contiguous hashing is allowed: +1
-1
3) Allow multi-dimensional hashing: +-0
-1
--
___
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
[issue15836] unittest assertRaises should verify excClass is actually a BaseException class
Changes by Ezio Melotti ezio.melo...@gmail.com: -- nosy: +ezio.melotti ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15836 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11866] race condition in threading._newname()
Changes by Charles-François Natali neolo...@free.fr: -- stage: - commit review ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11866 ___ ___ 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: Could we perhaps take a small poll? My own vote is: 1) Allow bytes hashing at all: +0.5 +10. The buffer() object in 2.x was hashable, and a very important use case of memoryview is replacing buffer(). 2) If 1) is allowed, then also non-contiguous hashing is allowed: +1 3) Allow multi-dimensional hashing: +-0 I don't care about these. I kind of agree with Martin that hashability should be motivated by an use case, so -0. -- ___ 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
[issue11866] race condition in threading._newname()
Antoine Pitrou added the comment: With or without Raymond's suggested change, global _counter is not necessary anymore. Note that this fix only works on implementations where itertools.count().next is atomic. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11866 ___ ___ 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:
py x = memoryview(array.array('B',b'cba'))
I find the array example is different. The user has to remember one thing:
memoryviews based on arrays don't hash.
For memoryviews based on bytes one would have to remember:
- 'B', 'c' and 'b' hash
- only C-contiguous arrays hash
- b'abc'[::-1] hashes, but memoryview(b'abc')[::-1] does not
--
___
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
[issue15836] unittest assertRaises should verify excClass is actually a BaseException class
R. David Murray added the comment: Since it is a bugfix it can be applied at any time now. Checkins to default will end up in 3.3.1 and 3.4. (Only features need to wait until after 3.3 is branched in the main repo.) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15836 ___ ___ 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 01.09.12 20:06, schrieb Stefan Krah: - b'abc'[::-1] hashes, but memoryview(b'abc')[::-1] does not I find that memoryview(b'abc')[::-1] is a strange thing to have, anyway, so I'm not bothered by it behaving different. I can accept that it needs to be supported for consistency, but I would recommend against using it in applications. Who needs reversed memory, anyway? The only case were I ever needed reversal is lists (typically sorted, perhaps cronological). -- ___ 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
[issue15840] Ambiguity with regard to the effect of accessing a closed IOBase instance
New submission from Alexander Konovalenko: Two pieces of the documentation for io.IOBase seem to contradict each other: At http://docs.python.org/library/io.html#io.IOBase: Note that calling any method (even inquiries) on a closed stream is undefined. Implementations may raise IOError in this case. At http://docs.python.org/library/io.html#io.IOBase.close: Once the file is closed, any operation on the file (e.g. reading or writing) will raise a ValueError. Perhaps the confusion arises in part because it is not clear when a requirement for all IOBase implementations is documented and when the docs merely describe the default behavior of IOBase that implementations are free to override. Those passages are inconsistent on two points: 1) IOError and ValueError are not subclasses one of another. So what should we expect an IOBase implementation to raise? 2) Undefined behavior means literally anything can happen. Technically, that means calling read() or readable() on a closed file (or other kind of stream) could wreak havoc in a totally unrelated part of the system or segfault the Python interpreter. That is definitely a thing to carefully avoid in any production systems. On the other hand, raising an exception, even if we don't know in advance whether it will be ValueError or IOError, is pretty much defined behavior. An exception is easy to deal with and to contain inside a module. So please clarify how dangerous it actually is to access an IOBase stream after it has been closed. -- assignee: docs@python components: Documentation messages: 169660 nosy: alexkon, docs@python priority: normal severity: normal status: open title: Ambiguity with regard to the effect of accessing a closed IOBase instance versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15840 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15599] test_circular_imports() of test_threaded_import fails on FreeBSD 9.0
Antoine Pitrou added the comment: Since Linux has no problems whatsoever, I'm inclined to think that's a FreeBSD issue. Maybe. If you believe it's so, I guess the patch can be committed. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15599 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1528167] Tweak to make string.Templates more customizable
R. David Murray added the comment: I don't think this closure was appropriate. The idea was accepted twice and argued against once, so it isn't dead (it's just resting). -- assignee: barry - nosy: +r.david.murray resolution: wont fix - status: closed - open versions: +Python 3.4 -Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1528167 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15840] Ambiguity with regard to the effect of accessing a closed IOBase instance
Antoine Pitrou added the comment: 1) IOError and ValueError are not subclasses one of another. So what should we expect an IOBase implementation to raise? Ideally, ValueError should be raised, but I suspect some methods raise IOError instead. Undefined behavior means literally anything can happen. In practice, it will either raise an error, or be ignored. For example, calling close() a second time would be ignored. Calling readable() may return the original value (before the file was closed), etc. Any non-trivial behaviour should be reported as a bug, though. Especially, reading or writing methods (read(), write(), readline() etc.) should *never* succeed on a closed file. -- components: +IO nosy: +pitrou stage: - needs patch versions: +Python 3.2, Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15840 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15840] Ambiguity with regard to the effect of accessing a closed IOBase instance
Antoine Pitrou added the comment: Actually, I would suggest we standardize the docs on raising ValueError as the official behaviour, and fix non-compliant behaviours as bugs. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15840 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15841] Some StringIO and BytesIO methods can succeed after close
New submission from Antoine Pitrou: f = io.StringIO() f.close() f.readable() True f.read() Traceback (most recent call last): File stdin, line 1, in module ValueError: I/O operation on closed file. f = io.BytesIO() f.close() f.readable() True f.read() Traceback (most recent call last): File stdin, line 1, in module ValueError: I/O operation on closed file -- components: IO, Library (Lib) messages: 169665 nosy: pitrou priority: normal severity: normal status: open title: Some StringIO and BytesIO methods can succeed after close type: behavior versions: Python 2.7, Python 3.2, Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15841 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15841] Some StringIO and BytesIO methods can succeed after close
Changes by Antoine Pitrou pit...@free.fr: -- nosy: +benjamin.peterson, hynek, stutzbach ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15841 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15840] Ambiguity with regard to the effect of accessing a closed IOBase instance
Changes by Antoine Pitrou pit...@free.fr: -- nosy: +benjamin.peterson, hynek, stutzbach ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15840 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15842] Some SocketIO methods can succeed after close()
New submission from Antoine Pitrou: import socket s = socket.socket() f = s.makefile(rb, buffering=0) f socket.SocketIO object at 0x7f2f323cd790 f.close() f.writable() False f.readable() False -- components: IO, Library (Lib) messages: 169666 nosy: benjamin.peterson, hynek, pitrou, stutzbach priority: normal severity: normal status: open title: Some SocketIO methods can succeed after close() type: behavior versions: Python 3.2, Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15842 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15840] Ambiguity with regard to the effect of accessing a closed IOBase instance
Antoine Pitrou added the comment: Related: issue15841 and issue15842. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15840 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2771] Test issue
Changes by Ezio Melotti ezio.melo...@gmail.com: -- hgrepos: +148 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2771 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15826] Increased test coverage of test_glob.py
R. David Murray added the comment: I've modified your patch slightly (cosmetic only). When I run it on default I get the following: /home/rdmurray/python/p33/Lib/os.py:263: BytesWarning: Comparison between bytes and string if tail == curdir: # xxx/newdir/. exists if xxx/newdir exists /home/rdmurray/python/p33/Lib/glob.py:63: BytesWarning: Comparison between bytes and string if basename == '': These presumably represent bugs. Care to investigate and file issues for them? -- Added file: http://bugs.python.org/file27088/test_glob.patch.updated ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15826 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2771] Test issue
Changes by Ezio Melotti ezio.melo...@gmail.com: -- keywords: +patch Added file: http://bugs.python.org/file27089/b17f9a10235f.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2771 ___ ___ 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
R. David Murray added the comment: Added some review comments on 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
[issue15599] test_circular_imports() of test_threaded_import fails on FreeBSD 9.0
Stefan Krah added the comment: The extreme slowness with a low switch interval is already present in 3430d7329a3b, so it's not related to the finer-grained import lock. The other FreeBSD 9.0 bots don't seem to have that problem, so I'm not sure any more if the patch is a good idea. FWIW, http://buildbot.python.org/all/buildslaves/koobs-freebsd runs in VirtualBox, my system runs in kvm. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15599 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14570] Document json sort_keys parameter properly
Changes by Chris Rebert pyb...@rebertia.com: Added file: http://bugs.python.org/file27090/json.rst.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14570 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14570] Document json sort_keys parameter properly
Chris Rebert added the comment: Attached updated patches. -- Added file: http://bugs.python.org/file27091/json_init.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14570 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15822] installed python may fail incorrectly trying to rebuild lib2to3 grammar pickles
Arfrever Frehtes Taifersar Arahesis added the comment: - done + done; \ Not needed. + touch $(DESTDIR)$(LIBDEST)/lib2to3/*Grammar*.pickle || true - prefix can be used to ignore failure of command: + -touch $(DESTDIR)$(LIBDEST)/lib2to3/*Grammar*.pickle However maybe failure of touch should not be ignored here. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15822 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15843] aifc.open expects only str or file pointer
New submission from Alastair Porter: Passing a unicode filename to aifc.open() results in the argument being treated like a filepointer instead of opening the file. The argument check, http://hg.python.org/cpython/file/default/Lib/aifc.py#l332 only checks if the argument is a str. Should this be extended to accept all string-type objects? Example usage: import aifc aifc.open(u/some/path) Traceback (most recent call last): File stdin, line 1, in module File /System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/aifc.py, line 924, in open return Aifc_read(f) File /System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/aifc.py, line 335, in __init__ self.initfp(f) File /System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/aifc.py, line 286, in initfp chunk = Chunk(file) File /System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/chunk.py, line 61, in __init__ self.chunkname = file.read(4) AttributeError: 'unicode' object has no attribute 'read' -- components: None messages: 169673 nosy: alastairp priority: normal severity: normal status: open title: aifc.open expects only str or file pointer type: behavior versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15843 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15822] installed python may fail incorrectly trying to rebuild lib2to3 grammar pickles
Ned Deily added the comment: I did it that way to ensure that the touch is executed after the copies. And the touch needs to be optional because the creation of the pickles can optionally fail. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15822 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15826] Increased test coverage of test_glob.py
Alessandro Moura added the comment: Im OK with the patch changes. ''' /home/rdmurray/python/p33/Lib/os.py:263: BytesWarning: Comparison between bytes and string if tail == curdir: # xxx/newdir/. exists if xxx/newdir exists /home/rdmurray/python/p33/Lib/glob.py:63: BytesWarning: Comparison between bytes and string if basename == '': ''' Yes, I do see these warnings running with -b. I will look into them and try to fix them. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15826 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15744] missing tests for {RawIO,BufferedIO,TextIO}.writelines
Changes by Antoine Pitrou pit...@free.fr: -- nosy: +benjamin.peterson, hynek, stutzbach ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15744 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15822] installed python may fail incorrectly trying to rebuild lib2to3 grammar pickles
Arfrever Frehtes Taifersar Arahesis added the comment: And the touch needs to be optional because the creation of the pickles can optionally fail. If creation of pickles failed, then touch will create 1 file literally named *Grammar*.pickle. ... done; \ for i in $(DESTDIR)$(LIBDEST)/lib2to3/*Grammar*.pickle; do \ if test -f $$i; then \ touch $$i; \ fi; \ done -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15822 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15822] installed python may fail incorrectly trying to rebuild lib2to3 grammar pickles
Ned Deily added the comment: Right you are, thanks! I had that in an earlier version. Are you able to verify the fix? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15822 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15645] 2to3 Grammar pickles not created when upgrading to 3.3.0b2
Arfrever Frehtes Taifersar Arahesis added the comment: libinstall target now contains: -PYTHONPATH=$(DESTDIR)$(LIBDEST) $(RUNSHARED) \ $(PYTHON_FOR_BUILD) -Wi -c import lib2to3.pygram, lib2to3.patcomp;lib2to3.patcomp.PatternCompiler() ... @for d in $(LIBSUBDIRS); \ do \ a=$(srcdir)/Lib/$$d; \ if test ! -d $$a; then continue; else true; fi; \ if test `ls $$a | wc -l` -lt 1; then continue; fi; \ b=$(LIBDEST)/$$d; \ for i in $$a/*; \ There is a small chance that with high parallelization the wildcard expansion in the last line will occur for $$a == lib2to3 before creation of pickles has finished, resulting in not installation of pickles. The solution would be to move creation of pickles to a separate target and make it a dependency of libinstall target. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15645 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15645] 2to3 Grammar pickles not created when upgrading to 3.3.0b2
Arfrever Frehtes Taifersar Arahesis added the comment: I meant $$d == lib2to3 and $$a == $(srcdir)/Lib/lib2to3 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15645 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15844] weird import errors
New submission from Daniel Swanson: I'm dealing with a bunch of nested folders and my imports have gone crazy. When I try to test one of the lower level scripts that imports one of the higher level one it gives me an error message. But, when I run the top one, (which cascadingly imports just about everything) it doesn't. And now I've got one trying to import something on the same level and it says it doesn't exist! This happens whenever I try to use folders, because of this, I only have one file of programs. -- components: None messages: 169680 nosy: weirdink13 priority: normal severity: normal status: open title: weird import errors type: behavior versions: Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15844 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15844] weird import errors
Daniel Swanson added the comment: correcting self. And now I've got one trying to import something on the same level and it says it doesn't exist! Should have been: And now I've got the top one importing one that's importing one on the same level and saying it doesn't exist! -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15844 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15814] memoryview: equality-hash invariant
Nick Coghlan added the comment: +1 for allowing bytes hashing. As Antoine noted, the 1D bytes variant of memoryview() fills the role previously handled by buffer(). +1 for allowing 1D non-contiguous hashing. This is from a simplicity perspective, as I don't want to have to explain to people why hash(memoryview(b'12'[::2])), hash(memoryview(b'123'[::2])) and hash(memoryview(b'12')[::2]) all work, but hash(memoryview(b'123')[::2]) fails. -1 for allowing hashing when ndim 1. We don't have a solid use case, and there's no odd value based corner cases to be considered. -- ___ 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
[issue15845] Fixing some byte-to-string conversion warnings
New submission from Alessandro Moura: This is related to issue 15826. When run with the -b option, some glob.py and os.py functions give warnings due to byte-to-string conversions: amoura@amoura-laptop:~/cpython$ ./python -b -c import glob; glob.glob(b'cover*/glob.cover') /home/amoura/cpython/Lib/glob.py:64: BytesWarning: Comparison between bytes and string if basename == '': amoura@amoura-laptop:~/cpython$ ./python -b -c import os; os.makedirs(b'tst/making/dirs') /home/amoura/cpython/Lib/os.py:266: BytesWarning: Comparison between bytes and string if tail == cdir: # xxx/newdir/. exists if xxx/newdir exists The attached patch fixes this. There is a rather more mysterious phenomenon with exceptions (which is triggered by test_exceptions for ImportException, but it happens for any Exception class): e = Exception(b'aaa') [60596 refs] e.args[0] b'aaa' [60601 refs] str(e) __main__:1: BytesWarning: str() on a bytes instance b'aaa' [60615 refs] e.args[0] b'aaa' [60615 refs] str(e) b'aaa' [60615 refs] e.args[0] b'aaa' [60615 refs] In other words, if a bytes argument is given to the exception, the first call to str triggers the warning, but further calls don't. Is this worth pursuing? -- components: Library (Lib) files: os_glob_bytes.patch keywords: patch messages: 169683 nosy: eng793 priority: normal severity: normal status: open title: Fixing some byte-to-string conversion warnings type: enhancement versions: Python 3.3 Added file: http://bugs.python.org/file27092/os_glob_bytes.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15845 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15844] weird import errors
Benjamin Peterson added the comment: Please provide a reproducable test case. -- nosy: +benjamin.peterson ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15844 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15839] SystemError raised by super() in erronous class should be NameError or RuntimeError
Changes by Benjamin Peterson benja...@python.org: -- versions: +Python 3.4 -Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15839 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15839] SystemError raised by super() in erronous class should be NameError or RuntimeError
Roundup Robot added the comment: New changeset e2e4a0a49d2e by Benjamin Peterson in branch 'default': Make super() internal errors RuntimeError instead of SystemError (closes #15839) http://hg.python.org/cpython/rev/e2e4a0a49d2e -- nosy: +python-dev resolution: - fixed stage: - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15839 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
