[issue39408] Add support for SQLCipher

Sebastian Noack added the comment: Yes, I could use LD_LIBRARY_PATH (after copying /usr/lib/libsqlcipher.so.0 to /some/folder/libsqlite3.so), or alternatively LD_PRELOAD, and the sqlite3 stdlib module will just work as-is with SQLCipher. The latter is in fact what I'm doing at the m

[issue39408] Add support for SQLCipher

Sebastian Noack added the comment: Well, the stdlib already depends on a third-party library here, i.e. SQLite3. SQLCipher is a drop-in replacement for SQLite3 that adds support for encrypted databases. In order to use SQLCipher, I'd have to build the sqlite3 module against SQLC

[issue39408] Add support for SQLCipher

New submission from Sebastian Noack : SQLCipher is industry-standard technology for managing an encrypting SQLite databases. It has been implemented as a fork of SQLite3. So the sqlite3 corelib module would build as-is against it. But rather than a fork (of this module), I'd rathe

[issue30297] Recursive starmap causes Segmentation fault

Sebastian Noack added the comment: Thanks for your response, both of you. All you said, make sense. Just for the record, I wouldn't necessarily expect 200k nested iterators to work. Even if it could be made work, I guess it would use way too much memory. But a RuntimeError would be

[issue30297] Recursive starmap causes Segmentation fault

Sebastian Noack added the comment: I just noticed that the segfault can also be reproduced with Python 2 [1]. So please ignore what I said before that this wouldn't be the case. While it is debatable whether using a lazy evaluated object with so many recursions is a good idea in the

[issue30297] Recursive starmap causes Segmentation fault

New submission from Sebastian Noack: If I run following code (on Python 3.5.3, Linux) the interpreter crashes with a segfault: def pbkdf2_bin(data, salt, iterations=1000, keylen=24, hashfunc=None): hashfunc = hashfunc or hashlib.sha1 mac = hmac.new(data, None, hashfunc) def

[issue24527] The MimeTypes class cannot ignore global files per instance

New submission from Sebastian Noack: In order to prevent the mimetypes module from considering global files and registry entries, you have to call mimetypes.init([]). However, this will enforce that behavior globally, and only works if the module wasn't initialized yet. There is a

[issue8800] add threading.RWLock

Sebastian Noack added the comment: @Kristján: Uhh, that is a huge amount of code, more than twice as much (don't counting tests) as my implementation, to accomplish the same. And it seems that there is not much code shared between the threading and multiprocessing implementation. And for

[issue8800] add threading.RWLock

Sebastian Noack added the comment: Exactly, with my implemantation "the lock acquired first will be granted first". There is no way that either shared nor exclusive locks can starve, and therefore it should satisfy all use cases. Since you can only share simple datastructures lik

[issue8800] add threading.RWLock

Sebastian Noack added the comment: Thanks, but as I already said there are a lot of implementations for shared/exclusive lock that can be acquired from different threads. But we need with threading as well as with multiprocessing. And by the way POSIX is the standard for implementing UNIX

[issue8800] add threading.RWLock

Sebastian Noack added the comment: I would love to see how other people would implement a shared/exclusive lock that can be acquired from different processes. However it really seems that nobody did it before. If you know a reference implementation I would be more than happy. There are

[issue8800] add threading.RWLock

Sebastian Noack added the comment: > If you want to argue it this way, I counter that the attributes > "shared" and "exclusive" apply to the type of "access to the > protected object" you are talking about, and yet, the name suggest > that they are att

[issue8800] add threading.RWLock

Sebastian Noack added the comment: @richard: I'm sorry, but both of my patches contain changes to 'Lib/threading.py' and can be applied on top of Python 3.3.0. So can you explain what do you mean, by missing the changes

[issue8800] add threading.RWLock

Sebastian Noack added the comment: Yes, you could also look at the shared/exclusive lock as one lock with different states. But this approach is neither more common, have a look at Java's ReadWriteLock [1] for example, which works just like my patch does, except that a factory is ret

[issue8800] add threading.RWLock

Sebastian Noack added the comment: I was just waiting for a comment pointing out, that my patch comes without tests. :) Note that we are still discussing the implementation and this patch is just a proof of concept. And since the way it is implemented and the API it provides could still

[issue8800] add threading.RWLock

Sebastian Noack added the comment: I've added a new patch, that implements a shared/exclusive lock as described in my comments above, for the threading and multiprocessing module. -- Added file: http://bugs.python.org/file27350/Added-ShrdExclLock-to-threading-and-multiprocessing.

[issue8800] add threading.RWLock

Sebastian Noack added the comment: Using a lock as context manager is the same as calling lock.acquire(blocking=True) and it will in fact block while waiting for an other thread to release the lock. In your code, the internal lock is indeed just hold for a very short period of time while

[issue8800] add threading.RWLock

Sebastian Noack added the comment: I would love to see a reader/writer lock implementation shipped with Python's threading (and multiprocessing) module. But I have some issues with the patch: 1. I would avoid the terms 'read' and 'write' as those terms are referring