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

[Terry Reedy]

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 real, 
and, I believe, the essence of the disagreement over iteration 
variables.  If the code equivalent to a comprehension is its definition, 
like a macro expansion, then survival of the iteration variable is to be 
expected.  If the equivalent code is an explanation of the *result* of 
evaluating a *self-contained expression*, then leakage is easily seen a 
wart, just as leakage of temporaries from any other expression would be.


My interpretation of what you say below is that you always wanted, for 
instance, [i*i for i in iterable] == [j*j for j in iterable] to be true, 
and saw the leakage making this not quite true as a wart.  In other 
words, within comprehensions (including generator expressions) 
iterations names should be regarded as dummy placeholders and not part 
of the value.


If this is correct, the list comprehension syntax could have been
  [\0 * \0 for \0 in iterable]
with  \1, \2, ... used as needed. (I am using the regex back-reference 
notation in a way similar to the use of str.format forward reference 
notation.)


I will stop here for now, as it is 1:30 am for me.

Terry

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
 > comprehension scope rules in Python 3 is a big improvement,

I might not be one of those 'most horrified' by (b), but I increasingly
don't like it, and I was at best -0 on the comprehension scope change.
To me, iteration variable assignment in the current scope is a
non-problem.  So to me the change was mostly useless churn.  Little
benefit, little harm.  And not worth fighting when others saw a benefit.


Fair enough, and by itself this might not have been enough reason to 
make the change. But see below.


However, having made the change to nested scopes, I think we should
stick with them.  Or repeal them.  (I believe there is another way to
isolate iteration names -- see  below).  To me, (b) amounts to half
repealing the nested scope change, making comprehensions half-fowl,
half-fish chimeras.


That depends on how you see it -- to me (b) just means that there's an 
implicit nonlocal[1] to make the assignment have the (desirable) 
side-effect.


The key thing to consider here is whether that side-effect is in fact 
desirable. For me, the side-effect of the comprehension's loop control 
variable was never desirable -- it was just an implementation detail 
leaking out. (And that's different from leaking a regular for-loop's 
control variable -- since we have 'break' (and 'else') there are some 
legitimate use cases. But comprehensions try to be expressions, and here 
the side effect is at best useless and at worst a nasty surprise.)


 > and who are familiar with the difference in implementation
 > of comprehensions (though not generator expressions) in Python 2
vs. 3.

That I pretty much am, I think.  In Python 2, comprehensions (the fish)
were, at least in effect, expanded in-line to a normal for loop.
Generator expressions (the fowls) were different.  They were, and still
are, expanded into a temporary generator function whose return value is
dropped back into the original namespace.  Python 3 turned
comprehensions (with 2 news varieties thereof) into fowls also,
temporary functions whose return value is dropped back in the original
namespace.  The result is that a list comprehension is equivalent to
list(generator_ expression), even though, for efficiency, it is not
implemented that way.  (To me, this unification is more a benefit than
name hiding.)


Right, and this consistency convinced me that the change was worth it. I 
just really like to be able to say "[... for ...]" is equivalent to 
"list(... for ...)", and similar for set and dict.


(b) proposes to add extra hidden code in and around the temporary
function to partly undo the isolation.


But it just adds a nonlocal declaration. There's always some hidden code 
('def' and 'return' at the very least).


list comprehensions would no
longer be equivalent to list(generator_expression), unless
generator_expressions got the same treatment, in which case they would
no longer be equivalent to calling the obvious generator function.
Breaking either equivalence might break someone's code.


Ah, there's the rub! I should probably apologize for not clarifying my 
terminology more. In the context of PEP 572, when I say "comprehensions" 
I include 

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

[INADA Naoki]

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 follow their understanding
> > rather than letting their understanding follow the code.
>
> ...or it could be that the code is written the way it is only for
> historical reasons, instead of bei
> ​​
> ng purposely written that way.
>

In
​​
this
​time, I suppose you thought .c <=> .h filename should be matched.
And we don't think so.

