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

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



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


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.


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


--
Terry Jan Reedy

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

[Python-Dev] Re: Speeding up CPython

[Abdur-Rahmaan Janhangeer]

On Thu, 13 May 2021, 01:09 Terry Reedy,  wrote:

> On 5/12/2021 2:50 PM, Abdur-Rahmaan Janhangeer wrote:
> > Great news, just a tiny bit from me.
> > I read the other day in the OpenSource report
> > sponsored by the Ford Foundation a CPython
> > contributor stating that we have an all time high
> > count of Python users but an all time low number of
> > contributors to CPython. I don't know how but
> > we certainly need a fake path to help people start
>
> I presume you mean 'fast path'?
>


No i mean fake path in the sense of a fork
 of CPython with issues for learning purposes
Then people work on solving the issues on their
own without PRing. It helps them get close to the
CPython source without waiting for merges or
comments since the fix will be documented.

It allows people to skill up without people involvement
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/5ERKGBKB2RNE7HZPFAZNOFUAVMDKTJJS/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Future PEP: Include Fine Grained Error Locations in Tracebacks

[Mike Miller]

On 2021-05-11 16:12, Guido van Rossum wrote:
On Tue, May 11, 2021 at 4:07 PM Gregory P. Smith There's a difference between tracebacks dumped as plain text (utf-8) by

traceback.print_exc() appearing on stderr or directed into log files and
what can be displayed within a terminal.  It is highly unusual to emit
terminal control characters into log files.


