[Python-Dev] Blocking the main branch due to too many buildbots failing

[Pablo Galindo Salgado]

Hi everyone,

We have a huge amount of buildbots failing and seems to be related to
different issues
that keep piling up. To prevent this from going worse,* I am blocking the
main branch*
*until these issues are resolved.*

Only release managers and the developer in residence will be able to merge
pull requests
until these issues are fixed. Please, ping me if you have a pull request
for fixing any of these
issues so we can merge.

I apologize for the inconvenience.

Thanks for your understanding,

Regards from rainy London,
Pablo Galindo Salgado
___
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/HU2LH5MX44QZXZ36YS4SOG4ZUPT4E7QT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Slowly bend the C API towards the limited API to get a stable ABI for everyone

[Steve Dower]

On 1/28/2022 6:17 PM, Antonio Cuni wrote:

Of course, in order to be fully usable, the HPy universal ABI will need special 
support by PyPI/pip/etc, because at the moment it is impossible to package it 
inside a wheel, AFAIK.


It's totally possible, it's just that none of the existing tools will 
automatically generate the tags you need. (These are most critical in 
the filename itself, and also appear in 1-2 bits of metadata that 
currently are unused AFAIK.)


Basically, instead of just "cp310" (or "abi3", etc.), you'll want to use 
dots to separate each supported version ("cp38.cp39.cp310"). That will 
match the wheel to any of those versions.


You can even do the same with OS platforms if you prefer fewer/bigger 
wheels over more platform-specific ones.


Python on all platforms since IIRC 3.6 (maybe 3.5?) also have version 
and platform-specific tags in extension modules. These do not support 
combining tags as in wheels (and unfortunately do not match wheel tags 
at all), but do allow you to have version/platform-specific 
.pyd/.dylib/.so files in a single wheel. Again, it's just that none of 
the current build backends will help you do it.


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

[Python-Dev] Re: Slowly bend the C API towards the limited API to get a stable ABI for everyone

[Antonio Cuni]

> If a project does R releases per year for P platforms that need to support V
> versions of Python, they would normally have to build R * P * V wheels.
> With a stable ABI, they could reduce that to R * P. That's the key point,
> right?

> Can HPy do that?

actually, it can do even better than that. When you compile an HPy extension 
you can choose which ABI to target:
- CPython ABI: in this modality, all HPy_* calls are statically translated 
(using static inline functions) into the corresponding Py_* call, and it 
generates modules like foo.cpython-38-x86_64-linux-gnu.so, undistinguishable 
from a "normal" module

- HPy universal ABI: in this modality, it generates something like 
foo.hpy-x86_64-linux-gnu.so: all API calls are done through the HPyContext 
(which is basically a giant vtable): this module can be loaded by any 
implementation which supports the HPy universal ABI, including CPython, PyPy 
and GraalPython.

The main drawback of the universal ABI is that it's slightly slower because it 
goes through the vtable indirection for every call, in particular 
HPy_Dup/HPy_Close which are mapped to Py_INCREF/Py_DECREF. Some early benchmark 
indicate a 5-10% slowdown. We haven't benchmarked it against the stable ABI 
though.

Of course, in order to be fully usable, the HPy universal ABI will need special 
support by PyPI/pip/etc, because at the moment it is impossible to package it 
inside a wheel, AFAIK.

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

[Python-Dev] Re: Slowly bend the C API towards the limited API to get a stable ABI for everyone

[Antonio Cuni]

> Does HPy have any clear guidance or assistance for their users to keep 
> it up to date?

not right now, because we are still somewhat in alpha mode and sometimes we 
redesign the API and/or break compatibility. But the plan is of course to 
stabilize at some point.

> I think it can be done with clear communication from the HPy project 
> (and us when we endorse it) that they will *never* break compatibility 
> and it's *always* safe (and indeed, essential) for their users to use 
> the latest version. But that's a big commitment that I can't sign them 
> up for.

I think this will be doable once HPy is mature enough, and I also agree that 
any kind of official endorsement from CPython and/or PSF will help a lot the 
adoption of HPy itself.

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

[Python-Dev] Summary of Python tracker Issues

[Python tracker]

ACTIVITY SUMMARY (2022-01-21 - 2022-01-28)
Python tracker at https://bugs.python.org/

To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.

