[issue28120] The Blaze test suite segfaults with 4a5b61b0d090

Stefan Krah added the comment: Sorry Victor, I have been reporting memory related issues for a long time here. ;) I'm already using Valgrind, why would I set PYTHONMALLOC=debug? -- ___ Python tracker <http://bugs.python.org/is

[issue28120] The Blaze test suite segfaults with 4a5b61b0d090

Stefan Krah added the comment: Victor, I'm beginning to resent your tone. -- ___ Python tracker <http://bugs.python.org/issue28120> ___ ___ Python-bugs-list m

[issue28120] The Blaze test suite segfaults with 4a5b61b0d090

Changes by Stefan Krah : -- nosy: -skrah ___ Python tracker <http://bugs.python.org/issue28120> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue28120] The Blaze test suite segfaults with 4a5b61b0d090

Stefan Krah added the comment: It fails in pytest and has a segfault. The pytest issue should probably be separate issue (it could also be a blaze issue). This is a minimal reproducer for the segfault: = from blaze.expr import symbol

[issue28120] SQLAlchemy's expire_instance() causes _PyDict_Pop: Assertion `ix >= 0' failed.

Stefan Krah added the comment: Thanks, Christian! -- ___ Python tracker <http://bugs.python.org/issue28120> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue28055] pyhash's siphash24 assumes alignment of the data pointer

Stefan Krah added the comment: FWIW, MSVC optimizes memcpy: http://bugs.python.org/issue15993 The pgo issue has been fixed according to Steve Dower. -- nosy: +skrah ___ Python tracker <http://bugs.python.org/issue28

[issue28055] pyhash's siphash24 assumes alignment of the data pointer

Stefan Krah added the comment: For memoryview this is not possible: It is explicitly unaligned and the feature is used in e.g. NumPy. -- ___ Python tracker <http://bugs.python.org/issue28

[issue28055] pyhash's siphash24 assumes alignment of the data pointer

Stefan Krah added the comment: Ah, yes. But compilers optimize memcpy and this is a guaranteed slowdown for the unaligned memoryview case. -- ___ Python tracker <http://bugs.python.org/issue28

[issue28055] pyhash's siphash24 assumes alignment of the data pointer

Stefan Krah added the comment: Numpy itself internally doesn't. Consumers of numpy arrays use memoryviews. Numpy is often used as a library these days, even for simple things like storing a 2-d table, which can easily be several TB. It is also easy to generate unaligned data by just tak

[issue28055] pyhash's siphash24 assumes alignment of the data pointer

Stefan Krah added the comment: s/unaligned/not 8-byte-aligned/ -- ___ Python tracker <http://bugs.python.org/issue28055> ___ ___ Python-bugs-list mailin

[issue28055] pyhash's siphash24 assumes alignment of the data pointer

Stefan Krah added the comment: I don't understand this. Could you explain? -- ___ Python tracker <http://bugs.python.org/issue28055> ___ ___ Python-bugs-l

[issue28055] pyhash's siphash24 assumes alignment of the data pointer

Stefan Krah added the comment: I see. No, most NumPy arrays are C-contiguous. Multi-dimmensional arrays are contiguous, too. Non C-contiguous arrays arise mostly during slicing or if they're Fortran-order to begin with. But NumPy aside, it's weird to have slice of a huge regular

[issue27961] remove support for platforms without "long long"

Stefan Behnel added the comment: Removing HAVE_LONG_LONG entirely causes breakage of third party code that uses this macro to enable PY_LONG_LONG support. Could you please always define it instead of removing it? -- nosy: +scoder ___ Python tracker

[issue28397] Faster index range checks

Stefan Krah added the comment: Serhiy, could you please take out _decimal.c? I thought we had been through that before. :) :) :) -- nosy: +skrah ___ Python tracker <http://bugs.python.org/issue28

[issue28397] Faster index range checks

Stefan Krah added the comment: The same applies to memoryview.c and _testbuffer.c -- I doubt that there's any measurable speed benefit and the clarity is reduced (I also don't want macros there). -- ___ Python tracker <http://bu

[issue28397] Faster index range checks

