[Python-Dev] Re: Need help on security vulnerability zlib 1.2.11

[matti . picus]

The pyinstaller docs https://pyinstaller.org/en/stable/ refer to the google 
group  pyinstal...@googlegroups.com or you can try their issue tracker 
https://github.com/pyinstaller/pyinstaller/issues
___
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/HUYWJCJAGM2PBVYYTUUDSHHLGMW6P6WC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Python-Dev] Replace debug runtime checks in release mode, with assertions in debug mode

[Matti Picus]

On 7/2/22 17:55, Victor Stinner wrote:

End users should not have to
pay the price of these runtime checks.



Is the cost of the checks measurable and significant? Surely sanitizing 
arguments to prevent segfaults is worth a few nano-seconds?



Matti

___
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/OK43VQKWNXOCPLXQQI3TH5KUXHUUZZLM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: issues-test-2 spam?

[Matti Picus]

  
  




  Message: 1
Date: Sun, 26 Dec 2021 21:48:22 +0100
From: Ezio Melotti 
Subject: [Python-Dev] Re: issues-test-2 spam?
To: "Steven D'Aprano" 
Cc: python-dev 
Message-ID:
	
Content-Type: text/plain; charset="UTF-8"

Sorry, my mistake (again :)

...

Since the python-core team has 110 members and only 65 people are
added automatically, I think it might depend on user-specific settings
(e.g. if you are a member of the python org and you are following it,
you might get automatically subscribed to every new org repo).

...

--Ezio




You may want to try the experiments in a private repo under your
  username rather than under the python organization. I think this
  will prevent anyone except you from getting notified. You could
  even go further and set up a dummy bpo-migrator github user, then
  no one should get notifications. Thanks for doing the work.

Matti

  

___
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/WZQ255LDL4OWVQT5AL74TEC7Y7KKZ276/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 674: Disallow using macros as l-value

[matti . picus]

On Tue, 7 Dec 2021 16:08:27 -0800 Guido van Rossum gu...@python.org wrote:

I wonder if there’s a role for HPy in this context? What if instead of
evolving the stable ABI and the limited API, instead we were to focus on
first-class support for HPy?

The hope with the HPy project is indeed to provide a C API that is close to the 
original API to make porting easy and have it perform as close to the existing 
API as possible. At the same time, HPy is sufficently removed to be a good “C 
extension API” (as opposed to a stable subset of the CPython implementation 
API) that does not leak implementation details. To ensure this latter property 
is why we try to develop everything in parallel for CPython, PyPy, and GraalVM 
Python.

On Wed, 8 Dec 2021 01:47:38 +0100 Victor Stinner vstin...@python.org wrote:

Providing HPy as a first-class citizen in CPython, as already done in
PyPy, would be great to promote HPy! However, HPy evolves quickly and
so needs to be released more frequently than CPython. At least, we
could promote it more in the C API documentation, as we already
promote Cython.

Indeed, at this point HPy is still evolving very fast. We are still solving
issues while migrating NumPy, have begun adding support for HPy to Cython,
and will start working on pybind11 soon. I believe by the time we have these
users of the existing C API working, HPy should be in a state where it is
generally useful and can be deemed stable enough that further development can 
follow a more stable process.

For me, HPy is the only valid stable API and stable ABI in the long
term which is efficient on any Python implementation. Its design is
very different than the C API: HPy avoids all C API design mistakes,
it doesn’t leak any implementation detail.

In the long run the HPy project would like to become a promoted API to
write Python C extensions.

Tim Felgentreff, posted by Matti Picus
(on behalf of the HPy team)
___
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/GBDS2W575VED2KQN6DIN7E5JCMNKNQJF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 674: Disallow using macros as l-value

[matti . picus]

Victor Stinner wrote:
> First, PyPy tried to only implement a subset of the C API and promote
> cffi for incompatible C extensions. This approach failed.

Just to be clear: I don't think any of the PyPy devs assumed the huge Python 
c-extension ecosystem would suddenly run to adopt CFFI, so calling our effort 
to emulate the C-API a consequence of any failure is a bit of an exaggeration.

> So PyPy decided to be as compatible as possible with CPython for the C
> API. Now PyPy basically supports the whole C API and doesn't want to
> drop support for the C extensions "abusing" the C API, like using
> macros as l-value.

