Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

On Tue, Jun 26, 2018 at 05:42:43AM +1000, Chris Angelico wrote: > So. sublocal scopes, like in the earliest versions of PEP 572? > > The wheel turns round and round, and the same spokes come up. It isn't as if comprehensions (and generator expressions) run in a proper separate scope. It is

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

On 6/26/2018 10:36 PM, Guido van Rossum wrote: [This is my one response today] Thank you for clearly presenting how you see 'comprehension', 'generator expression' and by implication 'equivalent code'. The latter can either be a definition or an explanation. The difference is subtle but rea

Re: [Python-Dev] Policy on refactoring/clean up

On Wed, Jun 27, 2018 at 2:27 PM Jeroen Demeyer wrote: > On 2018-06-27 00:02, Guido van Rossum wrote: > > And TBH a desire to refactor a lot of code is often a sign of a > > relatively new contributor who hasn't learned their way around the code > > yet, so they tend to want to make the code follo

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

Steven D'Aprano wrote: ":=" is the second most common syntax used for assignment in common programming languages, Yes, but it represents an *ordinary* assigment in those languages. The special way that's being proposed to use it in Python is not obvious. -- Greg __

Re: [Python-Dev] Policy on refactoring/clean up

On 2018-06-27 00:02, Guido van Rossum wrote: And TBH a desire to refactor a lot of code is often a sign of a relatively new contributor who hasn't learned their way around the code yet, so they tend to want to make the code follow their understanding rather than letting their understanding follow

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

[This is my one response today] On Mon, Jun 25, 2018 at 12:40 PM Terry Reedy wrote: > On 6/24/2018 7:25 PM, Guido van Rossum wrote: > > I'd wager that the people who might be most horrified about it > > the (b) scoping rule change > > > would be people who feel strongly that the change to the >

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

On Mon, Jun 25, 2018 at 11:30:24AM +1200, Greg Ewing wrote: > Guido van Rossum wrote: > >Greg seem to be +0 or better for (a) > > Actually, I'm closer to -1 on (a) as well. I don't like := as a > way of getting assignment in an expression. The only thing I would > give a non-negative rating is som

Re: [Python-Dev] Policy on refactoring/clean up

I know there was a big follow-up already, but I'd like to point out that (while clearly not everyone feels the same) I am personally inclined to set the bar pretty high for refactoring that don't add functionality. It makes crawling through history using e.g. git blame harder, since the person who

Re: [Python-Dev] PEP 576

On 2018-06-26 21:43, Mark Shannon wrote: https://github.com/markshannon/pep-576 Your version of PEP 576 looks very different from the "official" PEP 576 at https://www.python.org/dev/peps/pep-0576/ So can you please make a pull request to https://github.com/python/peps/pulls Also feel free to

[Python-Dev] PEP 576

Hi all, Just a reminder that PEP 576 still exists as a lightweight alternative to PEP 575/580. It achieves the same goals as PEP 580 but is much smaller. https://github.com/markshannon/pep-576 Unless there is a big rush, I would like to do some experiments as to whether the new calling conve

Re: [Python-Dev] We now have C code coverage!