Stefan Krah added the comment: In the following program, with gcc-5.3 doit() is significantly faster than doit2() in 64-bit Linux: #include int doit(int64_t index, int64_t nitems) { return index < 0 || index >=

[issue28397] Faster index range checks

Stefan Krah added the comment: The difference in favor of doit() is even more pronounced with this loop (also sorry for the uninitialized variable, but that does not make a difference for benchmarking): = for (i = 0; i < 1; i++) { for (j = 0

[issue28397] Faster index range checks

Stefan Krah added the comment: Which version is faster in your tests? -- ___ Python tracker <http://bugs.python.org/issue28397> ___ ___ Python-bugs-list mailin

[issue28397] Faster index range checks

Stefan Krah added the comment: That matches my results as well: -O2 gives about the same speed, with -O3 doit() has a huge advantage. I'm not sure this is an optimization at all. -- ___ Python tracker <http://bugs.python.org/is

[issue28397] Faster index range checks

Stefan Krah added the comment: On 64-bit Linux there's no difference: $ ./usr/bin/gcc -O3 -o issue28397-2 issue28397-2.c $ time ./issue28397-2 0 real0m2.486s user0m2.424s sys 0m0.014s $ time ./issue28397-2 1 real0m2.433s user0m2.422s sys 0m0.008s Also, most o

[issue28435] test_urllib2_localnet.ProxyAuthTests fails with no_proxy and NO_PROXY env

New submission from Stefan Prawda: test_urllib2_localnet.ProxyAuthTests fails with no_proxy and NO_PROXY env set: NO_PROXY=localhost,127.0.0.0/8,::1 no_proxy=localhost,127.0.0.0/8,::1 Patch attached. Run: ./python -m unittest test.test_urllib2_localnet.ProxyAuthTests -v

[issue28435] test_urllib2_localnet.ProxyAuthTests fails with no_proxy and NO_PROXY env

Changes by Stefan Prawda : -- nosy: +lukasz.langa ___ Python tracker <http://bugs.python.org/issue28435> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue27779] Sync-up docstrings in C version of the the decimal module

Stefan Krah added the comment: Raymond: "code area" meant literally that -- all code under Modules/_decimal/* is by myself. It is well understood that you and many people (e.g. Mark Dickinson) have a stake in Decimal. This however does not warrant reassigning an issue in which I h

[issue27779] Sync-up docstrings in C version of the the decimal module

Stefan Krah added the comment: Lisa, thanks for the patch. I've left some comments -- some docstrings in the Python version are outdated, some not quite correct, some are not very clear (to me). I don't know how to proceed. Initially I thought it would be as easy as just takin

[issue27779] Sync-up docstrings in C version of the the decimal module

Stefan Krah added the comment: Okay great. I think it's probably best to produce an initial patch with the verbatim Python docstrings (you can of course address the comments that I already made), then we mark the passages that are clearly not valid for _decimal or outdated for _pyde

[issue27779] Sync-up docstrings in C version of the the decimal module

Changes by Stefan Krah : -- keywords: +patch ___ Python tracker <http://bugs.python.org/issue27779> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue27779] Sync-up docstrings in C version of the the decimal module

Changes by Stefan Krah : -- keywords: -easy, patch ___ Python tracker <http://bugs.python.org/issue27779> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue28772] Bus error in Python 3.6.0beta

New submission from Stefan Scherfke: Hi all, I am trying to build a custom Conda installer for Python 3.6.0b4. I could successfully build an run Python. However, when I run the generated Conda installer, it dies with a "Bus error". It happens when Conda's meta-installer

[issue1129] OpenSSL detection broken for Python 3.0a1

New submission from Stefan Sonnenberg-Carstens: In line 618 the comparison must be this: if (openssl_ver >= 0x00908000): otherwise there are complaints about not being able to build the _sha256 and _sha512 modules, even if OpenSSL >= 0.9.8 is installed, as in my case. -- comp

[issue1129] OpenSSL detection broken for Python 3.0a1

Stefan Sonnenberg-Carstens added the comment: Patch attached: --- setup.py2007-09-07 16:08:05.0 -0400 +++ ../Python-3.0a1_SSC/setup.py2007-09-07 16:07:31.0 -0400 @@ -613,7 +613,7 @@ else: missing.append('_hashlib') -if (o

[issue1126] file.fileno and file.isatty() should be implementable by any file like object

Stefan Sonnenberg-Carstens added the comment: You are free to do what you want. Reasons for not implementing fileno and isatty are: - fileno should be an integer pointing to a real file, so that low-level functions in libc can handle that. Can you provide such ? (see http://netbsd.gw.com/cgi-bin

[issue1125] bytes.split shold have same interface as str.split, or different name

Stefan Sonnenberg-Carstens added the comment: IMHO I also aggree that strings and bytes (list of bytes) should have the same interface. It is common sense that talking about strings most programmers think of a list of bytes composing it (char *). So the abbreviation should also hold true with

[issue1134] Parsing a simple script eats all of your memory

Stefan Sonnenberg-Carstens added the comment: Same under Linux with Python 3.0a1. Eats all cpu + memory -- nosy: +pythonmeister __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/

[issue1141] reading large files

Stefan Sonnenberg-Carstens added the comment: Perhaps this is an issue of line separation ? Could you provide the output of wc -l on a *NIX box ? And, could you try with this code: import sys print(sys.version_info) import time print (time.localtime()) fichin=open(r'D:\python

[issue1141] reading large files

Stefan Sonnenberg-Carstens added the comment: Sorry, this way: import sys print(sys.version_info) import time print (time.strftime('%Y-%m-%d %H:%M:%S')) fichin=open(r'D:\pythons\16s\total_gb_161_16S.gb') start = time.time() for i,li in enumerate(fichin): if

[issue1142] code sample showing errors reading large files with py 2.5

Stefan Sonnenberg-Carstens added the comment: Error confirmed for this python: Python 3.0a1 (py3k, Sep 10 2007, 22:45:51) [GCC 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)] on linux2 See this: [EMAIL PROTECTED]:~$ python2.4 large_io.py (2, 4, 4, 'final', 0) 2007-09-10 21:41:5

[issue1142] code sample showing errors reading large files with py 2.5/3.0

Changes by Stefan Sonnenberg-Carstens: -- components: +Interpreter Core title: code sample showing errors reading large files with py 2.5 -> code sample showing errors reading large files with py 2.5/3.0 versions: +Python 3.0 __ Tracker <

[issue1142] code sample showing errors reading large files with py 2.5/3.0

Stefan Sonnenberg-Carstens added the comment: I can confirm that under Linux (Linux nx6310 2.6.22-1-mepis-smp #1 SMP PREEMPT Wed Sep 5 22:23:08 EDT 2007 i686 GNU/Linux, SimplyMepis 7.0b3) 1. using Python 3.0a1 is _very_ slow 2. it eats all your cpu (see my post) I did not take the time to wait

[issue1159] os.getenv() not updated after external module uses C putenv()

Stefan Sonnenberg-Carstens added the comment: > As per the document and my simple test (on Linux), os.putenv() does > not update os.environ. I think, it should update it. What would be the benefit ? -- nosy: +pythonmeister __ Tracker <[EMAIL

[issue1159] os.getenv() not updated after external module uses C putenv()

Stefan Sonnenberg-Carstens added the comment: I'd like to see perl/ruby behaviour: an dict (os.environ), nothing more (perl %ENV,ruby $ENV). Get rid of setenv/putenv at all. 3.0a1 has even more: There is os.environ (a dict), os.[put|get]env() and os.environ.p

[issue1279] os.system() oddity under Windows XP SP2

New submission from Stefan Sonnenberg-Carstens: When doing such os.system("a command wich writes a outfile") f = open("the file the command before wrote") the file is empty. If I do this: os.popen("a command wich writes a outfile") f = open("the file the co

[issue1405] Garbage collection not working correctly in Python 2.3

New submission from Stefan Sonnenberg-Carstens: when running this script: aList = [] for i in xrange(5E5): aList += [[]] for j in xrange(10): aList[-1].append([]) del aList It does not give back the memory even a import gc gc.collect() afterwards does not do it. In Python

[issue1366] popen spawned process may not write to stdout under windows

Stefan Sonnenberg-Carstens added the comment: the popen call does not redirect stderr. If you do something like 2>null (windows) or 2>/dev/null (*nix) it will _never_ get printed. If you want to have stderr & stdout getting in via popen and thus stdout, under *nix and windows you wou

[issue1398] Can't pickle partial functions

Stefan Sonnenberg-Carstens added the comment: You are using an old protocol version pickle.dumps(partial_f,2) does the trick: >>> pickle.dumps(partial_f,2) '\x80\x02cfunctools\npartial\nq\x00)\x81q\x01}q\x02b.' -- nosy: +pythonmeister ___

[issue1405] Garbage collection not working correctly in Python 2.3

Stefan Sonnenberg-Carstens added the comment: No, I can't. As many Front Arena Developers on the 1.6/2.0/2.1/2.2 can't. Python 2.4 will be in Front Arena 4.0. Lightyears away from here. Same behaviour seen under Solaris 10 / Python 2.5.1 -- versions: +

[issue3233] Timestamp stored in ZIP file not correct ?

New submission from Stefan Sonnenberg-Carstens <[EMAIL PROTECTED]>: Given the attached source, I can produce these results: [EMAIL PROTECTED] ~]$ python ziptest.py Start 10:05:54 ZIP stored mtime: (2008, 6, 29, 10, 5, 54) Original mtime: (2008, 6, 29, 10, 5, 54) Duration 0.0029170513153

[issue3233] Timestamp stored in ZIP file not correct ?

Stefan Sonnenberg-Carstens <[EMAIL PROTECTED]> added the comment: [EMAIL PROTECTED] ~]$ python -V Python 2.5.1 [EMAIL PROTECTED] ~]$ uname -a Linux localhost.localdomain 2.6.25.6-55.fc9.i686 #1 SMP Tue Jun 10 16:27:49 EDT 2008 i686 i686 i386 GNU

[issue3233] Timestamp stored in ZIP file not correct ?

Stefan Sonnenberg-Carstens <[EMAIL PROTECTED]> added the comment: I changed the script a bit, so that the txt file is not getting recreated every time. It gives: [EMAIL PROTECTED] ~]$ python ziptest.py Start 10:15:05 ZIP stored mtime: (2008, 6, 29, 10, 15, 4) Original mtime: (2008, 6,

[issue1603] Wanted behaviour ?

New submission from Stefan Sonnenberg-Carstens: >>> a = {} >>> a['a'] = [1,2,3,4,5] >>> a['b'] = [1,2,3,4,5] >>> a['c'] = [1,2,3,4,5] >>> for k in a.keys(): ... print a[k] ... for t in a[k]: ... del

[issue35325] imp.find_module() return value documentation discrepancy

New submission from Stefan Bauer (TraceTronic) : I’d like to report a discrepancy between the documentation and implementation of the method imp.find_module(). The documentation <https://docs.python.org/3.7/library/imp.html#imp.find_module> currently says “If the module does not liv

[issue35325] imp.find_module() return value documentation discrepancy

Stefan Bauer (TraceTronic) added the comment: Hi, thank you for your proposal. However, your version still contains the discepancy. Maybe I formulated the problem not clear, so let's try again: The documentation should state that "pathname" will be None (not the empty strin

[issue7308] Named group regex error

New submission from Stefan Sonnenberg-Carstens : >>> import re >>> p = re.compile(r'(P?("[^"]*"))') >>> p.match('"Hallo"') >>> p = re.compile(r'("[^"]*")') >>> p.match('"

[issue21724] resetwarnings doesn't reset warnings registry

Stefan van der Walt added the comment: This can be quite painful to work around, since the warning registry is scattered all over. See, e.g., https://github.com/scikit-image/scikit-image/blob/master/skimage/_shared/_warnings.py#L9 -- nosy: +stefanv

[issue2527] Pass a namespace to timeit

Changes by Stefan van der Walt : -- nosy: +stefanv ___ Python tracker <http://bugs.python.org/issue2527> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue2057] difflib: add patch capability

Changes by Stefan van der Walt : -- nosy: +stefanv ___ Python tracker <http://bugs.python.org/issue2057> ___ ___ Python-bugs-list mailing list Unsubscribe:

<    45   46   47   48   49   50