Re: [Python-Dev] Benchmarks why we need PEP 576/579/580

[Jeroen Demeyer]

On 2018-07-22 08:27, INADA Naoki wrote:

It's interesting... But I failed to build sage.


What went wrong?


It's build step is
too different from
normal Python package.


That's true because Sage considers itself a distribution rather than a 
package. But it's possible to pick the distribution apart and build just 
the Python package "sage". In fact, various Linux distros package Sage 
that way. The reason for it being a distribution is mainly that it has a 
huge number of dependencies (many of them not Python), so it wouldn't be 
possible to do "pip install sage" anyway.



It tooks very long time to build.


That's just a matter of waiting a few hours.


And
"install from source"
document only describe step to `./sage` command work.  It doesn't describe
step to `improt sage` works.


Those two are pretty much equivalent. If you really want just the 
latter, you can run "make sageruntime" in the Sage root.



Target application should be easy to test, benchmark and profile for all of
core-devs interesting in these PEPs.


I feel like the bar for this PEP is being raised all the time. First, 
you ask for an application benchmark and I provided an application 
benchmark. Now you complain that my application is not suitable. Why 
don't you just believe my timings?



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] Benchmarks why we need PEP 576/579/580

[Jeroen Demeyer]

On 2018-07-22 01:14, Guido van Rossum wrote:

Jeroen was asked to provide benchmarks
but only provided them for Python 2. The reasoning that not much has
changed that could affect the benchmarks feels a bit optimistic, that’s all.


The micro-benchmarks showed a clear difference on Python 3.8 (git 
master) between tp_call and optimized call paths.


The application benchmark on Python 2.7.15 shows that the difference 
between tp_call and optimized call paths matters in real applications.


I agree that this isn't 100% bullet-proof evidence, but at least it's a 
strong indication that it might be worth it to start discussing the 
actual PEP.



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] Benchmarks why we need PEP 576/579/580

[Stefan Behnel]

Guido van Rossum schrieb am 22.07.2018 um 01:14:
> The cost would be if we were to end up maintaining all that code and it
> wouldn’t make much difference.

Well, this is exactly my point. Someone has to maintain the *existing* code
base and help newcomers to get into it and understand it. This is not easy.
The proposed implementation *already* makes a difference. And it does not
even degrade the performance while doing that, isn't that great?

To make this clear – right now, there is someone who stands up and
volunteers to invest the work to clean up the current implementation. He
has already designed, and even implemented, a protocol that applies to all
types of callables in the same way *and* that is extensible for current and
future needs and optimisations. I think this is way more than anyone could
ask for, and it would be very sad if this chance was wasted, and we would
have to remain with the current implementation.

Stefan

___
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] Benchmarks why we need PEP 576/579/580

[Guido van Rossum]

OK, I believe you, I was just referring to the relative irreproducibility
of Jeroen's results (see INADA Naoki's problems).

My main point is actually that until the Python core devs have elected a
new BDFL or come up with some other process for accepting PEPs, no action
will be taken on this PEP -- AFAIK there's no BDFL-Delegate for this PEP.
You can argue until you're blue in the face, but the new process won't be
ready until Jan 2019. (Read the python-committers archives, e.g.
https://mail.python.org/pipermail/python-committers/2018-July/005935.html.)

To make this clear -- right now, there is no-one who can approve this PEP,
and you will have to wait until 2019 until there is.

Of course you can form a subcommittee where you try to agree on the
details, and I recommend that. But getting argumentative on python-dev is
not going to be very productive. In 2019 people will remember that you were
very forceful in taking your position, not what that position was or why
it's reasonable.

Sorry I don't have better news.

On Sun, Jul 22, 2018 at 5:52 AM, Stefan Behnel  wrote:

> Guido van Rossum schrieb am 22.07.2018 um 01:14:
> > The cost would be if we were to end up maintaining all that code and it
> > wouldn’t make much difference.
>
> Well, this is exactly my point. Someone has to maintain the *existing* code
> base and help newcomers to get into it and understand it. This is not easy.
> The proposed implementation *already* makes a difference. And it does not
> even degrade the performance while doing that, isn't that great?
>
> To make this clear – right now, there is someone who stands up and
> volunteers to invest the work to clean up the current implementation. He
> has already designed, and even implemented, a protocol that applies to all
> types of callables in the same way *and* that is extensible for current and
> future needs and optimisations. I think this is way more than anyone could
> ask for, and it would be very sad if this chance was wasted, and we would
> have to remain with the current implementation.
>
> Stefan
>
> ___
> 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] Benchmarks why we need PEP 576/579/580

[Jeroen Demeyer]

On 2018-07-22 18:14, Guido van Rossum wrote:

Sorry I don't have better news.


I don't consider that particularly bad news (but not good news either). 
I feel like the status on PEP 580 isn't anywhere near accepted anyway.


