[Python-Dev] Re: Request for comments on final version of PEP 653 (Precise Semantics for Pattern Matching)

[Paul Moore]

On Tue, 6 Apr 2021 at 06:15, Stephen J. Turnbull
 wrote:
>
> Paul Moore writes:
>
>  > It *is* merged and publicly released - it's in the latest 3.10
>  > alpha.
>
> Merged, yes, but in my terminology alphas, betas, and rcs aren't
> "public releases", they're merely "accessible to the public".  (I'm
> happy to adopt your terminology when you're in the conversation, I'm
> just explaining what I meant in my previous post.)

*shrug* It's (in my experience) a continuum - it's not in a release
yet, but it is available via an installer, with a (pre-release)
version number. But I get what you're saying and don't disagree, to be
honest. I see the discrepancy as mostly being because we're trying to
use (imprecise) informal language to pin down precise nuances.

The main point I was making is that it's merged into the CPython
source code at this stage, and available for people to download and
experiment with, which is something I was unclear about.

>  > The fact that the implementation kept getting referred to as the
>  > "reference implementation" confused me into thinking it hadn't been
>  > released yet, and that simply isn't true. Calling it "the
>  > implementation" avoids that confusion, IMO.
>
> The only thing I understand in that paragraph is "that [it hadn't been
> released yet] simply isn't true", which is true enough on your
> definition of "released".  But why does "reference implementation"
> connote "unreleased"?  That seems to be quite different from Mark's
> usage.

In my experience, people developing PEPs will sometimes provide what
gets referred to as a "reference implementation" of the proposal,
which is a PR or equivalent that people can apply and try out if they
want to see how the proposal works in practice. That "reference
implementation" is generally seen as part of the *proposal*, even if
it then becomes the final merged code as well. Once it's released, it
tends to no longer get called the *reference* implementation, as it's
now just the implementation (in CPython) of the feature.

PEP 1 uses this terminology, as well - "Standards Track PEPs consist
of two parts, a design document and a reference implementation" and
"Once a PEP has been accepted, the reference implementation must be
completed. When the reference implementation is complete and
incorporated into the main source code repository, the status will be
changed to "Final"". PEP 635 follows this terminology, with a
"Reference implementation" section linking to the development branch
for the feature.

To put this back into the context of this discussion, when Mark was
referring to the "reference implementation" it made me think that
maybe we were talking about that development branch, and that the code
for the pattern matching PEP hadn't yet been merged to the main
branch, which is why we were still iterating over implementation
details. And that led me to think that they'd better get the
discussion resolved soon, as they risk missing the 3.10 deadline if
things drag on. Which *isn't* the case, and if I'd been following
things more closely I'd have known that, but avoiding the term
"reference implementation" for the merged change would also have
spared my confusion.

> I don't have an objection to your usage, I'd just like us all to
> converge on a set of terms so that Brandt has a compact way of saying
> "as far as I know, for the specification under discussion this
> implementation is completely accurate and folks are welcome to refer
> to the PEP, to the code, or to divergences as seems appropriate to
> them".  I'm not sure if that's exactly what Brandt meant by "reference
> implementation", but that's how I understood it.

Agreed, a common understanding is the main thing here. And as I'm not
an active participant in the discussion, and I now understand the
situation, my views shouldn't have too much weight in deciding what
the best terminology is.

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

[Python-Dev] [RELEASE] The last Python 3.10 alpha (3.10.0a7) is available - Prepare for beta freeze

[Pablo Galindo Salgado]

Br. do you feel that? That's the chill of *beta freeze* coming
closer. Meanwhile, your friendly CPython release team doesn’t
rest even on holidays and we have prepared a shiny new release for you:
Python 3.10.0a7.


Dear fellow core developer:
This alpha is the last release before feature freeze (2021-05-03), so make
sure that all new features and PEPs are landed in the master branch before
we
release the first beta. Please, be specially mindfully to check the CI and
the buildbots, maybe even using the test-with-buildbots label in GitHub
before
merging so the release team don’t need to fix a bunch of reference leaks or
platform-specific problems on the first beta release.



*Go get the new alpha here:*
https://www.python.org/downloads/release/python-3100a7/


*Python 3.10.0a7*Release Date: April 5, 2021

This is an early developer preview of Python 3.10

*Major new features of the 3.10 series, compared to 3.9*