Header files are organized for exposing APIs,
and source files are
organized for implementing
​the ​
APIs.
​Since goal is different,
they
​aren't​
match
​ed​
always.​
​​

​Regards,​
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Greg Ewing]

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

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Jeroen Demeyer]

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 the code.


...or it could be that the code is written the way it is only for 
historical reasons, instead of being purposely written that way.

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Guido van Rossum]

[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
> > comprehension scope rules in Python 3 is a big improvement,
>
> I might not be one of those 'most horrified' by (b), but I increasingly
> don't like it, and I was at best -0 on the comprehension scope change.
> To me, iteration variable assignment in the current scope is a
> non-problem.  So to me the change was mostly useless churn.  Little
> benefit, little harm.  And not worth fighting when others saw a benefit.
>

Fair enough, and by itself this might not have been enough reason to make
the change. But see below.


> However, having made the change to nested scopes, I think we should
> stick with them.  Or repeal them.  (I believe there is another way to
> isolate iteration names -- see  below).  To me, (b) amounts to half
> repealing the nested scope change, making comprehensions half-fowl,
> half-fish chimeras.
>

That depends on how you see it -- to me (b) just means that there's an
implicit nonlocal[1] to make the assignment have the (desirable)
side-effect.

The key thing to consider here is whether that side-effect is in fact
desirable. For me, the side-effect of the comprehension's loop control
variable was never desirable -- it was just an implementation detail
leaking out. (And that's different from leaking a regular for-loop's
control variable -- since we have 'break' (and 'else') there are some
legitimate use cases. But comprehensions try to be expressions, and here
the side effect is at best useless and at worst a nasty surprise.)


> > and who are familiar with the difference in implementation
> > of comprehensions (though not generator expressions) in Python 2 vs. 3.
>
> That I pretty much am, I think.  In Python 2, comprehensions (the fish)
> were, at least in effect, expanded in-line to a normal for loop.
> Generator expressions (the fowls) were different.  They were, and still
> are, expanded into a temporary generator function whose return value is
> dropped back into the original namespace.  Python 3 turned
> comprehensions (with 2 news varieties thereof) into fowls also,
> temporary functions whose return value is dropped back in the original
> namespace.  The result is that a list comprehension is equivalent to
> list(generator_ expression), even though, for efficiency, it is not
> implemented that way.  (To me, this unification is more a benefit than
> name hiding.)
>

Right, and this consistency convinced me that the change was worth it. I
just really like to be able to say "[... for ...]" is equivalent to
"list(... for ...)", and similar for set and dict.


> (b) proposes to add extra hidden code in and around the temporary
> function to partly undo the isolation.


But it just adds a nonlocal declaration. There's always some hidden code
('def' and 'return' at the very least).


> list comprehensions would no
> longer be equivalent to list(generator_expression), unless
> generator_expressions got the same treatment, in which case they would
> no longer be equivalent to calling the obvious generator function.
> Breaking either equivalence might break someone's code.
>

Ah, there's the rub! I should probably apologize for not clarifying my
terminology more. In the context of PEP 572, when I say "comprehensions" I
include generators! PEP 572 states this explicitly (
https://github.com/python/peps/blame/master/pep-0572.rst#L201-L202).

Certainly PEP 572 intends to add that implicit nonlocal to both
comprehensions and generator expressions. (I just got really tired of
writing that phrase over and over, and at some point I forgot that this is
only a parenthetical remark added in the PEP's latest revision, and not
conventional terminology -- alas. :-)

Part (b) of PEP 572 does several things of things to *retain* consistency:

- The target of := lives in the same scope regardless of whether it occurs
in a comprehension, a generator expression, or just in some other
expression.

- When it occurs in a comprehension or generator expression, the scope is
the same regardless of whether it occurs in the "outermost iterable" or not.

If we didn't have (b) the target would live in the comprehension/genexpr
scope if it occurred in a comprehension/genexp but outside its "outermost
iterable", and in the surrounding scope otherwise.


> ---
>
> How loop variables might be isolated without a nested scope: After a
> comprehension is parsed, so that names become strings, rename the loop
> variables to something otherwise illegal.  For instance, i could become
> '', just as lambda becomes '' as the name of the resulting
> function.  Expand the comprehension as in Python 2, except for deleting
> the loop names along with the temporary result name.
>
> Assignment expressions within a comprehension would 

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

[Steven D'Aprano]

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 some form of "where" or "given".
> 
> Brief summary of reasons for disliking ":=":
> 
> * Cryptic use of punctuation

":=" is the second most common syntax used for assignment in common 
programming languages, not just Pascal. Even modern languages like Go 
use it. If that's "cryptic", what word would you use to describe 
@decorator syntax? *wink*

Honestly Greg, can you put your hand on your heart and swear that if you 
came across "name := expression" in source code you wouldn't be able to 
hazard a guess as the meaning of the := operator?


> * Too much overlap in functionality with "="

If you are willing to consider a non-negative rating under the 
"given/willing"spelling, presumably the "overlap in functionality" isn't 
that important. (Otherwise it would be an argument against the feature 
*regardless of spelling*.)

So why should it be an argument against the := spelling?


> * Asymmetry between first and subsequent uses of the bound value

I don't know what this means.


> * Makes expressions cluttered and hard to read to my eyes

And Nick's more verbose "given" proposal makes expressions less 
cluttered?

result = process(first=(spam := ham or eggs), second=spam*5)

result = process(first=(spam given spam = ham or eggs), second=spam*5)


The := spelling has three syntactic elements: the target name, the := 
operator itself, and the expression being assigned.

The syntax you are willing to consider has five elements: an arbitrarily 
complex return expression, the keyword "given", the target name, the = 
operator, and the expression being assigned.

It isn't rational to say that adding extra complexity and more syntactic 
elements *reduces* clutter. At the minimum, Nick's syntax requires:

- an extra keyword ("given" or "where")

- a repetitive, redundant, repeated use of the target name

just to save one : character. That adds, not subtracts, clutter.

Aside from the asymmetry issue (which I don't understand) it seems that 
most of your arguments against := apply equally, or even more strongly, 
to the "expr given name = expr" version.

I know matters of taste are deeply subjective, but we ought to 
distinguish between *subjective* and *irrational* reasons for disliking 
proposed features, and try to resist the irrational ones:

"We should change the spelling of set.add to set.append, as
that will remove the troublesome double-letter, and reduce
typing."

*wink*



-- 
Steve
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Guido van Rossum]

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
last refactored the code ends up owning it even though they weren't
responsible for all its intricacies (which might separately be blame-able
on many different commits).

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 the code.

Also see https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence


On Tue, Jun 26, 2018 at 2:03 AM 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 *against*
> refactoring code to make it easier to read and write? (Note that I'm not
> talking about pure style issues here)
>
> Background: cpython has a source file "call.c" (introduced in
> https://github.com/python/cpython/pull/12) but the corresponding
> declarations are split over several .h files. While working on PEP 580,
> I found this slightly confusing. I decided that it would make more sense
> to group all these declarations in a new file "call.h". That's what PR
> 7909 does. In my opinion, the resulting code is easier to read. It also
> defines a clear place for declarations of future functionality added to
> "call.c" (for example, if we add a public API for FASTCALL). Finally, I
> added/clarified a few comments.
>
> I expected the PR to be either ignored or accepted. However, I received
> a negative reaction from Inada Naoki on it.
>
> I don't mind closing the PR and keeping the status quo if there is a
> general agreement. However, I'm afraid that a future reviewer of PEP 580
> might say "your includes are a mess" and he will be right.
>
>
> Jeroen.
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/guido%40python.org
>


-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 576

[Jeroen Demeyer]

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 add pointers to your PEP on PEP 579.


Jeroen.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] PEP 576

[Mark Shannon]

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 convention should be


typedef (*callptr)(PyObject *func, PyObject *const *stack,
   Py_ssize_t nargs, PyObject *kwnames);

or whether the increased generality of:

typedef (*callptr)(PyObject *func, PyObject *const *stack,
   Py_ssize_t nargs, PyObject *kwnames,
   PyTupleObject *starargs, PyObject *kwdict);

is a worthwhile enhancement.


An implementation can be found here:
https://github.com/python/cpython/compare/master...markshannon:pep-576-minimal


Cheers,
Mark.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Dima Tisnek]

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 (the first
> results of which can now be seen at https://codecov.io/gh/python/cpython).
>
> And funny enough the coverage average changed less than 1%. :)
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> dimaqq%40gmail.com
>
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Ivan Pozdeev via Python-Dev]

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 useful to have.


Inada pointed me to YAGNI 
(https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it) but I 
disagree with that premise: there is a large gray zone between 
"completely useless" and "really needed". My PR falls in that gap of 
"nice to have but we can do without it".



You may suggest it as a supplemental PR to PEP 580. Or even a part of
it, but since the changes are controversial, better make the
refactorings into separate commits so they can be rolled back 
separately

if needed.


If those refactorings are rejected now, won't they be rejected as 
part of PEP 580 also?


This is exactly what that the YAGNI principle is about, and Inada was 
right to point to it.


Strike this part out since he didn't actually say that as it turned out.

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. Thus any "would be nice to have" tinkerings are 
essentially a waste of time and possibly a degradation, too: you'll 
very likely have to change them again when the real need arises -- 
while having to live with any drawbacks in the meantime.


So, if you suggest those changes together with the PEP 580 PR, they 
will be reviewed through the prism of the new codebase and its needs, 
which are different from the current codebase and its needs.



___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/vano%40mail.mipt.ru




--
Regards,
Ivan

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Petr Viktorin]

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 that you will
be the most comfortable with. Thus any "would be nice to have"
tinkerings are essentially a waste of time and possibly a degradation,
too: you'll very likely have to change them again when the real need
arises -- while having to live with any drawbacks in the meantime.