I just hope that Python development won't stall completely. Even if no 
formal action can be taken on this PEP (or any other), I hope that there 
will still be informal discussion.



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] Benchmarks why we need PEP 576/579/580

[Jeroen Demeyer]

On 2018-07-22 14:52, Stefan Behnel wrote:

Someone has to maintain the *existing* code
base and help newcomers to get into it and understand it.


This is an important point that people seem to be overlooking. The 
complexity and maintenance burden of PEP 580 should be compared to the 
status-quo. The existing code is complicated, yet nobody seems to find 
that a problem. But when PEP 580 makes changes to that complicated code 
(and documents some of the existing complexity), it's suddenly the fault 
of PEP 580 that the code is complicated.


I also wonder if there is a psychological difference simply because this 
is a PEP and not an issue on bugs.python.org. That might give the 
impression that it's a more serious thing somehow. Previous 
optimizations (https://bugs.python.org/issue26110 for example) were not 
done in a PEP and nobody ever mentioned that the extra complexity might 
be a problem.


Finally, in some ways, my PEP would actually be a simplification because 
it replaces several special cases by one general protocol. Admittedly, 
the general protocol that I propose is more complicated than each 
existing special case individually but the overall complexity might 
actually decrease.



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] Finding Guido's replacement

[Chris Angelico]

Guido's term as Benevolent Dictator For Life has been a long one, but
in the wake of his resignation, we have an opportunity to correct some
fundamental flaws in the system. Among them:

* Guido lacks patience, as evidenced by the brevity of his acceptance
posts. See 
https://mail.python.org/pipermail/python-dev/2017-December/151038.html
and https://mail.python.org/pipermail/python-dev/2011-November/114545.html
and particularly
https://mail.python.org/pipermail/python-dev/2016-May/144646.html
where Guido specifically cites his own lack of patience.

* Lately, all Guido's actions have been to benefit his employer, not
the Common Pythonista. We have proof of this from reliable reporting
sources such as Twitter and social media.

* Finally, "For Life" is far too long. We need to change our rulers
periodically.

I propose a new way to appoint a project head. All candidates shall be
flown to an island owned by the Python Secret Underground (which
emphatically does NOT exist, but an island that would be owned by it
if it did), whereupon they parachute down, search for guns, and
proceed to fight each other until only one is left alive. The survivor
shall be treated to a chicken dinner and proclaimed Patient,
Understanding, Benevolent Governor, a title which shall be retained
for one fortnight, after which we repeat the exercise.

If this plan meets with broad approval, I shall write up PEP 3401, in
honour of the prior art in PEP 401.

ChrisA
___
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] Benchmarks why we need PEP 576/579/580

[Antoine Pitrou]

On Sun, 22 Jul 2018 22:11:25 +0200
Jeroen Demeyer  wrote:
> On 2018-07-22 14:52, Stefan Behnel wrote:
> > Someone has to maintain the *existing* code
> > base and help newcomers to get into it and understand it.  
> 
> This is an important point that people seem to be overlooking. The 
> complexity and maintenance burden of PEP 580 should be compared to the 
> status-quo. The existing code is complicated, yet nobody seems to find 
> that a problem. But when PEP 580 makes changes to that complicated code 
> (and documents some of the existing complexity), it's suddenly the fault 
> of PEP 580 that the code is complicated.
> 
> I also wonder if there is a psychological difference simply because this 
> is a PEP and not an issue on bugs.python.org. That might give the 
> impression that it's a more serious thing somehow. Previous 
> optimizations (https://bugs.python.org/issue26110 for example) were not 
> done in a PEP and nobody ever mentioned that the extra complexity might 
> be a problem.

Two things:
- the issue26110 changes are not very large, it's just two additional
  opcodes and a bit of support code
- more importantly, issue26110 is entirely internal changes, while you
  are proposing to add a new protocol (which is like a new API)

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] Benchmarks why we need PEP 576/579/580

[Jeroen Demeyer]

On 2018-07-22 22:32, Antoine Pitrou wrote:

Two things:
- the issue26110 changes are not very large, it's just two additional
   opcodes and a bit of support code


I didn't mean to compare PEP 580 to that specific issue, it was just an 
example. Even if issue26110 is small, the total complexity added by many 
incremental changes can still be big.



- more importantly, issue26110 is entirely internal changes, while you
   are proposing to add a new protocol (which is like a new API)


Just to make sure I understand you: your point is that it's 
automatically more complicated because it's an API instead of an 
internal change?

___
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] Benchmarks why we need PEP 576/579/580

[Stefan Behnel]

Jeroen Demeyer schrieb am 22.07.2018 um 22:54:
> On 2018-07-22 22:32, Antoine Pitrou wrote:
>> - more importantly, issue26110 is entirely internal changes, while you
>>    are proposing to add a new protocol (which is like a new API)
> 
> Just to make sure I understand you: your point is that it's automatically
> more complicated because it's an API instead of an internal change?

