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
Jared Grubb added the comment:
Yes:
re.match('.*', '')
_sre.SRE_Match object at 0x107c6d308
re.match('.*?', '')
_sre.SRE_Match object at 0x107c6d370
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16990
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 rep...@bugs.python.org
http://bugs.python.org
New submission from Jared Grubb pyt...@jaredgrubb.com:
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
Jared Grubb pyt...@jaredgrubb.com 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 rep...@bugs.python.org
New submission from Jared Grubb pyt...@jaredgrubb.com:
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
Jared Grubb pyt...@jaredgrubb.com 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
Jared Grubb pyt...@jaredgrubb.com 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
New submission from Jared Grubb pyt...@jaredgrubb.com:
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
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
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
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
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
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
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
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 stdin, line 1, in module
File
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
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 stdin, line 1, in module
File
/Library
18 matches
Mail list logo
