date:20210513

[Python-Dev] Re: PEP 659: Specializing Adaptive Interpreter

2021-05-13 Thread Terry Reedy


On 5/12/2021 1:40 PM, Mark Shannon wrote:

This is an informational PEP about a key part of our plan to improve 
CPython performance for 3.11 and beyond.


What is the purpose of this PEP?  It seems in part to be like a 
Standards Track PEP in that it proposes a new (revised) implementation 
idea for the CPython bycode interpreter.  Do you not intend this to not 
constitute approval of even the principle?


One of the issues in the new project gave formulas for the cost versus 
benefit calculations underlying specialization.  Depending on your 
purpose, it might be good to include them.  They certainly gave some 
clarity to me.


--
Terry Jan Reedy

___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/I3UXYIMASCD5MDJ5QU6ITF6CRKIURHQ5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Speeding up CPython

2021-05-13 Thread Abdur-Rahmaan Janhangeer

Greetings,

One crucial missing piece in the Python world is the focus
on internals of projects. You have many talks on usage and
scaling but not enough on internals. Even less workshops.
For OpenSource to thrive, you need people who master the codebase.
It's a long process. You get there by having core contributors over
time. How does a contributor becomes a core one? By getting the feet wet
into the codebase and tackling more difficult as time passes. That's why
instead of waiting for people to find issues, work on it, wait for
validation,
we can improve the training process without damage to the codebase.
People get the educational version of the repo, solve the issues at their
own pace up to the level where they'll feel confident to try a meaningful
PR. Seeing it with the eye of a knowledgeable person makes will make them
PR not just for the sake of PR but because of a real need. One practical
way is also to point the intermediate steps to resources on the internet,
like
this and that C articles to get started with C, this article to understand
this C
behaviour, this talk at this conf to understand this part of the C API, i
built a
tool specifically to document those intermediate steps by gathering
resources
on the internet, will start using it soon: https://linkolearn.com/. I am
part of the
Flask Community Workgroup (It's due to be announced soon, but here is the
link:
https://flaskcwg.github.io/). One of the aims of it is education, a good
deal about
internals. We aim to roll out some initiatives by next year. What caused me
to
write the first post is that there seems to be a bottleneck somewhere when
you
see contributors overwhelmed by OpenSource tasks. If it were some obscure
project
I understand but not one of the most popular OpenSource product of today.

Kind Regards,

Abdur-Rahmaan Janhangeer
about | blog

github
Mauritius
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/473YV6T3RVI55KA45LA5KIA7FXQHBSEY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Speeding up CPython

2021-05-13 Thread Chris Angelico

On Thu, May 13, 2021 at 5:37 PM Abdur-Rahmaan Janhangeer
 wrote:
>
> Greetings,
>
> One crucial missing piece in the Python world is the focus
> on internals of projects. You have many talks on usage and
> scaling but not enough on internals. Even less workshops.
> For OpenSource to thrive, you need people who master the codebase.
> It's a long process. You get there by having core contributors over
> time. How does a contributor becomes a core one? By getting the feet wet
> into the codebase and tackling more difficult as time passes. That's why
> instead of waiting for people to find issues, work on it, wait for validation,
> we can improve the training process without damage to the codebase.
> People get the educational version of the repo, solve the issues at their
> own pace up to the level where they'll feel confident to try a meaningful
> PR. Seeing it with the eye of a knowledgeable person makes will make them
> PR not just for the sake of PR but because of a real need.

How is this "educational version" different from a forked git
repository? I'm confused here.

ChrisA
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/N2BUH2MHDTPERNA4TLCXQOL5KQ5FFL3D/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Speeding up CPython

2021-05-13 Thread Abdur-Rahmaan Janhangeer

Greetings,

On Thu, May 13, 2021 at 11:43 AM Chris Angelico  wrote:

> How is this "educational version" different from a forked git
> repository? I'm confused here.
>

Oh i mean a forked git repository with internal-focused documentations,
issues
opened with description of changes to be made then repo set to READONLY.
A way to view what the solved issues look like in included under
'internal-focused documentations'

Kind Regards,

Abdur-Rahmaan Janhangeer
about  | blog

github 
Mauritius
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/6DFH2ZVEZ6HYQTYZYZYEG3FZT3KN67G6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 659: Specializing Adaptive Interpreter

2021-05-13 Thread Mark Shannon

Hi Terry,

On 13/05/2021 5:32 am, Terry Reedy wrote:

On 5/12/2021 1:40 PM, Mark Shannon wrote:

This is an informational PEP about a key part of our plan to improve
CPython performance for 3.11 and beyond.

As always, comments and suggestions are welcome.

The claim that starts the Motivation section, "Python is widely
acknowledged as slow.", has multiple problems. While some people
believe, or at least claim to believe "Python is slow", other know that
as stated, the latter is false. Languages do not have a speed, only
implementations running code for particular applications have a speed,
or a speed relative to equivalent code in another language with a
different runtime.

I broadly agree, but CPython is largely synonymous with Python and
CPython is slower than it could be.

The phrase was not meant to upset anyone.
How would you rephrase it, bearing in mind that needs to be short?

I reason I am picking on this is that the meme 'Python is slow' is being
morphed into 'Python is destroying the earth' (and should be abandoned,
if not banned). Last fall, a science news journal (Nature News?) quoted
a 'concerned scientist' saying just this. An internet troll repeated it
last week on comp.lang.python (from where it leaked onto python-list).

It is a legitimate concern that CPython is bad for the environment, and
one that I hope we can address by speeding up CPython.

Since, faster == less energy for the same amount of work, making CPython
faster will reduce the amount of CO2 produced to do that work and
hopefully make it less of a concern.

Of course, compared to the environmental disaster that is BitCoin, it's
not a big deal.

It is true that Python has characteristics that make it *relatively*
difficult to write interpreters that are *relatively* fast in certain
applications. But the opposite is also true. The language does *not*
mandate that objects, their methods, and modules be written in the
language.

Hence, CPython implements builtin objects and function and some stdlib
modules in C and allows 3rd party modules written in C or C++ or
Fortran. I believe the first killer app for Python, in the mid 1990s,
numerical computing with NumericalPython. Rather than being 'slow',
CPython *enabled* people, with a few percent of added time, to access
fast, heavily optimized C and Fortran libraries and do things they could
not do in Fortran and that would have been much more difficult in C. My
daughter's PhD thesis work is a recent example of using Python to access
C libraries.

Yes, one of the great things about Python is that almost every library
of any size has Python bindings.

But there is a difference between making code that is already written in
C/Fortran available to Python and telling people to write code in
C/Fortran because their Python code is too slow.

We want people to be able to write code in Python and have it perform at
the level they would get from a good Javascript or lua implementation.

The concerned scientist mentioned above noted, more or less correctly,
that numerical code, such as neuro-network code, is, say, 80x slower in
pure python than in compiled C. But he did not mention that serious
numerical and scientific work in Python is not done with such code.

I have seen this sort of bogus comparison before.

It is still important to speed up Python though.

If a program does 95% of its work in a C++ library and 5% in Python, it
can easily spend the majority of its time in Python because CPython is a
lot slower than C++ (in general).

Cheers,
Mark.

https://www.python.org/dev/peps/pep-0659/

___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/QAWW7I733TPNU4VE2I4J2FCPCXXVM7MG/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 659: Specializing Adaptive Interpreter

2021-05-13 Thread Paul Moore

On Thu, 13 May 2021 at 09:23, Mark Shannon  wrote:
>
> Hi Terry,
>
> On 13/05/2021 5:32 am, Terry Reedy wrote:
> > On 5/12/2021 1:40 PM, Mark Shannon wrote:
> >
> >> This is an informational PEP about a key part of our plan to improve
> >> CPython performance for 3.11 and beyond.
> >
> >> As always, comments and suggestions are welcome.
> >
> > The claim that starts the Motivation section, "Python is widely
> > acknowledged as slow.", has multiple problems. While some people
> > believe, or at least claim to believe "Python is slow", other know that
> > as stated, the latter is false.  Languages do not have a speed, only
> > implementations running code for particular applications have a speed,
> > or a speed relative to equivalent code in another language with a
> > different runtime.
>
> I broadly agree, but CPython is largely synonymous with Python and
> CPython is slower than it could be.
>
> The phrase was not meant to upset anyone.
> How would you rephrase it, bearing in mind that needs to be short?

How about simply "The CPython interpreter, while sufficiently fast for
much use, could be faster"? Along with the following sentence, this
seems to me to state the situation fairly but in a way that motivates
this proposal.

Paul
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/UQFXWM64JORKYJVAGIOV6YJ5OWDTTQRA/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 659: Specializing Adaptive Interpreter

2021-05-13 Thread Mark Shannon

Hi Terry,

On 13/05/2021 8:20 am, Terry Reedy wrote:

On 5/12/2021 1:40 PM, Mark Shannon wrote:

This is an informational PEP about a key part of our plan to improve
CPython performance for 3.11 and beyond.

What is the purpose of this PEP? It seems in part to be like a
Standards Track PEP in that it proposes a new (revised) implementation
idea for the CPython bycode interpreter. Do you not intend this to not
constitute approval of even the principle?

I will make it a standards PEP if anyone feels that would be better.
We can implement PEP 659 incrementally, without any large changes to the
implementation or any to the language or API/ABI, so a standards PEP
didn't seem necessary to us.

However, because it is a large change to the implementation, it seemed
worth documenting and doing so in a clearly public fashion. Hence the
informational PEP.

One of the issues in the new project gave formulas for the cost versus
benefit calculations underlying specialization. Depending on your
purpose, it might be good to include them. They certainly gave some
clarity to me.

Which ones in particular? I can add something like them to the PEP.

Cheers,
Mark.

___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/VY3JB3XO4D2E65ZR5IZUDP7MFQJ3JXIF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 659: Specializing Adaptive Interpreter

2021-05-13 Thread Chris Jerdonek

On Wed, May 12, 2021 at 10:48 AM Mark Shannon  wrote:

> ...
> For those of you aware of the recent releases of Cinder and Pyston,
> PEP 659 might look similar.
> It is similar, but I believe PEP 659 offers better interpreter
> performance and is more suitable to a collaborative, open-source
> development model.
>

I was curious what you meant by "is more suitable to a collaborative,
open-source
development model," but I didn't see it elaborated on in the PEP. If this
is indeed a selling point, it might be worth mentioning that and saying why.

--Chris


> As always, comments and suggestions are welcome.
>
> Cheers,
> Mark.
>
> Links:
>
> https://www.python.org/dev/peps/pep-0659/
> https://github.com/facebookincubator/cinder
> https://github.com/pyston/pyston
> ___
> Python-Dev mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/[email protected]/message/VKBV4X6ZEMRBALW7JNOZYI22KETR4F3R/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/NGDXMGDYQQSJO73WOPSQO7GM4OXDKI73/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] The repr of a sentinel

2021-05-13 Thread Irit Katriel via Python-Dev

Following a recent change, we now have in traceback.py:

_sentinel = object()
def print_exception(exc, /, value=_sentinel, tb=_sentinel, limit=None,
file=None, chain=True):

So now:

>>> import traceback
>>> help(traceback.print_exception)
Help on function print_exception in module traceback:

print_exception(exc, /, value=, tb=,
limit=None, file=None, chain=True)


Is there a convention on how such default sentinel values should appear in
docs?

https://bugs.python.org/issue43024
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/ZLVPD2OISI7M4POMTR2FCQTE6TPMPTO3/
Code of Conduct: http://python.org/psf/codeofconduct/

40 matches

Mail list logo