I think it's more that it changes something substantial in a way that is
not just internal but visible to users. I think it's more than just a
tracker issue and worth going through the PEP process.

Stefan

___
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] Benchmarks why we need PEP 576/579/580

[Antoine Pitrou]

On Sun, 22 Jul 2018 22:54:24 +0200
Jeroen Demeyer  wrote:
> 
> > - more importantly, issue26110 is entirely internal changes, while you
> >are proposing to add a new protocol (which is like a new API)  
> 
> Just to make sure I understand you: your point is that it's 
> automatically more complicated because it's an API instead of an 
> internal change?

No, what I mean here is that adding a public API requires additional
thought compared to adding an internal optimization (the internal
optimization can easily be reverted if there's a problem, while the
public API can not).  Hence the preference for a PEP.

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] Benchmarks why we need PEP 576/579/580

[Guido van Rossum]

On Sun, Jul 22, 2018 at 1:11 PM, Jeroen Demeyer  wrote:

> On 2018-07-22 14:52, Stefan Behnel wrote:
>
>> Someone has to maintain the *existing* code
>> base and help newcomers to get into it and understand it.
>>
>
> This is an important point that people seem to be overlooking. The
> complexity and maintenance burden of PEP 580 should be compared to the
> status-quo. The existing code is complicated, yet nobody seems to find that
> a problem. But when PEP 580 makes changes to that complicated code (and
> documents some of the existing complexity), it's suddenly the fault of PEP
> 580 that the code is complicated.
>
> I also wonder if there is a psychological difference simply because this
> is a PEP and not an issue on bugs.python.org. That might give the
> impression that it's a more serious thing somehow. Previous optimizations (
> https://bugs.python.org/issue26110 for example) were not done in a PEP
> and nobody ever mentioned that the extra complexity might be a problem.
>
> Finally, in some ways, my PEP would actually be a simplification because
> it replaces several special cases by one general protocol. Admittedly, the
> general protocol that I propose is more complicated than each existing
> special case individually but the overall complexity might actually
> decrease.


So does your implementation of the PEP result in a net increase or decrease
of the total lines of code? I know that that's a poor proxy for complexity
(we can all imagine example bits of code that would become less complex by
rewriting them in more lines), but if your diff actually deleted more lines
than it adds, that would cut short a lot of discussion. I have a feeling
though that that's not the case, and now you're in the defense.

-- 
--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] Finding Guido's replacement

[Eric Fahlgren]

On Sun, Jul 22, 2018 at 1:19 PM Chris Angelico  wrote:

> * Finally, "For Life" is far too long. We need to change our rulers
> periodically.
>

​With the proposed bi-weekly death matches, "for life" may actually be too
short.​
___
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] Benchmarks why we need PEP 576/579/580

[Ivan Pozdeev via Python-Dev]