Python 3.10 is still in development. This release, 3.10.0a7 is the last of
seven planned alpha releases. Alpha releases are intended to make it easier
to test the current state of new features and bug fixes and to test the
release process. During the alpha phase, features may be added up until the
start of the beta phase (2021-05-03) and, if necessary, may be modified or
deleted up until the release candidate phase (2021-10-04). Please keep in
mind that this is a preview release and its use is not recommended for
production environments.

Many new features for Python 3.10 are still being planned and written.
Among the new major new features and changes so far:

PEP 623 – Deprecate and prepare for the removal of the wstr member in
PyUnicodeObject.
PEP 604 – Allow writing union types as X | Y
PEP 612 – Parameter Specification Variables
PEP 626 – Precise line numbers for debugging and other tools.
bpo-38605: from __future__ import annotations (PEP 563) is now the default.
PEP 618 – Add Optional Length-Checking To zip.
bpo-12782: Parenthesized context managers are now officially allowed.
PEP 632 – Deprecate distutils module.
PEP 613 – Explicit Type Aliases
PEP 634 – Structural Pattern Matching: Specification
PEP 635 – Structural Pattern Matching: Motivation and Rationale
PEP 636 – Structural Pattern Matching: Tutorial
PEP 644 – Require OpenSSL 1.1.1 or newer
PEP 624 – Remove Py_UNICODE encoder APIs
PEP 597 – Add optional EncodingWarning
(Hey, fellow core developer, if a feature you find important is missing
from this list, let Pablo know.)
The next pre-release of Python 3.10 will be 3.10.0b1 ( the first beta
release and feature freeze ), currently scheduled for Monday, 2021-05-03.

*And now for something completely different*

In physics, the twin paradox is a thought experiment in special relativity
involving identical twins, one of whom makes a journey into space in a
high-speed rocket and returns home to find that the twin who remained on
Earth has aged more. This result appears puzzling because each twin sees
the other twin as moving, and so, as a consequence of an incorrect and
naive application of time dilation and the principle of relativity, each
should paradoxically find the other to have aged less. However, this
scenario can be resolved by realising that the travelling twin is
undergoing acceleration, which makes him a non-inertial observer. In both
views, there is no symmetry between the spacetime paths of the twins.
Therefore, the twin paradox is not a paradox in the sense of a logical
contradiction.

Your friendly release team,
Pablo Galindo Salgado @pablogsal
Ned Deily @nad
Steve Dower @steve.dower
___
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/G2J3SBJ4EOW6MQZZJQNTXKHRWTAVBMKP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 652 Accepted -- Maintaining the Stable ABI

[Petr Viktorin]

On 05. 04. 21 21:46, Pablo Galindo Salgado wrote:

Hi Petr,

Thank you for submitting PEP 652 (Maintaining the Stable ABI). After 
evaluating
the situation and discussing the PEP, the Steering Council is happy with 
the PEP
and hereby accepts it. The Steering council thinks that this is a great 
step forward
in order to have a clear definition of what goes into the Stable ABI and 
what guarantees
the Python core team offers regarding the stable ABI while offering at 
the same time a

plan to improve the maintenance and stability of the stable ABI.

We would also like to see some improvements in the official 
documentation (not only on the
devguide) regarding this topic and what guarantees do we offer 
(currently we only have a small
section about this in https://docs.python.org/3/c-api/stable.html 
 but there is a lot of 
information
and clarifications in the PEP that we would like to be also in the 
documentation).


Congratulations, Petr!

With thanks from the whole Python Steering Council,
Pablo Galindo Salgado



Thanks to you and the CS for consideration!
I'm definitely planning to update the documentation prose as well.
___
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/OPBBMHVEXJ2YZKKIM45TGL3BMISLSU56/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: [python-committers] NOTE: Python 3.9.3 contains an unintentional ABI incompatibility leading to crashes on 32-bit systems

[Victor Stinner]

Hi,

About this very specific ABI issue, one long term solution would be to
exclude the PyThreadState structure from the C API, to not rely on it
the ABI level.

I started to add getter functions in Python 3.9:
PyThreadState_GetInterpreter(), PyThreadState_GetFrame() and
PyThreadState_GetID(). I'm working on updating C extensions to use
these getter functions, rather than accessing directly PyThreadState
members. I wrote a new pythoncapi_compat.h header file (in an exteral
project, pythoncapi_compat) to provide getter functions to Python
2.7-3.8. Cython gives me most of the work, since it gets and sets many
PyThreadState members.