I think it would be more accurate to say that PyPy, as a small project in the 
huge Python ecosystem, is trying to support any C-API used widely by the 
community. If there is a common PyPy voice (after all, we are also a project 
with many opinions),  we don't "not want to drop support" nor "want to drop 
support" for any commonly used C-API interfaces, rather we want to stay out of 
this argument and promote alternatives such as CFFI, cppyy, and HPy instead. 

> Victor

Matti
___
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/3HGX42QFURHCU6O6DOKBXLVTFIU6RDBO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PyPy performance stats (was Re: Speeding up CPython)

[Matti Picus]

On 10/21/20 2:38 PM, Matti Picus wrote:

On 10/21/20 20:42:02 +1100 Chris Angelico wrote:


When I go looking for PyPy performance stats, everything seems to be
Python 2.7. Is there anywhere that compares PyPy3 to CPython 3.6 (or
whichever specific version)? Or maybe it's right there on
https://speed.pypy.org/  and I just can't see it - that's definitely
possible:)

ChrisA



They are not on the front page. You can find them, but it requires 
digging around in the Comparison page[0].


I guess we could switch to emphasizing python3 on the front page, help 
in updating and reconfiguring Codespeed [1] would be awesome.


Matti


[0] https://speed.pypy.org/comparison/

[1] https://github.com/python/codespeed/tree/speed.pypy.org



Just as a follow up: the front page of speed.pypy.org now shows the 
latest pypy 3.6 vs cpython 3.6.7.


Matti
___
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/2BXQUZO24SZOP2AEQTB3RQNHQWC5APJ6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Speeding up CPython

[Matti Picus]

On Wed, Oct 21, 2020 at 3:38 AM Steven D'Aprano st...@pearwood.info 
 wrote:


> some insulting FUD that is not worth repeating, and an apology


Just to set the record straight, PyPy has been available on conda-forge 
[0] since March, and has seen close to 70,000 downloads [1] from that 
channel alone, in addition to the downloads from 
https://downloads.python.org/pypy and the other channels where it is 
available. This is far from CPython's wild popularity, but people are 
successfully using it with the scientific python stack. It is true there 
is more work to be done, that does not mean it is useless.



It is in CPython's interest to have a viable alternative interpreter for 
many reasons. The code of conduct [3] should guide discourse when 
relating to all people and projects in the Python ecosystem, not just 
internally to CPython.


Matti


[0] https://conda-forge.org/blog/posts/2020-03-10-pypy/

[1] https://anaconda.org/conda-forge/pypy3.6

[2] https://www.python.org/psf/conduct/
___
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/MPU2RYONWC4KHXEJ5D4VHHNSICIDY6LD/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] creating Lib/tests/cmath_testcases.txt for 64 bit complex numbers

[Matti Picus]

  
  
Hi. I am implementing complex numbers for pypy's version of numpy. 
Numpy has both 128 bit (based on 64 bit floats) and 64 bit (based on
32 bit floats) complex numbers, where afaict cmath uses strictly 128
bit complex numbers. I made sure the 128 bit numpy complex numbers
in pypy pass the tests in Lib/tests/cmath_testcases.txt.
I would like to generate a similar file to cmath_testcases.txt for
64 bit complex numbers. I found the earliest commit of the file at
http://hg.python.org/cpython/file/b69f443ef480/Lib/test/cmath_testcases.txt
Can the authors of the original file help me reconstruct the scripts
or programs used to generate it, and reformulate them for 32 bit
floats?
Since there are more than 2000 cases, and many need rewriting, I
prefer an automated method to error-prone hand coding.
By the way, the level of testing is most impressive.
Thanks for any help or tips,
Matti Picus
  

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

[Python-Dev] creating Lib/tests/cmath_testcases.txt for 64 bit complex numbers (text)

[Matti Picus]

(I apologize for posting HTML mail. Retrying.)
Hi. I am implementing complex numbers for pypy's version of numpy.

Numpy has both 128 bit (based on 64 bit floats) and 64 bit (based on 32
bit floats) complex numbers, where afaict cmath uses strictly 128 bit
complex numbers. I made sure the 128 bit numpy complex numbers in pypy
pass the tests in Lib/tests/cmath_testcases.txt.
I would like to generate a similar file to cmath_testcases.txt for 64
bit complex numbers. I found the earliest commit of the file at
http://hg.python.org/cpython/file/b69f443ef480/Lib/test/cmath_testcases.txt

