[Python-Dev] Re: PEP 448 review

[Brett Cannon]

Wow, we are now getting Canadian-specific spam!

Since the volume on this mailing list is so low, should we change everyone
to be moderated to start and then remove that after they have posted
appropriately? Or did this get through by accident?

On Wed, Mar 29, 2023 at 12:19 PM  wrote:

> It seems like you have thoroughly read through the PEP and the discussion
> thread and have formed an opinion about the proposed changes. It's great
> that you have taken the time to understand the proposal and the reasoning
> behind it.
>
> Georg Brandl's comments and Greg Ewing's explanations do shed light on
> some of the concerns raised by the proposal. However, it is good to see
> that you find the sequence and dict flattening syntax proposals to be clean
> and logical.
>
> Regarding the comprehensions part of the proposal, it appears that you are
> ambivalent about it. You acknowledge that it provides a way to flatten a
> sequence of sequences, but you also point out some of the odd edge cases
> that you discovered while experimenting in the interpreter. It's good to
> see that you are taking a cautious approach and are not rushing to endorse
> this part of the proposal.
>
> Overall, your analysis is thoughtful and well-reasoned. It's good to see
> that you are engaging with the proposal in a critical manner and taking
> into account the different perspectives presented in the discussion thread.
> Regards: https://www.extraappliance.ca/washing-machine-repair-edmonton/
> ___
> 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/6BP32AXSJAJPWHU274M3RBLLFUBSQUC6/
> 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/4ACX7TQV3YV6UDZ65AHPMM7UAWCJARYI/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: please consider changing --enable-unicode default to ucs4

[Brett Cannon]

Python no longer has `--enable-unicode` as part of `./configure`.

On Tue, Mar 14, 2023 at 9:26 AM Jonathan Benson via Python-Dev <
python-dev@python.org> wrote:

>
>
> Sent from my iPhone
> ___
> 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/TA3MZ2TSDGVAJ7NTTR5F37V7AVRM7ELR/
> 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/RH364BR4UKCJ5FY37PMOB55BX7O4S7GU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Contributing the Pyston jit?

[Brett Cannon]

FYI you will probably get more engagement if you posted this to
discuss.python.org .

On Thu, Feb 23, 2023, 10:18 Kevin Modzelewski  wrote:

> Hello all, we on the Pyston team would like to propose the contribution of
> our JIT
>  
> into
> CPython main. We're interested in some initial feedback on this idea before
> putting in the work to rebase the jit to 3.12 for a PEP and more formal
> discussion.
>
> Our jit is designed to be simple and to generate code quickly, so we
> believe it's a good point on the design tradeoff curve for potential
> inclusion. The runtime behavior is intentionally kept almost completely the
> same as the interpreter, just lowered to machine code and with
> optimizations applied.
>
> Our jit currently targets Python 3.7-3.10, and on 3.8 it achieves a 10%
> speedup on macrobenchmarks (similar to 3.11). It's hard to estimate the
> potential speedup of our jit rebased onto 3.12 because there is overlap
> between what our jit does and the optimizations that have gone into the
> interpreter since 3.8, but there are several optimizations that would be
> additive with the current performance work:
> - Eliminating bytecode dispatch overhead
> - Mostly-eliminating stack management overhead
> - Reducing the number of reference count operations in the interpreter
> - Faster function calls, particularly of C functions
> - More specialization opportunities, both because a jit is not limited by
> bytecode limits, but also because it is able to do dynamic specializations
> that are not possible in an interpreter context
>
> There is also room for more optimizations -- in Pyston we've co-optimized
> the interpreter+jit combination such as by doing more extensive profiling
> in the interpreter. Our plan would be to submit an initial version that
> does not contain these optimizations in order to minimize the diff, and add
> them later.
>
> Our jit uses the DynASM assembler library (part of LuaJIT) to generate
> machine code. Our jit currently supports Mac and Linux, 64-bit ARM and
> x86_64. Now that we have two architectures supported, adding additional
> ones is not too much work.
>
> We think that our jit fits nicely in the technical roadmap of the Faster
> CPython project, but conflicts with their plan to build a new custom
> tracing jit.
>
>
> As mentioned, we'd love to get feedback about the overall appetite for
> including a jit in CPython!
>
> kmod
> ___
> 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/7HTSM36GBTP4H5HEUV4JMCDSVYVFFGGV/
> 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/ZUF5ZYFNFHVMVPCJMSQA23MCVM2OPJTN/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Contributing the Pyston jit?

[Brett Cannon]

On Thu, Feb 23, 2023, 11:34 Wes Turner  wrote:

> Please consider colesbury/nogil in rebasing?
> https://github.com/colesbury/nogil
>

It's very premature for anyone to concern themselves with Sam's nogil work
when it comes to their own work as PEP 703 has not been sent to the SC (let
alone been accepted).


>
> On Thu, Feb 23, 2023, 1:20 PM Kevin Modzelewski  wrote:
>
>> Hello all, we on the Pyston team would like to propose the contribution
>> of our JIT
>>  
>> into
>> CPython main. We're interested in some initial feedback on this idea before
>> putting in the work to rebase the jit to 3.12 for a PEP and more formal
>> discussion.
>>
>> Our jit is designed to be simple and to generate code quickly, so we
>> believe it's a good point on the design tradeoff curve for potential
>> inclusion. The runtime behavior is intentionally kept almost completely the
>> same as the interpreter, just lowered to machine code and with
>> optimizations applied.
>>
>> Our jit currently targets Python 3.7-3.10, and on 3.8 it achieves a 10%
>> speedup on macrobenchmarks (similar to 3.11). It's hard to estimate the
>> potential speedup of our jit rebased onto 3.12 because there is overlap
>> between what our jit does and the optimizations that have gone into the
>> interpreter since 3.8, but there are several optimizations that would be
>> additive with the current performance work:
>> - Eliminating bytecode dispatch overhead
>> - Mostly-eliminating stack management overhead
>> - Reducing the number of reference count operations in the interpreter
>> - Faster function calls, particularly of C functions
>> - More specialization opportunities, both because a jit is not limited by
>> bytecode limits, but also because it is able to do dynamic specializations
>> that are not possible in an interpreter context
>>
>> There is also room for more optimizations -- in Pyston we've co-optimized
>> the interpreter+jit combination such as by doing more extensive profiling
>> in the interpreter. Our plan would be to submit an initial version that
>> does not contain these optimizations in order to minimize the diff, and add
>> them later.
>>
>> Our jit uses the DynASM assembler library (part of LuaJIT) to generate
>> machine code. Our jit currently supports Mac and Linux, 64-bit ARM and
>> x86_64. Now that we have two architectures supported, adding additional
>> ones is not too much work.
>>
>> We think that our jit fits nicely in the technical roadmap of the Faster
>> CPython project, but conflicts with their plan to build a new custom
>> tracing jit.
>>
>>
>> As mentioned, we'd love to get feedback about the overall appetite for
>> including a jit in CPython!
>>
>> kmod
>> ___
>> 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/7HTSM36GBTP4H5HEUV4JMCDSVYVFFGGV/
>> 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/EL7O7TJNYBFH2MRAV2AZCBUWV2TVUXMW/
> 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/6QS5NJUIX4OB645IFIGMQM2UHNECSQMG/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Python Launcher not Installed on Windows Machine

[Brett Cannon]

How did you install Python? If you got it from the Microsoft Store I
believe the Python Launcher is not included.

On Tue, Dec 13, 2022 at 7:20 PM Margo Hoover 
wrote:

> Dear Jonathan and Brian,
>
> I have python and pip installed on my Windows machine. However, I do not
> seem to have the python launcher installed (if that is even possible). I am
> a very beginner in Python. Could you explain how I should 'download' the
> python installer, or if I should even do that. What would be a next step?
>
> Thank you once again,
>
> Sincerely,
>
> Margaux Hoover
>
> --
>
> Margaux Hoover
>
> Xtrepid Design
> ___
> 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/RDA5VNV2CDGARVUVKPV2VW6GRWLMWV3S/
> 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/SNOKIVOL55FOJZ5J2CPXFNL5LZJHTX7O/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Switching to Discourse

[Brett Cannon]

On Fri, Dec 2, 2022 at 8:17 AM Baptiste Carvello <
devel2...@baptiste-carvello.net> wrote:

> Le 02/12/2022 à 10:09, Gregory P. Smith a écrit :
> >
> > On Thu, Dec 1, 2022 at 8:37 AM Victor Stinner  > > wrote:
> >
> >
> > Should we *close* the python-dev mailing list?
> >
> >
> > I'd be in favor of this.
>
> Why?


