On Sun, Aug 28, 2011 at 7:28 AM, Guido van Rossum gu...@python.org wrote:
Are you volunteering? (Even if you don't want to be the only
maintainer, it still sounds like you'd be a good co-maintainer of the
regex module.)
My name is listed in the experts index for 're' [0], and that should
On Aug 27, 2011, at 07:11 PM, Martin v. Löwis wrote:
A PEP should IMO only cover end-user aspects of the new re module.
Code organization is typically not in the PEP. To give a specific
example: you mentioned that there is (near) code duplication
MRAB's module. As a reviewer, I would discuss
On Aug 26, 2011, at 05:25 PM, Dan Stromberg wrote:
from __future__ import is an established way of trying something for a while
to see if it's going to work.
Actually, no.
The documentation says:
-snip snip-
__future__ is a real module, and serves three purposes:
* To avoid confusing
On Aug 27, 2011, at 01:15 PM, Ben Finney wrote:
My question is directed more to M-A Lemburg's passage above, and its
implicit assumption that the user understand the changes between
“Unicode 2.0/3.0 semantics” and “Unicode 6 semantics”, and how their own
needs relate to those semantics.
More
On 8/29/2011 9:00 AM, Barry Warsaw wrote:
On Aug 27, 2011, at 07:11 PM, Martin v. Löwis wrote:
A PEP should IMO only cover end-user aspects of the new re module.
Code organization is typically not in the PEP. To give a specific
example: you mentioned that there is (near) code duplication
On Sun, Aug 28, 2011 at 2:28 PM, Guido van Rossum gu...@python.org wrote:
On Sat, Aug 27, 2011 at 8:59 PM, Ezio Melotti ezio.melo...@gmail.com wrote:
I think it would be good to:
1) have some document that explains the general design and main (internal)
functions of the module (e.g. a PEP);
Someone asked me off-line what I wanted besides talk. Here's the list
I came up with:
You could try for instance volunteer to do a thorough code review of
the regex code, trying to think of ways to break it (e.g. bad syntax
or extreme use of nesting etc., or bad data). Or you could volunteer
to
On Fri, Aug 26, 2011 at 8:47 PM, Steven D'Aprano st...@pearwood.infowrote:
Antoine Pitrou wrote:
On Fri, 26 Aug 2011 17:25:56 -0700
Dan Stromberg drsali...@gmail.com wrote:
If you add regex as import regex, and the new regex module doesn't work
out, regex might be harder to get rid of.
I'm not sure it's worth doing an extensive review of the code, a better
approach might be to require extensive test coverage (and a review of
tests).
I think it's worth. It's really bad if only one developer fully
understands the regex implementation.
Regards,
Martin
I can't either, but ISTR hearing that from __future__ import was started
with such an intent.
No, not at all. The original intention was to enable features that would
definitely would be added, not just right now. Tim Peters always
objected to claims that future imports were talking about
On 8/26/2011 9:56 PM, Antoine Pitrou wrote:
Another interesting question is whether it's easy to port to the PEP
393 string representation, if it gets accepted.
Will the re module need porting also?
--
Terry Jan Reedy
___
Python-Dev mailing list
Am 27.08.2011 08:33, schrieb Terry Reedy:
On 8/26/2011 9:56 PM, Antoine Pitrou wrote:
Another interesting question is whether it's easy to port to the PEP
393 string representation, if it gets accepted.
Will the re module need porting also?
That's a quality-of-implementation issue (in
On Sat, Aug 27, 2011 at 4:01 PM, Dan Stromberg drsali...@gmail.com wrote:
You're talking technically, which is important, but wasn't what I was
suggesting would be helped.
Politically, and from a marketing standpoint, it's easier to withdraw a
feature you've given with a Play with this, see
On Sat, 27 Aug 2011 09:18:14 +0200
Martin v. Löwis mar...@v.loewis.de wrote:
Am 27.08.2011 08:33, schrieb Terry Reedy:
On 8/26/2011 9:56 PM, Antoine Pitrou wrote:
Another interesting question is whether it's easy to port to the PEP
393 string representation, if it gets accepted.
On Sat, 27 Aug 2011 08:02:31 +0200
Martin v. Löwis mar...@v.loewis.de wrote:
I'm not sure it's worth doing an extensive review of the code, a better
approach might be to require extensive test coverage (and a review of
tests).
I think it's worth. It's really bad if only one developer
On 26 Aug, 09:45 pm, gu...@python.org wrote:
I just made a pass of all the Unicode-related bugs filed by Tom
Christiansen, and found that in several, the response was this is
fixed in the regex module [by Matthew Barnett]. I started replying
that I thought that we should fix the bugs in the re
On Fri, Aug 26, 2011 at 11:01 PM, Dan Stromberg drsali...@gmail.com wrote:
[Steven]
Have then been any __future__ features that were added provisionally?
I can't either, but ISTR hearing that from __future__ import was started
with such an intent. Irrespective, it's hard to import something
On Sat, Aug 27, 2011 at 9:19 AM, Guido van Rossum gu...@python.org wrote:
On Fri, Aug 26, 2011 at 11:01 PM, Dan Stromberg drsali...@gmail.com
wrote:
[Steven]
Have then been any __future__ features that were added provisionally?
I can't either, but ISTR hearing that from __future__ import
On Sat, Aug 27, 2011 at 11:48, Dan Stromberg drsali...@gmail.com wrote:
No, this was not the intent of __future__. The intent is that a
feature is desirable but also backwards incompatible (e.g. introduces
a new keyword) so that for 1 (sometimes more) releases we require the
users to use the
Am 27.08.2011 12:10, schrieb Antoine Pitrou:
On Sat, 27 Aug 2011 08:02:31 +0200
Martin v. Löwis mar...@v.loewis.de wrote:
I'm not sure it's worth doing an extensive review of the code, a better
approach might be to require extensive test coverage (and a review of
tests).
I think it's
On Sat, Aug 27, 2011 at 9:53 AM, Brian Curtin brian.cur...@gmail.comwrote:
On Sat, Aug 27, 2011 at 11:48, Dan Stromberg drsali...@gmail.com wrote:
No, this was not the intent of __future__. The intent is that a
feature is desirable but also backwards incompatible (e.g. introduces
a new
On 2011-08-27, at 2:20 PM, Dan Stromberg wrote:
On Sat, Aug 27, 2011 at 9:53 AM, Brian Curtin brian.cur...@gmail.com wrote:
On Sat, Aug 27, 2011 at 11:48, Dan Stromberg drsali...@gmail.com wrote:
No, this was not the intent of __future__. The intent is that a
feature is desirable but also
I disagree. The first paragraph says this has something to do with new
keywords. It doesn't appear to say what we expect users to -do- with
it. Both are important.
Well, users can use the new features...
Is it You'd better try this, because it's going in eventually. If you
don't try it
Dan Stromberg wrote:
On Sat, Aug 27, 2011 at 9:53 AM, Brian Curtin brian.cur...@gmail.comwrote:
On Sat, Aug 27, 2011 at 11:48, Dan Stromberg drsali...@gmail.com wrote:
No, this was not the intent of __future__. The intent is that a
feature is desirable but also backwards incompatible (e.g.
Nick Coghlan wrote:
The next step needed is for someone to volunteer to write and champion
a PEP that:
Would it be feasible and desirable to modify regex so
that it *is* backwards-compatible with re, with a view
to making it a drop-in replacement at some point?
If not, the PEP should discuss
On 8/27/2011 7:39 PM, Greg Ewing wrote:
Nick Coghlan wrote:
The next step needed is for someone to volunteer to write and champion
a PEP that:
Would it be feasible and desirable to modify regex so
that it *is* backwards-compatible with re, with a view
to making it a drop-in replacement at
On Sun, Aug 28, 2011 at 3:48 AM, Terry Reedy tjre...@udel.edu wrote:
These are reasons why both Ezio and I suggested on the tracker adding regex
without deleting re. (I personally would not mind just replacing re with
regex, but then I have no legacy re code to break. So I am not suggesting
On Sat, Aug 27, 2011 at 5:48 PM, Terry Reedy tjre...@udel.edu wrote:
Many of the things regex does differently might be called either bug fixes
or feature changes, depending on one's viewpoint. Regex should definitely
not be 'bug-compatible'.
Well, as you said, it depends on one's viewpoint.
On Sat, Aug 27, 2011 at 4:56 AM, Antoine Pitrou solip...@pitrou.net wrote:
On Sat, 27 Aug 2011 04:37:21 +0300
Ezio Melotti ezio.melo...@gmail.com wrote:
I'm not sure it's worth doing an extensive review of the code, a better
approach might be to require extensive test coverage (and a
On Sat, Aug 27, 2011 at 8:59 PM, Ezio Melotti ezio.melo...@gmail.com wrote:
On Sat, Aug 27, 2011 at 4:56 AM, Antoine Pitrou solip...@pitrou.net wrote:
On Sat, 27 Aug 2011 04:37:21 +0300
Ezio Melotti ezio.melo...@gmail.com wrote:
I'm not sure it's worth doing an extensive review of the
On 8/27/2011 11:54 PM, Guido van Rossum wrote:
If so, it would be like the decimal
module, which closely tracks the IEEE decimal standard, rather than the
binary float standard.
Well, I would hope that for each major Python version (i.e. 3.2,
3.3, 3.4, ...) we would pick a specific version of
Guido van Rossum wrote:
I just made a pass of all the Unicode-related bugs filed by Tom
Christiansen, and found that in several, the response was this is
fixed in the regex module [by Matthew Barnett]. I started replying
that I thought that we should fix the bugs in the re module (i.e.,
On Fri, Aug 26, 2011 at 3:09 PM, M.-A. Lemburg m...@egenix.com wrote:
Guido van Rossum wrote:
I just made a pass of all the Unicode-related bugs filed by Tom
Christiansen, and found that in several, the response was this is
fixed in the regex module [by Matthew Barnett]. I started replying
On Fri, 26 Aug 2011 15:18:35 -0700
Guido van Rossum gu...@python.org wrote:
I can't say I liked how that transition was handled last time around.
I really don't want to have to tell people Oh, that bug is fixed but
you have to use regex instead of re and then a few years later have
to tell
On Fri, Aug 26, 2011 at 3:33 PM, Antoine Pitrou solip...@pitrou.net wrote:
On Fri, 26 Aug 2011 15:18:35 -0700
Guido van Rossum gu...@python.org wrote:
I can't say I liked how that transition was handled last time around.
I really don't want to have to tell people Oh, that bug is fixed but
On Fri, Aug 26, 2011 at 2:45 PM, Guido van Rossum gu...@python.org wrote:
...but on second thought I wonder if maybe regex is
mature enough to replace re in Python 3.3.
I agree that the move from regex to re was kind of painful.
It seems someone should merge the unit tests for re and regex,
However, I don't know much about regex
The problem really is: nobody does (except for Matthew Barnett
probably). This means that this contribution might be stuck
forever: somebody would have to review the module, identify
issues, approve it, and take the blame if something breaks.
That takes
On Fri, Aug 26, 2011 at 3:54 PM, Martin v. Löwis mar...@v.loewis.de wrote:
However, I don't know much about regex
The problem really is: nobody does (except for Matthew Barnett
probably). This means that this contribution might be stuck
forever: somebody would have to review the module,
Guido van Rossum wrote:
On Fri, Aug 26, 2011 at 3:09 PM, M.-A. Lemburg m...@egenix.com wrote:
Guido van Rossum wrote:
I just made a pass of all the Unicode-related bugs filed by Tom
Christiansen, and found that in several, the response was this is
fixed in the regex module [by Matthew
On 27/08/2011 00:08, Tom Christiansen wrote:
M.-A. Lemburgm...@egenix.com wrote
on Sat, 27 Aug 2011 01:00:31 +0200:
The good part is that it's based on the re code, the FUD comes
from the fact that the new lib is 380kB larger than the old one
and that's not even counting the generated
On Fri, Aug 26, 2011 at 4:21 PM, MRAB pyt...@mrabarnett.plus.com wrote:
On 27/08/2011 00:08, Tom Christiansen wrote:
M.-A. Lemburgm...@egenix.com wrote
on Sat, 27 Aug 2011 01:00:31 +0200:
The good part is that it's based on the re code, the FUD comes
from the fact that the new lib is
M.-A. Lemburg m...@egenix.com wrote
on Sat, 27 Aug 2011 01:00:31 +0200:
The good part is that it's based on the re code, the FUD comes
from the fact that the new lib is 380kB larger than the old one
and that's not even counting the generated 500kB of lookup
tables.
Well, you have to put
On Fri, 26 Aug 2011 15:47:21 -0700
Guido van Rossum gu...@python.org wrote:
The best way would be to contact the author, Matthew Barnett,
I had added him to the beginning of this thread but someone took him off.
or to ask
on the tracker on http://bugs.python.org/issue2636. He has been
On Sat, 27 Aug 2011 01:00:31 +0200
M.-A. Lemburg m...@egenix.com wrote:
I can't say I liked how that transition was handled last time around.
I really don't want to have to tell people Oh, that bug is fixed but
you have to use regex instead of re and then a few years later have
to tell
On Fri, 26 Aug 2011 15:48:42 -0700
Dan Stromberg drsali...@gmail.com wrote:
Then there probably should be a from __future__ import for a while.
If you are willing to use a from __future__ import, why not simply
import regex as re
? We're not Perl, we don't have built-in syntactic support
On Fri, Aug 26, 2011 at 5:08 PM, Antoine Pitrou solip...@pitrou.net wrote:
On Fri, 26 Aug 2011 15:48:42 -0700
Dan Stromberg drsali...@gmail.com wrote:
Then there probably should be a from __future__ import for a while.
If you are willing to use a from __future__ import, why not simply
M.-A. Lemburg m...@egenix.com writes:
Guido van Rossum wrote:
I really don't want to have to tell people Oh, that bug is fixed
but you have to use regex instead of re and then a few years later
have to tell them Oh, we're deprecating regex, you should just use
re.
No, you tell them:
On Sat, Aug 27, 2011 at 1:57 AM, Guido van Rossum gu...@python.org wrote:
On Fri, Aug 26, 2011 at 3:54 PM, Martin v. Löwis mar...@v.loewis.de
wrote:
[...]
Among us, some are more regex gurus than others; you know
who you are. I guess the PSF would pay for the review, if that
is what it
Ben Finney wrote:
M.-A. Lemburg m...@egenix.com writes:
No, you tell them: If you want Unicode 6 semantics, use regex, if
you're fine with Unicode 2.0/3.0 semantics, use re.
What do we say, then, to those who are unaware of the different
semantics between those versions of Unicode, and want
On Sat, 27 Aug 2011 04:37:21 +0300
Ezio Melotti ezio.melo...@gmail.com wrote:
I'm not sure it's worth doing an extensive review of the code, a better
approach might be to require extensive test coverage (and a review of
tests). If the code seems well written, commented, documented (I think
On Fri, 26 Aug 2011 17:25:56 -0700
Dan Stromberg drsali...@gmail.com wrote:
On Fri, Aug 26, 2011 at 5:08 PM, Antoine Pitrou solip...@pitrou.net wrote:
On Fri, 26 Aug 2011 15:48:42 -0700
Dan Stromberg drsali...@gmail.com wrote:
Then there probably should be a from __future__ import for
Steven D'Aprano st...@pearwood.info writes:
Ben Finney wrote:
M.-A. Lemburg m...@egenix.com writes:
No, you tell them: If you want Unicode 6 semantics, use regex, if
you're fine with Unicode 2.0/3.0 semantics, use re.
What do we say, then, to those who are unaware of the different
Ben Finney wrote:
Steven D'Aprano st...@pearwood.info writes:
Ben Finney wrote:
M.-A. Lemburg m...@egenix.com writes:
No, you tell them: If you want Unicode 6 semantics, use regex, if
you're fine with Unicode 2.0/3.0 semantics, use re.
What do we say, then, to those who are unaware of the
Antoine Pitrou wrote:
On Fri, 26 Aug 2011 17:25:56 -0700
Dan Stromberg drsali...@gmail.com wrote:
[...]
If you add regex as import regex, and the new regex module doesn't work
out, regex might be harder to get rid of. from __future__ import is an
established way of trying something for a
54 matches
Mail list logo