This is awesome, thank you Ammar! On 23 June 2018 at 06:21, Brett Cannon wrote: > Thanks to a PR from Ammar Askar we now run Python under lcov as part of > the code coverage build. And thanks to codecov.io automatically merging > code coverage reports we get a complete report of our coverage (th

Re: [Python-Dev] Policy on refactoring/clean up

On 26.06.2018 14:54, Ivan Pozdeev via Python-Dev wrote: On 26.06.2018 14:43, Jeroen Demeyer wrote: On 2018-06-26 13:11, Ivan Pozdeev via Python-Dev wrote: AFAICS, your PR is not a strict improvement What does "strict improvement" even mean? Many changes are not strict improvements, but still

Re: [Python-Dev] Policy on refactoring/clean up

On 06/26/18 14:13, Jeroen Demeyer wrote: On 2018-06-26 13:54, Ivan Pozdeev via Python-Dev wrote: This is exactly what that the YAGNI principle is about, and Inada was right to point to it. Until you have an immediate practical need for something, you don't really know the shape and form for it t

Re: [Python-Dev] Policy on refactoring/clean up

On 2018-06-26 13:54, INADA Naoki wrote: Real need is important than my preference. If it is needed PEP 580, I'm OK. Of course it's not needed. I never claimed that it was. I think it's *nice to have* right now and slightly more *nice to have* when changes/additions are made to call.c in the

Re: [Python-Dev] Policy on refactoring/clean up

On 2018-06-26 13:54, Ivan Pozdeev via Python-Dev wrote: This is exactly what that the YAGNI principle is about, and Inada was right to point to it. Until you have an immediate practical need for something, you don't really know the shape and form for it that you will be the most comfortable with.

Re: [Python-Dev] Policy on refactoring/clean up

On Tue, 26 Jun 2018 11:00:48 +0200 Jeroen Demeyer wrote: > Hello, > > On https://github.com/python/cpython/pull/7909 I encountered friction > for a PR which I expected to be uncontroversial: it just moves some code > without changing any functionality. > > So basically my question is: is there

Re: [Python-Dev] Policy on refactoring/clean up

On 26.06.2018 14:54, INADA Naoki wrote: On Tue, Jun 26, 2018 at 8:46 PM Jeroen Demeyer > wrote: On 2018-06-26 13:11, Ivan Pozdeev via Python-Dev wrote: > AFAICS, your PR is not a strict improvement What does "strict improvement" even mean? Many changes a

Re: [Python-Dev] Policy on refactoring/clean up

On 2018-06-26 13:54, INADA Naoki wrote: ​No, YAGNI is posted by someone and they removed their comment. Sorry for that, I misunderstood the email that GitHub sent me. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/li

Re: [Python-Dev] Policy on refactoring/clean up

On Tue, Jun 26, 2018 at 8:46 PM Jeroen Demeyer wrote: > On 2018-06-26 13:11, Ivan Pozdeev via Python-Dev wrote: > > AFAICS, your PR is not a strict improvement > > What does "strict improvement" even mean? Many changes are not strict > improvements, but still useful to have. > > Inada pointed me

Re: [Python-Dev] Policy on refactoring/clean up

On 26.06.2018 14:43, Jeroen Demeyer wrote: On 2018-06-26 13:11, Ivan Pozdeev via Python-Dev wrote: AFAICS, your PR is not a strict improvement What does "strict improvement" even mean? Many changes are not strict improvements, but still useful to have. Inada pointed me to YAGNI (https://en

Re: [Python-Dev] Policy on refactoring/clean up

On 2018-06-26 13:11, Ivan Pozdeev via Python-Dev wrote: AFAICS, your PR is not a strict improvement What does "strict improvement" even mean? Many changes are not strict improvements, but still useful to have. Inada pointed me to YAGNI (https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_

Re: [Python-Dev] Policy on refactoring/clean up

Hi, I created call.c when I worked on optimizations. I saw that performances depend on the code locality and that compilers are more eager to inline code when it's in the same file. Moreover, call.c now contains some private functions like function_code_fastcall() or _PyObject_CallFunctionVa() whi

Re: [Python-Dev] Policy on refactoring/clean up

On 26.06.2018 12:00, Jeroen Demeyer wrote: Hello, On https://github.com/python/cpython/pull/7909 I encountered friction for a PR which I expected to be uncontroversial: it just moves some code without changing any functionality. So basically my question is: is there some CPython policy *agai

Re: [Python-Dev] Policy on refactoring/clean up

26.06.18 12:11, INADA Naoki пише: FYI, I don't against general refactoring, when I agree it's really make code cleaner, readable. I against your PR because I didn't feel it really make code cleaner, readable. I already commented about it on the PR. https://github.com/python/cpython/pull/7909#

Re: [Python-Dev] Policy on refactoring/clean up

FYI, I don't against general refactoring, when I agree it's really make code cleaner, readable. I against your PR because I didn't feel it really make code cleaner, readable. I already commented about it on the PR. https://github.com/python/cpython/pull/7909#issuecomment-400219905 So it's not pro

[Python-Dev] Policy on refactoring/clean up

Hello, On https://github.com/python/cpython/pull/7909 I encountered friction for a PR which I expected to be uncontroversial: it just moves some code without changing any functionality. So basically my question is: is there some CPython policy *against* refactoring code to make it easier to

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

On 26.06.2018 1:58, Greg Ewing wrote: Chris Angelico wrote: The wheel turns round and round, and the same spokes come up. Unless there's a repository of prior discussion no-one can be bothered to gather scraps from around the Net. Wikis solve this by all the discussion being in one place,

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

On 26.06.2018 0:13, Steve Holden wrote: On Mon, Jun 25, 2018 at 8:37 PM, Terry Reedy > wrote: On 6/24/2018 7:25 PM, Guido van Rossum wrote: I'd wager that the people who might be most horrified about it the (b) scoping rule change would be peo

Re: [Python-Dev] [python-committers] 3.7.0 / 3.6.6 Update: all systems go for final releases!

Congrats, Ned. Thank you for all of your hard work! -- Eric > On Jun 26, 2018, at 2:39 AM, Ned Deily wrote: > > A quick update: after many months we are at the finish line. We are on > track (mixing metaphors) to release 3.7.0 (and 3.6.6) this week on > 2018-06-27. Since 3.7.0rc1 shipped 2 week