[issue8931] '#' has no affect with 'c' type
Torsten Landschoff added the comment: Attached patch makes Python throw an exception in the case above. It also adds a test case for that case. -- keywords: +patch nosy: +torsten Added file: http://bugs.python.org/file23904/issue_8931.diff ___ Python tracker <http://bugs.python.org/issue8931> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11822] Improve disassembly to show embedded code objects
Torsten Landschoff added the comment:
I offer the attached patch as a starting point to fulfill this feature request.
The patch changes the output to insert the disassembly of local code objects on
the referencing line.
As that made the output unreadable to me, I added indentation for the nested
code (by 4 spaces, hoping that nobody will nest code 10 levels deep :-)
This results in the following output for the original example:
>>> from dis import dis
>>> dis('[x**2 for x in range(3)]')
1 0 LOAD_CONST 0 ( at
0x7f24a67dde40, file "", line 1>)
1 0 BUILD_LIST 0
3 LOAD_FAST0 (.0)
>>6 FOR_ITER16 (to 25)
9 STORE_FAST 1 (x)
12 LOAD_FAST1 (x)
15 LOAD_CONST 0 (2)
18 BINARY_POWER
19 LIST_APPEND 2
22 JUMP_ABSOLUTE6
>> 25 RETURN_VALUE
3 LOAD_CONST 1 ('')
6 MAKE_FUNCTION0
9 LOAD_NAME0 (range)
12 LOAD_CONST 2 (3)
15 CALL_FUNCTION1
18 GET_ITER
19 CALL_FUNCTION1
22 RETURN_VALUE
--
keywords: +patch
nosy: +torsten
Added file: http://bugs.python.org/file23908/issue11822.diff
___
Python tracker
<http://bugs.python.org/issue11822>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12306] zlib: Expose zlibVersion to query runtime version of zlib
New submission from Torsten Landschoff : I am currently fighting a curious problem in using zlib from Python: Decompression completes but sometimes the resulting output does not match a sha224 hash of the expected output. I deployed a zlib 1.2.5 with our PyInstaller output but the problem persists. I would like to check that the program is actually using the right zlib version. zlib provides the function zlibVersion to access the actual run time version. The attached patch exposes this function from the zlib module. I also added a unit test to check that the function is there and the output matches ZLIB_VERSION (which should match on the build machine). -- components: Library (Lib) files: zlibversion.diff keywords: patch messages: 138044 nosy: torsten priority: normal severity: normal status: open title: zlib: Expose zlibVersion to query runtime version of zlib type: feature request versions: Python 2.7, Python 3.2, Python 3.3 Added file: http://bugs.python.org/file22307/zlibversion.diff ___ Python tracker <http://bugs.python.org/issue12306> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12306] zlib: Expose zlibVersion to query runtime version of zlib
Changes by Torsten Landschoff : Added file: http://bugs.python.org/file22308/zlibversion_py3.diff ___ Python tracker <http://bugs.python.org/issue12306> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12306] zlib: Expose zlibVersion to query runtime version of zlib
Torsten Landschoff added the comment: Here is an updated patch: * Function zlibVersion() replaced by module-level constant ZLIB_RUNTIME_VERSION * Added documentation (with versionadded: 3.3) -- Added file: http://bugs.python.org/file22343/zlib_runtime_version.diff ___ Python tracker <http://bugs.python.org/issue12306> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12306] zlib: Expose zlibVersion to query runtime version of zlib
Torsten Landschoff added the comment: Documentation for ZLIB_VERSION. I just notice that it makes no sense to add the version info to that section. Feel free to move the two snippets. I added a versionadded tag here as well (ZLIB_VERSION was already in Python 1.5). Is there any old release for that versionadded tags should be removed? -- Added file: http://bugs.python.org/file22344/zlib_version_doc.diff ___ Python tracker <http://bugs.python.org/issue12306> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11797] 2to3 does not correct "reload"
Torsten Landschoff added the comment: The other use case I see is to reload a module during debugging after changing the code. This is especially useful for big GUI applications. -- nosy: +torsten ___ Python tracker <http://bugs.python.org/issue11797> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12353] argparse cannot handle empty arguments
Torsten Landschoff added the comment: Here is an updated patch including unit test coverage. -- keywords: +patch nosy: +torsten Added file: http://bugs.python.org/file22430/issue12353_test.diff ___ Python tracker <http://bugs.python.org/issue12353> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12353] argparse cannot handle empty arguments
Torsten Landschoff added the comment: > Your unit test isn't consistent with the other unit tests in that set, which > makes me suspicious that it isn't testing what we need to test. That is because I did not try to understand the machinery behind the argparse unit tests completely. I did not want to create an extra unit test class just for this one test. > Also, there are unit tests for this case further up in the test file > (TestEmptyAndSpaceContainingArguments). I haven't been able to reproduce the > bug. Did you run the unit tests from my patch? > Can you post a short program that reproduces the failure? Here you go: from argparse import ArgumentParser parser = ArgumentParser(fromfile_prefix_chars="@") parser.parse_args([""]) This gives me Traceback (most recent call last): File "", line 1, in File "/opt/python3/lib/python3.3/argparse.py", line 1726, in parse_args args, argv = self.parse_known_args(args, namespace) File "/opt/python3/lib/python3.3/argparse.py", line 1758, in parse_known_args namespace, args = self._parse_known_args(args, namespace) File "/opt/python3/lib/python3.3/argparse.py", line 1770, in _parse_known_args arg_strings = self._read_args_from_files(arg_strings) File "/opt/python3/lib/python3.3/argparse.py", line 2003, in _read_args_from_files if arg_string[0] not in self.fromfile_prefix_chars: IndexError: string index out of range -- ___ Python tracker <http://bugs.python.org/issue12353> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12353] argparse cannot handle empty arguments
Torsten Landschoff added the comment: Here is another possible patch that will catch the problem. But this enables the fromfile_prefix_chars option for all tests checking empty and space arguments. This way a problem that occurs only without that option might be hidden. We would need to run those tests with and without fromfile_prefix_chars. -- Added file: http://bugs.python.org/file22433/modify_test_empty.diff ___ Python tracker <http://bugs.python.org/issue12353> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12353] argparse cannot handle empty arguments
Torsten Landschoff added the comment: ping!? I think this should be either applied or dropped. It does not make sense to have such a simple issue rot in the bug tracker... -- ___ Python tracker <http://bugs.python.org/issue12353> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8994] pydoc does not support non-ascii docstrings
Torsten Landschoff added the comment: You are right, this is a duplicate of #6625. And in fact I should have known since I commented on that bug... -- status: open -> closed ___ Python tracker <http://bugs.python.org/issue8994> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8488] Docstrings of non-data descriptors "ignored"
Torsten Landschoff added the comment: FYI, this still applies to r86094 of py3k. -- ___ Python tracker <http://bugs.python.org/issue8488> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue850728] Semaphore.acquire() timeout parameter
Torsten Landschoff added the comment: Thanks for applying! -- ___ Python tracker <http://bugs.python.org/issue850728> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11406] There is no os.listdir() equivalent returning generator instead of list
Torsten Landschoff added the comment: I would regard this as Type: resource usage, instead of performance. Given enough RAM, loading the whole directory at once will likely be faster. The downsides of os.listdir: a) You can't get a peek at the files so far, it's all or nothing. I only wanted to know if a directory is empty and I have to read the whole thing just to throw it away (maybe I missed another library function?) b) Using it in a GUI basically requires you to use threads if you may run into a dir with many files. Especially on a slow filesystem (network). Because you won't regain control until the whole thing is read. I would like to have an iterator version as well, but I also dislike another function (especially the "x" prefix). How about adding a keyword argument to select iterator behaviour? -- nosy: +torsten ___ Python tracker <http://bugs.python.org/issue11406> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11688] SQLite trace callback
New submission from Torsten Landschoff : I'd like to access the SQLite trace callback from Python to actually see the same queries that SQLite actually gets to see. The C API of SQLite supports this via the sqlite3_trace function. I added support to this to the sqlite3 module plus unit tests testing that it is called, can be removed again and that unicode arguments arrive correctly at the callback. Please consider applying the patch. I am not sure if this should go to the pysqlite project on Google Code directly, I am just submitting it here because I worked in the python source tree as I am more used to its build system. I am sorry, Gerhard, if this is the wrong way. -- components: Library (Lib) files: sqlite_trace_py3.diff keywords: patch messages: 132275 nosy: torsten priority: normal severity: normal status: open title: SQLite trace callback type: feature request versions: Python 2.7, Python 3.3 Added file: http://bugs.python.org/file21413/sqlite_trace_py3.diff ___ Python tracker <http://bugs.python.org/issue11688> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11688] SQLite trace callback
Torsten Landschoff added the comment: Here is the same change for Python 2.7. I don't expect this to get merged on the Python 2 branch, put perhaps it is useful to somebody. -- Added file: http://bugs.python.org/file21414/sqlite_trace_py27.diff ___ Python tracker <http://bugs.python.org/issue11688> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11689] sqlite: Incorrect unit test fails to detect failure
New submission from Torsten Landschoff : The CheckClearHandler test in Lib/sqlite3/test/hooks.py is invalid. It sets a local variable in a callback where it wants to change the variable in the closure. Patch attached. -- components: Tests files: test_clear_handler_py3.diff keywords: patch messages: 132278 nosy: torsten priority: normal severity: normal status: open title: sqlite: Incorrect unit test fails to detect failure versions: Python 2.7, Python 3.3 Added file: http://bugs.python.org/file21415/test_clear_handler_py3.diff ___ Python tracker <http://bugs.python.org/issue11689> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11689] sqlite: Incorrect unit test fails to detect failure
Changes by Torsten Landschoff : Added file: http://bugs.python.org/file21416/test_clear_handler_py27.diff ___ Python tracker <http://bugs.python.org/issue11689> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10740] sqlite3 module should allow DDL statements in transactions
Torsten Landschoff added the comment: The attached patch is my take on this issue. I ran into the problem that during schema upgrades dropping a table was not rolled back. In another instance, renaming a table was not rolled back. This greatly increases the risk of data loss for our application. Because I do not currently foresee which commands might need dropping out of a transaction and because of backwards compatibility woes, I added a new field to the sqlite3.Connection: operation_needs_transaction_callback This function is called to decide if a running transaction should be implicitly committed (I'd consider this dangerous), if a transaction has to be started if not running (should normally always hold) or if the transaction state should be left alone. For example, the "pragma foreign_keys = ..." is a no-op inside a transaction, therefore an implicit begin would be possibly harmful. In our application, we enable foreign keys when getting the connection out of the SQLAlchemy pool via a pool listener, which would be disabled if there is an implicit begin triggered. The patch also adds a bunch of unit tests to cover the new behaviour. -- nosy: +torsten Added file: http://bugs.python.org/file21417/sqlite_transaction_config_py27.diff ___ Python tracker <http://bugs.python.org/issue10740> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10740] sqlite3 module should allow DDL statements in transactions
Torsten Landschoff added the comment: Same patch for Python 3. In fact, this also adds a missing Py_XDECREF. -- Added file: http://bugs.python.org/file21418/sqlite_transaction_config_py3.diff ___ Python tracker <http://bugs.python.org/issue10740> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10740] sqlite3 module should allow DDL statements in transactions
Changes by Torsten Landschoff : Added file: http://bugs.python.org/file21419/sqlite_transaction_config_py27.diff ___ Python tracker <http://bugs.python.org/issue10740> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11688] SQLite trace callback
Torsten Landschoff added the comment:
> A couple of comments:
> - this is a new feature, so can only go in in 3.x: no need to post a 2.7
> patch (unless this helps Gerhard for his standalone project)
The motivation for the 2.7er patch is mostly that we are still using Python 2.x
at work and I made this patch for 2.7 first. Actually I will need to backport
it to 2.6 but I guess there are no differences. And maybe I should have
submitted this against pysqlite directly which is (AFAICT) also still
targetting 2.x.
> - you need to document the new API in Doc/library/sqlite3.rst
Sure. I was just filing the report to have the code on file and this was only
fallout from another patch. I will create an updated patch including
documentation about the feature.
> About the patch: looks mostly good!
Thanks.
> +self.assertTrue([x for x in traced_statements if x.find("create
> table foo") != -1])
>
> This looks a bit complicated, why not something like
> `any("create table foo" in x for x in traced_statements)`?
Fine with me. I did not know that "bar" in "foobarbaz" works (I was expecting
it to act as if the right hand string is a list of characters). Obviously I was
wrong. Further I thought "any" was new in 2.6 and therefore not suitable for
use in pysqlite which was also wrong.
> (`y in x` is simper and more readable than `x.find(y) != -1`)
I agree, I just did not know it works for substrings.
> +sqlite3_trace(self->db, _trace_callback, trace_callback);
> +if (PyDict_SetItem(self->function_pinboard, trace_callback, Py_None)
> == -1)
> +return NULL;
>
> Shouldn't sqlite3_trace() be called only after PyDict_SetItem() succeeds?
Good catch. If SetItem fails, trace_callback may become invalid and the
_trace_callback will crash. I did not think about that as I only derived that
function from similar code in the module. I will have to fix this as well.
--
___
Python tracker
<http://bugs.python.org/issue11688>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10740] sqlite3 module should allow DDL statements in transactions
Torsten Landschoff added the comment: > Torsten basically you are suggesting that PRAGMA would never work at all with > my 'do not strcmp() the sql at all, always begin a transaction' approach? No. Most pragmas should still work and getting the current setting of a pragma should also work. I was only referring to http://www.sqlite.org/pragma.html#pragma_foreign_keys Quote: > This pragma is a no-op within a transaction; foreign key constraint > enforcement may only be enabled or disabled when there is no pending BEGIN or > SAVEPOINT. I did not see such a restriction for other pragmas though I admit that I did not reread the list in full. -- ___ Python tracker <http://bugs.python.org/issue10740> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11688] SQLite trace callback
Torsten Landschoff added the comment:
> - you need to document the new API in Doc/library/sqlite3.rst
Included in the updated patch.
> +self.assertTrue([x for x in traced_statements if x.find("create
> table foo") != -1])
>
> This looks a bit complicated, why not something like
> `any("create table foo" in x for x in traced_statements)`?
Fixed.
> +sqlite3_trace(self->db, _trace_callback, trace_callback);
> +if (PyDict_SetItem(self->function_pinboard, trace_callback, Py_None)
> == -1)
> +return NULL;
>
> Shouldn't sqlite3_trace() be called only after PyDict_SetItem() succeeds?
Fixed as well. I just reversed the calls. What I dislike about this function
pinboard approach is that every function registered as a callback stays pinned
to the SQLite connection for the lifetime of the latter. But that belongs into
another patch, I guess.
--
Added file: http://bugs.python.org/file21468/sqlite_trace.diff
___
Python tracker
<http://bugs.python.org/issue11688>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11688] SQLite trace callback
Torsten Landschoff added the comment: > The patch looks good to me, thank you! > Gerhard, would you like to tackle this? Otherwise I'll commit in a couple of > days. What I am still wondering about is if it would make sense to use the text factory here. It might make sense to pass through the bytes directly without translation into unicode (especially for big amounts). OTOH, this is mostly a debugging aid and nothing that would be enabled in production. And premature optimization is the root of all evil... -- ___ Python tracker <http://bugs.python.org/issue11688> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10740] sqlite3 module should allow DDL statements in transactions
Torsten Landschoff added the comment: The attached patch is an updated version which adds a bit of documentation. -- Added file: http://bugs.python.org/file21479/sqlite_transaction_config_v2.diff ___ Python tracker <http://bugs.python.org/issue10740> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10740] sqlite3 module should allow DDL statements in transactions
Torsten Landschoff added the comment: I updated the patch for upstream pysqlite2. Available at http://code.google.com/p/pysqlite/issues/detail?id=24 Patch over there is for Python 2 (tested with our production Python 2.6). -- ___ Python tracker <http://bugs.python.org/issue10740> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10804] Copy and paste error in _json.c
New submission from Torsten Landschoff : There is a copy and paste error in _json.c: The pairs_hook field is assigned but object_hook is verified to be non-null. The same field is verified a few lines back to this is superfluous at least. -- components: Library (Lib) files: patch messages: 125044 nosy: torsten priority: normal severity: normal status: open title: Copy and paste error in _json.c versions: Python 2.7 Added file: http://bugs.python.org/file20219/patch ___ Python tracker <http://bugs.python.org/issue10804> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10804] Copy and paste error in _json.c
Torsten Landschoff added the comment: FYI, this bug is not in Python 3.3 (as of svn r87615). -- ___ Python tracker <http://bugs.python.org/issue10804> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10886] Unhelpful backtrace for multiprocessing.Queue
New submission from Torsten Landschoff : When trying to send an object via a Queue that can't be pickled, one gets a quite unhelpful traceback: Traceback (most recent call last): File "/usr/lib/python2.6/multiprocessing/queues.py", line 242, in _feed send(obj) PicklingError: Can't pickle : attribute lookup __builtin__.module failed I have no idea where I am sending this. It would be helpful to get the call trace to the call to Queue.put. My workaround was to create a Queue via this function MyQueue: def MyQueue(): import cPickle def myput(obj, *args, **kwargs): cPickle.dumps(obj) return orig_put(obj, *args, **kwargs) q = Queue() orig_put, q.put = q.put, myput return q That way I get the pickle exception in the caller to put and was able to find out the offending code. -- components: Library (Lib) messages: 125996 nosy: torsten priority: normal severity: normal status: open title: Unhelpful backtrace for multiprocessing.Queue type: feature request versions: Python 2.6 ___ Python tracker <http://bugs.python.org/issue10886> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8299] Improve GIL in 2.7
Torsten Landschoff added the comment: Silly question, I know, but why isn't the GIL just implemented as a lock of the host operating system? After all, we want mutual exclusion, I don't see why condition variables are required for this. I have to admin that I did not look at the source, so the reason might be documented there. -- nosy: +torsten ___ Python tracker <http://bugs.python.org/issue8299> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8389] Incomprehensibly import error
New submission from Torsten Landschoff : I ran into an ImportError I was unable to explain: $ python -c "import a.b" Traceback (most recent call last): File "", line 1, in File "a/b/__init__.py", line 1, in import a.b.c File "a/b/c.py", line 2, in import a.b.t as t AttributeError: 'module' object has no attribute 'b' This is the source code: $ tail `find -name \*.py` ==> ./demo.py <== import a.b ==> ./a/__init__.py <== ==> ./a/b/c.py <== # Does not work: import a.b.t as t # Works: # import a.b # from a.b import t ==> ./a/b/t.py <== ==> ./a/b/__init__.py <== import a.b.c # Works: # import a.b.t Replacing any import with one of the versions annotated as working fixes it. Stripping another level from the package tree fixes it as well. Why!? -- components: Interpreter Core files: import_error.tar.gz messages: 103091 nosy: torsten severity: normal status: open title: Incomprehensibly import error versions: Python 2.6 Added file: http://bugs.python.org/file16915/import_error.tar.gz ___ Python tracker <http://bugs.python.org/issue8389> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8389] Incomprehensibly import error
Torsten Landschoff added the comment: Err, typo, in c.py I meant to write # Does not work: import a.b.t as t # Works: # import a.b.t So without renaming it it works. -- ___ Python tracker <http://bugs.python.org/issue8389> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7316] Add a timeout functionality to common locking operations
Torsten Landschoff added the comment: While you are at it, you might want to submit the patch from http://bugs.python.org/issue850728 as well. It adds timeouts for semaphores. :) -- ___ Python tracker <http://bugs.python.org/issue7316> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8488] Docstrings of non-data descriptors "ignored"
New submission from Torsten Landschoff : [I would assign priority minor to this, but the tracker won't let me] I really like the online documentation features of python. However, I wonder about the output of the following simple example: class Descriptor(object): """Doc of a non-data descriptor.""" def __get__(self, instance, owner): return 42 if instance else self class GetSetDescriptor(Descriptor): """Doc of a data-descriptor.""" def __set__(self, instance, value): pass class Demo(object): non_data = Descriptor() data = GetSetDescriptor() help(Demo) This results in Help on class Demo in module __main__: class Demo(builtins.object) | Methods defined here: | | non_data = <__main__.Descriptor object> | -- | Data descriptors defined here: | | __dict__ | dictionary for instance variables (if defined) | | __weakref__ | list of weak references to the object (if defined) | | data | Doc of a data-descriptor. I think the behaviour of pydoc wrt. the non_data descriptor is a bit out of line. I would have expected to find the docstring in the output here. -- components: Library (Lib) files: doc.py messages: 103880 nosy: torsten severity: normal status: open title: Docstrings of non-data descriptors "ignored" type: behavior versions: Python 2.5, Python 2.6, Python 3.1, Python 3.2 Added file: http://bugs.python.org/file17027/doc.py ___ Python tracker <http://bugs.python.org/issue8488> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36780] Interpreter exit blocks waiting for futures of shut-down ThreadPoolExecutors
Torsten Landschoff added the comment: I intended to file a bug because of the shutdown problem but found out there is this ticket already. In our application we sometimes run into this problem that you can't exit because of a hanging TCP connection used inside a ThreadPoolExecutor task. executor.shutdown(wait=False) does not help - the process still hangs. Another problem was inside our tests were a bug caused a hanging task inside a thread pool executor and the test runner (pytest) would not terminate because of this. I actually went so far to drop the thread reference inside the concurrent.futures.thread module. :-( A documented way to drop a hanging executor thread would be very much appreciated. -- nosy: +torsten ___ Python tracker <https://bugs.python.org/issue36780> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13020] structseq.c: refleak
Torsten Landschoff added the comment: +1 for the patch. All the error paths above the change do Py_DECREF(arg); return NULL; arg is initialized with PySequence_Fast, which returns a new reference. Hard to create a test case for this... -- nosy: +torsten ___ Python tracker <http://bugs.python.org/issue13020> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13833] No documentation for PyStructSequence
New submission from Torsten Landschoff : While writing a C extension I wanted to create a namedtuple like object as os.statvfs and friends do. I was unable to find a simple way to do this from C and was wondering how the posixmodule does it. It turned out that there is a PyStructSequence type for this. It would be nice to have it documented. First draft for the documentation update attached. -- assignee: docs@python components: Documentation files: structseq_doc.diff keywords: patch messages: 151657 nosy: docs@python, torsten priority: normal severity: normal status: open title: No documentation for PyStructSequence type: enhancement versions: Python 3.3 Added file: http://bugs.python.org/file24280/structseq_doc.diff ___ Python tracker <http://bugs.python.org/issue13833> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13873] SIGBUS in test_zlib on Debian bigmem buildbot
Torsten Landschoff added the comment: I tried to reproduce this crash on my desktop system. AMD64, 8 GB RAM (only) and on Debian unstable from today. Testing the exact same Python version (hg update d2cf8a34ddf90fb1bc8938de0f736694e61f73fa) the test passes just fine here... -- nosy: +torsten ___ Python tracker <http://bugs.python.org/issue13873> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13601] sys.stderr should be line-buffered when stderr is not a TTY
Torsten Landschoff added the comment: > Looking at > http://pubs.opengroup.org/onlinepubs/9699919799/functions/stdin.html (which > also covers stdout and stderr), it specifically says about stderr: "When > opened, the standard error stream is not fully buffered;". I was of the impression that this is defined in ISO C already. Unfortunately, I only have ISO C 99 at hand, but this clearly states in section 7.19.3 (Files), enumeration item 7: > As initially opened, the standard error stream is not fully buffered; > the standard input and standard output streams are fully buffered if and > only if the stream can be determined not to refer to an interactive device. I am quite sure this is just as as it was in the original ANSI C standard. -- nosy: +torsten ___ Python tracker <https://bugs.python.org/issue13601> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27035] Cannot set exit code in atexit callback
Torsten Landschoff added the comment: As this bug report clearly states this worked as documented in Python 2.7 and stopped working sometime in the Python 3 series. I just ran into this while porting some code to Python 3 which uses an atexit handler to wind down some resources on process exit. This sometimes gets stuck and instead of hanging indefinitely the cleanup is aborted if it takes longer than a few seconds. As this is actually an error, the registered exit function raises SystemExit to modify the exit code in this case. This used to work fine but does not anymore... Observe: ## Python 2.7 works fine $ sudo docker run python:2.7 python -c "import atexit,sys;atexit.register(sys.exit,124)"; echo $? 124 ## Python 3.2 (oldest Python 3 on docker hub) swallows the exit code (but prints it) $ sudo docker run python:3.2 python -c "import atexit,sys;atexit.register(sys.exit,124)"; echo $? Error in atexit._run_exitfuncs: SystemExit: 124 0 ## Same for 3.3 up to 3.6 $ sudo docker run python:3.3 python -c "import atexit,sys;atexit.register(sys.exit,124)"; echo $? Error in atexit._run_exitfuncs: SystemExit: 124 0 $ sudo docker run python:3.5 python -c "import atexit,sys;atexit.register(sys.exit,124)"; echo $? Error in atexit._run_exitfuncs: SystemExit: 124 0 $ sudo docker run python:3.6 python -c "import atexit,sys;atexit.register(sys.exit,124)"; echo $? Error in atexit._run_exitfuncs: SystemExit: 124 0 ## Python 3.7 swallows the exit code *and does not even print it*: $ /opt/python-dev/bin/python3.7 -c "import atexit,sys;atexit.register(sys.exit,124)"; echo $? 0 -- nosy: +torsten type: enhancement -> behavior ___ Python tracker <https://bugs.python.org/issue27035> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14965] super() and property inheritance behavior
Torsten Landschoff added the comment: I stumbled across this omission as well in 2010 and brought this up on python-dev: http://mail.python.org/pipermail/python-dev/2010-April/099672.html There were no replies, but perhaps my post adds a bit of information and also there is another patch linked from there. I attached my patch from 2010 for reference. -- nosy: +torsten Added file: http://bugs.python.org/file26966/44560_44559.diff ___ Python tracker <http://bugs.python.org/issue14965> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21505] cx_freeze multiprocessing bug
Torsten Landschoff added the comment: That sounds like you did not initialize the freeze support of the multiprocessing module: https://docs.python.org/3/library/multiprocessing.html#multiprocessing.freeze_support Basically, you need to add the following code to your main, before anything else: from multiprocessing import freeze_support freeze_support() Interestingly, the documentation states that starting a new Process instance without freeze_support will raise a RuntimeError. Maybe the detection of that situation failed in your case? -- nosy: +torsten ___ Python tracker <http://bugs.python.org/issue21505> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10740] sqlite3 module breaks transactions and potentially corrupts data
Torsten Landschoff added the comment:
Hi all,
let me warn you first: I have put a lot a effort in writing the patch back
then. I moved on since as I don't even know when the improvement will make any
difference for me. As so often, trying to contribute to an open source project
turned out to be a waste of time, for the following reasons:
1. the patch first has to made it past review before being committed
2. it will be released with some distant version (looking from 2011)
3. I couldn't just replace Python with a new version for our builds (even if it
was released within a month)
In the end I had to work around the problem in client code. If anybody cares,
the solution was to special case SQLite as a database backend and do
transactions manually. As we now have to support Oracle as well, we don't have
the luxury of transactions with DDL anyhow so basically we drop out of DBAPI2
transaction management and everything becomes easy again.
I should have replied earlier to the questions. Maybe by answering I stand a
chance that I will ever use sqlite3 in Python 3 again.
Quoting Aymeric Augustin (aymeric.augustin):
> That patch solves the problem, at the cost of introducing an unwieldy API,
> "operation_needs_transaction_callback".
You are right, I had forgotten that each client would need to know about it. In
fact, the value used in the tests etc. should probably be the default.
The idea was to not take away from what's there already: The sqlite3 module
already has a feature to inspect a command and begin or commit automatically.
Just stripping that away *removes* a feature that has been available for a long
time. I'd rather give the
client more control instead of less and let him fine tune this behaviour.
Also, there was good reason for this special casing of SQLite: Adhering to
DBAPI2 would really kill concurrent access to SQLite: After reading something
from the database, any other thread is blocked from writing to the database.
In our case (we are using SQLAlchemy), the effect is that any attribute access
to an ORM mapped object must be "secured" by rolling back after reading (in
case you were only reading). Let me try to illustrate in an example:
Previous code:
modification_time = component.modification_time
If the modification time is not loaded, this will query it from the database in
the bowls of SQLAlchemy. Now the database is locked, if it weren't for the
"smart" transaction management of the sqlite3 module.
Quoting the new patch to the documentation:
> Standard mode: In this mode, the :mod:`sqlite3` module opens a transaction
> implicitly before any statement, unless a transaction is already active. This
> adheres more closely to PEP 249 semantics, possibly at the cost of
> performance under concurrent workloads.
The cost of performance for our workload here is called deadlock. To fix this
in user code, the example code above needs fixing like this:
modification_time = component.modification_time
# Unlock SQLite if this came from the database (and we are using SQLite)
session = get_orm_session(component)
if session and session.bind.dialect.name == 'sqlite':
session.rollback()
But this is obviously absolutely wrong if any changes have been made before
reading. So the attribute access becomes something like:
session = get_orm_session(component)
do_rollback = session and not (session.new or session.updated or
session.deleted)
modification_time = component.modification_time
# Unlock SQLite if this came from the database (and we are using SQLite)
if do_rollback and session.bind.dialect.name == 'sqlite':
session.rollback()
When done right this is not a big deal though - we roll back our database
connection in the idle event of our GUI main loop to make sure background
processing is not hanging indefinately. But not all code may be so lucky.
When starting with Python I always thought that code like this is harmles:
>>> conn = sqlite3.connect("test.db")
>>> data = list(conn.execute("select * from mytable"))
Currently it is, but only because sqlite3 module parses the select as DQL and
does not lock the database.
Long story short: The unwieldly operation_needs_transaction_callback gives you
full control about this feature of the module that is a misfeature nowadays
because it relies on flawed assumptions.
Quoting Aymeric Augustin (aymeric.augustin) again:
> I'm very skeptical of the other API, "in_transaction". Other database
> backends usually provide an "autocommit" attribute.
Interesting. I've never seen such an attribute. It is there without me ever
noticing:
http://cx-oracle.readthedocs.org/en/latest/connection.html?highlight=autocommit#Connection.autocommit
http://initd.org/psycopg/docs/connection.html
[issue1336] subprocess.Popen hangs when child writes to stderr
Torsten Landschoff added the comment: > ita1024: please don't post to closed issues; your message here will be > ignored. Bugs for Python 2 will be ignored anyway so what can you do? I am currently fighting with the effects of using threads, subprocess.Popen and sqlite in Python2 and found this bug report. Among other issues (like a hang for still unknown reasons when calling subprocess.Popen) I have also seen gc getting disabled for a long running process which has multiple threads and starts processes via subprocess.Popen from different threads. The attached example subprocess_demo.py reproduces disabling GC for me in Python 2.7.6. I checked with Python 3.4 and it is fixed there. Looking at the source, Python 3 implements subprocess.Popen correctly by doing fork + execve at the C side, unless the caller really wants to run a preexec_fn and is prepared for the failure. Another case for using Python 3... -- nosy: +torsten Added file: http://bugs.python.org/file35668/subprocess_demo.py ___ Python tracker <http://bugs.python.org/issue1336> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16379] SQLite error code not exposed to python
New submission from Torsten Landschoff:
The sqlite3 module does not expose the sqlite3 error codes to python. This
makes it impossible to detect specific error conditions directly.
Case in point: If a user selects some random file as the database in our
application, we can not detect that it is not a valid database file:
$ /opt/python3/bin/python3
Python 3.4.0a0 (default:2d6eec5d01f7, Nov 1 2012, 10:47:27)
[GCC 4.6.3] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import sqlite3
>>> conn = sqlite3.connect("/etc/passwd")
>>> from pprint import pprint
>>> try:
... conn.execute("select * from random_table")
... except Exception as e:
... pprint({name: getattr(e, name) for name in dir(e)})
... raise
...
{'__cause__': None,
'__class__': ,
'__context__': None,
'__delattr__': ,
'__dict__': {},
'__dir__': ,
'__doc__': None,
'__eq__': ,
'__format__': ,
'__ge__': ,
'__getattribute__': ,
'__gt__': ,
'__hash__': ,
'__init__': ,
'__le__': ,
'__lt__': ,
'__module__': 'sqlite3',
'__ne__': ,
'__new__': ,
'__reduce__': ,
'__reduce_ex__': ,
'__repr__': ,
'__setattr__': ,
'__setstate__': ,
'__sizeof__': ,
'__str__': ,
'__subclasshook__': ,
'__suppress_context__': False,
'__traceback__': ,
'__weakref__': None,
'args': ('file is encrypted or is not a database',),
'with_traceback': }
Traceback (most recent call last):
File "", line 2, in
sqlite3.DatabaseError: file is encrypted or is not a database
>>>
Currently, one can only match the error message, with is bad programming style.
The error code for this error is SQLITE_NOTADB, as found in the function
sqlite3ErrStr when searching for the message in SQLite's main.c at
http://www.sqlite.org/src/artifact/02255cf1da50956c5427c469abddb15bccc4ba09
Unfortunately, the sqlite3 module does not expose the error code itself
(neither the actual error code nor the defined error codes) in any way. Errors
are handled in Modules/_sqlite/util.c:
http://hg.python.org/cpython/file/2d6eec5d01f7/Modules/_sqlite/util.c#l99
I would like to have the defined error codes available in some mapping inside
the sqlite3 module as well as the actual error code inside every sqlite
exception e as e.sqlite_errcode
--
components: Library (Lib)
messages: 174395
nosy: torsten
priority: normal
severity: normal
status: open
title: SQLite error code not exposed to python
type: enhancement
versions: Python 3.4
___
Python tracker
<http://bugs.python.org/issue16379>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16921] Docs of subprocess.CREATE_NEW_CONSOLE are wrong
New submission from Torsten Landschoff: The documentation of CREATE_NEW_CONSOLE at http://docs.python.org/3/library/subprocess.html#subprocess.CREATE_NEW_CONSOLE states: This flag is always set when Popen is created with shell=True. This does not fit the code which does if (_subprocess.GetVersion() >= 0x8000 or os.path.basename(comspec).lower() == "command.com"): # Win9x, or using command.com on NT. We need to creationflags |= _subprocess.CREATE_NEW_CONSOLE So the statement is only true on very old versions on Windows. I suggest to fix the documentation (patch attached) or to remove that obsolete hack (and drop support for Windows <= NT). -- components: Windows files: create_new_console.diff keywords: patch messages: 179578 nosy: torsten priority: normal severity: normal status: open title: Docs of subprocess.CREATE_NEW_CONSOLE are wrong versions: Python 3.5 Added file: http://bugs.python.org/file28674/create_new_console.diff ___ Python tracker <http://bugs.python.org/issue16921> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10740] sqlite3 module breaks transactions and potentially corrupts data
Torsten Landschoff added the comment: Just a heads up that I am still interested in this issue. I started to write up my expectations to the sqlite module wrt. exception handling. It's not finished yet but I attached what I got so far. I hope everybody agrees that those doctests should all pass. -- Added file: http://bugs.python.org/file35780/sqlite_sanity_check.rst ___ Python tracker <http://bugs.python.org/issue10740> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20147] multiprocessing.Queue.get() raises queue.Empty exception if even if an item is available
Changes by Torsten Landschoff : Added file: http://bugs.python.org/file33328/queue_timeout_1.diff ___ Python tracker <http://bugs.python.org/issue20147> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20147] multiprocessing.Queue.get() raises queue.Empty exception if even if an item is available
New submission from Torsten Landschoff:
The behaviour of multiprocessing.Queue surprised me today in that Queue.get()
may raise an exception even if an item is immediately available. I tried to
flush entries without blocking by using the timeout=0 keyword argument:
$ /opt/python3/bin/python3
Python 3.4.0b1 (default:247f12fecf2b, Jan 6 2014, 14:50:23)
[GCC 4.6.3] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from multiprocessing import Queue
>>> q = Queue()
>>> q.put("hi")
>>> q.get(timeout=0)
Traceback (most recent call last):
File "", line 1, in
File "/opt/python3/lib/python3.4/multiprocessing/queues.py", line 107, in get
raise Empty
queue.Empty
Actually even passing a small non-zero timeout will not give me my queue entry:
>>> q.get(timeout=1e-6)
Traceback (most recent call last):
File "", line 1, in
File "/home/torsten/opensrc/cpython/Lib/multiprocessing/queues.py", line 107,
in get
raise Empty
queue.Empty
Expected behaviour for me would be to return the item that is in the queue. I
know that there is a kwarg *block* which gives me the desired behaviour:
>>> q.get(block=False)
'hi'
In my case the get call is embedded in my own module which does not currently
expose the block parameter. My local solution is of course to update the
wrapper:
if timeout == 0:
timeout = None
block = False
However I see a few smells here in the python standard library. First,
everything else seems to accept timeout=0 as nonblocking:
>>> import threading
>>> lock = threading.Lock()
>>> lock.acquire(timeout=0)
True
>>> from queue import Queue
>>> q = Queue()
>>> q.put("hi")
>>> q.get(timeout=0)
'hi'
Of special note is that queue.Queue behaves as I would have expected. IMHO it
should be consistent with multiprocessing.Queue.
Also note that queue.Queue.get() and queue.Queue.put() name their blocking flag
"block", while everybody else uses "blocking".
As a side note, I think the current approach is flawed in computing the
deadline. Basically it does the following:
deadline = time.time() + timeout
if not self._rlock.acquire(block, timeout):
raise Empty
timeout = deadline - time.time()
if timeout < 0 or not self._poll(timeout):
raise Empty
On my system, just taking the time twice and computing the delta takes 2
microseconds:
>>> import time
>>> t0 = time.time(); time.time() - t0
2.384185791015625e-06
Therefore calling Queue.get(block, timeout) with 0 < timeout < 2e-6 will never
return anything from the queue even though Queue.get(block=False) would do
that. This contradicts the idea that Queue.get(block=False) will return faster
than with block=True with any timeout > 0.
Apart from that, as Python does not currently support waiting on multiple
sources, we currently often check a queue with a small timeout concurrently
with doing other stuff. In case the system get really loaded, I would expect
this to cause problems because the updated timeout may fall below zero.
Suggested patch attached.
--
components: Library (Lib)
files: queue_timeout_0.diff
keywords: patch
messages: 207443
nosy: torsten
priority: normal
severity: normal
status: open
title: multiprocessing.Queue.get() raises queue.Empty exception if even if an
item is available
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file33327/queue_timeout_0.diff
___
Python tracker
<http://bugs.python.org/issue20147>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6625] UnicodeEncodeError on pydoc's CLI
Torsten Landschoff added the comment: I tested this as well and it seems to work now. :-) Thanks for fixing it! -- ___ Python tracker <http://bugs.python.org/issue6625> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8994] pydoc does not support non-ascii docstrings
New submission from Torsten Landschoff : With the attached file doc.py I see the following behaviour: tors...@ddhp3:~$ pydoc doc Traceback (most recent call last): File "/usr/bin/pydoc", line 5, in pydoc.cli() File "/usr/lib/python2.6/pydoc.py", line 2309, in cli help.help(arg) File "/usr/lib/python2.6/pydoc.py", line 1773, in help elif request: doc(request, 'Help on %s:') File "/usr/lib/python2.6/pydoc.py", line 1516, in doc pager(render_doc(thing, title, forceload)) File "/usr/lib/python2.6/pydoc.py", line 1323, in pager pager(text) File "/usr/lib/python2.6/pydoc.py", line 1343, in return lambda text: pipepager(text, 'less') File "/usr/lib/python2.6/pydoc.py", line 1364, in pipepager pipe.write(text) UnicodeEncodeError: 'ascii' codec can't encode characters in position 184-186: ordinal not in range(128) With the terminal on sys.stdout I get "UTF-8" as the encoding (sys.stdout.encoding), therefore I would expect this to work. It would be helpful to have an option to set the encoding when running pydoc as well. And, of course, accessing the documentation via a web browser (pydoc -p 8000, firefox http://localhost:8000) I get a blank screen for the doc.py example. And a backtrace on the terminal where I started pydoc. -- components: Unicode files: doc.py messages: 107774 nosy: torsten priority: normal severity: normal status: open title: pydoc does not support non-ascii docstrings type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file17666/doc.py ___ Python tracker <http://bugs.python.org/issue8994> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24882] ThreadPoolExecutor doesn't reuse threads until #threads == max_workers
Torsten Landschoff added the comment: For demonstration purposes, here is a small example specifically for Linux which shows how each request starts a new thread even though the client blocks for each result. -- nosy: +torsten Added file: http://bugs.python.org/file43061/many_threads.py ___ Python tracker <http://bugs.python.org/issue24882> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22922] asyncio: call_soon() should raise an exception if the event loop is closed
Torsten Landschoff added the comment: If anybody cares, here is a small patch to implement this. I ran the test suite and nothing else fails because of this change. However I wonder if this is a slippery slope to go: If call_soon raises after the event loop is closed than everything else that registers an action with the loop should raise as well. So for consistency this patch should grow quite a bit (unless create_connection, add_reader etc. already raise in this case). If the decision is to go this path I would also suggest to add a new exception type for "Event loop is closed" so that it can be caught in client code. YMMV -- keywords: +patch nosy: +torsten Added file: http://bugs.python.org/file37298/call_soon_after_close.diff ___ Python tracker <http://bugs.python.org/issue22922> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22922] asyncio: call_soon() should raise an exception if the event loop is closed
Torsten Landschoff added the comment: > > If the decision is to go this path I would also suggest to add a new > > exception type for "Event loop is closed" so that it can be caught in > > client code. > I don't see the purpose of handling such exception. It's an obvious bug, you must not handle bugs :) Unless you can't directly fix them. They might be inside a library and triggered during application shutdown. -- ___ Python tracker <http://bugs.python.org/issue22922> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25757] Subclasses of property lose docstring
New submission from Torsten Landschoff: I actually found this in Python2, but it is still unchanged in Python 3.6 dev. Namely, creating an instance of a class derived from property will drop the docstring passed explicitly to the constructor: torsten@defiant:~$ python3.6 Python 3.6.0a0 (default:9fcfdb53e8af, Nov 27 2015, 23:11:09) [GCC 4.8.4] on linux Type "help", "copyright", "credits" or "license" for more information. >>> property(doc="Hello world").__doc__ 'Hello world' >>> class SubProp(property): pass ... >>> SubProp(doc="Hello world").__doc__ >>> This war surprising to me. I actually used a subclass of property to describe fields of configuration classes with extensive documentation, which disappeared during runtime. In Python2 I work around this by assigning to __doc__ as the last thing in the constructor of my SubProp class. -- components: Interpreter Core messages: 255511 nosy: torsten priority: normal severity: normal status: open title: Subclasses of property lose docstring type: behavior versions: Python 3.6 ___ Python tracker <http://bugs.python.org/issue25757> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25757] Subclasses of property lose docstring
Torsten Landschoff added the comment: Here is a proposed patch to correct this including regression tests. -- keywords: +patch Added file: http://bugs.python.org/file41176/subprop_doc.diff ___ Python tracker <http://bugs.python.org/issue25757> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25757] Subclasses of property lose docstring
Torsten Landschoff added the comment: Just a note about the patch: I changed the behaviour a bit in that the code does not ignore random exceptions while getting getter.__doc__. I think that would be surprising for most users and it also does not match the application of the doc field to the subclass, where exceptions are propagated. -- ___ Python tracker <http://bugs.python.org/issue25757> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25757] Subclasses of property lose docstring
Changes by Torsten Landschoff : Added file: http://bugs.python.org/file41181/subprop_doc_r2.diff ___ Python tracker <http://bugs.python.org/issue25757> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25757] Subclasses of property lose docstring
Torsten Landschoff added the comment: Prompted by Emanuel's comment I ran the test with repetitions. This does not actually test his assertion that I missed a decref since he referred to the error case when setting the __doc__ key of the instance dict fails. But I was curious none the less. I was shocked that this failed with ``` torsten@defiant:~/mirror/cpython$ make test TESTOPTS="-R 3:2 test_property" ... test test_property failed -- Traceback (most recent call last): File "/home/torsten/mirror/cpython/Lib/test/test_property.py", line 172, in test_property_decorator_doc_writable self.assertEqual(sub.__class__.spam.__doc__, 'Eggs') AssertionError: 'Spam' != 'Eggs' ``` But this was not introduced by my changes, rather it is an existing bug in the tests: test_property_decorator_doc_writable modifies a class created on module level so the second repetition sees the already updated class. fix_repetitions.diff contains a fix for this problem (by defining the class locally in the test method). While at it I introduced a refleak on purpose and this is correctly reported by the tests. Good to know how to test for this :-) -- Added file: http://bugs.python.org/file41183/fix_repetitions.diff ___ Python tracker <http://bugs.python.org/issue25757> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25843] lambdas on the same line may incorrectly share code objects
Changes by Torsten Landschoff : -- nosy: +torsten ___ Python tracker <http://bugs.python.org/issue25843> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1475692] replacing obj.__dict__ with a subclass of dict
Torsten Landschoff added the comment: I just bumped into this issue because I was shown by a colleague that my implementation of immutable objects (by replacing __dict__ with an ImmutableDict that inherits from dict and blocks write accesses) is ineffective - ouch! I'd expect that Python either rejects subclasses of dict for obj.__dict__ or actually implements accessing correctly. Especially since the enum module created the impression for me that replacing __dict__ is a viable approach (enum.py uses __prepare__ in the meta class to provide a different dict class for enum types, just found https://www.python.org/dev/peps/pep-3115/). Interestingly the PEP 3115 example code notes the following: # Note that we replace the classdict with a regular # dict before passing it to the superclass, so that we # don't continue to record member names after the class # has been created. -- nosy: +torsten ___ Python tracker <http://bugs.python.org/issue1475692> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22543] -W option cannot use non-standard categories
Torsten Landschoff added the comment: Wow, this was news to me and I just ran into it in python 2.7. Checked in Python 3 and it's still there: ``` (py3)->torsten.landschoff@horatio:~$ python3 --version Python 3.6.0a3+ (py3)->torsten.landschoff@horatio:~$ python3 -W error::sqlalchemy.exc.SAWarning -c "print()" Invalid -W option ignored: invalid module name: 'sqlalchemy.exc' ``` I see no easy way to fix this. One way I thought about is to have hooks for importing of modules (called when a module is put into ``sys.modules``, not sure if there is something like this already) and have the warning system trigger on that. There is no way to raise an exception before it is imported anyway... -- nosy: +torsten ___ Python tracker <http://bugs.python.org/issue22543> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1336] subprocess.Popen hangs when child writes to stderr
Torsten Landschoff added the comment: Just got bitten by this problem again. If anybody else still runs into this, the solution on python2.7 is to install the subprocess32 module from pypi.python.org and use that instead of subprocess. -- ___ Python tracker <http://bugs.python.org/issue1336> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