Issues counts and deltas:
  open7157 (-18)
  closed 51138 (+124)
  total  58295 (+106)

Open issues with patches: 2888 


Issues opened (71)
==

#33205: GROWTH_RATE prevents dict shrinking
https://bugs.python.org/issue33205  reopened by rhettinger

#38195: A bug in the multiprocessing module
https://bugs.python.org/issue38195  reopened by eshkrig

#44733: Feature request: maxtasksperchild for ProcessPoolExecutor
https://bugs.python.org/issue44733  reopened by gregory.p.smith

#44734: turtle: tests for Vec2D.__abs__ are too strict
https://bugs.python.org/issue44734  reopened by petr.viktorin

#45162: Remove old deprecated unittest features
https://bugs.python.org/issue45162  reopened by gregory.p.smith

#45200: Address Sanitizer: libasan dead lock in pthread_create() (test
https://bugs.python.org/issue45200  reopened by vstinner

#45680: Documentation on `GenericAlias` objects and `__class_getitem__
https://bugs.python.org/issue45680  reopened by kj

#46240: Incorrect hint about forgetting a comma
https://bugs.python.org/issue46240  reopened by vstinner

#46285: protocol_version in http.server.test can be ignored
https://bugs.python.org/issue46285  reopened by eric.araujo

#46462: Email Header Folding Converts Non-CRLF Newlines to CRLFs
https://bugs.python.org/issue46462  opened by jwalterclark

#46464: concurrent.futures.ProcessPoolExecutor can deadlock when tcmal
https://bugs.python.org/issue46464  opened by yilei

#46465: Regression caused by CALL_FUNCTION specialization for C functi
https://bugs.python.org/issue46465  opened by vstinner

#46472: A option that choose between single quote and double quote in 
https://bugs.python.org/issue46472  opened by I-love-study

#46475: typing.Never and typing.assert_never
https://bugs.python.org/issue46475  opened by Jelle Zijlstra

#46477: Enum: ensure bitwise operators on subclasses are correct
https://bugs.python.org/issue46477  opened by ethan.furman

#46479: Implement typing.reveal_locals
https://bugs.python.org/issue46479  opened by Jelle Zijlstra

#46480: Implement typing.assert_type
https://bugs.python.org/issue46480  opened by Jelle Zijlstra

#46482: `typing.Annotation.__new__` is not covered
https://bugs.python.org/issue46482  opened by sobolevn

#46483: `pathlib.PurePath.__class_getitem__` does not return `GenericA
https://bugs.python.org/issue46483  opened by sobolevn

#46484: Add test for Calendar().iterweekdays()
https://bugs.python.org/issue46484  opened by wangjiahua

#46487: `_SSLProtocolTransport` doesn't have the `get_write_buffer_lim
https://bugs.python.org/issue46487  opened by mooncell07

#46489: webbrowser crashes Ubuntu kernel
https://bugs.python.org/issue46489  opened by dizcza

#46490: Add "follow_symlinks=False" support for "os.utime()" on Window
https://bugs.python.org/issue46490  opened by Delgan

#46493: Add an API to indicate if the process might have multiple thre
https://bugs.python.org/issue46493  opened by gregory.p.smith

#46494: Mention typing_extensions in the typing documentation
https://bugs.python.org/issue46494  opened by Jelle Zijlstra

#46495: IDLE subsection of What's New 3.11
https://bugs.python.org/issue46495  opened by terry.reedy

#46496: idlelib/NEWS.txt for 3.11.0 and backports
https://bugs.python.org/issue46496  opened by terry.reedy

#46497: IDLE macOS shortcut ctrl+S doesn???t work for show completions
https://bugs.python.org/issue46497  opened by dvd101x

#46498: Add new triplets for loongarch64
https://bugs.python.org/issue46498  opened by loongson-zn

#46500: make timeit module accept files
https://bugs.python.org/issue46500  opened by CCLDArjun

#46501: Windows 10, turtle left right not working
https://bugs.python.org/issue46501  opened by wizprokidz

#46506: [Windows] wrap CreateFile to support follow_symlinks
https://bugs.python.org/issue46506  opened by eryksun

#46507: enabling cProfile to profile code given as an argument "?? la"
https://bugs.python.org/issue46507  opened by jul2