It is important to clarify that this is exactly what I did. I *have* an 
implementation of PEP 580 and it's based on that PR 7909.


I just think that this PR makes sense independently of whether PEP 580 
will be accepted.



So, if you suggest those changes together with the PEP 580 PR


That sounds like a bad idea because that would be mixing two issues in 
one PR. If I want to increase my chances of getting PEP 580 and its 
implementation accepted, I shouldn't bring in unrelated changes.


To put it in a different perspective: if somebody else would make a PR 
to one of my projects doing a refactoring and adding new features, I 
would ask them to split it up.


Actually, that's exactly what we *did* ask Jeroen with his earlier 
proposal for PEP 575, where the implementation ended up being quite big. 
Split the changes to make it more manageable.


Unfortunately I haven't had time to study this PR yet (work is taking 
all my time lately), but I trust that Jeroen will propose actual 
improvements on top of the clean-up.

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Jeroen Demeyer]

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 future.

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Jeroen Demeyer]

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. Thus any "would be nice to have"
tinkerings are essentially a waste of time and possibly a degradation,
too: you'll very likely have to change them again when the real need
arises -- while having to live with any drawbacks in the meantime.


It is important to clarify that this is exactly what I did. I *have* an 
implementation of PEP 580 and it's based on that PR 7909.


