On 3 October 2017 at 11:31, Eric Snow wrote:
> There shouldn't be a need to synchronize on INCREF. If both
> interpreters have at least 1 reference then either one adding a
> reference shouldn't be a problem. If only one interpreter has a
> reference then the other won't be adding any references
On 3 October 2017 at 03:13, Koos Zevenhoven wrote:
> 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:
>
> class Wrapper:
> def __init__(self):
>
On 3 October 2017 at 03:02, Christian Heimes wrote:
> On 2017-10-02 16:59, Barry Warsaw wrote:
>> On Oct 2, 2017, at 10:48, Christian Heimes wrote:
>>>
>>> That approach could work, but I think that it is the wrong approach. I'd
>>> rather keep Python optimized for long-running processes and intr
Hi,
Good news: Python 3.6.3 has no more known security vulnerabilities ;-)
Python 3.6.3 fixes two security vulnerabilities:
"urllib FTP protocol stream injection"
https://python-security.readthedocs.io/vuln/urllib_ftp_protocol_stream_injection.html
"Expat 2.2.3" (don't impact Linux, since Linux
On behalf of the Python development community and the Python 3.6
release team, I am happy to announce the availability of Python 3.6.3,
the third maintenance release of Python 3.6. Detailed information
about the changes made in 3.6.3 can be found in the change log here:
https://docs.python.org/3.
On Tue, Oct 3, 2017, at 08:03, Barry Warsaw wrote:
> Guido van Rossum wrote:
> > There have been no further comments. PEP 552 is now accepted.
> >
> > Congrats, Benjamin! Go ahead and send your implementation for review.Oops.
> > Let me try that again.
>
> While I'm very glad PEP 552 has been a
On 03Oct2017 0755, Antoine Pitrou wrote:
On Tue, 3 Oct 2017 08:36:55 -0600
Eric Snow wrote:
On Tue, Oct 3, 2017 at 5:00 AM, Antoine Pitrou wrote:
On Mon, 2 Oct 2017 22:15:01 -0400
Eric Snow wrote:
I'm still not convinced that sharing synchronization primitives is
important enough to be wor
26.09.17 23:47, Guido van Rossum пише:
I've read the current version of PEP 552 over and I think everything
looks good for acceptance. I believe there are no outstanding objections
(or they have been adequately addressed in responses).
Therefore I intend to accept PEP 552 this Friday, unless g
03.10.17 18:15, Guido van Rossum пише:
It's really not that hard. You just check the magic number and if it's
the new one, skip 4 words. No need to understand the internals of the
header.
Hence you should know all old magic numbers to determine if the read
magic number is the new one. Right?
I'm fine with adding an API, though I don't think that an API that knows
about all current (historic) and future formats belongs in importlib.util
-- that module only concerns itself with the *current* format.
In terms of the API design I'd make take an IO[bytes] and just read and
parse the header
03.10.17 17:21, Barry Warsaw пише:
What if the compiler could recognize constant arguments to re.compile() and do
the regex compilation at that point? You’d need a way to represent the
precompiled regex in the bytecode, and it would technically be a semantic
change since regex problems would
On Tue, 3 Oct 2017 08:15:04 -0700
Guido van Rossum wrote:
> It's really not that hard. You just check the magic number and if it's the
> new one, skip 4 words. No need to understand the internals of the header.
Still, I agree with Barry that an API would be nice.
Regards
Antoine.
>
> On Oct 3
It's really not that hard. You just check the magic number and if it's the
new one, skip 4 words. No need to understand the internals of the header.
On Oct 3, 2017 08:06, "Barry Warsaw" wrote:
> Guido van Rossum wrote:
> > There have been no further comments. PEP 552 is now accepted.
> >
> > Con
INADA Naoki schrieb am 03.10.2017 um 05:29:
> Before deferring re.compile, can we make it faster?
I tried cythonizing both sre_compile.py and sre_parse.py, which gave me a
speedup of a bit more than 2x. There is definitely space left for further
improvements since I didn't know much about the code
Guido van Rossum wrote:
> There have been no further comments. PEP 552 is now accepted.
>
> Congrats, Benjamin! Go ahead and send your implementation for review.Oops.
> Let me try that again.
While I'm very glad PEP 552 has been accepted, it occurs to me that it
will now be more difficult to pars
Hi,
On Mon, Oct 2, 2017 at 11:42 AM, Raymond Hettinger <
raymond.hettin...@gmail.com> wrote:
>
>
> I don't expect to find anything that would help users of Django, Flask,
> and Bottle since those are typically long-running apps where we value
> response time more than startup time.
>
Actually, as
On Tue, 3 Oct 2017 08:36:55 -0600
Eric Snow wrote:
> On Tue, Oct 3, 2017 at 5:00 AM, Antoine Pitrou wrote:
> > On Mon, 2 Oct 2017 22:15:01 -0400
> > Eric Snow wrote:
> >>
> >> I'm still not convinced that sharing synchronization primitives is
> >> important enough to be worth including it in t
On Tue, Oct 3, 2017 at 5:00 AM, Antoine Pitrou wrote:
> On Mon, 2 Oct 2017 22:15:01 -0400
> Eric Snow wrote:
>>
>> I'm still not convinced that sharing synchronization primitives is
>> important enough to be worth including it in the PEP. It can be added
>> later, or via an extension module in t
On Tue, 3 Oct 2017 10:21:55 -0400
Barry Warsaw wrote:
> On Oct 3, 2017, at 01:41, Serhiy Storchaka wrote:
> >
> > 03.10.17 06:29, INADA Naoki пише:
> >> More optimization can be done with implementing sre_parse and sre_compile
> >> in C.
> >> But I have no time for it in this year.
> >
> >
On Oct 3, 2017, at 01:41, Serhiy Storchaka wrote:
>
> 03.10.17 06:29, INADA Naoki пише:
>> More optimization can be done with implementing sre_parse and sre_compile in
>> C.
>> But I have no time for it in this year.
>
> And please don't do this! This would make maintaining the re module hard.
On Oct 3, 2017, at 01:35, Serhiy Storchaka wrote:
>
>> diff --git a/Lib/string.py b/Lib/string.py
>> index b46e60c38f..fedd92246d 100644
>> --- a/Lib/string.py
>> +++ b/Lib/string.py
>> @@ -81,7 +81,7 @@ class Template(metaclass=_TemplateMetaclass):
>> delimiter = '$'
>> idpattern = r'[
On Mon, 2 Oct 2017 22:15:01 -0400
Eric Snow wrote:
>
> I'm still not convinced that sharing synchronization primitives is
> important enough to be worth including it in the PEP. It can be added
> later, or via an extension module in the meantime. To that end, I'll
> add a mechanism to the PEP f
I've probably missed a lot of this discussion, but this lazy import
discussion confuses me. We already have both eager import (import at the
top of the file), and lazy import (import right before use).
The former is good when you know you need the module, and the latter is
good when you having the
> * RegexFlag.__and__ and __new__ is called very often.
Yeah, when the re module was modified to use enums for flags,
re.compile() became slower:
https://pyperformance.readthedocs.io/cpython_results_2017.html#slowdown
https://speed.python.org/timeline/#/?exe=12&ben=regex_compile&env=1&revs=200&eq
24 matches
Mail list logo
