[issue16990] re: match of nongreedy regex not grouping right
Jared Grubb added the comment: You're right. My mistake. I thought "match" meant "the full string must match", but in Python it means "the beginning must match". Sorry for the noise. -- ___ Python tracker <http://bugs.python.org/issue16990> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16990] re: match of nongreedy regex not grouping right
Jared Grubb added the comment:
Yes:
>>> re.match('.*', '')
<_sre.SRE_Match object at 0x107c6d308>
>>> re.match('.*?', '')
<_sre.SRE_Match object at 0x107c6d370>
--
___
Python tracker
<http://bugs.python.org/issue16990>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16990] re: match of nongreedy regex not grouping right
New submission from Jared Grubb:
re.match matches, but the capture groups are empty. That's not possible.
Python 2.7.2 (default, Oct 11 2012, 20:14:37)
[GCC 4.2.1 Compatible Apple Clang 4.0 (tags/Apple/clang-418.0.60)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import re
>>> re.match('.*', 'stuff').group() # greedy matches and captures; cool.
'stuff'
>>> re.match('.*?', 'stuff').group() # nongreedy matches (cool) but doesnt
>>> capture (huh?)
''
--
components: Library (Lib)
messages: 180162
nosy: jaredgrubb
priority: normal
severity: normal
status: open
title: re: match of nongreedy regex not grouping right
versions: Python 2.7
___
Python tracker
<http://bugs.python.org/issue16990>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7432] Py3k doc: "from __future__ import division" not necessary
Jared Grubb added the comment: Ditto on a few dozen lines later: INPLACE_TRUE_DIVIDE()¶ Implements in-place TOS = TOS1 / TOS when from __future__ import division is in effect. -- ___ Python tracker <http://bugs.python.org/issue7432> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7432] Py3k doc: "from __future__ import division" not necessary
New submission from Jared Grubb : In the Python 3.1 docs for the 'dis' module, the following appears: ( http://docs.python.org/3.1/library/dis.html ) BINARY_TRUE_DIVIDE()¶ Implements TOS = TOS1 / TOS when from __future__ import division is in effect. There is always true in 3k, correct? The "when" clause should be removed. -- assignee: georg.brandl components: Documentation messages: 95950 nosy: georg.brandl, jaredgrubb severity: normal status: open title: Py3k doc: "from __future__ import division" not necessary versions: Python 3.1 ___ Python tracker <http://bugs.python.org/issue7432> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7343] "What's new in 3.0" says % operator will be deprecated in 3.1
New submission from Jared Grubb : The existing text: http://www.python.org/doc/3.0/whatsnew/3.0.html "A new system for built-in string formatting operations replaces the % string formatting operator. (However, the % operator is still supported; it will be deprecated in Python 3.1 and removed from the language at some later time.) Read PEP 3101 for the full scoop." Python 3.1 did not deprecate the % operator, right? Is it appropriate to edit the 3.0 docs to reflect that? -- assignee: georg.brandl components: Documentation messages: 95411 nosy: georg.brandl, jaredgrubb severity: normal status: open title: "What's new in 3.0" says % operator will be deprecated in 3.1 versions: Python 3.0 ___ Python tracker <http://bugs.python.org/issue7343> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1580] Use shorter float repr when possible
Jared Grubb added the comment: The process that you describe in msg85741 is a way of ensuring "memcmp(&x, &y, sizeof(x))==0", and it's portable and safe and is the Right Thing that we all want and expect. But that's not "x==y", as that Sun paper explains. It's close, but not technically accurate, as the implication arrow only goes one way (just as "x=1/y" implies "xy=1" in algebra, but not the other way around) I'd be interested to see if you could say that the Python object model/bytecode interpretation enforces a certain quauntum of operations that actually does imply "eval(repr(x))==x"; but I suspect it's unprovable, and it's fragile as Python grows to have more support in CLI/LLVM/JVM backends. My pedantic mind would strip any and all references to floating-point equality out of the docs, as it's dangerous and insidiously misleading, even in "obvious" cases. But, I'll stop now :) (FYI: I've enjoyed the ~100 messages here.. Great stuff!) -- ___ Python tracker <http://bugs.python.org/issue1580> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1580] Use shorter float repr when possible
Jared Grubb added the comment:
I think ANY attempt to rely on eval(repr(x))==x is asking for trouble,
and it should probably be removed from the docs.
Example: The following C code can vary *even* on a IEEE 754 platform,
even in two places in the same source file (so same compile options),
even in the same 5 lines of code recompiled after changing code that
does even not touch/read 'x' or 'y':
double x, y;
x = 3.0/7.0;
y = x;
/* ... code that doesnt touch/read x or y ... */
printf(" x==y: %s", (x==y) ? "true" : "false");
So, how can we hope that eval(repr(x))==x is EVER stable? Equality and
floating point should raise the hairs on the back of everyone's neck...
(Code above based on
http://docs.sun.com/source/806-3568/ncg_goldberg.html in section
"Current IEEE 754 Implementations", along with a great explanation on
why this is true. The code example is a little different, but the same
concept applies.)
--
nosy: +jaredgrubb
___
Python tracker
<http://bugs.python.org/issue1580>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5349] abstractmethod vs C++ pure virtual
New submission from Jared Grubb :
On page library/abc.html documenting abc.abstractmethod, the following
text about C++ is placed in a note:
"Note: Unlike C++’s pure virtual functions, or Java abstract methods,
these abstract methods may have an implementation. This implementation
can be called via the super() mechanism from the class that overrides
it. This could be useful as an end-point for a super-call in a framework
that uses cooperative multiple-inheritance."
This is not an accurate description of C++'s pure virtual functions.
Pure virtual functions CAN have an implementation, which can be called
from derived classes; this makes them behave just like Python's
abstractmethod.
Example:
struct Abstract {
virtual void foo() = 0;
};
void Abstract::foo() {
std::cout << "pure virtual function called";
}
struct Derived : public Abstract {
virtual void foo() {
Abstract::foo(); // call the abstract impl
}
};
--
assignee: georg.brandl
components: Documentation
messages: 82618
nosy: georg.brandl, jaredgrubb
severity: normal
status: open
title: abstractmethod vs C++ pure virtual
versions: Python 2.6
___
Python tracker
<http://bugs.python.org/issue5349>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2182] tokenize: does not allow CR for a newline
Jared Grubb <[EMAIL PROTECTED]> added the comment: I actually hadnt thought of that. PyPy should actually use universal newlines to its advantage; after all, it IS written in Python... Thanks for the suggestion! In any case, I wanted to get this bug about the standard library in your record, in case you wanted to handle it. It is fairly innocuous, so I'll let it go. Take care. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2182> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2182] tokenize: does not allow CR for a newline
Jared Grubb <[EMAIL PROTECTED]> added the comment:
Yes, but exec(string) also gives a syntax error for \r\n:
exec('x=1\r\nprint x')
The only explanation I could find for ONLY permitting \n as newlines in
exec(string) comes from PEP278: "There is no support for universal
newlines in strings passed to eval() or exec. It is envisioned that such
strings always have the standard \n line feed, if the strings come from
a file that file can be read with universal newlines." (This is why my
original example had to be exec(file) and not just a simple exec(string))
Of the 3 newline types, exec(*) allows 1 or all 3 as the case may be,
and tokenize allows exactly 2 of them. I honestly am not sure what the
"right" way is (or should be), but either way, the tokenize module is
not consistent with exec.
(By the way, if you're curious why I filed this issue and Issue#2180,
I'm working on the PyPy project to help improve its current Python
lexer/parser. In order to ensure that it is correct and robust, I was
experimenting with corner cases in Python syntax and I found these cases
where tokenize disagrees with exec.)
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2182>
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2182] tokenize: does not allow CR for a newline
Jared Grubb <[EMAIL PROTECTED]> added the comment: This is not a report on a bug in exec(), but rather a bug in the tokenize module -- the behavior between the CPython tokenizer and the tokenize module is not consistent. If you look in the tokenize.py source, it contains code to recognize both \n and \r\n as newlines, but it ignores the possibility that \r could be the line ending character (as the Python reference says). __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2182> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2273] test_decimal: possible thread lockup in test case
Jared Grubb <[EMAIL PROTECTED]> added the comment: I ran into this bug because I created a context manager in one of my own projects, and the regression tests in test_decimal looked like a good start for my own regression tests... when some recent changes broke MY code, I found the test bug too and realized that the test_decimal file had the same problem. So, I figured I'd share the wealth :) __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2273> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2273] test_decimal: possible thread lockup in test case
New submission from Jared Grubb <[EMAIL PROTECTED]>: In Lib\test\test_decimal.py, attached is a bugfix for two bugs: 1) If the thfunc2 actually fails, then its thread will throw an exception and never set the Events that thfunc1 is waiting for; thus, thfunc1 never returns, causing the whole unittest to hang. 2) DecimalUseOfContextTest.test_threading should wait on both finish1 and finish2 (instead of waiting on finish1 twice). -- components: Library (Lib) files: test_decimal.patch keywords: patch messages: 63463 nosy: jaredgrubb severity: normal status: open title: test_decimal: possible thread lockup in test case type: crash versions: Python 2.5 Added file: http://bugs.python.org/file9656/test_decimal.patch __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2273> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2180] tokenize: mishandles line joining
Jared Grubb added the comment:
CPython allows \ at EOF, but tokenize does not.
>>> s = 'print 1\\\n'
>>> exec s
1
>>> tokenize.tokenize(StringIO(s).readline)
1,0-1,5:NAME'print'
1,6-1,7:NUMBER '1'
Traceback (most recent call last):
File "", line 1, in
File
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/tokenize.py",
line 153, in tokenize
tokenize_loop(readline, tokeneater)
File
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/tokenize.py",
line 159, in tokenize_loop
for token_info in generate_tokens(readline):
File
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/tokenize.py",
line 283, in generate_tokens
raise TokenError, ("EOF in multi-line statement", (lnum, 0))
tokenize.TokenError: ('EOF in multi-line statement', (2, 0))
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2180>
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2182] tokenize: does not allow CR for a newline
New submission from Jared Grubb:
tokenize recognizes '\n' and '\r\n' as newlines, but does not tolerate '\r':
>>> s = "print 1\nprint 2\r\nprint 3\r"
>>> open('temp.py','w').write(s)
>>> exec(open('temp.py','r'))
1
2
3
>>> tokenize.tokenize(open('temp.py','r').readline)
1,0-1,5:NAME'print'
1,6-1,7:NUMBER '1'
1,7-1,8:NEWLINE '\n'
2,0-2,5:NAME'print'
2,6-2,7:NUMBER '2'
2,7-2,9:NEWLINE '\r\n'
3,0-3,5:NAME'print'
3,6-3,7:NUMBER '3'
3,7-3,8:ERRORTOKEN '\r'
4,0-4,0:ENDMARKER ''
--
components: Extension Modules
messages: 62959
nosy: jaredgrubb
severity: minor
status: open
title: tokenize: does not allow CR for a newline
type: behavior
versions: Python 2.5
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2182>
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2180] tokenize: mishandles line joining
New submission from Jared Grubb: tokenize does not handle line joining properly, as the following string fails the CPython tokenizer but passes the tokenize module. Example 1: >>> s = "if 1:\n \\\n #hey\n print 1" >>> exec s Traceback (most recent call last): File "", line 1, in File "", line 3 #hey ^ SyntaxError: invalid syntax >>> tokenize.tokenize(StringIO(s).readline) 1,0-1,2:NAME'if' 1,3-1,4:NUMBER '1' 1,4-1,5:OP ':' 1,5-1,6:NEWLINE '\n' 2,0-2,2:INDENT ' ' 3,2-3,6:COMMENT '#hey' 3,6-3,7:NEWLINE '\n' 4,2-4,7:NAME'print' 4,8-4,9:NUMBER '1' 5,0-5,0:DEDENT '' 5,0-5,0:ENDMARKER '' __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2180> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2180] tokenize: mishandles line joining
Changes by Jared Grubb: -- components: Extension Modules nosy: jaredgrubb severity: minor status: open title: tokenize: mishandles line joining type: behavior versions: Python 2.5 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2180> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
