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
Torsten Landschoff <t.landsch...@gmx.net> 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 dow
Torsten Landschoff <t.landsch...@gmx.net> 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 n
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
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
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
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
Changes by Torsten Landschoff <t.landsch...@gmx.net>:
--
nosy: +torsten
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue25843>
___
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
Changes by Torsten Landschoff <t.landsch...@gmx.net>:
Added file: http://bugs.python.org/file41181/subprop_doc_r2.diff
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
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
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
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 <rep...@bugs.python.org>
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
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
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
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
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
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
Torsten Landschoff added the comment:
I tested this as well and it seems to work now. :-) Thanks for fixing it!
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6625
Changes by Torsten Landschoff t.landsch...@gmx.net:
Added file: http://bugs.python.org/file33328/queue_timeout_1.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20147
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
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
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
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
Torsten Landschoff t.landsch...@gmx.net 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
Torsten Landschoff t.landsch...@gmx.net 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
New submission from Torsten Landschoff t.landsch...@gmx.net:
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
Torsten Landschoff t.landsch...@gmx.net 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
Torsten Landschoff t.landsch...@gmx.net 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
Torsten Landschoff t.landsch...@gmx.net 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 rep...@bugs.python.org
http
Torsten Landschoff t.landsch...@gmx.net 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
Torsten Landschoff t.landsch...@gmx.net 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
Torsten Landschoff t.landsch...@gmx.net 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 rep
Torsten Landschoff t.landsch...@gmx.net 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 rep
Torsten Landschoff t.landsch...@gmx.net 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
Torsten Landschoff t.landsch...@gmx.net 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
New submission from Torsten Landschoff t.landsch...@gmx.net:
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
Changes by Torsten Landschoff t.landsch...@gmx.net:
Added file: http://bugs.python.org/file22308/zlibversion_py3.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12306
Torsten Landschoff t.landsch...@gmx.net 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
Torsten Landschoff t.landsch...@gmx.net 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
Torsten Landschoff t.landsch...@gmx.net 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 rep
Torsten Landschoff t.landsch...@gmx.net 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
Torsten Landschoff t.landsch...@gmx.net 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
Torsten Landschoff t.landsch...@gmx.net 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
New submission from Torsten Landschoff t.landsch...@gmx.net:
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
Torsten Landschoff t.landsch...@gmx.net 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
New submission from Torsten Landschoff t.landsch...@gmx.net:
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
Changes by Torsten Landschoff t.landsch...@gmx.net:
Added file: http://bugs.python.org/file21416/test_clear_handler_py27.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11689
Torsten Landschoff t.landsch...@gmx.net 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
Torsten Landschoff t.landsch...@gmx.net 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 rep
Changes by Torsten Landschoff t.landsch...@gmx.net:
Added file: http://bugs.python.org/file21419/sqlite_transaction_config_py27.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10740
Torsten Landschoff t.landsch...@gmx.net 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
New submission from Torsten Landschoff t.landsch...@gmx.net:
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
New submission from Torsten Landschoff t.landsch...@gmx.net:
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
Torsten Landschoff t.landsch...@gmx.net added the comment:
FYI, this bug is not in Python 3.3 (as of svn r87615).
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10804
Torsten Landschoff t.landsch...@gmx.net added the comment:
Thanks for applying!
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue850728
Torsten Landschoff t.landsch...@gmx.net 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 rep...@bugs.python.org
http
Torsten Landschoff t.landsch...@gmx.net added the comment:
FYI, this still applies to r86094 of py3k.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8488
New submission from Torsten Landschoff t.landsch...@gmx.net:
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 module
pydoc.cli()
File /usr/lib/python2.6/pydoc.py, line 2309, in cli
New submission from Torsten Landschoff t.landsch...@gmx.net:
[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
Torsten Landschoff t.landsch...@gmx.net 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 rep...@bugs.python.org
New submission from Torsten Landschoff t.landsch...@gmx.net:
I ran into an ImportError I was unable to explain:
$ python -c import a.b
Traceback (most recent call last):
File string, line 1, in module
File a/b/__init__.py, line 1, in module
import a.b.c
File a/b/c.py, line 2
Torsten Landschoff t.landsch...@gmx.net 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 rep...@bugs.python.org
http
Torsten Landschoff t.landsch...@gmx.net 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
65 matches
Mail list logo