Because in the past people have complained about having too many places to
keep track of discussions (and this goes in both directions; some people
don't read email regularly while others live in their inbox). Since we are
promoting/pushing folks to use discuss.python.org it means this mailing
list starts to feel like more of a burden/excess.

-Brett


> Californian firms won't let their employees use an unmoderated
> forum for fear of liability: OK, so be it. But that's no reason to force
> other people to use tools they dislike.


We are just saying that we may, as a team, not want to be the people
providing a mailing list for folks to use to discuss Python development. Or
at the very least not make it feel like a requirement for core devs to
monitor this mailing list like it has been in the past. If people choose to
keep using email then they can choose to do so on their own, just like IRC
or any other place people chat.

-Brett


> "Modern tools" hegemonism is
> little more than pure intolerance.
>
> Or at least setting up an auto-responder
> > suggesting people post on discuss.python.org 
> > instead.
>
> Just put a line in the list signature stating that discussions requiring
> core-dev attention should happen on discourse, and be done.
>
> Cheers,
> Baptiste
> ___
> 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/IDKDF7P4WTNVZNJHJZIEQB2M42THOJ3V/
> 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/VJMEAXDGZBENDSCIIFZM65SHK7VEU3QJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: A proposal to modify `None` so that it hashes to a constant

[Brett Cannon]

On Tue, Nov 29, 2022 at 12:58 PM Yoni Lavi  wrote:

> It does make your argument invalid though,


It makes that single sentence invalid, but the rest of my points still
hold, e.g. the language makes no guarantee about hash consistency between
executions, set order is not guaranteed, etc. are all still valid points.
And as I said earlier, I also agree with the points made in the issue you
linked to, so I'm still -0 on this.

-Brett


> since it's based on this assumption that I was asking for a requirement on
> iteration order (e.g. like dict's iteration order = insertion order
> guarantee), which is not the case.
>
> Again, determinism means that given all input data and commands fed to a
> data structure is the same, it will arrive at the same observable state,
> any time you start from scratch and replay this workload. In the context of
> sets, "all input data" includes the hashing function itself, and
> "observable state" also includes the order in which items will be returned
> if iterated. Note that there is NO requirement here on what that order
> might be.
>
> Under this definition, sets in Python are deterministic, and _always_ have
> been. And even outside of Python, there are aren't many cases where people
> willingly want to use data structures with non deterministic behavior. It
> usually involves concurrency (in the form of multithreading) and extreme
> performance requirements. And it's never the "standard" choice even in
> languages that do offer this. Determinism is generally considered as a
> valuable property in computation, at least when it is feasible to maintain
> it.
> ___
> 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/5Z3SOH4JDHRGYF4NTLND4E2UFM7QIXTL/
> 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/LTX5IT5ST3BU7T4CZ5M4G4Z4Q2X2CTNV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: A proposal to modify `None` so that it hashes to a constant

[Brett Cannon]

On Mon, Nov 28, 2022 at 5:38 PM Steven D'Aprano  wrote:

> On Mon, Nov 28, 2022 at 11:13:34PM +, Oscar Benjamin wrote:
> > On Mon, 28 Nov 2022 at 22:56, Brett Cannon  wrote:
>
> > > That's actually by design. Sets are not meant to be deterministic
> > > conceptually as they are essentially a bag of stuff. If you want
> > > deterministic ordering you should convert it to a list and sort the
> > > list.
> >
> > What does "sets are not meant to be deterministic" even mean?
>
> I'm not Brett, so I'm not answering for him, but many people (sometimes
> including me) misuse "not deterministic" to refer to set order and the
> old dict order.


Yep, that's what I mean. And my comment about dicts earlier is old
knowledge from before we made dict iteration deterministic based on
insertion order since I'm been doing this for too long. 

-Brett


> Of course set order is deterministic, it is determined
> by the combination of the set implementation, the hashing algorithm, and
> the history of the set -- all the items that have ever appeared in the
> set (both those removed and those that remain).
>
> Set order is deterministic in the same way that roulette wheels are
> deterministic.
>
> We don't have a good term for this: the items don't appear in random
> order. But it is not predictable either, except in very special cases.
> "Arbitrary" is not right either, since that implies we can easily choose
> whatever set order we want.
>
> I think that physicists call this "deterministic chaos"
>
>
> https://www.quora.com/Theoretical-Physics-What-is-deterministic-but-unpredictable
>
> (sorry for the quora link) so I guess we might say that set iteration
> order is "deterministically chaotic" if you want to be precise, but life
> is too short for that level of pedantry (and that's coming from me, a
> Grade A Pedant *wink*) so people often describe it as random, arbitrary,
> or non-deterministic when it's none of those things :-).
>
> Maybe we could call set order "pseudo-random".
>
> Getting back to the design part, I think that what Brett is trying to
> get across is not that the chaotic set order is in and of itself a
> requirement, but that given the other requirements, chaotic set order is
> currently considered a necessary condition.
>
> As I understand it, we could make sets ordered, but only at the cost of
> space (much more memory) or time (slower) or both.
>
> I am sure that Guido is correct that **if** somebody comes up with a
> fast, efficient ordered set implementation that doesn't perform worse
> than the current implementation, we will happily swap to giving sets a
> predictable order, as we did with dicts. (Practicality beats purity --
> even if sets are *philosophically* unordered, preserving input order is
> too useful to give up unless we gain something in return.)
>
> But I don't think it is fair or kind to call Brett's argument FUD. At
> the very least it is uncharitable interpretation of Brett's position.
>
> > It would be useful to have a straight-forward way to sort a set into a
> > deterministic ordering but no such feature exists after the Py3K
> > changes (sorted used to do this in Python 2.x).
>
> `sorted()` works fine on homogeneous sets. It is only heterogeneous sets
> that are a problem, and in practice, that usually means None mixed in
> with some other type.
>
>
> --
> 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/UAVNSMS3XFAQQ6ZRD27IXPTWZFCHP6M4/
> 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/ZUACMM6HDUOG4VIAPAK7W5Q6WQRRLI2U/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: A proposal to modify `None` so that it hashes to a constant

[Brett Cannon]

On Sun, Nov 27, 2022 at 11:36 AM Yoni Lavi  wrote:

> I wrote a doc stating my case here:
>
> https://docs.google.com/document/d/1et5x5HckTJhUQsz2lcC1avQrgDufXFnHMin7GlI5XPI/edit#
>
> Briefly,
>
> 1. The main motivation for it is to allow users to get a predictable
> result on a given input (for programs that are doing pure compute, in
> domains like operations research / compilation), any time they run their
> program. Having stable repro is important for debugging. Notebooks with
> statistical analysis are another similar case where this is needed: you
> might want other people to run your notebook and get the same result you
> did.
>

But the hash of an object is not guaranteed to be stable by the language,
so I would argue someone expecting that is expected to convert
random-access data structures  to ones that are consistent when necessary
(e.g. sorted lists).


>
> 2. The reason the hash non-determinism of None matters in practice is that
> it can infect commonly used mapping key types, such as frozen dataclasses
> containing `Optional[int]` fields.
>

I don't see why the hashing within a dict needs to be consistent as that's
not a guarantee we make with Python.


>
> 3. Non-determinism emerging from other value types like `str` can be
> disabled by the user using `PYTHONHASHSEED`, but there's no such protection
> against `None`.
>

If I remember correctly, PYTHONHASHSEED was added to help folks migrate
when we added randomness to hashing as they had accidentally come to expect
a consistent iteration order on dictionary keys. I wouldn't take its
existence to suggest that PYTHONHASHSEED is meant to make **all** hashing
consistent (e.g. people who implement their own __hash__ don't have to
follow that expectation).


>
> All it takes is for your program to compute a set somewhere with affected
> keys, and iterate on it - and determinism is lost.
>

That's actually by design. Sets are not meant to be deterministic
conceptually as they are essentially a bag of stuff. If you want
deterministic ordering you should convert it to a list and sort the list.


>
> The need to modify None itself is caused by two factors
> - `Optional` being implemented effectively as `T | None` in Python as a
> strongly established practice
> - The fact that `__hash__` is an intrinsic property of a type in Python,
> the hashing function cannot be externally supplied to its builtin container
> types. So we have to modify the type None itself, rather than write some
> alternative hasher that we could use if we care about deterministic
> behavior across runs.
>
> This was debated at length over the forum and in discord.
> I also posted a PR for it, and it was closed, see:
>
> https://github.com/python/cpython/issues/99540
> https://github.com/python/cpython/pull/99541
>
> Asking for opinions, and to re-open the PR, provided there is enough
> support for such a change to take place.
>

I personally agree with the arguments made in the issue, so I'm afraid I
don't' support making the change as we worked hard to stop people from
relying on consistent hashing/iteration from random-access data structures
like dict and set.

-Brett


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

[Python-Dev] Re: problem with Distributed File System Replication and Namespacing and different versions of Python 3

[Brett Cannon]

On Fri, Oct 21, 2022 at 11:11 AM Juan Cristóbal Quesada <
rainonthescarecrowhumanwhe...@gmail.com> wrote:

> I guess my simplified question would be:
>
> ¿how does Python 3 versions manage Distributed File Systems and in
> particular Windows' DFS?
>

In no specific way. We typically ask the OS to handle any file system
details.


>
> Is it supported by the "import system" in Python? What differences are
> there?
>

Not explicitly. Everything is done via file paths and things in the os
module (technically the posix or nt module depending on what OS you are
running on).

-Brett


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

[Python-Dev] Re: problem with Distributed File System Replication and Namespacing and different versions of Python 3

[Brett Cannon]

Import is implementing in Python itself via importlib, so you could try
walking through the code with a debugger to see where the difference may be
(I personally can't think of anything obvious that changed in importlib
between 3.9 and 3.10 that would affect this).

On Thu, Oct 20, 2022 at 11:36 AM 
wrote:

> Hi,
> I have a question about a problem we are facing in different Python
> versions, like Python 3.7.7, Python 3.8, Python 3.6 and Python 3.9.
> This apparently doesnt happen in Python 3.10.2 and we were wondering how
> we could achieve the same behaviours without going deep into the nuts and
> bolts of the python import system.
>
> We have python libraries that are distributed in a networked environment
> that when imported for the first time they are correctly imported but
> something happens in the meantime that prevents it from loading anymore.
> This networked paths are domain paths that are bound to a final "real" path
> in a specific file server from a specific site in the world.
>
> What happens is, when injecting into the sys.path the domain names it
> doesnt import but when injecting into the sys.path the "real" file server
> path it works, generally speaking. We have been facing this issue in such
> different python 3 versions and i was wondering what makes this work in
> Python 3.10.2.
>
> Apparently, in my opinion it is a mix of two things involved: one,
> something the DFS-R DFS-N does at a very low level, that python 3 versions
> dont like when importing and the other one, the fact that is a network path.
>
> Can anybody shed some light about the improvements regarding this?
>
> We will be tied to all these python versions for a very long time and we
> need to give solution to this.
> One of the possibilities would be to distribute the libraries into C:/
> local disc, this eliminating the network path variable. But it would be
> nice to know what is causing this in Python < 3.10.2.
>
> Thanks in advance.
> ___
> 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/5EJ7FAWQSUOFFYSCBZF2NRQSY3SULVV5/
> 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/P4DVGKVDXOFY2VAG2PKAZGG7BTDRK2E5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Moving to Discourse

[Brett Cannon]

On Thu, Sep 22, 2022 at 12:41 AM Baptiste Carvello <
devel2...@baptiste-carvello.net> wrote:

> Hello,
>
> Le 21/09/2022 à 13:14, Petr Viktorin a écrit :
> > On 21. 09. 22 10:17, Baptiste Carvello wrote:
> >>
> >> * mailing-list mode: there needs to be a *standardized* set of filters
> >> to access Core-Dev + PEPs (and only that).
> >> [...]
>
> > Do you have a proposal we could standardize?
> > Open a PR on the devguide. You shouldn't need an official hat-wearer
> > around, unless there's a disagreement.
>
> I believe indeed that the devguide should provide complete guidance
> towards getting a python-dev equivalent using mailing-list mode, to
> avoid many users having to reinvent the wheel. I don't have enough
> experience to give such advice myself (yet).
>
> > But I don't think the goal is to make sure all people using the mailing
> > list get the same set of posts. Different people have different
> interests.
>
> That's exaggerated: often many people share common interests, and thus
> want to follow a common set of discussions.


... which is expected to take place on Discourse. A key point here is we
are trying to consolidate after having this split approach for a few years
that people found annoying. We also acknowledge we can't stop people from
talking wherever they want on the internet.


> This is what makes up a
> discussion forum. Python-dev has served well its hundreds (or is it
> thousands) of users over all those years, so its perimeter must be
> sensible enough.
>

But the mailing list has also not served others well either (and people
have explicitly told us the mailing list didn't serve them, so this isn't a
hypothesis), so I don't think it "must be sensible enough" that what
python-dev does is always best/right/sensible. There is no perfect
solution, hence why we had this lengthy discussion to begin with.


>
> > Only mirroring/archiving Core-Dev + PEPs also seems pretty arbitrary.
>
> According to the devguide, "these are the Discourse equivalents to the
> python-dev mailing list". I believe many people want just that. This is
> also the perimeter that makes most sense for long term external
> archival, as it is likely to contain all major design discussions.
>
> >> * RSS: the shortcomings I described in my august post [2] are still
> >> there. At the very least, the PSF needs to make sure that the age /
> >> length limits of the RSS files (both core-dev.rss and posts.rss) are
> >> *much* increased.
>
> > I'm not sure what the PSF can do here -- this sounds like it should be a
> > feature request to Discourse.
>
> Discourse could indeed make their RSS interface much friendlier. Alas,
> as I say in my previous message, a very useful feature request
> (per-category post feeds) has been lingering for 6 years. So I won't
> hold my breath.
>
> In the meantime, I suppose Discourse must have some instance
> configuration knobs, and it would make sense that the length of the RSS
> files can be changed there (being a very arbitrary limit). The PSF could
> then choose a more appropriate length just for their own instance (the
> current 25-post limit represents less than 24 hours; a few days instead
> would be nice).
>

If you can find the setting then we can look at tweaking it, but a quick
glance at the admin interface didn't turn up anything obvious.

-Brett


>
> > I guess the mailing list mode is a better option if you don't want to
> > miss anything. Is it lacking something that RSS provides, besides easier
> > filtering?
>
> There is room between not missing anything and having less than 24 hours
> of history available.
>
> Since you asked (but not a major point): RSS is accessible without
> registering an account.
>
> Cheers,
> Baptiste
>
> >> [2]
> >>
> https://mail.python.org/archives/list/python-dev@python.org/message/UZJ27G57F7QJJ2LYBDGZQ5BIXLH7OXWJ/
> ___
> 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/MBARP67IL4X3LUWQGEELTMFPJCLUXBTI/
> 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/ZD27KIII3TVMKZJSTRBYAKBS3BU43JUZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Switching to Discourse

[Brett Cannon]

On Fri, Jul 22, 2022 at 3:45 AM Samuel Colvin  wrote:

> Reading this thread and thinking about discuss.python.org/Discourse - I'm
> surprised no one is advocating github discussions
> .
>

I think it's because discuss.python.org is what we decided to try years ago
at the 2018 core dev sprint (so nearly 4 years ago), while GitHub
Discussions would be a brand new thing to try and get people on board with.


>
> In particular organisation discussions
>  would
> provide an obvious central place for discussions that would be easy to find
> and use for everyone.
>
> Advantages of github discussions:
>
>- Virtually all developers have a github account and are familiar with
>github & GFM
>
>
Discourse lets you log in via GitHub. I'm not sure if Discourse is straight
Commonmark (probably is, though, since the co-creator of Discourse kicked
off Commonmark because of Discourse).


>
>- Github provides great support for participating or watching
>discussion via email - Discourse is really bad at this (at least by 
> default)
>- GH discussions obviously integrate well with the rest of github -
>links to issues & pull requests (including other repos), discussions can be
>moved to other repos, issues can be created from discussions, issues can be
>converted to discussions - e.g. if someone creates a bug report which
>should really be a feature discussion
>
>
True, but that does make the discussion specific to the repo, which in this
instance would be CPython and somewhat the language itself. This doesn't
encompass something like packaging which has completely moved all
development discussions over to discuss.python.org (and people have been
generally happy with it). So I'm not sure if moving over to Discussions
would actually lead to discuss.python.org going anywhere if you were trying
to eliminate that need.


>
>- No extra service to maintain or pay for
>
> This is already true for discuss.python.org; Discourse is kindly donating
the hosting on their SaaS platform.

>
>- GH discussions (unlike issues) provide good threading functionality
>without the full treeview madness of hackernews etc.
>
> Before going "all in" with discuss.python.org/Discourse I think GH
> discussions should be seriously considered.
>

If you can get people excited enough to say they are willing to give it a
try, and the folks saying they are going to stop participating if/when we
move to Discourse would actually stay if we moved to Discussions, then we
can definitely talk about it.

-Brett


>
> Samuel
>
> --
>
> Samuel Colvin
>
>
> On Fri, 15 Jul 2022 at 12:19, Petr Viktorin  wrote:
>
>> Hello,
>> Currently development discussions are split between multiple
>> communication channels, for example:
>> - python-dev and discuss.python.org for design discussions,
>> - GitHub Issues and Pull Requests for specific changes,
>> - IRC, Discord and private chats for real-time discussions,
>> - Topic-specific channels like typing-sig.
>>
>> While most of these serve different needs, there is too much overlap
>> between python-dev and discuss.python.org. It seems that for most
>> people, this situation is worse than sticking to either one platform –
>> even if we don't go with that person's favorite.
>>
>> The discuss.python.org experiment has been going on for quite a while,
>> and while the platform is not without its issues, we consider it a
>> success. The Core Development category is busier than python-dev.
>> According to staff, discuss.python.org is much easier to moderate.. If
>> you're following python-dev but not discuss.python.org, you're missing
>> out.
>>
>> The Steering Council would like to switch from python-dev to
>> discuss.python.org.
>> Practically, this means:
>> - Moving the required PEP announcements to discuss.python.org
>> - Moving discuss.python.org up in the devguide communications page
>> (https://devguide.python.org/communication/)
>> - And that's it?
>>
>> I imagine that the mailing list will stay around for continuing past
>> discussion threads and for announcements, eventually switching to
>> auto-reject incoming messages with a pointer to discuss.python.org.
>>
>> To be clear, discuss.python.org allows editing posts, which is frankly
>> handy for typos and clarifications. Editing alone should not be used for
>> adding new info -- we should cultivate a culture of being friendly to
>> mail users & notification watchers. This probably bears repeating in a
>> few places.
>>
>> We're aware not everyone wants to use the discuss.python.org website,
>> but there are some ways to avoid it:
>>
>> - For new PEPs, you can point your RSS client to
>> https://www.python.org/dev/peps/peps.rss – it's not e-mail, but many
>> email clients have RSS support. You can also watch the Steering Council
>> issues on GitHub (https://github.com/python/steering-council/issues/)
>> for important 

[Python-Dev] Re: Switching to Discourse

[Brett Cannon]

On Thu, Jul 21, 2022 at 10:34 AM Skip Montanaro 
wrote:

> > No, Discord is a different thing; it does text and voice communication
> > channels in real-time. If you're familiar with Slack, it's broadly
> > similar in purpose.
>
> Thanks (and to the others who replied).


FYI this multiple responses issue doesn't come up on Discourse because the
replies are shown in real-time (as is the "Skip is typing ..." at the
bottom).


> It seems like they've tried to
> make it a game, giving me the "opportunity" to buy boosts (or
> whatever). What's up with that?


It's for "funding" a Discord server and how Discord makes money (otherwise
the service is free).


> Do we really need yet another place
> full of overlapping discussion channels?
>

Discord isn't overlapping with Discourse. Think of Discord as replacing IRC
while also providing audio chat (and other things). For instance, people
who were working together to squash release blockers for b4 were chatting
live on Discord.
___
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/XVDO47NTGAPYELRZYLAYJJVJGHOP2NBD/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Do not harass other mailing list subscribers privately

[Brett Cannon]

The SC has been notified of at least one instance of someone subscribed to
this list harassing another subscriber privately. We wanted to remind folks
that we expect people to behave reasonably towards each other, else people
risk losing access to this mailing list and other places where Python is
developed per the Code of Conduct.

Poor behaviour, public or private, is not acceptable and will have
ramifications where we are trying to facilitate an open, considerate, and
respectful community that is under our control.

-Brett, on behalf of the Python steering council
___
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/M6KNQVHRKOBU4WHCEYQINA37A7F433J2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: compiling errors, SSL

[Brett Cannon]

On Tue, Jul 19, 2022 at 2:17 PM Kevin T via Python-Dev <
python-dev@python.org> wrote:

> I have built this on systems at work, that are populated by CAD guys who
> have developed a good set of libraries to maintain in a linux
> distribution.  Went without a hitch.
>
> I am trying to build this at home with an opensuse distribution.  I am not
> trying to do any modifications to python, now or in the future.  I am
> trying to build this as another software installation wants 3.7 or better
> and opensuse provided 3.6.
>
> I am stuck with a early compile error after the make command.
>
> I have downloaded, built and installed the openSSl.
> I have changed the ld.so.conf to include the newly built ssl in the list
> and re-ran ldconfig.  Even though I have added the newly built ssl to the
> conf file a dump of the ldconfig does not show the locally built ssl libs.
> Does this process depend on LD_LIBRARY_PATH ?  Defining LD_LIBRARY_PATH
> made no discernable difference.
>
> kevin@localhost:~/Sources/Python-3.10.5> sudo ldconfig -p | grep ssl
> [sudo] password for root:
>libssl3.so (libc6,x86-64) => /usr/lib64/libssl3.so
>libssl.so.1.1 (libc6,x86-64) => /usr/lib64/libssl.so.1.1
>libevent_openssl-2.1.so.6 (libc6,x86-64) =>
> /usr/lib64/libevent_openssl-2.1.so.6
>
> The newly built ssl dir:
> kevin@localhost:~/Sources/Python-3.10.5> ls -lrt /usr/local/ssl
> total 40
> drwxr-xr-x 1 root root14 Jul 18 15:17 include
> drwxr-xr-x 1 root root   190 Jul 18 15:17 lib64
> drwxr-xr-x 1 root root30 Jul 18 15:17 bin
> drwxr-xr-x 1 root root 0 Jul 18 15:17 private
> drwxr-xr-x 1 root root 0 Jul 18 15:17 certs
> drwxr-xr-x 1 root root36 Jul 18 15:17 misc
> -rw-r--r-- 1 root root 12292 Jul 18 15:17 openssl.cnf.dist
> -rw-r--r-- 1 root root 12292 Jul 18 15:17 openssl.cnf
> -rw-r--r-- 1 root root   412 Jul 18 15:17 ct_log_list.cnf.dist
> -rw-r--r-- 1 root root   412 Jul 18 15:17 ct_log_list.cnf
> drwxr-xr-x 1 root root12 Jul 18 15:18 share
>
>
> I see in the web pages the known prerequisites and installed them.
> kevin@localhost:/usr/local/ssl/lib64> sudo zypper install python310-idle
> python310-devel python310-curses python310-dbm python310-tk
>
> kevin@localhost:/usr/local/ssl/lib64> sudo zypper install build-essential
> gdb lcov pkg-config   libbz2-dev libffi-dev libgdbm-dev
> libgdbm-compat-dev liblzma-dev   libncur
> ses5-dev libreadline6-dev libsqlite3-dev libssl-dev   lzma lzma-dev
> tk-dev uuid-dev zlib1g-dev
>
> I see in the web pages this snip:
>
> Python build finished successfully!
> The necessary bits to build these optional modules were not found:
> _bz2  _dbm  _gdbm
> _lzma _sqlite3  _ssl
> _tkinter  _uuid readline
> zlib
> To find the necessary bits, look in setup.py in detect_modules()
> for the module's name.
>
> What is one supposed to do with detect_modules?  Add something or remove
> something ?
>

It's up to you. It's more of a hint to let you know how Python searches for
what it needs to build those modules. Also know that setup.py is going away
in Python 3.12: https://github.com/python/cpython/pull/94474 .
___
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/NEZNAJA42G7A6ZTQFD4O33CUBFTUBWQ5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: New `python` Organization Repository Policy

[Brett Cannon]

On Fri, Jul 15, 2022 at 4:54 AM Joannah Nanjekye 
wrote:

> I understand that the steering council decides new repositories that can
> be added to the Python organization but as a committer, it is good courtesy
> that public decisions are discussed first on committer channels because
> this impacts allow us to a degree I.e you are some how responsible for that
> code too.
>

I think that's fair. I opened
https://github.com/python/steering-council/issues/132 to discuss it.
Obviously if people have opinions on this, please share them here.

-Brett


> At least I get notifications for all repositories.
>
> On Fri., Jul. 15, 2022, 2:32 p.m. Petr Viktorin, 
> wrote:
>
>> (Cross-posted from
>>
>> https://discuss.python.org/t/new-python-organization-repository-policy/17376
>> – please perfer commenting there.)
>>
>> Hello,
>>
>> When asked about adding the typing_extensions repository to the Python
>> organization (https://github.com/python/steering-council/issues/126),
>> the Steering Council discussed a general policy for the organization, as
>> the current one
>> (https://devguide.python.org/devcycle/#organization-repository-policy)
>> seems outdated.
>>
>> We decided on the guidelines below.
>>
>> Note that existing repositories can stay under python. However, we will
>> ask that:
>> – PSF infrastructure be moved under the psf organization, and
>> – all repositories under python will need to require the CLA and have
>> two-factor authentication for all committers, otherwise move elsewhere
>> or be archived.
>>
>> – Petr, on behalf of the Steering Council
>>
>>
>>
>>
>> New Organization Repository Policy
>>
>> Within the GitHub Python organization, repositories are expected to
>> relate to the Python language, the CPython reference implementation,
>> their documentation and their development workflow. This includes, for
>> example:
>> - The reference implementation of Python and related repositories (i.e.
>> CPython)
>> - Tooling and support around CPython development (e.g. pyperformance,
>> Bedevere)
>> - Helpers and backports for Python/CPython features (e.g.
>> typing-extensions,  typeshed, tzdata, pythoncapi-compat)
>> - Organization-related repositories (e.g. the Code of Conduct, .github)
>> - Documentation and websites for all the above (e.g. python.org
>> repository, PEPs, Devguide, docs translations)
>> - Infrastructure for all the above (e.g. docsbuild-scripts,
>> buildmaster-config)
>> - Discussions and notes around official development-related processes
>> and events (e.g. steering-council, core-sprint)
>>
>> Before adding a new repository, permission should be sought from the
>> Python steering council. Note that several repositories remain in the
>> organization for historic reasons, and would probably not be appropriate
>> today.
>>
>> All non-archived repositories must require contributors to sign the PSF
>> Contributor Agreement.
>>
>> Generally, new repositories should start their life under personal
>> GitHub accounts or other GitHub orgs. It is relatively easy to move a
>> repository to the organization once it is mature. For example, this
>> would now apply to experimental features like asyncio, exceptiongroups
>> or typed_ast and drafts of new guides and other documentation (e.g.
>> redistributor-guide).
>>
>> General-use tools and libraries (e.g. mypy or black) should also be
>> developed outside the python organization, unless core devs (as
>> represented by the SC) specifically want to “bless” one implementation
>> (as with e.g. typeshed, tzdata, or pythoncapi-compat).
>> ___
>> 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/JP4T26I5HLO5SB3DKELDPQJPOR4JHLAN/
>> 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/FAASOMUNQZDJBCOTZK6I2KH55SDOONF6/
> 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/5ABWATH2YMMBTTGHZAWN6AK23V6UQOOG/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Method __func__ objects are unpicklable

[Brett Cannon]

I believe a lot of people use https://pypi.org/project/cloudpickle/ thanks
to its support for pickling functions.

On Fri, Jun 10, 2022 at 4:56 AM haael  wrote:

>
>
> During some sophisticated pickling I noticed that method `__func__`
> objects are unpicklable, because they share the name with the bound
> method object itself.
>
>
> ```
> from pickle import dumps
>
> class A:
>  @classmethod
>  def b(cls):
>  pass
>
> print(A.b) # >
> print(A.b.__func__) # 
>
> dumps(A.b) # works
> dumps(A.b.__func__) # breaks
> # >Traceback (most recent call last):
> # >  File "", line 1, in 
> # >_pickle.PicklingError: Can't pickle :
> # >it's not the same object as __main__.A.b
> ```
>
>
> The last call compains that global symbol "A.b" is not the same object
> as `A.b.__func__`.
>
> Everything would work if the `__func__` objects had the suffix
> ".__func__" in their qualname.
>
> Actually setting the qualname of the `__func__` object makes it
> picklable, but then the bound method object is unpicklable, as it
> inherits the name from the `__func__`. It would be good if they were
> separate.
>
> This is an attempt at emulating the desired behavior:
>
>
> ```
> from pickle import dumps
>
> class A:
>  pass
>
> def c(cls):
>  pass
>
> A.c = lambda: c(A)
> A.c.__qualname__ = "A.c"
> A.c.__name__ = "c"
> A.c.__self__ = A
> A.c.__func__ = c
> A.c.__func__.__qualname__ = "A.c.__func__"
>
> print(A.c) # 
> print(A.c.__func__) # 
>
> dumps(A.c) # works
> dumps(A.c.__func__) # works
> ```
>
>
> Can we make the `__func__` objects picklable this way?
>
>
> haael
>
> ___
> 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/N2J6MVLURTBAB5PJLJG3LO6U4PTPJMU2/
> 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/NSBJC3266COHPPTNJMLVDHNW4AS7E4QE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 689 – Unstable C API tier (was: Semi-stable C API tier)

[Brett Cannon]

On Mon, May 30, 2022 at 12:54 PM Steve Dower  wrote:

> I prefer separate header files, provided people outside of core always
> have one (presumably "Python.h") that should be included first and
> includes enough info to check which headers will be available (i.e. the
> version defs).
>

The idea we were kicking around was e.g. `Python-unstable.h` would be all
of the limited API plus the unstable parts, `Python-unlimited.h` would be
**everything**, etc. I would expect `Python.h` would continue to be what it
is today for compatibility purposes. There wouldn't necessarily be an
"always have one" header since these header files would cascade into each
other as you opted into more and more unstable APIs (think about this as
layers of APIs  and representing each encompassing layer with a header
file). This would also let teams set policies of how much instability risk
they were willing to take by having CI have an allowlist/blocklist of
Python header files.

-Brett


>
> Modifying preprocessor definitions for different Python versions, or
> having to set them before knowing what version is being used, seems more
> complicated.
>

> Cheers,
> Steve
>
> On 5/30/2022 8:26 PM, Brett Cannon wrote:
> > We discussed having leading underscores for this API tier, and it was
> decided that a leading underscore was preferred.
> >
> > This did start a discussion, though, about whether we should control API
> access/opt-in via `#include` by having `.h` files that convey what API the
> user is opting into, or use `#define` to control what gets exposed via
> `Python.h`. The general feeling was that the header file idea is ideal, but
> it is a little extra work to transition to if you want to be compatible
> with older versions of Python that wouldn't have the header files (Victor's
> compatibility project could help here). The question for the team is
> whether separate header files makes sense to others, or would people prefer
> using `#define` and `Python.h` to control API access/opt-in?
>
___
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/NOIKBK6MREMWLRLN76KZTHRABKKOHWUN/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 689 – Unstable C API tier (was: Semi-stable C API tier)

[Brett Cannon]

We discussed having leading underscores for this API tier, and it was decided 
that a leading underscore was preferred.

This did start a discussion, though, about whether we should control API 
access/opt-in via `#include` by having `.h` files that convey what API the user 
is opting into, or use `#define` to control what gets exposed via `Python.h`. 
The general feeling was that the header file idea is ideal, but it is a little 
extra work to transition to if you want to be compatible with older versions of 
Python that wouldn't have the header files (Victor's compatibility project 
could help here). The question for the team is whether separate header files 
makes sense to others, or would people prefer using `#define` and `Python.h` to 
control API access/opt-in?
___
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/Q5JU5YKGX2U2UAAILDH45S5UGN6GLVXT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Summary of Python tracker Issues

[Brett Cannon]

Can we shut this down or unsubscribe the weekly email?

On Fri, May 13, 2022 at 11:13 AM Python tracker 
wrote:

>
> ACTIVITY SUMMARY (2022-05-06 - 2022-05-13)
> 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:
>   open7146 ( +0)
>   closed 51841 ( +0)
>   total  58987 ( +0)
>
> Open issues with patches: 2890
>
>
> Most recent 15 issues with no replies (15)
> ==
>
> #47258: Python 3.10 hang at exit in drop_gil() (due to resource warnin
> https://bugs.python.org/issue47258
>
> #47256: re: limit the maximum capturing group to 1,073,741,823, reduce
> https://bugs.python.org/issue47256
>
> #47253: LOAD_GLOBAL instruction with wrong source position
> https://bugs.python.org/issue47253
>
> #47252: socket.makefile documentation is missing data regarding the 'b
> https://bugs.python.org/issue47252
>
> #47251: Merge BINARY_SUBSCR_LIST_INT with BINARY_SUBSCR_LIST_TUPLE
> https://bugs.python.org/issue47251
>
> #47244: email.utils.formataddr does not respect double spaces
> https://bugs.python.org/issue47244
>
> #47242: Annoying white bar in IDLE (line 457 in sidebar.py)
> https://bugs.python.org/issue47242
>
> #47241: [C API] Move the PyCodeObject structure to the internal C API
> https://bugs.python.org/issue47241
>
> #47238: Python threading.Event().wait() depends on the system time
> https://bugs.python.org/issue47238
>
> #47236: Document types.CodeType.replace() changes about co_exceptionta
> https://bugs.python.org/issue47236
>
> #47228: Document that na??ve datetime objects represent local time
> https://bugs.python.org/issue47228
>
> #47222: subprocess.Popen() should allow capturing output and sending i
> https://bugs.python.org/issue47222
>
> #47219: asyncio with two interpreter instances
> https://bugs.python.org/issue47219
>
> #47218: adding name to lzmafile
> https://bugs.python.org/issue47218
>
> #47217: adding name to BZ2File
> https://bugs.python.org/issue47217
>
>
>
> Most recent 15 issues waiting for review (15)
> =
>
> #47256: re: limit the maximum capturing group to 1,073,741,823, reduce
> https://bugs.python.org/issue47256
>
> #47255: Many broken :meth: roles in the docs
> https://bugs.python.org/issue47255
>
> #47254: enhanced dir?
> https://bugs.python.org/issue47254
>
> #47251: Merge BINARY_SUBSCR_LIST_INT with BINARY_SUBSCR_LIST_TUPLE
> https://bugs.python.org/issue47251
>
> #47243: Duplicate entry in 'Objects/unicodetype_db.h'
> https://bugs.python.org/issue47243
>
> #47233: show_caches option affects code positions reported by dis.get_
> https://bugs.python.org/issue47233
>
> #47222: subprocess.Popen() should allow capturing output and sending i
> https://bugs.python.org/issue47222
>
> #47218: adding name to lzmafile
> https://bugs.python.org/issue47218
>
> #47217: adding name to BZ2File
> https://bugs.python.org/issue47217
>
> #47216: adding mtime option to gzip open()
> https://bugs.python.org/issue47216
>
> #47215: Add "unstable" frame stack api
> https://bugs.python.org/issue47215
>
> #47208: Support libffi implementations that cannot support invocations
> https://bugs.python.org/issue47208
>
> #47205: posix.sched_{get|set}affinity(-1) no longer returns ProcessLoo
> https://bugs.python.org/issue47205
>
> #47200: Add ZipInfo.mode property
> https://bugs.python.org/issue47200
>
> #47199: multiprocessing: micro-optimize Connection.send_bytes() method
> https://bugs.python.org/issue47199
> ___
> 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/LEYLS2TYSZ4NVDFLTDSQUT25C2Y4QG2O/
> 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/C53WJXVWHZNGLTTPFQXHUWIZCYF2FBP7/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Migration plan for the distutils removal in Python 3.12

[Brett Cannon]

On Tue, May 10, 2022 at 10:23 AM Guido van Rossum  wrote:

> Shouldn't we wean our internal tools off this obsolete version of
> distutils too, rather than just move it around?
>

I think so. We technically have a year to get this done, so if we can't do
that then I'm afraid we have much bigger issues with the project's
maintenance.

-Brett


>
> On Tue, May 10, 2022 at 9:26 AM Steve Dower 
> wrote:
>
>> On 5/10/2022 4:33 PM, Christian Heimes wrote:
>> > On 10/05/2022 13.18, Victor Stinner wrote:
>> >> test_peg_generator and test_cppext build C extensions with distutils.
>> >> Until these tests are modified to use something else, we still need to
>> >> keep distutils. So I propose to rename it to _distutils to remove it
>> >> from the stdlib. Maybe these tests can use ensurepip to install
>> >> setuptools which provides distutils.
>> >>
>> >> There is also the c-analyzer tool which uses distutils to run a C
>> >> preprocessor.
>> >
>> > We can easily take care of test_cppext and add the build step to
>> > Makefile. How does test_peg_generator depend on distutils? I don't see
>> > an import of distutils in the directory.
>> >
>> > I would prefer to fix and remove all imports of distutils before we
>> > resort to renaming the package. Please give us time until alpha 1.
>> There
>> > is no need to rush it *now*.
>>
>> I agree. The internal tools that use it are all in our Tools directory,
>> so we can move distutils there and explicitly add an import path to
>> locate it. No need to keep it in the stdlib (Lib/) at all.
>>
>> Migrating to Makefile builds is probably better long-term, but not as
>> important as moving distutils out from the stdlib so that setuptools can
>> rely on their copy being the "main" one.
>>
>> 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/LGF4BJMN3H7L6QFTZTDBMOA2GPZQFHC6/
>> 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/L3JRME4CC5SXJJ2MSYSXBU6OBYLWVKKS/
> 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/45EXS6S7PMTNWYMVU6EWLFFIIYAM3WR4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Migration plan for the distutils removal in Python 3.12

[Brett Cannon]

On Tue, May 10, 2022 at 12:59 AM Victor Stinner  wrote:

> Hi,
>
> Two years ago, PEP 632 "Deprecate distutils module" was accepted: the
> distutils package was deprecated in Python 3.10 and scheduled for
> removal in Python 3.12. Questions.
>
> * Is the Python ecosystem ready for the distutils removal? How many
> projects are expected to be broken by this removal?
>
> * Is setuptools a drop-in replacement of distutils for most cases? Are
> there tools and documentation explaining how to replace distutils with
> setuptools?
>

Change `import distutils` with `import setuptools`.  But more thorough
guidance can be found at
https://setuptools.pypa.io/en/latest/deprecated/distutils-legacy.html?highlight=distutils
.


>
> * Is there a tool to migrate from setup.py (distutils) to
> pyproject.toml (setuptools)? The dephell project can convert a
> setup.py script to pyproject.toml using poetry as the build system.
>

You don't have to migrate a setuptools project to pyproject.toml to keep
functioning. I would strongly encourage people at least specify a
build-system table in pyproject.toml as it's easy to do, but pip doesn't
require even this for setuptools projects:

```toml

[build-system]requires = ["setuptools"]build-backend = "setuptools.build_meta"

```

But the rest of the project's metadata can stay in setup.py or setup.cfg if
they want. But there is experimental support to fully support PEP 621 and
specifying metadata in pyproject.toml:
https://setuptools.pypa.io/en/latest/userguide/pyproject_config.html .


>
> * Can we simply suggest installing setuptools to users who still use
> "import distutils"? setuptools now provides the a "distutils" package.
>

If they are unwilling to update, yes.


>
> * Should we keep distutils in Python stdlib a few more Python releases
> if the removal causes too many practical issues?
>

I don't think so.

-Brett


>
>
> A code search in top 5000 PyPI projects (at 2022-01-26) using the
> regex '(import|from) distutils' matchs 5,567 lines in 1,229 projects.
> Some statistics:
>
> * 851 projects (1,372 lines) import distutils in setup.py
> * 233 projects (700 lines) use distutils.version
> * 92 projects (205 lines) use distutils.util
> * 1,018 lines are type annotations (.pyi files)
>
> I failed to group the remaining 2,272 lines.
>
> Converting 851 projects from setup.py with distutils to pyproject.toml
> is going to take a few months if not years. Python 3.12 will likely be
> released in October 2023 (in year and a half).
>
>
> Since setuptools 60 (December 2021), setuptools installs a
> distutils-precedence.pth file to override the stdlib module with its
> local distutils copy by default. The SETUPTOOLS_USE_DISTUTILS=stdlib
> environment variable can be used to explicitly request the stdlib
> flavor. If I understood correct, distutils is now maintained in
> setuptools, rather than in the Python stdlib.
>
> Python "make install" installs an up to date setuptools and so
> indirectly its distutils-precedence.pth file which makes the distutils
> local copy of setuptools available. But many Linux distributions
> splits setuptools and pip from the "python" package.
>
>
> Right now, Python still uses distutils internally for multiple use
> cases. I propose to start with renaming the distutils package to
> _distutils in the stdlib:
>
> * https://github.com/python/cpython/issues/92584
> * https://github.com/python/cpython/pull/92585
>
> Right now, the change is blocked by pip which still imports distutils
> (even if it prefers sysconfig in practice on Python 3.10 and newer). I
> reported the issue to pip, it should be easy to fix.
>
> Once Python will no longer depend on _distutils, it will be possible
> to fully remove it.
>
>
> By the way, Fedora 35 now longer provides automatically setuptools
> when building a Python package. A dependency to setuptools must now be
> explicit, since they are projects which don't use setuptools nor
> distutils, but other build systems.
>
>
> https://fedoraproject.org/wiki/Changes/Reduce_dependencies_on_python3-setuptools
>
> 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/XFZJ43VSIWCYNQ5ZYT64XF7PMH4YDUWC/
> 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/7YOD2KW3JND5DDHOBS22XVCUYQWWTEP7/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Can I ask a real dumb procedural question about GitHub email?

[Brett Cannon]

On Wed, May 4, 2022 at 11:26 AM Skip Montanaro 
wrote:

> I subscribe to the python/cpython stuff on GitHub. I find it basically
> impossible to follow because of the volume. I realize there are
> probably plenty of extra changes going in based on the recent language
> summit (and maybe some sprints at PyCon?) as well as the proximity to
> the beta 1 freeze. Still, does anyone actually try to follow
> everything that comes out of that firehose? I've received updates to
> about 125 new GMail conversations (more total messages than that) in
> the last 24 hours, and that's after using filters to delete
> Miss-Islington-type messages altogether. As far as I can quickly
> ascertain, all the messages are from real people, not bots.
>
> How (if at all) do people deal with this firehose of email? Am I the
> only person dumb enough to have tried?


If no one replies, then you might be the only brave soul trying.  I
stopped years ago even under bpo.

-Brett


> I used to scan for
> csv-module-related messages, but don't even try to do that now. My
> only real reason for continuing to subscribe is that it feeds into a
> process that updates a dictionary of "common" words used by my
> XKCD-936-derived password generator.
>
> Thx,
>
> Skip
> ___
> 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/BCBQWW2ZLRU2GCSZJH6Q6YNAXMH3Q6FB/
> 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/BKPPZC6WE6LP5AHEZZVVUFESYOYAM6WZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Add -P command line option to not add sys.path[0]

[Brett Cannon]

On Tue, Apr 26, 2022 at 2:50 AM Victor Stinner  wrote:

> Hi,
>
> There are 4 main ways to run Python:
>
> (1) python -m module [...]
> (2) python script.py [...]
> (3) python -c code [...]
> (4) python [...]
>
> (1) and (2) insert the directory of the module/script at sys.path[0].
> (3) and (4) insert an empty string at sys.path[0].
>
> This behavior is convenient and is maybe part of Python usability
> success: importing a module in the current directory is as easy as
> "import other_module" (load other_module.py). But it's also a threat
> to security: an attacker can override a stdlib module by creating a
> Python script with the same name than a stdlib module, like os.py or
> shutil.py.
>
> People learning Python commonly create a file with the same name than
> a stdlib module (ex: random.py) and then are clueless in face of an
> ImportError exception.
>
> Changing the default behavior was discussed multiple times. No
> consensus was reached, maybe because most users like the current
> default behavior and are not affected by corner cases (see below).
>
> I propose adding a -P option to Python command line interface to "not
> add sys.path[0]":
> https://github.com/python/cpython/pull/31542


We would use this in the Python extension for VS Code for case (1) as we
have had issues with (1) when running tools on people's behalf. People will
accidentally shadow the stdlib and then do something unexpected as an
import side-effect in their shadowing module like delete files. Not
something you want happening when you're just wanting to run Pylint. 

-Brett


>
>
> See the documentation in the PR for the exact behavior of this option.
> I prefer to add an environment variable, only pass the option
> explicitly on the command line.
>
> Since Python 3.4, there is already the -I ("isolated mode") option:
> https://docs.python.org/dev/using/cmdline.html#cmdoption-I
>
> The -I option has other effects like disabling user site directories,
> it option doesn't fit use cases of the -P option.
>
> One annoying issue of the Python default behavior is that running a
> script in /usr/bin/ as root can create or override .pyc files in the
> /usr directory, even in the /usr/bin/ directory. Example of this
> surprising and annoying issue:
> https://github.com/benjaminp/six/issues/359#issuecomment-996159668
>
> The -P option can be used in #!/usr/bin/python shebang to avoid this issue.
>
> --
>
> An alternative would be to change the default behavior to not add
> sys.path[0], and add an option to opt-in for Python 3.10 behavior.
> Here are my notes about it:
> https://github.com/vstinner/misc/blob/main/cpython/pep_path0.rst
>
> What do you think?
>
> 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/IU5Q2AXAURFVDPRWNU3BDFVKV2QX5NOR/
> 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/2DCKKOJNB4T3ZKXQAEFTC6ZCMXPONFPG/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Proposal to deprecate mailcap

[Brett Cannon]

After talking about this in the SC today, we agreed to deprecate mailcap
under the auspices of PEP 594:
https://github.com/python/peps/commit/701999a91dc5f976c00d5bde1510226ebd9c7822
.

On Thu, Apr 14, 2022 at 11:44 AM Brett Cannon  wrote:

> A CVE has been opened against mailcap (see
> https://github.com/python/cpython/issues/68966 for details). I'm not
> aware of anyone trying to maintain the module and Victor did a search
> online and didn't find any use of the module in the top 5000 projects on
> PyPI (see the issue). The module is also under 300 lines of Python code
> that only  (https://github.com/python/cpython/blob/main/Lib/mailcap.py),
> so vendoring wouldn't be burdensome.
>
> As such, I'm proposing we deprecate mailcap in 3.11 and remove it in 3.13.
> Any explicit objections?
>
___
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/I32FOGSHZWPQYFWHXVR7BGQ3IHRD7VJY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Proto-PEP part 1: Forward declaration of classes

[Brett Cannon]

On Sat, Apr 23, 2022 at 2:39 PM Rob Cliffe via Python-Dev <
python-dev@python.org> wrote:

> UGH!
>

I understand you don't like the proposal, but do please try to keep it
civil. It's totally okay to say you don't like something, but I don't think
anyone would take kindly to someone coming up to them in person and going,
"UGH!" in their face about an idea they had.

-Brett


>
> I thought there was a general understanding that when typing was added
> to Python, there would be no impact, or at least minimal impact, on
> people who didn't use it.  (Raises hand.)
> Now we see an(other) instance of intention creep.
> Rob Cliffe
>
> On 23/04/2022 02:13, Larry Hastings wrote:
> >
> >
> > This document is a loose proto-PEP for a new "forward class" /
> > "continue class" syntax.  Keep in mind, the formatting is a mess. If I
> > wind up submitting it as a real PEP I'll be sure to clean it up first.
> >
> >
> > /arry
> >
> > --
> >
> >
> > PEP : Forward declaration of classes
> >
> > Overview
> > 
> >
> > Python currently has one statement to define a class, the `class`
> > statement:
> >
> > ```Python
> > class X():
> > # class body goes here
> > def __init__(self, key):
> > self.key = key
> > ```
> >
> > This single statement declares the class, including its bases and
> > metaclass,
> > and also defines the contents of the class in the "class body".
> >
> > This PEP proposes an additional syntax for declaring a class which splits
> > this work across two statements:
> > * The first statement is `forward class`, which declares the class and
> > binds
> >   the class object.
> > * The second statement is `continue class`, which defines the contents
> >   of the class in the "class body".
> >
> > To be clear: `forward class` creates the official, actual class object.
> > Code that wants to take a reference to the class object may take
> > references
> > to the `forward class` declared class, and interact with it as normal.
> > However, a class created by `forward class` can't be *instantiated*
> > until after the matching `continue class` statement finishes.
> >
> > Defining class `X` from the previous example using this new syntax
> > would read
> > as follows:
> >
> > ```
> > forward class X()
> >
> > continue class X:
> > # class body goes here
> > def __init__(self, key):
> > self.key = key
> > ```
> >
> > This PEP does not propose altering or removing the traditional `class`
> > statement;
> > it would continue to work as before.
> >
> >
> > Rationale
> > -
> >
> > Python programmers have had a minor problem with classes for years:
> > there's
> > no way to have early-bound circular dependencies between objects. If A
> > depends on B, and B depends on A, there's no linear order that allows
> > you to cleanly declare both.
> >
> > Most of the time, the dependencies were in late-binding code, e.g. A
> > refers
> > to B inside a method.  So this was rarely an actual problem at
> > runtime.  When
> > this problem did arise, in code run at definition-time, it was usually
> > only
> > a minor headache and could be easily worked around.
> >
> > But the explosion of static type analysis in Python, particularly with
> > the `typing` module and the `mypy` tool, has made circular
> > definition-time
> > dependencies between classes commonplace--and much harder to solve.
> > Here's
> > one simple example:
> >
> > ```Python
> > class A:
> > value: B
> >
> > class B:
> > value: A
> > ```
> >
> > An attribute of `B` is defined using a type annotation of `A`, and an
> > attribute of `A` is defined using a type annotation of `B`. There's
> > no order to these two definitions that works; either `A` isn't defined
> > yet, or `B` isn't defined yet.
> >
> > Various workarounds and solutions have been proposed to solve this
> > problem,
> > including two PEPs: PEP 563 (automatic stringized annotations) and PEP
> > 649
> > (delayed evaluation of annotations using functions).
> > But nothing so far has been both satisfying and complete; either it
> > is wordy and clumsy to use (manually stringizing annotations), or it
> > added restrictions and caused massive code breakage for runtime use of
> > annotations (PEP 563), or simply didn't solve every problem (PEP 649).
> > This proposed  `forward class` / `continue class` syntax should permit
> > solving *every* forward-reference and circular-reference problem faced
> > in Python, using an elegant and Pythonic new syntax.
> >
> > As a side benefit, `forward class` and `continue class` syntax enables
> > rudimentary separation of "interface" from "implementation", at least for
> > classes.  A user seeking to "hide" the implementation details of their
> > code could put their class definitions in one module, and the
> > implementations of those classes in a different module.
> >
> > This new syntax is not intended to replace the traditional 

[Python-Dev] Re: Python multithreading without the GIL

[Brett Cannon]

On Sat, Apr 23, 2022 at 8:31 AM  wrote:

> Hello all,
>
> I am very excited about a future multithreaded Python. I managed to
> postpone some rewrites in the company I work for Rust/Go, precisely because
> of the potential to have a Python solution in the medium term.
>
> I was wondering. Is Sam Gross' nogil merge being seriously considered by
> the core Python team?
>

Yes, although we have no timeline as to when we will make a decision about
whether we will accept it or not. The last update we had on the work was
Sam was upstreaming the performance improvements he made that were not
nogil-specific. The nogil work was also being updated for the `main`
branch. Once that's all done we will probably start a serious discussion as
to whether we want to accept it.
___
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/KCATAW2AXWFBGYCVN3IQPIKU2QN2GAA3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: GSOC

[Brett Cannon]

On Tue, Apr 19, 2022 at 7:14 AM Jean Abou Samra  wrote:

> Hi,
>
> Le 19/04/2022 à 01:56, faresbaso...@gmail.com a écrit :
> > i want to contribute in mailman which is a sub-org under python software
>
>
> Where do you see this? I can't find it under github.com/python.
> The repository seems to be living here:
>
> https://gitlab.com/mailman/mailman


GSoC has historically organized Python-based projects too small to have
their own org under the Python Software Foundation (
https://summerofcode.withgoogle.com/programs/2022/organizations/python-software-foundation),
so it has nothing to do with where a repo lives. You can see Mailman listed
at https://python-gsoc.org/ideas.html .

-Brett


>
>
> Wait, actually, I see a merge request from you there. Did
> you find it in the meantime?
>
>
> > in  GSOC
> > there's 2 templates to submit i want to know which template is the
> correct one,
> > the one in mailman's site or the one in python's site
>
>
>
> Whatever infrastructure Mailman may share with Python, it is an
> entirely separate project, so this will almost certainly be
> the template from the Mailman project.
>
> Best,
> Jean
>
> ___
> 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/AREDYQMSWMDLQK77LIYUHWDVHLER6WOG/
> 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/QF6V2MT7A42ASXHZ2L6RPT4LCXA2Y4AK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Proposal to deprecate mailcap

[Brett Cannon]

A CVE has been opened against mailcap (see
https://github.com/python/cpython/issues/68966 for details). I'm not aware
of anyone trying to maintain the module and Victor did a search online and
didn't find any use of the module in the top 5000 projects on PyPI (see the
issue). The module is also under 300 lines of Python code that only  (
https://github.com/python/cpython/blob/main/Lib/mailcap.py), so vendoring
wouldn't be burdensome.

As such, I'm proposing we deprecate mailcap in 3.11 and remove it in 3.13.
Any explicit objections?
___
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/EB2BS4DBWSTBIOPQL5QTBSIOBORWSCMJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Declarative imports

[Brett Cannon]

On Sun, Apr 10, 2022 at 2:39 AM Daniel Pope  wrote:

> On Fri, 8 Apr 2022, 17:44 Guido van Rossum,  wrote:
>
>> The interesting idea here seems to make "lazy imports" easier to
>> implement by making them explicit in the code. So far, most lazy import
>> frameworks for Python have done hacks with `__getattribute__` overrides.
>>
>
> The value is more than ease of implementation. Having syntax for import
> expressions makes them statically analysable, which is needed for type
> checkers and IDE autocompletion.
>
> But I also see value in being able to type out code that uses modules not
> yet imported without breaking my flow to add an import statement. I don't
> yet trust IDEs to do this because I've been bitten by them doing so
> incorrectly in the past.
>
> The key questions to me are
>> - What should the notation be?
>>
>
> I would like to bid again for (import package.module) as an expression.
> Instead of doing the import and assigning package to a variable package it
> would evaluate to the module object package.module.
>

That is an extremely subtle shift for what `import x.y` does compared to
`(import x.y)`. That requires a context switch of not only seeing `import`
in an expression context, but that the statement also acts differently in
terms of what is returned by the equivalent statement. I really don't to
try and teach that distinction to a newcomer. And I don't think the
ergonomics are great enough to warrant the context switch.

Plus you can do this today with imortlib.import_module(). Unless you're
suggesting the name also be bound in the scope it's run in? In which case
that's `(abc := importlib.import_module("collections.abc")).Mapping`.

-Brett


>
> The `as` form is not needed because no name is assigned and the `from`
> form isn't as valuable because you can just use attribute access afterwards.
>
> It isn't terse but it does make use of the import keyword and is thus
> instantly recognisable. It is even syntax highlighted correctly by much
> existing software. If we're using the import keyword then I think it has to
> look like this.
>
> But I concede that it isn't particularly elegant to type hint things with
>
> (import collections.abc).Mapping
>
> ...but not so inelegant that I couldn't see myself using it for a few
> one-off imports per module.
>
> A quirk is that it means there's a big difference between the statements
>
> import foo
>
> and
>
> (import foo)
>
> because one assigns a variable. I don't mind that; I don't think it is too
> ambiguous to a reader.
>
>
>
> ___
> 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/T6V7WZAFEXGWMHXLHS7XHYXI5OPMOZKA/
> 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/5HMNON4YODBJNHSSAYT4B7CRZJUKFGW4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Importing a submodule doesn't always set an attribute on its parent

[Brett Cannon]

On Sat, Apr 9, 2022 at 1:53 PM dfremont--- via Python-Dev <
python-dev@python.org> wrote:

> Thanks, Brett. I understand why the behavior happens, I just don't
> understand the decision to implement imports this way. Since there's no
> warning in the documentation that removing items from sys.modules can break
> the fact that "import X.Y" defines "X.Y" (note that the "behind the
> curtain" stuff happens *before* the second import, so it's still the case
> that the second import does not define "X.Y" as implied by the docs), and
> there's also no warning that submodules must be removed at the same time as
> their parent, I would expect my example code to work.
>
> I don't see any downside to having "import X.Y" always set the Y attribute
> of X (instead of only setting it if 'X.Y' is not already in sys.modules),
> but if you think it's a bad idea, here's a suggestion for a paragraph to
> add at the end of PLR 5.4.2:
>
> "Note that the binding to the submodule object in the parent module's
> namespace is only added when the submodule is actually *loaded*. If the
> submodule is already present in `sys.modules` when it is imported (through
> any of the mechanisms above), then it will not be loaded again and no
> binding will be added to the parent module."
>

I don't want the import docs to be that detailed. As others have suggested,
something more about "directly mutating the contents of `sys.modules` may
have unexpected side-effects" is better.


>
> If removing a module but not its submodules from sys.modules is considered
> "cheating" and could potentially break other parts of the import system,
> that should also be documented, e.g. by adding the sentence "If you delete
> a key for a module in `sys.modules`, you must also delete the keys for all
> submodules of that module." at the end of the 3rd paragraph of PLR 5.3.1.
> However, I would much rather not impose this restriction, since it seems
> unnecessarily restrictive (indeed, my code violates it but works fine, and
> changing it to transitively remove all submodules would necessitate
> reloading many modules which do not actually need to be reloaded).
>
> (Terry, thanks for your suggestion. My concern about adding such a vague
> warning is that to me, it reads as saying that all bets are off if you
> modify sys.modules by hand, which means it would never be safe to do so,
> i.e., the behavior might change arbitrarily in a future Python version.


That's correct, and that's the reason Terry suggested that wording. If we
were to do the import system over again, sys.modules would either be hidden
from direct access, be attached to the code implementing the importer, or
have a leading underscore. So we don't want to strengthen the definition at
all; best we are comfortable with is put up a warning that you don't want
to do stuff with sys.modules unless you know what you're doing.


> But in my opinion there are legitimate cases where it is necessary to
> ensure a module will be reloaded the next time it is imported, and the
> documented way to do that is to remove entries from sys.modules.)
>

The Python import system is simply not designed around the idea of undoing
an import (the fact that imports have side-effects guarantee it will never
be 100% successful). Plus even using something like importlib.reload()
won't necessarily get you what you want since any object stored as an
attribute somewhere will not get updated.
___
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/MLQT5UTTRDNXP5PTTIAAJME6JBAWASBR/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Importing a submodule doesn't always set an attribute on its parent

[Brett Cannon]

On Fri, Apr 8, 2022 at 4:38 PM dfremont--- via Python-Dev <
python-dev@python.org> wrote:

> Hello,
>
> I came across what seems like either a bug in the import system or a gap
> in its documentation, so I'd like to run it by folks here to see if I
> should submit a bug report. If there's somewhere else more appropriate to
> discuss this, please let me know.
>
> If you import A.B, then remove A from sys.modules and import A.B again,
> the newly-loaded version of A will not contain an attribute referring to B.
> Using "collections.abc" as an example submodule from the standard library:
>
> >>> import sys
> >>> import collections.abc
> >>> del sys.modules['collections']
> >>> import collections.abc
> >>> collections.abc
> Traceback (most recent call last):
>   File "", line 1, in 
> AttributeError: module 'collections' has no attribute 'abc'
>
> This behavior seems quite counter-intuitive to me: why should the fact
> that B is already loaded prevent adding a reference to it to A?


Because `"collections.abc" in sys.modules` is true. The import system
expects that if you already imported a module then everything that needed
to happen, happened. Basically you cheated by not doing a thorough cleaning
of sys.modules by not deleting all the submodules as well.


> It also goes against the general principle that "import FOO" makes the
> expression "FOO" well-defined;


You're dealing with the import system; you never got to have a well-defined
statement to begin with. 


> for example PLR 5.7 states that "'import XXX.YYY.ZZZ' should expose
> 'XXX.YYY.ZZZ' as a usable expression".


And it did. But then you went behind the curtain and moved stuff around.


> Finally, it violates the "invariant" stated in PLR 5.4.2 that if 'A' and
> 'A.B' both appear in sys.modules, then A.B must be defined and refer to
> sys.modules['A.B'].
>

That isn't an invariant that holds when you delete things outside of the
import system; that statement is what the import system *does*, not what
the import system guarantees to always be true.


>
> On the other hand, PLR 5.4.2 also states that "when a submodule is loaded
> using any mechanism... a binding is placed in the parent module's namespace
> to the submodule object", which is consistent with the behavior above,
> since the second import of A.B does not actually "load" B (only retrieve it
> from the sys.modules cache). So perhaps Python is working as intended here,
> and there is an unwritten assumption that if you unload a module from the
> cache, you must also unload all of its submodules. If so, I think this
> needs to be added to the documentation (which currently places no
> restrictions on how you can modify sys.modules, as far as I can tell).
>
> This may be an obscure corner case that is unlikely to come up in practice
> (I imagine few people need to modify sys.modules), but it did actually
> cause a bug in a project I work on, where it is necessary to uncache
> certain modules so that they can be reloaded. I was able to fix the bug
> some other way, but I think it would still be worthwhile to either make the
> import behavior more consistent (so that 'import A.B' always sets the B
> attribute of A) or add a warning in the documentation about this case. I'd
> appreciate any thoughts on this!
>

Feel free to propose some language to update the docs, but changing this
behaviour very well may have unintended consequences, so I would rather not
try to change it.
___
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/U5DDT4DUJ7U3VO62VZ333SWIN7QFZPHJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: About PEPs being discussed on Discourse

[Brett Cannon]

On Thu, Apr 7, 2022 at 7:33 PM Stephen J. Turnbull <
stephenjturnb...@gmail.com> wrote:

> Gregory P. Smith writes:
>
>  > We feel it too. We've been finding Discourse more useful from a
> community
>  > moderation and thread management point of view as well as offering
> markdown
>  > text and code rendering. Ideal for PEP discussions.
>
> The specific mention of "community moderation" and "thread management"
> makes me suspect that part of that effect is due to increased cost of
> participation for casual observers.


As one of the discuss.python.org admins and a former ML admin (sans
python-committers), I can tell that "increased cost of participation for
casual observers" is not at all the motivation behind Greg's comment (you
can look at the user of the Users category to see that the barrier of entry
isn't there). Discourse it just flat-out easier to admin: individuals can
flag posts, automatic spam detection, site-wide admins instead of per-list,
ability to split topics, ability to lock topics, ability to "slow down"
topics, time-limited suspensions, etc. I quit being an admin for any ML
beyond python-committers because I found it too frustrating to deal w/ when
compared to the tools I have on discuss.python.org.


Suggestion for PEP monitoring:
>
> AIUI the PEP process at a high level view is fairly well monitored by
> a certain set of GitHub commits: the proto-PEP "PEP-" commit, the
> commit that assigns it a PEP number, and commits that change status.
> How about a GitHub bot that does nothing but post PEP commit logs to a
> dedicated Discourse channel?  It should be possible to remove typo
> fixes and the like by posting any that change title, number, or
> status, and from the rest exclude any commits that change less than a
> dozen lines or something like that.  Or perhaps PEP committers could
> be asked to include some kind of tag like "#trivial" to distinguish
> them.
>

It's a possibility if someone wants to put the work in.
___
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/LS5XDBPIRHGBQ6Q2255366BBPQ2HYSEV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Are "Batteries Included" still a Good Thing? [was: It's now time to deprecate the stdlib urllib module]

[Brett Cannon]

On Wed, Mar 30, 2022 at 4:53 AM Barney Gale  wrote:

> On Wed, 30 Mar 2022 at 12:20, Antoine Pitrou  wrote:
>
>> On Wed, 30 Mar 2022 12:03:58 +0100
>> Steve Dower  wrote:
>> > On 30Mar2022 1124, Barney Gale wrote:
>> > > I'd like to become a maintainer for the pathlib module, if possible.
>> I
>> > > know the code and tests inside-out, and I've been wrestling the
>> > > internals for past few Python releases. I check the bugs/PRs at least
>> > > every week and help wherever I can.
>> >
>> > Antoine is still active, so if he's fine with that, I'm also
>> supportive.
>> > You're certainly familiar enough with that module.
>>
>> I'm entirely supportive. Huge thank you for working on pathlib!
>>
>
> Thank you Antoine, Steve. It's humbling to stand on your shoulders and
> thrilling to give back to Python. If I'm successful in my application I'll
> do my best to take good care of pathlib and hopefully urllib too.
>

The first step is to get triage permissions:
https://devguide.python.org/triaging/?highlight=triage#python-triage-team .
We can't add anyone to the CODEOWNERS file unless you have write
permissions, which means becoming a core dev. I have added myself to
CODEOWNERS for pathlib and I will try to remember to @ mention you on
things, Barney (https://github.com/python/cpython/pull/32202).

Antoine, I left you out of my PR for CODEOWNERS just because I thought it
was presumptuous to add anyone to more GitHub notifications without their
permission.


>
> These batteries ain't dead yet! :D
>

Definitely not all of them. 

-Brett


>
> Best,
>
> Barney
> ___
> 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/RWVLBPUYNCLCJUYKFR2GWU3V5IT55UCG/
> 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/NR2WVMXF64G7KK6IBGBGYNTKX2AEZUMK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Are "Batteries Included" still a Good Thing? [was: It's now time to deprecate the stdlib urllib module]

[Brett Cannon]

On Tue, Mar 29, 2022 at 8:58 AM Ronald Oussoren 
wrote:

>
>
> On 29 Mar 2022, at 00:34, Brett Cannon  wrote:
>
>
>
> On Mon, Mar 28, 2022 at 11:52 AM Christopher Barker 
> wrote:
>
>> On Mon, Mar 28, 2022 at 11:29 AM Paul Moore  wrote:
>>
>>> To be honest, I feel like I'm just reiterating stuff I've said before
>>> here, and I think the same is true of the points I'm responding to
>>
>>  ...
>>
>>>  (I'm not *against* going over the debate again,
>>> it helps make sure people haven't changed their minds, but it's
>>> important to be clear that none of the practical facts have changed,
>>> if that is the case).
>>>
>>
>> Maybe there's a way to make this discussion (it feels more like a
>> discussion than debate at the moment) more productive by writing some
>> things down. I'm not sure it's a PEP, but some kind of:
>>
>> "policy for the stdlib" document in which we could capture the primary
>> points of view, places where there's consensus, etc. would be helpful to
>> keep us retreading this over and over again.
>>
>> I suggest this without the bandwidth to actually shepherd the project,
>> but if someone wants to, I think it would be a great idea.
>>
>
> Once
> https://mail.python.org/archives/list/python-committ...@python.org/thread/5EUZLT5PNA4HT42NGB5WVN5YWW5ASTT5/
>  is considered resolved, the next part of my "what *is* the stdlib" plan
> is to finally try to suss all of this out and more-or-less write a stdlib
> policy PEP so we stop talking about this. My guess it will be more of
> guidance about what we want the stdlib to be and thus guide what things
> belong in it. No ETA on that work since I also have four other big Python
> projects on the go right now whose work I am constantly alternating between.
>
>
> Having such a policy is a good thing and helps in evolving the stdlib, but
> I wonder if the lack of such a document is the real problem.   IMHO the
> main problem is that the CPython team is very small and therefore has
> little bandwidth for maintaining, let alone evolving, large parts of the
> stdlib.  In that it doesn’t help that some parts of the stdlib have APIs
> that make it hard to make modifications (such as distutils where
> effectively everything is part of the public API).  Shrinking the stdlib
> helps in the maintenance burden, but feels as a partial solution.
>

You're right that is the fundamental problem. But for me this somewhat
stems from the fact that we don't have a shared understanding of what the
stdlib *is*,  and so the stdlib is a bit unbounded in its size and scope.
That leads to a stdlib which is hard to maintain. It's just like dealing
with any scarce resource: you try to cut back on your overall use as best
as you can and then become more efficient with what you must still consume;
I personally think we don't have an answer to the "must consume" part of
that sentence that leads us to "cut back" to a size we can actually keep
maintained so we don't have 1.6K open PRs
<https://github.com/python/cpython/pulls>.


> That said, I have no ideas on how a better stdlib development  proces
> would look like, let alone on how to get there.
>

I did what I could when I helped get us over to GitHub and what Mariatta
helped bring to our workflow.


>
> Ronald
>
>
> -Brett
>
>
>>
>> -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/GAZAFRFVJVQZMEIHTQUJASP7VRAKA5RR/
>> 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/PC67DOLDEQXIAGXEB2QXCGS3C4B6PTCY/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
>
> —
>
> 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/TCS3VOPVYI254GSC3OXGVB6ISUSMN7W7/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Enhancing generic type documentation in the standard library

[Brett Cannon]

On Mon, Mar 28, 2022 at 3:58 PM Luciano Ramalho  wrote:

> On Wed, Mar 23, 2022 at 5:01 PM Brett Cannon  wrote:
> > The SC somewhat agrees!  See
> https://mail.python.org/archives/list/typing-...@python.org/thread/TVMQJXOJFOYFPDMQDFG6G4B6J3MLRYKB/
> where we have asked for at least the specs to get consolidated into proper
> documentation instead of spread out across various PEPs.
>
> That makes me somewhat happy.
>
> Just kidding. I totally agree that the typing PEPs need to be
> consolidated into specs, which then need to be kept up-to-date.
>
> The issue I raised is related but different: we now have dozens of
> generic types in the standard library that are not fully documented in
> PEPs or hardly anywhere else.
>
> For example, PEP 585–Type Hinting Generics In Standard Collections
> merely lists the types which, back then, were changed to accept type
> parameters within [ ]. That PEP does not document the number, meaning,
> or variance of the accepted type parameters.
>
> When Guido and I refactored the `typing` module docs for Python 3.9,
> we marked dozens of types as deprecated. The entries for those
> deprecated types, such as `typing.Generator`, are the only places
> where the parameters accepted by the generic type are
> documented—albeit in a way that's not user-friendly:
>
> class typing.Generator(Iterator[T_co], Generic[T_co, T_contra, V_co])
>
> > My personal hope is this will also lead to better docs overall in a
> central location instead of spread out among modules, tools, etc.
>
> We share that hope and I am willing to help.
>
> Documenting the generic types in the standard library is a much
> smaller task than turning the typing PEPs into specs. It seems like a
> good next step on the way to better typing docs.
>

Since the typing-sig will likely be doing the work and driving such an
effort I would ask over there. I personally would love for a
typing.python.org or equivalent subsection of docs.python.org to exist.

-Brett


>
> Cheers,
>
> Luciano
>
>
>
> >
> > -Brett
> >
> >>
> >>
> >> We now have lots of generic types in the standard library, but their
> >> formal type parameters are poorly documented—or not documented at
> >> all—in the standard library documentation.
> >>
> >> More importantly: the documentation we have about specific
> >> covariant/contravariant types is now in entries in the `typing` module
> >> that are all deprecated since PEP 585 was implemented in Python 3.9.
> >>
> >> Below I present two of many examples where the documentation of a
> >> generic type is not great.
> >>
> >> However, if people agree this is a problem, we need to discuss where
> >> and how to put the documentation in a way that is not too disruptive
> >> to users of Python who don't know or don't care about type hints, for
> >> many reasons that we should not judge.
> >>
> >> For example, where do we document the fact that `dict` accepts two
> >> invariant formal type parameters, and that `frozenset` accepts one
> >> contravariant type parameter?
> >>
> >> What do you think?
> >>
> >> Cheers,
> >>
> >> Luciano
> >>
> >> _
> >> EXAMPLE 1: `Callable` variance is not documented
> >>
> >> For example, in the `Callable` type, the `ReturnType` parameter is
> >> covariant, and the `ParameterType` parameters are all contravariant.
> >>
> >> But there is no mention of variance in this entry:
> >>
> https://docs.python.org/3/library/typing.html?highlight=typing#typing.Callable
> >>
> >> Also, no mention of the fact that `collections.abc.Callable` is generic
> here:
> >>
> https://docs.python.org/3/library/collections.abc.html#collections.abc.Callable
> >>
> >> PEP 483—The Theory of Type Hints—is the only official Python doc where
> >> I found the information about the variance of the formal type
> >> parameters of `Callable`. The explanation there is brilliant [0].
> >>
> >> [0] https://peps.python.org/pep-0483/#covariance-and-contravariance
> >>
> >> Regardless, the intended audience of PEPs is "core developers"—which
> >> is neither a superset nor a subset of "Python devs now using type
> >> hints". We should not rely on PEPs to document features for Python
> >> users in general.
> >>
> >> _
> >> EXAMPLE 2: `Generator` variance could be better documented
> >>

[Python-Dev] Re: Are "Batteries Included" still a Good Thing? [was: It's now time to deprecate the stdlib urllib module]

[Brett Cannon]

On Mon, Mar 28, 2022 at 11:52 AM Christopher Barker 
wrote:

> On Mon, Mar 28, 2022 at 11:29 AM Paul Moore  wrote:
>
>> To be honest, I feel like I'm just reiterating stuff I've said before
>> here, and I think the same is true of the points I'm responding to
>
>  ...
>
>>  (I'm not *against* going over the debate again,
>> it helps make sure people haven't changed their minds, but it's
>> important to be clear that none of the practical facts have changed,
>> if that is the case).
>>
>
> Maybe there's a way to make this discussion (it feels more like a
> discussion than debate at the moment) more productive by writing some
> things down. I'm not sure it's a PEP, but some kind of:
>
> "policy for the stdlib" document in which we could capture the primary
> points of view, places where there's consensus, etc. would be helpful to
> keep us retreading this over and over again.
>
> I suggest this without the bandwidth to actually shepherd the project, but
> if someone wants to, I think it would be a great idea.
>

Once
https://mail.python.org/archives/list/python-committ...@python.org/thread/5EUZLT5PNA4HT42NGB5WVN5YWW5ASTT5/
is considered resolved, the next part of my "what *is* the stdlib" plan is
to finally try to suss all of this out and more-or-less write a stdlib
policy PEP so we stop talking about this. My guess it will be more of
guidance about what we want the stdlib to be and thus guide what things
belong in it. No ETA on that work since I also have four other big Python
projects on the go right now whose work I am constantly alternating between.

-Brett


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

[Python-Dev] Re: Enhancing generic type documentation in the standard library

[Brett Cannon]

On Wed, Mar 23, 2022 at 11:03 AM Luciano Ramalho 
wrote:

> Hello, everyone!
>
> I believe our documentation about types needs another overhaul.
>

The SC somewhat agrees!  See
https://mail.python.org/archives/list/typing-...@python.org/thread/TVMQJXOJFOYFPDMQDFG6G4B6J3MLRYKB/
where we have asked for at least the specs to get consolidated into proper
documentation instead of spread out across various PEPs. My personal hope
is this will also lead to better docs overall in a central location instead
of spread out among modules, tools, etc.

-Brett


>
> We now have lots of generic types in the standard library, but their
> formal type parameters are poorly documented—or not documented at
> all—in the standard library documentation.
>
> More importantly: the documentation we have about specific
> covariant/contravariant types is now in entries in the `typing` module
> that are all deprecated since PEP 585 was implemented in Python 3.9.
>
> Below I present two of many examples where the documentation of a
> generic type is not great.
>
> However, if people agree this is a problem, we need to discuss where
> and how to put the documentation in a way that is not too disruptive
> to users of Python who don't know or don't care about type hints, for
> many reasons that we should not judge.
>
> For example, where do we document the fact that `dict` accepts two
> invariant formal type parameters, and that `frozenset` accepts one
> contravariant type parameter?
>
> What do you think?
>
> Cheers,
>
> Luciano
>
> _
> EXAMPLE 1: `Callable` variance is not documented
>
> For example, in the `Callable` type, the `ReturnType` parameter is
> covariant, and the `ParameterType` parameters are all contravariant.
>
> But there is no mention of variance in this entry:
>
> https://docs.python.org/3/library/typing.html?highlight=typing#typing.Callable
>
> Also, no mention of the fact that `collections.abc.Callable` is generic
> here:
>
> https://docs.python.org/3/library/collections.abc.html#collections.abc.Callable
>
> PEP 483—The Theory of Type Hints—is the only official Python doc where
> I found the information about the variance of the formal type
> parameters of `Callable`. The explanation there is brilliant [0].
>
> [0] https://peps.python.org/pep-0483/#covariance-and-contravariance
>
> Regardless, the intended audience of PEPs is "core developers"—which
> is neither a superset nor a subset of "Python devs now using type
> hints". We should not rely on PEPs to document features for Python
> users in general.
>
> _
> EXAMPLE 2: `Generator` variance could be better documented
>
> The entry for `typing.Generator` [1] has this heading:
>
> class typing.Generator(Iterator[T_co], Generic[T_co, T_contra, V_co])
>
> Answer quickly: how many formal type parameters does `Generator`
> require? Which are covariant? Which are contravariant?
>
> [1]
> https://docs.python.org/3/library/typing.html?highlight=typing#typing.Generator
>
> Nowhere in that page [1] there's an explanation of the `*_co` and
> `*_contra` naming convention, much less their semantics.
>
> Fortunately, the text of the `typing.Generator` entry says: "A
> generator can be annotated by the generic type `Generator[YieldType,
> SendType, ReturnType]".
>
> Unfortunately, `typing.Generator` is deprecated and will be gone in 5
> years or so...
>
> The same issue applies to all the other generic types: builtins
> (`dict`, `frozenset`), ABCs, etc.
> Their formal type parameters they accept as generics are either
> undocumented, or documented in parts of the `typing` module that are
> already deprecated.
>
> Thoughts?
>
> --
> Luciano Ramalho
> |  Author of Fluent Python (O'Reilly, 2015)
> | http://shop.oreilly.com/product/0636920032519.do
> |  Technical Principal at ThoughtWorks
> |  Twitter: @ramalhoorg
> ___
> 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/UGXWIADYG37N3ML4NBAKYF2C536HR273/
> 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/54IOPEZKV5YEGIBKWX5FUJ6RFC5W47YH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: C API: Move PEP 523 "Adding a frame evaluation API to CPython" private C API to the internal C API

[Brett Cannon]

On Wed, Mar 23, 2022 at 2:48 AM Petr Viktorin  wrote:

> On 22. 03. 22 19:07, Victor Stinner wrote:
> > Hi,
> >
> > I proposed two PRs to move the private C API (Include/cpython/) of PEP
> > 523 "Adding a frame evaluation API to CPython" to the internal C API
> > (Include/internals/):
> >
> > * https://github.com/python/cpython/pull/32052
> > * https://github.com/python/cpython/pull/32054
> >
> > API:
> >
> > * _PyFrameEvalFunction type
> > * _PyInterpreterState_GetEvalFrameFunc()
> > * _PyInterpreterState_SetEvalFrameFunc()
> > * (undocumented) _PyEval_EvalFrameDefault()
> >
> > The private API to get/set the eval function *is* documented at:
> >
> https://docs.python.org/dev/c-api/init.html#c._PyInterpreterState_GetEvalFrameFunc
> >
> > I added the Get/Set functions so debuggers don't have to access
> > directly to the PyInterpreterState structure which has been moved to
> > the internal C API in Python 3.8.
> >
> > This API causes me multiple issues:
> >
> > * It's a private API and I'm trying to remove the private API from the
> > public C API header files.
> > * The _PyFrameEvalFunction type is not stable: it got a new "tstate"
> > parameter in Python 3.9 and the type of the second parameter changed
> > from PyFrameObject* to _PyInterpreterFrame* in Python 3.11.
> > * These functions use the _PyInterpreterFrame type which is part of
> > the internal C API.
> >
> > While Pyston didn't bring a JIT compiler to Python with PEP 523,
> > debuggers were made faster by using this API. Debuggers like pydevd,
> > debugpy and ptvsd use it.
> >
> > I propose to move theses API to the internal header files
> > (Include/internals/) to clarify that it's not part of the public C API
> > and that there is no backward compatibility warranty.
> >
> > The change is being discussed at:
> > https://bugs.python.org/issue46850
> >
> > --
> >
> > PEP 523 API added more private functions for code objects:
> >
> > * _PyEval_RequestCodeExtraIndex()
> > * _PyCode_GetExtra()
> > * _PyCode_SetExtra()
> >
> > The _PyEval_RequestCodeExtraIndex() function seems to be used by the
> > pydevd debugger. The two others seem to be unused in the wild. I'm not
> > sure if these ones should be moved to the internal C API. They can be
> > left unchanged, since they don't use a type only defined by the
> > internal C API.
>
> PEP 523 clearly meant for these to be used by external tools, but made
> them private. That sounds like a contradiction.
>
> Brett/Dino, what was the intent here?
>

>From the PEP :
"The API is purposefully listed as private to communicate the fact that
there are no semantic guarantees of the API between Python releases."

-Brett


>
> IMO, if external code should use these, they should lose the leading
> underscore.
>
>
>
___
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/OI73PLAILLG75IKKZAADIH4GSOIXFWIQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Gathering edge cases around type annotation PEPs

[Brett Cannon]

I created
https://discuss.python.org/t/finding-edge-cases-for-peps-484-463-and-649-type-annotations/14314
on behalf of the SC to help gather edge cases where the various approaches
that PEPs have proposed will fail. Our hope is to get an overall picture of
the trade-offs the various PEPs ask us to make.

PLEASE DO NOT REPLY HERE! I'm reaching out to the typing SIG and Pydantic
(at least) and it's much easier for others to log into discuss.python.org
with a GitHub account than it is to sign up for this mailing list just to
participate in this discussion.
___
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/AKVBJHEQLKU5QSOHB6MYK2TOK5K4OCA4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Defining tiered platform support

[Brett Cannon]

On Mon, Mar 14, 2022 at 11:18 PM Larry Hastings  wrote:

>
> On 3/14/22 20:31, Brett Cannon wrote:
>
>
>
> On Fri, Mar 11, 2022 at 5:17 PM Victor Stinner 
> wrote:
>
>> It would be great to have the list of supported platforms per Python
>> version!
>>
>
> I could see the table in PEP 11 being copied into the release PEPs.
>
>
> By "release PEPs", you mean the release schedule PEPs, like PEP 619
> "Python 3.10 Release Schedule"?
>
> https://peps.python.org/pep-0619/
>
>
Yep!


>
> Because, yeah, I think that would be the best place for it.  Though then
> maybe the name of the PEP should change, as the document is doing double
> duty.
>

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

[Python-Dev] Re: Defining tiered platform support

[Brett Cannon]

On Fri, Mar 11, 2022 at 5:17 PM Victor Stinner  wrote:

> It would be great to have the list of supported platforms per Python
> version!
>

I could see the table in PEP 11 being copied into the release PEPs.


>
> Maybe supporting new platforms and dropping support for a platform
> should be document in What's New in Python x.y. GCC does that for
> example. It also *deprecates* support for some platforms. Example:
> https://gcc.gnu.org/gcc-9/changes.html
>
> --
>
> It's always hard for me to know what is the minimum supported Windows
> version. PEP 11 refers to Windows support:
> https://peps.python.org/pep-0011/#microsoft-windows
>
> But I don't know how to get this info from the Microsoft
> documentation. I usually dig into Wikipedia articles to check which
> Windows version is still supported or not, but I'm confused between
> "mainstream support" and "extended support".
>

It's "free with purchase" and "pay us more and we will keep supporting
you". You can think of it as standard versus extended warranties.

https://docs.microsoft.com/en-us/lifecycle/policies/fixed


>
> For example, which Python version still support Windows 7? Wikipedia
> says that Windows 7 mainstream support ended in 2015, and extended
> support ended in 2020. But Python still has a Windows 7 SP1 buildbot
> for Python 3.8: https://buildbot.python.org/all/#/builders/60


Just because we have a buildbot does not mean we support it. All it means
is someone in the community cares enough about Windows 7 to want to know
when CPython no longer works.


>
>
> What is the minimum Windows supported by Python 3.10?
>

I believe it's Windows 8.

https://docs.microsoft.com/en-us/lifecycle/faq/windows
https://docs.microsoft.com/en-us/lifecycle/products/windows-81

-Brett


>
> Victor
>
> On Mon, Mar 7, 2022 at 8:06 PM Christian Heimes 
> wrote:
> >
> > On 07/03/2022 18.02, Petr Viktorin wrote:
> > >> Why the devguide? I view the list of platforms as important for public
> > >> consumption as for the core dev team to know what to (not) accept PRs
> > >> for.
> > >
> > > So, let's put it in the main docs?
> > > Yes, I guess the devguide is a weird place to check for this kind of
> > > info. But a Python enhancement proposal is even weirder.
> >
> >
> > +1 for our main docs (cpython/Doc/)
> >
> > Platform support is Python versions specific. Python 3.10 may support
> > different version than 3.11 or 3.12. It makes sense to keep the support
> > information with the code.
> >
> > Christian
> > ___
> > 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/LJID7Y7RFSCRUYLJS3E56WBGJU2R44E4/
> > Code of Conduct: http://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/GCWULFTKFZNJFV7FWDMFBQVBMY5QBJJQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Defining tiered platform support

[Brett Cannon]

On Mon, Mar 7, 2022 at 11:05 AM Christian Heimes 
wrote:

> On 07/03/2022 18.02, Petr Viktorin wrote:
> >> Why the devguide? I view the list of platforms as important for public
> >> consumption as for the core dev team to know what to (not) accept PRs
> >> for.
> >
> > So, let's put it in the main docs?
> > Yes, I guess the devguide is a weird place to check for this kind of
> > info. But a Python enhancement proposal is even weirder.
>
>
> +1 for our main docs (cpython/Doc/)
>
> Platform support is Python versions specific. Python 3.10 may support
> different version than 3.11 or 3.12. It makes sense to keep the support
> information with the code.
>

Technically it's CPython version-specific. I also don't know where we would
list this in the docs. Looking at https://docs.python.org/3/ I wouldn't
know where to look for such information.
___
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/OYVN2XROV6DQ5IYBM5NT7EHSAJLDXFE5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Defining tiered platform support

[Brett Cannon]

On Mon, Mar 7, 2022 at 11:01 AM Christian Heimes 
wrote:

> On 04/03/2022 21.41, Brett Cannon wrote:
> > Therefore I propose that we target the oldest manylinux standard
> > accepted by PyPI, for which the operating system has not reached its
> > EOL. At the moment this is manylinux2014, aka CentOS 2024 with EOL
> June
> > 2024. We could also state that we aim for compatibility with oldest
> > Debian Stable and Ubuntu LTS with standard, free security updates.
> > As of
> > today Debian 10 Buster Ubuntu 18.04 Bionic are the oldest versions
> with
> > regular updates.
> >
> >
> > So does that mean you want to list the Linux distros explicitly? Or you
> > want to explicitly list the glibc version?
>
> I want to explicitly mention glibc and Linux distro for manylinux binary
> wheels standards that are supported by PyPI. For the rest we should be a
> bit more hand-wavy. Maybe we can point to our list of stable buildbots?
>

How about we list Linux support as based on the libc implementation and
version and point as various stable buildbots that cover that libc?


>
> >
> > We should say something about compilers. I wouldn't list compiler
> > versions, though. Compiler features like C99 support should be
> > sufficient.
> >
> >
> > Then what more would you want than what's listed in PEP 7 already?
>
> Nothing in particular other than a link to the PEP, so people can
> discover the requirement more easily.
>

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

[Python-Dev] Re: Defining tiered platform support

[Brett Cannon]

On Fri, Mar 4, 2022 at 1:44 AM Petr Viktorin  wrote:

> On 04. 03. 22 0:30, Brett Cannon wrote:
> > Do we officially support NetBSD? Do you know how to find out if we do?
> > You might think to look at
> > https://www.python.org/dev/peps/pep-0011/#supporting-platforms
> > <https://www.python.org/dev/peps/pep-0011/#supporting-platforms> , but
> > that just loosely defines the criteria and it still doesn't list the
> > actual platforms we support. (BTW I don't know if we do officially
> > support NetBSD, hence this email.)
> >
> > I think we should clarify this sort of thing and be a bit more upfront
> > with the level of support we expect/provide for a platform. As such, I
> > want to restructure PEP 11 to list the platforms we support, not just
> > list the platforms we stopped supporting. To do this I want define 3
> > different tiers that outline what our support requirements and promises
> > are for platforms.
>
> While you're at it: consider moving the lists to the devguide, so the
> PEP would only contain the general process & criteria.
>

Why the devguide? I view the list of platforms as important for public
consumption as for the core dev team to know what to (not) accept PRs for.


>
>
> > Tier 1 is the stuff we run CI against: latest Windows, latest macOS,
> > Linux w/ the latest glibc (I don't know of a better way to define Linux
> > support as I don't know if a per-distro list is the right abstraction).
> > These are platforms we won't even let code be committed for if they
> > would break; they block releases if they don't work. These platforms we
> > all implicitly promise to support.
> >
> > Tier 2 is the platforms we would revert a change within 24 hours if they
> > broke: latest FeeBSD, older Windows, older macOS, Linux w/ older
> > glibc.This is historically the "stable buildbot plus a core dev" group
> > of platforms. The change I would like to see is two core devs (in case
> > one is on vacation), and a policy as to how a platform ends up here
> > (e.g. SC must okay it based on consensus of everyone). The stable
> > buildbot would still be needed to know if a release is blocked as we
> > would hold a release up if they were red. The platform and the core devs
> > supporting these platforms would be listed in PEP 11.
>
> Do we need two core devs to revert changes?
>

No, but consider you are trying to land something before b1 and a tier 2
platform keeps failing. You have no idea why, but e.g. Victor is on
vacation and is unavailable to help. I personally wouldn't want to wait
until the next version of Python just because a platform we say we support
had its expert take an inconvenient vacation.


> What are the duties of someone listed for a platform, anyway?
>

I would expect they would be the reviewer of PRs for that platform. Also
domain expert to help out with questions as they arise if their platform
could potentially block a release or feature getting in.


>
> > Tier 3 are platforms we accept PRs for to keep working, but they won't
> > block a release. At least one core dev must be listed to be in charge of
> > PRs that affect the platform. A buildbot would be nice but not required.
> > I'm thinking either historical platforms we support or something like
> > Emscripten that's working towards being a tier 2 platform. I'm not sure
> > if we want to have explicit approval to be in this tier beyond the
> > outlined requirements, but obviously if a core dev isn't keeping up with
> > PRs then the platform will be dropped.
> >
> > All other platforms we do not directly support in the repository and it
> > is up to the community to keep functioning. We can obviously keep
> > accepting general patches to up compatibility, but platform-specific
> > patches for anything outside of these tiers wouldn't. No issue if
> > someone provides a buildbot for their own benefit, but these buildbots
> > would never hold anything up.
> >
> > When a Python version hits b1, then that platform is considered
> > supported for that version as long as the requirements outlined above
> > continue to be met. Once the Python version hits EOL then like anything,
> > support ends no matter what. We could capture the supported platforms
> > for a version in the release schedule PEP if people want >
> > I would expect appropriate labels being added to the builders listed at
> > https://buildbot.python.org/all/#/builders
> > <https://buildbot.python.org/all/#/builders> to signify which platforms
> > we block releases for (e.g. `tier-1,`, `tier-2`, or `release-blocker` as
> > a generic label).
> >
> > I would

[Python-Dev] Re: Defining tiered platform support

[Brett Cannon]

On Fri, Mar 4, 2022 at 1:32 AM Ronald Oussoren 
wrote:

>
>
> On 4 Mar 2022, at 00:30, Brett Cannon  wrote:
>
> Do we officially support NetBSD? Do you know how to find out if we do? You
> might think to look at
> https://www.python.org/dev/peps/pep-0011/#supporting-platforms , but that
> just loosely defines the criteria and it still doesn't list the actual
> platforms we support. (BTW I don't know if we do officially support NetBSD,
> hence this email.)
>
> I think we should clarify this sort of thing and be a bit more upfront
> with the level of support we expect/provide for a platform. As such, I want
> to restructure PEP 11 to list the platforms we support, not just list the
> platforms we stopped supporting. To do this I want define 3 different tiers
> that outline what our support requirements and promises are for platforms.
>
> Tier 1 is the stuff we run CI against: latest Windows, latest macOS, Linux
> w/ the latest glibc (I don't know of a better way to define Linux support
> as I don't know if a per-distro list is the right abstraction). These are
> platforms we won't even let code be committed for if they would break; they
> block releases if they don't work. These platforms we all implicitly
> promise to support.
>
> Tier 2 is the platforms we would revert a change within 24 hours if they
> broke: latest FeeBSD, older Windows, older macOS, Linux w/ older glibc.This
> is historically the "stable buildbot plus a core dev" group of platforms.
> The change I would like to see is two core devs (in case one is on
> vacation), and a policy as to how a platform ends up here (e.g. SC must
> okay it based on consensus of everyone). The stable buildbot would still be
> needed to know if a release is blocked as we would hold a release up if
> they were red. The platform and the core devs supporting these platforms
> would be listed in PEP 11.
>
>
> What’s the difference between Tier 1 and 2 other than that PRs are checked
> with tier 1 platforms before committing and with tier 2 afterwards?
>

Everyone on the core team supports tier 1, while for tier 2 there's only
those who specifically volunteer to support it.


>
> In particular, tier 1 contains windows server and not desktop (even though
> I expect that those are compatible as far as our use is concerned), and
> does not contain the macOS versions that we actually support in the
> installers on python.org (macOS 10.9 or later, both x86_64 and arm64).
> AFAIK support for macOS 10.9 in the python.org installers is now
> primarily, if not only, tested by Ned. That could, and probably should, be
> automated but that’s a significant amount of work.
>

So macOS 10.9 would be tier 3. There's nothing wrong with that, just we
obviously don't know when it fails now anyway, so it technically only holds
up a release so much as Ned as RM for macOS builds can choose to.


>
>
> […]
>
>
>
> I don't know if we want to bother listing CPU architectures since we are a
> pure C project which makes CPU architecture less of a thing, but I'm
> personally open to the idea of CPU architectures being a part of the
> platform definition.
>
>
> CTypes is hardware specific, although through libiff. There’s also
> intermittent discussions about support for ancient hardware platforms.
> Would we block a release when (for example) support for Linux on sparc32 is
> broken?
>

If it's tier 2 or higher, yes.

-Brett


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

[Python-Dev] Re: Defining tiered platform support

[Brett Cannon]

On Fri, Mar 4, 2022 at 12:48 AM Christian Heimes 
wrote:

> Hi Brett,
>
> thanks for starting the discussion! Much appreciated.
>
> On 04/03/2022 00.30, Brett Cannon wrote:
> > Tier 1 is the stuff we run CI against: latest Windows, latest macOS,
> > Linux w/ the latest glibc (I don't know of a better way to define Linux
> > support as I don't know if a per-distro list is the right abstraction).
> > These are platforms we won't even let code be committed for if they
> > would break; they block releases if they don't work. These platforms we
> > all implicitly promise to support.
>  >
> > Tier 2 is the platforms we would revert a change within 24 hours if they
> > broke: latest FeeBSD, older Windows, older macOS, Linux w/ older
> > glibc.This is historically the "stable buildbot plus a core dev" group
> > of platforms. The change I would like to see is two core devs (in case
> > one is on vacation), and a policy as to how a platform ends up here
> > (e.g. SC must okay it based on consensus of everyone). The stable
> > buildbot would still be needed to know if a release is blocked as we
> > would hold a release up if they were red. The platform and the core devs
> > supporting these platforms would be listed in PEP 11.
>
> I would like to see an explicit statement about glibc compatibility.
> glibc's API and ABI is very stable. We have autoconf feature checks for
> newer glibc features, so I'm not overly concerned with breaking
> compatibility with glibc. Anyhow we should also ensure that we are
> backwards compatible with older glibc releases that are commonly used in
> the community.
>
> Therefore I propose that we target the oldest manylinux standard
> accepted by PyPI, for which the operating system has not reached its
> EOL. At the moment this is manylinux2014, aka CentOS 2024 with EOL June
> 2024. We could also state that we aim for compatibility with oldest
> Debian Stable and Ubuntu LTS with standard, free security updates. As of
> today Debian 10 Buster Ubuntu 18.04 Bionic are the oldest versions with
> regular updates.
>

So does that mean you want to list the Linux distros explicitly? Or you
want to explicitly list the glibc version?


>
>
> Apropos libc, what is our plan concerning musl libc (Alpine)? It's a
> popular distro for containers. CPython's test suite is failing on latest
> Alpine (https://bugs.python.org/issue46390). Some of the problems seem
> to be caused by issues or missing features in musl libc. I like to see
> the problems fixed before we claim basic support for Alpine.
>
>
> > I would expect PEP 11 to list the appropriate C symbol that's set for
> > that platform, e.g. __linux__.
>
> For POSIX-like OS I would rather follow the example of Rust and use
> platform target triplet. The triplet encodes machine (CPU arch), vendor,
> and operating system. The OS part can encode libc. For example
> x86_64-*-linux-gnu for "x84_64 arch", "any vendor", and "Linux with GNU
> libc (glibc)". Commands like ./config.guess or gcc -dumpmachine return
> the current triplet.
>
> The target triplet is used by autoconf's ./configure script a lot.
>

That's fine by me if others agree.


>
>
> > I don't know if we want to bother listing CPU architectures since we are
> > a pure C project which makes CPU architecture less of a thing, but I'm
> > personally open to the idea of CPU architectures being a part of the
> > platform definition.
>
> I strongly recommend that we include machine architecture, too. We have
> some code that uses machine specific instructions or features, e.g.
> unaligned memory access. We cannot debug problems on CPU archs unless we
> have access to the hardware.
>

Based on other replies it sounds like that's what people want.


>
>
> > I don't think we should cover C compilers here as that's covered by PEP
> > 7. Otherwise PEP 7 should only list C versions/features and PEP 11 lists
> > compilers and their versions.
>
> We should say something about compilers. I wouldn't list compiler
> versions, though. Compiler features like C99 support should be sufficient.
>

Then what more would you want than what's listed in PEP 7 already?


>
> Do we target the platform's default compiler or are we targeting the
> latest compiler that is officially supported for the platform? CentOS 7
> comes with an old GCC, but has newer GCC versions in SCL (Developer
> Toolset 8). I'm asking because CentOS 7's default gcc does not support
> stdatomic.h. The official manylinux2014 OSCI container image ships GCC
> from devtoolset-8.
>

I think that depends on the person supporting the platform.
___
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/V2SLVKWYW3PSKPD3HI6QFJDSXD526TFR/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Defining tiered platform support

[Brett Cannon]

Do we officially support NetBSD? Do you know how to find out if we do? You
might think to look at
https://www.python.org/dev/peps/pep-0011/#supporting-platforms , but that
just loosely defines the criteria and it still doesn't list the actual
platforms we support. (BTW I don't know if we do officially support NetBSD,
hence this email.)

I think we should clarify this sort of thing and be a bit more upfront with
the level of support we expect/provide for a platform. As such, I want to
restructure PEP 11 to list the platforms we support, not just list the
platforms we stopped supporting. To do this I want define 3 different tiers
that outline what our support requirements and promises are for platforms.

Tier 1 is the stuff we run CI against: latest Windows, latest macOS, Linux
w/ the latest glibc (I don't know of a better way to define Linux support
as I don't know if a per-distro list is the right abstraction). These are
platforms we won't even let code be committed for if they would break; they
block releases if they don't work. These platforms we all implicitly
promise to support.

Tier 2 is the platforms we would revert a change within 24 hours if they
broke: latest FeeBSD, older Windows, older macOS, Linux w/ older glibc.This
is historically the "stable buildbot plus a core dev" group of platforms.
The change I would like to see is two core devs (in case one is on
vacation), and a policy as to how a platform ends up here (e.g. SC must
okay it based on consensus of everyone). The stable buildbot would still be
needed to know if a release is blocked as we would hold a release up if
they were red. The platform and the core devs supporting these platforms
would be listed in PEP 11.

Tier 3 are platforms we accept PRs for to keep working, but they won't
block a release. At least one core dev must be listed to be in charge of
PRs that affect the platform. A buildbot would be nice but not required.
I'm thinking either historical platforms we support or something like
Emscripten that's working towards being a tier 2 platform. I'm not sure if
we want to have explicit approval to be in this tier beyond the outlined
requirements, but obviously if a core dev isn't keeping up with PRs then
the platform will be dropped.

All other platforms we do not directly support in the repository and it is
up to the community to keep functioning. We can obviously keep accepting
general patches to up compatibility, but platform-specific patches for
anything outside of these tiers wouldn't. No issue if someone provides a
buildbot for their own benefit, but these buildbots would never hold
anything up.

When a Python version hits b1, then that platform is considered supported
for that version as long as the requirements outlined above continue to be
met. Once the Python version hits EOL then like anything, support ends no
matter what. We could capture the supported platforms for a version in the
release schedule PEP if people want.

I would expect appropriate labels being added to the builders listed at
https://buildbot.python.org/all/#/builders to signify which platforms we
block releases for (e.g. `tier-1,`, `tier-2`, or `release-blocker` as a
generic label).

I would expect PEP 11 to list the appropriate C symbol that's set for that
platform, e.g. __linux__.

I don't know if we want to bother listing CPU architectures since we are a
pure C project which makes CPU architecture less of a thing, but I'm
personally open to the idea of CPU architectures being a part of the
platform definition.

I don't think we should cover C compilers here as that's covered by PEP 7.
Otherwise PEP 7 should only list C versions/features and PEP 11 lists
compilers and their versions.

FYI the tier support idea and the rough definitions above come from Rust:
https://doc.rust-lang.org/nightly/rustc/platform-support.html .
___
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/ZPBSHENP3V7KHNPYWE6BEQD5ASES2NLV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Test error

[Brett Cannon]

You might want to try asking your question at
https://mail.python.org/mailman3/lists/core-mentorship.python.org/ which is
specifically set up to help people.

But in general, all the tests are passing for folks. You will need to run
those tests individually to see why they are failing for you.

On Thu, Mar 3, 2022 at 12:01 PM  wrote:

> I am new to open source and think to contribute to python .
> I was going through the developer guide and when i run this code "./python
> -m test -j3" on my terminal i got this result which say it fail .Now can
> someone tell me this is normal or happning to me only . If this happen to
> everyone how can i fix this
> == Tests result: FAILURE ==
> 380 tests OK.
> 2 tests failed:
> test_compileall test_distutils
> 43 tests skipped:
> test_asdl_parser test_check_c_globals test_clinic test_curses
> test_dbm_gnu test_dbm_ndbm test_devpoll test_epoll test_fcntl
> test_fork1 test_gdb test_grp test_ioctl test_kqueue
> test_multiprocessing_fork test_multiprocessing_forkserver test_nis
> test_openpty test_ossaudiodev test_pipes test_poll test_posix
> test_pty test_pwd test_readline test_resource test_smtpnet
> test_socketserver test_spwd test_syslog test_threadsignals
> test_timeout test_tix test_tk test_ttk_guionly test_urllib2net
> test_urllibnet test_wait3 test_wait4 test_winsound test_xmlrpc_net
> test_xxtestfuzz test_zipfile64
> Total duration: 11 min 14 sec
> Tests result: FAILURE
> ___
> 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/HLNULX74RBEQ5ZKVTZBT4FYTZGT7JET2/
> 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/4FYW7MIRJ2D6PRETBCE3JVGRMQ67HPTS/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: October/November/December Steering Council update

[Brett Cannon]

On Tue, Mar 1, 2022 at 9:00 AM Joannah Nanjekye 
wrote:

> > Steering Council did a one hour Q recorded session with Visionary
> sponsor, Bloomberg.
>
> Is it possible to access this recording for transparency purposes or is
> it confidential?
>

We can ask, but I vaguely remember the folks at Bloomberg being told they
could ask us questions involving internal tech.


>
> I saw some people in another language community on a twitter thread where
> people were having
> rumours and speculations of similar discussions, thinking such companies
> influence community decisions.
>
>
If I remember correctly it was the same type of questions we have gotten
from the host of the core dev sprints: where do you see things going, do
you have plans for this, what's the next challenge for Python, etc. It's
actually just like the kind of Q that has occurred at PyCon US as well.
Usually the private nature stems more from people saying, "we have this
system at work that does this and what do you think of that," and not any
influence campaign.

The fact that I can't remember what was asked shows how influential the Q
was. 

And in case anyone happens to be ever concerned, the 2/5 rule for any
single company being on the SC is a direct way this is kind of concern is
stopped. After that is not voting for anyone you think won't put Python's
best interest ahead of corporate interests.


> Disclaimer: I personally trust the SC.
>

Thanks! 

-Brett


>
>
>
> On Tue, Mar 1, 2022 at 7:39 PM Pablo Galindo Salgado 
> wrote:
>
>> We’ve just published the October, November and December steering council
>> update for 2021, also included below:
>>
>>
>> https://github.com/python/steering-council/blob/main/updates/2021-10-steering-council-update.md
>>
>> https://github.com/python/steering-council/blob/main/updates/2021-11-steering-council-update.md
>>
>> https://github.com/python/steering-council/blob/main/updates/2021-12-steering-council-update.md
>>
>> Just as a reminder, if you have any questions or concerns, feel free to
>> contact us or open an issue in the SC repo:
>> https://github.com/python/steering-council
>>
>>
>> *October 11*
>>
>>- SC met with the Developer-in-Residence and provided feedback on the
>>Developer-in-Residence activity blog.
>>- SC decided to keep 2020 dates for 2021 election.
>>- SC discussed the draft about the SC's position on the PEP 649 / PEP
>>563 situation (stringified annotations) and provided feedback.
>>- SC discussed whether or not they should extend their weekly
>>meetings and/or do more async communications. They also decided that the 
>> SC
>>should continue having meetings and working during the elections.
>>
>>
>> *October 18*
>>
>>- Steering Council met with the GitHub Issues PM for an update on the
>>migration. Priority right now is getting a testing repo out to the core 
>> dev
>>sprint and triagers by Wednesday.
>>- SC reviewed PEP 663 (Standardizing Enum str(), repr(), and format()
>>behaviors) and potential PEP Delegates.
>>- SC reviewed and discussed issues open on
>>https://github.com/python/steering-council/issues
>>
>>
>> *October 19*
>>
>>- SC met with the Search Firm the PSF is using for the Executive
>>Director search, to provide input on the search parameters, and suggest
>>potential candidates.
>>
>>
>> *October 25*
>>
>>- Steering Council did a one hour Q recorded session with Visionary
>>sponsor, Bloomberg.
>>- Steering Council discussed PEP 649 and PEP 563 (stringified
>>annotations). The group may want to delegate this to Łukasz but will
>>discuss this more next week.
>>- The candidate PEP Delegate for PEP 663 (Standardizing Enum str(),
>>repr(), and format() behaviors) declined. The Steering Council will think
>>of who else it can be delegated to, or take it on themselves.
>>
>> November 1
>>
>>- The SC discussed PEP 649 -- Deferred Evaluation Of Annotations
>>Using Descriptors  & PEP
>>563 -- Postponed Evaluation of Annotations
>>. The SC decided it would
>>tell the community that more information is needed. Barry will draft an
>>email explaining the current situation and calling for help from static 
>> and
>>dynamic typing users.
>>- The SC reviewed the open issues in the public Steering Council
>>repo: https://github.com/python/steering-council/issues.
>>- The SC discussed SC promotion during the call for nomination
>>period, which started on Nov 1.
>>- The SC discussed PEP 663 - Standardizing Enum str(), repr(), and
>>format() behaviors  and
>>that Barry would write the rejection draft.
>>- Brett informed the SC of an issue involving the return type of
>>iterators and the SC decided it would continue discussing it at the next
>>meeting (https://bugs.python.org/issue45250).
>>

[Python-Dev] Re: PEP 683: "Immortal Objects, Using a Fixed Refcount" (round 2)

[Brett Cannon]

On Wed, Feb 23, 2022 at 8:19 AM Petr Viktorin  wrote:

> On 23. 02. 22 2:46, Eric Snow wrote:
>
>
[SNIP]


>
> > So it seems like the bar should be pretty low for this one (assuming
> > we get the performance penalty low enough).  If it were some massive
> > or broadly impactful (or even clearly public) change then I suppose
> > you could call the motivation weak.  However, this isn't that sort of
> > PEP.


Yes, but PEPs are not just about complexity, but also impact on users. And
"impact" covers backwards-compatibility which includes performance
regressions (i.e. making Python slower means it may no longer be a viable
for someone with specific performance requirements). So with the initial 4%
performance regression it made sense to write a PEP.
___
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/Z4SXVNRLHFWRPLB4UQZQVW7SKDUJH6GY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Request for feedback: pathlib.AbstractPath prototype

[Brett Cannon]

On Thu, Feb 10, 2022 at 2:15 PM Ethan Furman  wrote:

> On 2/10/22 1:45 PM, Brett Cannon wrote:
>
>  > Protocols would let folks rely on a common Path object API w/o having
> to require the object
>  > come from pathlib itself or explicitly subclass something (which I
> admit would be rare, but
>  > there's no reason to artificially constrain this either). Now maybe
> this is too broad of an
>  > API for people to care, but since protocols are also ABCs it doesn't
> inherently make things
>  > worse, either. So I would say subclassing Protocol makes sense while
> still using
>  > abc.abstractmethod for methods people must implement.
>
> Brett, when you say Protocol are you referring to static typing?


Yep, specifically
https://docs.python.org/3/library/typing.html#typing.Protocol .


>   In your earlier email I thought you were referring to
> building blocks such as _fs_path, or the __iter__ and __next__ protocols.
>

Technically those are *special methods*  that define a protocol (obviously
`typing.Protocol` got its name from somewhere ). But it's all the same
concept: defining what methods you expect an object to have.
___
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/IGYMVZYNQZZ2PXBQTOIG7TVJVZWFNLYI/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Request for feedback: pathlib.AbstractPath prototype

[Brett Cannon]

On Wed, Feb 9, 2022 at 11:59 AM Barney Gale  wrote:

> Penny for your thoughts on those questions, Brett? Protocols are new to
> me. I see importlib.abc.Traversable is a Protocol, and I'm giving PEP 544 a
> read now.
>

Protocols would let folks rely on a common Path object API w/o having to
require the object come from pathlib itself or explicitly subclass
something (which I admit would be rare, but there's no reason to
artificially constrain this either). Now maybe this is too broad of an API
for people to care, but since protocols are also ABCs it doesn't inherently
make things worse, either. So I would say subclassing Protocol makes sense
while still using abc.abstractmethod for methods people must implement.


>
> I reckon only stat(), open() and iterdir() would be essential for users to
> implement.
>

Seems like a reasonable set to have to implement.

-Brett


>
> On Wed, 9 Feb 2022 at 19:02, Brett Cannon  wrote:
>
>> One thing to discuss (and which has been brought up on the PR), is
>> whether this should be an ABC to force people to explicitly raise
>> `NotImplementedError`?
>>
>> The next question is whether any of this should be a (very wide) protocol
>> instead of an ABC?
>>
>> On Wed, Feb 9, 2022 at 7:05 AM Barney Gale  wrote:
>>
>>> Over the last couple of years I've been tidying up the pathlib
>>> internals, with a view towards adding an AbstractPath class to the
>>> hierarchy. Users would be able to subclass AbstractPath to implement other
>>> kinds of filesystems: s3, google cloud storage, pandas, ftp, git, zip and
>>> tar files, etc. By implementing some abstract methods (stat(), iterdir(),
>>> open(), etc) they'd benefit from a number of derived methods (is_dir(),
>>> glob(), read_text(), etc). There's already a healthy ecosystem of PyPI
>>> packages attempting this, but there's presently no officially-supported
>>> route.
>>>
>>> I've now submitted a PR that adds an initial underscore-prefixed
>>> implementation of this class:
>>> https://github.com/python/cpython/pull/31085. The implementation is
>>> simple: wherever Path calls functions in os, io, pwd, etc, AbstractPath
>>> instead raises NotImplementedError. The Path class becomes an
>>> implementation of AbstractPath.
>>>
>>> These methods directly raise NotImplementedError: cwd(), stat(),
>>> iterdir(), readlink(), resolve(), expanduser(), owner(), group(), open(),
>>> touch(), mkdir(), symlink_to(), hardlink_to(), rename(), replace(),
>>> chmod(), unlink(), rmdir()
>>>
>>> These methods call through to the above methods: absolute(), lstat(),
>>> exists(), is_dir(), is_file(), is_mount(), is_symlink(), is_block_device(),
>>> is_char_device(), is_fifo(), is_socket(), home(), samefile(), scandir(),
>>> glob(), rglob(), read_bytes(), read_text(), write_bytes(), write_text(),
>>> lchmod(), link_to()
>>>
>>> Some methods aren't applicable to some kinds of filesystems, e.g. zip
>>> files don't support symlinks, working directories or home directories. In
>>> these cases I think it's reasonable to raise NotImplementedError. Indeed,
>>> pathlib.Path methods already raise NotImplementedError when certain local
>>> filesystem features aren't available (readlink(), group(), etc).
>>>
>>> If any readers of this list have previously tried to extend pathlib to
>>> other domains, or are otherwise interested in pathlib development, please
>>> could you let me know what you think of the proposed API?
>>>
>>> Many thanks
>>> ___
>>> 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/JB7QGDNI2CNXFX7LQQ2X2WPOZ7DWVNQL/
>>> 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/CVU3MHGFLAIUMTCHMZBPLFJBW3MLMNAG/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Request for feedback: pathlib.AbstractPath prototype

[Brett Cannon]

One thing to discuss (and which has been brought up on the PR), is whether
this should be an ABC to force people to explicitly raise
`NotImplementedError`?

The next question is whether any of this should be a (very wide) protocol
instead of an ABC?

On Wed, Feb 9, 2022 at 7:05 AM Barney Gale  wrote:

> Over the last couple of years I've been tidying up the pathlib internals,
> with a view towards adding an AbstractPath class to the hierarchy. Users
> would be able to subclass AbstractPath to implement other kinds of
> filesystems: s3, google cloud storage, pandas, ftp, git, zip and tar files,
> etc. By implementing some abstract methods (stat(), iterdir(), open(), etc)
> they'd benefit from a number of derived methods (is_dir(), glob(),
> read_text(), etc). There's already a healthy ecosystem of PyPI packages
> attempting this, but there's presently no officially-supported route.
>
> I've now submitted a PR that adds an initial underscore-prefixed
> implementation of this class: https://github.com/python/cpython/pull/31085.
> The implementation is simple: wherever Path calls functions in os, io, pwd,
> etc, AbstractPath instead raises NotImplementedError. The Path class
> becomes an implementation of AbstractPath.
>
> These methods directly raise NotImplementedError: cwd(), stat(),
> iterdir(), readlink(), resolve(), expanduser(), owner(), group(), open(),
> touch(), mkdir(), symlink_to(), hardlink_to(), rename(), replace(),
> chmod(), unlink(), rmdir()
>
> These methods call through to the above methods: absolute(), lstat(),
> exists(), is_dir(), is_file(), is_mount(), is_symlink(), is_block_device(),
> is_char_device(), is_fifo(), is_socket(), home(), samefile(), scandir(),
> glob(), rglob(), read_bytes(), read_text(), write_bytes(), write_text(),
> lchmod(), link_to()
>
> Some methods aren't applicable to some kinds of filesystems, e.g. zip
> files don't support symlinks, working directories or home directories. In
> these cases I think it's reasonable to raise NotImplementedError. Indeed,
> pathlib.Path methods already raise NotImplementedError when certain local
> filesystem features aren't available (readlink(), group(), etc).
>
> If any readers of this list have previously tried to extend pathlib to
> other domains, or are otherwise interested in pathlib development, please
> could you let me know what you think of the proposed API?
>
> Many thanks
> ___
> 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/JB7QGDNI2CNXFX7LQQ2X2WPOZ7DWVNQL/
> 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/A3P646PI6U27UNXETNR7X76NGKSX6OI4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Should we require IEEE 754 floating-point for CPython?

[Brett Cannon]

On Tue, Feb 8, 2022 at 10:20 PM Steven D'Aprano  wrote:

> On Tue, Feb 08, 2022 at 05:48:46PM -0800, Gregory P. Smith wrote:
> > On Tue, Feb 8, 2022 at 2:41 PM Steven D'Aprano 
> wrote:
>
> > > If the answer to those questions are Yes, that rules out using Unums,
> > > posits, sigmoid numbers etc as the builtin float. (The terminology is a
> > > bit vague, sorry.) Do we want that?
> >
> > It does not rule anything else out should they become viable.  This is
> just
> > a statement that to build cpython we require ieee754 support.  It does
> not
> > say anything about how our Python float type is implemented internally.
>
> Posits do not implement IEEE-754. They aren't merely a different
> internal representation of the IEEE-754 floating point standard, they
> implement a different numeric system altogether.
>
> Things that IEEE-754 require, such as signed zero and signed infinity,
> are not supported by posits. Posits include a single unsigned zero and a
> single unsigned infinity.
>
> Earlier, I made a mistake: I misremembered that posits support a single
> NAN, and so I removed Mark's question about requiring NANs from my
> quoting. I was wrong to do so: posits do not have any NANs.
>
> So if we require NANs, or IEEE-754, that rules out posits as the builtin
> float.
>

As Greg said, all we are discussing is requiring NaN and IEEE-754 in order
to compile CPython. There's nothing saying we can't change how things are
implemented in CPython in the future if something else made sense. And if
someone wants to fork CPython to implement something else they can as well.
And none of this has any bearing on the language based on the trend of this
conversation's answer to Mark's third question. So I am not seeing how any
decision we make from this thread about CPython and IEEE-754 rules anything
out in the future?
___
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/6LYTRCA3JGLAX4H4GOOMKCXCYZVPJLEE/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Brett Cannon]

On Wed, Feb 9, 2022 at 4:19 AM Petr Viktorin  wrote:

>
>
> On 09. 02. 22 4:39, h.vetin...@gmx.com wrote:
> >> Maybe a more practical approach would be to use C99 "except of
> > features not supported by MSVC of Visual Studio 2019"?
> >
> > This could be formulated in a more neutral way by saying
> >
> > "C99 without the things that became optional in C11", or perhaps
>
> That sounds like a better wording!
>
> > "C11 without optional features" (at least from the POV of MSVC,
> > haven't checked the other compilers/platforms for C11-compliance).
>
> That's an interesting idea -- what's keeping us from C11?
>

No one asking before, probably because we have been trying to get to C99
for so long. 


> In other words: the main thing keeping us from C99 is MSVC support, and
> since that compiler apparently skipped C99, should we skip it as well?
>

If we think "C11 without optional features" is widely supported then I
think that's a fine target to have.

For anyone not sure what's optional in C11, I found
https://en.wikipedia.org/wiki/C11_%28C_standard_revision%29#Optional_features
. Other than atomics being discussed on Discord for mimalloc, leaving those
things out seem reasonable to me.

-Brett


>
>
> >> In practice, we can try to support VS 2017, the version currently
> > recommended by the devguide:
> >
> > 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.
> > ___
> > 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/IIZ6LXK2MANUHZAMYSXDF5KPF3VIRKDJ/
> > 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/ERQQFXNAGANR2ND3SRDVCIQZKYTT6OBM/
> 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/SV7M2CXVULHVG4X6SXZV7ZR5Y4TD3IBR/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: It's now time to deprecate the stdlib urllib module

[Brett Cannon]

On Mon, Feb 7, 2022 at 5:51 PM Jim J. Jewett  wrote:

> There are problems with urllib.  With hindsight, it would have been nice
> to do a few things differently.  But that doesn't make migrating away from
> it any easier.
>
> This thread has mentioned several "better" alternatives -- but with the
> exception of 3rd party Requests, the docs don't even mention them.
>

And as soon as httpx hits 1.0 I plan to update the docs to point at it. But
until that occurs I personally do not want to have a debate about whether
httpx's 0.N version number means it shouldn't be recommended.


>
> Saying "You can do better, but we won't tell you how" is pretty rude to
> beginners, and we should not do it.
>
> Delegating to the operating system may be sensible for a production
> system, and there is nothing wrong with saying so in the docs, and it would
> be great if we made that easy.  But it is absolutely not a reasonable
> replacement for a straightforward (possibly inefficient and non-scalable)
> implementation written in python that people can read and use for
> reference.  urllib shouldn't be deprecated until we have a better solution
> to *that* use case that is also in the stdlib.  (That might well be worth
> doing, but it should happen before the deprecation.)
>

Why do you think the stdlib *must *provide an example implementation for
this specific scenario? Is there something unique to HTTP request handling
that you feel is important to demonstrate?
___
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/XNYPBSXW7DIBQN5YLXCWUOBLIEBRMPEP/
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

[Brett Cannon]

On Tue, Feb 8, 2022 at 8:30 AM Victor Stinner  wrote:

> Hi Petr,
>
> Thanks for the SC review, it's very helpful! I know that it's a big PEP :-)
>
> On Tue, Feb 8, 2022 at 11:33 AM Petr Viktorin  wrote:
> > *All other things being equal, static inline functions are better than
> > macros.*
> > Specifically, inline static functions should be preferred over
> > function-like macros in new code. Please add a note about this to PEP 7.
>
> Ok, I created: https://github.com/python/peps/pull/2315
>
>
> > *When there is no backwards compatibility issue, macros can be changed
> > to static inline functions.*
> > In effect, the SC accepts the first part of the PEP, except cases where:
> > a macro is converted to macro and function ("Cast to PyObject*"),
>
> 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)
> #define PyWeakref_GET_OBJECT(ref) (... ((PyWeakReference
> *)(ref))->wr_object ...)
>
> Does it mean that these macros must remain macros?
>
> PEP 670 proposes adding a macro to still cast their arguments to the
> requested type so the PEP doesn't add any new compiler warnings. The
> PEP proposes to consider removing these implicit casts later (to
> reduce the scope and limit annoyance caused by the PEP).
>
> If the macro is converted to a static inline function without such
> convenient macro, C extensions which don't pass the expected types
> will get spammed by warnings. Well, it's easy to fix, and once it is
> fixed, the code remains compatible with old Python versions.
>
> I'm not sure that I understood the SC statement here: does it mean
> that these specific macros (which cast their arguments) must remain
> macros, or that it's ok to convert them to static inline functions
> (even if it can emit new warnings)?
>
> If the SC is ok to add new compiler warnings, I'm fine with it. Most
> functions are documented with an exact type, they are not documented
> to cast implicitly their arguments to the expected types.
>
> For example, Py_INCREF() expects a PyObject* type in the documentation:
> https://docs.python.org/dev/c-api/refcounting.html#c.Py_INCREF
>
> --
>
> Or is the problem that having a macro to wrap a static inline function
> requires to change the function name? Well, technically, it's not
> needed... I wrote a PR so the macro and the function have the same
> name:
> https://github.com/python/cpython/pull/31217
>
> For example, the Py_INCREF() macro now calls Py_INCREF(), instead of
> calling _Py_INCREF().
>
> Static inline functions are not part of the ABI since they are
> inlined, but it's maybe better to avoid the "_" prefix to avoid
> confusion in debuggers and profilers (especially when comparing old
> and new Python versions).
>
>
> > and where the return value is removed.
>
> In this case, I propose to leave these macros unchanged in PEP 670 in
> this case, as it already excludes macros which can be used as l-values
> (macros changed by PEP 674).
>
> I would prefer to have the whole PEP 670 either accepted or rejected.
> I'm not comfortable with a half-accepted status, it's misleading for
> readers.
>

That's why we pointed out what is not controversial and can be done without
a PEP. That lets you update the PEP for everything remaining so we can
focus on what really need discussion instead on things that are an obvious
"yes" to us.
___
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/TCZDU6QBSHYBZQCVAJZBJMDZQTTI7BIL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: RFC on PEP 675: Arbitrary Literal Strings

[Brett Cannon]

On Mon, Feb 7, 2022 at 4:59 PM S Pradeep Kumar  wrote:

> On Mon, Feb 7, 2022 at 3:55 PM Brett Cannon  wrote:
>
>> Can I suggest adding a "Specification" section (see
>> https://www.python.org/dev/peps/pep-0012/#suggested-sections for the
>> suggested sections to have in a PEP)?
>>
>
> Brett: I'm sorry about this oversight. I've fixed it in
> https://github.com/python/peps/pull/2313
>

No need to apologize! Writing your first PEP is a lot to take on and
something like this is easy to overlook. Besides, I blame Jelle as sponsor.


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

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

[Brett Cannon]

On Mon, Feb 7, 2022 at 9:12 AM Victor Stinner  wrote:

> Hi,
>
> I made a change to require C99  "NAN" constant and I'm was
> asked to update the PEP 7 to clarify the C subset is needed to build
> Python 3.11.
>
> Python 3.6 requires a subset of the C99 standard to build defined by the
> PEP 7:
> https://www.python.org/dev/peps/pep-0007/
>
> I modified Python 3.11 to require more C99 features of the  header:
>
> * bpo-45440: copysign(), hypot(), isfinite(), isinf(), isnan(), round()
> * bpo-46640: NAN
>
> After my NAN change (bpo-46640), Petr Viktorin asked me to update the
> PEP 7. I proposed a change to simply say that "Python 3.11 and newer
> versions use C99":
> https://github.com/python/peps/pull/2309
>
> I would prefer to not have to give an exhaustive list of C99 features
> used by CPython, since it's unclear to me what belongs to C99 or to
> ISO C89. As I wrote before, Python already uses C99 features since
> Python 3.6.
>
> On my PEP PR, Guido van Rossum asked me to escalate the discussion to
> python-dev, so here I am :-)
>
> In "C99", the number "99" refers to the year 1999, the standard is now
> 23 years old:
> https://en.wikipedia.org/wiki/C99
>
> In 2022, C99 is now well supported by C compilers supported by Python:
> GCC, clang, MSVC.


I think if those compilers fully C99 at this point we should consider just
moving completely over to C99.

-Brett


>
> I don't know if AIX XLC supports C99. AIX provides a "c99" compiler
> compatible with C99. It also seems like GCC is usable on AIX.
>
> I don't know if ICC supports C99. Python doesn't officially the ICC
> compiler, the ICC buildbots are gone a few years ago. But sometimes I
> make some changes to enhance the ICC support, when the change is small
> enough.
>
> Note: Python also uses C11 , but it's not required: there
> are fallbacks for compilers which don't support it.
>
> 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/J5FSP6J4EITPY5C2UJI7HSL2GQCTCUWN/
> 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/ZLDOBJUVMTIRETVRNHPWWO5MBHTXYEW3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: RFC on PEP 675: Arbitrary Literal Strings

[Brett Cannon]

Can I suggest adding a "Specification" section (see
https://www.python.org/dev/peps/pep-0012/#suggested-sections for the
suggested sections to have in a PEP)?

When you first pull up the PEP it goes from "Rationale" to "Valid Locations
for LiteralString". As a reader that doesn't point me at a valid start
point to capture the key details I need to know to understand what changes
to Python are being proposed. For instance, is LiteralString supported to
be a new built-in? Is it a subclass of str? I have no way to know from the
first section of the PEP that isn't trying to convince me why this PEP is
worth reading.

On Mon, Feb 7, 2022 at 3:38 PM Pradeep Kumar Srinivasan 
wrote:

> PEP 675 [1] introduces a supertype for precise literal string types, such
> as `Literal["foo"]`, called `LiteralString`.
>
> The PEP allows libraries to distinguish the type of command strings from
> data. Powerful, command-executing libraries try to prevent security
> vulnerabilities by accepting arguments separately from the SQL query or
> shell command. However, these libraries have no way to prevent programmers
> from, say, using f-strings to embed arguments within the command string,
> which can allow malicious users to execute arbitrary commands (called
> "SQL/shell injection"). With this PEP, libraries can rely on type checkers
> to prevent such common, undesired uses.
>
> Scala has a very similar concept that is used to prevent SQL injection at
> compile time. [5] We also discuss the drawbacks of alternative approaches,
> such as security linters, full taint analysis, and NewTypes [6].
>
> Since we have reached consensus on the PEP in typing-sig [2], we wanted to
> get your comments and suggestions before submitting to the Steering
> Council.
>
> This PEP is mainly useful for type checking. There are no changes to
> Python syntax or runtime behavior.
>
> Discussions:
> + typing-sig: [2]
> + BPO issue suggesting using this PEP to prevent vulnerabilities in
> loggers: [4]
> + Reddit thread on r/Python discussing this PEP: [3]
>
> Thanks,
> S Pradeep Kumar
> Graham Bleaney
>
> [1]: https://www.python.org/dev/peps/pep-0675/
> [2]:
> https://mail.python.org/archives/list/typing-...@python.org/thread/VB74EHNM4RODDFM64NEEEBJQVAUAWIAW/
> [3]:
> https://www.reddit.com/r/Python/comments/r71lzi/pep_675_arbitrary_literal_strings/
> [4]: https://bugs.python.org/issue46200
> [5]:
> https://www.python.org/dev/peps/pep-0675/#literal-string-types-in-scala
> [6]: https://www.python.org/dev/peps/pep-0675/#rejected-alternatives
> ___
> 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/AXR3ZBEZF2UTBC2RFCASBTQB4ZYNQGET/
> 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/7O66E32XD6ZWLQHW55OPWBJ6AQNF7SYT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: It's now time to deprecate the stdlib urllib module

[Brett Cannon]

On Mon, Feb 7, 2022 at 4:56 AM Steve Dower  wrote:

> On 2/6/2022 4:44 PM, Christian Heimes wrote:
> > If I had the power and time, then I would replace urllib with a simpler,
> > reduced HTTP client that uses platform's HTTP library under the hood
> > (WinHTTP on Windows, NSURLSession (?) on macOS, Web API for Emscripten,
> > maybe curl on Linux/BSD). For non-trivial HTTP requests, httpx or
> > aiohttp are much better suited than urllib.
>
> I'm +1 on this, though I think it would have to be in place before the
> "two releases until removal" kicked in for urllib.request.
>

Yes, we definitely couldn't deprecate anything regarding downloading over
HTTP w/o having a replacement in place.

I am not even considering deprecating urllib.parse.


>
> The stdlib can't get by without at least the basic functionality of curl
> built in natively. But we can do this on most platforms without
> vendoring OpenSSL, which is a HUGE win. Then our default behaviour could
> correctly use proxies (including auto-config), CA certificate bundles,
> integrated authentication, and other OS features that are currently
> ignored by our core.
>

I also agree this is the best of the 2 options, although I would also
accept Christian's other option of a more targeted, tight,
standards-compliant solution if that would somehow lead to less maintenance
overhead. And when I say "less maintenance overhead," I really mean it: I
would question whether following redirects as an option is worth the
overhead in this scenario. I'm very much thinking of this from a
bootstrap/script/learning scenario and pushing people towards e.g. httpx
for anything fancier.


>
> Chances are we could keep simple urlopen() calls in place, and use the
> deprecation as a "potential change of behaviour" without necessarily
> having to break the API. I'm yet to come across a case where making a
> trivial urlopen() call _better_ would break things (the cases I've seen
> that would break are things like "using an OpenSSL environment variable
> to configure something that I wish had been automatic").
>

We could try to get fancy and only raise DeprecationWarning in cases where
things won't work to extend when we consider pushing people to the better
API.


>
> The nature of network/internet access is that we have to break things
> periodically anyway, because all the code that was written over the last
> 30+ years is eventually going to be found to be exploitable. I'd be
> quite happy to say "Python gives you what your OS gives you; update the
> OS for fixes".
>

Exactly. My guideline for this whole idea would be that if it doesn't make
sense in a beginner course that says to "download an HTML page and count
all the anchor tags," then it's too fancy for the stdlib. And that should
be enough to bootstrap installers which then get you httpx. Otherwise the
networking stack moves too fast (from a security POV) and requires unique
knowledge to get right that we have simply not kept up as much as we would
like. I think it's okay to admit it might be time to trim with part of the
stdlib down to something that we can manage easily (but we *cannot* drop
the ability to download something over HTTPS).
___
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/VP2WXOBWPGAX7UIH25DWRSYWFEDNINNU/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Brett Cannon]

On Mon, Feb 7, 2022 at 8:59 AM Victor Stinner  wrote:

> On Mon, Feb 7, 2022 at 5:48 PM Guido van Rossum  wrote:
> > So you're proposing to completely get rid of those three?
>
> I don't propose to remove them, but only call them if Python is built
> in debug mode. Or remove them from the release build, unless
> ./configure --with-assertions is used.
>
>
> > And you're sure that each and every single call to any of those is
> better off being an assert()?
>
> For many years, many C extensions raised an exception *and* returned a
> result: that's a bug. The strange part is that in some cases, the
> exceptions is somehow ignored and the program continues running fine.
>
> That's why I added _Py_CheckFunctionResult() and _Py_CheckSlotResult()
> which helped to catch such bugs. But before that, these programs were
> running fine :-)
>
> So it's not fully clear to me there was really a bug or it's just that
> Python became more pedantic :-)
>
>
> About PyErr_BadInternalCall(): in 10 years, I saw a few SystemError
> raised by this function, but usually when I hacked on Python. It's
> really rare to hit such bug.
>
>
> > (I still haven't gotten into the habit of building in debug mode by
> default, in part because it *isn't* the default when you invoke ./configure
> or PCbuild/build.bat.)
>
> If you don't develop C extensions, the release mode is faster and enough
> ;-)
>
> Ah. I don't know if CIs like GitHub Actions and Azure Pipelines
> provide Python debug builds. If if it's not the case, it would be nice
> to have the choice :-)
>

They do not:
https://github.com/actions/python-versions/blob/797eb71c41e47d194f563c7ef01790d734534788/builders/ubuntu-python-builder.psm1#L35-L38
.
___
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/VRISRYZVU47PQRWKHN77CV5545SKUI5O/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Should we require IEEE 754 floating-point for CPython?

[Brett Cannon]

On Mon, Feb 7, 2022 at 12:31 PM Gregory P. Smith  wrote:

>
>
> On Mon, Feb 7, 2022 at 11:06 AM Victor Stinner 
> wrote:
>
>> Hi Mark,
>>
>> Aha, good, you posted an email to python-dev, good :-) Last days, I
>> was trying to collect more data about this topic, especially find
>> platforms which *don't* support IEEE 754, before posting to
>> python-dev.
>>
>> Nowadays, outside museums, it's hard to find computers which don't
>> implement IEEE 754.
>>
>> * Since 1998, IBM S/390 supports IEEE 754.
>> * Compaq/DEC VAX didn't use IEEE 754, but are no longer built since
>> 2000 (you cant still use Python 3.10 if it can be built on it!)
>> * Some Cray computers like Cray SV1 (1998) don't implement IEEE 754,
>> but other Cray computers like Cray T90 (1995) implement IEEE 754.
>>
>> There are embedded devices with no hardware FPU: in this case, the FPU
>> is implemented in software. I expect it to implement IEEE 754. Is
>> CPython a good target for such small CPUs which have no hardware FPU?
>> MicroPython may better fit their needs.
>>
>> On the other side, all moderns CPU architectures support IEEE 754:
>> Intel x86, ARM, IBM Power and PowerPC, Compaq/DEC Alpha, HP PA-RISC,
>> Motorola 68xxx and 88xxx, SGI R-, Sun SPARC.
>>
>> Sources:
>>
>> *
>> https://en.wikipedia.org/wiki/Floating-point_arithmetic#IEEE_754:_floating_point_in_modern_computers
>> *
>> https://stackoverflow.com/questions/2234468/do-any-real-world-cpus-not-use-ieee-754
>>
>>
>> On Mon, Feb 7, 2022 at 7:25 PM Mark Dickinson  wrote:
>> > - Should we require the presence of NaNs in order for CPython to build?
>> > - Should we require IEEE 754 floating-point for
>> CPython-the-implementation?
>>
>> In the past, when we deprecated the support for an old platform, we
>> didn't suddenly remove the code. We made sure that it's no longer
>> possible to build on it. So if anyone notices, it's easy to revert
>> (ex: remove the few lines in configure).
>>
>> Would it make sense to trigger a build error on plaforms which don't
>> support IEEE 754 in Python 3.11, and later decide if it's time to
>> remove the code in in Python 3.12?
>>
>> Well. If you ask *me*, I'm in favor of removing the code right now. If
>> someone needs to support a platform which doesn't support IEEE 754,
>> the support can be maintained *outside* the Python source code, as
>> external patches or as a Git fork, no?
>>
>> Honestly, I never got access to any machine which doesn't support IEEE
>> 754 (or nobody told me!).
>>
>>
>> > - Should we require IEEE 754 floating-point for Python-the-language?
>>
>> Right now, I have no opinion on this question.
>>
>>
>> > Note that on the current main branch there's a Py_NO_NAN macro that
>> builders can define to indicate that NaNs aren't supported, but the Python
>> build is currently broken if Py_NO_NAN is defined (see
>> https://bugs.python.org/issue46656). If the answer to the first question
>> is "No", then we need to fix the build under Py_NO_NAN. That's not a big
>> deal - perhaps a couple of hours of work.
>>
>> My comment on bpo-46656: "Python uses Py_NAN without "#ifdef Py_NAN"
>> guard since 2008. Building Python with Py_NO_NAN never worked. Nobody
>> reported such build failure in the last 14 years..."
>>
>> If anyone would try building/using Python on a platform without NAN, I
>> would expect that we would get a bug report or an email. I'm not aware
>> of anything like that, so it seems like nobody uses Python on such
>> platform.
>>
>> Victor
>>
>
> It's 2022. We should just require both NaN and IEEE-754.
>
> By the time a system is large enough to build and run CPython, it is
> exceedingly unlikely that it will not be able to do that. Even if it means
> software emulation of IEEE-754 floating point on something large yet odd
> enough not to have a FPU.
>
> The places where non-IEEE-754 and non-NaN floating point are likely to
> exist are in specialized parallelized coprocessor hardware. Not the general
> purpose CPU running CPython.
>

Do we have a buildbot that has a CPU or OS that can't handle IEEE-754? What
are the chances we will get one? If the answers are "none" and "slim", then
it seems reasonable to require NaN and IEEE-754.
___
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/QTJAUZ476W7UXL2LQR3VWZBB6CVQ7OA6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Should we require IEEE 754 floating-point for CPython?

[Brett Cannon]

On Mon, Feb 7, 2022 at 11:02 AM Victor Stinner  wrote:

> Hi Mark,
>
> Aha, good, you posted an email to python-dev, good :-) Last days, I
> was trying to collect more data about this topic, especially find
> platforms which *don't* support IEEE 754, before posting to
> python-dev.
>
> Nowadays, outside museums, it's hard to find computers which don't
> implement IEEE 754.
>
> * Since 1998, IBM S/390 supports IEEE 754.
> * Compaq/DEC VAX didn't use IEEE 754, but are no longer built since
> 2000 (you cant still use Python 3.10 if it can be built on it!)
> * Some Cray computers like Cray SV1 (1998) don't implement IEEE 754,
> but other Cray computers like Cray T90 (1995) implement IEEE 754.
>
> There are embedded devices with no hardware FPU: in this case, the FPU
> is implemented in software. I expect it to implement IEEE 754. Is
> CPython a good target for such small CPUs which have no hardware FPU?
> MicroPython may better fit their needs.
>
> On the other side, all moderns CPU architectures support IEEE 754:
> Intel x86, ARM, IBM Power and PowerPC, Compaq/DEC Alpha, HP PA-RISC,
> Motorola 68xxx and 88xxx, SGI R-, Sun SPARC.
>

RISC-V also supports the 2008 IEEE-754 spec:
https://riscv.org/technical/specifications/ .

-Brett



>
> Sources:
>
> *
> https://en.wikipedia.org/wiki/Floating-point_arithmetic#IEEE_754:_floating_point_in_modern_computers
> *
> https://stackoverflow.com/questions/2234468/do-any-real-world-cpus-not-use-ieee-754
>
>
> On Mon, Feb 7, 2022 at 7:25 PM Mark Dickinson  wrote:
> > - Should we require the presence of NaNs in order for CPython to build?
> > - Should we require IEEE 754 floating-point for
> CPython-the-implementation?
>
> In the past, when we deprecated the support for an old platform, we
> didn't suddenly remove the code. We made sure that it's no longer
> possible to build on it. So if anyone notices, it's easy to revert
> (ex: remove the few lines in configure).
>
> Would it make sense to trigger a build error on plaforms which don't
> support IEEE 754 in Python 3.11, and later decide if it's time to
> remove the code in in Python 3.12?
>
> Well. If you ask *me*, I'm in favor of removing the code right now. If
> someone needs to support a platform which doesn't support IEEE 754,
> the support can be maintained *outside* the Python source code, as
> external patches or as a Git fork, no?
>
> Honestly, I never got access to any machine which doesn't support IEEE
> 754 (or nobody told me!).
>
>
> > - Should we require IEEE 754 floating-point for Python-the-language?
>
> Right now, I have no opinion on this question.
>
>
> > Note that on the current main branch there's a Py_NO_NAN macro that
> builders can define to indicate that NaNs aren't supported, but the Python
> build is currently broken if Py_NO_NAN is defined (see
> https://bugs.python.org/issue46656). If the answer to the first question
> is "No", then we need to fix the build under Py_NO_NAN. That's not a big
> deal - perhaps a couple of hours of work.
>
> My comment on bpo-46656: "Python uses Py_NAN without "#ifdef Py_NAN"
> guard since 2008. Building Python with Py_NO_NAN never worked. Nobody
> reported such build failure in the last 14 years..."
>
> If anyone would try building/using Python on a platform without NAN, I
> would expect that we would get a bug report or an email. I'm not aware
> of anything like that, so it seems like nobody uses Python on such
> platform.
>
> 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/PPVBMCKL5E2MVTWVFGSI4VTT6IAJ5QBF/
> 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/WLYIMCEBOKWHYX4XIYLRRX4VHGZGMSJO/
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

[Brett Cannon]

On Thu, Feb 3, 2022 at 3:53 PM Eric V. Smith  wrote:

> On 2/3/2022 12:15 PM, Victor Stinner wrote:
> > I'm working bottom-to-top: prepare PyObject and PyVarObject to become
> > opaque, *and* top-to-bottom: prepare subclasses (structures
> > "inheriting" from PyObject and PyVarObject) to become opaque like
> > PyFrameObject.
> >
> > IMO if PyObject* becomes a handle, the migration to the HPy API should
> > be much easier.
>
> It seems to me that moving PyObject* to be a handle leaves you in a
> place very similar to HPy. So why not just focus on making HPy suitable
> for developing C extensions, leave the existing C API alone, and
> eventually abandon the existing C API?
>

I think that's a possibility. I think it's a question for the team here
whether that's the long-term goal that we want. If so we can make all of
our work head towards that and help out HPy out as best we can.
___
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/US5U3STNFQGWLWVD6PLK6RDHYG5SH3Z3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Moving away from _Py_IDENTIFIER().

[Brett Cannon]

On Thu, Feb 3, 2022 at 6:31 AM Victor Stinner  wrote:

> On Wed, Feb 2, 2022 at 11:43 PM Eric Snow 
> wrote:
> > My plan is to replace our use of _Py_IDENTIFIER() with statically
> > initialized string objects (as fields under _PyRuntimeState).  That
> > involves the following:
> >
> > * add a PyUnicodeObject field (not a pointer) to _PyRuntimeState for
> > each string that currently uses _Py_IDENTIFIER() (or
> > _Py_static_string())
>
> In bpo-39465, I made the _PyUnicode_FromId() compatible with running
> sub-interpreters in parallel (one GIL per interpreter).
>
> A "static" PyUnicodeObject would have to share the reference count
> between sub-interpreters, whereas Py_INCREF/Py_DECREF are not
> thread-safe: there is lock to prevent data races.
>
> Is there a way to push the "immortal objects" strategy discussed in
> bpo-40255? The deepfreeze already pushed some functions related to
> that, like _PyObject_IMMORTAL_INIT() in the internal C API.
> Moreover... deepfreeze already produces "immortal" PyUnicodeObject
> strings using the "ob_refcnt = 9" hack.
>
> IMO we should decide on a strategy. Either we move towards immortal
> objects (modify Py_INCREF/Py_DECREF to not modify the ref count if an
> object is immortal), or we make sure that no Python is shared between
> two Python interpreters.
>

Either we come to an agreement as a group (for against the concept and then
how to do it), or if there's a stalemate it goes to the SC (with
potentially a PEP to properly explain the nuances of the proposed solution).

-Brett


>
>
> > I'd also like to actually get rid of _Py_IDENTIFIER(), along with
> > other related API including ~14 (private) C-API functions.  Dropping
> > all that helps reduce maintenance costs.
>
> Is it required by your work on static strings, or is it more about
> removing the API which would no longer be consumed by Python itself?
>
> If it's not required, would it make sense to follow the PEP 387
> deprecation (mark functions as deprecated, document the deprecation,
> and wait 2 releases to remove it)?
>
> 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/FFQ6N7K2BHG37JVFOACIEZLTKH43NV3L/
> 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/VFI6XGSCY2PVGHEHHDJY5QOT7MKM4Q5P/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Moving away from _Py_IDENTIFIER().

[Brett Cannon]

On Thu, Feb 3, 2022 at 6:37 AM Victor Stinner  wrote:

> By the way, Argument Clinic now produces way faster calling
> conventions than hand-written METH_VARARGS with PyArg_ParseTuple(). It
> would be make this tool available to 3rd party projects.
>
> Either extract it and put it on PyPI, but it means that Python will
> need to Python and pip install something to build itself... not good?
>

Since we check in the generated source you only need Python installed while
developing CPython, not to build it. And since that's already a requirement
to build the docs, freeze code, etc. I don't think that's an unreasonable
requirement.

We also don't have to break Argument Clinic out of our repo just to make it
available externally. There's nothing saying we can't have a subdirectory
of code that we directly rely on and publish separately for our development
needs. Could even add blurb into the repo that way if we wanted to.

-Brett


>
> Or we can add it to stdlib. IMO we need to write more tests and more
> documentation. Right now, test_clinic is "light". Another issue is
> that it requires on the currently privte _PyArg_Parser structure. By
> the way, this structure is causing crashes if sub-interpreters are run
> in parallel (one GIL per interpreter) because of the
> _PyArg_Parser.kwtuple tuple of keyword parameter names (tuple of str).
>
> If Eric's tool becomes successful inside CPython, we may consider to
> make it available to 3rd party projects as well. Such tool and
> Argument Clinic and not so different than Cython which generates C
> code to ease the development of C extensions modules.
>
> Victor
>
> On Thu, Feb 3, 2022 at 7:50 AM Inada Naoki  wrote:
> >
> > +1 for overall.
> >
> > On Thu, Feb 3, 2022 at 7:45 AM Eric Snow 
> wrote:
> > >
> > >
> > > I'd also like to actually get rid of _Py_IDENTIFIER(), along with
> > > other related API including ~14 (private) C-API functions.  Dropping
> > > all that helps reduce maintenance costs.  However, at least one PyPI
> > > project (blender) is using _Py_IDENTIFIER().  So, before we could get
> > > rid of it, we'd first have to deal with that project (and any others).
> > >
> >
> > It would be nice to provide something similar to _PY_IDENTIFIER, but
> > designed (and documented) for 3rd party modules like this.
> >
> > ```
> > typedef struct {
> > Py_IDENTIFIER(foo);
> > ...
> > } Modstate;
> > ...
> > // in some func
> > Modstate *state = (Modstate*)PyModule_GetState(module);
> > PyObject_GetAttr(o, PY_IDENTIFIER_STR(state->foo));
> > ...
> > // m_free()
> > static void mod_free(PyObject *module) {
> > Modstate *state = (Modstate*)PyModule_GetState(module);
> > Py_IDENTIFIER_CLEAR(state->foo);
> > }
> > ```
> >
> >
> > --
> > Inada Naoki  
> > ___
> > 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/ZZ5QOZDOAO734SDRJGMXW6AJGAVEPUHE/
> > Code of Conduct: http://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/QNP7RDER74XU3DNHJP5EAZY6G6N4VYE7/
> 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/NUPJY6G3OYEMYEAUA7BJX665A6PHDHW6/
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

[Brett Cannon]

On Thu, Feb 3, 2022 at 9:27 AM Victor Stinner  wrote:

> Hi Guido,
>

[SNIP]


>
> On Thu, Feb 3, 2022 at 1:40 AM Guido van Rossum  wrote:
>
>
[SNIP]


> >
> > Maybe we need to help there. For example IIRC conda-forge will build
> conda packages -- maybe we should offer a service like that for wheels?
>
> Tooling to automate the creation of wheel binary packages targeting
> the stable ABI would help. C extensions likely need changing a few
> function calls which are not supported by the limited C API. Someone
> has to do this work.
>

The idea of having a service to build wheels for folks is an old one that I
think a ton of people would benefit from.

Currently, people typically get pointed to
https://pypi.org/project/cibuildwheel/ as the per-project solution. But
designing a safe way to build wheels from any sdist on PyPI, keeping such a
service up, having the free processing to do it, etc. is unfortunately a
big enough project that no one has stepped forward to try and tackle it.
___
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/JYSDC7EVKPAITBEE4JJR6WNIMNBQYY44/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Brett Cannon]

On Tue, Jan 18, 2022 at 9:43 AM Richard Damon 
wrote:

>
>
> On Jan 18, 2022, at 11:34 AM, Guido van Rossum  wrote:
>
> 
> At best it shows that deprecations are complicated no matter how well you
> plan them. I remember that "noisy by default" deprecation warnings were
> widely despised.
>
> On Tue, Jan 18, 2022 at 6:49 AM Antoine Pitrou  wrote:
>
>> On Tue, 18 Jan 2022 15:17:41 +0100
>> Victor Stinner  wrote:
>> > Hi,
>> >
>> > My colleagues Tomáš Hrnčiar and Miro Hrončok made good progress on
>> > updating Python 3.10 to Python 3.11 in Fedora, but some specific
>> > Python 3.11 incompatible changes are causing more troubles than
>> > others:
>> >
>> https://discuss.python.org/t/experience-with-python-3-11-in-fedora/12911
>> >
>> > We propose to revert the following 2 changes in Python 3.11 and
>> > postpone them in a later Python version, once most projects will be
>> > compatible with these changes:
>> >
>> > * Removal of unittest aliases (bpo-45162): it broke 61 Fedora packages
>> > * Removals from configparser module (bpo-45173) - broke 28 Fedora
>> packages
>>
>> Doesn't this show, once again, that making DeprecationWarning silent by
>> default was a mistake?
>>
>>
> --
> --Guido van Rossum (python.org/~guido)
> *Pronouns: he/him **(why is my pronoun here?)
> *
>
>
> One thought, what if they were off by default UNLESS you were doing unit
> tests?
>

I believe pytest already does this.

-Brett


>
> That would cut out a lot of the excessive noise issue, but put them in
> before the programmer when they are developing. Yes, they will get the
> warnings for dependencies but that lets the programmer apply pressure to
> fix it or warning they may need to change something if it won’t get fixed.
> ___
> 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/UAHZKJNQTMXDORVGX5U5EHKI4HQAV7BN/
> 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/BSGVVVO2DLPUZPU37ETVYYZLNNL3VEF4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Minor inconvenience: f-string not recognized as docstring

[Brett Cannon]

On Tue, Jan 11, 2022 at 10:40 AM Gregory P. Smith  wrote:

>
> On Tue, Jan 11, 2022 at 10:29 AM Guido van Rossum 
> wrote:
>
>> I personally think F-strings should not be usable as docstrings. If you
>> want a dynamically calculated docstring you should assign it dynamically,
>> not smuggle it in using a string-like expression. We don't allow "blah {x}
>> blah".format(x=1) as a docstring either, not "foo %s bar" % x.
>>
>
> Agreed.  If we wanted to remove the wart of constant f-strings happening
> to work as an implementation detail in this context, that *could* be made
> into a warning.  But that kind of check may be best left to a linter for
> *all* of these dynamic situations that don't wind up populating __doc__.
>

Agreed on not supporting it and linters catching such a mistake.

-Brett


>
> -gps
>
>
>>
>> On Tue, Jan 11, 2022 at 8:12 AM Antoine Pitrou 
>> wrote:
>>
>>> On Tue, 11 Jan 2022 10:58:03 -0500
>>> "Eric V. Smith"  wrote:
>>> > Constant f-strings (those without substitutions) as doc strings used
>>> to
>>> > work, since the compiler turns them into normal strings.
>>> >
>>> > I can't find exactly where it was removed, but there was definitely
>>> > discussion about it. See https://bugs.python.org/issue28739 for at
>>> least
>>> > part of the discussion.
>>>
>>> Ah, sorry for the misunderstanding.  While the example I showed doesn't
>>> have any substitutions, I'm interested in the non-trivial (non-constant)
>>> case actually :-)
>>>
>>> Regards
>>>
>>> Antoine.
>>>
>>>
>>> >
>>> > Eric
>>> >
>>> > On 1/11/2022 8:41 AM, Antoine Pitrou wrote:
>>> > > Hello,
>>> > >
>>> > > Currently, a f-string is not recognized as a docstring:
>>> > >
>>> >  class C: f"foo"
>>> >  C.__doc__
>>> > 
>>> > > This means you need to use a (admittedly easy) workaround:
>>> > >
>>> >  class C: __doc__ = f"foo"
>>> >  C.__doc__
>>> > > 'foo'
>>> > >
>>> > > Shouldn't the former be allowed for convenience?
>>> > >
>>> > > 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/UALMEMQ4QW7W4HE2PIBARWYBKFWJZFB4/
>>> > > 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/37YAHCREZYZFSV4BRDKUEQAX4ZF4JTI6/
>>> 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/35R3DCNPIQJ7ZCHTLP64IP2XZCK7QSLJ/
>> 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/QFGCXW25TZOMEN2DRVLDQ4XQQSYNNTI7/
> 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/J5EMBDNY52ZHZPPUZSRUOCUYF4RCSRZH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Function Prototypes

[Brett Cannon]

On Thu, Dec 23, 2021 at 5:13 PM Guido van Rossum  wrote:

> On Thu, Dec 23, 2021 at 3:24 PM Steven D'Aprano 
> wrote:
>
>> On Thu, Dec 23, 2021 at 02:09:50PM -0800, Guido van Rossum wrote:
>>
>> > Without decorator too (that was Lukasz’ idea). Why bother with the
>> > decorator (*if* we were to go there)?
>>
>> So that
>>
>> def func(params): pass
>>
>> creates a function object, and
>>
>> def func(params)
>>
>> makes a Callable type object?
>>
>
> No, no, no. That syntax has already been discredited.
>
> Mark's proposal was
> ```
> @Callable
> def func(params): pass
> ```
> My question is, why does it need `@Callable`?
>

My guess is the thinking is to prevent anyone from thinking that the
function is actually meant to do anything other than be a type signature
for a callable. Otherwise it's very much convention to know what is
purposefully a no-op/always-returns-None function meant to be a callable
type based either on the naming scheme or some other practice like the
ellipsis body versus you just haven't implemented the function yet.


> Lukasz proposed just using any (undecorated) function, with the convention
> being that the body is `...` (to which I would add the convention that the
> function *name* be capitalized, since it is a type). My question (for Mark,
> or for anyone who supports `@Callable`) is why bother with the decorator.
> It should be easy to teach a type checker about this:
>
> ```
> def SomeFn(x: float) -> int:
> ...
>
> def twice(f: SomeFn) -> SomeFn:
> return lambda x: f(f(x))
> ```
>

It probably is more useful without the decorator. For instance, if you want
to type a function parameter to something that acts like `open()`, then
would you want to reproduce that type annotation or just say `opener:
builtins.open`? This would actually lean into duck typing even by allowing
people to easily say, "I want _something_ that directly quacks like this
callable" instead of having to manually duplicate the API with a separate
type annotation (which one could still do if they were worried about code
drift in regards to expectations). Basically it makes all functions and
methods immediately a potential type annotation which could be rather
powerful and could lead to more callables being used compared to
single-method protocols if there isn't some OOP need to pass an object with
a method around.
___
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/OWQBEY3ZEWAJAZALSNG47XTEEH53MFLO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: RFC on Callable Syntax PEP

[Brett Cannon]

As someone with use of this, would you find this useful (i.e. +1, +0)?
Serhiy already said "no" in another thread.

On Mon, Dec 20, 2021 at 4:38 AM Andrew Svetlov 
wrote:

> Perhaps Serhiy did more accurate counting, my estimate is very rough.
>
> On Mon, Dec 20, 2021 at 2:15 PM Serhiy Storchaka 
> wrote:
>
>> 20.12.21 13:42, Mark Shannon пише:
>> > OOI, of those 1577 Callable type hints, how many distinct Callable
>> types?
>>
>> Around 15-20%. Most of them are in tests which widely use pytest
>> fixtures, so functions taking and returning callables are common. There
>> are around 200 occurrences in non-test code, half of them are distinct
>> types.
>>
>> ___
>> 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/7YXSPACKOU7AGOHEZX2VAMXEELA3OZGA/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
>
> --
> Thanks,
> Andrew Svetlov
> ___
> 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/Q4A4ZTJHSS6ALDXHZJEERJBVGJNYC6KV/
> 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/2OPXHGWUDCFTDIYEARIRJFIGWLM6JTLR/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: RFC on Callable Syntax PEP

[Brett Cannon]

On Mon, Dec 20, 2021 at 3:44 AM Mark Shannon  wrote:

> Hi,
>
> Why not make Callable usable as a function decorator?
>
>
>
> The motivating example in the PEP is this:
>
>
> def flat_map(
>  l: list[int],
>  func: Callable[[int], list[int]]
> ) -> list[int]:
>  
>
>
> Since, as the PEP claims, `Callable[[int], list[int]]` is hard to read,
> then give it a name and use regular function definition syntax.
>
>
> @Callable
> def IntToIntFunc(a:int)->int:
>  pass
>
>
> def flat_map(
>  l: list[int],
>  func: IntToIntFunc
> ) -> list[int]:
>  
>
>
> To me, this seems much clearer than the proposed syntax and is more
> general.
>
>
> It is a little longer, but unless you are playing code golf, that
> shouldn't matter.
>

It's an interesting idea! Both `@overload` and `@final` show there is
precedence for having decorators have special meanings to static type
checkers:
https://docs.python.org/3/library/typing.html#functions-and-decorators.


>
> Cheers,
> Mark.
>
>
>
> On 16/12/2021 5:57 pm, Steven Troxler wrote:
> > Hello all,
> >
> > Thanks everyone for comments on our earlier thread [1] about callable
> type syntax. We now  have a draft PEP [2] proposing an arrow-based syntax
> for callable types, for example:
> >
> > ```
> > (int, str) -> bool # equivalent to Callable[[int, str], bool]
> > ```
> >
> > In support of the PEP we also have:
> > - a reference implementation of the parser [3] to ensure the grammar is
> correct  (tests [5], [6], [7])
> > - a detailed specification of planned runtime behavior [4], which is not
> yet in the reference implementation
> >
> > We'd like to get your feedback about the PEP in general, and especially
> details and edge cases we need to consider regarding runtime behavior.
> >
> > Cheers,
> > Steven Troxler
> >
> > -
> > [1] Earlier python-dev thread
> https://mail.python.org/archives/list/python-dev@python.org/thread/VBHJOS3LOXGVU6I4FABM6DKHH65GGCUB/
> > [2] PEP 677: https://www.python.org/dev/peps/pep-0677/
> > [3] Reference implementation of Parser:
> https://github.com/stroxler/cpython/tree/callable-type-syntax--shorthand
> > [4] Details on the runtime behavior:
> https://docs.google.com/document/d/15nmTDA_39Lo-EULQQwdwYx_Q1IYX4dD5WPnHbFG71Lk/edit
> >
> > [5] Ast tests for parser changes:
> >
> https://github.com/stroxler/cpython/blob/20eb59fdca0d6d8dbe4efa3b04038c7c22024654/Lib/test/test_ast.py#L359-L392
> > [6] Easy-read tests of examples from the PEP:
> https://github.com/stroxler/cpython/blob/callable-type-syntax--shorthand/Lib/test/test_callable_type_examples_for_pep.py
> > [7] Test sanity checking hundreds of examples pulled from typeshed:
> >
> https://github.com/stroxler/cpython/blob/callable-type-syntax--shorthand/Lib/test/test_callable_type_examples_for_pep.py
> > ___
> > 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/OGACYN2X7RX2GHAUP2AKRPT6DP432VCN/
> > 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/2BKD5YBU7WJMUY3TSX34HX5IICT5UFRQ/
> 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/OCLGF6IXGHVBCCA24ZFJMUEFJ2DJVAQX/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: RFC on Callable Syntax PEP

[Brett Cannon]

On Sun, Dec 19, 2021 at 8:26 PM Christopher Barker 
wrote:

>
> On 12/18/2021 3:13 PM, Batuhan Taskaya wrote:
>>
>> > tl;dr: I find it very troubling that we are going on a path where need
>> > to increase the language complexity (syntax) only in the cause
>> > 'easier' typing.
>
>
> Which brings up the question is whether it's worth adding  syntax for
> typing, but only in the context of typing.
>

The SC has already said we don't like that idea as that bifurcates the
knowledge one needs in order to even have a chance at comprehending a type
hint. Plus PEP 649 wouldn't be possible in that instance unless we ship a
second parser just for type hints in order to translate the type-specific
syntax to type-related objects.

-Brett


> As of right now, typing.get_type_hints() will evaluate a string
> annotation, e.g.
>
> In [62]: def f(x:"int"):
> ...: pass
> ...:
>
> In [63]: typing.get_type_hints(f)
> Out[63]: {'x': int}
>
> so get_type_hints could extend its acceptable syntax with this new use of
> -> -- and it could get used by wrapping it in quotes. And depending on
> how PEP 563 gets resolved, the quotes may not be necessary in the future.
>
> And this could open up some other nifty things, like extending what's
> allowable inside [] -- there was a discussion a while back on python-ideas
> about extending the __getitem__ protocol, partly motivated by type hints.
>
> -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/JWPMHLSPFTYAYSMWCX7LOXWBEU4FA6DC/
> 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/N7HF4FDSPEPJDWFD56NFUPHOEBU4AS7D/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: The python command help is too long

[Brett Cannon]

On Sat, Dec 18, 2021 at 4:00 PM Guido van Rossum  wrote:

> On Sat, Dec 18, 2021 at 2:16 PM Serhiy Storchaka 
> wrote:
>
>> The output of "python -h" is 104 lines long now. It was only 51 lines in
>> 3.6. 35% of it is about the -X option, and 30% about environment
>> variables. Also some lines in the -X option description are too long
>> (102 columns). Both topics are "advanced" and mostly interested for
>> debugging. I suggest to move them out of the main help output.
>>
>
> Sounds like a good plan.
>
>
>> The are two options:
>>
>> 1. Move it to pydoc topics. The advantage is that it is a standard way,
>> there are already 88 topics. The disadvantage is that this information
>> will be not available in "minimal" installations of Python which do not
>> include docs.
>>
>> 2. Add command-line options like -hX and -henv. The information will
>> always be available with the interpreter, but the interface is special.
>>
>
> For -X, I suggest we could output the following line:
>
> -X opt : implementation-specific option; use -X help to list options.
>

+1 from me.


>
> We could also see if we can put the help text for each of the supported -X
> flags in the table defining these flags (sorry, I can't recall where it
> lives, but I'm pretty sure I've seen such a table.)
>
> For env vars I think moving this to pydoc is fine; I don't think we have a
> process or mechanism that ensures the docs for env vars are even complete.
> (We don't have one for the flags either, but somehow I find it hard to
> conceive of someone adding a new command line flag without them or someone
> else involved in the code review thinking of updating the help text. But I
> find it quite conceivable that someone adds a new env var used only in a
> corner case without anyone thinking to update the docs. And I presume that
> the -E flag isn't honored 100% of the time either.)
>
> But I wouldn't object to a -h sub-option that lists environment vars
> either.
>

I think an option to `-h` for environment variables is also good as that
command can be the generic `-h` output as well without resorting to needing
to run Python code like pydoc to get at more help.
___
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/BSXEPG6ERPYCPPQ6WVAF3NJU5CVFFJ4Y/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: "immortal" objects and how they would help per-interpreter GIL

[Brett Cannon]

On Tue, Dec 14, 2021 at 10:23 AM Eric Snow 
wrote:

> Most of the work toward interpreter isolation and a per-interpreter
> GIL involves moving static global variables to _PyRuntimeState or
> PyInterpreterState (or module state).  Through the effort of quite a
> few people, we've made good progress.  However, many globals still
> remain, with the majority being objects and most of those being static
> strings (e.g. _Py_Identifier), static types (incl. exceptions), and
> singletons.
>
> On top of that, a number of those objects are exposed in the public
> C-API and even in the limited API. :(  Dealing with this specifically
> is probably the trickiest thing I've had to work through in this
> project.
>
> There is one solution that would help both of the above in a nice way:
> "immortal" objects.
>
> The idea of objects that never get deallocated isn't new and has been
> explored here several times.  Not that long ago I tried it out by
> setting the refcount really high.  That worked.  Around the same time
> Eddie Elizondo at Facebook did something similar but modified
> Py_INCREF() and Py_DECREF() to keep the refcount from changing.  Our
> solutions were similar but with different goals in mind.  (Facebook
> wants to avoid copy-on-write in their pre-fork model.)
>
> A while back I concluded that neither approach would work for us.  The
> approach I had taken would have significant cache performance
> penalties in a per-interpreter GIL world.  The approach that modifies
> Py_INCREF() has a significant performance penalty due to the extra
> branch on such a frequent operation.
>
> Recently I've come back to the idea of immortal objects because it's
> much simpler than the alternate (working) solution I found.  So how do
> we get around that performance penalty?  Let's say it makes CPython 5%
> slower.  We have some options:
>
> * live with the full penalty
> * make other changes to reduce the penalty to a more acceptable
> threshold than 5%
> * eliminate the penalty (e.g. claw back 5% elsewhere)
> * abandon all hope
>
> Mark Shannon suggested to me some things we can do.  Also, from a
> recent conversation with Dino Viehland it sounds like Eddie was able
> to reach performance-neutral with a few techniques.  So here are some
> things we can do to reduce or eliminate that penalty:
>
> * reduce refcount operations on high-activity objects (e.g. None, True,
> False)
> * reduce refcount operations in general
> * walk the heap at the end of runtime initialization and mark all
> objects as immortal
> * mark all global objects as immortal (statics or in _PyRuntimeState;
> for PyInterpreterState not needed)
>
> What do you think?  Does this sound realistic?  Are there additional
> things we can do to counter that penalty?
>

There's also the concern of memory usage if these immortal objects are
never collected.

But *which *objects are immortal? You only listed None, True, and False.
Otherwise assume/remember I'm management and provide a list and/or link of
what would get marked as immortal so we can have an idea of the memory
impact.
___
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/XSN7EFFQHGG4PS4JVXRXT7Q626ZGIKHF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: subinterpreters and their possible impact on large extension projects

[Brett Cannon]

On Tue, Dec 14, 2021 at 9:41 AM Eric Snow 
wrote:

> One of the open questions relative to subinterpreters is: how to
> reduce the amount of work required for extension modules to support
> them?  Thanks to Petr Viktorin for a lot of work he's done in this
> area (e.g. PEP 489)!  Extensions also have the option to opt out of
> subinterpreter support.
>
> However, that's only one part of the story.  A while back Nathaniel
> expressed concerns with how making subinterpreters more accessible
> will have a negative side effect affecting projects that publish large
> extensions, e.g. numpy.  Not all extensions support subinterpreters
> due to global state (incl. in library dependencies).  The amount of
> work to get there may be large.  As subinterpreters increase in usage
> in the community, so will demand increase for subinterpreter support
> in those extensions.  Consequently, such projects be pressured to do
> the extra work (which is made even more stressful by the short-handed
> nature of most open source projects) .
>
> So we (the core devs) would effectively be requiring those extensions
> to support subinterpreters, regardless of letting them opt out.  This
> situation has been weighing heavily on my mind since Nathaniel brought
> this up.  Here are some ideas I've had or heard of about what we could
> do to help:
>
> * add a page to the C-API documentation about how to support
> subinterpreters
> * identify the extensions most likely to be impacted and offer to help
> * add more helpers to the C-API to make adding subinterpreter support
> less painful
> * fall back to loading the extension in its own namespace (e.g. use
> ldm_open())
> * fall back to copying the extension's file and loading from the copied
> file
> * ...
>
>  I'd appreciate your thoughts on what we can do to help.  Thanks!
>

What *are* the requirements put upon an extension in order to support
subinterpreters? you hint at global state at the C level, but nothing else
is mentioned. Is that it?
___
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/S4QV6SYRGEN7IZZX6YBLS3DQRNLRGCKH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] PEP template file now available

[Brett Cannon]

I just pushed an update to PEP 12 which includes a complete PEP template
file.

You can see the file at
https://github.com/python/peps/blob/main/pep-0012/pep-.rst and it is
also embedded in PEP 12 at https://python.github.io/peps/pep-0012/#template
(it will hit the official URL eventually).
___
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/I5V2ZHQMQIHAW7HR4JNIA7JJKPORJBSM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Expectations of typing (was: The current state of typing PEPs)

[Brett Cannon]

On Wed, Dec 1, 2021 at 10:40 PM Christopher Barker 
wrote:

> I know this isn't really the place for this conversation, but:
>
>
>> which is what `os.PathLike` represents, hence why `str` isn't covered by
>> it);
>>
>
> wait, what? It seems so clear to me that "PathLike" (as a type specifier)
> would mean: anything that can be passed into os.fspath to give me a path.
> (or, of course to the stdlib functions that take paths)
>

That is not what the docs say:
https://docs.python.org/3/library/os.html#os.PathLike. And as the creator
of that ABC it's very much on purpose (see
https://www.python.org/dev/peps/pep-0519/ for details).


> Isn't the entire purpose of os.fspath that you can write code like:
>
> def fun(some_kind_of_path):
>some_kind_of_path = os.fspath(some_kind_of_path)
>
>(or just pass it to a function you takes PathLIke)
>
> and go on your merry way -- e.g. duck typing, baby!
>

Depends on what "your merry way" is. As the docs say, os.fspath() is about
getting the file system representation. That's not something to directly
manipulate in a pathlib world unless you're using os.path to manipulate
that string encoding (but which PEP 519 was specifically created to avoid
such encoding headaches):
https://docs.python.org/3/library/os.html#os.fspath .


>
> Is there really no way to annotate that simply now?
>

Once again, depends on what "simply" means to you. The examples I gave I
don't find complicated, especially when we are talking about APIs that are
trying to accept a broad set of types to convert into a single type. If you
want to create a type variable that represents anything that is valid to
`os.fspath()` or `pathlib.Path` to avoid typing out 2 or 4 types, then that
can be considered for inclusion in the stdlib somewhere.

But as I said previously, in my code I just take pathlib.Path or
pathlib.PurePath and I'm done as I don't want to be dealing with encoded
file paths and instead with objects that represent file paths.


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

[Python-Dev] Re: Expectations of typing (was: The current state of typing PEPs)

[Brett Cannon]

On Tue, Nov 30, 2021 at 1:34 PM Paul Moore  wrote:

> On Tue, 30 Nov 2021 at 19:07, Brett Cannon  wrote:
> >
> > On Tue, Nov 30, 2021 at 9:09 AM Steven D'Aprano 
> wrote:
> >>
> >> On Tue, Nov 30, 2021 at 02:30:18PM +, Paul Moore wrote:
> >>
> >> > And to be clear, it's often very non-obvious how to annotate something
> >> > - in https://github.com/pfmoore/editables I basically gave up because
> >> > I couldn't work out how to write a maintainable annotation for an
> >> > argument that is "a Path, or something that can be passed to the Path
> >> > constructor to create a Path" (it's essentially impossible without
> >> > copy/pasting the argument annotation for the Path constructor).
> >
> > You're after
> https://docs.python.org/3/library/os.html?highlight=pathlike#os.PathLike:
> `str | PathLike[str]` (if you're only accepting string paths).
>
> Well, it's not really. What I'm after, as I stated, is "anything that
> can be passed to the Path constructor". Yes, str | PathLike[str] is
> probably close enough (although why is it OK for me to prohibit bytes
> paths?)


It's your code; do what you want.  If you want to accept bytes, then you
can accept bytes. I personally just don't care about the bytes edge case,
so I leave it out. Plus I don't think pathlib supports bytes paths to begin
with, so if you are after just the pathlib.Path case then you don't want
bytes unless you're going to handle the decoding.

But if you want bytes then you're after
https://github.com/python/typeshed/blob/8542b3518a36313af57b13227996168e592fe868/stdlib/_typeshed/__init__.pyi#L84
which is what `open()` takes (plus ints): `str | bytes | os.PathLike[str] |
os.PathLike[bytes]`.


> but that's what I mean about copying the Path constructor's
> annotations. If Path changes, I have to change my code.
>

Yep. You are writing down your expectations of what is acceptable to pass
in and you're choosing to be very flexible, and so you have to write down
more. I don't think anyone is claiming that typing your code takes no
effort.

But practically speaking the constructor to pathlib.Path isn't going to
change.


>
> This is a very common idiom:
>
> def f(p: ???):
> p = Path(p)
> ...
>
> Why isn't it correspondingly straightforward to annotate?
>

If we added an object to pathlib that represented the type annotation for
the constructor of pathlib then it wouldn't be. It's probably not an
unreasonable idea since this idiom is common enough, I just don't know if
anyone has bothered to suggest it for the module.


>
> If PathLike[str] included str, then it would be a lot easier. It's not
> at all obvious to me why it doesn't (well, that's not entirely true -
> it's because PathLike is an ABC, not a protocol, and it's not intended
> to define "the type of objects that the Path constructor takes"). It
> would still not be documented anywhere, though.
>

You're essentially wrapping the constructor to `pathlib.Path` as broadly as
possible, which means you want types as broad as possible while still being
accurate. You could also tell users, "give me pathlib.Path objects" and
your troubles go away or "an object that implements the `__fspath__`
protocol" (which is what `os.PathLike` represents, hence why `str` isn't
covered by it); it all depends on what sort of assumptions you want to be
able to make about what you're given. But because you're wanting to accept
multiple types to support both the "old" way of string paths and the "new"
way of `__fspath__` you then need to put the work in to accept those types.

Personally, I treat string paths vs pathlib object paths like encoding and
decoding strings; get it converted immediately at the boundary of your code
and then just assume pathlib everywhere else. Pathlib was added in Python
3.4 and is well-known enough at this point that I don't worry about people
not being aware of it, so I let users do the glue from any string paths
they get to my APIs.

But to be clear, path representations != pathlib.Path type parameters !=
`__fspath__` protocol; there's subtlety here regardless of the types.


>
> >> I thought that type inference was supposed to solve that sort of
> >> problem? If the typechecker can see that an argument is passed to the
> >> Path constructor, it should be able to infer that it must be the same
> >> types as accepted by Path.
> >
> > I would change that "should" to "may". Python's dynamism makes
> inferencing really hard.
>
> That's fair. That's why I think it should be straightforward for the
> user to explicitly say "this argument should accept the same types as
> pathlib.Path does". If inference can't do

[Python-Dev] Expectations of typing (was: The current state of typing PEPs)

[Brett Cannon]

On Tue, Nov 30, 2021 at 9:09 AM Steven D'Aprano  wrote:

> On Tue, Nov 30, 2021 at 02:30:18PM +, Paul Moore wrote:
>
> > And to be clear, it's often very non-obvious how to annotate something
> > - in https://github.com/pfmoore/editables I basically gave up because
> > I couldn't work out how to write a maintainable annotation for an
> > argument that is "a Path, or something that can be passed to the Path
> > constructor to create a Path" (it's essentially impossible without
> > copy/pasting the argument annotation for the Path constructor).
>

You're after
https://docs.python.org/3/library/os.html?highlight=pathlike#os.PathLike:
`str | PathLike[str]` (if you're only accepting string paths).


>
> I thought that type inference was supposed to solve that sort of
> problem? If the typechecker can see that an argument is passed to the
> Path constructor, it should be able to infer that it must be the same
> types as accepted by Path.
>

I would change that "should" to "may". Python's dynamism makes inferencing
really hard.


>
> Aside: I'm a little disappointed in the way the typing ecosystem has
> developed. What I understood was that we'd get type inference like ML or
> Haskell use, so we wouldn't need to annotate *everything*, only the bits
> needed to resolve ambiguity. But what we seem to have got is typing like
> C, Pascal and Java, except gradual. Am I being unreasonable to be
> disappointed? I'm not a heavy mypy user, I just dabble with it
> occasionally, so maybe I've missed something.
>

It really depends on the code base. Type checkers can make guesses based on
the code they have available to them, but that only works if the usage is
really clear and the dynamic nature of the code doesn't make things murky.
For instance, look at open() and how whether you opened a file with `b` or
not influences whether the object's methods return strings or bytes. What
would you expect to be inferred in that case if you didn't annotate open()
with overrides to specify how its arguments influence the returned object?

It also depends on how lenient your type checker is willing to be. Compiled
languages get to know all potential inputs and outputs of a function
upfront, while Python it's a guess based on what you happen to have
installed since you can always just `importlib.import_module()` anything at
any time. But since type checkers typically prefer false-positives over
false-negatives for correctness, it means having to clarify more code.


>
>
>
> > Anyway, we're *way* off topic now, and I doubt there's much that the
> > SC or python-dev can do to change the community view on typing,
> > anyway.
>
> Heh. We could update PEP 8 to ban type annotations, then watch as the
> people who over-zealously apply PEP 8 to everything AND over-zealously
> insist on adding type annotations to everything have their heads
> explode.
>
>
> --
> 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/Y6GOWIZV5JCOG5TP4ZZ4SVLXL4BGDJTI/
> 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/PTIX4SV7OECBKAGXPAOHSGVPMZNN47B4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Please be careful about changing PEPs post-submission to the SC

[Brett Cannon]

On Thu, Nov 18, 2021 at 2:25 PM Guido van Rossum  wrote:

> I know PEP 646 was one of these.
>

I purposefully didn't "out" anyone, but yes. 


> In our defense, we *did* notify the SC that there was a pending issue (
> https://github.com/python/steering-council/issues/59#issuecomment-951728233),
> although at the time we didn't anticipate it to become such a contentious
> discussion between the PEP authors.
>

You definitely did, but I know I had personally assumed it was already
resolved and committed based on the wording being past tense and the change
being classified as small.


> (Though, while contentious, it's still a minor edge case in the PEP, and I
> don't think it would affect the SC's position which way we eventually end
> up going.)
>

Yeah, probably not a big deal in the end.


>
> I'm guessing that the recommended approach in such a case is just to close
> the SC issue and reopen it once the PEP is updated?
>

Yeah, I think so. Just saying something like, "closing this for now as we
have discovered something that we need to resolve first; will re-open and
leave a comment when we are ready again" is helpful to let us know to
simply halt thinking and discussing the PEP.


>
> On Thu, Nov 18, 2021 at 12:04 PM Brett Cannon  wrote:
>
>> This is a personal plea (i.e. not coming from the SC at all), but in the
>> last month we have had PEPs changed twice post-submission to the SC. That's
>> a big time sink as we take multiple meetings to discuss a PEP and having
>> things change underneath us causes us to have to re-evaluate our
>> discussions (and I know I pretty much start thinking about PEPs once they
>> are submitted, whether we are actively discussing them or not and I'm
>> probably not the only SC member who does this).
>>
>> I know no one did this maliciously or anything, but since it's happened
>> twice now I just want to ask people be cognizant of this. Please reach out
>> to the SC if you want to make a change so we can discuss whether we think
>> it will help/hurt the PEP, etc. and we are also not taken off-guard by
>> things shifting (assume we don't monitor the commits and PRs to the peps
>> repo, so unless you explicitly say, "hold on", we won't realize discussions
>> are ongoing in a PR or anything). If that means withdrawing your PEP for
>> consideration for a while that's totally fine and it won't hurt your
>> chances of acceptance once you're at a stable state with your PEP.
>>
>> Once again, this is a personal ask and no one is mad at anyone. I'm just
>> asking people be very clear in communicating with us when they want to make
>> a change to a PEP or they have suddenly have an open issue they are still
>> discussing after they open an issue in the steering-council repo for us to
>> review a PEP and need us to stop considering their PEP for a while.
>> ___
>> 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/ZLC3H2XLEYJLFV3TRQ2EWRKRGZZ7DRMC/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
>
> --
> --Guido van Rossum (python.org/~guido)
> *Pronouns: he/him **(why is my pronoun here?)*
> <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
>
___
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/WTRRNNSJXDCIJ6U2UBOSJHWSE3GFQHOB/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Please be careful about changing PEPs post-submission to the SC

[Brett Cannon]

This is a personal plea (i.e. not coming from the SC at all), but in the
last month we have had PEPs changed twice post-submission to the SC. That's
a big time sink as we take multiple meetings to discuss a PEP and having
things change underneath us causes us to have to re-evaluate our
discussions (and I know I pretty much start thinking about PEPs once they
are submitted, whether we are actively discussing them or not and I'm
probably not the only SC member who does this).

I know no one did this maliciously or anything, but since it's happened
twice now I just want to ask people be cognizant of this. Please reach out
to the SC if you want to make a change so we can discuss whether we think
it will help/hurt the PEP, etc. and we are also not taken off-guard by
things shifting (assume we don't monitor the commits and PRs to the peps
repo, so unless you explicitly say, "hold on", we won't realize discussions
are ongoing in a PR or anything). If that means withdrawing your PEP for
consideration for a while that's totally fine and it won't hurt your
chances of acceptance once you're at a stable state with your PEP.

Once again, this is a personal ask and no one is mad at anyone. I'm just
asking people be very clear in communicating with us when they want to make
a change to a PEP or they have suddenly have an open issue they are still
discussing after they open an issue in the steering-council repo for us to
review a PEP and need us to stop considering their PEP for a while.
___
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/ZLC3H2XLEYJLFV3TRQ2EWRKRGZZ7DRMC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: SC Acceptance: PEP 646 -- Variadic Generics

[Brett Cannon]

I put the PEP back on our agenda to discuss this.

On Wed, Nov 17, 2021 at 2:40 PM Guido van Rossum  wrote:

> Hi Barry,
>
> That's fantastic news!
>
> Somewhat embarrassingly, on typing-sig we're still discussing one or two
> final tweaks. In particular, the PEP as accepted forbids a certain
> construct (passing a tuple of indefinite length to a function using `*args:
> *Ts`) that after all we may actually want to allow. This would affect
> static type checkers only, there's no change in the grammar or runtime
> associated with lifting this restriction. See
> https://github.com/python/peps/pull/2125
>
> I presume the SC is okay with that?
>
> --Guido
>
> On Wed, Nov 17, 2021 at 2:15 PM Barry Warsaw  wrote:
>
>> Hello Mark, Matthew, Pradeep, Vincent, and Guido,
>>
>> The Python Steering Council discussed the latest version of PEP 646
>> (Variadic Generics) at our last meeting, and have unanimously decided to
>> accept the PEP.  Congratulations!
>>
>> We want to specifically mention that we appreciate the way you called out
>> the Python grammar changes required by the typing features you proposed.
>> As we’ve said before, the Steering Council strongly believes that the
>> typing language and the “general” Python programming language should remain
>> aligned, so the implications of syntax change proposed in the PEP for
>> typing needed to be addressed for non-typed Python as well.  The PEP
>> explains this change well, and does a good job of justifying the semantics
>> and usefulness of the change for non-type related purposes.
>>
>> Please feel free to change the PEP status to Accepted, and to merge your
>> changes to Python 3.11 at your convenience.
>>
>> With our appreciation,
>> -Barry (on behalf of the Python Steering Council)
>>
>>
>
> --
> --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/YBSS4FJ474TJ23XOUSFI5E6N7GAXB3T5/
> 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/VRB3NJKZ4ZDKXY64EHCICVX4FMLB5BDV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Do we need to remove everything that's deprecated?

[Brett Cannon]

On Tue, Nov 16, 2021 at 4:46 AM Petr Viktorin  wrote:

> On 16. 11. 21 1:11, Brett Cannon wrote:
> >
> >
> > On Sun, Nov 14, 2021 at 3:01 PM Victor Stinner  > <mailto:vstin...@python.org>> wrote:
> >
> > On Sun, Nov 14, 2021 at 6:34 PM Eric V. Smith  > <mailto:e...@trueblade.com>> wrote:
> >  > On second thought, I guess the existing policy already does this.
> > Maybe
> >  > we should make it more than 2 versions for deprecations? I've
> written
> >  > libraries where I support 4 or 5 released versions. Although
> maybe I
> >  > should just trim that back.
> >
> > If I understood correctly, the problem is more for how long is the
> new
> > way available?
> >
> >
> > I think Eric was suggesting more along the lines of PEP 387 saying that
> > deprecations should last as long as there is a supported version of
> > Python that *lacks* the deprecation. So for something that's deprecated
> > in 3.10, we wouldn't remove it until 3.10 is the oldest Python version
> > we support. That would be October 2025 when Python 3.9 reaches EOL and
> > Python 3.13 comes out as at that point you could safely rely on the
> > non-deprecated solution across all supported Python versions (or if you
> > want a full year of overlap, October 2026 and Python 3.14).
> >
> > I think the key point with that approach is if you wanted to maximize
> > your support across supported versions, this would mean there wouldn't
> > be transition code except when the SC approves of a shorter deprecation.
> > So a project would simply rely on the deprecated approach until they
> > started work towards Python 3.13, at which point they drop support for
> > the deprecated approach and cleanly switch over to the new approach as
> > all versions of Python at that point will support the new approach as
> well.
>
> That sounds like a reasonable minimum for minor cleanups -- breakage
> that doesn't block improvements.
>

> The current 'two years' minimum (and SC exceptions) is, IMO, appropriate
> for changes that do block improvements -- e.g. if removing old Unicode
> APIs allows reorganizing the internals to get a x% speedup, it should be
> removed after the 2-years of warnings (*if* the speedup is also made in
> that version -- otherwise the removal can be postponed).
> Even better if there's some alternate API for the affected use cases
> which works on all supported Python versions.
>

If enough people come forward supporting this idea then you could propose
to the SC that PEP 387 get updated with this guidance.

-Brett


>
>
>
> And then there are truly trivial removals like the "failUnless" or
> "SafeConfigParser" aliases. I don't see a good reason to remove those --
> they could stay deprecated forever. The only danger that API posed to
> users is that it might be removed in the future (and that will break
> their code), or that they'll get a warning or a linter nag.
>

If deprecations ever become permanent, then there will have to be a
cleaning of the stdlib first before we lock the team into this level of
support contract.
___
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/D47IPVKOFREETNKNDWDDJY5NWBGQAN66/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: portable venv

[Brett Cannon]

On Tue, Nov 16, 2021 at 8:08 AM Tamás Ozsváth  wrote:

> Hi All,
> I tried to compose a protable virtualEnvironment using Python. I aready
> found a solution which already works but still not stable.
> So by creating venv in conventional way, I additionally copy the Python
> executable and related dlls, zip file, ._pth file to the root of venv
> folder.
> The weak point of this solution is the pyvenv.cfg file and the value of
> the home variable!
> It can accept both absolute or relative paths, it is fine and good as it
> is. Using this solution (copiing Python executable and other files) and
> changing home path to .\venv(as relative) I am able to fetch packages by
> using pip install.
> But not all the packages! Eg pyinstaller changes the scope of calling
> Python.exe thatswhy not possible to fetch it. (Not found:
> .\venv\python.exe)
>
> I assume during parsing of home path inside pyenv.cfg by converting it to
> absolute path(if a relative path was given) behind the scene, I and anybody
> else would have a fully functionally portable virtualenv solution!
>

Do note that virtual environments do not work the same on all platforms.
For instance, on OSs that support symlinks (by default), the venv is not
self-contained by copying binaries in order to make their creation faster.
Virtual environments are also specifically designed and meant to be cheap
and disposable rather than relocatable/reusable in multiple situations.

If you want to make moving environments easier, then I would look at PEP
582: https://www.python.org/dev/peps/pep-0582/ .
___
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/G2GDWBMH6VPSJFPJOG7CAGIBPCVFUHSH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Remove asyncore, asynchat and smtpd modules

[Brett Cannon]

On Tue, Nov 16, 2021 at 3:05 AM Petr Viktorin  wrote:

> On 12. 11. 21 13:09, Victor Stinner wrote:
> >>> It was decided to start deprecating the asyncore, asynchat and smtpd
> >>> modules in Python 3.6 released in 2016, 5 years ago. Python 3.10 emits
> >>> DeprecationWarning.
> >>
> >> Wait, only Python 3.10?
> >> According to the policy, the warning should be there for *at least* two
> >> releases. (That's a minimum, for removing entire modules it might make
> >> sense to give people even more time.)
> >
> > The PEP 387 says "Similarly a feature cannot be removed without notice
> > between any two consecutive releases."
> >
> > It is the case here. The 3 modules are marked as deprecated for 4
> > releases in the documentation: Python 3.6, 3.7, 3.9 and 3.10. Example:
> > https://docs.python.org/3.6/library/asyncore.html
>
> PEP 387 also contains a detailed process for making incompatible
> changes, which calls for warnings to appear in at least two releases.
>
> Do you think the process section can be ignored? We should remove it
> from the PEP if that's the case.
>

I don't think it should be ignored and the modules got yanked prematurely.
A request can be made to the SC, though, to expedite the removal with only
one release raising an exception.
___
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/WRYNHCXYNBV2CMF6UUB6BLOSVN24HHOI/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Remove asyncore, asynchat and smtpd modules

[Brett Cannon]

On Fri, Nov 12, 2021 at 4:16 AM Victor Stinner  wrote:

> > > It was decided to start deprecating the asyncore, asynchat and smtpd
> > > modules in Python 3.6 released in 2016, 5 years ago. Python 3.10 emits
> > > DeprecationWarning.
> >
> > Wait, only Python 3.10?
> > According to the policy, the warning should be there for *at least* two
> > releases. (That's a minimum, for removing entire modules it might make
> > sense to give people even more time.)
>
> The PEP 387 says "Similarly a feature cannot be removed without notice
> between any two consecutive releases."
>
> It is the case here. The 3 modules are marked as deprecated for 4
> releases in the documentation: Python 3.6, 3.7, 3.9 and 3.10. Example:
> https://docs.python.org/3.6/library/asyncore.html
>

But have they been raising exceptions for two releases?
___
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/6VQPRSUR3XAOKQBGEIT6XA2XST6JDDFT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Do we need to remove everything that's deprecated?

[Brett Cannon]

On Sun, Nov 14, 2021 at 3:01 PM Victor Stinner  wrote:

> On Sun, Nov 14, 2021 at 6:34 PM Eric V. Smith  wrote:
> > On second thought, I guess the existing policy already does this. Maybe
> > we should make it more than 2 versions for deprecations? I've written
> > libraries where I support 4 or 5 released versions. Although maybe I
> > should just trim that back.
>
> If I understood correctly, the problem is more for how long is the new
> way available?
>

I think Eric was suggesting more along the lines of PEP 387 saying that
deprecations should last as long as there is a supported version of Python
that *lacks* the deprecation. So for something that's deprecated in 3.10,
we wouldn't remove it until 3.10 is the oldest Python version we support.
That would be October 2025 when Python 3.9 reaches EOL and Python 3.13
comes out as at that point you could safely rely on the non-deprecated
solution across all supported Python versions (or if you want a full year
of overlap, October 2026 and Python 3.14).

I think the key point with that approach is if you wanted to maximize your
support across supported versions, this would mean there wouldn't be
transition code except when the SC approves of a shorter deprecation. So a
project would simply rely on the deprecated approach until they started
work towards Python 3.13, at which point they drop support for the
deprecated approach and cleanly switch over to the new approach as all
versions of Python at that point will support the new approach as well.

-Brett


>
> For example, if the new way is introduced in Python 3.6, the old way
> is deprecated is Python 3.8, can we remove the old way in Python 3.10?
> It means that the new way is available in 4 versions (3.6, 3.7, 3.8,
> 3.9), before the old way is removed. It means that it's possible to
> have a single code base (no test on the Python version and no feature
> test) for Python 3.6 and newer.
>
> More concrete examples:
>
> * the "U" open() flag was deprecated since Python 3.0, removed in
> Python 3.11: the flag was ignored since Python 3.0, code without "U"
> works on Python 3.0 and newer
>
> * collections.abc.MutableMapping exists since Python 3.3:
> collections.MutableMapping was deprecated in Python 3.3, removed in
> Python 3.10. Using collections.abc.MutableMapping works on Python 3.3
> and newer.
>
> * unittest: failIf() alias, deprecated since Python 2.7, was removed
> in Python 3.11: assertFalse() always worked.
>
> For these 3 changes, it's possible to keep support up to Python 3.3.
> Up to Python 3.0 if you add "try/except ImportError" for
> collections.abc.
>
> IMO it would help to have a six-like module to write code for the
> latest Python version, and keep support for old Python versions. For
> example, have hacks to be able to use collections.abc.MutableMapping
> on Python 3.2 and older (extreme example, who still care about Python
> older than 3.5 in 2021?).
>
> I wrote something like that for the C API, provide *new* C API
> functions to *old* Python versions:
> https://github.com/pythoncapi/pythoncapi_compat
>
> 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/WD6NLGVI5AXB3POKQHOUKZ5WUR2HBLV2/
> 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/QPWE4RNBYHN4XCDYNJ2APEQQWQJPEQNO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Proposal: Allow non-default after default arguments

[Brett Cannon]

On Tue, Nov 9, 2021 at 6:31 AM Steven D'Aprano  wrote:

> By the way, this discussion is probably better suited to the
> Python-Ideas mailing list. But since we're here...
>
> On Tue, Nov 09, 2021 at 11:37:40AM +0100, Sebastian Rittau wrote:
>
> > >>To me, the "natural" solution looks like this:
> > >>
> > >>def foo(x=None, y): ...
> [...]
>
> Chris Angelico asked:
> > >What would this mean, though:
> > >
> > >foo(2)
> > >
> > >Is that legal?
> >
> > No. This would be equal to foo(x=2) (same as now), meaning the required
> > argument "y" is missing.
>
> That's an odd interpretation. What you described earlier is very similar
> to the calling convention of range, which conceptually looks like this:
>
> range([start=0,] end, [step=1])
>
> With your example of "foo(x=None, y)" I would expect foo(2) to mean that
> x gets the default and y gets the passed in argument 2, similar to the
> way that range(2) works.
>

But we all understand range() because we have been using it for years and
there's a mathematical understanding of what it represents. If you were
taught "range(2, 5) returns the numbers 2 through 5, exclusive" and then
were asked, "what does range(2) do?", I'm not sure what a beginner would
assume, but thinking it goes from 5 to infinity wouldn't be an unreasonable
leap to make.

An API like range() is also not pervasive, so it can be supported without
any special parameter support and not feel icky; `def range(x, y=None, z=1,
/)` covers its unique situation.

But for me, the key issue is simply remembering what one argument means
compares to two. foo(1) versus foo(1, 2) is not self-documenting whether
that `1` in the first call would get bound to the same thing as the `1` in
the second call. I would need to have quite the understanding of the API to
know that without having to look something up in the docs. But the current
semantics don't have this issue, and `1` means the same thing in both
scenarios (unless you're doing something really weird like range(), which
is something I wouldn't want to encourage).
___
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/I52V5QLMNR5OUGRUEPX4S6WDCYUF3X2L/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Oh look, I've been subscribed to python/issues-test-2 notifications again

[Brett Cannon]

What notification? (I fully admit I may not have gotten one due to some
team I'm in, but I have no such notification if it happened recently.)

On Thu, Nov 4, 2021 at 12:16 AM Larry Hastings  wrote:

>
> I guess this is part of the migration from bpo to GitHub issues?  Maybe
> the initial work could be done in a private repo, to cut down on the
> spurious email notifications to literally everybody subscribed to cpython?
> Which is a lot of people.
>
>
> */arry*
> ___
> 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/H5KW6GRHIF2VWOGNRH5367WB3K2GPARO/
> 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/OJYGOHGS27CUY7KWHE5PEC2CKYH6M5PI/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 663:

[Brett Cannon]

Rendered versions can be found at the following links:

https://www.python.org/dev/peps/pep-0663/
https://python.github.io/peps/pep-0663/

On Tue, Nov 2, 2021 at 8:41 PM Ethan Furman  wrote:

> See the latest changes, which are mostly a (hopefully) improved abstract,
> better tables, and some slight rewordings.
>
> Feedback welcome!
>
> ---
>
> PEP: 663
> Title: Standardizing Enum str(), repr(), and format() behaviors
> Version: $Revision$
> Last-Modified: $Date$
> Author: Ethan Furman 
> Discussions-To: python-dev@python.org
> Status: Draft
> Type: Informational
> Content-Type: text/x-rst
> Created: 23-Feb-2013
> Python-Version: 3.11
> Post-History: 20-Jul-2021, 02-Nov-2021
> Resolution:
>
>
> Abstract
> 
>
> Update the ``repr()``, ``str()``, and ``format()`` of the various Enum
> types
> to better match their intended purpose.  For example, ``IntEnum`` will have
> its ``str()`` change to match its ``format()``, while a user-mixed int-enum
> will have its ``format()`` match its ``str()``.  In all cases, an enum's
> ``str()`` and ``format()`` will be the same (unless the user overrides
> ``format()``).
>
> Add a global enum decorator which changes the ``str()`` and ``repr()``
> (and
> ``format()``) of the decorated enum to be a valid global reference: i.e.
> ``re.IGNORECASE`` instead of .
>
>
> Motivation
> ==
>
> Having the ``str()`` of ``IntEnum`` and ``IntFlag`` not be the value causes
> bugs and extra work when replacing existing constants.
>
> Having the ``str()`` and ``format()`` of an enum member be different can be
> confusing.
>
> The addition of ``StrEnum`` with its requirement to have its ``str()`` be
> its
> ``value`` is inconsistent with other provided Enum's ``str``.
>
> The iteration of ``Flag`` members, which directly affects their
> ``repr()``, is
> inelegant at best, and buggy at worst.
>
>
> Rationale
> =
>
> Enums are becoming more common in the standard library; being able to
> recognize
> enum members by their ``repr()``, and having that ``repr()`` be easy to
> parse, is
> useful and can save time and effort in understanding and debugging code.
>
> However, the enums with mixed-in data types (``IntEnum``, ``IntFlag``, and
> the new
> ``StrEnum``) need to be more backwards compatible with the constants they
> are
> replacing -- specifically, ``str(replacement_enum_member) ==
> str(original_constant)``
> should be true (and the same for ``format()``).
>
> IntEnum, IntFlag, and StrEnum should be as close to a drop-in replacement
> of
> existing integer and string constants as is possible.  Towards that goal,
> the
> ``str()`` output of each should be its inherent value; e.g. if ``Color``
> is an
> ``IntEnum``::
>
>  >>> Color.RED
>  
>  >>> str(Color.RED)
>  '1'
>  >>> format(Color.RED)
>  '1'
>
> Note that ``format()`` already produces the correct output, only ``str()``
> needs
> updating.
>
> As much as possible, the ``str()``, ``repr()``, and ``format()`` of enum
> members
> should be standardized across the standard library.  However, up to Python
> 3.10
> several enums in the standard library have a custom ``str()`` and/or
> ``repr()``.
>
> The ``repr()`` of Flag currently includes aliases, which it should not;
> fixing that
> will, of course, already change its ``repr()`` in certain cases.
>
>
> Specification
> =
>
> There a three broad categories of enum usage:
>
> - simple: ``Enum`` or ``Flag``
>a new enum class is created with no data type mixins
>
> - drop-in replacement: ``IntEnum``, ``IntFlag``, ``StrEnum``
>a new enum class is created which also subclasses ``int`` or ``str``
> and uses
>``int.__str__`` or ``str.__str__``
>
> - user-mixed enums and flags
>the user creates their own integer-, float-, str-, whatever-enums
> instead of
>using enum.IntEnum, etc.
>
> There are also two styles:
>
> - normal: the enumeration members remain in their classes and are accessed
> as
>``classname.membername``, and the class name shows in their ``repr()``
> and
>``str()`` (where appropriate)
>
> - global: the enumeration members are copied into their module's global
>namespace, and their module name shows in their ``repr()`` and ``str()``
>(where appropriate)
>
> Some sample enums::
>
>  # module: tools.py
>
>  class Hue(Enum):  # or IntEnum
>  LIGHT = -1
>  NORMAL = 0
>  DARK = +1
>
>  class Color(Flag):  # or IntFlag
>  RED = 1
>  GREEN = 2
>  BLUE = 4
>
>  class Grey(int, Enum):  # or (int, Flag)
> BLACK = 0
> WHITE = 1
>
> Using the above enumerations, the following two tables show the old and new
> output (blank cells indicate no change):
>
>
> +++-++---+
> | style  | category   | enum repr() | enum str() | enum
> format() |
>
> 

[Python-Dev] Re: Should the definition of an "(async) iterator" include __iter__?

[Brett Cannon]

FYI I opened https://github.com/python/cpython/pull/29170 to loosen/correct the 
definition of "iterator", but I got push-back on the PR and this thread never 
reached a clear conclusion. As such I'll ask the SC to make a call.
___
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/EKPXVWPBUS4AGPDTBEEVV7VNMMDUZ4LW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: The Default for python -X frozen_modules.

[Brett Cannon]

On Mon, Sep 27, 2021 at 9:54 AM Eric Snow 
wrote:

> We've frozen most of the stdlib modules imported during "python -c
> pass" [1][2], to make startup a bit faster.  Import of those modules
> is controlled by "-X frozen_modules=[on|off]".  Currently it defaults
> to "off" but we'd like to default to "on".  The blocker is the impact
> on contributors.  I expect many will make changes to a stdlib module
> and then puzzle over why those changes aren't getting used.  That's an
> annoyance we can avoid, which is the point of this thread.
>
> Possible solutions:
>
> 1. always default to "on" (the annoyance for contributors isn't big
> enough?)
> 2. default to "on" if it's a PGO build (and "off" otherwise)
> 3. default to "on" unless running from the source tree
>
> Thoughts?
>

What about opting out when `--with-pydebug` is used? I'm not sure how many
people actively develop in a non-debug build other than testing something,
but at that point I would be having to run `make` probably anyway for
whatever I'm mucking with if it's *that* influenced by a debug build.
___
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/PYX65WVG5ICXEBIY5ZDLDFAJHDU56HLA/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Worried about Python release schedule and lack of stable C-API

[Brett Cannon]

On Sun, Sep 26, 2021 at 3:51 AM Phil Thompson via Python-Dev <
python-dev@python.org> wrote:

> On 26/09/2021 05:21, Steven D'Aprano wrote:
>
> [snip]
>


> > These are not rhetorical questions, I genuinely do not know. I *think*
> > that there was an attempt to make a stable C API back in 3.2 days:
> >
> > https://www.python.org/dev/peps/pep-0384/
> >
> > but I don't know what difference it has made to extension writers in
> > practice. From your description, it sounds like perhaps not as big a
> > difference as we would have liked.
> >
> > Maybe extension writers are not using the stable C API? Is that even
> > possible? Please excuse my ignorance.
>
> PyQt has used the stable ABI for many years. The main reason for using
> it is to reduce the number of wheels. The PyQt ecosystem currently
> contains 15 PyPI projects across 4 platforms supporting 5 Python
> versions (including v3.10). Without the stable ABI a new release would
> require 300 wheels. With the stable ABI it is a more manageable 60
> wheels.
>
> However the stable ABI is still a second class citizen as it is still
> not possible (AFAIK) to specify a wheel name that doesn't need to
> explicitly include each supported Python version (rather than a minimum
> stable ABI version).
>

Actually you can do this. The list of compatible wheels for a platform
starts at CPython 3.2 when the stable ABI was introduced and goes forward
to the version of Python you are running. So you can build a wheel file
that targets the oldest version of CPython that you are targeting and its
version of the stable ABI and it is considered forward compatible. See
`python -m pip debug --verbose` for the complete list of wheel tags that
are supported for an interpreter.
___
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/E4EA6GW6N5NREEBM4QOA7GTLBGTGD4AV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: f-strings in the grammar

[Brett Cannon]

On Mon, Sep 20, 2021 at 8:58 AM Thomas Grainger  wrote:

> I don't think the python syntax should be beholden to syntax highlighting
> tools, eventually some syntax feature that PEG enables will require every
> parser or highlighter to switch to a similar or more powerful parse tool
>

But that's not how syntax highlighting works in editors. You typically
don't get to choose the parsing tool used for syntax highlighting, you just
define the grammar using whatever is provided by the editor (which has
always been regexes based on my experience). So there's no way to "require"
every editor out there to switch to a PEG parser or equivalent to support
Python's grammar because that's asking every editor to change how syntax
highlighting is implemented at a lower level.

Having said all that, I think as long as we understand that this is a
side-effect then it's fine; syntax highlighting is usually not tied to
semantics in an editor so it shouldn't be a blocker on this. If people care
they simply won't use the same type of quotes in their code (which I bet is
what most people will do unless Black says otherwise ).

But I also think this means we definitely have to get a parser module for
tools together as this is way more potential breakage than just parentheses
for `with` statements and I don't know if formatting tools can just move to
the AST module at that point. 
___
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/I4POAK22LZW4RNFGFFKQ6BILRLCSQO2I/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Should the definition of an "(async) iterator" include __iter__?

[Brett Cannon]

On Sun, Sep 19, 2021 at 8:15 AM Steve Holden  wrote:

> I understood that _iterables_ are required to have an __iter__ method, not
> iterators.
>
> Therefore, are we simply discussing whether all iterators should be
> iterable?
>

At this point it's more about how to document this.


> At the moment the CPython implementation does't require that AFAIK.
>

Correct. I plan to go through the docs and clarify things. I opened
https://bugs.python.org/issue45250 to track this.


>
> regards
>  Steve
>
> On Tue, Sep 14, 2021 at 8:39 PM Guido van Rossum  wrote:
>
>> My view of this is:
>>
>> A. It's not an iterator if it doesn't define `__next__`.
>>
>> B. It is strongly recommended that iterators also define `__iter__`.
>>
>> In "standards" language, I think (A) is MUST and (B) is merely OUGHT or
>> maybe SHOULD.
>>
>> On Tue, Sep 14, 2021 at 12:30 PM Brett Cannon  wrote:
>>
>>> Over in https://github.com/python/typeshed/issues/6030 I have managed
>>> to kick up a discussion over what exactly an "iterator" is. If you look at
>>> https://docs.python.org/3/library/functions.html#iter you will see the
>>> docs say it "Return[s] an iterator
>>> <https://docs.python.org/3/glossary.html#term-iterator> object." Great,
>>> but you go the glossary definition of "iterator" at
>>> https://docs.python.org/3/glossary.html#term-iterator you will see it
>>> says "[i]terators are required to have an __iter__()
>>> <https://docs.python.org/3/reference/datamodel.html#object.__iter__>
>>> method" which neither `for` nor `iter()` actually enforce.
>>>
>>> Is there something to do here? Do we loosen the definition of "iterator"
>>> to say they *should* define __iter__? Leave it as-is with an
>>> understanding that we know that it's technically inaccurate for iter() but
>>> that we want to encourage people to define __iter__? I'm assuming people
>>> don't want to change `for` and `iter()` to start requiring __iter__ be
>>> defined if we decided to go down the "remove the __aiter__ requirement"
>>> from aiter() last week.
>>>
>>> BTW all of this applies to async iterators 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/3W7TDX5KNVQVGT5CUHBK33M7VNTP25DZ/
>>> Code of Conduct: http://python.org/psf/codeofconduct/
>>>
>>
>>
>> --
>> --Guido van Rossum (python.org/~guido)
>> *Pronouns: he/him **(why is my pronoun here?)*
>> <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
>> ___
>> 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/OICGRBPLXO6WXO4CHTGUK46WIHO7PDUU/
>> 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/KHDMNMW6XEPYOZ5AQ22AN6YTN2POMHQE/
> 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/WHUPQJQAKMKSOR54PCSWQQYYKLJ5ZKZS/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Discussion about how to manage additions/removals to the stdlib

[Brett Cannon]

https://discuss.python.org/t/how-do-we-want-to-manage-additions-removals-to-the-stdlib/10681

This comes from my language summit talk on the stdlib to help clarify some
things about how we manage the stdlib from the perspective of
additions/deletions.

FYI I will be *muting this email thread immediately*, so please participate
on discuss.python.org if you have anything to say (I almost didn't post
here, but I figured I would see if there's any chance people will follow
through on discuss.python.org if directed there and told feedback here will
be ignored).
___
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/KB2CLR6Q2NVSPA2WR4KPP2S4ITOMAHMS/
Code of Conduct: http://python.org/psf/codeofconduct/