I just think that this PR makes sense independently of whether PEP 580 
will be accepted.



So, if you suggest those changes together with the PEP 580 PR


That sounds like a bad idea because that would be mixing two issues in 
one PR. If I want to increase my chances of getting PEP 580 and its 
implementation accepted, I shouldn't bring in unrelated changes.


To put it in a different perspective: if somebody else would make a PR 
to one of my projects doing a refactoring and adding new features, I 
would ask them to split it up.

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Antoine Pitrou]

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 some CPython policy *against* 
> refactoring code to make it easier to read and write? (Note that I'm not 
> talking about pure style issues here)

I think refactorings are generally ok, assuming they bring a
substantial maintainability or readability benefit.  I haven't studied
your PR enough to decide whether that's the case for the changes you
are proposing, though.

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Ivan Pozdeev via Python-Dev]

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 are not strict
improvements, but still useful to have.

Inada pointed me to YAGNI


​No, YAGNI is posted by someone and they removed their comment.


Yes, that was me instead.
I posted it and then changed my mind. Apparently, notifications were 
sent nonetheless.

I didn't watch the thread and kinda assumed that you pointed that out, too.
(Just to put everything straight and not make anyone suspect I'm trying 
to pull the wool over anyone's eyes here.)




My point was:

Moving code around makes:

  * hard to track history.

  * hard to backport patches to old branches.

https://github.com/python/cpython/pull/7909#issuecomment-400219905

And I prefer keeping definitions relating to​ methods in methodobject.h to
move them to call.h only because they're used/implemented in call.c

(https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it) but I
disagree with that premise: there is a large gray zone between
"completely useless" and "really needed". My PR falls in that gap of
"nice to have but we can do without it".


​So I didn't think even it is "nice to have".​

> You may suggest it as a supplemental PR to PEP 580. Or even a
part of
> it, but since the changes are controversial, better make the
> refactorings into separate commits so they can be rolled back
separately
> if needed.

If those refactorings are rejected now, won't they be rejected as
part
of PEP 580 also?


Real need is important than my preference.  If it is needed PEP 580, 
I'm OK.

But I didn't know which part of the PR is required by PEP 580.

Regards,

--
INADA Naoki  mailto:songofaca...@gmail.com>>


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/vano%40mail.mipt.ru


--
Regards,
Ivan

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Jeroen Demeyer]

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/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[INADA Naoki]

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 to YAGNI
>

