Patrick Maupin added the comment:
You are correct that I have conflated two issues, but they are not orthogonal
-- if you choose to use relative imports, you will never encounter this issue,
because your imports will all be of the 'from ... import' form.
(And, as you point out, the fact
Patrick Maupin added the comment:
concurrent/futures/__init__.py may be a better example than 2to3 for this
issue. It's relatively new code, it's part of the standard library, it's
fairly small and self-contained, and it doesn't follow the promulgated standard.
If it's bad code, it should
Patrick Maupin added the comment:
I don't think anything is wrong with that code. But PEP 8 prescribes a way of
doing something that often won't work (which is unusual for PEP 8), with no
discussion of this fact.
> I think the key thing to take away from this whole discussion is "do
Patrick Maupin added the comment:
The PEP 8 recommendation to "use absolute imports" is completely, totally,
unambiguously meaningless absent the expectation that packages refer to parts
of themselves. And it works, too! (For a single level of package.)
As soon as packages
Patrick Maupin added the comment:
I'm a big fan of stitching things together at the top myself -- maybe that's
partly an unconscious reaction to this very issue.
But I'm not sanguine about how easy it is to express this practice in the docs.
This issue arose in the context of me answering
Patrick Maupin added the comment:
(stuff about cPython)
No, I was curious about whether somebody maintained pure-Python fixes (e.g. to
the re parser and compiler). Those could be in a regular package that fixed
some corner cases such as the capture group you just applied a patch
Patrick Maupin added the comment:
Example
text = 'test1/1.jp2'
text.rstrip('.2jp')
'test1/1'
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24445
Patrick Maupin added the comment:
I think you misunderstand rstrip -- it works from the right, and checks to see
if the right-most character is in the string you have given it. As long as it
is, then it will remove the character and loop
--
nosy: +Patrick Maupin
Patrick Maupin added the comment:
Thank you for the quick response, Serhiy. I had started investigating and come
to the conclusion that it was a problem with the compiler rather than the C
engine. Interestingly, my next step was going to be to use names for the
compiler constants
New submission from Patrick Maupin:
The addition of a capturing group in a re.split() pattern, e.g. using '(\n)'
instead of '\n', causes a factor of 10 performance degradation.
I use re.split a() lot, but never noticed the issue before. It was extremely
noticeable on 1000 patterns in a 5BG
Patrick Maupin added the comment:
1) I have obviously oversimplified my test case, to the point where a developer
thinks I'm silly enough to reach for the regex module just to split on a
linefeed.
2) '\n(?=(\n))' -- yes, of course, any casual user of the re module would
immediately choose
Patrick Maupin added the comment:
Just to be perfectly clear, this is no exaggeration:
My original file was slightly over 5GB.
I have approximately 1050 bad strings in it, averaging around 11 characters per
string.
If I split it without capturing those 1050 strings, it takes 3.7 seconds
12 matches
Mail list logo
