[issue21042] ctypes.util.find_library() should return full pathname instead of filename in linux

Tamás Bence Gedai added the comment: Is there anything else that I can do for this issue? -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/i

[issue21042] ctypes.util.find_library() should return full pathname instead of filename in linux

Tamás Bence Gedai added the comment: Updated the patch to remove the code duplication, now it stores the values that are calculated in the setUpClass method. It was a good and simple idea, I should have come up with it... :) I'm pretty sure I got the errors during configuration because

[issue21042] ctypes.util.find_library() should return full pathname instead of filename in linux

Tamás Bence Gedai added the comment: I've added a new method to Test_OpenGL_libs as you suggested. I check whether find_library returns an absolute path. Note that I didn't distinguish different systems, as according to the docs, only Linux systems return the file name, other systems return

[issue21042] ctypes.util.find_library() should return full pathname instead of filename in linux

Tamás Bence Gedai added the comment: What do you think about this regex? '(lib%s\.[^\s]+\s\(%s(?:\)|,\s.*\))\s=>\s.*)' % (re.escape(name), abi_type)) It works on 64 bit, just like before, but I could not test it on 32 bit. I'll add tests soon. I looked for documentation on ldcon

[issue23718] strptime() can produce invalid date with negative year day

Tamás Bence Gedai added the comment: I've added a new patch, it uses an other way to calculate the number of days in a given year. I updated the tests, so now it doesn't fail, I also added some extra test cases to test leap years. -- Added file: http://bugs.python.org/file41936

[issue23718] strptime() can produce invalid date with negative year day

Tamás Bence Gedai added the comment: Actually there are already test cases, but they test for the wrong behaviour. The very same example is tested there, but the test gives the expected result, so tm_yday = -3. My implementation returns 362, which looks more reasonable. So currently with my

[issue24015] timeit should start with 1 loop, not 10

Tamás Bence Gedai added the comment: Then maybe the docs should be clarified. "If -n is not given, a suitable number of loops is calculated by trying successive powers of 10 (starting from 10) until the total time is at least 0.2 se

[issue24015] timeit should start with 1 loop, not 10

Tamás Bence Gedai added the comment: I don't know what happened to this issue, but it looks good to me. So here is a patch for it as Joachim suggested. $ time ./python -m timeit "import time; time.sleep(1.0)" 1 loops, best of 3: 1 sec per loop real0m4.134s user0m

[issue21042] ctypes.util.find_library() should return full pathname instead of filename in linux

Tamás Bence Gedai added the comment: I fixed the ABI matching, it was a stupid mistake, thanks for pointing it out :) I think now it works as expected. I really don't find a place for testing. Maybe a new test file could be added, but I think the testing code for find_library wouldn't be more

[issue26279] time.strptime does not properly convert out-of-bounds values

Tamás Bence Gedai added the comment: This is connected to http://bugs.python.org/issue23718 I submitted a patch that hopefully solves this problem. -- nosy: +beng94 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/i

[issue23718] strptime() can produce invalid date with negative year day

Tamás Bence Gedai added the comment: I made a patch, that solves this issue. The problem was that there wasn't any Sunday (%w = 0) on the 0th week in 2015. 2015 started on Thursday, therefore the first Sunday was on 2014.12.28. julian variable is used to set the tm_yday, which was a minus

[issue23718] strptime() can produce invalid date with negative year day

Tamás Bence Gedai added the comment: It looks interesting, let me try to solve this. At first it seems odd that _calc_julian_from_U_or_W returns -2, I guess something is wrong around there. -- nosy: +beng94 ___ Python tracker <rep...@bugs.python.

[issue21042] ctypes.util.find_library() should return full pathname instead of filename in linux

Tamás Bence Gedai added the comment: Added a new patch, as Martin pointed out, I put back the ABI matching. The regex looks quite ugly, because it has to match \n\t. To be exact, it has to match something like this: "/lib/x86_64-linux-gnu/libc.so.6\n\tlibbz2.so.1.0 (libc6,x86-64)".

[issue20109] TestProgram is mentioned in the unittest docs but is not documented

Tamás Bence Gedai added the comment: I think TestProgram should be anonymous, all the work is done in its constructor. I don't see why would anyone would call its functions. I can update the docs if it's needed. -- nosy: +beng94 ___ Python tracker

[issue21328] Resize doesn't change reported length on create_string_buffer()

Tamás Bence Gedai added the comment: Thanks for the remarks, I think the issue can be closed as well. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/i

[issue21328] Resize doesn't change reported length on create_string_buffer()

Tamás Bence Gedai added the comment: I've added a patch, that solves the problem with the built-in len. Even if it turns out that this functionality is not needed, it was quite of a challenge to track down the issue, I've learned a lot. :) Here are some functions, that I looked through, might