#46508: codec name acceptance became way too lenient in 3.9
https://bugs.python.org/issue46508  opened by gregory.p.smith

#46509: Type-specialized Py_DECREF
https://bugs.python.org/issue46509  opened by Dennis Sweeney

#46511: dataclasses: Allow typing.Annotated to wrap dataclasses-specif
https://bugs.python.org/issue46511  opened by GBeauregard

#46512: Explicit or correct behavior of filecmp.cmpfiles w/ absolute p
https://bugs.python.org/issue46512  opened by bers

#46518: SSL socket timeout not set after client connects via accept
https://bugs.python.org/issue46518  opened by tomazas

#46520: `ast.unparse` produces syntactically illegal code for identifi
https://bugs.python.org/issue46520  opened by Kodiologist

#46521: compile_command not raising syntax error when command ends wit

[Python-Dev] Re: Slowly bend the C API towards the limited API to get a stable ABI for everyone

[Steve Dower]

On 1/28/2022 5:15 PM, Barry Warsaw wrote:

On Jan 28, 2022, at 09:00, Steve Dower  wrote:


Does HPy have any clear guidance or assistance for their users to keep it up to 
date?

I'm concerned that if we simply substitute "support the C API for everyone" with 
"support the C API for every version of HPy" we're no better off.


Will it ever make sense to pull HPy into the CPython repo so that they evolve 
together?  I can see advantages and disadvantages.  If there’s a point in the 
future where we can just start promoting HPy as an official alternative C API, 
then it will likely get more traction over time.  The disadvantage is that HPy 
would evolve at the same annual pace as CPython.


Possibly, but we'd have to be really careful to not actually *evolve* 
HPy. It would essentially be a new stable API, but ideally one that uses 
all the preprocessor tricks we can (and perhaps runtime tricks) to 
compile against any CPython version rather than just the one that it 
comes with.


PSF "ownership" is probably enough to make it official (for those people 
who need everything to be "official"). I don't think that's necessary, 
but it does smooth the path for some people to be willing to use it.


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

[Python-Dev] Re: Slowly bend the C API towards the limited API to get a stable ABI for everyone

[Guido van Rossum]

I think we will get *one* chance in the next decade to get it right.
Whether that's HPy or evolution of the C API I'm not sure.

Victor, am I right that the (some) stable ABI will remain important because
projects don't have resources to build wheels for every Python release? If
a project does R releases per year for P platforms that need to support V
versions of Python, they would normally have to build R * P * V wheels.
With a stable ABI, they could reduce that to R * P. That's the key point,
right?

Can HPy do that?

On Fri, Jan 28, 2022 at 9:19 AM Barry Warsaw  wrote:

> On Jan 28, 2022, at 09:00, Steve Dower  wrote:
> >
> > Does HPy have any clear guidance or assistance for their users to keep
> it up to date?
> >
> > I'm concerned that if we simply substitute "support the C API for
> everyone" with "support the C API for every version of HPy" we're no better
> off.
>
> Will it ever make sense to pull HPy into the CPython repo so that they
> evolve together?  I can see advantages and disadvantages.  If there’s a
> point in the future where we can just start promoting HPy as an official
> alternative C API, then it will likely get more traction over time.  The
> disadvantage is that HPy would evolve at the same annual pace as CPython.
>
> -Barry
>
> ___
> 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/ABFHYMUHQXKMFSBGYMFHKTGHBYJN3XJF/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


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

[Python-Dev] Re: Slowly bend the C API towards the limited API to get a stable ABI for everyone

[Barry Warsaw]

On Jan 28, 2022, at 09:00, Steve Dower  wrote:
> 
> Does HPy have any clear guidance or assistance for their users to keep it up 
> to date?
> 
> I'm concerned that if we simply substitute "support the C API for everyone" 
> with "support the C API for every version of HPy" we're no better off.

Will it ever make sense to pull HPy into the CPython repo so that they evolve 
together?  I can see advantages and disadvantages.  If there’s a point in the 
future where we can just start promoting HPy as an official alternative C API, 
then it will likely get more traction over time.  The disadvantage is that HPy 
would evolve at the same annual pace as CPython.

-Barry



signature.asc
Description: Message signed with OpenPGP
___
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/ABFHYMUHQXKMFSBGYMFHKTGHBYJN3XJF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Slowly bend the C API towards the limited API to get a stable ABI for everyone

