[Python-Dev] PEP 682: Format Specifier for Signed Zero

[John Belmonte]

Just a note that this PEP is being discussed at

  https://discuss.python.org/t/pep-682-format-specifier-for-signed-zero

TLDR; When formatting a number (especially with rounding options), often
you don't want negative-signed zero as an output.  A format spec extension
enables normalizing such values to positive zero.

Regards,
--John Belmonte
___
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/HI6IXJK7NA44IYJXYSFVXPZLQMTC3M6A/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Move the pythoncapi_compat project under the GitHub Python or PSF organization?

[Petr Viktorin]

On 14. 02. 22 17:26, Ronald Oussoren wrote:



On 14 Feb 2022, at 14:07, Petr Viktorin > wrote:




On 14. 02. 22 13:37, Antoine Pitrou wrote:

On Mon, 14 Feb 2022 13:19:00 +0100
Petr Viktorin mailto:encu...@gmail.com>> wrote:


If we don't have much sympathy for projects that use private API where
does that leave pythoncapi_compat?

If you look at pythoncapi_compat.h, it provides backports for
recently-introduced public APIs such as PyObject_CallOneArg().


Yes.
On older Python versions, where the public API wasn't yet available, 
those backports use private API. If we change the private API in a 
point release, the backport will break.


Do you have an example of this? On first glance the pythoncapi_compat.h 
header only uses public APIs, other than (maybe) accessing fields of the 
thread state directly.


That's my example. Those fields are documented as "subject to change at 
any time."


But I wouldn't be afraid to do this more generally -- if we add a public 
API for something that needed private API before, freeze the old way in 
previous versions. Not only add it to pythoncapi_compat, but also to 
CPython CI, and maybe to the docs.




BTW. I’m +1 on providing this header, it makes it easier for projects to 
maintain compatibility with older Python versions. That said, we should 
continue to be careful and considerate when evolving the public API as 
migrating a project to a newer API is still work.


Yup. I'm strongly against making pythoncapi_compat mandatory.
___
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/5UF322HMUGL64SXNQGYEZDHBEE3Q5D7Z/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Move the pythoncapi_compat project under the GitHub Python or PSF organization?

[Ronald Oussoren via Python-Dev]

> On 14 Feb 2022, at 14:07, Petr Viktorin  wrote:
> 
> 
> 
> On 14. 02. 22 13:37, Antoine Pitrou wrote:
>> On Mon, 14 Feb 2022 13:19:00 +0100
>> Petr Viktorin  wrote:
>>> 
>>> If we don't have much sympathy for projects that use private API where
>>> does that leave pythoncapi_compat?
>> If you look at pythoncapi_compat.h, it provides backports for
>> recently-introduced public APIs such as PyObject_CallOneArg().
> 
> Yes.
> On older Python versions, where the public API wasn't yet available, those 
> backports use private API. If we change the private API in a point release, 
> the backport will break.

Do you have an example of this? On first glance the pythoncapi_compat.h header 
only uses public APIs, other than (maybe) accessing fields of the thread state 
directly.

BTW. I’m +1 on providing this header, it makes it easier for projects to 
maintain compatibility with older Python versions. That said, we should 
continue to be careful and considerate when evolving the public API as 
migrating a project to a newer API is still work.

Ronald
—

Twitter / micro.blog: @ronaldoussoren
Blog: https://blog.ronaldoussoren.net/

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

[Python-Dev] Re: Move the pythoncapi_compat project under the GitHub Python or PSF organization?

[Petr Viktorin]

On 14. 02. 22 13:37, Antoine Pitrou wrote:

On Mon, 14 Feb 2022 13:19:00 +0100
Petr Viktorin  wrote:


If we don't have much sympathy for projects that use private API where
does that leave pythoncapi_compat?


If you look at pythoncapi_compat.h, it provides backports for
recently-introduced public APIs such as PyObject_CallOneArg().


Yes.
On older Python versions, where the public API wasn't yet available, 
those backports use private API. If we change the private API in a point 
release, the backport will break.