Can the authors of the original file help me reconstruct the scripts or
programs used to generate it, and reformulate them for 32 bit floats?
Since there are more than 2000 cases, and many need rewriting, I prefer
an automated method to error-prone hand coding.

By the way, the level of testing is most impressive.

Thanks for any help or tips,
Matti Picus
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] backporting stdlib 2.7.x from pypy to cpython

[Matti Picus]

  
  
On 8/06/2012 9:29 PM, Brett Cannon wrote:

  
  On Fri, Jun 8, 2012 at 2:21 PM, fwierzbi...@gmail.com
fwierzbi...@gmail.com
wrote:

  On Fri, Jun 8, 2012 at 10:59 AM, Brett Cannon
br...@python.org
wrote:
 R. David already replied to this, but just to
reiterate: tests can always
 get updated, and code that fixes a bug (and leaving a
file open can be
 considered a bug) can also go in. It's just stuff like
code refactoring,
 speed improvements, etc. that can't go into Python 2.7
at this point.
  
  Thanks for the clarification!
  
 If/until the stdlib is made into its own repo, should
the various VMs
 consider keeping a common Python 2.7 repo that contains
nothing but the
 stdlib (or at least just modifications to those) so
they can modify in ways
 that CPython can't accept because of compatibility
policy? You could keep it
 on hg.python.org
(or wherever) and then all push to it. This might also be a
 good way to share Python implementations of extension
modules for Python 2.7
 instead of everyone maintaining there own for the next
few years (although I
 think those modules should go into the stdlib directly
for Python 3 as
 well). Basically this could be a test to see if
communication and
 collaboration will be high enough among the other VMs
to bother with
 breaking out the actual stdlib into its own repo or if
it would just be a
 big waste of time.
  
  I'd be up for trying this. I don't think it's easy to fork a
  subdirectory of CPython though - right now I just keep an
  unchanged
  copy of the 2.7 LIb in our repo (PyPy does the same, at least
  the last
  time I checked).



Looks like hg doesn't have support yet: http://stackoverflow.com/questions/920355/how-do-i-clone-a-sub-folder-of-a-repository-in-mercurial .
 
The only sane option I can see then is to keep doing what
  you and PyPy are doing and keep a copy of the stdlib, but now
  you all simply share the repo instead of keeping your own
  copies and possibly use subrepos to pull it into your own hg
  repos.



  
 P.S. Do we need a python-implementations mailing list
or something for
 discussing overall VM-related stuff among all VMs
instead of always bringing
 this up on python-dev? E.g. I wish I had a place where
I could get all the
 VM stakeholders' attention to make sure that importlib
as it stands in
 Python 3.3 will skip trying to import Python bytecode
properly (or if the
 VMs will simply provide their own setup function and
that won't be a worry).
 And I would have no problem with keeping it like
python-committers in terms
 of closed subscriptions, open archive in order to keep
the noise low.
  
  I think a python-implementations list would be a fantastic
  idea - I
  sometimes miss multi-implementation discussions in python-dev,
  or at
  least come in very late.



If other people agree then I will get Barry to create it. 
  

I will follow a path of contributing the changes using
  bugs.python.org. Suggested changes will be the minumum needed to
  make the stdlib modules functional on pypy

Thanks,

Matti

  

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

[Python-Dev] backporting stdlib 2.7.x from pypy to cpython

[Matti Picus]

The windows port of pypy makes special demands on stdlib, specifically that 
files are explicitly closed. There are some other minor issues, in order to
merge all the changes necessary to get pypy windows up to speed, around 10
modules or at  least their tests seem to need to be modified.
I have been doing a bit of work on the stdlib shipped with pypy 1.9 
(version 2.7.2 unfortunately) to make it compliant. Assuming there is interest, 
what would be the best path to get, for instance, a modified version of 
mailbox.py with its tests (test_mailbox.py and test_old_mailbox.py) backported
to cpython? 
Matti 

PS - I know closing files on delete is also an issue for cpython3.3, I did
merge as much of 3.3 back into mailbox as I could, but there were still more
issues.


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