[issue16864] sqlite3.Cursor.lastrowid isn't populated when executing a SQL REPLACE statement
Alex Lord added the comment: Went back to test to see if the other statements are covered already. Unit tests show that lastrowid is set properly no matter what form of sqlite insert statement is used. sqlite_lastrowid_35_v2.patch contains the doc changes, unit test changes, and code change. I believe that the latest version of this patch is ready for a code review by a core dev. -- Added file: http://bugs.python.org/file39339/sqlite_lastrowid_35_v2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16864 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18789] XML Vunerability Table Unclear
Raymond Hettinger added the comment: The table would still be more clear with safe and vulnerable entries. -- nosy: +rhettinger ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18789 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24161] PyIter_Check returns false positive for objects of type instance
New submission from behzad nouri: - python 2 only, not reproducible on python 3 Attached file makes an extension module which just returns PyIter_Check value on passed object. Calling the function with an object of type instance returns true, even though the object is not iterator: import spam class Foo: ... pass ... foo = Foo() type(foo) type 'instance' spam.isiter(foo) # ?! 1 next(foo) TypeError: instance has no next() method -- components: Interpreter Core files: spammodule.c messages: 242866 nosy: behzad.nouri priority: normal severity: normal status: open title: PyIter_Check returns false positive for objects of type instance type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file39335/spammodule.c ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24161 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24017] Implemenation of the PEP 492 - Coroutines with async and await syntax
Changes by Yury Selivanov yseliva...@gmail.com: -- dependencies: +add a Generator ABC ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24017 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24017] Implemenation of the PEP 492 - Coroutines with async and await syntax
Yury Selivanov added the comment: New patch is attached. Nick, I think that all of your feedback should be addressed in this patch. Major changes: 1. There are two code flags now: CO_COROUTINE and CO_GENBASED_COROUTINE (I'm OK to use another name, see my older comments). CO_COROUTINE is assigned to all 'async def' code objects. CO_GENBASED_COROUTINE is assigned to generator-based coroutines decorated with types.coroutine(). 2. tp_await renamed to tp_as_async. (I'm OK to use another name, please see my older comment first) PyAsyncMethods struct holds three slots: am_await, am_aiter, am_anext. Implementing am_exit would be tricky, because of how SETUP_WITH opcode is engineered. I'd really prefer to not to add it. 3. collections.abc.Coroutine. 4. etc (all other feedback from you). -- Added file: http://bugs.python.org/file39337/await_05.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24017 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21800] Implement RFC 6855 (IMAP Support for UTF-8) in imaplib.
Roundup Robot added the comment: New changeset 195343b5e64f by R David Murray in branch 'default': #21800: Add RFC 6855 support to imaplib. https://hg.python.org/cpython/rev/195343b5e64f -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21800 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24134] assertRaises can behave differently
R. David Murray added the comment: Yeah, the general case of wrappers is something I hadn't considered. Probably we should go the deprecation route. Robert, what's your opinion? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24134 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24161] PyIter_Check returns false positive for objects of type instance
Raymond Hettinger added the comment: The PyIter_Check() macro in Include/abstract.h does a quick test to see whether the tp_iternext slot is null or marked as not implemented. That works for builtin types but not for user defined classes (heap types). Old-style instances, see Objects/classobject.c::instance_iternext(), all define iternext with code that attempts lookup and call to the next() method, and if not it is not found, raises the TypeError you are seeing. The conflict is that PyIter_Check() aims to be a fast check of a static slot entry while instance_iternext() aims for a dynamic call-it-and-see-if-it-works check much like PyObject_HasAttr() does. Since this code is very old (back to Python 2.2) and has been mostly harmless (as far as we know), one resolution would be to just document this as a known limitation of PyIter_Check(). Rather than using PyIter_Check(), extensions should just call next() on object and see whether it succeeds. -- nosy: +rhettinger ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24161 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16864] sqlite3.Cursor.lastrowid isn't populated when executing a SQL REPLACE statement
Alex Lord added the comment: Thanks for Alex_gayner and lifeless. They pointed out the sqlite3_last_row_id is part of the sqlite3 module itself (not cpython). https://www.sqlite.org/c3ref/last_insert_rowid.html According the documentation we can expect that if a constraint stops an insertion then the lostrowid is not modified. As such the changes required to add full INSERT OR CONDITION support for last row id is unit tests for each statement and changing the conditional to recognize all insert cases. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16864 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24158] Error of the hint of upgrading pip
Donald Stufft added the comment: Hey, This is actually a message that comes from a third party component, pip in this case. I've opened up https://github.com/pypa/pip/issues/2773 with the pip project and suggest that further discussion/tracking happen there. It will be picked up by Python automatically when it gets fixed in pip and released and updated in Python. -- resolution: - third party status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24158 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24161] PyIter_Check returns false positive for objects of type instance
behzad nouri added the comment: That works for builtin types but not for user defined classes Rather than using PyIter_Check(), extensions should just call next() on object and see whether it succeeds but then, what would be the use case of PyIter_Check outside of python core? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24161 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21800] Implement RFC 6855 (IMAP Support for UTF-8) in imaplib.
R. David Murray added the comment: Thanks, Maciek (and Milan). I tweaked your patch slightly (mostly doc changes...I moved the discussion of the utf8 RFC into the enable method only, and added back the docs for utf8_enabled). I made some review comments about the changes other than that doc reorg that I made before commit, just FYI. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21800 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20362] longMessage attribute is ignored in unittest.TestCase.assertRegexpMatches etc
Ilia Kurenkov added the comment: Hi there! I was wondering if anyone had a chance to take a look at this :) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20362 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23970] Update distutils.msvccompiler for VC14
Steve Dower added the comment: Any further comments on this? I'd like to get it in for beta (though I don't believe it's covered by feature freeze). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23970 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23955] Add python.ini file for embedded/applocal installs
Steve Dower added the comment: Any further comments/bikeshedding on the applocal parameter? I still need to do some docs, but I want the basic design agreed upon first. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23955 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15027] Faster UTF-32 encoding
Mark Lawrence added the comment: As this appears to be a performance improvement only can it go into 3.5 or do we wait for 3.x? -- nosy: +BreamoreBoy ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15027 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24162] [2.7 regression] test_asynchat test failure on i586-linux-gnu
New submission from Matthias Klose: I see this on i586-linux-gnu and i686-linux-gnu. Reverting the 95844:fb6c2fbbde34 commit makes the problem go away. python: ../Modules/_collectionsmodule.c:711: deque_del_item: Assertion `i = 0 i (((PyVarObject*)(deque))-ob_size)' failed. Makefile:818: recipe for target 'test' failed make[1]: *** [test] Aborted (core dumped) -- components: Library (Lib) messages: 242875 nosy: benjamin.peterson, doko, rhettinger priority: release blocker severity: normal status: open title: [2.7 regression] test_asynchat test failure on i586-linux-gnu type: crash versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24162 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24163] shutil.copystat pukes when attribute security.selinux is present
New submission from Spencer Stirling: Using shutil.copytree to copy a directory tree. The source dir lives on a Windows 7 host, however is being accessed from inside a VirtualBox VM as a shared folder (using vagrant to manage this whole thing). The destination directory is just a regular linux directory inside the VM. The guest OS is CentOS 5. shutil.copystat dies on this copy. I have tracked the problem down to line 154 in shutil.py: os.setxattr(dst, name, value, follow_symlinks=follow_symlinks) The issue is that the src directory apparently defines the attribute security.selinux, however setxattr doesn't see this attribute in the destination and throws an exception. -- components: IO messages: 242881 nosy: sstirlin priority: normal severity: normal status: open title: shutil.copystat pukes when attribute security.selinux is present type: behavior versions: Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24163 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24161] PyIter_Check returns false positive for objects of type instance
Raymond Hettinger added the comment: but then, what would be the use case of PyIter_Check outside of python core? You could still use it anywhere. It will give a correct result in the cases of extension modules, builtin types, and new-style classes. It will give a false positive in the case of old-style classes. The latter case doesn't seem to be of much consequence (there is a still a TypeError raised when next() is called), so you just find out a bit later than you otherwise would (I believe that is why this is why we haven't gotten a bug report in the 13+ years this code has existed). The feature is imperfect, incomplete and not as useful as it could be. But this ship sailed a long time ago. It is far too late for redesign (and risking unintended breakage). FWIW, PyIter_Check() is used several times in the Python core: sqlite, cPickle, and iter(). In those examples, there seem to be no adverse consequences for the false positive because we still get a TypeError downstream when the actual call is made to next(). -- assignee: - docs@python components: +Documentation -Interpreter Core nosy: +docs@python priority: normal - low stage: - needs patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24161 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1818] Add named tuple reader to CSV module
Ilia Kurenkov added the comment: Friendly reminder that this exists. I know everyone's busy and this is marked as low-priority, but I'm gonna keep bumping this till we add a solution :) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1818 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24163] shutil.copystat fails when attribute security.selinux is present
Changes by Raymond Hettinger raymond.hettin...@gmail.com: -- title: shutil.copystat pukes when attribute security.selinux is present - shutil.copystat fails when attribute security.selinux is present ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24163 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24161] PyIter_Check returns false positive for objects of type instance
Changes by Raymond Hettinger raymond.hettin...@gmail.com: -- keywords: +patch Added file: http://bugs.python.org/file39338/doc_iter_check.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24161 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16864] sqlite3.Cursor.lastrowid isn't populated when executing a SQL REPLACE statement
Alex Lord added the comment:
Updated the patch to have a versionchanged for lastrowid in
Doc/Library/sqlite3.rst and Doc/whatsnew/3.5.rst
One thing of note is that I wasn't able to get the indentation to be on the
same level for sqlite3.rst (it would either intent the description text or the
versionchange text).
Now that I'm actually starting to understand the dbapi and sqlite3 I've come to
the conclusion that the lastrowid method should update the lastrowid for the
INSERT OR ROLLBACK, INSERT OR ABORT, INSERT OR FAIL, INSERT OR IGNORE
statements as well as the INSERT and INSERT OR REPLACE statements.
I'm unsure how hard or simple supporting those statements will be
The code in question is
704 Py_DECREF(self-lastrowid);$
705 if (!multiple statement_type == STATEMENT_INSERT) {$
706 sqlite_int64 lastrowid;$
707 Py_BEGIN_ALLOW_THREADS$
708 lastrowid = sqlite3_last_insert_rowid(self-connection-db);$
709 Py_END_ALLOW_THREADS$
710 self-lastrowid = _pysqlite_long_from_int64(lastrowid);
And the difficulty will be if sqlite3_last_insert_rowid (line 708) does or
doesn't return a row id if the OR STATEMENT portion of those inserts are
triggered.
The Problem I'm having is that when I tried to find sqlite3_last_insert_rowid
in the Modules/_sqlite directory I got nothing
$ grep -r sqlite3_last_insert_rowid Modules/_sqlite/
Modules/_sqlite//cursor.c:lastrowid =
sqlite3_last_insert_rowid(self-connection-db);
When I pulled the grep out to the entire cpython repository
$ grep -r sqlite3_last_insert_rowid .
Binary file
./build/lib.macosx-10.10-x86_64-3.5-pydebug/_sqlite3.cpython-35dm-darwin.so
matches
Binary file ./build/lib.macosx-10.10-x86_64-3.5-pydebug/_sqlite3.so matches
Binary file
./build/temp.macosx-10.10-x86_64-3.5-pydebug/Users/alexlord/mercurial/cpython/Modules/_sqlite/cursor.o
matches
./Modules/_sqlite/cursor.c:lastrowid =
sqlite3_last_insert_rowid(self-connection-db);
I still didn't find anything and I'm not sure where to go from here.
--
Added file: http://bugs.python.org/file39336/sqlite_lastrowid_35.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16864
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24153] threading/multiprocessing tests fail on chromebook under crouton generated chroots
Changes by Davin Potts pyt...@discontinuity.net: -- nosy: +davin ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24153 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24134] assertRaises can behave differently
Serhiy Storchaka added the comment: Agree, this change breaks general wrappers around assertRaises, and this breakage is unavoidable. Likely we should rollback changes in maintained releases. The fix in Django doesn't LGTM. It depends on internal detail. More correct fix should look like: def assertRaisesMessage(self, expected_exception, expected_message, *args, **kwargs): return six.assertRaisesRegex(self, expected_exception, re.escape(expected_message), *args, **kwargs) I used special sentinel because it is simple solution, but we should discourage to use this detail outside the module. Proposed patch (for 3.5) uses a little more complex approach, that doesn't attract to use implementation details. In additional, added more strict argument checking, only the msg keyword parameter now is acceptable in context manager mode. Please check changed docstrings. It is possible also to make transition softer. Accept None as a callable and emit the deprecation warning. -- resolution: fixed - stage: resolved - patch review status: closed - open Added file: http://bugs.python.org/file39334/assert_raises_args.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24134 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24156] test.test_ssl.ThreadedTests unit test failed
New submission from Roman Rader:
==
FAIL: test_server_accept (test.test_ssl.ThreadedTests)
--
Traceback (most recent call last):
File /home/roma/Documents/MY/cpython/Lib/test/test_ssl.py, line 2904, in
test_server_accept
self.assertEqual(peer, client_addr)
AssertionError: Tuples differ: ('192.168.1.103', 43446) != ('127.0.0.1', 43446)
--
components: +Tests
title: unit test - test.test_ssl.ThreadedTests unit test failed
versions: +Python 3.5
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24156
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24156] unit test
Changes by Roman Rader antig...@gmail.com: -- nosy: Roman.Rader priority: normal severity: normal status: open title: unit test ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24156 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24134] assertRaises can behave differently
R. David Murray added the comment: Given one failure there are probably more. So we should probably back this out of 2.7 and 3.4. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24134 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21162] code in multiprocessing.pool freeze if inside some code from scikit-learn (and probably liblinear) executed on ubuntu 12.04 64 Bit
Ivan K added the comment: This behaviour was reproduced on Ubuntu 12.04 and on Centos 7 (centos image running on vagrant) so I don't expect this is ddistro specific -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21162 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24134] assertRaises can behave differently
Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com: -- nosy: +Arfrever ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24134 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24017] Implemenation of the PEP 492 - Coroutines with async and await syntax
Andrew Svetlov added the comment: On Sun, May 10, 2015 at 7:21 PM, Yury Selivanov rep...@bugs.python.org wrote: Yury Selivanov added the comment: Review sent - very nice work on this Yury. Thanks a lot, Nick! Highlights: * I concur with Stefan that we should have a full PyCoroutineMethods struct at the C level, with a tp_as_coroutine pointer to that replacing the current tp_reserved slot Do you think that tp_as_async is a better name? (I explained my point of view in code review comments) Also, do we need slots for __aenter__ and __aexit__? We don't have slots for regular context manager protocol, fwiw. * I also concur with Stefan about adding a Coroutine ABC I will. We definitely need it. * PyType_FromSpec (and typeslots.h) will need updating once we agree on a slot structure (with my recommendation being define C level slots for all of the new PEP 492 methods) * I found CO_COROUTINE/CO_NATIVE_COROUTINE confusing as a reader of the implementation, as they only told me how the objects were defined, rather than telling me why I should care. Based on what I gleaned of their intended purpose from reading the implementation, I suggest switching this to instead use CO_COROUTINE (set for all coroutines, regardless of how they were defined) and CO_ITERABLE_COROUTINE (set only for those coroutines that also support iteration), and adjusting the naming of other APIs accordingly. I agree that CO_COROUTINE is something that we should use for 'async def' functions (instead of CO_NATIVE_COROUTINE). However, CO_ITERABLE_COROUTINE sounds a bit odd to me, as generator-based coroutines (at least in asyncio) aren't supposed to be iterated over. How about CO_GENBASED_COROUTINE flag? Maybe CO_ASYNC_COROUTINE and CO_OLDSTYLE_COROUTINE? This is wild proposal, feel free to ignore it. * I found the names of the WITH_CLEANUP_ENTER and WITH_CLEANUP_EXIT bytecodes misleading, as they don't refer to the corresponding context management phases - they're both related to the exit phase. WITH_CLEANUP_START and WITH_CLEANUP_FINISH should be clearer for readers (both of the implementation and of the disassembled bytecode). Big +1. Your names are much better. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24017 ___ -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24017 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24159] Misleading TypeError when pickling bytes to a file opened as text
Changes by Jon Clements jon...@googlemail.com: -- nosy: +joncle ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24159 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24157] test_urandom_fd_reopened failure on Mac OS X
New submission from Skip Montanaro: Got this reproducibly on the cpython branch on my Mac (Yosemite 10.10.3). It succeeds on my 3.4 branch, both updated a few minutes ago. Didn't see it already reported: % ./python.exe Lib/test/test_os.py s..sss.ss...s...s.sss.s.sssF...ss == FAIL: test_urandom_fd_reopened (__main__.URandomFDTests) -- Traceback (most recent call last): File Lib/test/test_os.py, line 1273, in test_urandom_fd_reopened self.assertEqual(len(out), 8) AssertionError: 66 != 8 -- Ran 189 tests in 1.352s FAILED (failures=1, skipped=41) -- components: Tests messages: 242856 nosy: skip.montanaro priority: normal severity: normal status: open title: test_urandom_fd_reopened failure on Mac OS X versions: Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24157 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24017] Implemenation of the PEP 492 - Coroutines with async and await syntax
Yury Selivanov added the comment: Review sent - very nice work on this Yury. Thanks a lot, Nick! Highlights: * I concur with Stefan that we should have a full PyCoroutineMethods struct at the C level, with a tp_as_coroutine pointer to that replacing the current tp_reserved slot Do you think that tp_as_async is a better name? (I explained my point of view in code review comments) Also, do we need slots for __aenter__ and __aexit__? We don't have slots for regular context manager protocol, fwiw. * I also concur with Stefan about adding a Coroutine ABC I will. We definitely need it. * PyType_FromSpec (and typeslots.h) will need updating once we agree on a slot structure (with my recommendation being define C level slots for all of the new PEP 492 methods) * I found CO_COROUTINE/CO_NATIVE_COROUTINE confusing as a reader of the implementation, as they only told me how the objects were defined, rather than telling me why I should care. Based on what I gleaned of their intended purpose from reading the implementation, I suggest switching this to instead use CO_COROUTINE (set for all coroutines, regardless of how they were defined) and CO_ITERABLE_COROUTINE (set only for those coroutines that also support iteration), and adjusting the naming of other APIs accordingly. I agree that CO_COROUTINE is something that we should use for 'async def' functions (instead of CO_NATIVE_COROUTINE). However, CO_ITERABLE_COROUTINE sounds a bit odd to me, as generator-based coroutines (at least in asyncio) aren't supposed to be iterated over. How about CO_GENBASED_COROUTINE flag? * I found the names of the WITH_CLEANUP_ENTER and WITH_CLEANUP_EXIT bytecodes misleading, as they don't refer to the corresponding context management phases - they're both related to the exit phase. WITH_CLEANUP_START and WITH_CLEANUP_FINISH should be clearer for readers (both of the implementation and of the disassembled bytecode). Big +1. Your names are much better. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24017 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24160] Pdb sometimes crashes when trying to remove a breakpoint defined in a different debugger sessoon
New submission from ppperry: import pdb, test3 pdb.run(reload(test3)) string(1)module() (Pdb) s --Call-- c:\documents and settings\perry\desktop\coding_projects\python\test3.py(1)module() - foo = 7789 (Pdb) b 2 Breakpoint 1 at c:\documents and settings\perry\desktop\coding_projects\python\test3.py:2 (Pdb) c c:\documents and settings\perry\desktop\coding_projects\python\test3.py(2)module() - bar = 7788 (Pdb) c pdb.run(reload(test3)) string(1)module() (Pdb) s --Call-- c:\documents and settings\perry\desktop\coding_projects\python\test3.py(1)module() - foo = 7789 (Pdb) b 1 Breakpoint 2 at c:\documents and settings\perry\desktop\coding_projects\python\test3.py:1 (Pdb) cl 1 Traceback (most recent call last): File pyshell#592, line 1, in module pdb.run(reload(test3)) File C:\Python27\lib\pdb.py, line 1238, in run Pdb().run(statement, globals, locals) File C:\Python27\lib\bdb.py, line 400, in run exec cmd in globals, locals File string, line 1, in module File test3.py, line 1, in module foo = 7789 File C:\Python27\lib\bdb.py, line 51, in trace_dispatch return self.dispatch_call(frame, arg) File C:\Python27\lib\bdb.py, line 80, in dispatch_call self.user_call(frame, arg) File C:\Python27\lib\pdb.py, line 148, in user_call self.interaction(frame, None) File C:\Python27\lib\pdb.py, line 210, in interaction self.cmdloop() File C:\Python27\lib\cmd.py, line 142, in cmdloop stop = self.onecmd(line) File C:\Python27\lib\pdb.py, line 279, in onecmd return cmd.Cmd.onecmd(self, line) File C:\Python27\lib\cmd.py, line 221, in onecmd return func(arg) File C:\Python27\lib\pdb.py, line 622, in do_clear err = self.clear_bpbynumber(i) File C:\Python27\lib\bdb.py, line 297, in clear_bpbynumber self._prune_breaks(bp.file, bp.line) File C:\Python27\lib\bdb.py, line 268, in _prune_breaks self.breaks[filename].remove(lineno) ValueError: list.remove(x): x not in list Running the same code without first defining a breakpoint (in the second debugger instance) raises KeyError: [path to test3.py] on the same lien The contents of test3.py are irrelevant, as long as it is at least two lines long and syntactically correct. -- components: Library (Lib) messages: 242861 nosy: georg.brandl, ppperry priority: normal severity: normal status: open title: Pdb sometimes crashes when trying to remove a breakpoint defined in a different debugger sessoon type: behavior versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24160 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24158] Error of the hint of upgrading pip
New submission from Codetrainee: When first running pip built in python 3.4.3 on windows, it will notify you that you should upgrade to 6.1.1 The recommended command is 'pip install --upgrade pip' However, if you run this command, it will uninstall pip as well as fail to upgrade pip. On the official site of pip, it gives the command on windows - 'python -m pip install -U pip', which runs perfectly. -- components: Installation messages: 242857 nosy: codetrainee priority: normal severity: normal status: open title: Error of the hint of upgrading pip type: crash versions: Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24158 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24158] Error of the hint of upgrading pip
Changes by Alex Gaynor alex.gay...@gmail.com: -- nosy: +dstufft, ncoghlan ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24158 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17620] Python interactive console doesn't use sys.stdin for input
Changes by Paul Moore p.f.mo...@gmail.com: -- nosy: +paul.moore ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17620 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19873] There is a duplicate function in Lib/test/test_pathlib.py
Mark Lawrence added the comment: Can we have a formal commit review please as Jessica's comment in msg212966 that the patch looked good was over one year ago. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19873 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24159] Misleading TypeError when pickling bytes to a file opened as text
New submission from Jason R. Coombs:
I had a piece of code which I distilled to this:
import pickle
with open('out.pickle', 'w') as out:
pickle.dump(out, b'data')
Running that code raises this error:
TypeError: must be str, not bytes
The error is raised at the dump call with no additional context. Based on the
error, my reaction is to think that pickled doesn't support bytes objects in
pickles.
On further examination, it's not actually that the bytes cannot be pickled, but
that the 'dump' call requires that the file be opened in binary mode ('wb'),
but because of the error message essentially says expecting a text string and
because it's unclear that the error is raised during the write to the stream
and because the JSON library expects an output stream to be opened in text
mode, the error message is misleading.
At least [two other people think the behavior could be
clearer](http://stackoverflow.com/questions/13906623/using-pickle-dump-typeerror-must-be-str-not-bytes#comment43761528_13906715).
Would it be possible and reasonable to trap a TypeError at the call to `.write`
and replace or augment the message with something like file must be opened in
binary mode?
On second thought, perhaps the culprit isn't pickle here, but the stream
writer. Perhaps the `.write` method should provide a clearer message indicating
the context at which it's expecting str and not bytes.
--
components: IO
messages: 242858
nosy: jason.coombs
priority: low
severity: normal
status: open
title: Misleading TypeError when pickling bytes to a file opened as text
type: behavior
versions: Python 3.5
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24159
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22906] PEP 479: Change StopIteration handling inside generators
Roundup Robot added the comment: New changeset 787cc3d1d3af by Yury Selivanov in branch 'default': Issue #22906: Do incref before SetCause/SetContext https://hg.python.org/cpython/rev/787cc3d1d3af -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22906 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