[Steve Dower]

Does HPy have any clear guidance or assistance for their users to keep 
it up to date?


I'm concerned that if we simply substitute "support the C API for 
everyone" with "support the C API for every version of HPy" we're no 
better off.


I think it can be done with clear communication from the HPy project 
(and us when we endorse it) that they will *never* break compatibility 
and it's *always* safe (and indeed, essential) for their users to use 
the latest version. But that's a big commitment that I can't sign them 
up for.


Cython seems to manage it okay. I can't remember the last compat issue I 
had there that wasn't on our (C-API) side.


Thoughts?

Cheers,
Steve

On 1/28/2022 4:50 PM, Victor Stinner wrote:

Wait, where is the HPy project in that plan? :-) The HPy project
(brand new C API) is a good solution for the long term!

My concerns about HPy right now is that, in short, CPython has to
continue supporting the C API for a few more years, and we cannot
evolve CPython before it will become reasonable to consider removing
the "legacy" C API.

I explained that in details in the PEP 674 (Disallow using Py_TYPE()
and Py_SIZE() macros as l-values):
https://www.python.org/dev/peps/pep-0674/#relationship-with-the-hpy-project

In parallel, we should continue promoting the usage of Cython, cffi,
pybind11 and HPy, rather than using directly the C API.

Victor

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

[Python-Dev] Re: Slowly bend the C API towards the limited API to get a stable ABI for everyone

[Victor Stinner]

Wait, where is the HPy project in that plan? :-) The HPy project
(brand new C API) is a good solution for the long term!

My concerns about HPy right now is that, in short, CPython has to
continue supporting the C API for a few more years, and we cannot
evolve CPython before it will become reasonable to consider removing
the "legacy" C API.

I explained that in details in the PEP 674 (Disallow using Py_TYPE()
and Py_SIZE() macros as l-values):
https://www.python.org/dev/peps/pep-0674/#relationship-with-the-hpy-project

In parallel, we should continue promoting the usage of Cython, cffi,
pybind11 and HPy, rather than using directly the C API.

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

[Python-Dev] Slowly bend the C API towards the limited API to get a stable ABI for everyone

[Victor Stinner]

Hi,

There is a reason why I'm bothering C extensions maintainers and
Python core developers with my incompatible C API changes since Python
3.8. Let me share my plan with you :-)


In 2009 (Python 3.2), Martin v. Löwis did an amazing job with the PEP
384 "Defining a Stable ABI" to provide a "limited C API" and a "stable
ABI" for C extensions: build an extension once, use it on multiple
Python versions. Some projects like PyQt5 and cryptograpy use it, but
it is just a drop in the PyPI ocean (353,084 projects). I'm trying to
bend the "default" C API towards this "limited C API" to make it
possible tomorrow to build *more* C extensions for the stable ABI.

My goal is that the stable ABI would be the default, and only a
minority of C extensions would opt-out because they need to access to
more functions for best performance.

The basic problem is that at the ABI level, C extensions must only
call functions, rather than getting and setting directly to structure
members. Structures changes frequently in Python (look at changes
between Python 3.2 and Python 3.11), and any minor structure change
breaks the ABI. The limited C API hides structures and only use
function calls to solve this problem.


Since 2020, I'm modifying the C API, one function by one, to slowly
hide implementations (prepare the API to make strutures opaque). I
focused on the following structures:

* PyObject and PyVarObject (bpo-39573)
* PyTypeObject (bpo-40170)
* PyFrameObject (bpo-40421)
* PyThreadState (bpo-39947)

The majority of C extensions use functions and macros, they don't
access directly structure members. There are a few members which are
sometimes accessed directly which prevents making these structures
opaque. For example, some old C extensions use obj->ob_type rather
than Py_TYPE(obj). Fixing the minority of C extensions should benefit
to the majority which may become compatible with the stable ABI.

I am also converting macros to static inline functions to fix their
API: define parameter types, result type and avoid surprising macros
side effects ("macro pitfalls"). I wrote the PEP 670 "Convert macros
to functions in the Python C API" for these changes.


I wrote the upgrade_pythoncapi.py tool in my pythoncapi_project (*)
which modify C code to use Py_TYPE(), Py_SIZE() and Py_REFCNT() rather
than accessing directly PyObject and PyVarObject members.

