Hi,
Stéphane Wirtel gave a talk last month at Pycon CA about CPython pull
requests. His slides:
https://speakerdeck.com/matrixise/cpython-loves-your-pull-requests
He produced interesting statistics that we didn't have before on pull
requests (PR), from February 2017 to October 2017:
* total
I've been discussing this PEP offline with Victor, but he suggested we
should discuss it in public instead.
I am very worried about this long and rambling PEP, and I propose that it
not be accepted without a major rewrite to focus on clarity of the
specification. The "Unicode just works" summary
On Tue, Dec 5, 2017 at 11:11 AM, Barry Warsaw wrote:
> On Dec 5, 2017, at 13:24, Guido van Rossum wrote:
>
> > But the whole point of the PEP is that it only warns about deprecations
> in code over which the user has control -- likely __main__ is their own
>
On 12/4/2017 6:21 PM, MRAB wrote:
I've finally come to a conclusion as to what the "correct" behaviour of
zero-width matches should be: """always return the first match, but
never a zero-width match that is joined to a previous zero-width match""".
Is this different from current re or regex?
2017-12-05 22:18 GMT+01:00 Guido van Rossum :
> So I guess PEP acceptance week is over. :-(
My bad, Barry wrote "PEP Acceptance Day", not week, on twitter ;-)
https://twitter.com/pumpichank/status/937770805076905990
Victor
___
On Tue, 5 Dec 2017 at 08:31 Senthil Kumaran wrote:
> On Tue, Dec 5, 2017 at 6:25 AM, Victor Stinner
> wrote:
>
>> Stéphane Wirtel gave a talk last month at Pycon CA about CPython pull
>> requests. His slides:
>>
>>
Hi,
Thank you for this post to python-dev.
About my talk, it was a real pleasure to give it at PyCon Canada, and I
hope I could propose it to PyCon US for a larger public.
But the goal behind this talk was to show that we have a good community,
firstly by the external contributors and by the
2017-12-05 19:24 GMT+01:00 Guido van Rossum :
>> I disagree that *users* of an application is supposed to "handle"
>> deprecation warnings: report them to the developer, or even try to fix
>> them. IHMO these warnings (hidden by default) were introduced for
>> developers of the
On Tue, Dec 5, 2017 at 12:10 PM, Victor Stinner
wrote:
> 2017-12-05 19:24 GMT+01:00 Guido van Rossum :
> >> I disagree that *users* of an application is supposed to "handle"
> >> deprecation warnings: report them to the developer, or even try to fix
>
05.12.17 22:10, Victor Stinner пише:
Maybe we need something to declare the code that we own, to
enable warnings on them.
Just compare __author__ with the name of the user running a script. ;-)
___
Python-Dev mailing list
Python-Dev@python.org
2017-12-05 21:21 GMT+01:00 Serhiy Storchaka :
> 05.12.17 22:10, Victor Stinner пише:
>>
>> Maybe we need something to declare the code that we own, to
>> enable warnings on them.
>
> Just compare __author__ with the name of the user running a script. ;-)
I was thinking as
Hi Mariatta,
Thank you, I was really happy to see you at my talk, usually this kind
of talk is boring ;-) just kidding, but usually I prefer a technical talk.
Le 05/12/17 à 16:25, Mariatta Wijaya a écrit :
> I saw the talk in person :) Congrats Stéphane!
>
> You can get the reviews from a
On Tue, 5 Dec 2017 19:46:39 +0100
Stephane Wirtel via Python-Dev wrote:
> But seriously, I was surprised by the number of Pull Requests and by the
> number of contributors from Feb 2017 to Oct 2017.
>
> Here is my graph for October and November 2017.
Is it possible to
On Tue, Dec 5, 2017 at 6:25 AM, Victor Stinner
wrote:
> Stéphane Wirtel gave a talk last month at Pycon CA about CPython pull
> requests. His slides:
>
>https://speakerdeck.com/matrixise/cpython-loves-your-pull-requests
>
> He produced interesting statistics that we
On Tue, Dec 5, 2017 at 9:59 AM, Victor Stinner
wrote:
> 2017-12-05 16:50 GMT+01:00 Guido van Rossum :
> > Honestly, I didn't completely follow what Victor thinks of the PEP -- his
> > post seemed mostly about promoting his own -X dev flag.
>
> -X dev
On Dec 5, 2017, at 13:24, Guido van Rossum wrote:
> But the whole point of the PEP is that it only warns about deprecations in
> code over which the user has control -- likely __main__ is their own code,
> and they *can* handle it.
I’m not so sure how true that is. I have
2017-12-05 16:50 GMT+01:00 Guido van Rossum :
> Honestly, I didn't completely follow what Victor thinks of the PEP -- his
> post seemed mostly about promoting his own -X dev flag.
-X dev is similar (but different) than -W default: show warnings which
are hidden by default
On 2017-12-05 20:26, Terry Reedy wrote:
On 12/4/2017 6:21 PM, MRAB wrote:
I've finally come to a conclusion as to what the "correct" behaviour of
zero-width matches should be: """always return the first match, but
never a zero-width match that is joined to a previous zero-width match""".
Is
On Tue, Dec 5, 2017 at 1:18 PM, Guido van Rossum wrote:
>
>
> I am very worried about this long and rambling PEP,
>
FWIW, I read the PEP on the bus this morning on a phone, and while lng, I
didn't find it too rambling. And this topic has been very often discussed
in very long
Chris:
> I just took another look at 538 -- and yes, the relationship between the two
> is really unclear. In particular, with 538, why do we need 540? I honestly
> don't know.
The PEP 538 only impacts platforms which provide the C.UTF-8 locale or
a variant: only a few recent Linux distribution.
Hi,
I knew that I had to rewrite my PEP 540, but I was too lazy. Since
Guido explicitly requested a shorter PEP, here you have!
https://www.python.org/dev/peps/pep-0540/
Trust me, it's the same PEP, but focused on the most important
information and with a shorter rationale ;-)
Full text below.
> Annex: Differences between the PEP 538 and the PEP 540
> ==
>
> The PEP 538 uses the "C.UTF-8" locale which is quite new and only
> supported by a few Linux distributions; this locale is not currently
> supported by FreeBSD or macOS for
On 6 December 2017 at 05:11, Barry Warsaw wrote:
> On Dec 5, 2017, at 13:24, Guido van Rossum wrote:
>
>> But the whole point of the PEP is that it only warns about deprecations in
>> code over which the user has control -- likely __main__ is their own code,
On 6 December 2017 at 12:51, Eric Snow wrote:
> Hi all,
>
> I've finally updated PEP 554. Feedback would be most welcome. The
> PEP is in a pretty good place now and I hope to we're close to a
> decision to accept it. :)
Nice updates! I like this version.
> In
On Wed, Dec 6, 2017 at 4:46 PM, Nick Coghlan wrote:
> Something I've just noticed that needs to be clarified: on Linux, "C"
> locale and "POSIX" locale are aliases, but this isn't true in general
> (e.g. it's not the case on *BSD systems, including Mac OS X).
For those of us
On 12/5/2017 10:25 AM, Mariatta Wijaya wrote:
* Time to merge a PR: 3 days in average, good!
Slide said 2.98 days, another said 4.4% by developers.
Regarding the average time to merge PR, I'm interested to know the
average time to merge for PRs not made by Python Core Devs.
Trivially
On 6 December 2017 at 11:01, Victor Stinner wrote:
>> Annex: Differences between the PEP 538 and the PEP 540
>> ==
>>
>> The PEP 538 uses the "C.UTF-8" locale which is quite new and only
>> supported by a few Linux
Announcing the immediate availability of Python 3.6.4 release candidate 1
and of Python 3.7.0 alpha 3!
Python 3.6.4rc1 is the first release candidate for Python 3.6.4, the next
maintenance release of Python 3.6. While 3.6.4rc1 is a preview release and,
thus, not intended for production
Oh, revised version is really short!
And I have one worrying point.
With UTF-8 mode, open()'s default encoding/error handler is
UTF-8/surrogateescape.
Containers are really growing. PyCharm supports Docker and many new Python
developers use Docker instead of installing Python directly on their
Something I've just noticed that needs to be clarified: on Linux, "C"
locale and "POSIX" locale are aliases, but this isn't true in general
(e.g. it's not the case on *BSD systems, including Mac OS X).
To handle that in PEP 538, I made it clear that everything is keyed
specifically off the "C"
On 6 December 2017 at 06:43, Victor Stinner wrote:
> At the end, I'm not sure that the PEP 565 is really needed or would help
> anyone.
Folks, I'd really appreciate it if you could comment on the merits of
the PEP without implicitly claiming that I don't exist, and
I'm sorry about my laziness.
I've very busy these months, but I'm back to OSS world from today.
While I should review carefully again, I think I'm close to accept PEP 540.
* PEP 540 really helps containers and old Linux machines PEP 538 doesn't work.
And containers is really important for
On 6 December 2017 at 14:34, Nick Coghlan wrote:
> That said, I go agree we could offer easier to use APIs to app
> developers that just want to hide warnings from their users, so I've
> filed https://bugs.python.org/issue32229 to propose a straightforward
>
On 12/5/2017 8:07 PM, INADA Naoki wrote:
Oh, revised version is really short!
And I have one worrying point.
With UTF-8 mode, open()'s default encoding/error handler is
UTF-8/surrogateescape.
Containers are really growing. PyCharm supports Docker and many new Python
developers use Docker
On 12/06/2017 03:51 AM, Eric Snow wrote:
Hi all,
I've finally updated PEP 554. Feedback would be most welcome. The
PEP is in a pretty good place now and I hope to we're close to a
decision to accept it. :)
[...]
C-extension opt-in/opt-out
--
By using the
On 6 December 2017 at 16:18, Glenn Linderman wrote:
> "b" mostly matters on Windows, correct? And Windows doesn't use C or POSIX
> locale, correct? And if these are correct, then is this an issue? And if so,
> why?
In Python 3, "b" matters everywhere, since it controls
Hi all,
I've finally updated PEP 554. Feedback would be most welcome. The
PEP is in a pretty good place now and I hope to we're close to a
decision to accept it. :)
In addition to resolving the open questions, I've also made the
following changes to the PEP:
* put an API summary at the top
On 6 December 2017 at 15:59, Chris Angelico wrote:
> On Wed, Dec 6, 2017 at 4:46 PM, Nick Coghlan wrote:
>> Something I've just noticed that needs to be clarified: on Linux, "C"
>> locale and "POSIX" locale are aliases, but this isn't true in general
>>
If you ask me this PEP is not going to make everyone happy, but I think it
is an improvement, and it seems many people are in agreement or at least
don't object to it (and obviously Nick thinks it's going to be a big
improvement).
Therefore I am planning to accept it by the end of this week
Hi,
Since it's the PEP Acceptance Week, I try my luck! Here is my very
long PEP to propose a tiny change. The PEP is very long to explain the
rationale and limitations.
Inaccurate tl; dr with the UTF-8 mode, Unicode "just works" as expected.
Reminder: INADA Naoki was nominated as the
I saw the talk in person :) Congrats Stéphane!
You can get the reviews from a specific PR using the API:
https://developer.github.com/v3/pulls/reviews/#list-reviews-on-a-pull-request
For example, for reviews made to CPython PR number 1:
41 matches
Mail list logo