[issue25708] runpy hides traceback for some exceptions
New submission from Cal Leeming: Originally posted here: http://stackoverflow.com/q/33873243/1267398 The problem is caused by this line: # For -m switch, just display the exception info = str(exc) Caused by the following commit in 2008; https://mail.python.org/pipermail/python-checkins/2008-February/066256.html The commit states; "Try to make command line error messages from runpy easier to understand (and suppress traceback cruft from the implicitly invoked runpy machinery)" However by suppressing the traceback it's now impossible to debug what caused the error when running with `runpy` without wrapping the entire `__init__.py` with your own try/except statement. I'd like to propose either displaying the full traceback by default, or adding a CLI option to enable it at runtime. The fact that it only suppresses *some* tracebacks and not all is a flawed approach surely? Thoughts? -- components: Interpreter Core messages: 255169 nosy: ncoghlan, sleepycal priority: normal severity: normal status: open title: runpy hides traceback for some exceptions type: behavior versions: Python 3.4 ___ Python tracker <http://bugs.python.org/issue25708> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24922] assertWarnsRegex doesn't allow multiple warning messages
New submission from Cal Leeming: There was a discussion/patch in #9754 [1]. This allows for multiple warning types as a tuple, e.g.; self.assertWarnsRegex((DeprecationWarning, RuntimeWarning), "^E1000:") However, it does not allow testing for multiple warning messages, e.g.; expect = ((UserWarning, "^W1000"), (UserWarning, "^W1001")) self.assertWarnsRegex(*expect) This is slightly unexpected, as `test.support.check_warnings` allows this behaviour, e.g. expect = ((UserWarning, "^W1000"), (UserWarning, "^W1001")) check_warnings(*expect) Therefore I am proposing that `assertWarnsRegex` and `assertWarns` are modified to reflect the behaviour of `check_warnings`, whilst ensuring backwards compatibility. (e.g. if arg[0] is tuple, use new approach, otherwise use old approach). [1]: http://bugs.python.org/issue9754 -- components: Interpreter Core messages: 249048 nosy: sleepycal priority: normal severity: normal status: open title: assertWarnsRegex doesn't allow multiple warning messages type: behavior versions: Python 3.4 ___ Python tracker <http://bugs.python.org/issue24922> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24887] Sqlite3 has no option to provide open flags
New submission from Cal Leeming: There are several flags which can be provided to Sqlite3 during connection [1]. Alternative libraries such as apsw provide the ability to use these flags [2], however it would be nice if `sqlite3` supported this out of the box. Is there any reason why the wrapper for `sqlite3` does not allow flags to be passed in? If not, can we add it? [1]: https://www.sqlite.org/c3ref/open.html [2]: https://github.com/rogerbinns/apsw/blob/master/example-code.py#L466 -- components: Library (Lib) messages: 248770 nosy: sleepycal priority: normal severity: normal status: open title: Sqlite3 has no option to provide open flags versions: Python 3.4 ___ Python tracker <http://bugs.python.org/issue24887> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24744] Lack of type checks in pkgutil.walk_packages and friends
New submission from Cal Leeming: The documentation states that pkgutil.walk_packages() path must be None or a list of paths [1]. After passing in a string, the result was a blank list rather than a type error or automatic conversion to a list. If this method is documented that it must only accept a list or None, then there should surely be type checks to this effect? This was a bit of a gotcha that left me head scratching for 30 minutes (after not realising it only took a list, not an str, which in itself seems a bit odd) -- components: Interpreter Core messages: 247529 nosy: sleepycal priority: normal severity: normal status: open title: Lack of type checks in pkgutil.walk_packages and friends versions: Python 3.4 ___ Python tracker <http://bugs.python.org/issue24744> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16379] SQLite error code not exposed to python
Cal Leeming added the comment: Any update on this? Still seems to be a problem as of 3.4.0. -- nosy: +sleepycal ___ Python tracker <http://bugs.python.org/issue16379> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16609] float loses precision when passed to str()
Changes by Cal Leeming : -- status: open -> pending ___ Python tracker <http://bugs.python.org/issue16609> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16609] float loses precision when passed to str()
Cal Leeming added the comment: Actually, you do have a good point, this should have been using random.getrandbits really. -- status: pending -> open ___ Python tracker <http://bugs.python.org/issue16609> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16609] random.random() / float() loses precision when passed to str()
Cal Leeming added the comment: Many thanks for your lengthy response David. Sorry, my initial bug report stated it was Python 2.7. The tests I performed were actually on Python 2.6.6. I will take a look at how to contribute documentation updates, and once I've familiarized myself with it I'll submit a patch for review. Thanks again -- ___ Python tracker <http://bugs.python.org/issue16609> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16609] random.random() / float() loses precision when passed to str()
Cal Leeming added the comment: Normally I would concur, but casting random.random() to a string is commonly used, and people aren't going to read the entire floating point arithmetic page to figure this out. And even if they do, that page still doesn't make it entirely obvious at first read. Hopefully if anyone else is caught out by this, then they will see this thread at least :X -- ___ Python tracker <http://bugs.python.org/issue16609> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16609] random.random() / float() loses precision when passed to str()
Cal Leeming added the comment: As stated before, I have already read this document. This ticket is specifically about making users aware of this behaviour in the form of a documentation update on the random.random() docs. The link you provided does not exactly make this very clear. -- resolution: invalid -> status: pending -> open ___ Python tracker <http://bugs.python.org/issue16609> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16609] random.random() / float() loses precision when passed to str()
New submission from Cal Leeming: Hello, Today I came up against a strange problem where collisions were being encountered after less than 1mil iterations when attempting to use random.random(). After much digging, the problem was because I was casting my float to a string, and this was automatically rounding it. Some explanation is given [1], but it still leaves me with questions. >>> import random >>> random.random() 0.33885573194811902 >>> x = random.random() >>> x 0.88022393777095409 >>> print x 0.880223937771 >>> str(x) '0.880223937771' >>> print str(x) 0.880223937771 >>> repr(x) '0.88022393777095409' >>> str(repr(x)) '0.88022393777095409' After painstakingly searching through documentation (including the lengthy one about floating points arithmetic), I was unable to find any explanation behind why the float is automatically rounded if str() is called on it. Although I doubt this behavior would ever be changed, it would be nice to update the documentation to reflect this. I'm thinking a note underneath random.random() explaining that you have to use repr() and not str() in order to maintain floating point precision. Thoughts? Cal [1] http://stackoverflow.com/questions/3481289/converting-a-python-float-to-a-string-without-losing-precision -- components: Interpreter Core messages: 176930 nosy: sleepycal priority: normal severity: normal status: open title: random.random() / float() loses precision when passed to str() versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue16609> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15407] CSV parser fails to iterate properly on 2.6.6
Cal Leeming added the comment: @david Gotcha - I had a feeling that would be the case. Thank you for the quick replies anyway guys! Hopefully this will help others in the future :) -- ___ Python tracker <http://bugs.python.org/issue15407> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15407] CSV parser fails to iterate properly on 2.6.6
Cal Leeming added the comment: Okay, just found the reason for this.. It's because I was putting a .read() on the file descriptor.. I really think that the CSVReader should raise an assertion in the event that it is passed an object which has no iterator, or if it is given a string, as this is a fairly easy mistake to make. -- ___ Python tracker <http://bugs.python.org/issue15407> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15407] CSV parser fails to iterate properly on 2.6.6
Cal Leeming added the comment: This bug also seems to be showing in 2.7.3 -- ___ Python tracker <http://bugs.python.org/issue15407> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15407] CSV parser fails to iterate properly on 2.6.6
Cal Leeming added the comment: Sorry, accidently pasted the wrong code snippet previously. The correct code snippet is: datx = open("data.txt", "rb").read() rows = csv.reader( datx ) for row in rows: print x -- ___ Python tracker <http://bugs.python.org/issue15407> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15407] CSV parser fails to iterate properly on 2.6.6
New submission from Cal Leeming : Getting some extremely strange behavior when attempting to parse a fairly standard CSV in Python 2.6.6. I've tried a whole different mixture of dialects, quoting options, line terminators etc, and none seem to get a happy ending. Spent about 2 hours banging my head against a brick wall on this, and struggling to see how the CSV libs could be so fundamentally broken, given that I couldn't find any other related bugs. I have attempted to parse the following CSV data: "First","Middle","Last","Nickname","Email","Category" "Moe","","Howard","Moe","m...@3stooges.com","actor" "Jerome","Lester","Howard","Curly","cu...@3stooges.com","actor" "Larry","","Fine","Larry","la...@3stooges.com","musician" "Jerome","","Besser","Joe","j...@3stooges.com","actor" "Joe","","DeRita","CurlyJoe","curly...@3stooges.com","actor" "Shemp","","Howard","Shemp","sh...@3stooges.com","actor" The code used to parse was this: datx = open("data.txt", "rb").read() rows = csv.reader( datx , dialect="wat") for row in rows: print x The output given is this: ['First'] ['', ''] ['Middle'] ['', ''] ['Last'] ['', ''] ['Nickname'] ['', ''] ['Email'] ['', ''] ['Category'] [] ['Moe'] ['', ''] [''] ['', ''] ['Howard'] ['', ''] ['Moe'] ['', ''] ['m...@3stooges.com'] ['', ''] ['actor'] [] ['Jerome'] ['', ''] ['Lester'] ['', ''] ['Howard'] ['', ''] ['Curly'] ['', ''] ['cu...@3stooges.com'] ['', ''] ['actor'] [] ['Larry'] ['', ''] [''] ['', ''] ['Fine'] ['', ''] ['Larry'] ['', ''] ['la...@3stooges.com'] ['', ''] ['musician'] [] ['Jerome'] ['', ''] [''] ['', ''] ['Besser'] ['', ''] ['Joe'] ['', ''] ['j...@3stooges.com'] ['', ''] ['actor'] [] ['Joe'] ['', ''] [''] ['', ''] ['DeRita'] ['', ''] ['CurlyJoe'] ['', ''] ['curly...@3stooges.com'] ['', ''] ['actor'] [] ['Shemp'] ['', ''] [''] ['', ''] ['Howard'] ['', ''] ['Shemp'] ['', ''] ['sh...@3stooges.com'] ['', ''] ['actor'] [] -- components: None messages: 165938 nosy: sleepycal priority: normal severity: normal status: open title: CSV parser fails to iterate properly on 2.6.6 versions: Python 2.6 ___ Python tracker <http://bugs.python.org/issue15407> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13095] Support for splitting lists/tuples into chunks
Cal Leeming added the comment: Oh - and while we are at it - how about having merge_list() and unique_list() as part of the core too?? def unique_list(seq): # Dave Kirby # Order preserving seen = set() return [x for x in seq if x not in seen and not seen.add(x)] def merge_list(seq): merged = [] for s in seq: for x in s: merged.append(x) return merged Raymond - any thoughts on these 3 requests??? Cal -- ___ Python tracker <http://bugs.python.org/issue13095> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13095] Support for splitting lists/tuples into chunks
New submission from Cal Leeming : After a while of digging around, I noticed that the core libs don't provide an easy way of splitting a list/tuple into chunks - as per the following discussion: http://www.aspwinhost.com/In-what-way-do-you-split-an-list-into-evenly-sized-chunks-on-Python/ Therefore, I'd like to +1 feature request this. Any thoughts?? Cal -- components: Library (Lib) messages: 144831 nosy: sleepycal priority: normal severity: normal status: open title: Support for splitting lists/tuples into chunks type: feature request ___ Python tracker <http://bugs.python.org/issue13095> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12455] urllib2 forces title() on header names, breaking some requests
Cal Leeming added the comment: Thats full understandable that the default won't change. I'll put this in my todo list to write a patch in a week or two. On 1 Jul 2011 08:45, "R. David Murray" wrote: > > R. David Murray added the comment: > > Quoting http://tools.ietf.org/html/rfc2068#section-4.2: > > Field names are case-insensitive. > > Which is only logical, since they are modeled on email headers, and email header names are case insensitive. So, the server in question is broken, yes, but that doesn't mean we can't provide a facility to allow Python to inter-operate with it. Email, for example, preserves the case of the field names it parses or receives from the application program, but otherwise treats them case-insensitively. However, since the current code coerces to title case, we have to provide this feature as a switchable facility defaulting to the current behavior, for backward compatibility reasons. > > And someone needs to write a patch > > -- > > ___ > Python tracker > <http://bugs.python.org/issue12455> > ___ -- nosy: +sleepycal Added file: http://bugs.python.org/file22537/unnamed ___ Python tracker <http://bugs.python.org/issue12455> ___Thats full understandable that the default won't change. I'll put this in my todo list to write a patch in a week or two. On 1 Jul 2011 08:45, "R. David Murray" <mailto:rep...@bugs.python.org";>rep...@bugs.python.org> wrote:> > R. David Murray <mailto:rdmur...@bitdance.com";>rdmur...@bitdance.com> added the comment: > > Quoting http://tools.ietf.org/html/rfc2068#section-4.2";>http://tools.ietf.org/html/rfc2068#section-4.2:> > Field names are case-insensitive.> > Which is only logical, since they are modeled on email headers, and email header names are case insensitive. So, the server in question is broken, yes, but that doesn't mean we can't provide a facility to allow Python to inter-operate with it. Email, for example, preserves the case of the field names it parses or receives from the application program, but otherwise treats them case-insensitively. However, since the current code coerces to title case, we have to provide this feature as a switchable facility defaulting to the current behavior, for backward compatibility reasons. > > And someone needs to write a patch> > --> > ___> Python tracker <mailto:rep...@bugs.python.org";>rep...@bugs.python.org> > <http://bugs.python.org/issue12455";>http://bugs.python.org/issue12455>> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12455] urllib2 forces title() on header names, breaking some requests
Cal Leeming added the comment: Damn 3.3 huh? Ah well, at least it's in the pipeline ^_^ Thanks for your help on this @r.david.murray! -- ___ Python tracker <http://bugs.python.org/issue12455> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12455] urllib2 Request() forces capitalize() on header names, breaking some requests
Cal Leeming added the comment: So @r.david.murray, it would appear you were right :D Really, I should have looped through each method on str(), and wrapped them all to see which were being called, but lesson learned I guess. Sooo, I guess now the question is, can we possibly get a vote on having a feature which disables this functionality from the opener level. Something like: opener = urllib2.build_opener(urllib2.HTTPHandler(debuglevel=1, keep_original_header_case=True)) But obviously a less tedious attribute name :) In the mean times, if anyone else comes up against this problem, the code I pasted above will work fine for now. Cal -- ___ Python tracker <http://bugs.python.org/issue12455> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12455] urllib2 Request() forces capitalize() on header names, breaking some requests
Cal Leeming added the comment: (short answer, I found the cause, and a suitable monkey patch) - below are details of how I did it and steps I took. - Okay so I forked AbstractHTTPHandler() then patched do_request_(), at which point "request.headers" and request.header_items() have the correct header name (Content-MD5). So I tried this: opener = urllib2.build_opener(urllib2.HTTPHandler(debuglevel=1)) opener.addheaders = [("Content-TE5", 'test'), ] However the headers came back capitalized, so the problem is happening somewhere after addheaders. > grep -R "addheaders" *.py urllib.py:self.addheaders = [('User-Agent', self.version)] urllib.py:self.addheaders.append(args) urllib.py:for args in self.addheaders: h.putheader(*args) urllib.py:for args in self.addheaders: h.putheader(*args) urllib2.py:self.addheaders = [('User-agent', client_version)] urllib2.py:for name, value in self.parent.addheaders: > grep -R "def putheader" *.py httplib.py:def putheader(self, header, value): httplib.py:def putheader(self, header, *values): I also then found: http://stackoverflow.com/questions/3278418/testing-urllib2-application-http-responses-loaded-from-files I then patched this: class HTTPConnection(httplib.HTTPConnection): def putheader(self, header, value): print [header, value] This in turn brought back: ['Content-Md5', 'nts0yj7AdzJALyNOxafDyA=='] Which means it's happening before putheader(). So I patched _send_request() on HTTPConnection(), and that also brought back 'Content-Md5'. Exception trace shows: File "/ddcms/dev/webapp/../webapp/sites/ma/management/commands/ddcms.py", line 147, in _send_request _res = opener.open(req) -- CORRECT -- File "/usr/local/lib/python2.6/urllib2.py", line 391, in open response = self._open(req, data) -- CORRECT -- File "/usr/local/lib/python2.6/urllib2.py", line 409, in _open '_open', req) -- CORRECT -- File "/usr/local/lib/python2.6/urllib2.py", line 369, in _call_chain result = func(*args) -- CORRECT -- File "/ddcms/dev/webapp/../webapp/sites/ma/management/commands/ddcms.py", line 126, in http_open return self.do_open(HTTPConnection, req) -- CORRECT -- File "/usr/local/lib/python2.6/urllib2.py", line 1142, in do_open h.request(req.get_method(), req.get_selector(), req.data, headers) -- INVALID -- File "/usr/local/lib/python2.6/httplib.py", line 914, in request self._send_request(method, url, body, headers) File "/ddcms/dev/webapp/../webapp/sites/ma/management/commands/ddcms.py", line 122, in _send_request raise The line that causes it? headers = dict( (name.title(), val) for name, val in headers.items()) So it would appear that title() also needs monkey patching.. Patched to use: # Patch case sensitive headers (due to reflected API being non RFC compliant, and # urllib2 not giving the option to choose between the two) class _str(str): def capitalize(s): print "capitalize() bypassed: sending value: %s" % ( s ) return s def title(s): print "title() bypassed: sending value: %s" % ( s ) return s _headers = {_str('Content-MD5') : _md5_content} capitalize() bypassed: sending value: Content-MD5 title() bypassed: sending value: Content-MD5 send: 'POST /url/api HTTP/1.1\r\nContent-MD5: nts0yj7AdzJALyNOxafDyA==\r\n\r\n' -- ___ Python tracker <http://bugs.python.org/issue12455> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12455] urllib2 Request() forces capitalize() on header names, breaking some requests
Cal Leeming added the comment: Sorry, I should clarify.. The str() patch worked, but it failed to work within the realm of urllib2: s = _str("Content-MD5") print "Builtin:" print "plain: %s" % ( s ) print "capitalized: %s" % ( s.capitalize() ) s = str("Content-MD5") print "Builtin:" print "plain: %s" % ( s ) print "capitalized: %s" % ( s.capitalize() ) Builtin: plain: Content-MD5 capitalized: Content-MD5 Builtin: plain: Content-MD5 capitalized: Content-md5 Why it works in the unit test, and not within urllib2, is totally beyond me. Especially since I put a debug call on the method, and it does get called.. yet urllib2 debug still shows it sending the wrong value. --- capitalize() bypassed: sending value: Content-MD5 send: 'POST /api/url\r\nContent-Md5: nts0yj7AdzJALyNOxafDyA==\r\n\r\n' --- I have a feeling that the problem may lie somewhere after the opener (like HTTPConnection or AbstractHTTPHandler), rather than the urllib2 calls to capitalize(), but not having much luck monkey patching those :X -- ___ Python tracker <http://bugs.python.org/issue12455> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12455] urllib2 Request() forces capitalize() on header names, breaking some requests
New submission from Cal Leeming : I came up against a problem today whilst trying to submit a request to a remote API. The header needed to contain: 'Content-MD5' : "md5here" But the urllib2 Request() forces capitalize() on all header names, and transformed it into "Content-Md5", which in turn made the remote web server ignore the header and break the request (as the remote side is case sensitive, of which we don't have any control over). I attempted to get smart by using the following patch: class _str(str): def capitalize(s): print s return s _headers = {_str("Content-MD5") : 'md5here'} But this failed to work: ---HEADERS--- {'Content-MD5': 'nts0yj7AdzJALyNOxafDyA=='} ---URLLIB2 DEBUG--- send: 'POST /api/v1 m HTTP/1.1\r\nContent-Md5: nts0yj7AdzJALyNOxafDyA==\r\n\r\n\r\n' Upon inspecting the urllib2.py source, I found 3 references to capitalize() which seem to cause this problem, but it seems impossible to monkey patch, nor fix without forking. Therefore, I'd like to +1 a feature request to have an extra option at the time of the request being opened, to bypass the capitalize() on header names (maybe, header_keep_original = True or something). And, if anyone could suggest a possible monkey patch (which doesn't involve forking huge chunks of code), that'd be good too :) Thanks Cal -- components: Library (Lib) messages: 139512 nosy: Cal.Leeming priority: normal severity: normal status: open title: urllib2 Request() forces capitalize() on header names, breaking some requests type: behavior versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue12455> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12325] regex matches incorrectly on literal dot (99.9% confirmed)
Cal Leeming added the comment: Oh jeez, you're going to think I'm such an idiot. I just ran a completely fresh test in the cli (away from the original source), and the issue disappeared (it was caused by caching - apparently). I'm really sorry to have bothered you guys, I should have thought and tested this outside the original code first. I'll make sure to do this before posting any bugs in the future. Thank you for your extremely fast response though! Cal -- ___ Python tracker <http://bugs.python.org/issue12325> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12325] regex matches incorrectly on literal dot (99.9% confirmed)
Cal Leeming added the comment: Take particular notice to the following: \.co\.uk or literal 99 literal 111 literal 46 literal 117 literal 107 >>> map(lambda x: chr(x), [99,111,46,117,107]) ['c', 'o', '.', 'u', 'k'] It would appear it is ignoring the first \. But why?? -- ___ Python tracker <http://bugs.python.org/issue12325> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12325] regex matches incorrectly on literal dot (99.9% confirmed)
Changes by Cal Leeming : -- type: -> behavior ___ Python tracker <http://bugs.python.org/issue12325> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12325] regex matches incorrectly on literal dot (99.9% confirmed)
New submission from Cal Leeming : I believe I might have found a bug in the Python re libraries. Here is a complete debug of what is happening (my apologies for the nature of the actual text). I have ran this regex through RegexBuddy (and a few other tools), and all of them do the correct action (which is to not do any replacement), apart from Python. I haven't yet tried this in another language. ORIGINAL TEXT >>313229176 me and a buddy and his girlfriend were watching tv once and this blabbering idiot starts talking about this scientific study she heard about where they built a fake city and only one guy didn't know that it was a fake. we all paused for a second and i said "the truman show?" and she says "yeah! that was the name of it!" me my buddy and his girlfriend all catch eyes and are baffled at how stupid she was TEXT AFTER REGEX SUB me and a buddy and his girlfriend were http://watching.tv once and this blabbering idiot starts talking about this scientific study she heard about where they built a fake city and only one guy didn't know that it was a fake.we all paused for a second and i said "the truman show?" and she says "yeah! that was the name of it!" me my buddy and his girlfriend all catch eyes and are baffled at how stupid she was --- --- REPLACED TEXT --- watching tv http://watching.tv --- REGEX _t = re.compile(r"(^| )((?:[\w\-]{2,}?\.|)(?:[\w\-]{2,}?)(?:\.com|\.net|\.org|\.co\.uk|\.tv|\.ly))", flags = re.IGNORECASE | re.MULTILINE | re.DEBUG) COMMAND _t.sub("\\1http://\\2";, original_message_here) REGEX DEBUG subpattern 1 branch at at_beginning or literal 32 subpattern 2 subpattern None branch min_repeat 2 65535 in category category_word literal 45 literal 46 or subpattern None min_repeat 2 65535 in category category_word literal 45 subpattern None literal 46 branch literal 99 literal 111 literal 109 or literal 110 literal 101 literal 116 or literal 111 literal 114 literal 103 or literal 99 literal 111 literal 46 literal 117 literal 107 or literal 116 literal 118 or literal 108 literal 121 -- components: Regular Expressions messages: 138234 nosy: Cal.Leeming priority: normal severity: normal status: open title: regex matches incorrectly on literal dot (99.9% confirmed) versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue12325> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12235] subprocess throws wrong exception if script can't be executed
Cal Leeming added the comment: Ah okay, shell=True is a good work around then :) Thanks! Cal -- ___ Python tracker <http://bugs.python.org/issue12235> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12235] subprocess.check_output throws wrong exception if non executable
Cal Leeming added the comment: Yeah, I resolved the issue already. This bug report is focused primarily on the (somewhat misleading) exception message given back. I think it should at least include "bad interpreter", otherwise it is a tad misleading. Cal -- ___ Python tracker <http://bugs.python.org/issue12235> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12235] subprocess.check_output throws wrong exception if non executable
Cal Leeming added the comment: Oh also, here is the version: simplicitymedialtd@sws01.internal [~/webapps/cdn06.prod/src/webapp/cmd] > python Python 2.7 Stackless 3.1b3 060516 (release27-maint, Aug 29 2010, 15:44:48) [GCC 4.3.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. -- components: +None type: -> behavior versions: +Python 2.7 ___ Python tracker <http://bugs.python.org/issue12235> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12235] subprocess.check_output throws wrong exception if non executable
New submission from Cal Leeming : If you attempt to call subprocess.check_output() on a file which is not executable, it gives a "file not found" exception, rather than "file not executable". Took me about 3 hours to figure out why it kept saying the file didn't exist, when it clearly did :| ***@***# ls -la ***/src/webapp/tools/grab.sh -rwxr-xr-x 1 *** *** 4398 Apr 19 10:55 ***/src/webapp/tools/grab.sh ***@***# ***/src/webapp/tools/grab.sh bash: ***/src/webapp/tools/grab.sh: /bin/sh^M: bad interpreter: No such file or directory Traceback (most recent call last): File "***/src/webapp/../webapp/idx/fourchan/tasks.py", line 77, in run subprocess.check_output([ DOWNLOAD_BIN, ]) File "/usr/local/lib/python2.7/subprocess.py", line 530, in check_output process = Popen(stdout=PIPE, *popenargs, **kwargs) File "/usr/local/lib/python2.7/subprocess.py", line 672, in __init__ errread, errwrite) File "/usr/local/lib/python2.7/subprocess.py", line 1201, in _execute_child raise child_exception OSError: [Errno 2] No such file or directory Request: None -- messages: 137439 nosy: Cal.Leeming priority: normal severity: normal status: open title: subprocess.check_output throws wrong exception if non executable ___ Python tracker <http://bugs.python.org/issue12235> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11974] Class definition gotcha.. should this be documented somewhere?
New submission from Cal Leeming : So, when you create a class like this: class Obj: children = [] The 'children' object essentially becomes shared across all instances of Obj. To get around this, you have to use: class Obj: children = None def __init__(self): children = [] I have attached proof of concept code which can trigger this bug. Although I have almost 8 years of experience with Python, this is the first time I have actually noticed this, however, I am sure that similar things have happened in the past, and I just didn't investigate it enough to realise what was going on. Although this isn't a bug, it is likely that other advanced developers may also not know about, or have been caught out by this little gotcha. So, perhaps it might be worth documenting it somewhere? Let me know your thoughts. Cal -- components: Interpreter Core files: obj.py messages: 134919 nosy: sleepycal priority: normal severity: normal status: open title: Class definition gotcha.. should this be documented somewhere? type: feature request versions: Python 2.7 Added file: http://bugs.python.org/file21848/obj.py ___ Python tracker <http://bugs.python.org/issue11974> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com