Matthew Barnett <[EMAIL PROTECTED]> added the comment:
Needed to correct regex_2.6rc2+2.diff.
Added file: http://bugs.python.org/file11553/regex_2.6rc2+2.diff
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Matthew Barnett <[EMAIL PROTECTED]> added the comment:
regex_2.6rc2+3.diff adds reverse searching with the re.REVERSE/re.R and
"(?r)" flag.
This gives results such as:
>>> re.findall("(\w+)", "one two three")
['one', 'two', &#x
Matthew Barnett <[EMAIL PROTECTED]> added the comment:
Implemented as part of #3825.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue516762>
___
Matthew Barnett <[EMAIL PROTECTED]> added the comment:
regex_2.6rc2+4.diff fixes the ordering of the capture groups for reverse
searching.
Added file: http://bugs.python.org/file11558/regex_2.6rc2+4.diff
___
Python tracker <[EMAIL PROTECTE
Changes by Matthew Barnett <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file11558/regex_2.6rc2+4.diff
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Matthew Barnett <[EMAIL PROTECTED]> added the comment:
Correction of regex_2.6rc2+4.diff. (Aargh!)
Added file: http://bugs.python.org/file11559/regex_2.6rc2+4.diff
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Matthew Barnett <[EMAIL PROTECTED]> added the comment:
Implemented in #2636 and #3825.
--
nosy: +mrabarnett
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.
Matthew Barnett <[EMAIL PROTECTED]> added the comment:
Patch regex_2.6rc2+5.diff adds scoped and 'negative' flags for (?i),
(?m) and (?s). The other flags remain unchanged in behaviour.
See #433024, #433027 and #433028.
Added file: http://bugs.python.org/file11585/reg
Matthew Barnett <[EMAIL PROTECTED]> added the comment:
Implemenetd in #3825.
--
nosy: +mrabarnett
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.
Matthew Barnett <[EMAIL PROTECTED]> added the comment:
Implemented in #3825.
--
nosy: +mrabarnett
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.
Matthew Barnett <[EMAIL PROTECTED]> added the comment:
Implemented in #3825.
--
nosy: +mrabarnett
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.
Matthew Barnett <[EMAIL PROTECTED]> added the comment:
Patch regex_2.6rc2+6.diff is a bugfix.
Added file: http://bugs.python.org/file11587/regex_2.6rc2+6.diff
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Matthew Barnett <[EMAIL PROTECTED]> added the comment:
Comparing item 2 and item 3, I think that item 3 is the Pythonic choice
and item 2 is a bad idea.
Item 4: back-references in the pattern are like \1 and (?P=name), not
\g<1> or \g, and in the replacement string are like \g<1&
Matthew Barnett <[EMAIL PROTECTED]> added the comment:
This also affects re.findall().
--
nosy: +mrabarnett
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.o
Matthew Barnett <[EMAIL PROTECTED]> added the comment:
Regarding item 22: there's also #1647489 ("zero-length match confuses
re.finditer()").
This had me stumped for a while, but I might have a solution. I'll see
whether it'll fix item 22 too.
I wasn't plan
Matthew Barnett <[EMAIL PROTECTED]> added the comment:
What should:
[m.groups() for m in re.finditer(r'(^z*)|(^q*)|(\w+)', 'abc')]
return? Should the second group also yield a zero-width match before the
third group is tried? I think it
Matthew Barnett <[EMAIL PROTECTED]> added the comment:
What about r'(^z*)|(q*)|(\w+)'? I could imagine that the first group
could match only at the start of the string, but if the second group
doesn't have that restriction then it could match the second time, and
only after
Changes by Matthew Smart <[EMAIL PROTECTED]>:
--
nosy: +mattsmart
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3959>
___
__
Matthew Barnett <[EMAIL PROTECTED]> added the comment:
FYI, I posted msg73737 after finding that the fix for the original case
was really very simple, but then thought about whether it would behave
as expected when there were more zero-width matches, hence the later
Matthew Barnett <[EMAIL PROTECTED]> added the comment:
Just out of interest, is there any plan to include #1160 while we're at it?
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.
Matthew Barnett <[EMAIL PROTECTED]> added the comment:
For reference, these are all the regex-related issues that I've found
(including this one!):
id : activity : title
#2636: 25/09/08 : Regexp 2.7 (modifications to current re 2.2.2)
#1160: 25/09/08 : Medium size reg
Matthew Barnett <[EMAIL PROTECTED]> added the comment:
I have to report that the fix appears to be successful:
>>> print [m.groups() for m in re.finditer(r'(^z*)|(\w+)', 'abc')]
[('', None), (None, 'abc')]
>>> print re.findall(r&
Matthew Barnett <[EMAIL PROTECTED]> added the comment:
#814253 is part of the fix for variable-width lookbehind.
BTW, I've just tried a second time to register with Launchpad, but still
no reply. :-(
___
Python tracker <[EMAIL PRO
Matthew Barnett <[EMAIL PROTECTED]> added the comment:
Tried [EMAIL PROTECTED] twice, no reply. Succeeded with
[EMAIL PROTECTED]
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Matthew Barnett <[EMAIL PROTECTED]> added the comment:
I've been completely unable to get Bazaar to work with Launchpad:
authentication errors and bzrlib.errors.TooManyConcurrentRequests.
___
Python tracker <[EMAIL PROTECTED]>
<ht
Matthew Barnett <[EMAIL PROTECTED]> added the comment:
I have it working finally!
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2636>
___
_
Matthew Barnett <[EMAIL PROTECTED]> added the comment:
I did a search on the permissions problem:
https://answers.launchpad.net/bzr/+question/34332.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Matthew Barnett <[EMAIL PROTECTED]> added the comment:
I haven't yet found out how to turn on compression when getting the
branches, so I've only looked at
lp:~pythonregexp2.7/python/issue2636+01+09-02+17+18+19+20+21+24+26. I
did see that the SRE_FLAG_REVERSE flag was miss
Matthew Barnett <[EMAIL PROTECTED]> added the comment:
issue2636-01+09-02+17_backport.diff is the backport fix.
Still unable to compress the download, so that's >200MB each time!
Added file: http://bugs.python.org/file11657/issue2636-01+09-02+17
Matthew Barnett <[EMAIL PROTECTED]> added the comment:
The explanation of the zero-width bug is incorrect. What happens is this:
The functions for finditer(), findall(), etc, perform searches and want
the next one to continue from where the previous match ended. However,
if the mat
Matthew Barnett <[EMAIL PROTECTED]> added the comment:
I'll have a look at this. No promises, though.
--
nosy: +mrabarnett
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.py
Matthew Barnett <[EMAIL PROTECTED]> added the comment:
I've found an interesting difference between Python and Perl regular
expressions:
In Python:
\Z matches at the end of the string
In Perl:
\Z matches at the end of the string or before a newline at the
Matthew Barnett <[EMAIL PROTECTED]> added the comment:
Perl v5.10 offers the ability to have duplicate capture group numbers in
branches. For example:
(?|(a)|(b))
would number both of the capture groups as group 1.
Something to include?
___
Matthew Barnett <[EMAIL PROTECTED]> added the comment:
I've extended the group referencing. It now has:
Forward group references
(\2two|(one))+
\g-type group references
(n is name or number)
\g (Python re replacement string)
\g{n} (Perl)
\g'n' (Per
Matthew Barnett <[EMAIL PROTECTED]> added the comment:
Perl (?number) for calling numbered groups and (?&name) for named groups
(Perl also supports (?P>name)). (?R) is equivalent to (?0).
It's interesting that the documentation for both Perl and PCRE say that
they support
Matthew Barnett added the comment:
issue2636-20100204.zip is a new version of the regex module.
I've added splititer and added a build for Python 3.1.
--
versions: +Python 3.1
Added file: http://bugs.python.org/file16122/issue2636-2010020
Matthew Barnett added the comment:
issue2636-20100210.zip is a new version of the regex module.
The reported bugs appear to be fixed now.
--
Added file: http://bugs.python.org/file16195/issue2636-20100210.zip
___
Python tracker
<h
Matthew Barnett added the comment:
As stated in msg73781, this is being addressed in issue #2636.
My regex module handles the test case without complaint:
>>> import regex
>>> r = regex.compile('|'.join('%d'%x for x in range(7000)))
>>> r.match(&
Matthew Barnett added the comment:
I've been aware for some time that exception messages in Python 2 can't be
Unicode, but I wasn't sure which encoding to use, so I've decided to use that
of sys.stdout.
It appears to work OK in IDLE and at the Python prompt.
issue2636
New submission from Matthew Russell :
Tuples, as we know are designed to immutable.
Hence I'm questioning if the following behavior is considered a defect:
>>> t = (1, 2)
>>> t += (1, 2, 3)
>>> t
(1, 2, 3)
?
--
components: Interpreter Core
messages:
Matthew Russell added the comment:
Yes, the output is fishy indeed my bad (paste error).
Tim: I hadn't thought for long enough or thought to check with the id builtin -
nice catch.
--
status: open -> closed
___
Python tracke
Matthew Barnett added the comment:
The re module is addressed in issue #2636.
BTW, my regex module behaves like Ruby:
>>> regex.sub(r"((x|y)*)*", "(\\1, \\2)", "xyyzy", count=1)
'(, y)zy'
>>> regex.sub(r"((x|y+)*)*", &quo
Matthew Barnett added the comment:
The issue started about updating the re module and adding features that other
languages already possess in their regex implementations (the last time any
significant work was done on it was in 2003).
The hope is that the new regex implementation will
Matthew Barnett added the comment:
The main text at http://pypi.python.org/pypi/regex appears to have lost its
backslashes, for example:
The Unicode escapes u and U are supported.
instead of:
The Unicode escapes \u and \U are supported
Matthew Barnett added the comment:
issue2636-20100218.zip is a new version of the regex module.
I've added '.' to the permitted characters when parsing the name of a property.
The name itself is no longer reported in the error message.
I've also corrected the positi
Matthew Barnett added the comment:
issue2636-20100219.zip is a new version of the regex module.
The regex module should give the same results as the re module for backwards
compatibility.
The ignorecase bug is now fixed.
This new version releases the GIL when matching on str and bytes (str
Matthew Barnett added the comment:
On a related note, this doesn't work either:
>>> "{-1}".format("x", "y", "z")
Traceback (most recent call last):
File "", line 1, in
"{-1}".format("x", "y"
Matthew Barnett added the comment:
I don't know what happened there. I didn't notice that the zip file was way too
small. Here's a replacement (still called issue2636-20100222.zip).
Unicode script properties are already included, at least those whose
definitions at htt
Matthew Barnett added the comment:
OK, you've convinced me, \X is supported. :-)
issue2636-20100223.zip is a new version of the regex module.
--
Added file: http://bugs.python.org/file16331/issue2636-20100223.zip
___
Python tracker
Matthew Barnett added the comment:
issue2636-20100224.zip is a new version of the regex module.
It includes support for matching based on Unicode scripts as well as on Unicode
blocks and properties.
--
Added file: http://bugs.python.org/file16362/issue2636-20100224.zip
Matthew Barnett added the comment:
\p{name} is supported for Unicode properties, scripts and blocks in my regex
module (see issue #2636).
It also supports the POSIX set syntax, although I'm not sure that we really
need to have 2 ways of doing it, eg \p{Alpha} and [[:
Matthew Barnett added the comment:
issue2636-20100226.zip is a new version of the regex module.
It now supports the branch reset (?|...|...), enabling the different branches
of an alternation to reuse group numbers.
--
Added file: http://bugs.python.org/file16375/issue2636-20100226
Matthew Barnett added the comment:
\X shouldn't be allowed in a character class because it's equivalent to
\P{M}\p{M}*. It's a bug, now fixed in issue2636-20100304.zip.
I'm not convinced about the set intersection and difference stuff. Isn't that
overdoing it a litt
Matthew Barnett added the comment:
issue2636-20100323.zip is a new version of the regex module.
It now includes a test script. Most of the tests come from the existing test
scripts.
--
Added file: http://bugs.python.org/file16626/issue2636-20100323.zip
Matthew Barnett added the comment:
issue2636-20100331.zip is a new version of the regex module.
It includes speed-ups and a minor bugfix.
--
Added file: http://bugs.python.org/file16709/issue2636-20100331.zip
___
Python tracker
<h
Matthew Barnett added the comment:
issue2636-20100413.zip is a new version of the regex module.
It includes additional speed-ups.
--
Added file: http://bugs.python.org/file16905/issue2636-20100413.zip
___
Python tracker
<http://bugs.python.
Matthew Barnett added the comment:
Yes, it passed all the tests, although I've since found a minor bug that isn't
covered/caught by them, so I'll need to add a few more tests.
Anyway, do:
regex.match(ur"\p{Ll}", u"a")
regex.match(ur'(?u)\w'
Matthew Barnett added the comment:
issue2636-20100414.zip is a new version of the regex module.
I think I might have identified the cause of the problem, although I still
haven't been able to reproduce it, so I can't be certain.
--
Matthew Barnett added the comment:
Oops, forgot the file! :-)
--
Added file: http://bugs.python.org/file16916/issue2636-20100414.zip
___
Python tracker
<http://bugs.python.org/issue2
Matthew Barnett added the comment:
Octal escapes are at most 3 octal digits, so the normal way to handle "\41" +
"1" is "\0411".
Some languages support variable-length hex escapes of the form "\x{1B}", so we
could add that and also "\o{41}"
New submission from Matthew Cowles :
[From a question first posted to python-help]
A socket's send function may return 0 if no bytes have been sent. Under at
least OS X 10.6.2, it may also raise errno 35 (resource temporarily
unavailable) if no network buffers are available. If a Python
Matthew Cowles added the comment:
> if you get this type of error, it's probably because you're using non-
> blocking sockets
That's what I thought at first too. But the user's sockets were set to blocking.
> spinning around the send call trying to resend the d
New submission from Matthew Cowles :
[Originally from a post to the python-help list]
Over at:
http://docs.python.org/py3k/tutorial/datastructures.html#sets
it says:
>>> fruit = ['apple', 'orange', 'apple', 'pear', 'orange', &#x
Matthew Cowles added the comment:
[Replying to various posts]
[neologix]
> That's one broken networking stack...
I'm not disagreeing, but you'd have to take that up with Apple.
> How would you circumvent this problem anyway ?
The code has to go around again in the case
Matthew Barnett added the comment:
You could try the regex module mentioned in issue 2636.
--
___
Python tracker
<http://bugs.python.org/issue3262>
___
___
Pytho
Matthew Cowles added the comment:
> A minimal example which reproduces the behavior. :)
Unfortunately the problem wasn't mine originally. I'm just the guy on
python-help who happened to figure out the answer. But if someone can get me
access to an FTP server on the other end o
Matthew Cowles added the comment:
Apologies! Further investigation indicates that the user had set a timeout in
the ftplib module. I'll close this. In an ideal world, errors due to timeouts
would look like they were related to timeouts. But that's a different matter
New submission from Matthew Brett :
I have a valid zlib compressed string, attached here as 'mat.bin' (1.7M), that
cause and error on zlib.decompress decompression:
>>> import zlib
>>> data = open('mat.bin', 'rb').read()
>>> out = zlib.d
Matthew Brett added the comment:
Hi,
> Antoine Pitrou added the comment:
>
> After a bit of debugging, it seems your data is not actually a complete zlib
> stream (*). What did you generate it with?
>
> (*) in technical terms, the zlib never returns Z_STREAM_END when
&g
Matthew Brett added the comment:
>> Thanks for the debugging. The stream comes from within a matlab 'mat'
>> file. I maintain the scipy matlab file readers; the variables within
>> these files are zlib compressed streams.
>
> So this would be a Matlab is
Matthew Barnett <[EMAIL PROTECTED]> added the comment:
Further to msg74203, I can see no reason why we can't allow duplicate
capture group names if the groups are on different branches are are thus
mutually exclusive. For example:
(?Pa)|(?Pb)
Apart from this I think that dupl
Matthew Barnett <[EMAIL PROTECTED]> added the comment:
The left operand is a bytestring and the right operand is a unicode
string, so it makes sense that it raises an exception, although it would
be clearer if it said "'in ' requires unicode string as left
operand".
Matthew Barnett <[EMAIL PROTECTED]> added the comment:
Subversion is formatting a string from a time (strftime), so a repeated
placeholder is OK.
You're trying to _parse_ a time from a string (strptime). If you're
telling it that 2 different parts of the string are the date, w
New submission from Matthew Cowles :
[From a question sent to the python-help list.]
In the Python 3 tutorial at:
http://docs.python.org/3.0/tutorial/datastructures.html#dictionaries
it says:
The keys() method of a dictionary object returns a list of all the keys
used in the dictionary, in
Matthew Karas added the comment:
I'm sorry, will this fix get into a new release? I tried using a tix
widget on 2.6.1 and got the same error.
--
nosy: +lucidguppy
___
Python tracker
<http://bugs.python.org/i
New submission from Matthew Barnett :
I've found that the following 4 Unicode characters/codepoints don't
behave as I'd expect: Dž (U+01C5), Lj (U+01C8), Nj (U+01CB), Dz (U+01F2).
For example, u'\u01C5'.istitle() returns True and
unicodedata.category(u'\u01C5'
Matthew Barnett added the comment:
issue2636-features.diff is based on Python 2.6. It includes:
Named Unicode characters eg \N{LATIN CAPITAL LETTER A}
Unicode character properties eg \p{Lu} (uppercase letter) and \P{Lu}
(not uppercase letter)
Other character properties not restricted to
Matthew Barnett added the comment:
This has been addressed in issue #2636.
--
nosy: +mrabarnett
___
Python tracker
<http://bugs.python.org/issue1519638>
___
___
Matthew Barnett added the comment:
In issue #2636 I'm using the following:
Alpha is Ll, Lo, Lt, Lu.
Digit is Nd.
Word is Ll, Lo, Lt, Lu, Mc, Me, Mn, Nd, Nl, No, Pc.
These are what are specified at
http://www.regular-expressions.info/posixbrackets.html
--
nosy: +mraba
Matthew Barnett added the comment:
Python 2.6 does (and probably Python 3.x, although I haven't checked):
>>> u"\N{LATIN CAPITAL LETTER A}"
u'A'
If it's good enough for Python's Unicode string literals
Matthew Barnett added the comment:
WindowsError is a subclass of OSError, so it's not entirely
contradictory, just a little misleading... :-)
--
nosy: +mrabarnett
___
Python tracker
<http://bugs.python.org/i
New submission from Matthew Woodcraft :
In the current "What's New In Python 3.0" documentation, under "Changes
To Exceptions", it is claimed that the removal of StandardError is "in
2.6 already".
But according to the 2.6.1 documentation, StandardErro
Matthew Barnett added the comment:
issue2636-features-2.diff is based on Python 2.6.
Bugfix. No new features.
Added file: http://bugs.python.org/file12974/issue2636-features-2.diff
___
Python tracker
<http://bugs.python.org/issue2
Matthew Barnett added the comment:
This problem has been addressed in issue #2636.
Although the extra checks certainly aren't foolproof, neither of the
examples given are slow.
--
nosy: +mrabarnett
___
Python tracker
<http://bugs.py
Matthew Barnett added the comment:
This problem has been addressed in issue #2636.
Although the extra checks certainly aren't foolproof, some regular
expressions which were slow won't be any more.
--
nosy: +mrabarnett
___
Python trac
Matthew Barnett added the comment:
This problem has been addressed in issue #2636.
Extra checks have been added to reduce the amount of backtracking.
--
nosy: +mrabarnett
___
Python tracker
<http://bugs.python.org/issue1566
Matthew Barnett added the comment:
This has been addressed in issue #2636.
--
nosy: +mrabarnett
___
Python tracker
<http://bugs.python.org/issue1662581>
___
___
Matthew Barnett added the comment:
The new code includes some extra checks which, although not foolproof,
certainly reduce the amount of backtracking in a lot of cases.
___
Python tracker
<http://bugs.python.org/issue1662
Change by Matthew Rahtz :
--
pull_requests: +29905
pull_request: https://github.com/python/cpython/pull/31804
___
Python tracker
<https://bugs.python.org/issue43
Change by Matthew Rahtz :
--
pull_requests: +29943
pull_request: https://github.com/python/cpython/pull/31844
___
Python tracker
<https://bugs.python.org/issue43
Change by Matthew Rahtz :
--
pull_requests: +29944
pull_request: https://github.com/python/cpython/pull/31845
___
Python tracker
<https://bugs.python.org/issue43
Change by Matthew Rahtz :
--
pull_requests: +29945
pull_request: https://github.com/python/cpython/pull/31846
___
Python tracker
<https://bugs.python.org/issue43
Matthew Rahtz added the comment:
Thanks for starting this, Jelle - I was a bit unsure about how to proceed here.
Given that https://github.com/python/cpython/pull/31800 is already merged, I'd
also propose something halfway between the two extremes: return a sensible
substitution whe
Matthew Rahtz added the comment:
(Having said that, to be clear: my preferred solution currently would still be
the solution where we just return a new GenericAlias for anything involving a
TypeVarTuple. The crux is what Serhiy is happy with
Matthew Barnett added the comment:
I'd just like to point out that to a user it could _look_ like a bug, that an
error occurred while reporting, because the traceback isn't giving a 'clean'
report; the stuff about the KeyError i
Matthew Barnett added the comment:
I don't think it's a typo, and you could argue the case for "qualifiers", but I
still agree with the proposal as it's a more meaningful term in the context.
--
___
Python tracker
Matthew Rahtz added the comment:
[Guido]
> What would be an example of a substitution that's too complex to do?
We also need to remember the dreaded arbitrary-length tuple. For example, I
think it should be the case that:
```python
T = TypeVar('T')
Ts = TypeVarTuple(&#x
Matthew Rahtz added the comment:
P.s. To be clear, (I think?) these are all substitutions that are computable.
We *could* implement the logic to make all these evaluate correctly if we
wanted to. It's just a matter of how much complexity we want to allow in
typing.py (or in the runti
Matthew Rahtz added the comment:
Ooh, thanks for the reminder! I'll start drafting this now.
--
nosy: +matthew.rahtz
___
Python tracker
<https://bugs.python.org/is
Change by Matthew Rahtz :
--
keywords: +patch
pull_requests: +30183
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/32103
___
Python tracker
<https://bugs.python.org/issu
201 - 300 of 828 matches
Mail list logo