​No, YAGNI is posted by someone and they removed their comment.

My point was:

Moving code around makes:
>
>- hard to track history.
>
>
>- hard to backport patches to old branches.
>
>  https://github.com/python/cpython/pull/7909#issuecomment-400219905

And I prefer keeping definitions relating to​ methods in methodobject.h to
move them to call.h only because they're used/implemented in call.c



> (https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it) but I
> disagree with that premise: there is a large gray zone between
> "completely useless" and "really needed". My PR falls in that gap of
> "nice to have but we can do without it".
>
>
​So I didn't think even it is "nice to have".​



> > You may suggest it as a supplemental PR to PEP 580. Or even a part of
> > it, but since the changes are controversial, better make the
> > refactorings into separate commits so they can be rolled back separately
> > if needed.
>
> If those refactorings are rejected now, won't they be rejected as part
> of PEP 580 also?
>

Real need is important than my preference.  If it is needed PEP 580, I'm OK.
But I didn't know which part of the PR is required by PEP 580.

Regards,

-- 
INADA Naoki  
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Ivan Pozdeev via Python-Dev]

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.wikipedia.org/wiki/You_aren%27t_gonna_need_it) but I 
disagree with that premise: there is a large gray zone between 
"completely useless" and "really needed". My PR falls in that gap of 
"nice to have but we can do without it".



You may suggest it as a supplemental PR to PEP 580. Or even a part of
it, but since the changes are controversial, better make the
refactorings into separate commits so they can be rolled back separately
if needed.


If those refactorings are rejected now, won't they be rejected as part 
of PEP 580 also?


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. Thus any "would be nice to have" 
tinkerings are essentially a waste of time and possibly a degradation, 
too: you'll very likely have to change them again when the real need 
arises -- while having to live with any drawbacks in the meantime.


So, if you suggest those changes together with the PEP 580 PR, they will 
be reviewed through the prism of the new codebase and its needs, which 
are different from the current codebase and its needs.



___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/vano%40mail.mipt.ru


--
Regards,
Ivan

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Jeroen Demeyer]

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_it) but I 
disagree with that premise: there is a large gray zone between 
"completely useless" and "really needed". My PR falls in that gap of 
"nice to have but we can do without it".



You may suggest it as a supplemental PR to PEP 580. Or even a part of
it, but since the changes are controversial, better make the
refactorings into separate commits so they can be rolled back separately
if needed.


If those refactorings are rejected now, won't they be rejected as part 
of PEP 580 also?

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Victor Stinner]

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() which are called from other public
functions. Without call.c, some of these functions should be make
"public" (exposed) which has also an impact on performance. Putting
all these functions in the same file helps the compiler to produce
more efficient code, but should also prevent inconsistencies when we
modify a calling convention.

