New submission from Lukas Lueg :
The objects provided by hashlib mainly serve the purpose of computing hashes
over strings of arbitrary size. The user gets a new object (e.g.
hashlib.sha1()), calls .update() with chunks of data and then finally uses
.digest() or .hexdigest() to get the hash
Lukas Lueg added the comment:
Thanks for your comment; it is a very valid point to consider. However, as a
vector-based implementation is roughly three to four times faster than what
the current API can provide by design (reduced overhead and GIL-relaxation not
included), I may disagree
New submission from Lukas Lueg :
The built-in function map() currently swallows any exception that might have
occured while trying to get an iterator from any parameter. This produces
unexpected behaviour for applications that require a certain type of exception
to be raised when __iter__
Lukas Lueg added the comment:
+1
--
nosy: +ebfe
___
Python tracker
<http://bugs.python.org/issue9285>
___
___
Python-bugs-list mailing list
Unsubscribe:
Lukas Lueg added the comment:
Why not make the start-callback be able to return a boolean value to the
gcmodule that indicates if garbage collection should take place or not.
For example, any value returned from the callback that evaluates to False (like
null) will cause the module to
Lukas Lueg added the comment:
Collection may re-occur at any time, there is no promise to the callback code.
However, the callback can disable the gc, preventing further collection.
I don't think we need the other callbacks to be informed. As the callbacks are
worked down in the order
Lukas Lueg added the comment:
Agreed, let's have the simple callback first.
To solve 2) later on, we could have the callback proposed here be the
'execution'-callback. It neither has nor will have the capability to prevent
garbage-collection.
We can introduce another 'pre
Lukas Lueg added the comment:
agreed
--
___
Python tracker
<http://bugs.python.org/issue1501108>
___
___
Python-bugs-list mailing list
Unsubscribe:
Lukas Lueg added the comment:
Sent the form by fax
___
Python tracker
<http://bugs.python.org/issue4818>
___
___
Python-bugs-list mailing list
Unsubscribe:
Lukas Lueg added the comment:
fixed naming, lock get's tried before releasing the gil to wait for it
Added file: http://bugs.python.org/file12568/md5module_small_locks-2.diff
___
Python tracker
<http://bugs.python.org/i
Changes by Lukas Lueg :
Removed file: http://bugs.python.org/file12565/md5module_small_locks.diff
___
Python tracker
<http://bugs.python.org/issue4818>
___
___
Python-bug
New submission from Lukas Lueg :
Here is the follow-up to issue #4818. The patches attached allow the
built-in SHA modules to release the GIL.
Also the build-in SHA modules will now no longer accept "s#" as input.
Input is parsed just as in the openssl-driven classes where
unicode-o
Changes by Lukas Lueg :
--
keywords: +patch
Added file: http://bugs.python.org/file12569/sha1module_small_locks.diff
___
Python tracker
<http://bugs.python.org/issue4
Changes by Lukas Lueg :
Added file: http://bugs.python.org/file12570/sha256module_small_locks.diff
___
Python tracker
<http://bugs.python.org/issue4821>
___
___
Python-bug
Changes by Lukas Lueg :
Added file: http://bugs.python.org/file12571/sha512module_small_locks.diff
___
Python tracker
<http://bugs.python.org/issue4821>
___
___
Python-bug
Lukas Lueg added the comment:
The lock is created while having the GIL in EVP_update. No other
function releases the GIL (besides the creator-function which does not
need the local lock).
Thereby no other thread can be in between ENTER and LEAVE while the lock
is allocated
Changes by Lukas Lueg :
Removed file: http://bugs.python.org/file12533/hashopenssl_threads-4.diff
___
Python tracker
<http://bugs.python.org/issue4751>
___
___
Python-bug
Lukas Lueg added the comment:
I've modified haypo's patch as commented. The object's lock should be
free 99.9% of the time so we try non-blocking first and can thereby skip
releasing and re-locking the gil (to avoid a deadlock).
Added file: http://bugs.pytho
Lukas Lueg added the comment:
The current behaviour may help the majority by ignorance and cause weird
errors for others. We tell people that Python distincts between Text and
Data but actually treat it all the same by implicit encoding.
Modules that only operate on Bytes should reject Unicode
Lukas Lueg added the comment:
please attach 64times01-double.zip if possible
--
nosy: +ebfe
___
Python tracker
<http://bugs.python.org/issue4844>
___
___
Pytho
Lukas Lueg added the comment:
solved in #4818 and #4821
--
nosy: +ebfe
___
Python tracker
<http://bugs.python.org/issue3745>
___
___
Python-bugs-list mailin
Changes by Lukas Lueg :
Removed file: http://bugs.python.org/file12587/hashlibopenssl_small_lock-4.diff
___
Python tracker
<http://bugs.python.org/issue4751>
___
___
Pytho
Lukas Lueg added the comment:
PyThread_allocate_lock can fail without interference. object->lock will
stay NULL and the GIL is simply not released.
___
Python tracker
<http://bugs.python.org/iss
New submission from Lukas Lueg :
MD5 is one of the most popular cryptographic hash-functions around,
mainly for it's good performance and availability throughout
applications and libraries. The MD5 algorithm is currently implemented
in python as part of the hashlib-module and (in more ge
Lukas Lueg added the comment:
As I already said to Raymond: At least we should update the
documentation. The "FAQ" currently linked is from 2005.
The CERT-Advisory from provides a clean and simple language: "In 2008,
researchers demonstrated the practical vulnerability [...] W
Lukas Lueg added the comment:
> It might be a good idea to remove the word "secure" from the
> hashlib documentation, since security of these algorithms is
> always limited to a certain period of time.
I'm sorry, was that a boy attempted humor ? [Misuse quote from DH3:
Lukas Lueg added the comment:
This is basically the same problem as with other bytes-orientated modules.
The choice is either to reject unicode and force the caller to use
.encode() on all his strings (so 'password' is an instance of bytes and
'ch' an instance of int). I&#
Lukas Lueg added the comment:
The default encoding is UTF8. Even without that there should be no
problems while staying in the same environment as the
character->translation is the same.
However it violates the rule of least surprise to see zipfile throwing
CRC errors because the password
Lukas Lueg added the comment:
I'll do a patch for 2.7
--
versions: +Python 2.7 -Python 3.1
___
Python tracker
<http://bugs.python.org/issue4751>
___
___
Lukas Lueg added the comment:
yes, I got lost on that one. I'll create a patch for 2.7 tonight.
___
Python tracker
<http://bugs.python.org/issue4751>
___
___
Pytho
Lukas Lueg added the comment:
Patch for 2.7
Added file: http://bugs.python.org/file13057/hashlibopenssl_gil_py27.diff
___
Python tracker
<http://bugs.python.org/issue4
Lukas Lueg added the comment:
test_case_md5_0 (__main__.HashLibTestCase) ... ok
test_case_md5_1 (__main__.HashLibTestCase) ... ok
test_case_md5_2 (__main__.HashLibTestCase) ... ok
test_case_md5_huge (__main__.HashLibTestCase) ... ok
test_case_md5_uintmax (__main__.HashLibTestCase) ... ok
Lukas Lueg added the comment:
passing optimize=1 does not help when there is a script
(...scripts=['bla.py']...) in the given distribution. The error will be
thrown for bla.pyo and bla.pyc
--
nosy: +ebfe
___
Python tracker
<http://bu
Lukas Lueg added the comment:
I was investigating a callgrind dump of my code, showing how badly
unicode_hash() was affecting my performance. Using google's cityhash instead
of the builtin algorithm to hash unicode objects improves overall performance
by about 15 to 20 percent for my
Lukas Lueg added the comment:
It's a cache sitting between an informix db and and an internal web service.
Stuff comes out of db, processed, json'ifed, cached and put on the wire. 10**6s
of strings pass this process per request if uncached...
I use CityHash64WithSeed, the seed being
Lukas Lueg added the comment:
Here are some benchmarks for a arm7l on a rk30-board. CityHash was compiled
with -mcpu=native -O3.
CityHash is around half as fast as the native algorithm for small strings and
way, way slower on larger ones. My guess would be that the complex arithmetic
in
Lukas Lueg added the comment:
The 10**4-case is an error (see insane %), I've never been able to reproduce.
Having done more tests with fixed cpu frequency and other daemons' process
priority reduced, cityhash always comes out much slowe
Changes by Lukas Lueg :
Added file: http://bugs.python.org/file30475/cityhash_fasthast3.txt
___
Python tracker
<http://bugs.python.org/issue16427>
___
___
Python-bug
Lukas Lueg added the comment:
Here are more benchmarks of vanilla 3.4 vs. cityhash vs. fast_hash_3 on both
arm7l and x86-64. The patch was applied varbatim, only caching disabled. On
arm7l, the cpu was fixed to maximum freq (it seems to take ages to switch
frequencies, at least there is a lot
New submission from Lukas Lueg:
If the SSL-port is unavailable due to firewall settings (or the host simply
being down), the SSL-tests in test_smtpnet.py fail instead of being skipped.
The tests should be skipped if the smtp.google.com can't be reached and fail
only in case of unexp
Lukas Lueg added the comment:
Diff the make test_smtpnet pass if the network-resource is available but
smtp.google.com's ssl-port can't be reached. Most probably there is a better
way to do this.
--
keywords: +patch
Added file: http://bugs.python.org
Lukas Lueg added the comment:
The behavior is triggered in Modules/_json.c:encoder_listencode_obj(). It
actually has nothing to do with the TypeError itself, any object that produces
a new string representation of itself will do.
The function encoder_listencode_obj() calls the user-supplied
Lukas Lueg added the comment:
It's perfectly fine for the function to return an object that can't be put
directly into a json string. The function may not convert the object directly
but in multiple steps; the encoder will call the function again with the new
object until everyt
Lukas Lueg added the comment:
I have to say this feels like spooky action at a distance.
Wouldnt it be less intrusive - while achieving the same result - to make
MemoryError uncatchable if the flag is set?
--
nosy: +ebfe
___
Python tracker
<h
Lukas Lueg added the comment:
In any strategy only a heuristic could be used in order to decide wether or not
it's safe to raise MemoryError. How exactly is memory pressure expected for
x=[2]*200 but not for x=2*200 ?
I don't think a new function could ultimatly achieve it&
Lukas Lueg added the comment:
The heuristic basically has to decide if memory pressure is so high that it's
not save to return to the interpreter. Even if there is a chosen value (e.g.
failed allocation attempts below 1mb are considered fatal), there can always be
another OS-thread i
Lukas Lueg added the comment:
This could be avoided by
lives_in_init = (('lion': ['Africa', 'America']), ('lion': ['Europe']))
lives_in = {}
for k, v in lives_in_init:
assert k not in lives_in
lives_in[k] = v
del lives_in_init
W
Lukas Lueg added the comment:
PyLint or PyChecker can only do this if the keys are all simple objects like
ints or strings. Consider a class with a custom __hash__
--
___
Python tracker
<http://bugs.python.org/issue16
New submission from Lukas Lueg:
IDLE crashes due to what seems to be a use-after-free bug. Opening a file from
the 'Open...'-menu leads to a segfault after the text has been rendered. It
seems this can be reproduced 100% of the time if the file is big (e.g. 150kb)
and the windo
Lukas Lueg added the comment:
using NSZombieEnabled and MallocStackLoggingNoCompact we can see the
use-after-free behaviour
--
Added file: http://bugs.python.org/file28099/malloc_history.txt
___
Python tracker
<http://bugs.python.org/issue16
Lukas Lueg added the comment:
Switching to ActiveState's TCL fixes the problem on MacOS 10.6
I won't be able to produce a trace for a debug-build on Windows; attaching a
semi-useless trace anyway.
--
Added file: http://bugs.python.org/file28135/backtrace_w
Lukas Lueg added the comment:
On windows, IDLE only crashes if executed via pythonw.exe; if executed under
python.exe, the attached traceback is dumped to stderr
--
Added file: http://bugs.python.org/file28136/excp_traceback.txt
___
Python tracker
Lukas Lueg added the comment:
self.io is set to null before the colorization is finished. When IDLE's
text-window is closed, the AttributeErrors printed to stderr cause IDLE to
crash due to #13582.
One can also trigger the exceptions on any other OS as described in OP. While
#13582
Lukas Lueg added the comment:
@Roger: Triggering the segfault on MacOS 10.6 requires some interaction with
the text-window while the text is being rendered. This includes moving the
window or just clicking into it's canvas. Carefully leaving the window alone
while colorization is goi
Lukas Lueg added the comment:
Thorsten, the problem is that you are using line-based syntax. The code 'for
buffer in f:' will read one line per iteration and put it to 'buffer'; for a
file opened in binary mode, the iterator will always seek to the next b'\n'.
D
Lukas Lueg added the comment:
Only way to be sure: Enable & announce for 3.5 and wait for bug reports
--
nosy: +ebfe
___
Python tracker
<http://bugs.python.org/iss
New submission from Lukas Lueg:
The patch "zlib_keywords.patch" makes zlib's classes and functions accept
keyword arguments as documented. It also fixes two cases in which the docstring
differ from the documentation (decompress(data) vs. decompress(string) and
compresso
Lukas Lueg added the comment:
Attaching a patch to fix all pep8/pyflakes warnings and errors in test_zlib.py
--
Added file: http://bugs.python.org/file28419/zlib_tests_pep8.patch
___
Python tracker
<http://bugs.python.org/issue16
Lukas Lueg added the comment:
Nothing of what you mention is a problem of this patch.
The memLevel-keyword was not supported as of now, only the docstring
("memLevel") and the documentation ("memlevel") mentioned it. There is no
third-party code that could have used it.
T
Lukas Lueg added the comment:
Count me in
--
nosy: +ebfe
___
Python tracker
<http://bugs.python.org/issue1054967>
___
___
Python-bugs-list mailing list
Unsub
Lukas Lueg added the comment:
I'm not sure if such a API is feasible. The very nature of Python makes
it impossible to tell in advance what the interpreter will do when
getting called. This is even true for simple functions - think of your
function getting decorated...
Let's co
Lukas Lueg added the comment:
This is true for all objects whose input could be concatenated.
For example with hashlib:
data = ['foobar']*10
mdX = hashlib.sha1()
for d in data:
mdX.update(d)
mdY = hashlib.sha1()
mdY.update("".join(data))
mdX.digest() == mdY.
New submission from Lukas Lueg :
The file pointer's behaviour after opening a file in 'a+b' mode is not
consistent among platforms: The pointer is set to the beginning of the
file on Linux and to the end of the file on MacOS. You have to call
.seek(0) before calling .read() to
Lukas Lueg added the comment:
bump
hashlibopenssl_gil_py27.diff has not yet been applied to py27 and does
not apply cleanly any more. Here is an updated version.
--
status: pending -> open
Added file: http://bugs.python.org/file13646/hashlibopenssl_gil_py27_2.d
Changes by Lukas Lueg :
Removed file: http://bugs.python.org/file13057/hashlibopenssl_gil_py27.diff
___
Python tracker
<http://bugs.python.org/issue4751>
___
___
Pytho
Lukas Lueg added the comment:
Thanks for your efforts. I don't think you are stepping on anyone's toes
when picking up an issue that was unsolved for almost 5 years :-)
Please post patches to this bug for review/comments/help/whatever
--
Changes by Lukas Lueg :
--
nosy: -ebfe
___
Python tracker
<http://bugs.python.org/issue16632>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.pyth
Changes by Lukas Lueg :
--
nosy: -ebfe
___
Python tracker
<http://bugs.python.org/issue9285>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.pyth
Lukas Lueg added the comment:
Another proposal: Add a new BaseClass that, if inherited from, causes an
exception to be uncatchable (e.g. class HardMemoryError(MemoryError,
UncatchableException)).
--
___
Python tracker
<http://bugs.python.
Lukas Lueg added the comment:
I very strongly doubt that it actually crashes your kernel - it basically
can't. Your desktop becomes unresponsive for up to several minutes as the
kernel has paged out about every single bit of memory to disk, raising access
times by several orders of magn
70 matches
Mail list logo