Is this a proposal for "blessing" these specific workarounds, and making 
sure they don't break? That sounds nice, actually. It would mean some 
additional work, though.



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

[Python-Dev] Re: Move the pythoncapi_compat project under the GitHub Python or PSF organization?

[Antoine Pitrou]

Hi,

On Thu, 10 Feb 2022 23:58:31 +0100
Victor Stinner  wrote:
> 
> Would it make sense to move the pythoncapi_compat project under the
> GitHub Python or PSF organization to make it more "official" and a
> little bit more sustainable?

I'm +1 on this.  Many projects maintain their own set of compatibility
wrappers and it makes sense to have an actively maintained project that
centralizes these.

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

[Python-Dev] Re: Move the pythoncapi_compat project under the GitHub Python or PSF organization?

[Antoine Pitrou]

On Mon, 14 Feb 2022 13:19:00 +0100
Petr Viktorin  wrote:
> 
> If we don't have much sympathy for projects that use private API where 
> does that leave pythoncapi_compat?

If you look at pythoncapi_compat.h, it provides backports for
recently-introduced public APIs such as PyObject_CallOneArg().

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

[Python-Dev] Re: Move the pythoncapi_compat project under the GitHub Python or PSF organization?

[Petr Viktorin]

On 11. 02. 22 19:25, Neil Schemenauer wrote:

On 2022-02-11 06:14, Petr Viktorin wrote:


Sounds reasonable, but...

The implication of endorsing code like this is that *we cannot change 
private API even in patch releases*, which I don't think is documented 
anywhere, and might be a bit controversial.


I think we are still allowed to change them.  We should be aware of the 
impact though.  If an API is supposed to be private but is actually used 
by a large number of 3rd party extensions, we need to consider carefully 
when changing it.  I don't have much sympathy for work caused for people 
using clearly marked private APIs.  OTOH, practicality beats purity and 
we want them to be able to somehow use new versions of Python.



I'm all for "practicality beats purity" -- lots of people don't know the 
complicated backcompat rules, don't read the docs, have read older 
versions of docs, or don't notice things on reviews. It's bad to break 
their code without reason. But IMO it's good to set clear rules and 
stick to them ourselves, even if we're lenient in enforcing them.



If we don't have much sympathy for projects that use private API where 
does that leave pythoncapi_compat?

Is it an exception (like Cython? SWIG? Megacorp© Codegen™?)
Or would it be hypocritical to adopt it?
Or..  hmm, maybe we should retroactively declare the workaround API as 
stable in the specific CPython versions where pythoncapi_compat uses it? 
(Usually, these would be the versions before it was removed.) Is that 
what adopting pythoncapi_compat in the python org would mean?

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

[Python-Dev] Re: Steering Council reply to PEP 670 -- Convert macros to functions in the Python C API

[Antoine Pitrou]

On Wed, 9 Feb 2022 17:49:19 +0100
Victor Stinner  wrote:
> On Wed, Feb 9, 2022 at 1:04 PM Petr Viktorin  wrote:
> > > Right now, a large number of macros cast their argument to a type. A
> > > few examples:
> > >
> > > #define PyObject_TypeCheck(ob, type)
> > > PyObject_TypeCheck(_PyObject_CAST(ob), type)
> > > #define PyTuple_GET_ITEM(op, i) (_PyTuple_CAST(op)->ob_item[i])
> > > #define PyDict_GET_SIZE(mp)  (assert(PyDict_Check(mp)),((PyDictObject
> > > *)mp)->ma_used)  
> >
> > When I look at the Rationale points, and for the first three of these
> > macros I didn't find any that sound very convincing:
> > - Functions don't have macro pitfalls, but these simple macros don't
> > fall into the pits.
> > - Fully defining the argument types means getting rid of the cast,
> > breaking some code that uses the macro
> > - Debugger support really isn't that useful for these simple macros
> > - There are no new variables  
> 
> Using a static inline function, profilers like Linux perf can count
> the CPU time spend in static inline functions (on each CPU instruction
> when using annotated assembly code). For example, you can see how much
> time (accumulated time) is spent in Py_INCREF(), to have an idea of
> the cost of reference counting in Python.