You can follow the progress at: https://bugs.python.org/issue39947

Victor

On Sat, Apr 3, 2021 at 9:45 PM Łukasz Langa  wrote:
>
> The memory layout of PyThreadState was unintentionally changed in the recent 
> 3.9.3 bugfix release. This leads to crashes on 32-bit systems when importing 
> binary extensions compiled for Python 3.9.0 - 3.9.2. This is a regression.
>
> We will be releasing a hotfix 3.9.4 around 24 hours from now to address this 
> issue and restore ABI compatibility with C extensions built for Python 3.9.0 
> - 3.9.2.
>
> Details:
> https://bugs.python.org/issue43710
>
>
> - Ł
> ___
> python-committers mailing list -- python-committ...@python.org
> To unsubscribe send an email to python-committers-le...@python.org
> https://mail.python.org/mailman3/lists/python-committers.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-committ...@python.org/message/OUCNKMFBNGFK2AI4B7S7MF5O6UVLBSMB/
> Code of Conduct: https://www.python.org/psf/codeofconduct/



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

[Python-Dev] Re: Request for comments on final version of PEP 653 (Precise Semantics for Pattern Matching)

[Brandt Bucher]

Hi Mark.

Thanks for your reply, I really appreciate it.

Mark Shannon said:
> My intention, and I apologize for not making this clearer, was not to 
> denigrate your work, but to question the implications of the term "reference".
> 
> Calling something a "reference" implementation suggests that it is something 
> that people can refer to, that is near perfectly correct and fills in the 
> gaps in the specification.
> 
> That is a high standard, and one that is very difficult to attain. It is why 
> I use the term "implementation", and not "reference implementation" in my 
> PEPs.

Interesting. The reason I typically include a "Reference Implementation" 
section in my PEPs is because they almost always start out as a copy-paste of 
the template in PEP 12 (which also appears in PEP 1):

https://www.python.org/dev/peps/pep-0001/#what-belongs-in-a-successful-pep
https://www.python.org/dev/peps/pep-0012/#suggested-sections

Funny enough, PEP 635 has a "Reference Implementation" section, which itself 
refers to the implementation as simply a "feature-complete CPython 
implementation":

https://www.python.org/dev/peps/pep-0635/#reference-implementation

(PEP 634 and PEP 636 don't mention the existence of an implementation at all, 
as far as I can tell.)

It's not a huge deal, but we might consider updating those templates if the 
term "Reference Implementation" implies a higher standard than "we've put in 
the work to make this happen, and you can try it out here" (which is what I've 
usually used the section to communicate).

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

[Python-Dev] Re: Request for comments on final version of PEP 653 (Precise Semantics for Pattern Matching)

[Ethan Furman]

On 4/4/21 2:15 AM, Mark Shannon wrote:

Calling something a "reference" implementation suggests that it is something that people can refer to, that is near 
perfectly correct and fills in the gaps in the specification.


That is a high standard, and one that is very difficult to attain.


Indeed.  I don't think even the CPython reference implementation achieves that standard -- unless we have vastly 
different ideas on what "near perfectly correct" means.


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

[Python-Dev] PEP 647 Accepted

[Barry Warsaw]

The Python Steering Council reviewed PEP 647 -- User-Defined Type Guards, and 
is happy to accept the PEP for Python 3.10.  Congratulations Eric!

We have one concern about the semantics of the PEP however.  In a sense, the 
PEP subverts the meaning of the return type defined in the signature of the 
type guard, to express an attribute of the type guard function.  Meaning, type 
guard functions actually *do* return bools, but this is not reflected in the 
return type:

"Using this new mechanism, the is_str_list function in the above example would 
be modified slightly. Its return type would be changed from bool to 
TypeGuard[List[str]]. This promises not merely that the return value is 
boolean, but that a true indicates the input to the function was of the 
specified type.”

In fact, the promise that it returns a bool is de-facto knowledge you must have 
when you see “TypeGuard” in the return type.  It is an implicit assumption.

Generally this might not be a problem, however when a type guard function is 
used for multiple purposes (e.g. a type guard and a “regular” function), then 
the return type is misleading, since a TypeGuard object is *not* returned.  
It’s unclear what type checkers would do in this case.

The SC debated alternatives, including the decorator syntax specifically 
mentioned in the Rejected Ideas.  We also discussed making TypeGuard a 
“wrapping” type defining an __bool__() so that e.g. is_str_list() would be 
defined as such:

