Victor brings up a good question in his review of the PEP 553 implementation.
The question is whether $PYTHONBREAKPOINT should be ignored if -E is given?
I think it makes sense for $PYTHONBREAKPOINT to be sensitive to -E, but in thinking about it some more, it might make better sense for the semantics to be that when -E is given, we treat it like PYTHONBREAKPOINT=0, i.e. disable the breakpoint, rather than fallback to the `pdb.set_trace` default.
My thinking is this: -E is often used in production environments to prevent stray environment settings from affecting the Python process. In those environments, you probably also want to prevent stray breakpoints from stopping the process, so it’s more helpful to disable breakpoint processing when -E is given rather than running pdb.set_trace().
If you have a strong opinion either way, please follow up here, on the PR, or on the bug tracker.
Hi all, It was suggested that I start a new thread, because the other
thread drifted away from its original topic. So here, in case someone is
On Oct 2, 2017 17:03, "Koos Zevenhoven <k7hoven(a)gmail.com> wrote:
On Mon, Oct 2, 2017 at 6:42 AM, Guido van Rossum <guido(a)python.org> wrote:
On Sun, Oct 1, 2017 at 1:52 PM, Koos Zevenhoven <k7hoven(a)gmail.com> wrote:
On Oct 1, 2017 19:26, "Guido van Rossum" <guido(a)python.org> wrote:
Your PEP is currently incomplete. If you don't finish it, it is not even a
contender. But TBH it's not my favorite anyway, so you could also just
I can withdraw it if you ask me to, but I don't want to withdraw it without
any reason. I haven't changed my mind about the big picture. OTOH, PEP 521
is elegant and could be used to implement PEP 555, but 521 is almost
certainly less performant and has some problems regarding context manager
wrappers that use composition instead of inheritance.
It is my understanding that PEP 521 (which proposes to add optional
__suspend__ and __resume__ methods to the context manager protocol, to be
called whenever a frame is suspended or resumed inside a `with` block) is
no longer a contender because it would be way too slow. I haven't read it
recently or thought about it, so I don't know what the second issue you
mention is about (though it's presumably about the `yield` in a context
manager implemented using a generator decorated with
Well, it's not completely unrelated to that. The problem I'm talking about
is perhaps most easily seen from a simple context manager wrapper that uses
composition instead of inheritance:
self._wrapped = SomeContextManager()
Now, if the wrapped contextmanager becomes a PEP 521 one with __suspend__
and __resume__, the Wrapper class is broken, because it does not respect
__suspend__ and __resume__. So actually this is a backwards compatiblity
But if the wrapper is made using inheritance, the problem goes away:
Now the wrapper cleanly inherits the new optional __suspend__ and
__resume__ from the wrapped context manager type.
+ Koos Zevenhoven + http://twitter.com/k7hoven +
Before deferring re.compile, can we make it faster?
I profiled `import string` and small optimization can make it 2x faster!
(but it's not backward compatible)
import time: self [us] | cumulative | imported package
import time: 2339 | 9623 | string
string module took about 2.3 ms to import.
* RegexFlag.__and__ and __new__ is called very often.
* _optimize_charset is slow, because re.UNICODE | re.IGNORECASE
diff --git a/Lib/sre_compile.py b/Lib/sre_compile.py
index 144620c6d1..7c662247d4 100644
@@ -582,7 +582,7 @@ def isstring(obj):
def _code(p, flags):
- flags = p.pattern.flags | flags
+ flags = int(p.pattern.flags) | int(flags)
code = 
# compile info block
diff --git a/Lib/string.py b/Lib/string.py
index b46e60c38f..fedd92246d 100644
@@ -81,7 +81,7 @@ class Template(metaclass=_TemplateMetaclass):
delimiter = '$'
idpattern = r'[_a-z][_a-z0-9]*'
braceidpattern = None
- flags = _re.IGNORECASE
+ flags = _re.IGNORECASE | _re.ASCII
def __init__(self, template):
self.template = template
import time: 1191 | 8479 | string
Of course, this patch is not backward compatible. [a-z] doesn't match with
'ı' or 'ſ' anymore.
But who cares?
# LATIN SMALL LETTER I, LATIN SMALL LETTER DOTLESS I
(0x69, 0x131), # iı
# LATIN SMALL LETTER S, LATIN SMALL LETTER LONG S
(0x73, 0x17f), # sſ
There are some other `re.I(GNORECASE)` options in stdlib. I'll check them.
More optimization can be done with implementing sre_parse and sre_compile
But I have no time for it in this year.
Inada Naoki <songofacandy(a)gmail.com>