The "time spent in Py_INCREF" doesn't tell you the cost of reference
counting. Modern CPUs execute code out-of-order and rely on many
internal structures (such as branch predictors, reorder buffers...).
The *visible* time elapsed between the instruction pointer entering and
leaving a function doesn't tell you whether Py_INCREF had adverse
effects on the utilization of such internal structures (making
reference counting more costly than it appears to be), or on the
contrary whether the instructions in Py_INCREF were successfully
overlapped with other computations (making reference counting
practically free).

The only reliable way to evaluate the cost of reference counting is to
compare it against alternatives in realistic scenarios.

Regards

Antoine.



> It's not possible when using
> macros.
> 
> For debuggers, you're right that Py_INCREF() and PyTuple_GET_ITEM()
> macros are very simple and it's not so hard to guess that the debugger
> is executing their code in the C code or the assembly code. But the
> purpose of PEP 670 is to convert way more complex macros. I wrote a PR
> to convert unicodeobject.h macros, IMO there are one of the worst
> macros in Python C API:
> https://github.com/python/cpython/pull/31221
> 
> I always wanted to convert them, but some core devs were afraid of
> performance regressions. So I wrote a PEP to prove that there is no
> impact on performance.
> 
> IMO the new unicodeobject.h code is way more readable. I added two
> "kind" variables which have a well defined scope. In macros, no macro
> is used currently to avoid macro pitfalls: name conflict if there is
> already a "kind" macro where the macro is used.
> 
> The conversion to static inline macros also detected a bug with "const
> PyObject*": using PyUnicode_READY() on a const Unicode string is
> wrong, this function modifies the object if it's not ready (WCHAR
> kind). It also detected bugs on "const void *data" used to *write*
> into string characters (PyUnicode_WRITE).
> 
> 
> > - Macro tricks (parentheses and comma-separated expressions) are needed,
> > but they're present and tested.  
> 
> The PEP rationale starts with:
> "The use of macros may have unintended adverse effects that are hard
> to avoid, even for experienced C developers. Some issues have been
> known for years, while others have been discovered recently in Python.
> Working around macro pitfalls makes the macro coder harder to read and
> to maintain."
> 
> Are you saying that all core devs are well aware of all macro pitfalls
> and always avoid them? I'm well aware of these pitfalls, and I fall
> into their trap multiple times.
> 
> The bpo-30459 issue about PyList_SET_ITEM() is a concrete example of
> old bugs that nobody noticed before.
> 
> 
> > The "massive change to working code" part is important. Such efforts
> > tend to have unexpected issues, which have an unfortunate tendency to
> > surface before release and contribute to release manager burnout.  
> 
> Aren't you exaggerating a bit? Would you mind to elaborate? Do you
> have examples of issues caused by converting macros to static inline
> functions?
> 
> I'm not talking about incompatible C API changes made on purpose, but
> about PEP 670 changes.
> 
> The PEP lists many macros converted to static inline functions and
> static inline functions converted to regular functions:
> https://www.python.org/dev/peps/pep-0670/#macros-converted-to-functions-since-python-3-8
> 
> Are you aware of release manager burnout caused by these changes?
> 
> Victor



___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org

[Python-Dev] Re: Require a C compiler supporting C99 to build Python 3.11

[Antoine Pitrou]

On Wed, 09 Feb 2022 03:39:42 -
h.vetin...@gmx.com wrote:
> 
> That is becoming dated quickly, as Microsoft has deprecated, and is removing,
> that version quite rapidly from their CI services (azure/GHA), i.e. mid 
> March, see:
> https://github.com/actions/virtual-environments/issues/4312.
> 
> It's understandable in the sense that they don't want to support a third 
> version
> in addition to vs2022 and vs2019, but the net effect is that very few (open 
> source)
> projects will keep using vs2017 going forward.

Not every project using CPython is an open source project, though.
And CPython probably supports more platforms than GHA or Azure do.

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