def is_str_list(val: List[object]) -> TypeGuard[List[str]]:
"""Determines whether all objects in the list are strings"""
return TypeGuard(all(isinstance(x, str) for x in val))

but this also isn’t quite accurate, and we were concerned that this might be 
highly inconvenient in practice.  In a sense, the type guard-ness of the 
function is an attribute about the function, not about the parameters or return 
type, but there is no way to currently express that using Python or type 
checking syntax.

I am not sure whether you considered and rejected this option, but if so, 
perhaps you could add some language to the Rejected Ideas about it.  Ultimately 
we couldn’t come up with anything better, so we decided that the PEP as it 
stands solves the problem in a practical manner, and that this is for the most 
part a wart that users will just have to learn and internalize.

Cheers,
-Barry (on behalf of the Python Steering Council)



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

[Python-Dev] Re: PEP 646 (Variadic Generics): final call for comments

[Stephan Hoyer]

I just wanted to thank Matthew & Pradeep for writing this PEP and for
clarifications to the broader context of PEP 646 for array typing in
https://github.com/python/peps/pull/1904.

As someone who is heavily involved in the Python numerical computing
community (e.g., NumPy, JAX, Xarray), but who is not so familiar with the
details of Python's type system, it is reassuring to see that a broad range
of use-cases related to type checking of named axes & shapes have been
considered, and could build upon the infrastructure in this PEP.

Type checking for shapes is something the NumPy community is very
interested in -- there are more thumbs up on the relevant issue on NumPy's
GitHub than any others (https://github.com/numpy/numpy/issues/7370) and we
recently added a "typing" module that is under active development.

It will certainly require experimentation to figure out the best ways to
use type checking for ndarrays, but this PEP looks like an excellent
foundation for such work.

On Sat, Mar 20, 2021 at 9:52 AM Matthew Rahtz via Python-Dev <
python-dev@python.org> wrote:

> Hi everyone,
>
> We've got to the stage now with PEP 646 that we're feeling pretty happy
> with it. So far though we've mainly been workshopping it in typing-sig, so
> as PEP 1 requires we're asking for some feedback here too before submitting
> it to the steering council.
>
> If you have time over the next couple of weeks, please take a look at the
> current draft and let us know your thoughts:
> https://www.python.org/dev/peps/pep-0646/ (Note that the final couple of
> sections are out of date; https://github.com/python/peps/pull/1880
> clarifies which grammar changes would be required, now that PEP 637 has
> been rejected. We also have a second PR in progress at
> https://github.com/python/peps/pull/1881 clarifying some of the
> motivation.)
>
> Thanks!
> Matthew and Pradeep
> ___
> 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/5GWS2GGVJ4PAMOWM6YVVKZVMR5BRFRGV/
> 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/UDM7Y6HLHQBKXQEBIBD5ZLB5XNPDZDXV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Request for comments on final version of PEP 653 (Precise Semantics for Pattern Matching)

[Greg Ewing]

On 7/04/21 5:22 am, Brandt Bucher wrote:

we might consider updating those templates if the term "Reference Implementation" implies 
a higher standard than "we've put in the work to make this happen, and you can try it out 
here"


Maybe "prototype implementation" would be better? I think I've used
that term in PEPs before.

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

[Python-Dev] Call for attention: pip’s migration path from distutils to sysconfig is narrowing

[Tzu-ping Chung]

Cross-posted from https://discuss.python.org/t/8111 on Brett’s suggestion.

A while ago, I proposed pip’s migration plan from distutils to sysconfig[1], in
preparation of distuitls’s deprecation and planned removal in Python 3.12. When
working on the implementation, however, I realised sysconfig currently lacks
important abstractions that pip needs to correctly interface with downstream
Python redistributors and alternative Python implementations. I raised the
issue in b.p.o.43312[2] and provided a pull request[3], but failed to progress
things forward.

With only one alpha window left[4], time is running out for the change to make
it into 3.10. If this has to wait for 3.11, pip will be left with only one year
to perform the migration away from distutils and detect possible backward
incompatibilities, which, since Python packaging tends to have a very long tail
of users on older Python versions, would make the distutils removal extremely
disruptive.