(*) https://github.com/pythoncapi/pythoncapi_compat

In this tool, I also added "Borrow" variant of functions like
PyFrame_GetCode() which returns a strong reference, to replace
frame->f_code with _PyFrame_GetCodeBorrow(). In Python 3.11, you
cannot use the frame->f_code member anymore, since it has been
removed! You must call PyFrame_GetCode() (or pythoncapi_compat
_PyFrame_GetCodeBorrow() variant).


There are also a few macros which can be used as l-values like
Py_TYPE(): "Py_TYPE(type1) = type2" must now be written
"Py_SET_TYPE(type1, type2)" to avoid setting directly the tp_type type
at the ABI level. I proposed the PEP 674 "Disallow using Py_TYPE() and
Py_SIZE() macros as l-values" to solve these issues.


Currently, many "functions" are still implemented as macros or static
inline functions, so C extensions still access structure members at
the ABI level for best Python performance. Converting these to regular
functions has an impact on performance and I would prefer to first
write a PEP giving the rationale for that.


Today, it is not possible yet to build numpy for the stable ABI. The
gap is just too large for this big C extension. But step by step, the
C API becomes closer to the limited API, and more and more code is
ready to be built for the stable ABI.


Well, these C API changes have other advantages, like preparing Python
for further optimizations, ease Python maintenance, clarify the
seperation between the limited C API and the default C API, etc. ;-)

Victor
--
Night gathers, and now my watch begins. It shall not end until my death.
___
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/DN6JAK62ZXZUXQK4MTGYOFEC67XFQYI5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Request to revert unittest and configparser incompatible changes in Python 3.11

[Stephen J. Turnbull]

Steven D'Aprano writes:

 > Or maybe, as a developer (not an end-user of an app), you could be more 
 > proactive in reporting those warnings to the third party, and 
 > encouraging them to fix them. Maybe even submitting a patch?

As Chris B points out, it's quite possible that (generic) you have
already reported, and maybe even submitted that patch, but you still
have to wait for the release.  Thing about submitting such patches --
I can't speak for Python programs, but in XEmacs I probably refused
more warning-suppression patches than I accepted, because there was a
deeper problem that needed to be fixed and the annoying warning was
merely a side effect.  And for any project, even if you submit a
patch, there's no guarantee that the next version (or three) will
contain it, which means vendoring the source.  Urk!

 > Of course I understand that folks are busy maintaining their own
 > project, and have neither the time nor the inclination to take over
 > the maintenance of every one of their dependencies. But we
 > shouldn't just dismiss warnings in those dependencies as "warnings
 > I don't care about" and ignore them as Not My Problem.

Sure, but it's still worth providing various kinds of automation.  For
example, it would be nice if downstream (us) could fire and forget
reports of DeprecationWarnings, knowing that bug reporting systems
would automatically identify and merge them.  And for
DeprecationWarnings, rather than patching, it would be usually be nice
to suppress the warning, I think.

Steve

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

[Python-Dev] Re: Python no longer leaks memory at exit

[Simon Cross]

> tl; dr Python no longer leaks memory at exit on the "python -c pass" command 
> ;-)

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

[Python-Dev] Re: Request to revert unittest and configparser incompatible changes in Python 3.11

[Christopher Barker]

On Thu, Jan 27, 2022 at 10:47 AM Steven D'Aprano 
wrote:

> > >Getting the right people to pay attention to them is always the hard
> part.
>
> Or maybe, as a developer (not an end-user of an app), you could be more
> proactive in reporting those warnings to the third party, and
> encouraging them to fix them. Maybe even submitting a patch?
>

Personally, I do exactly that -- but more often than not (thankfully) the
upstream project is already working on it, or already fixed it, but in a
version that I can't use yet. So then I really want to silence those
warnings. Which is pretty easy to do with pytest, but maybe not so easy
everywhere?


>  But we shouldn't just
> dismiss warnings in those dependencies as "warnings I don't care about"
> and ignore them as Not My Problem.
>

Unless we have done due diligence already :-)

-CHB


-- 
Christopher Barker, PhD (Chris)

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython
___
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/YUWICC2Q274FBOZF5BX2N3BYEO7MHMQH/
Code of Conduct: http://python.org/psf/codeofconduct/