I think it'll benefit all to keep the discussion objective, or at least 
"good subjective" 
(https://stackoverflow.blog/2010/09/29/good-subjective-bad-subjective/). 
Laments or mutual accusations are only wasting everyone's time, 
including the writers.
It's strange that even Guido jumped on the bandwagon -- since he's 
supposed to have had lots of experience to tell right away when a 
discussion has become unproductive. (Or maybe he's testing us?)



All the material to discuss that we have in this thread is a single test 
result that's impossible to reproduce and impossible to run in Py3.


All that this shows is that the PEPs will _likely_ substantially improve 
performance in some scenarios. It's however impossible to say from this 
how frequent these scenarios are in practice, and how consistent the 
improvement is among them. Likewise, it's impossible to say anything 
about the complexity the changes will reduce/introduce without a 
proof-of-concept implementation. So while this is an argument in favor 
of the PEPs, it's too flimsy _on its own_ to accept anything. More and 
better tests and/or sample implementations are needed to say anything 
more conclusive.


All that was already pointed out, and that's where the thread should 
have ended IMO 'cuz there's nothing else to say on the matter.



On 23.07.2018 1:28, Guido van Rossum wrote:
On Sun, Jul 22, 2018 at 1:11 PM, Jeroen Demeyer > wrote:


On 2018-07-22 14:52, Stefan Behnel wrote:

Someone has to maintain the *existing* code
base and help newcomers to get into it and understand it.


This is an important point that people seem to be overlooking. The
complexity and maintenance burden of PEP 580 should be compared to
the status-quo. The existing code is complicated, yet nobody seems
to find that a problem. But when PEP 580 makes changes to that
complicated code (and documents some of the existing complexity),
it's suddenly the fault of PEP 580 that the code is complicated.

I also wonder if there is a psychological difference simply
because this is a PEP and not an issue on bugs.python.org
. That might give the impression that it's
a more serious thing somehow. Previous optimizations
(https://bugs.python.org/issue26110
 for example) were not done in
a PEP and nobody ever mentioned that the extra complexity might be
a problem.

Finally, in some ways, my PEP would actually be a simplification
because it replaces several special cases by one general protocol.
Admittedly, the general protocol that I propose is more
complicated than each existing special case individually but the
overall complexity might actually decrease.


So does your implementation of the PEP result in a net increase or 
decrease of the total lines of code? I know that that's a poor proxy 
for complexity (we can all imagine example bits of code that would 
become less complex by rewriting them in more lines), but if your diff 
actually deleted more lines than it adds, that would cut short a lot 
of discussion. I have a feeling though that that's not the case, and 
now you're in the defense.


--
--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/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] Finding Guido's replacement

[Ivan Pozdeev via Python-Dev]

Whatever you decide, please research existing practices and their 
results so as not to repeat the same mistakes as others made before you.
In particular, http://meatballwiki.org/wiki/BenevolentDictator and 
https://en.wikipedia.org/wiki/Anti-pattern .
It would be a waste if Python falls victim to the same trapping as 
thousands before it.



On 22.07.2018 23:12, Chris Angelico wrote:

Guido's term as Benevolent Dictator For Life has been a long one, but
in the wake of his resignation, we have an opportunity to correct some
fundamental flaws in the system. Among them:

* Guido lacks patience, as evidenced by the brevity of his acceptance
posts. See 
https://mail.python.org/pipermail/python-dev/2017-December/151038.html
and https://mail.python.org/pipermail/python-dev/2011-November/114545.html
and particularly
https://mail.python.org/pipermail/python-dev/2016-May/144646.html
where Guido specifically cites his own lack of patience.

* Lately, all Guido's actions have been to benefit his employer, not
the Common Pythonista. We have proof of this from reliable reporting
sources such as Twitter and social media.

* Finally, "For Life" is far too long. We need to change our rulers
periodically.

I propose a new way to appoint a project head. All candidates shall be
flown to an island owned by the Python Secret Underground (which
emphatically does NOT exist, but an island that would be owned by it
if it did), whereupon they parachute down, search for guns, and
proceed to fight each other until only one is left alive. The survivor
shall be treated to a chicken dinner and proclaimed Patient,
Understanding, Benevolent Governor, a title which shall be retained
for one fortnight, after which we repeat the exercise.

If this plan meets with broad approval, I shall write up PEP 3401, in
honour of the prior art in PEP 401.

ChrisA
___
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] Finding Guido's replacement

[Abdur-Rahmaan Janhangeer]

sometimes back after the event the BDFL1 said that "the new BDFL might be
less demanding"

hint to an imminent new one? i won't tell much the core devs (not all) have
already shown their preferences

fun fact: weirdly enough after BDFL1 took a vac (for life?), google made
it's appearance on the mailing list

THE NEED FOR CENTRAL AUTHORITY

there is an absolute need for a central coordinator. the main threat to
open source projects is politics. when you have someone to settle stuffs,
fine you move on

PROCEDURE OF ACCEPTANCE

since BDFL1 is still alive, that saves the community some trouble. he is i
presume aware of py-related stuffs and his choosing of a successor is a
most viable option

PREMISE OF CHOICE

the choice should be made in consultation with the core devs as they are
recognised members of the community based on their contributions. the core
devs should orient the choice, they in themselves have not the power to
veto, topple or reverse the decision. in the unlikely case of complete
unfavouritism, the BDFL1 can pursue further

CORE DEVS AS COMMITTEE

the above hints to the core devs as a body in itself, beyond programming

VALIDITY OF CHOICE

the choice of BDFL1 must be acknowledged by the community. psf members
should vote of whether they like the choice or not, fir it is the users who
make the language valuable. by psf members, reference is made to the basic
type of membership, open to all py programmers who have agreed to the psf
rules. in case of non agreement, the process is to be repeated

CRITICISM OF THE BDFLs BY FORMER AND LATTER ONES

no BFFL shall criticise others. in case of non-acceptance of actions, a PHA
shall be submitted

PHA

a Python Halt Appeal is a document submitted to the current core devs and
the current BDFL to halt a specific activity considered "nuisible" to the
growth and development of python. in case of majority acceptance of the
core devs, it shall be accepted

THE NEED FOR ALTERNATIVE NAMING OF DICTATOR OR EMPHASISING THE MEANING

the python leader if he has absolute power should not be questioned or
should not be made to back out as his appointment is by definition

CITING THIS DOCUMENT / LICENSE

this mail can be freely used, modified or built upon provided that
attribution is made to the author in clear ways with no obfuscation
whatsoever

Abdur-Rahmaan Janhangeer
https://github.com/Abdur-rahmaanJ
Mauritius
___
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