I wish this does not sound like I’m pressuring people to accept my patch; that
is not my intention at all. I do, however, very strongly feel pip’s inability
to remove distutils dependence is not taken seriously enough, and will be very
problematic if the status quo continues. Either something is done for sysconfig
in Python 3.10, or distutils’s removal must be delayed indefinitely until pip
is able to replace its distutils usages with stdlib replacements. Otherwise,
3.12 users will not be able to use pip.

[1]: https://github.com/pypa/pip/issues/9617
[2]: https://bugs.python.org/issue43312
[3]: https://github.com/python/cpython/pull/24644
[4]: https://discuss.python.org/t/8107


--
Tzu-ping Chung (@uranusjr)
uranu...@gmail.com
https://uranusjr.com

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

[Python-Dev] Re: Request for comments on final version of PEP 653 (Precise Semantics for Pattern Matching)

[Stephen J. Turnbull]

Greg Ewing writes:
 > On 7/04/21 5:22 am, Brandt Bucher wrote:
 > > we might consider updating those templates if the term "Reference
 > > Implementation" implies a higher standard than "we've put in the
 > > work to make this happen, and you can try it out here"
 > 
 > Maybe "prototype implementation" would be better? I think I've used
 > that term in PEPs before.

That seems to me to correspond well to Brandt's standard as expressed
above.

To me, "prototype implementation" is somewhere between "proof of
concept" and "reference implementation", and I welcome the additional
precision.  The big question is can such terms be used accurately (ie,
do various people assign similar meanings to them)?

I would define them functionally as

proof of concept
demonstrates some of the features, especially those that were
considered "difficult to implement"

prototype implementation
implements the whole spec, so can be used be developers to
prototype applications,

reference implementation
intended to be a complete and accurate implementation of the
specification

By "complete and accurate" I mean that it can be used experimentally
to understand what the spec means without much worry that the
proponent will brush off questions with "oh, that's just not
implemented yet, read the spec if you want to know how it will work
when we're done."  Furthermore, any divergence between spec and
implementation is a bug that is actually a broken promise.  (The
promise implied by "reference".)  Finally, as development continues
there is a promise that the spec and implementation will be kept in
sync (of course changes might be provisional, but even then the sync
should be maintained).

I don't think the Platonic ideal interpretation of "reference
implementation" is very useful.  Software evolves.  It evolves very
quickly during initial development, but it's useful to "ask the
implementation" about the spec even then.  That's implied by
methodologies like test-driven development.  There are other workflows
where that's not true.  My claim is that "reference implementation"
can be useful to distinguish development processes where you expect
the implementation to reliably reflect the spec, even in corner cases,
from those where you shouldn't.  And even as the software evolves.

Note that if we use this definition, then the "Reference
Implementation" requirement of the PEP process becomes quite a high
bar.  I think we all agree on that.  So I advocate, as Brandt
suggested, that we revise the PEP template.  In particular I think it
should use Greg's term "prototype implementation".  Optionally, we
could make "reference implementation" available to proponents who wish
to make that claim about their implementation.

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

[Python-Dev] How to attract developer attention to issue tracker items?

[pjfarley3]

Hi developers,

What should / shouldn't I do to attract any python developer response to
issue tracker items?  I am unsure of the proper procedure to follow so I am
asking here first.

I have filed two issues on the python issue tracker for python curses
issues:

1.  # 43715, a documentation update request (suggested additional
documentation file uploaded)
2.  # 43716, a possible ABI issue for the curses.pair_number() function
return value in a Windows environment

With respect to the documentation issue, I would appreciate any review of
whether the suggested documentation addition that I uploaded as a text file
is acceptable as-is or whether further refinement or correction is needed.

In the case of the possible ABI issue I am uncertain whether the issue is in
the python interface code or in the underlying curses implementation library
(windows-curses V2.2.0 using PDCurses).  I would appreciate it if anyone
knowledgeable of the python curses interfacing code could advise me whether
I need to pursue the issue with the third party library provider or with the
python development team.  At the moment all that I know is that the
"workaround" that I discovered corrects the issue under Windows but is not
necessary under linux / ncurses (in my testing I used Ubuntu 20.04 WSL2 to
confirm that fact).

TIA for your patience with my ignorance of the proper procedures and
channels.

My environment:

Windows 10 Pro 64 (latest version)
Python 3.8.9 (tags/v3.8.9:a743f81, Apr  6 2021, 14:02:34) [MSC v.1928 64 bit
(AMD64)]
Windows-curses V2.2.0

Peter
--

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