I'm not sure of the rationale behind the proposed call.h header. Is it
difficult to maintain actual definitions in multiple header files? I'm
used to them, it's easy to discover them, so *I* am not really
convinced that call.h adds any value. I also expect fewer changes in
header changes than in the implementation (call.c).

Victor

2018-06-26 11:11 GMT+02:00 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#issuecomment-400219905
>
> So it's not problem about general policy about refactoring / clean up.
> It's just my preference.  If Victor and Serhiy prefer the PR, I'm OK to
> merge it.
>
> Regards,
>
> --
> INADA Naoki  
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/vstinner%40redhat.com
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Ivan Pozdeev via Python-Dev]

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 *against* 
refactoring code to make it easier to read and write? (Note that I'm 
not talking about pure style issues here)


Background: cpython has a source file "call.c" (introduced in 
https://github.com/python/cpython/pull/12) but the corresponding 
declarations are split over several .h files. While working on PEP 
580, I found this slightly confusing. I decided that it would make 
more sense to group all these declarations in a new file "call.h". 
That's what PR 7909 does. In my opinion, the resulting code is easier 
to read. It also defines a clear place for declarations of future 
functionality added to "call.c" (for example, if we add a public API 
for FASTCALL). Finally, I added/clarified a few comments.


I expected the PR to be either ignored or accepted. However, I 
received a negative reaction from Inada Naoki on it.


I don't mind closing the PR and keeping the status quo if there is a 
general agreement. However, I'm afraid that a future reviewer of PEP 
580 might say "your includes are a mess" and he will be right.


AFAICS, your PR is not a strict improvement, that's the reason for the 
"friction".
You may suggest it as a supplemental PR to PEP 580. Or even a part of 
it, but since the changes are controversial, better make the 
refactorings into separate commits so they can be rolled back separately 
if needed.




Jeroen.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/vano%40mail.mipt.ru


--
Regards,
Ivan

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Serhiy Storchaka]

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#issuecomment-400219905

So it's not problem about general policy about refactoring / clean up.
It's just my preference.  If Victor and Serhiy prefer the PR, I'm OK to 
merge it.


I'm with Inada.

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[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#issuecomment-400219905

So it's not problem about general policy about refactoring / clean up.
It's just my preference.  If Victor and Serhiy prefer the PR, I'm OK to
merge it.

Regards,

-- 
INADA Naoki  
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Policy on refactoring/clean up

[Jeroen Demeyer]

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 read and write? (Note that I'm not 
talking about pure style issues here)


Background: cpython has a source file "call.c" (introduced in 
https://github.com/python/cpython/pull/12) but the corresponding 
declarations are split over several .h files. While working on PEP 580, 
I found this slightly confusing. I decided that it would make more sense 
to group all these declarations in a new file "call.h". That's what PR 
7909 does. In my opinion, the resulting code is easier to read. It also 
defines a clear place for declarations of future functionality added to 
"call.c" (for example, if we add a public API for FASTCALL). Finally, I 
added/clarified a few comments.


I expected the PR to be either ignored or accepted. However, I received 
a negative reaction from Inada Naoki on it.


I don't mind closing the PR and keeping the status quo if there is a 
general agreement. However, I'm afraid that a future reviewer of PEP 580 
might say "your includes are a mess" and he will be right.



Jeroen.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Ivan Pozdeev via Python-Dev]

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, and even they 
struggle is there were multiple.



A discussion long past, and a discussion yet to come.

There are no beginnings or endings in the Wheel of Python...



--
Regards,
Ivan

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Ivan Pozdeev via Python-Dev]

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 people who feel strongly that the change to the
comprehension scope rules in Python 3 is a big improvement,


I might not be one of those 'most horrified' by (b), but I
increasingly don't like it, and I was at best -0 on the
comprehension scope change. To me, iteration variable assignment
in the current scope is a non-problem.  So to me the change was
mostly useless churn.  Little benefit, little harm.  And not worth
fighting when others saw a benefit.