And yet it happens all the time. :-( Let's not risk that happening.



os.isatty() is helpful in that situation, no?

-Mike

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

[Python-Dev] Re: Speeding up CPython

[Terry Reedy]

On 5/12/2021 5:14 PM, Antoine Pitrou wrote:

On Wed, 12 May 2021 17:05:03 -0400
Terry Reedy  wrote:



Yet you always see it: new people not knowing where to start,
highly skilled contributors drowning and
intermediate contributors moving slowly


I have multiple times strongly recommended that people review issues and
PRs, and sometimes given details, but most won't or don't.


I don't know who "people" are in your sentence, but reviewing issues
and PRs generally requires a high familiarity with a project, and


Much can be done without what I think you mean by 'high familiarity'.

Bug issues:
  bpo: "On macOS with 3.8.3 I see this buggy behavior" If not enough 
info to reproduce, ask for it.  If there is, try to reproduce on lastest 
release or even better, repository build.  Sometimes, trying on a 
different OS is helpful.

  PR: make local PR branch and test whether proposed fix works.

Enhancement issues:
  bpo: if proposal is for core python or a module one has used, does 
proposal seem like an actual improvement?  enough to be worth the likely 
bother?

  PR: does the PR work as promised?  Do you like it?

PR Python code: read it.  See any possible improvements?


enough confidence to speak with a voice of (seeming) authority.


I prefer honesty to pretend authority.  Nearly 2 years ago, a 'new 
contributor' commented on a IDLE PR, "Would x be better?" It was a minor 
improvement, but a real one, so I made it, thanked the person, and 
encouraged further efforts.  That person did so and is now a core developer.


I would welcome more eyes on IDLE patches and use testing thereof.


I'm
not convinced it's generally easier than submitting a patch for a
particular issue you're comfortable with.


Some review actions are easier, some are not.  But the only way to learn 
to review other people's code is to do it, and it is a skill we need in 
at least some new coredevs.


--
Terry Jan Reedy

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

[Python-Dev] Re: Speeding up CPython

[Antoine Pitrou]

On Wed, 12 May 2021 17:05:03 -0400
Terry Reedy  wrote:
> 
> > contributing and level up to gain a pool of resources
> > We don't need to wait for easy issues or things like
> > that or wait for PR merge to level up.
> > 
> > Yet you always see it: new people not knowing where to start,
> > highly skilled contributors drowning and
> > intermediate contributors moving slowly  
> 
> I have multiple times strongly recommended that people review issues and 
> PRs, and sometimes given details, but most won't or don't.

I don't know who "people" are in your sentence, but reviewing issues
and PRs generally requires a high familiarity with a project, and
enough confidence to speak with a voice of (seeming) authority.  I'm
not convinced it's generally easier than submitting a patch for a
particular issue you're comfortable with.

Regards

Antoine.


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

[Python-Dev] Re: Speeding up CPython

[Terry Reedy]

On 5/12/2021 2:50 PM, Abdur-Rahmaan Janhangeer wrote:

Great news, just a tiny bit from me.
I read the other day in the OpenSource report
sponsored by the Ford Foundation a CPython
contributor stating that we have an all time high
count of Python users but an all time low number of
contributors to CPython. I don't know how but
we certainly need a fake path to help people start


I presume you mean 'fast path'?


contributing and level up to gain a pool of resources
We don't need to wait for easy issues or things like
that or wait for PR merge to level up.

Yet you always see it: new people not knowing where to start,
highly skilled contributors drowning and
intermediate contributors moving slowly


I have multiple times strongly recommended that people review issues and 
PRs, and sometimes given details, but most won't or don't.  Do you have 
any idea why?


--
Terry Jan Reedy

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

[Python-Dev] Re: Speeding up CPython

[Abdur-Rahmaan Janhangeer]

Great news, just a tiny bit from me.
I read the other day in the OpenSource report
sponsored by the Ford Foundation a CPython
contributor stating that we have an all time high
count of Python users but an all time low number of
contributors to CPython. I don't know how but
we certainly need a fake path to help people start
contributing and level up to gain a pool of resources
We don't need to wait for easy issues or things like
that or wait for PR merge to level up.

Yet you always see it: new people not knowing where to start,
highly skilled contributors drowning and
intermediate contributors moving slowly

I know all contributors are doing awesome
work but maybe something can be done to have
a smarter skilling up stream
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/WRAZOTSTUFYPJHN2QWKCD2C3WS6HCGV7/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Speeding up CPython

[Guido van Rossum]

On Fri, May 7, 2021 at 8:20 PM Gregory P. Smith  wrote:

>
> On Fri, May 7, 2021 at 6:51 PM Steven D'Aprano 
> wrote:
>
>> On Tue, Oct 20, 2020 at 01:53:34PM +0100, Mark Shannon wrote:
>> > Hi everyone,
>> >
>> > CPython is slow. We all know that, yet little is done to fix it.
>> >
>> > I'd like to change that.
>> > I have a plan to speed up CPython by a factor of five over the next few
>> > years. But it needs funding.
>>
>> I've noticed a lot of optimization-related b.p.o. issues created by
>> Mark, which is great. What happened with Mark's proposal here? Did the
>> funding issue get sorted?
>>
>
> I believe Guido has Mark contracting on Python performance through
> Microsoft?
>

For those who didn't attend the Language Summit yesterday, this is indeed
the case. We've been in stealth mode until the summit, but the cat is now
definitely out of the bag -- Microsoft is thanking the Python community by
funding work to speed up CPython. Besides Mark and myself, Eric Snow (a MS
employee like myself) is also full-time on this project. We expect to be
adding a few more people to the team.

Mark has already revealed his PEP 659 (Specializing Adaptive Interpreter).

We've also created a small GitHub org: https://github.com/faster-cpython/,
containing several repos:

- https://github.com/faster-cpython/cpython, a fork of cpython where we do
the work (PRs will mostly come from here)
- https://github.com/faster-cpython/tools, a set of tools we're using for
benchmarking and analysis and the like (the README contains some stats
we've gathered on bytecode occurrence)
- https://github.com/faster-cpython/ideas, a tracker where we're discussing
various plans and ideas

Contributions are welcome!

I've also published the slides of my language summit presentation:
https://github.com/faster-cpython/ideas/blob/main/FasterCPythonDark.pdf

-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*

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

[Python-Dev] PEP 659: Specializing Adaptive Interpreter

[Mark Shannon]

Hi everyone,

I would like to present PEP 659.

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


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.


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 -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/VKBV4X6ZEMRBALW7JNOZYI22KETR4F3R/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Necessary or not for enhancement of issue44097: “add configure option to control the groups of .pyc files to install”

[Xin, Peixing]

Mainly for storage size, especially for embedded devices. Installation time is 
small factor. Normally we just want one type of .pyc files. Getting all types 
installed at default looks burden to distributors. In some cases we even don't 
want any .pyc files at all. For example, if we copy the installed .py and .pyc 
file from one file system to another one (say from NTFS to FAT), probably the 
mtime of .py file could be changed due to the resolution limit of FAT file 
system. 

Thanks,
Peixing

-Original Message-
From: Antoine Pitrou  
Sent: Wednesday, May 12, 2021 5:36 PM
To: python-dev@python.org
Subject: [Python-Dev] Re: Necessary or not for enhancement of issue44097: “add 
configure option to control the groups of .pyc files to install”

[Please note: This e-mail is from an EXTERNAL e-mail address]

Hi Peixing,

On Wed, 12 May 2021 09:27:46 +
"Xin, Peixing"  wrote:
>
> I created issue44097 for build enhancement: “add configure option to control 
> the groups of .pyc files to install” and PR 23920 for the solution. From the 
> only a few of comments I’ve got, someone thinks this enhancement makes sense. 
> However, someone expressed opposition to this. So what is your opinion on 
> this PR? Necessary or not? I want to hear more views on this. Thanks.

If it's only a matter of storage size, you can easily delete the unwanted 
files.  Is there another concern?

Regards

Antoine.


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

[Python-Dev] Re: Necessary or not for enhancement of issue44097: “add configure option to control the groups of .pyc files to install”

[Antoine Pitrou]

Hi Peixing,

On Wed, 12 May 2021 09:27:46 +
"Xin, Peixing"  wrote:
> 
> I created issue44097 for build enhancement: “add configure option to control 
> the groups of .pyc files to install” and PR 23920 for the solution. From the 
> only a few of comments I’ve got, someone thinks this enhancement makes sense. 
> However, someone expressed opposition to this. So what is your opinion on 
> this PR? Necessary or not? I want to hear more views on this. Thanks.

If it's only a matter of storage size, you can easily delete the
unwanted files.  Is there another concern?

Regards

Antoine.


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

[Python-Dev] Necessary or not for enhancement of issue44097: “add configure option to control the groups of .pyc files to install”

[Xin, Peixing]

Hi ,

I created issue44097 for build enhancement: “add configure option to control 
the groups of .pyc files to install” and PR 23920 for the solution. From the 
only a few of comments I’ve got, someone thinks this enhancement makes sense. 
However, someone expressed opposition to this. So what is your opinion on this 
PR? Necessary or not? I want to hear more views on this. Thanks.

https://bugs.python.org/issue44097
https://github.com/python/cpython/pull/23920

Thanks,
Peixing

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