[issue9167] argv double encoding on OSX
Ronald Oussoren ronaldousso...@mac.com added the comment:
I cannot reproduce this with both 3.1.2 and 3.2a (py3k:80693), in both cases I
get the same output as you do on Linux. This is on OSX 10.6 though, I haven't
tested on 10.4 yet.
What is the output of the locale command on your OSX system? Mine says:
$ locale
LANG=en_US.UTF-8
LC_COLLATE=en_US.UTF-8
LC_CTYPE=en_US.UTF-8
LC_MESSAGES=en_US.UTF-8
LC_MONETARY=en_US.UTF-8
LC_NUMERIC=en_US.UTF-8
LC_TIME=en_US.UTF-8
LC_ALL=
And what is the value of __CF_USER_TEXT_ENCODING? My is:
$ echo ${__CF_USER_TEXT_ENCODING}
0x1F6:0:0
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9167
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9167] argv double encoding on OSX
Ronald Oussoren ronaldousso...@mac.com added the comment: BTW. My 3.1 build is: release31-maint:80235M, which is slightly newer that the 3.1.2 release. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9167 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9164] 2.7 sysconfig should handle arch duplicates while building universal on OS X
Jyrki Wahlstedt jyrki.wahlst...@wahlstedt.fi added the comment: The fix could be something like replace line 649 in sysconfig.py: archs = tuple(archs) with: archs = tuple(sorted(list(set(archs This removes the duplicates, but as transforming the list to set does not seem to keep order, it is necessary to sort the list (hence the previous line sorting the list could be dropped perhaps). -- title: 2.7 sysconfig should handle arch duplicates - 2.7 sysconfig should handle arch duplicates while building universal on OS X ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9164 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9164] 2.7 sysconfig should handle arch duplicates while building universal on OS X
Changes by Mark Dickinson dicki...@gmail.com: -- assignee: - ronaldoussoren components: +Macintosh nosy: +ronaldoussoren ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9164 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1974] email.MIMEText.MIMEText.as_string incorrectly folding long subject header
Nicolas Dumazet nicd...@gmail.com added the comment: Hello folks. (stumbling on this bug with Python2.7 release, noting that a few Mercurial tests broke with 2.7) I have no problem whatsoever with the fix itself (you know emails better than me), but you broke backwards compatibility for email.generator.Generator here, without propagating the changes to previous versions. 1) It would have been nice to flag this somewhere in the release notes, and/or the documentation for email.generator.Generator. Finding the reason of the Mercurial failures was... a bit trickier than necessary :) 2) What durable solutions can you propose for those of us that have to support several Python versions and share a similar behaviour? In a perfect world, I would simply do this: class CompatibleHeader(email.Header.Header.__class__): Python2.7 introduces a backwards incompatible change (Python issue1974, r70772) in email.generaor.Generator code: pre-2.7 code passed continuation_ws='\t' to the Header constructor, and 2.7 removed this parameter. Default argument is continuation_ws=' ', which means that the behaviour is different in 2.7 and 2.7 We consider the 2.7 behaviour to be preferable, but need to have an unified behaviour for versions 2.4 to 2.7 def __init__(self, **kw): # override continuation_ws kw['continuation_ws'] = ' ' email.Header.Header.__init__(self, **kw) email.Header.Header.__class__ = CompatibleHeader and get over it, but you'll notice that Header is still an old-style class... so that's not possible. Any suggestions? Thanks! -- nosy: +djc, nicdumz ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1974 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1974] email.MIMEText.MIMEText.as_string incorrectly folding long subject header
Chris Withers ch...@simplistix.co.uk added the comment: Maybe an old-fashioned monkey-patch would be the way to go? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1974 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2636] Regexp 2.7 (modifications to current re 2.2.2)
Ezio Melotti ezio.melo...@gmail.com added the comment: Matthew, I'd like to see at least some of these features in 3.2, but ISTM that after more than 2 years this issue is not going anywhere. Is the module still under active development? Is it ready? Is it waiting for reviews and to be added to the stdlib? Is it waiting for more people to test it on PyPI? If the final goal is adding it to the stdlib, are you planning to add it as a new module or to replace the current 're' module? (or is 'regex' just the 're' module with improvements that could be merged?) Another alternative would be to split it in smaller patches (ideally one per feature) and integrate them one by one, but IIRC several of the patches depend on each other so it can't be done easily. Unless there is already a plan about this (and I'm not aware of it), I'd suggest to bring this up to python-dev and decide what to do with the 'regex' module. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2636 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9154] Parser module doesn't understand function annotations.
Mark Dickinson dicki...@gmail.com added the comment: Patch fixing validation of function annotations and keyword-only arguments. There's still the issue of false positives: annotations on lambda arguments should raise an exception, but don't. -- keywords: +patch Added file: http://bugs.python.org/file17880/parser_annotations_kwonly.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9154 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9154] Parser module doesn't understand function annotations.
Changes by Mark Dickinson dicki...@gmail.com: -- stage: unit test needed - patch review ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9154 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9175] ctypes doesn't build on hp-ux
New submission from Ronald Oussoren ronaldousso...@mac.com: During the build of python2.7 on a HP-UX machine I get this compile error when building the ctypes extension: cc -Ae +z -Olimit 1500 -g -DNDEBUG -O -Ibuild/temp.hp-ux-B.11.23-9000-800-2.7/libffi/include -Ibuild/temp.hp-ux-B.11.23-9000-800-2.7/libffi -I/home/xsupport/bld/Python-2.7/Modules/_ctypes/libffi/src -I/opt/python2.7/include -I. -IInclude -I./Include -I/home/xsupport/bld/Python-2.7/Include -I/home/xsupport/bld/Python-2.7 -c /home/xsupport/bld/Python-2.7/Modules/_ctypes/_ctypes.c -o build/temp.hp-ux-B.11.23-9000-800-2.7/home/xsupport/bld/Python-2.7/Modules/_ctypes/_ctypes.o cpp: build/temp.hp-ux-B.11.23-9000-800-2.7/libffi/include/ffi.h, line 133: error 4044: Constant literal too large. cpp: build/temp.hp-ux-B.11.23-9000-800-2.7/libffi/include/ffi.h, line 134: error 4062: no 64-bit data type supported Compiler version: B9007AA C.11.23.12 HP C/aC++ Developer's Bundle System info: HP-UX ah006b02 B.11.23 U 9000/800 2284397887 unlimited-user license -- assignee: theller components: Build, ctypes messages: 109374 nosy: ronaldoussoren, theller priority: normal severity: normal status: open title: ctypes doesn't build on hp-ux type: compile error versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9175 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7899] MemoryError While Executing Python Code
Mark Dickinson dicki...@gmail.com added the comment: Peter, this looks like a different problem; please could you open a new issue? When/if you do, please could you also report: - what version of Python you're using - your system details (what OS? 32-bit or 64-bit?) If you can give us a better idea of what's in your 86Mb file, that would also help: perhaps post the first few and last few lines. What's in this list? Integers? Floats? Strings? It's not totally implausible that Python really *does* need gigabytes of memory to process a list in an 86Mb file. -- nosy: +mark.dickinson ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7899 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1974] email.MIMEText.MIMEText.as_string incorrectly folding long subject header
Nicolas Dumazet nicd...@gmail.com added the comment: Sure, where was my head. So, a simple patch like this one: _oldheaderinit = email.Header.Header.__init__ def _unifiedheaderinit(self, *args, **kw): # override continuation_ws kw['continuation_ws'] = ' ' _oldheaderinit(self, *args, **kw) email.Header.Header.__dict__['__init__'] = _unifiedheaderinit fixes the issue for us, and might be helpful to others. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1974 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9167] argv double encoding on OSX
Daniele Varrazzo p...@develer.com added the comment: Attached patch with test cases to check sys.argv and sys.executable. The tests fail against the daily snapshot, so adding python 3.2 to the affected versions. Variable __CF_USER_TEXT_ENCODING is undefined. Locale of the system is C: $ locale LANG= LC_COLLATE=C LC_CTYPE=C LC_MESSAGES=C LC_MONETARY=C LC_NUMERIC=C LC_TIME=C LC_ALL= -- keywords: +patch versions: +Python 3.2 Added file: http://bugs.python.org/file17881/test-argv.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9167 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9176] module termios doesn't build on HP-UX
New submission from Ronald Oussoren ronaldousso...@mac.com: I get the following error when building the termios module on HP-UX: cc -Ae +z -Olimit 1500 -g -DNDEBUG -O -I/opt/python2.7/include -I. -IInclude -I./Include -I/home/xsupport/bld/Python-2.7/Include -I/home/xsupport/bld/Python-2.7 -c /home/xsupport/bld/Python-2.7/Modules/termios.c -o build/temp.hp-ux-B.11.23-9000-800-2.7/home/xsupport/bld/Python-2.7/Modules/termios.o cc: /home/xsupport/bld/Python-2.7/Modules/termios.c, line 75: error 1574: Unknown size for mode. cc: /home/xsupport/bld/Python-2.7/Modules/termios.c, line 96: error 1530: Undefined struct or union. cc: /home/xsupport/bld/Python-2.7/Modules/termios.c, line 96: error 1527: Incompatible types in cast: Must cast from scalar to scalar or to void type. cc: /home/xsupport/bld/Python-2.7/Modules/termios.c, line 106: error 1530: Undefined struct or union. (The line numbers are off by 3 due to an experiment that doesn't affect the error message beyond the linenumbers). Compiler version: B9007AA C.11.23.12 HP C/aC++ Developer's Bundle System info: HP-UX ah006b02 B.11.23 U 9000/800 2284397887 unlimited-user license -- components: Build messages: 109378 nosy: ronaldoussoren priority: normal severity: normal status: open title: module termios doesn't build on HP-UX type: compile error versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9176 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9177] ssl.read/write on closed socket raises AttributeError
New submission from Cyril c...@excellency.fr:
This:
import socket, ssl
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
ssl_sock = ssl.wrap_socket(s)
ssl_sock.connect(('www.verisign.com', 443))
ssl_sock.close()
ssl_sock.read(1024)
raises:
Traceback (most recent call last):
File /tmp/bug.py, line 10, in module
ssl_sock.read(1024)
File /path/to/lib/python2.7/ssl.py, line 138, in read
return self._sslobj.read(len)
AttributeError: 'NoneType' object has no attribute 'read'
I would expect a socket.error instead, which mimics the way regular sockets
behave. Indeed, this code:
import socket, ssl
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect(('www.verisign.com', 80))
s.close()
s.recv(1024)
raises:
Traceback (most recent call last):
File /tmp/bug.py, line 6, in module
s.recv(1024)
File /path/to/lib/python2.7/socket.py, line 170, in _dummy
raise error(EBADF, 'Bad file descriptor')
socket.error: [Errno 9] Bad file descriptor
I've tested on the latest trunks on both 2.7 and 3.2. I've also tested on 2.6
and 3.1.
I can write a patch that fixes it if the bug is accepted.
--
components: Library (Lib)
messages: 109379
nosy: cbay
priority: normal
severity: normal
status: open
title: ssl.read/write on closed socket raises AttributeError
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9177
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9178] Compile problem on HP-UX 11
New submission from Ronald Oussoren ronaldousso...@mac.com: I get a segmentation fault in the compiler when building python 2.7 on an HP-UX machine. Compiler version: B9007AA C.11.23.12 HP C/aC++ Developer's Bundle System info: HP-UX ah006b02 B.11.23 U 9000/800 2284397887 unlimited-user license Last bit of the output of make: cc -Ae -c -Olimit 1500 -g -DNDEBUG -O -I. -IInclude -I./Include -DPy_BUILD_CORE -o Objects/exceptions.o Objects/exceptions.c ( 0) 0x002012ac Call_exit + 0x58 [/opt/ansic/lbin/ccom] ( 1) 0x001f3938 catch_signal + 0x1c [/opt/ansic/lbin/ccom] ( 2) 0x00967fb8 _sigreturn [/opt/ansic/lbin/ccom] ( 3) 0x008759ec doc_assign_range_bounds + 0x1430 [/opt/ansic/lbin/ccom] ( 4) 0x008730cc doc_process_ranges + 0xdc [/opt/ansic/lbin/ccom] ( 5) 0x0063b2d0 opt_driver + 0x1e20 [/opt/ansic/lbin/ccom] ( 6) 0x00547cc8 process_sllic_graph + 0x1a8 [/opt/ansic/lbin/ccom] ( 7) 0x00545320 pass2_ucode + 0x47c [/opt/ansic/lbin/ccom] ( 8) 0x005818b0 cg_end + 0x38c [/opt/ansic/lbin/ccom] ( 9) 0x002875fc be_end + 0x1c [/opt/ansic/lbin/ccom] (10) 0x00271df0 fl_defn + 0x5fc [/opt/ansic/lbin/ccom] (11) 0x0025e74c fl_stmt + 0x25c [/opt/ansic/lbin/ccom] (12) 0x001fa2ac cpx_Process_tree + 0xc18 [/opt/ansic/lbin/ccom] (13) 0x00213378 Process_tree_received_as_output + 0x474 [/opt/ansic/lbin/ccom] (14) 0x00212ea0 P_build_non_leaf + 0x8c [/opt/ansic/lbin/ccom] (15) 0x00205690 Faster_parser + 0x4bc [/opt/ansic/lbin/ccom] (16) 0x00202168 LR_parser + 0x10 [/opt/ansic/lbin/ccom] (17) 0x002015a0 Do_MW + 0x18 [/opt/ansic/lbin/ccom] (18) 0x001f4244 main + 0x7a0 [/opt/ansic/lbin/ccom] (19) 0x0090fa40 _start + 0x98 [/opt/ansic/lbin/ccom] (20) 0x001f2000 $START$ + 0x178 [/opt/ansic/lbin/ccom] cc: error 1405: /opt/ansic/lbin/ccom terminated abnormally with signal 11. *** Error exit code 9 I can finish the build by compiling this file and Modules/_io/_iomodule.o without the '-O' flag (the latter took some tweaking) It is unlikely that this is a Python bug, but I'm filing it here anyway just in case anyone else runs into it. see also: Issue9176, Issue9175 -- components: Build messages: 109380 nosy: ronaldoussoren priority: normal severity: normal status: open title: Compile problem on HP-UX 11 type: compile error versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9178 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7899] MemoryError While Executing Python Code
Mark Dickinson dicki...@gmail.com added the comment: Closing the original issue: there's insufficient information to reproduce or analyze the problem. -- resolution: - works for me status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7899 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9179] Lookback with group references incorrect (two issues?)
New submission from andrew cooke and...@acooke.org:
from re import compile
# these work as expected
assert compile('(a)b(?=b)(c)').match('abc')
assert not compile('(a)b(?=c)(c)').match('abc')
assert compile('(a)b(?=c)(c)').match('abc')
assert not compile('(a)b(?=b)(c)').match('abc')
# but when you add groups, you get bugs
assert not compile('(?:(a)|(x))b(?=(?(2)x|c))c').match('abc') # matches!
assert not compile('(?:(a)|(x))b(?=(?(2)b|x))c').match('abc')
assert compile('(?:(a)|(x))b(?=(?(2)x|b))c').match('abc') # fails!
assert not compile('(?:(a)|(x))b(?=(?(1)c|x))c').match('abc') # matches!
assert compile('(?:(a)|(x))b(?=(?(1)b|x))c').match('abc') # fails!
# but lookahead works as expected
assert compile('(?:(a)|(x))b(?=(?(2)x|c))c').match('abc')
assert not compile('(?:(a)|(x))b(?=(?(2)c|x))c').match('abc')
assert compile('(?:(a)|(x))b(?=(?(2)x|c))c').match('abc')
assert not compile('(?:(a)|(x))b(?=(?(1)b|x))c').match('abc')
assert compile('(?:(a)|(x))b(?=(?(1)c|x))c').match('abc')
# these are similar but, in my opinion, shouldn't even compile
# (group used before defined)
assert not compile('(a)b(?=(?(2)x|c))(c)').match('abc') # matches!
assert not compile('(a)b(?=(?(2)b|x))(c)').match('abc')
assert not compile('(a)b(?=(?(1)c|x))(c)').match('abc') # matches!
assert compile('(a)b(?=(?(1)b|x))(c)').match('abc') # fails!
assert compile('(a)b(?=(?(2)x|c))(c)').match('abc')
assert not compile('(a)b(?=(?(2)b|x))(c)').match('abc')
assert compile('(a)b(?=(?(1)c|x))(c)').match('abc')
# this is the error we should see above
try:
compile('(a)\\2(b)')
assert False, 'expected error'
except:
pass
--
components: Library (Lib)
messages: 109382
nosy: acooke
priority: normal
severity: normal
status: open
title: Lookback with group references incorrect (two issues?)
type: behavior
versions: Python 2.6
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9179
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9179] Lookback with group references incorrect (two issues?)
andrew cooke and...@acooke.org added the comment: I hope the above is clear enough (you need to stare at the regexps for a time) - basically, lookback with a group conditional is not as expected (it appears to be evaluated as lookahead?). Also, some patterns compile that probably shouldn't. The re package only supports (according to the docs) lookback on expressions whose length is known. So I guess it's also possible that (?(n)pat1|pat2) should always fail that, even when len(pat1) = len(pat2)? Also, the generally excellent unit tests for the re package don't have much coverage for lookback (I am writing my own regexp lib and it passes all the re unit tests but had a similar bug - that's how I found this one...). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9179 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2636] Regexp 2.7 (modifications to current re 2.2.2)
Alex Willmer a...@moreati.org.uk added the comment: I've packaged Matthew's latest revision and uploaded it to PyPI. This version will build for Python 2 and Python 3, parallel installs will coexist on the same machine. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2636 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9170] zipfile cannot read AES encrypted files
Amaury Forgeot d'Arc amaur...@gmail.com added the comment: zipfile only supports the Traditional PKWARE Encryption method. Support for other encryption methods would be useful. -- nosy: +amaury.forgeotdarc stage: - needs patch title: zipfile.extractall raises runtime error on correct password - zipfile cannot read AES encrypted files type: behavior - feature request ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9170 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9167] argv double encoding on OSX
Daniele Varrazzo p...@develer.com added the comment: I've made some other test with LANG=C on other platforms. It seems resulting in a clean error on Linux: $ LANG=C ./here/bin/python3 Python 3.2a0 (py3k, Jul 6 2010, 12:40:29) [GCC 4.3.2] on linux2 Type help, copyright, credits or license for more information. import sys, os snowman = '\u2603' os.system((sys.executable + -c 'import sys; print(sys.argv[-1].encode(\utf8\))' + snowman).encode(sys.getdefaultencoding())) Traceback (most recent call last): File string, line 1, in module UnicodeEncodeError: 'utf-8' codec can't encode character '\udce2' in position 0: surrogates not allowed 256 Notice that I had to use an explicit encoding or os.system would have tried to encode using ascii and barf, probably because of bug #8775. I've also been reported about issue #4388: I've checked and test_run_code() fails as described. So I think this bug can be considered a #4388 duplicate. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9167 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9179] Lookback with group references incorrect (two issues?)
andrew cooke and...@acooke.org added the comment: If it's any help, these are the equivalent tests as I think they should be (you'll need to translate engine(parse(... to compile(...) http://code.google.com/p/rxpy/source/browse/rxpy/src/rxpy/engine/backtrack/_test/engine.py?r=fc52f6959a0cfabdddc6960f47d7380128bb3584#284 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9179 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9179] Lookback with group references incorrect (two issues?)
Mark Dickinson dicki...@gmail.com added the comment: Thanks very much for the reports. So I guess it's also possible that (?(n)pat1|pat2) should always fail that, even when len(pat1) = len(pat2)? Yes, this seems likely to me. Possibly even the compile stage should fail, though I've no idea how feasible it is to make that happen. Unfortunately I'm not sure that any of the currently active Python developers is particularly well versed in the intricacies of the re module. The most realistic option here may be just to document the restrictions on lookbehind assertions more clearly. Unless you're able to provide a patch? -- nosy: +mark.dickinson, mrabarnett ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9179 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9179] Lookback with group references incorrect (two issues?)
Changes by Mark Dickinson dicki...@gmail.com: -- versions: +Python 2.7, Python 3.1, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9179 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9169] Deprecate use of more than 3 positional arguments in timedelta constructor
Changes by Alexander Belopolsky belopol...@users.sourceforge.net: -- priority: normal - low resolution: - rejected status: open - pending ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9169 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9179] Lookback with group references incorrect (two issues?)
andrew cooke and...@acooke.org added the comment: I thought someone was working on the re module these days? I thought there I'd seen some issues with patches etc? Anyway, short term, sorry - no patch. Medium/long term, yes it's possible, but please don't rely on it. The simplest way to document it is as you suggest, I think - just extend the qualifier on lookback requiring fixed length to exclude references to groups (it does seem to *bind* groups correctly on lookback, so there's no need to exclude them completely). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9179 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9179] Lookback with group references incorrect (two issues?)
Mark Dickinson dicki...@gmail.com added the comment: I thought someone was working on the re module these days? Well, there's issue 2636. It doesn't seem likely that that work will land in core Python any time soon, though. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9179 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9169] Deprecate use of more than 3 positional arguments in timedelta constructor
Mark Dickinson dicki...@gmail.com added the comment: I supported this idea when Alexander brought it up in IRC. On reflection, I think Antoine is right, though: deprecations aren't something to be done lightly. As a matter of good style, though, I'd still like to see all uses of timedelta in the standard library and documentation use the keywords explicitly: timedelta(minutes=10) is instantly understandable, while timedelta(0, 0, 0, 0, 10) requires some effort to understand (well, on my part, anyway). -- status: pending - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9169 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9169] Deprecate use of more than 3 positional arguments in timedelta constructor
Changes by Mark Dickinson dicki...@gmail.com: -- status: open - pending ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9169 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9180] Memory Error
New submission from Peter Wolf freakcy...@optusnet.com.au: I am using Ubuntu 10.04 32 bit and python 2.6.When I type the following line in a terminal python mydatafile.py I get the following error message on the next line MemoryError That is all. File details : It is a 2d list of floating point numbers 86Mb in size. Here is the start - mydata=[[1.51386,1.51399,1.51386,1.51399], [1.51386,1.51401,1.51401,1.51386], [1.51391,1.51406,1.51395,1.51401], [1.51392,1.514,1.51397,1.51395], [1.51377,1.5142,1.51387,1.51397], here is the end - [1.5631,1.5633,1.5631,1.5631], [1.5631,1.5632,1.5631,1.5631], [1.5631,1.5633,1.5631,1.5631], [1.563,1.5631,1.5631,1.5631]] I will add that exactly the same type of file but 49MB in size compiled with 1GB of ram although there was a lot of disk activity and the CPU seemed to be working very hard.The 86MB file produced the above error.I upgraded to 3.4GB and still the same error. -- components: None messages: 109392 nosy: freakcycle priority: normal severity: normal status: open title: Memory Error type: compile error versions: Python 2.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9180 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9169] Deprecate use of more than 3 positional arguments in timedelta constructor
Alexander Belopolsky belopol...@users.sourceforge.net added the comment: As a matter of good style, though, I'd still like to see all uses of timedelta in the standard library and documentation use the keywords explicitly ... It is a bit of a shame, but there are exactly 3 places using timedelta in stdlib: Lib/_strptime.py:492:tzdelta = datetime_timedelta(seconds=gmtoff) Lib/calendar.py:160:date -= datetime.timedelta(days=days) Lib/calendar.py:161:oneday = datetime.timedelta(days=1) The later two uses of keywords I don't necessarily approve, particularly timedelta(days=days). I find timedelta(n) meaning n days fairly easy to remember. Two arguments, timedelta(days, secs) is borderline. I would approve it if the meaning is clear from context as in MINUTE = timedelta(0, 60) or from the the argument name as in timedelta(0, seconds). I would certainly reject the abominations like FIVE_MINUTES = datetime.timedelta(0, 0, 0, 0, 5) in any code review. I checked datetime.rst and it looks like it only uses positional arguments for timedelta(0), which is pretty uncontroversial and in output displays. -- status: pending - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9169 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9180] Memory Error
Mark Dickinson dicki...@gmail.com added the comment: Thanks for the extra information; that helps a lot. I think this is expected behaviour: Python really does need that much memory to parse the file (as a Python file). Partly this is because Python objects actually do take up a fair amount of space: a length-4 list of floats on my (64-bit) machine takes 200 bytes, though on 32-bit machine this number should be a bit smaller. But partly it's that the compilation stage itself uses a lot of memory: for example, each of the floats in your input gets put into a dict during compilation; this dict is used to recognize multiple references to the same float, so that only one float object needs to be created for each distinct float value. And those dicts are going to get pretty big. I don't think that storing huge amounts of data in a .py file like this is usual practice, so I'm not particularly worried that importing a huge .py file can cause a MemoryError. For your case, I'd suggest parsing your datafile manually: reading the file line by line from within Python. Suggest closing this issue as won't fix. -- nosy: +mark.dickinson ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9180 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9180] Memory Error
Mark Dickinson dicki...@gmail.com added the comment: Just an additional note: have you considered using the pickle or json modules? -- resolution: - wont fix status: open - pending ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9180 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9181] Solaris extension building does not work with 64 bit python
New submission from Charles Solar charlesso...@gmail.com: On solaris, if you build a 64 bit python and use it to build an extension, it will not properly link the module. Apparently solaris requires the -m64 flag in the linker as well as the compile steps. Python distutils successfully compiles all the object files using -m64, but it fails to link with -m64 causing the entire build to fail if the extension needs a 64 bit library dependency ( will get 'incompatible library' errors from the linker ). To reproduce: build python with CFLAGS=-m64 -O3 LDFLAGS=-m64 build a C extension that depends on a 64 bit library (python setup.py install) I assume that it would work if the C extension does not need a specific 64 bit library as the linker will not go and look for the wrong version of file. So its a very uncommon but annoying bug. ld --version GNU ld (GNU Binutils) 2.20.1.20100303 Copyright 2009 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or (at your option) a later version. This program has absolutely no warranty. -- assignee: tarek components: Distutils, Distutils2, Extension Modules messages: 109396 nosy: redcomet, tarek priority: normal severity: normal status: open title: Solaris extension building does not work with 64 bit python type: compile error versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9181 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9000] Provide parseable repr to datetime.timezone
Alexander Belopolsky belopol...@users.sourceforge.net added the comment: I am attaching a python prototype. I am following the convention in place for the other datetime classes of prepending the repr with 'datetime.'. This may not be ideal, but better than to introduce an inconsistency. The only question I think is worth considering is the representation of timezone.utc. I would like to have repr(timezone(timedelta(0))) == 'datetime.timezone.utc' even though currently timezone(timedelta(0)) and timezone.utc are different but equal objects. This is going to change, however. See issue9051. [1] http://bugs.python.org/issue5094#msg106411 -- keywords: +patch Added file: http://bugs.python.org/file17882/issue9000-proto.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9000 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9009] Improve quality of Python/dtoa.c
Mark Dickinson dicki...@gmail.com added the comment: Second version of the strtod rewrite; has some additional documentation and comment fixes. No other significant changes from the first version. This is still a work in progress. -- Added file: http://bugs.python.org/file17883/rewrite_strtod_v2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9009 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9179] Lookback with group references incorrect (two issues?)
Matthew Barnett pyt...@mrabarnett.plus.com added the comment: Should a regex compile if a group is referenced before it's defined? Consider this: (?:(?(2)(a)|(b))+ Other regex implementations permit forward references to groups. BTW, I had a look at the re module, found it too difficult, and so started on my own implementation of the matching engine (available on PyPI). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9179 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9179] Lookback with group references incorrect (two issues?)
andrew cooke and...@acooke.org added the comment: Ah good point, thanks. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9179 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2636] Regexp 2.7 (modifications to current re 2.2.2)
Matthew Barnett pyt...@mrabarnett.plus.com added the comment: I started with trying to modify the existing re module, but I wanted to make too many changes, so in the end I decided to make a clean break and start on a new implementation which was compatible with the existing re module and which could replace the existing implementation, even under the same name. Apart from the recent bug fix, I haven't done any further work since April on it because I think it's pretty much ready. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2636 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9182] argparse: optional argument w/ narg='+' conflicts w/ positional argsument
New submission from Sergey Konoplev gray...@gmail.com:
Hello,
I am starting to use argparse package and faced the problem where an optional
argument w/ nargs='+' conflicts w/ a positional argument.
Here is the test case:
import argparse
p = argparse.ArgumentParser()
p.add_argument('foo', type=str)
_StoreAction(option_strings=[], dest='foo', nargs=None, const=None,
default=None, type=type 'str', choices=None, help=None, metavar=None)
p.add_argument('-b', '--bar', type=int, nargs='+')
_StoreAction(option_strings=['-b', '--bar'], dest='bar', nargs='+', const=None,
default=None, type=type 'int', choices=None, help=None, metavar=None)
p.print_help()
usage: [-h] [-b BAR [BAR ...]] foo
positional arguments:
foo
optional arguments:
-h, --helpshow this help message and exit
-b BAR [BAR ...], --bar BAR [BAR ...]
p.parse_args('-b 123 456 bla'.split())
usage: [-h] [-b BAR [BAR ...]] foo
: error: argument -b/--bar: invalid int value: 'bla'
It prints this usage string usage: [-h] [-b BAR [BAR ...]] foo so it is
assumed that I could use this -b 123 456 bla but it does not works.
How could it be and how to solve it?
Thank you in advance.
--
components: Library (Lib)
messages: 109402
nosy: gray_hemp
priority: normal
severity: normal
status: open
title: argparse: optional argument w/ narg='+' conflicts w/ positional argsument
type: behavior
versions: Python 2.6
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9182
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2636] Regexp 2.7 (modifications to current re 2.2.2)
Ezio Melotti ezio.melo...@gmail.com added the comment: So, if it's pretty much ready, do you think it could be included already in 3.2? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2636 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2636] Regexp 2.7 (modifications to current re 2.2.2)
Brian Curtin cur...@acm.org added the comment: Before anything else is done with it, it should probably be announced in some way. I'm not sure if anyone has opened any of these zip files, reviewed anything, ran anything, or if anyone even knows this whole thing has been going on. -- nosy: +brian.curtin ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2636 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2636] Regexp 2.7 (modifications to current re 2.2.2)
Ezio Melotti ezio.melo...@gmail.com added the comment: Yes, as I said in the previous message it should probably be announced on python-dev and see what the others think. I don't know how much the module has been used in the wild, but since there has been a PyPI package available for a few months now and since people reported here issues I assume someone is using it (however I don't know how many persons and if they used it with real applications or just played around with it). I don't want to rush the things, but if the module is ready I do want to start moving the things forward, so that after all the necessary decisions and reviews it eventually gets merged. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2636 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2636] Regexp 2.7 (modifications to current re 2.2.2)
Matthew Barnett pyt...@mrabarnett.plus.com added the comment: The file at: http://pypi.python.org/pypi/regex was downloaded 75 times, if that's any help. (Now reset to 0 because of the bug fix.) If it's included in 3.2 then there's the question of whether it should replace the re module and be called re. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2636 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2636] Regexp 2.7 (modifications to current re 2.2.2)
Ezio Melotti ezio.melo...@gmail.com added the comment: If it's backward-compatible with the 're' module, all the tests of the test suite pass and it just improves it and add features I don't see why not. (That's just my personal opinion though, other people might (and probably will) disagree.) Try to send an email on python-dev and see what they say. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2636 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2636] Regexp 2.7 (modifications to current re 2.2.2)
Jeffrey C. Jacobs timeho...@users.sourceforge.net added the comment: My only addition opinion is that re is very much used in deployed python applications and was written not just for correctness but also speed. As such, regex should be benchmarked fairly to show that it is commensurately speedy. I wouldn't not personally object to a slightly slower module, though not one that is noticeably slower and if it can be proven faster in the average case, it's one more check in the box for favorable inclusion. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2636 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2636] Regexp 2.7 (modifications to current re 2.2.2)
Vlastimil Brom vlastimil.b...@gmail.com added the comment: Thanks for the prompt fix! It would indeed be nice to see this enhanced re module in the standard library e.g. in 3.2, but I also really appreciate, that also multiple 2.x versions are supported (as my current main usage of this library involves py2-only wx gui). As for the usage statistics, I for one always downloaded the updates from here rather than pypi, but maybe it is not a regular case. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2636 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2636] Regexp 2.7 (modifications to current re 2.2.2)
Georg Brandl ge...@python.org added the comment: FWIW, I'd love seeing the updated regex module in 3.2. Please do bring it up on python-dev. Looking at the latest module on PyPI, I noted that the regex.py file is very long (~3500 lines), even though it is quite compressed (e.g. no blank lines between methods). It would be good to split it up. This would also remove the need for underscore-prefixing most of the identifiers, since they would simply live in another (private) module. Things like the _create_header_file function should be put into utility scripts. The C file is also very long, but I think we all know why :) It would also be nice to see some performance comparisons -- where is the new engine faster, where does it return matches while re just loops forever, and where is the new engine slower? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2636 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9146] Segfault in hashlib in OpenSSL FIPS mode using non-FIPS-compliant hashes, if ssl imported before hashlib
Dave Malcolm dmalc...@redhat.com added the comment:
I'm attaching an updated patch which:
- adds error checking to the various places where EVP_DigestInit is called
- adds a test to test_hashlib to ensure that hashlib still works gracefully
when OPENSSL_FORCE_FIPS_MODE=1 is set in the environment
Note that in this mode:
_hashlib.new('md5')
Traceback (most recent call last):
File stdin, line 1, in module
ValueError: error:060800A0:digital envelope routines:EVP_DigestInit_ex:unknown
cipher
[57670 refs]
but hashlib falls back to using the md5 module instead.
I started writing a test for _hashlib (as opposed to hashlib), but it's too
hard to express a runtime conditional on whether OPENSSL_FORCE_FIPS_MODE will
actually affect the behavior of EVP_DigestInit across the versions of openssl
that might be installed on the system.
I'm still waiting to hear back from the Fedora OpenSSL packager for info on how
to reproduce this on a vanilla OpenSSL.
--
Added file:
http://bugs.python.org/file17884/hashopenssl-fips-mode-errors-v3.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9146
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9182] argparse: optional argument w/ narg='+' conflicts w/ positional argsument
Éric Araujo mer...@netwok.org added the comment: Thanks for the bug report. Can you try separating option arguments from positional arguments with “--”? If yes, this would be a doc bug. Also, can you reproduce it with Python 2.7? -- nosy: +merwok ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9182 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2636] Regexp 2.7 (modifications to current re 2.2.2)
Alex Willmer a...@moreati.org.uk added the comment: On 6 July 2010 18:03, Matthew Barnett rep...@bugs.python.org wrote: The file at http://pypi.python.org/pypi/regex/ was downloaded 75 times, if that's any help. (Now reset to 0 because of the bug fix.) Each release was downloaded between 50 and 100 times. Matthew let me know if you'd like control of the package, or maintainer access. Other than the odd tweet I haven't publicized the releases. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2636 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3461] smtplib does not fully support IPv6 in EHLO
Mark Lawrence breamore...@yahoo.co.uk added the comment: Ran test_smtplib.py for Python 2.7 and 3.1.2 on Windows Vista all tests passed. -- stage: unit test needed - commit review ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3461 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9094] Make python-m pickletools do something useful
Alexander Belopolsky belopol...@users.sourceforge.net added the comment: On the second thought, this is clearly not a bug fix. Not a backport candidate. -- status: pending - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9094 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9009] Improve quality of Python/dtoa.c
Mark Dickinson dicki...@gmail.com added the comment: r82614: add functionality to change FPU rounding mode (via float.__setround__ and float.__getround__ functions), on platforms that support the standard C99 fesetround and fegetround functions: float.__getround__() 'tonearest' 1e300 * 1e300 inf float.__setround__(downward) 1e300 * 1e300 1.7976931348623157e+308 This is just temporary, so that I can test that FPU rounding mode doesn't affect results of string-to-float and float-to-string conversions. I'm not planning to merge any of r82614 back to py3k. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9009 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9163] test_gdb fails
Dave Malcolm dmalc...@redhat.com added the comment:
Deciphering the output from the assertion, the stdout from gdb when running the
test was:
--- BEGIN ---
Breakpoint 1, PyObject_Print (op=42, fp=0x401cf4e0, flags=1) at
Objects/object.c:329
329 {
#3 Frame 0x81e322c, for file
/home/mike/workspace/Python-2.7/Lib/test/gdb_sample.py, line 10, in baz
(args=(1, 2, 3))
print(42)
#7 (unable to read python frame information)
#10 Frame 0x81d5544, for file
/home/mike/workspace/Python-2.7/Lib/test/gdb_sample.py, line 7, in bar (a=1,
b=2, c=3)
baz(a, b, c)
#13 Frame 0x81d53dc, for file
/home/mike/workspace/Python-2.7/Lib/test/gdb_sample.py, line 4, in foo (a=1,
b=2, c=3)
bar(a, b, c)
--- END ---
but the expected output was:
--- BEGIN ---
^.*
#[0-9]+ Frame 0x[0-9a-f]+, for file .*gdb_sample.py, line 7, in bar \(a=1, b=2,
c=3\)
baz\(a, b, c\)
#[0-9]+ Frame 0x[0-9a-f]+, for file .*gdb_sample.py, line 4, in foo \(a=1, b=2,
c=3\)
bar\(a, b, c\)
#[0-9]+ Frame 0x[0-9a-f]+, for file .*gdb_sample.py, line 12, in module \(\)
foo\(1, 2, 3\)
--- END ---
There are various tests named test_basic_command. From the linenumber and
assertion, it's clear that this one is PyBtTests.test_basic_command.
This looks a lot like issue 8482.
What compiler options did you use when building Python?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9163
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9175] ctypes doesn't build on hp-ux
Martin v. Löwis mar...@v.loewis.de added the comment: I don't think ctypes supports acc; try gcc instead. -- nosy: +loewis ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9175 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9176] module termios doesn't build on HP-UX
Martin v. Löwis mar...@v.loewis.de added the comment: Can you provide a patch? -- nosy: +loewis ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9176 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9182] argparse: optional argument w/ narg='+' conflicts w/ positional argsument
Eric Smith e...@trueblade.com added the comment:
I get the same behavior in 2.7. Adding '--', I get:
p.parse_args('-b 123 456 -- bla'.split())
Namespace(bar=[123, 456], foo='bla')
Which is what I expect.
Éric: From your comment, I'm not sure if you think it's a doc bug because '--'
does work, or because it doesn't work without it. But I think it's working as
designed. I'm closing this. If you think it's a doc bug, please reopen and
change to the Documentation component.
--
nosy: +eric.smith
resolution: - invalid
status: open - closed
versions: +Python 2.7
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9182
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9178] Compile problem on HP-UX 11
Martin v. Löwis mar...@v.loewis.de added the comment: Closing the report as third-party bug, then. A compiler crash is most definitely not a bug in Python. -- nosy: +loewis resolution: - invalid status: open - closed versions: +3rd party -Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9178 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3461] smtplib does not fully support IPv6 in EHLO
R. David Murray rdmur...@bitdance.com added the comment: The patch still needs unit tests. -- nosy: +r.david.murray stage: commit review - unit test needed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3461 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9182] argparse: optional argument w/ narg='+' conflicts w/ positional argsument
Éric Araujo mer...@netwok.org added the comment: I was suggesting a doc bug only if the current doc didn’t advertise clearly this way of combining nargs with positional arguments. Using “--” is most certainly standard and right, Using “--” to explicitly signal positional arguments is most certainly right and standard, but people have to read about that for the first time somewhere. In a perfect world, that would be in their shell’s man page, but better add a word about it in the reference. The “--” marker is actually mentioned in one section: http://docs.python.org/dev/library/argparse#arguments-containing I’m reopening, suggesting that a line be added to explain the standard “--” separator for use cases like Sergey’s. -- assignee: - d...@python components: +Documentation -Library (Lib) nosy: +d...@python resolution: invalid - stage: - needs patch status: closed - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9182 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8605] test_gdb can fail with compiler opts
Dave Malcolm dmalc...@redhat.com added the comment: Thanks. The patch looks good to me, and appears to also fix issue 8482 and issue 9163: compiler optimization across all different compilers and configurations can somewhat arbitrarily break the ability for the debugger to work, and skipping the test in the face of optimization seems the sanest course of action. Minor nit: given that final_opt is set to at the start of the loop, the first conditional in: if final_opt and final_opt != '-O0': appears to be redundant. Setting Stage to commit review - I'd commit it (modulo the above nit), but I don't have rights to do so; looking for a committer to review this. -- stage: needs patch - commit review ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8605 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9182] argparse: optional argument w/ narg='+' conflicts w/ positional argsument
Éric Araujo mer...@netwok.org added the comment: Duh, please ignore the first two lines, I forgot to remove them after rephrasing my comment. Sorry. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9182 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9182] argparse: optional argument w/ narg='+' conflicts w/ positional argsument
Fred L. Drake, Jr. fdr...@acm.org added the comment: On Tue, Jul 6, 2010 at 4:33 PM, Éric Araujo rep...@bugs.python.org wrote: Using “--” to explicitly signal positional arguments is most certainly right and standard, but people have to read about that for the first time somewhere. In a perfect world, that would be in their shell’s man page, but better add a word about it in the reference. It's a convention; not all applications in the larger world support it at all. It needs to be documented for argparse, and also for specific applications (which may or may not be built using argparse or Python. This does not belong in the shell documentation unless needed for the shell itself. -- nosy: +fdrake ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9182 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9182] document “--” as a way to disti nguish option w/ narg='+' from positional argument in arg parse
Éric Araujo mer...@netwok.org added the comment: I always forget that not all programs follow getopt-style parsing rules, thanks for the reminder. -- keywords: +easy resolution: - accepted title: argparse: optional argument w/ narg='+' conflicts w/ positional argsument - document “--” as a way to distinguish option w/ narg='+' from positional argument in argparse ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9182 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9163] test_gdb fails
Michael Blume blume.m...@gmail.com added the comment: The commands I issued to build were just ./configure make make install These machines were both fairly vanilla setups, so I don't think there should have been any strange flags going to the compiler. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9163 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9163] test_gdb fails
Michael Blume blume.m...@gmail.com added the comment: -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -IInclude -I./Include -DPy_BUILD_CORE -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9163 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9182] document “--” as a way to disti nguish option w/ narg='+' from positional argument in arg parse
Sergey Konoplev gray...@gmail.com added the comment: Thank you for the hint. It is realy not so obvious. May be it is worth to add -- into the usage string this way usage: [-h] [-b BAR [BAR ...]] -- foo Otherwise it leads to misunderstanding. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9182 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9183] Intern UTC timezone
New submission from Alexander Belopolsky belopol...@users.sourceforge.net:
Attached patch makes timezone(timedelta(0)) always return the same instance as
timezone.utc. See issue9051 for pure python implementation.
With this patch, manipulation of aware datetime objects will be as efficient as
that of naive datetime objects. Note that having timezone.utc is not enough to
assure that the same tzinfo object is used because aware objects can be
produced by datetime.strptime(). With this patch,
datetime.strptime('2010-07-06 21:39:55 +', %Y-%m-%d %H:%M:%S
%z).tzinfo is timezone.utc
True
--
assignee: belopolsky
components: Extension Modules
files: intern-utc.diff
keywords: easy, patch
messages: 109432
nosy: belopolsky, mark.dickinson
priority: normal
severity: normal
stage: commit review
status: open
title: Intern UTC timezone
type: resource usage
versions: Python 3.2
Added file: http://bugs.python.org/file17885/intern-utc.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9183
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9163] test_gdb fails
Dave Malcolm dmalc...@redhat.com added the comment: Thanks for the info. The final optimization option passed to gcc is the -O3, so the build was done with optimization. It's not going to be possible to determine if and when gdb will be able to work in an optimized build across all different compilers and configurations. Issue 8605 has a patch to skip test_gdb if optimization was present in the compilation flags, and I think we should apply it. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9163 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1745] Backport of PEP 3102 keyword-only arguments to 2.6
Alexandre Vassalotti alexan...@peadrop.com added the comment: Now, that 2.7 is out we won't able to commit this anymore. It is sad to abandon a good patch like this. -- resolution: - wont fix stage: patch review - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1745 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9000] Provide parseable repr to datetime.timezone
Alexander Belopolsky belopol...@users.sourceforge.net added the comment: Attaching a C patch. -- resolution: - accepted stage: unit test needed - commit review Added file: http://bugs.python.org/file17887/issue9000.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9000 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2570] backport 3.0-style \u/\U processing in raw strings when unicode_literals is imported from __future__
Alexandre Vassalotti alexan...@peadrop.com added the comment: Closing this since Python 2.7 is out now. -- nosy: +alexandre.vassalotti resolution: - wont fix stage: needs patch - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2570 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9000] Provide parseable repr to datetime.timezone
Alexander Belopolsky belopol...@users.sourceforge.net added the comment: Replacing the patch. The previously attached patch reverted issue9051 a bit too aggressively. -- Added file: http://bugs.python.org/file17888/issue9000.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9000 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9000] Provide parseable repr to datetime.timezone
Changes by Alexander Belopolsky belopol...@users.sourceforge.net: Removed file: http://bugs.python.org/file17887/issue9000.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9000 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2570] backport 3.0-style \u/\U processing in raw strings when unicode_literals is imported from __future__
Ezio Melotti ezio.melo...@gmail.com added the comment: Isn't this a bug that could be fixed in 2.7.1? -- nosy: +ezio.melotti ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2570 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7716] IPv6 detection, don't assume existence of /usr/xpg4/bin/grep
Mark Lawrence breamore...@yahoo.co.uk added the comment: This is a miniscule patch to configure.in could someone please run with this. -- nosy: +BreamoreBoy ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7716 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7576] Avoid warnings in PyModuleDef_HEAD_INIT
Mark Lawrence breamore...@yahoo.co.uk added the comment: This is a miniscule patch to moduleobject.h could someone with the relevant knowledge please review it, thanks. -- nosy: +BreamoreBoy ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7576 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2986] difflib.SequenceMatcher not matching long sequences
Terry J. Reedy tjre...@udel.edu added the comment:
[Also posted to pydev for additional input, with Subject line
Issue 2986: difflib.SequenceMatcher is partly broken
Developed with input from Eli Bendersky, who will write patchfile(s) for
whichever change option is chosen.]
Summary: difflib.SeqeunceMatcher was developed, documented, and originally
operated as a flexible class for comparing pairs of sequences of any
[hashable] type. An experimental heuristic was added in 2.3a1 to speed up
its application to sequences of code lines, which are selected from an
unbounded set of possibilities. As explained below, this heuristic partly to
completely disables SequenceMatcher for realistic-length sequences from a small
finite alphabet. The regression is easy to fix. The docs were never changed to
reflect the effect of the heuristic, but should be, with whatever additional
change is made.
In the commit message for revision 26661, which added the heuristic, Tim Peters
wrote While I like what I've seen of the effects so far, I still consider this
experimental. Please give it a try! Several people who have tried it
discovered the problem with small alphabets and posted to the tracker. Issues
#1528074, #1678339. #1678345, and #4622 are now-closed duplicates of #2986. The
heuristic needs revision.
Open questions (discussed after the examples): what exactly to do, which
versions to do it too, and who will do it.
---
Some minimal difference examples:
from difflib import SequenceMatcher as SM
# base example
print(SM(None, 'x' + 'y'*199, 'y'*199).ratio())
# should be and is 0.9975 (rounded)
# make 'y' junk
print(SM(lambda c:c=='y', 'x' + 'y'*199, 'y'*199).ratio())
# should be and is 0.0
# Increment b by 1 char
print(SM(None, 'x' + 'y'*199, 'y'*200).ratio())
# should be .995, but now is 0.0 because y is treated as junk
# Reverse a and b, which increments b
print(SM(None, 'y'*199, 'x' + 'y'*199).ratio())
# should be .9975, as before, but now is 0.0 because y is junked
The reason for the bug is the heuristic: if the second sequence is at least 200
items long then any item occurring more than one percent of the time in the
second sequence is treated as junk. This was aimed at recurring code lines like
'else:' and 'return', but can be fatal for small alphabets where common items
are necessary content.
A more realistic example than the above is comparing DNA gene sequences.
Without the heuristic SequenceMatcher.get_opcodes() reports an appropriate
sequence of matches and edits and .ratio works as documented and expected. For
1000/2000/6000 bases, the times on a old Athlon 2800 machine are 1/2/12
seconds. Since 6000 is longer than most genes, this is a realistic and
practical use.
With the heuristic, everything is junk and there is only one match, ''==''
augmented by the initial prefix of matching bases. This is followed by one
edit: replace the rest of the first sequence with the rest of the second
sequence. A much faster way to find the first mismatch would be
i = 0
while first[i] == second[i]:
i+=1
The match ratio, based on the initial matching prefix only, is spuriously low.
---
Questions:
1: what change should be make.
Proposed fix: Disentangle the heuristic from the calculation of the internal
b2j dict that maps items to indexes in the second sequence b. Only apply the
heuristic (or not) afterward.
Version A: Modify the heuristic to only eliminate common items when there are
more than, say, 100 items (when len(b2j) 100 where b2j is first calculated
without popularity deletions).
The would leave DNA, protein, and printable ascii+[\n\r\t] sequences alone. On
the other hand, realistic sequences of more than 200 code lines should have at
least 100 different lines, and so the heuristic should continue to be applied
when it (mostly?) 'should' be. This change leaves the API unchanged and does
not require a user decision.
Version B: add a parameter to .__init__ to make the heuristic optional. If the
default were True ('use it'), then the code would run the same as now (even
when bad). With the heuristic turned off, users would be able to get the .ratio
they may expect and need. On the other hand, users would have to understand the
heuristic to know when and when not to use it.
Version C: A more radical alternative would be to make one or more of the
tuning parameters user settable, with one setting turning it off.
2. What type of issue is this, and what version get changed.
I see the proposal as partial reversion of a change that sometimes causes a
regression, in order to fix the regression. Such would usually be called a
bugfix. Other tracker reviewers claim this issue is a feature request, not a
bugfix. Either way, 3.2 gets the fix. The practical issue is whether at least
2.7(.1) should get the fix, or whether the bug should forever continue in 2.x.
3. Who will make the change.
Eli will write a patch and I will check it. However, Georg Brandel
[issue9000] Provide parseable repr to datetime.timezone
Alexander Belopolsky belopol...@users.sourceforge.net added the comment: Committed in r82617. Python version committed to sandbox in r82616. -- stage: commit review - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9000 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9183] Intern UTC timezone
Alexander Belopolsky belopol...@users.sourceforge.net added the comment: Python implementation of UTC interning can be done better than the one in issue9051. See attached issue9183-proto.diff. -- Added file: http://bugs.python.org/file17889/issue9183-proto.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9183 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8413] String interpolation doesn't work with sys.version_info
Benjamin Peterson benja...@python.org added the comment: Here's a patch. It makes structseq a subclass of tuple and along the way deletes tons of code. Please review. -- assignee: eric.smith - benjamin.peterson keywords: +patch Added file: http://bugs.python.org/file17890/structseq-inheritance.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8413 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2570] backport 3.0-style \u/\U processing in raw strings when unicode_literals is imported from __future__
Alexandre Vassalotti alexan...@peadrop.com added the comment: Actually, you are right. This could be added as bug fix. -- resolution: wont fix - stage: committed/rejected - needs patch status: closed - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2570 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2636] Regexp 2.7 (modifications to current re 2.2.2)
Matthew Barnett pyt...@mrabarnett.plus.com added the comment: As a crude guide of the speed difference, here's Python 2.6: re regex bm_regex_compile.py 86.53secs 260.19secs bm_regex_effbot.py 13.70secs8.94secs bm_regex_v8.py 15.66secs9.09secs Note that compiling regexes is a lot slower. I concentrated my efforts on the matching speed because regexes tend to be compiled only once, so it's not as important. Matching speed should _at worst_ be comparable. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2636 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4080] pyunit - display time of each test case - patch
Ezio Melotti ezio.melo...@gmail.com added the comment: The idea is interesting, but I would prefer to have a way to enable/disable this feature (and maybe even specify its format, e.g. the number of decimals). Moving the logic to an external function (possibly used as a decorator) might avoid some code duplication, but OTOH it would probably slow down the execution and the timing a little (I'm not sure that matters though). -- nosy: +ezio.melotti stage: unit test needed - patch review versions: -3rd party, Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4080 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4388] test_cmd_line fails on MacOS X
Changes by Daniele Varrazzo p...@develer.com: -- nosy: +piro ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4388 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8775] Use locale encoding to encode command line arguments (subprocess, os.exec*(), etc.)
Changes by Daniele Varrazzo p...@develer.com: -- nosy: +piro ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8775 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2986] difflib.SequenceMatcher not matching long sequences
Eli Bendersky eli...@gmail.com added the comment:
Thanks!
Now let's see what the other devs say. The first response seems not to have
understood what you meant completely :-)
Eli
On Wed, Jul 7, 2010 at 01:18, Terry J. Reedy rep...@bugs.python.org wrote:
Terry J. Reedy tjre...@udel.edu added the comment:
[Also posted to pydev for additional input, with Subject line
Issue 2986: difflib.SequenceMatcher is partly broken
Developed with input from Eli Bendersky, who will write patchfile(s) for
whichever change option is chosen.]
Summary: difflib.SeqeunceMatcher was developed, documented, and originally
operated as a flexible class for comparing pairs of sequences of any
[hashable] type. An experimental heuristic was added in 2.3a1 to speed up
its application to sequences of code lines, which are selected from an
unbounded set of possibilities. As explained below, this heuristic partly to
completely disables SequenceMatcher for realistic-length sequences from a
small finite alphabet. The regression is easy to fix. The docs were never
changed to reflect the effect of the heuristic, but should be, with whatever
additional change is made.
In the commit message for revision 26661, which added the heuristic, Tim
Peters wrote While I like what I've seen of the effects so far, I still
consider this experimental. Please give it a try! Several people who have
tried it discovered the problem with small alphabets and posted to the
tracker. Issues #1528074, #1678339. #1678345, and #4622 are now-closed
duplicates of #2986. The heuristic needs revision.
Open questions (discussed after the examples): what exactly to do, which
versions to do it too, and who will do it.
---
Some minimal difference examples:
from difflib import SequenceMatcher as SM
# base example
print(SM(None, 'x' + 'y'*199, 'y'*199).ratio())
# should be and is 0.9975 (rounded)
# make 'y' junk
print(SM(lambda c:c=='y', 'x' + 'y'*199, 'y'*199).ratio())
# should be and is 0.0
# Increment b by 1 char
print(SM(None, 'x' + 'y'*199, 'y'*200).ratio())
# should be .995, but now is 0.0 because y is treated as junk
# Reverse a and b, which increments b
print(SM(None, 'y'*199, 'x' + 'y'*199).ratio())
# should be .9975, as before, but now is 0.0 because y is junked
The reason for the bug is the heuristic: if the second sequence is at least
200 items long then any item occurring more than one percent of the time in
the second sequence is treated as junk. This was aimed at recurring code
lines like 'else:' and 'return', but can be fatal for small alphabets where
common items are necessary content.
A more realistic example than the above is comparing DNA gene sequences.
Without the heuristic SequenceMatcher.get_opcodes() reports an appropriate
sequence of matches and edits and .ratio works as documented and expected.
For 1000/2000/6000 bases, the times on a old Athlon 2800 machine are
1/2/12 seconds. Since 6000 is longer than most genes, this is a realistic
and practical use.
With the heuristic, everything is junk and there is only one match, ''==''
augmented by the initial prefix of matching bases. This is followed by one
edit: replace the rest of the first sequence with the rest of the second
sequence. A much faster way to find the first mismatch would be
i = 0
while first[i] == second[i]:
i+=1
The match ratio, based on the initial matching prefix only, is spuriously
low.
---
Questions:
1: what change should be make.
Proposed fix: Disentangle the heuristic from the calculation of the
internal b2j dict that maps items to indexes in the second sequence b. Only
apply the heuristic (or not) afterward.
Version A: Modify the heuristic to only eliminate common items when there
are more than, say, 100 items (when len(b2j) 100 where b2j is first
calculated without popularity deletions).
The would leave DNA, protein, and printable ascii+[\n\r\t] sequences alone.
On the other hand, realistic sequences of more than 200 code lines should
have at least 100 different lines, and so the heuristic should continue to
be applied when it (mostly?) 'should' be. This change leaves the API
unchanged and does not require a user decision.
Version B: add a parameter to .__init__ to make the heuristic optional. If
the default were True ('use it'), then the code would run the same as now
(even when bad). With the heuristic turned off, users would be able to get
the .ratio they may expect and need. On the other hand, users would have to
understand the heuristic to know when and when not to use it.
Version C: A more radical alternative would be to make one or more of the
tuning parameters user settable, with one setting turning it off.
2. What type of issue is this, and what version get changed.
I see the proposal as partial reversion of a change that sometimes causes a
regression, in order to fix the regression. Such would usually be called a
bugfix. Other tracker reviewers claim this
[issue2986] difflib.SequenceMatcher not matching long sequences
Changes by Eli Bendersky eli...@gmail.com: Removed file: http://bugs.python.org/file17891/unnamed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2986 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2986] difflib.SequenceMatcher not matching long sequences
Eli Bendersky eli...@gmail.com added the comment: I apologize for the previous message. It was created by mistake - by replying to Terry's mail which came from the bugtracker. I wish I knew how to remove it from here - is this possible and I'm missing the relevant priveleges? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2986 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9146] Segfault in hashlib in OpenSSL FIPS mode using non-FIPS-compliant hashes, if ssl imported before hashlib
Gregory P. Smith g...@krypto.org added the comment: I'm pretty sure Python setup.py does not build the non-openssl md5, sha1, sha256 and sha512 extension modules at all when openssl is present. So falling back on them is not likely to work unless anyone who wants this crazy force fips mode thing to not prevent them from existing in Python goes to the extra effort to compile them. -- nosy: +gregory.p.smith ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9146 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9146] Segfault in hashlib in OpenSSL FIPS mode using non-FIPS-compliant hashes, if ssl imported before hashlib
Changes by Gregory P. Smith g...@krypto.org: -- nosy: -gps ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9146 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9063] TZ examples in datetime.rst are incorrect
Alexander Belopolsky belopol...@users.sourceforge.net added the comment: There is nothing we can do about misreporting of UTC offset. Unlike time tuples, datetime objects do not store the DST flag and thus have no means to disambiguate between standard and DST during the hour after the clock is set back for DST to standard transition. Nevertheless, dt = datetime.fromtimestamp(t) is a well defined operation, it is dt.dst() and dt.utcoffset() which are not so well defined. According to the comment at the end of Modules/datetimemodule.c, in order for the default implementation of tzinfo.fromutc() to operate correctly, the concrete implementation of tzinfo.dst(dt) must treat dt that falls into the ambiguous hour (where it can be ether DST or standard time) as the standard time. This is precisely what is done in the implementation of USTimeZone class. The Local class, however, relies on mktime to choose between DST and standard and apparently, at least on OSX, mktime does not do what Python's tzinfo.fromutc() expects. The attached patch for Doc/includes/tzinfo-examples.py fixes this problem by passing is_dst=0 instead of -1 to mktime and also adds __repr__ to LocalTimezone class. With this patch, x = datetime(2010, 11, 7, 5) s = (x - datetime(1970, 1, 1))//timedelta(seconds=1) for i in range(-3600, 5000, 3600): ... datetime.fromtimestamp(s + i, Local) ... datetime.datetime(2010, 11, 7, 0, 0, tzinfo=EST/EDT) datetime.datetime(2010, 11, 7, 1, 0, tzinfo=EST/EDT) datetime.datetime(2010, 11, 7, 1, 0, tzinfo=EST/EDT) which is correct and consistent with Easter timezone: for i in range(-3600, 5000, 3600): ... datetime.fromtimestamp(s + i, Eastern) ... datetime.datetime(2010, 11, 7, 0, 0, tzinfo=Eastern) datetime.datetime(2010, 11, 7, 1, 0, tzinfo=Eastern) datetime.datetime(2010, 11, 7, 1, 0, tzinfo=Eastern) -- keywords: +patch nosy: +mark.dickinson stage: needs patch - commit review type: - behavior Added file: http://bugs.python.org/file17892/issue9063.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9063 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