However, having made the change to nested scopes, I think we
should stick with them.  Or repeal them.  (I believe there is
another way to isolate iteration names -- see below).  To me, (b)
amounts to half repealing the nested scope change, making
comprehensions half-fowl, half-fish chimeras.

​[...]​

-- 
Terry Jan Reedy


​I'd like to ask: how many readers of ​
​this email have ever deliberately taken advantage of the limited 
Python 3 scope in comprehensions and generator expressions to use what 
would otherwise be a conflicting local variable name?​


I did:

for l in (l.rstrip() for l in f):

The provisional unstripped line variable is totally unneeded in the 
following code.




I appreciate that the scope limitation can sidestep accidental naming 
errors, which is a good thing.


Unfortunately, unless we anticipate Python 4 (or whatever) also making 
for loops have an implicit scope, I am left wondering whether it's not 
too large a price to pay. After all, special cases aren't special 
enough to break the rules, and unless the language is headed towards 
implicit scope for all uses of "for" one could argue that the scope 
limitation is a special case too far. It certainly threatens to be yet 
another confusion for learners, and while that isn't the only 
consideration, it should be given due weight.



___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/vano%40mail.mipt.ru


--
Regards,
Ivan

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Eric V. Smith]

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 weeks ago, I am aware of only two
> noteworthy regressions that have been identified and now fixed. Since
> the issues for both have the potential to impact some (but small)
> subsets of 3.7.0 users and the fixes for both are straightforward and
> appear to be low-risk, I am planning to cherry-pick the fixes for them
> into 3.7.0 final without either another release candidate cycle or
> waiting for 3.7.1. There may be some doc fixes that get cherry-picked
> as well. At the moment, there are no plans for any bug cherry-picks for
> 3.6.6 final.
> 
> As you know, a new feature release is a big deal and something for all
> of us to be proud of.  A new feature release also has various, mostly
> minor, impacts to lots of different parts of our development
> infrastructure: to multiple branches of the cpython repo, to
> documentation builds, to different parts of the python.org web site,
> etc. You will start to see some of the changes roll out over the next 24
> to 36 hours and it may take some time until everything is in place.
> So please be patient until the official release announcement goes out
> before reporting release-related issues. Also be advised that over the
> same period, there may be a few brief periods where commit access to
> various cpython branches is blocked in order to do the necessary
> release engineering. If you run into this, for example when trying to
> merge a PR, please try again in a few hours.
> 
> Thanks and more later!
> 
> https://bugs.python.org/issue33851
> https://bugs.python.org/issue33932
> 
> --
>  Ned Deily
>  n...@python.org -- []
> 
> ___
> python-committers mailing list
> python-committ...@python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Ned Deily]

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 weeks ago, I am aware of only two
noteworthy regressions that have been identified and now fixed. Since
the issues for both have the potential to impact some (but small)
subsets of 3.7.0 users and the fixes for both are straightforward and
appear to be low-risk, I am planning to cherry-pick the fixes for them
into 3.7.0 final without either another release candidate cycle or
waiting for 3.7.1. There may be some doc fixes that get cherry-picked
as well. At the moment, there are no plans for any bug cherry-picks for
3.6.6 final.

As you know, a new feature release is a big deal and something for all
of us to be proud of.  A new feature release also has various, mostly
minor, impacts to lots of different parts of our development
infrastructure: to multiple branches of the cpython repo, to
documentation builds, to different parts of the python.org web site,
etc. You will start to see some of the changes roll out over the next 24
to 36 hours and it may take some time until everything is in place.
So please be patient until the official release announcement goes out
before reporting release-related issues. Also be advised that over the
same period, there may be a few brief periods where commit access to
various cpython branches is blocked in order to do the necessary
release engineering. If you run into this, for example when trying to
merge a PR, please try again in a few hours.

Thanks and more later!

https://bugs.python.org/issue33851
https://bugs.python.org/issue33932

--
  Ned Deily
  n...@python.org -- []

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com