[Python-Dev] Re: Retiring this mailing list ?

[Guido van Rossum]

But how would Tim Peters keep himself entertained in his retirement?

Seriously, let’s kill it. I thought it was already deprecated.

--Guido (mobile)


On Mon, Nov 13, 2023 at 02:19 Marc-Andre Lemburg  wrote:

> Hello everyone,
>
> for quite a while now, core discussions have moved to Discourse and
> people are obviously enjoying things there:
>
> https://discuss.python.org/c/core-dev/23
>
> The Discourse mailing list mode works reasonably well, so is a suitable
> replacement for this mailing list.
>
> Posts to this list are now mostly spam, mailer error reports and the
> occasional release postings:
>
> https://mail.python.org/archives/list/python-dev@python.org/latest
> (you can't see much of the spam, since we filter most of it)
>
>
> Question: Should we retire and archive this mailing list ?
> (I'm asking as one of the maintainers of the ML)
>
> Thanks,
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Experts (#1, Nov 13 2023)
>  >>> Python Projects, Coaching and Support ...https://www.egenix.com/
>  >>> Python Product Development ...https://consulting.egenix.com/
> 
>
> ::: We implement business ideas - efficiently in both time and costs :::
>
> eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
>  D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
> Registered at Amtsgericht Duesseldorf: HRB 46611
> https://www.egenix.com/company/contact/
>   https://www.malemburg.com/
>
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/PDRLCB6CNLQAFVGPTLXL5QV6SVQDPCCV/
> 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/ZMDHUGHVBAK3KBY6V4CMPCXIWU6PD5RE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Small lament...

[Guido van Rossum]

A bit late, this reached my inbox:
https://peternorvig.medium.com/new-python-operators-9f31b56ddcc7

On Sat, Apr 1, 2023 at 11:23 AM Skip Montanaro 
wrote:

> Just wanted to throw this out there... I lament the loss of waking up on
> April 1st to see a creative April Fool's Day joke on one or both of these
> lists, often from our FLUFL... Maybe such frivolity still happens, just not in
> the Python ecosystem? I know you can still import "this" or
> "antigravity", but those are now old (both introduced before 2010). When
> was the last time a clever easter egg was introduced or an April Fool's Day
> joke played?
>
> ¯\_(ツ)_/¯
>
> 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/Q62W2Q6R6XMX57WK2CUGEENHMT3C3REF/
> 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/LMMRU7FO72UGZQ3UFRVWFYOKRMBCVEHA/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Guido van Rossum]

[Oscar Benjamin]
> (If you think that there might be a
> performance penalty then you haven't understood the suggestion!)

Then I don't understand the question, and I will refrain from participating
further in this discussion.

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

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

[Guido van Rossum]

Nah, `__prepare__` very much predates stable dicts and that problem was
solved differently.

On Mon, Nov 28, 2022 at 4:46 PM Greg Ewing  wrote:

> On 29/11/22 12:51 pm, Guido van Rossum wrote:
> > "Sets weren't meant to be deterministic" sounds like a remnant of
> > the old philosophy, where we said the same about dicts -- until they
> > became deterministic without slowing down, and then everybody loved it.
>
> I got the impression that there were some internal language reasons
> to want stable dicts, e.g. so that the class dict passed to __prepare__
> preserves the order in which names are assigned in the class body. Are
> there any such use cases for stable sets?
>
> --
> Greg
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/3TEOQMV2UXOKWMHVYA63JLPLAZ2TNX55/
> 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/O7V5XLTAFZZXNTUXT5LD7C75XNGQZFIL/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Guido van Rossum]

To stir up some more fire, I would personally be fine with sets having the
same ordering guarantees as dicts, *IF* it can be done without performance
degradations. So far nobody has come up with a way to ensure that. "Sets
weren't meant to be deterministic" sounds like a remnant of the old
philosophy, where we said the same about dicts -- until they became
deterministic without slowing down, and then everybody loved it.

Regarding hash(None), I think that there is something to be said for making
that stable, and the arguments against it feel like rationalizations for
FUD. We've survived way larger controversies. I also note that hash(()) is
apparently stable.

On Mon, Nov 28, 2022 at 3:16 PM Oscar Benjamin 
wrote:

> On Mon, 28 Nov 2022 at 22:56, Brett Cannon  wrote:
> >
> > On Sun, Nov 27, 2022 at 11:36 AM Yoni Lavi 
> wrote:
> >>
> >> 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.
>
> What does "sets are not meant to be deterministic" even mean?
>
> Mathematically speaking sets are not meant to be ordered in any
> particular way but a computational implementation has to have some
> order and there is no reason to prefer non-deterministic order in
> general. Actually determinism in a computational context is usually a
> very valuable feature. I find it hard to see why non-determinism is
> "by design".
>
> Also it isn't usually possible to sort a list containing None:
>
> In [9]: sorted([None, 1, 2])
> ---
> TypeError Traceback (most recent call last)
>  in 
> > 1 sorted([None, 1, 2])
>
> TypeError: '<' not supported between instances of 'int' and 'NoneType'
>
> 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).
>
> --
> Oscar
> ___
> 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/ILP2ZKVXQIF2ONOWRJCMLNHI3LFUFBD3/
> 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/IGVDQ73A4PTUF42AAEA4AXS45ORUP6PB/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: NEWLINE sentinel behavior in CPython's PEG grammar

[Guido van Rossum]

I wonder if David may be struggling with the rule that a newline is
significant in the grammar unless it appears inside matching
brackets/parentheses/braces? I think that's in the lexer. Similarly,
multiple newlines are collapsed.

On Wed, Oct 26, 2022 at 1:19 PM Pablo Galindo Salgado 
wrote:

> Hi,
>
> As I mentioned, NEWLINE is a token. All uppercase words in the grammar are
> tokens and therefore are produced by the lexer, not the parser. Is not a
> built-in rule. In particular, that token is produced here:
>
>
> https://github.com/python/cpython/blob/6777e09166fc384ea0a4b50202c7b0bd7a23330c/Parser/tokenizer.c#L1773
>
>
> On Wed, 26 Oct 2022 at 20:59, David J W  wrote:
>
>> Pablo,
>> Nl and Newline are tokens but I am interested in NEWLINE's behavior
>> in the Python grammar, note the casing.
>>
>> For example in simple_stmts @
>> https://github.com/python/cpython/blob/main/Grammar/python.gram#L107
>>
>> Is that NEWLINE some sort of built in rule to the grammar?   In my
>> project I am running into problems where the parser crashes any time there
>> is some double like NL & N or Newline & NL but I want to nail down
>> NEWLINE's behavior in CPython's PEG grammar.
>>
>> On Wed, Oct 26, 2022 at 12:51 PM Pablo Galindo Salgado <
>> pablog...@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> I am not sure I understand exactly what you are asking but NEWLINE is a
>>> token, not a parser rule. What decides when NEWLINE is emitted is the lexer
>>> that has nothing to do with PEG. Normally PEG parsers also acts as
>>> tokenizers but the one in cpython does not.
>>>
>>> Also notice that CPython’s parser uses a version of the tokeniser
>>> written in C that doesn’t share code with the exposed version. You will
>>> find that the tokenizer module in the standard library actually behaves
>>> differently regarding what tokens are emitted in new lines and indentations.
>>>
>>> The only way to be sure is check the code unfortunately.
>>>
>>> Hope this helps.
>>>
>>> Regards from rainy London,
>>> Pablo Galindo Salgado
>>>
>>> > On 26 Oct 2022, at 19:12, David J W  wrote:
>>> >
>>> > 
>>> > I am writing a Rust version of Python for fun and I am at the parser
>>> stage of development.
>>> >
>>> > I copied and modified a PEG grammar ruleset from another open source
>>> project and I've already noticed some problems (ex Newline vs NL) with how
>>> they transcribed things.
>>> >
>>> > I am suspecting that CPython's grammar NEWLINE is a builtin rule for
>>> the parser that is something like `(Newline+ | NL+ ) {NOP}` but wanted to
>>> sanity check if that is right before I figure out how to hack in a NEWLINE
>>> rule and update my grammar ruleset.
>>> > ___
>>> > 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/NMCMEDMEBKATYKRNZLX2NDGFOB5UHQ5A/
>>> > 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/5ZV7BZOYHW3DELYIB4GKRWHUNTYW3V4K/
> 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/MD2THJ5BIBDSOB7HVFDPBUNCW76H5N3S/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: How about using modern C++ in development of CPython ?

[Guido van Rossum]

People are free to continue to use python-dev, it just no longer has any
official status, and many core devs and other key people have probably
unsubscribed. I certainly have ignored this discussion here, even though
(our of nostalgia, mostly) I am still subscribed.

--Guido

On Wed, Oct 19, 2022 at 9:11 AM Antoine Pitrou  wrote:

>
> Haven't we migrated to Discourse? This discussion will probably not
> have any effects on this mailing-list.
>
> (yes, not everyone likes Discourse, and I'm skeptical as well, but the
> decision has been made by now)
>
>
> On Mon, 17 Oct 2022 09:13:34 -
> "Denis Kotov"  wrote:
> > Stephen J. Turnbull wrote:
> > > Denis Kotov writes:
> > > > Usually people say that C++ not fit in CPython not knowing C++,
> > > > That's not the issue.  There are plenty of people who know C++ who
> say
> > > the benefits of C++ are not worth the bugs, the effort, and the plain
> > > old churn that a rewrite in C++ (even if incremental) would require.
> >
> > I am not sure about this one ...
> > For example, PyObject is much better to implement using C++ class, it
> will bring RAII that will reduce number of issues not free memory in CPython
> > See:
> > https://youtube.com/clip/UgkxyNe_dsZKinT_RT3UGb-BaP0SnvKteo2o
> >
> > Without RAII - introduced the most dangerous errors !!
>
>
>
> ___
> 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/3JYIICCL6C5NN6UFIQBHBYI4FGCLM3N6/
> 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/W6WEO2J7J6CYYR3C3UG4HIZRLDSBWHFU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 505 (None-aware operators) for Python 3.11

[Guido van Rossum]

Personally I think returning None is a fine API design, and IMO the
concerns about this pattern are overblown. Note that X|None is no different
than the "Maybe X" pattern that functional programmers are so fond of.

On Mon, Sep 19, 2022 at 8:02 AM Philipp Burch  wrote:

> Hi all,
>
> I've only here found out that there is a discussion going on about those
> none-aware operators and my first thought was "great, finally!". FWIW,
> I'd be happy with the syntax suggestion in the PEP, since '?' looks
> rather intuitive to me to mean something like "maybe".
>
> However, I then read the mentioned post of Steve Dower, with the final
> summary:
>
>  > So to summarise my core concern - allowing an API designer to "just
> use None" is a cop out, and it lets people write lazy/bad APIs rather
> than coming up with good ones.
>
> This is a very good point. In fact, I've never really thought about it
> that way and of course he's totally right that "SomeType | None" (or
> Optional[SomeType], which also somehow made me feel that this usage is
> fairly intended) is not optimal, at least for user defined
> types/classes. The problem is, that I never actually thought about his
> suggested way. And I wouldn't be surprised if this holds for many other
> people as well.
>
> Maybe it would be great to boldly mention these thoughts in the
> documentation at an appropriate place. In my opinion, there are at least
> the following good places where this would fit nicely:
>
> - The documentation of the dataclasses
> (https://docs.python.org/3/library/dataclasses.html), since this is
> probably the most common use case for the "| None" pattern. Going
> further, the dataclasses functionality might even be extended to make it
> simpler to generate such null-types (or however they are called), so
> that it is no longer "a tonne more work".
>
> - Linters like pylint could emit a note when seeing the "| None"
> pattern, linking to the explanation about why it is possibly not the
> best way to do it.
>
> - The documentation of the discussed None-aware operators. Since these
> new operators are closely coupled to the arguably suboptimal "| None"
> pattern, it is probably good to tell folks right there why they should
> consider better alternatives.
>
> As mentioned, I absolutely see Steve's point. However, there are many
> Python scripts/programs working without a complex API, where this "|
> None" pattern may still have its legitimate uses and the none-aware
> operators can make code easier to read (and write).
>
> Best regards,
> Philipp
> ___
> 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/Q2MOF5CJ7LSSZMEMB43YVEXD6PFATYTA/
> 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/7HEZXSLT2A63RDLXTJAOQWGBHNU3WDCR/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: glob's new include_hidden parameter

[Guido van Rossum]

I think it's wrong in the docs. From looking at the code, that flag applies
to all patterns, not just to `**`. (and "hidden" just means "begins with a
dot")

On Mon, Sep 12, 2022 at 9:04 AM Mats Wichmann  wrote:

>
> Just spotted that 3.11 adds an include_hidden.  At the moment a little
> confused because there's an apparent mismatch between docstring and docs.
>
> Lib/glob.py:
>
>  If `include_hidden` is true, the patterns '*', '?', '**'  will
> match hidden
>  directories.
>
>
> Doc/library/glob.rst:
>
> If *include_hidden* is true, "``**``" pattern will match hidden
> directories.
>
> ,,, with no mention of the other patterns.
>
> Is that just an omission in the rst doc?
>
> ___
> 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/QVZJAHFOHTNKNE72X7RGICBEROMSCG5R/
> 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/XPBIP5OYRB3LLJI36VNKVP6AFN4CFQ5Q/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Presenting PEP 695: Type Parameter Syntax

[Guido van Rossum]

Yeah, we all would have liked angle brackets, but there would be problems
with breaking lines between those. E.g.

def foo<
T: str,
S: int
> (arg1: T, arg2: S) -> tuple[T, S]:
...

cannot be parsed because the lexer doesn't treat angle brackets as matching
pairs.

In addition, we already use square brackets for *using* generics (e.g.
list[int]), and most surveyed languages use the same type of brackets in
declarations and uses.

On Thu, Jul 14, 2022 at 1:10 PM  wrote:

> Hi, I like this PEP but I couldn't find the motivation for using angle
> brackets over square braces (brackets?). The survey in Appendix A is great
> but lacks any conclusions. From that survey alone I would assume that angle
> brackets would have been chosen over square braces, given that they are the
> most common option and appear in (afaik) the more popular languages in that
> list. I think the PEP should add a section about the choice of syntax in
> the rejected section, which can be expanded upon in Appendix A.
>
> If you can't tell I'm in favor of angle brackets, I think the examples
> given in the PEP look a bit messy with so many parentheses and square
> braces in close proximity. Using angle brackets would make the distinction
> between typevars and function parameters clearer.
> ___
> 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/2LEHJKQGRHCHGQUFXUU3DTYKKDISNPFN/
> 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/CBCJCXDAQY5YXGBHRMLUGUNQAJMG3GAE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Exceptions and tracebacks and frames, oh my!

[Guido van Rossum]

This may be something you've already figured out, or not useful for your
use case, but the key insight here tends to be that traceback objects form
a singly-linked list from the frame where the exception was caught up to
the frame where it was raised, whereas the frames are linked in the
opposite direction, from the most deeply nested frame down to the main/root
frame (or the start/bootstrap frame for threads).

Tracebacks link to the frame. The lineno in the traceback is where the
exception was raised (or bubbled out) whereas the lineno in the frame is
where the frame is currently executing (probably in the exception handling
code).

On Thu, Jul 14, 2022 at 1:05 PM Yonatan Zunger  wrote:

> Hi everyone,
>
> Apologies for pinging the dev list; I'm shaving a very hairy yak, and the
> python-help crew, the docs, and the source are all unable to help.
>
> Context: I'm working on a library function to dump stack traces for all
> threads, sorta like _Py_DumpTracebackThreads but in Python and meant to be
> invoked from a high layer, and thus be pretty and readable and so on rather
> than signal-safe and robust. The hard part is combining data from thread
> stack frames and exceptions, since people generally want to know about
> these.
>
> What I'm having trouble understanding is the relationship between an
> exception's TB and the thread's frame. Two important differences I've
> noticed are that (a) the output of traceback.print_tb(sys.exc_info()[2])
> and traceback.print_stack(sys.exc_info()[2].tb_frame) are markedly
> different -- the former gives data about where the exception was raised,
> while the latter about where the thread currently is, usually in an
> exception handler and (b) if I'm in a unittest and dump the stack for a
> thread starting from its current frame (using traceback.format_stack and
> sys._current_frames), it gives a very deep stack that includes all the
> unittest harness code etc., but if I dump the stack for an exception
> starting from its TB object, it instead is very short and focused on where
> the exception happened.
>
> All of which tells me that I don't understand the relationship between the
> exception's traceback object and the frames it points to at all.
>
> Is there somewhere that explains this particular bit of magic, or someone
> who's well-versed in it? I have to admit that after a few hours of
> spelunking the code, I can't even figure out how the exception traceback is
> being set in the first place. :)
>
> Again, apologies for bugging the dev list with what (I hope) is a simple
> question -- if there's a FM I should be reading, please let me know!
>
> Yonatan
> ___
> 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/IRPWIRAZ3K5Y2F466ZISGSF5JBF657CB/
> 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/AM6ZT246YD4RCOSJIXJ5KTCVAPOM3DYC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Structural pattern matching and mangling private names

[Guido van Rossum]

Having thought about it some more, I agree with Daniel Moisset that the
current behavior is correct -- in D(__foo=bar), __foo is a keyword arg
position and those don't get mangled. Anyway, anything mangled would get
mangled according to the containing class (in your example, C), not
according to the class appearing in the call. Using the called class for
mangling would set a dangerous precedent.

So there's your answer -- the current behavior is as it should be. I'll
look into the patch with that in mind.

On Fri, Jul 1, 2022 at 10:54 AM  wrote:

> Guido van Rossum wrote:
> > If you want any kind of traction on this I recommend filing an
> opinionated
> > issue on this (explaining why the current behavior is wrong).
>
> Thanks - I'm asking from the point of view of trying to reimplement it. I
> don't actually have a strong opinion on whether the current behaviour is
> wrong - I'd just like to know if I should match it.
>
> From that point of view I've deviated from your advice slightly and
> created a PR instead to add a test for the current behaviour (
> https://github.com/python/cpython/pull/94500). Hopefully that'll either
> fix it is "intended" or stir up a different decision. I'm happy with either
> outcome.
>
> David
> ___
> 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/DBAJEVHAR6QD7HHECUESU6ZMPQKLBSC5/
> 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/4MTUBIKIFZ5GZ7MHPM7CDWTIQPRAYWWM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Presenting PEP 695: Type Parameter Syntax

[Guido van Rossum]

After several rounds of debate on typing-sig, I'd like to request feedback
on PEP 695: https://peps.python.org/pep-0695/

I am sponsoring this PEP, which was written by Eric Traut. The PEP attempts
to solve the problem that defining generic classes, functions and type
aliases currently is lacking dedicated syntax, instead using the cumbersome
`T = TypeVar("T", ...)` notation to create global variables that serve as
type variables.

As a personal historical note, I should mention that over 22 years ago I
already pondered type parameters. In an old document that I saved I found
the following code snippet:
```
def f (a: T) -> T: ...
```
which is eerily close to the proposal in this PEP, except that the PEP uses
square brackets:
```
def f[T](a: T) -> T: ...
```
It's been a long and circuitous road!

I am not quoting the entire PEP here, please follow the link:
https://peps.python.org/pep-0695/

-- 
--Guido van Rossum (python.org/~guido)
___
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/65KXYQOKHMZBGBHWKU6DRGOTN6PTZHFP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Structural pattern matching and mangling private names

[Guido van Rossum]

If you want any kind of traction on this I recommend filing an opinionated
issue on this (explaining why the current behavior is wrong).

On Wed, Jun 15, 2022 at 1:25 PM  wrote:

> Daniel Moisset wrote:
> > I might expect that in a "case D(something=__y)" you get the mangling for
> > __y, but I'm not sure what the implementation does now and I'm writing
> from
> > my phone
>
> Yes - that case does what you'd expect.
>
> Thanks for the reply.
> ___
> 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/3BALIBTV3ATAEC6G5ZJKAFBASZG4B5AP/
> 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/BX2QX3GUOGMBL5TGSSN7EQFJQHA6UQJM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Behavior of `asyncio.gather` when one of submitted tasks raises a `KeyboardInterrupt`.

[Guido van Rossum]

I'm sorry, I don't know the answer. Maybe you can read some of the source
code and report back here if you find any clues?

On Thu, Jun 9, 2022 at 1:53 PM Yves Duprat  wrote:

> Sorry for my imprecision, can you read the changes about the results:
> --
> With one coroutine in `asyncio.gather([sub_task()])`, result is:
> main_task(), be: CancelledError()
> __main__ 
>
> With two coroutines `asyncio.gather([sub_task(), asyncio.sleep(0)])` ,
> result is:
> main_task(), be: KeyboardInterrupt()
> __main__ 
> --
>
> Yves Duprat wrote:
> > Thank you for the straightforward explanation. May I ask you another
> question?
> > I don't understand the behavior of this waiting primitive. So here is
> the case below:
> > ```py
> > import asyncio
> > e = KeyboardInterrupt  # or SystemExit
> > async def sub_task():
> > raise e
> > async def main_task():
> > try:
> > await asyncio.gather(
> > # -- aws --
> > sub_task(),
> > asyncio.sleep(0)
> > )
> > except Exception as e:
> > print('\tmain_task(), e:', repr(e))
> > raise
> > except BaseException as e:
> > print('\tmain_task(), be:', repr(e))
> > if __name__ == '__main__':
> > try:
> > asyncio.run(main_task())
> > except e:
> > print(f'__main__ {e}')
> > ```
> > When one coroutine `[sub_task()]`, result is:
> > main_task(), be: CancelledError()
> > __main__ 
> > When two coroutines `[sub_task(), sleep(0)]` , result is:
> > main_task(), be: KeyboardInterrupt()
> > __main__ 
> > Why are results so different when `aws` contains single coroutine or two
> coroutines ?
> > Thank for your time
> > Yves
> > Guido van Rossum wrote:
> > > KeyboardInterrupt is generally not handled properly by asyncio, the
> normal
> > > behavior here is that the code just exits with a traceback.
> > > On Tue, Jun 7, 2022 at 11:00 AM Yves Duprat ydup...@gmail.com wrote:
> > > Hi,
> > > regarding this [issue93122](
> https://github.com/python/cpython/issues/93122),
> > > I am wondering what is the normal behavior of `asyncio.gather` when
> one of
> > > the submitted tasks raises a `KeyboardInterrupt` exception ? --
> regardless
> > > of the value of the `return_exception` parameter.
> > > It seems that this primitive does not behave the same way with
> > > `KeyboardInterrupt` and `ZeroDivisionError` exceptions. But may be it
> is
> > > normal ?
> > > I have searched in the documentation [here](
> > > https://docs.python.org/3/library/asyncio-task.html#asyncio.gather)
> but I
> > > did not find anything.
> > > Thanks for your help.
> > > Yves
> > > ___________
> > > 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/5KVY7SSD.
> ..
> > > 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-c.
> ..
> > >
> ___
> 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/CIDCWFDXIQ53745MI3V6S425SRSM6MRY/
> 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/U3JJ6UAJ6V7OOPD2OXYZJBZOXO5YCQVX/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Behavior of `asyncio.gather` when one of submitted tasks raises a `KeyboardInterrupt`.

[Guido van Rossum]

KeyboardInterrupt is generally not handled properly by asyncio, the normal
behavior here is that the code just exits with a traceback.

On Tue, Jun 7, 2022 at 11:00 AM Yves Duprat  wrote:

> Hi,
>
> regarding this [issue93122](https://github.com/python/cpython/issues/93122),
> I am wondering what is the normal behavior of `asyncio.gather` when one of
> the submitted tasks raises a `KeyboardInterrupt` exception ? -- regardless
> of the value of the `return_exception` parameter.
> It seems that this primitive does not behave the same way with
> `KeyboardInterrupt` and `ZeroDivisionError` exceptions. But may be it is
> normal ?
> I have searched in the documentation [here](
> https://docs.python.org/3/library/asyncio-task.html#asyncio.gather) but I
> did not find anything.
> Thanks for your help.
>
> Yves
> ___
> 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/5KVY7SSDTYWOAOCXVSXNBHCSDEJ5JPP7/
> 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/HTWTWS3M2PKQILSKN3V7UM73ZKOOQ33K/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Guido van Rossum]

I would love to see header files used for this -- while I know there is a
long tradition of feature-flags that must be #defined by the user before
#including a header in order to affect what the header exports (or not!),
30 years later I still find that approach pretty unintuitive.

But yes, it's going to be a complex transition.


On Mon, May 30, 2022 at 12:30 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/Q5JU5YKGX2U2UAAILDH45S5UGN6GLVXT/
> 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/GNDXKI3XTUI3TOOQI44BO5BUL6ZWQMI4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: [OT] Re: Raw strings ending with a backslash

[Guido van Rossum]

On Sat, May 28, 2022 at 12:11 MRAB

Names in Python are case-sensitive, yet the string prefixes are
> case-/insensitive/.
>
> Why?


IIRC we copied this from C for numeric suffixes  (0l and 0L are the same;
also hex digits and presumably 0XA == 0xa) and then copied that for string
prefixes without thinking about it much. I guess it’s too late to change.

—Guido
-- 
--Guido (mobile)
___
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/27HLMPDURSAN2YCTFWN6LETWQNY4POX7/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Issue: 92359 - Python 3.10 IDLE 64-bit doesn't open any files names code (code.py, code.pyw) - found a partial fix but looking for input

[Guido van Rossum]

So the "current working directory" is the directory containing the file,
right? That would explain the behavior.

Probably "Edit with IDLE" should be changed. I have no idea where that is
defined.

In 3.11 we should be able to make that use the new -P option, which doesn't
insert the working directory at the front of sys.path.

On Fri, May 13, 2022 at 6:50 PM  wrote:

> Hello,
>Link to the github issue page is here
> https://github.com/python/cpython/issues/92359
>
>This bug has been lurking in waiting for roughly 7 years or possibly
> longer.  The root issue is that the "Edit with IDLE" context menu executes
> idle with `python.exe -m idlelib` which puts the current working directory
> in sys.path but inside idlelib it has a `from code import ...` statement.
>   A kind of ugly hack is sitting in my fork of cpython here
> https://github.com/devdave/cpython/blob/issue_92359/Lib/idlelib/__main__.py
> .  All I did was put the Lib directory at the front of sys.path.
> Perhaps this is the best solution?  I don't know.
>
>Would appreciate any ideas for an alternative fix (ex perhaps changing
> how "Edit with IDLE" works?) or like I said, perhaps my fix is the best
> option because of how simple it is?
>
> Thanks,
>DevDave
> ___
> 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/NKMXPIQPISOPOV6OGASKXV4DEDZUH355/
> 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/XF3IRRYDYAHV7YAV4YNRB6EY3HVKDEBM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Starting a new thread

[Guido van Rossum]

Thinking about it, it's actually a fine design to have a decorator that
turns a regular function into one that starts a thread -- from the caller's
POV it's no different than having a function that explicitly starts a
thread, and it could be a nice shorthand if you do this all the time. (You
have to document it in either case.)

That said, I don't think we need this 3-line decorator in the stdlib.

--Guido


On Thu, May 12, 2022 at 10:40 PM Serhiy Storchaka 
wrote:

> 10.05.22 18:12, Barney Stratford пише:
> > This has a couple of advantages. I don’t have to import the threading
> module all over my code. I can use the neater syntax of function calls. The
> function’s definition makes it clear it’s returning a new thread since it’s
> decorated. It gets the plumbing out of the way so I an concentrate more on
> what my code does and less in how it does it.
>
> I do not see advantages. You definitely need to import the threading
> module or other module depending on the threading module in which you
> define the decorator. And you need to decorate the function. It will not
> save you a line of code.
>
> If you need to run a lot of functions in threads, note that a thread has
> some starting cost. Consider using concurrent.futures.ThreadPoolExecutor.
>
> If you only run few long living threads, the syntax of starting them
> does not matter, in comparison with the rest of your code.
>
> Also, it looks wrong to me to mix two different things: what code to
> execute and how to run it. If we need a neater syntax, I would propose:
>
>  t = threading.start_thread(func, *args, **kwargs)
>
> But I am not sure that it is worth to add such three-line function in
> the stdlib.
>
> ___
> 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/RBIAWP2J3NTYMLIS3W6CKX44G5QIBXAU/
> 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/DWPTNN2SZAPEP3HIAVAQ24BUYEDJSSF4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Starting a new thread

[Guido van Rossum]

It’s definitely too early for a PR, so if you already have one (I didn’t
see one linked to this thread) please close it.

Then once we’ve bikeshedded the right good idea you can start a new PR.

On Thu, May 12, 2022 at 12:21 Barney Stratford 
wrote:

> It seems like the consensus is that this is a good idea, but it’s the
> wrong good idea. Should I cancel the PR or should we try to make it into a
> better good idea?
>
> Cheers,
> 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/Z4AWYWNHJGOSBBU6DFV3ZS26WWQIILMW/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
-- 
--Guido (mobile)
___
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/YXGV6WQYHEKJWJGES6LS7DNUB5WFOVCQ/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Guido van Rossum]

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

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?)*
<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/L3JRME4CC5SXJJ2MSYSXBU6OBYLWVKKS/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: __dunder__ = None

[Guido van Rossum]

Non should behave as closely as possible to it not being defined at all. So
return NotImplemented.

On Sun, May 1, 2022 at 09:53 Patrick Reader <_...@pxeger.com> wrote:

> On 01/05/2022 06:20, Serhiy Storchaka wrote:
> > The question is how to interpret value None:
> >
> > * Always raise TypeError (with changed message)? This is what happen
> > currently when you set the method to None, this is the most compatible
> > option.
> > * Always raise an error, but allow to change it to more appropriate
> > type (for example AttributeError for __setattr__)?
> > * Interpret value None the same way as an absent attribute?
> What about binary operators (__add__, __eq__, etc)? Should they act as
> if they'd returned NotImplemented? Or immediately unconditionally raise
> a TypeError?
> ___
> 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/PLWKIT7FWXLKIGQXL3X5GFT3MGTC53R3/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
-- 
--Guido (mobile)
___
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/JNFF5Q6M2AU2YKZP52XTAL6HHDMGFRV7/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Proto-PEP part 4: The wonderful third option

[Guido van Rossum]

 FWIW, Carl presented a talk about his proposed way forward using PEP 649
with some small enhancements to handle cases like dataclasses (*), and it
was well received by those present. I personally hope that this means the
end of the "forward class declarations" proposals (no matter how
wonderful), but the final word is up to the SC.

(*) Mostly fixing the edge cases of the "eval __code__ with tweaked
globals" hack that Carl came up with previously, see
https://github.com/larryhastings/co_annotations/issues/2#issuecomment-1092432875
.

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

[Python-Dev] Re: PEP 689 – Semi-stable C API tier

[Guido van Rossum]

On Fri, Apr 29, 2022 at 10:15 AM Petr Viktorin  wrote:

> On 29. 04. 22 16:32, Victor Stinner wrote:
> > Ok, let me start with the serious business: API name.
> >
> > I'm not comfortable with "semi-stable". Python already has a "limited
> > API" and a "stable ABI". Just by its name, it's unclear what
> > "semi-stable" means.
> >
> > Honestly, I would be more comfortable with the name: "unstable API".
> > It would be clear that the API *can* change often. People who want to
> > know exactly the backward compatibility warranties can dig into the
> > API documentation to learn more about it.
> >
> > "Unstable API" is also the name the Guido proposed for PyCode_New() last
> year:
> >
> > * Proposal: declare "unstable APIs"
> >
> https://mail.python.org/archives/list/python-dev@python.org/thread/JM6SQ2YNMDAKXYD5O54QWMVR2X7QOXVL/
> > * Making code object APIs unstable
> >
> https://mail.python.org/archives/list/python-dev@python.org/thread/ZWTBR5ESYR26BUIVMXOKPFRLGGYDJSFC/
> >
> > Victor
>
>
> Nick Coghlan argued against that term:
>
> > "unstable" is the wrong term. We already have an unstable API tier: the
> > internal API, which can change even in maintenance releases. The value of
> > the new tier is that it is "semi stable": stable in maintenance releases,
> > unstable in feature releases.
>
> —
>
> https://mail.python.org/archives/list/python-dev@python.org/message/CTKKTHUV5R2A2RRN5DM32UQFNC42DDGJ/
>
>
> But I also like “unstable” better than “semi-stable”. Splitting the
> internals into “private”/“internal” and “unstable” seems reasonable.
>

I think picking "semi-stable" would be giving in to the OCD nerd in all of
us. :-) While perhaps technically less precise, "unstable" is the catchy
name with the right association. (And yes, we should keep it stable within
bugfix releases, but the name doesn't need to reflect that detail.) The
"internal API" isn't an API at all (except for CPython core developers and
contributors). The "unstable API" would definitely be an *API* for users
outside the core.

So let's please go with "unstable".

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

[Python-Dev] Re: Proto-PEP part 4: The wonderful third option

[Guido van Rossum]

I am traveling and have no keyboard right now, but it looks like this
thread is confusing the slots that a type gives to its *instances* and
extra slots in the type object itself. Only the latter are a problem.

I also would like to hear more about the problem this is trying to solve,
when th real-world examples. (E.g. from pydantic?)

On Tue, Apr 26, 2022 at 11:57 Larry Hastings  wrote:

>
> On 4/25/22 23:56, Ronald Oussoren wrote:
>
> A problem with this trick is that you don’t know how large a class object
> can get because a subclass of type might add new slots. This is currently
> not possible to do in Python code (non-empty ``__slots__`` in a type
> subclass is rejected at runtime), but you can do this in C code.
>
> Dang it!  __slots__!  Always there to ruin your best-laid plans.  *shakes
> fist at heavens*
>
> I admit I don't know how __slots__ is currently implemented, so I wasn't
> aware of this.  However!  The first part of my proto-PEP already proposes
> changing the implementation of __slots__, to allow adding __slots__ after
> the class is created but before it's instantiated.  Since this is so
> late-binding, it means the slots wouldn't be allocated at the same time as
> the type, so happily we'd sidestep this problem.  On the other hand, this
> raises the concern that we may need to change the C interface for creating
> __slots__, which might break C extensions that use it.  (Maybe we can find
> a way to support the old API while permitting the new late-binding
> behavior, though from your description of the problem I'm kind of doubtful.)
>
>
> Cheers,
>
>
> */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/YU3PJKPMJZNWKLZUG3JCJFGFOKGMV2GI/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
-- 
--Guido (mobile)
___
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/ZQ7T3IZIAUGEUJUUR7DDM72MLKWLKEAU/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Guido van Rossum]

On Mon, Apr 25, 2022 at 2:33 PM Brett Cannon  wrote:

>
>
> 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.
>

We haven't even discussed a *process* for how to decide. OTOH, in two days
at the Language Summit at PyCon, Sam will give a presentation to the core
devs present (which is far from all of us, alas).


> 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.
>

It's possible that I've missed those code reviews, but I haven't seen a
single PR from Sam, nor have there been any messages from him in this forum
or in any other forums I'm monitoring. I'm hoping that the Language Summit
will change this, but I suspect that there aren't that many perf
improvements in Sam's work that are easily separated from the nogil work.
(To be sure, Christian Heimes seems to have made progress with introducing
mimalloc, which is one of Sam's dependencies, but AFAIK that work hasn't
been finished yet.)

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

[Python-Dev] Re: Updating inspect APIs

[Guido van Rossum]

Is it not acceptable to create new functions that return non-named-tuple
objects (e.g. dataclasses with slots)? Otherwise the way the stats result
tuple works is a reasonable approach (and possibly deprecate indexed
access?)

On Sun, Apr 17, 2022 at 10:23 AM Pablo Galindo Salgado 
wrote:

> Hi,
>
> We are currently debating in gh-88116 (
> https://github.com/python/cpython/issues/88116)
> what's the best way forward to update the APIs in the inspect module to
> include the new position information.
>
> These APIs are inspect.getframeinfo, inspect.getouterframes,
> inspect.getinnerframes, inspect.stack and inspect.trace.
>
> The problem is that these APIs return a named tuple that now needs to
> include several new attributes (or one 4 tuple for
> the positions). Being named tuples, if we add a new attribute, existing
> unpackings of the tuple will now fail because there
> are more elements or the elements are in different positions. Also, it
> will be quite weird to add the new attributes at the
> end but leave the line number at the beginning.
>
> What's the best way to proceed here? The suggested way is to create a
> namedtuple subclass that adds the extra attributes
> but doesn't allow indexed access to it (there is a precedent to this in
> how we handled updating os.stat_result). I personally
> find this quite confusing but it certainly works. There may be other
> options.
>
> What do you think?
>
> Cheers from sunny London,
> Pablo Galindo Salgado
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/RTGG637WWPOWUHUF6TRJYUSBYYSVUPRA/
> 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/2YDFNBBGAW2QHVGPVQZBR2DINATSHM45/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Do you ever use ceval.c's LLTRACE feature?

[Guido van Rossum]

Hi Dennis,

It's been a while since I've used this code, but in the early days it was
indispensible. I think you have the right ideas on making it more useful
now that we're hacking on the bytecode again. Since lltrace is most useful
when the bytecode interpreter is somehow faulty, it doesn't make much sense
IMO to extend it with Python code, so indeed YAGNI on that proposal.

Since this will be useful only to a small audience, don't put too much
effort in it, but I'm sure that whatever effort you do put in it will be
much appreciated.

--Guido

On Thu, Apr 14, 2022 at 3:29 PM Dennis Sweeney 
wrote:

> Hi everyone,
>
> I'm looking to improve the output of the interpreter's LLTRACE feature to
> make it more understandable. This "feature" is undocumented, but it prints
> out the opcode and oparg of every bytecode instruction executed, along with
> some info about stack operations, whenever you've built with Py_DEBUG and
> the name `__ltrace__` is defined in the module.
>
> I've found this useful for debugging bits of the compiler and bytecode
> interpreter. For example, if I make some tweak that instroduces an
> off-by-one error, by default I get a segfault or a rather unhelpful
> assertion failure at `assert(EMPTY())` or `assert(STACK_LEVEL() <=
> frame->f_code->co_stacksize)` or similar, at best, with no inducation as to
> where or why that assertion is failing. But if I enable `__ltrace__` by
> either setting `__ltrace__=1` in some module or by manually setting
> `lltrace=1;` in the c code, I can follow what was happening in the
> interpreter just before the crash.
>
> I'd like the output in that scenario to be a bit more helpful. I propose
> printing opcode names rather than decimal digits, and printing out the name
> of the current function whenever a stack frame begins executing. I also
> proprose to print out the full stack contents (almost never very deep)
> before each bytecode, rather than printing the state piecemeal at each
> PUSH/POP/STACK_ADJUST macro. I opened issue
> https://github.com/python/cpython/issues/91462 and PR
> https://github.com/python/cpython/pull/91463
>
> I later found that this had been explored before by
> https://github.com/python/cpython/issues/69757, and there was a
> suggestion that this could be folded into a more generalized bytecode-level
> tracing feature that is pluggable with python code, similar to
> sys.settrace(). I would tend to think "YAGNI" -- lltrace is a feature for
> debugging the c internals of the interpreter, and there are already
> separate existing features like the `trace` module for tracing through
> Python code with different goals. I appreciate the simplicity of printf
> statements at the c level -- it feels more trustworthy than adding a
> complicated extra feature involving python calls and global state. It's as
> if I just littered the code with my own debugging print statements, but
> re-usable and better.
>
> I see no documentation anywhere, and there's only one test case in
> test_lltrace, just testing that there's no segfault. Looking back through
> the git history, I see that the basic `printf("%d: %d, %d\n", ...);` format
> goes back to 1990:
> https://github.com/python/cpython/blob/3f5da24ea304e674a9abbdcffc4d671e32aa70f1/Python/ceval.c#L696-L710
>
> I'm essentially writing to ask: how do you use lltrace? Does anyone rely
> on the particular format of the output? Would some of these improvements be
> helpful to you? What else could make it more helpful?
>
> Thanks,
> Dennis Sweeney
> ___
> 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/DELHX3N5PCZDWIK2DLU5JDG6JREQ42II/
> 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/7BR53ESXSZ4ZQH4Y6465YCSE2KNBOJRY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Proposal to deprecate mailcap

[Guido van Rossum]

Whoops, you’re right. I suppose I should have no opinion on whether to
deprecate it; I haven’t thought about it for over two decades…

On Thu, Apr 14, 2022 at 16:33 Jelle Zijlstra 
wrote:

>
>
> El jue, 14 abr 2022 a las 12:21, Damian Shaw ()
> escribió:
>
>> > I searched grep.app and found no significant usage.
>>
>> Maybe someone wants to inform mitmproxy?
>>
>> It's a very popular tool and it comes up using that tool when searching
>> for "import mailcap" using grep.app:
>> https://grep.app/search?q=import%20mailcap
>>
>> https://github.com/mitmproxy/mitmproxy/blob/main/mitmproxy/tools/console/master.py#L2
>>
>
> Thanks for catching that! I missed it because I mistakenly searched for
> '"import mailcap"' in quotes. It looks like mitmproxy isn't vulnerable to
> the security issue because it only passes a filename from mkstemp() to
> mailcap, and hopefully mkstemp filenames don't have shell metacharacters in
> them. However, if we deprecate mailcap mitmproxy will have to change their
> code.
>
> El jue, 14 abr 2022 a las 13:33, Guido van Rossum ()
> escribió:
>
>> Probably because it’s not a top level module — it’s inside the email
>> package.
>>
> It's in fact a top-level module.
>
> ___
> 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/25FNDJBERE5PLBP3VX3JQ7ER2LNE2K2O/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
-- 
--Guido (mobile)
___
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/AAIXGR57BXDULXPTJJN4LBTVR4KVFPED/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Proposal to deprecate mailcap

[Guido van Rossum]

On Thu, Apr 14, 2022 at 12:04 Jelle Zijlstra 
wrote:

>
>
> El jue, 14 abr 2022 a las 11:47, Brett Cannon ()
> escribió:
>
>> Do you know why this module wasn't included in PEP 594?
>

Probably because it’s not a top level module — it’s inside the email
package.

Should we do another audit of old modules to deprecate them before they
> cause problems?
>
-- 
--Guido (mobile)
___
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/ZMSD2LZ3SRM6E3W3Z2VDEKZIMVLO6VZW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Lazy Imports [was: Declarative imports]

[Guido van Rossum]

On Mon, Apr 11, 2022 at 1:07 PM Itamar O  wrote:

> Breaking out the discussion about lazy imports.
> It seems somewhat OT in the declarative imports thread.
>
> On Mon, Apr 11, 2022 at 10:50 AM Barry Warsaw  wrote:
>
>> Thanks Carl,
>>
>> > On Apr 9, 2022, at 08:25, Carl Meyer  wrote:
>> >
>> > Our experience in practice, though, has been that universally lazy
>> > imports is somewhat easier to adopt than Strict Modules, and has had a
>> > much bigger overall impact on reducing startup time for big CLIs (and
>> > a big web server too; as you note it's not as serious an issue for a
>> > web server in production, but restart time still does make a
>> > difference to dev speed / experience.)
>>
>> Excellent point about the impact of restarts and development time.
>> That’s been an issue for us a bit, but not an overwhelming motivation to
>> rewrite in other languages[1].
>>
>
> Lazy imports had been very significant to both CLI startup time, as
> well as service reload time during local development - we have
> more details in the docs [1], and a related blog post coming up soon.
>
>
>>
>> > Removing slow stuff happening
>> > at import time helps, but it'll never match the speed of not doing the
>> > import at all! We've seen startup time improvements up to 70% in
>> > real-world CLIs just by making imports lazy. We've also opened an
>> > issue to discuss the possibility of upstreaming this. [2]
>> >
>> > [1] https://github.com/facebookincubator/cinder/#strict-modules
>> > [2] https://bugs.python.org/issue46963
>>
>> Post-GH-issues-migration link for the issue:
>> https://github.com/python/cpython/issues/91119
>>
>> I’ve put some questions and comments there, but I’m also really curious
>> about the technical details for your lazy imports.  Have you gotten as far
>> as thinking about a PR or PEP?
>>
>
> Yes and Yes (at least for the "thinking about" part).
> Germán Méndez Bravo (Kronuz) will be drafting a PEP,
> and is leading work internally to port this from 3.8 (first
> to 3.10, then to the cpython main branch).
> We are planning to get started on this during PyCon sprints,
> it would be nice to connect in-person with anyone who's
> interested in this and happens to be in the sprints too!
>

I am and I will be.

>
>
>>
>> -Barry
>>
>> [1] Not that there aren’t other reasons folks give for rewriting, such as
>> multicore performance, ecosystem alignment (e.g. SREs being more
>> comfortable in Go), etc.
>>
>
> Itamar.
>
> [1]
> https://github.com/facebookincubator/cinder/blob/cinder/3.8/CinderDoc/lazy_imports.rst#lazy-imports
> ___
> 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/NIXH574H64DXEXNZK6NDOGNZKQQPUDYM/
> 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/KZRURVH7VLHD7JQ2ASNZ6OMBVTVYEYXG/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 687 – Isolating modules in the standard library

[Guido van Rossum]

In the sentence starting with

Types whose methods need access to their module instance will be converted
to heap types[...]

please emphasize (bold!) "whose methods need access to their module
instance".

Also emphasize this paragraph:

"Static types that do not need module state access, and have no other
reason to be converted, should stay static."

I hadn't noticed the qualification in the first sentence and had assumed
all types were to be converted, until I came across the second at the very
end of the section (where it is easily overlooked by lazy readers :-).

On Mon, Apr 11, 2022 at 6:33 AM Petr Viktorin  wrote:

> Hello,
> Please provide any feedback you might have on PEP 687 – Isolating
> modules in the standard library: https://peps.python.org/pep-0687/
>
>  From recent discussions around “what should have a PEP”, it’s clear
> that this should have been a PEP long ago. Better late than never, I guess!
>
> We submit this PEP to explain the changes, seek consensus on whether
> they are good, propose the remaining changes, and set best practices for
> new modules.
>
> There's a discussion thread on Discourse:
>
> https://discuss.python.org/t/pep-687-isolating-modules-in-the-standard-library/14824
>
>
> ___
> 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/B3HYQIE4Z5WBJCC3FUZJZHXLM32I4BZA/
> 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/MOGERKXYWRSSM65L5MK3PQC6BO65GLJ4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Declarative imports

[Guido van Rossum]

On Sun, Apr 10, 2022 at 2:31 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.
>

This has been brought up a few times and I don't get it. Currently a use of
an imported module is perfectly analyzable by all the static type checkers
I know of (e.g. mypy, Pyre, pyright). For the static analyzer it makes no
difference if I have

import re
.
.
.
def foo(x):
if re.match(r"blah", x): ...

or the hypothetical inline form:

def foo(x):
if @re.match(r"blah", x): ...


> 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.
>

I have too.

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

[Python-Dev] Re: Declarative imports

[Guido van Rossum]

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. IIRC the
Cinder version even modifies the bytecode and/or the interpreter.
Disregarding the specific notation proposed, *if* people would be willing
to mark the points where they expect lazy imports explicitly, that would
make implementation much simpler.

The argument that "imports on top" makes code more readable seems pretty
weak to me. The current hacks to speed up startup already violate this rule
(imports inside functions), and in most cases I start reading or writing
code in the middle of a file (having gotten there via a search in my
editor) and the meaning of an import is either obvious (e.g. re.match(...))
or requires another annoying search to find the definition of a certain
unknown variable. Tools can easily show all imports a module does.

The key questions to me are
- What should the notation be?
- Will users be willing to use it?

--Guido



On Fri, Apr 8, 2022 at 1:26 AM Malthe  wrote:

> This is an idea which has been brought up before, sometimes introduced
> as "heresy". But an interesting twist has surfaced now which is
> typing.
>
> But firstly, let me present the idea. It is very simple, that Python
> should have declarative imports, usable anywhere using a simple
> syntax, @.
>
> For example, `some_regex = @re.compile(...)`.
>
> What happens then is that before anything else in that module, that
> symbol is imported:
>
> from re import compile as _mangled_re_compile
>
> It must be the very first thing (hoisting) because when else would it
> happen? It's been suggested before to have a shorthand syntax which
> does a dynamic import at the time of using it but this brings me to
> the twist:
>
> We want typing to pick up these imports. And this twist has a second
> leg which is that we often need to import symbols simply in order to
> type some argument type or return type. This leads to a great many
> more imports to type.
>
> (Nevermind that if you want to take typing further, abstract
> interfaces really make more sense rather than specific
> implementations, but the point is the same.)
>
> A situation where this would come in really handy is in scripting such
> as how we use Python in Apache Airflow to let users write out simple
> workflows. A workflow definition which could be a 5-liner quickly
> becomes a 20-liner – consider for example:
>
> default_args = {
> "start_date": @datetime.datetime(...)
> }
>
> It's a lot more ergonomic from a user perspective (well perhaps for
> some users and for some programs).
>
> Thoughts?
>
> Cheers
> ___
> 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/UX6EJHLJNNLMFPWVPF5ANYHQSHDZK7SV/
> 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/BTWPAJRVQ24QX2Z7TIQPDYRXKJOGRPMU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Descriptions in unittest and avoiding confusion

[Guido van Rossum]

"Well, that escalated quickly." :-)

How did we get from a specific issue with docstrings and the unittest
package's test reporting to multi-line comments? If this was Discourse that
entire subdiscussion would have been flagged as off-topic and moved to its
own thread.

On Mon, Apr 4, 2022 at 10:12 AM Steven D'Aprano  wrote:

> On Mon, Apr 04, 2022 at 09:27:46AM -0700, Coyot Linden (Glenn Glazer)
> wrote:
> > On 4/4/22 09:25, Paul Moore wrote:
> > >On Mon, 4 Apr 2022 at 17:22, Coyot Linden (Glenn Glazer)
> > > wrote:
> > >>>I would welcome a multiline comment format that didn't involve
> > >>>docstrings.
> > >>Err, sorry, I meant multiline string format.
> > >I'm confused, what's wrong with """..."""? Triple quoted strings are
> > >not exclusively for docstrings...
> > >Paul
> >
> > That isn't my reading of PEP 257, I would be happy to be wrong about
> this.
>
> PEP 257 says that all docstrings should use triple quotes. It doesn't
> say that *only* docstrings should use triple quotes.
>
>
> --
> 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/3ULX4QF5WF6WBFT3KIIPXS2UI7OZUKRF/
> 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/3BZHMFATRS432LE66XKBMUSRJTKYBTAS/
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

[Guido van Rossum]

+1 to Nick's analysis and proposal. I had been mulling over my own reply
but this just about covers it.

On Sun, Apr 3, 2022 at 6:29 AM Nick Coghlan  wrote:

> On Fri, 1 Apr 2022, 6:47 pm Victor Stinner,  wrote:
>
>> On Wed, Mar 30, 2022 at 5:42 PM Guido van Rossum 
>> wrote:
>>
>> I'm not convinced that advertising an API as being Unstable (in the
>> documentation?) is going to solve any kind of problem. People love to
>> use private APIs, and they do it simply because it's technically
>> possible :-) At the end of the day, we have to help them updating
>> their code, otherwise we (at least my Red Hat team) cannot update
>> Python.
>>
>> I designed the internal C API to be more annoying to be used (need to
>> define a macro, need more specific #include) in the hope that people
>> will think twice before using it :-)
>>
>
>
> The changes you've made have been excellent, and the existing 3 categories
> (stable public ABI, stable public API, unstable internal API) cover the
> vast majority of cases.
>
> The final case that isn't quite covered yet is to offer a "semi-stable"
> API category for use cases that are intrinsically coupled to implementation
> details that may change between feature releases, but should remain stable
> within a release series.
>
> The concrete motivating example for the new category is the extra APIs you
> need in order to provide an alternative eval loop implementation.
>
> The internal API category doesn't properly cover that case, as the APIs
> there are free to change even in maintenance releases, and setting
> Py_BUILD_CORE exposes a lot more than what an alternative eval loop would
> need.
>
> Regular public functions may work in some cases, but aren't necessarily
> practical in others (such as exposing the internal frame details for use in
> alternative eval loops).
>
> From an implementation PoV, my own suggestion would be to define a new API
> tier with an opt-in macro rather than relying solely on documentation or
> naming conventions.
>
> For example, define "Py_SEMI_STABLE_API" to opt in, with the headers under
> "Include/cpython/semi_stable/" (I don't like "unstable" as potential
> terminology here, since the internal API is already unstable - we're
> splitting the difference between that and the long term stability of the
> full public API)
>
> Cheers,
> Nick.
>
>
>
>> Victor
>> ___
>> Python-Dev mailing list -- python-dev@python.org
>> To unsubscribe send an email to python-dev-le...@python.org
>> https://mail.python.org/mailman3/lists/python-dev.python.org/
>> Message archived at
>> https://mail.python.org/archives/list/python-dev@python.org/message/YCHLFQ5KW6XF5C5CFWF4MRTZEXVBZBMA/
>> 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/TBWSFAGJNCDEVNK4VSQTEUKYX6FRBUYA/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: code.replace() and Python 3.11 exception table

[Guido van Rossum]

By beta 1 things should be stable (modulo bug fixes). But documentation may
lag. If you can’t figure something out by reading the code by all means ask!

On Fri, Apr 1, 2022 at 11:40 Matthieu Dartiailh 
wrote:

> As the maintainer of bytecode (thanks to Victor), I expect that adding
> support for 3.11 will be challenging at least. However I hoped that by
> waiting for the first beta most changes would be at least documented. What
> would be the best channel to reach people that may clarify how things work
> starting with 3.11 ?
>
> Best
>
> Matthieu Dartiailh
>
> On Fri, Apr 1, 2022, 18:34 Mark Shannon  wrote:
>
>> Hi Gabriele,
>>
>> On 01/04/2022 4:50 pm, Gabriele wrote:
>> > Does this mean that this line in the bytecode library is likely to fail
>> with 3.11, with no way to fix it?
>> >
>>
>> You can pass the exception table the same way you pass all the other
>> arguments.
>> The exception table depends on the code, but that is nothing new. The
>> bytecode library already recomputes the consts, names, etc.
>>
>> TBH, calling `types.CodeType` didn't work for earlier versions either.
>> It just sort of worked, some of the time.
>>
>> Cheers,
>> Mark.
>>
>>
>> >
>> https://github.com/MatthieuDartiailh/bytecode/blob/7b0423234b0e999b45a4eb0c58115b284314f46b/bytecode/concrete.py#L398
>> <
>> https://github.com/MatthieuDartiailh/bytecode/blob/7b0423234b0e999b45a4eb0c58115b284314f46b/bytecode/concrete.py#L398
>> >
>> >
>> > On Fri, 1 Apr 2022, 10:40 Victor Stinner, > vstin...@python.org>> wrote:
>> >
>> > I created https://bugs.python.org/issue47185 <
>> https://bugs.python.org/issue47185> to discuss this issue:
>> > either recompute automatically co_exceptiontable, or at least
>> document
>> > the change.
>> >
>> > Victor
>> >
>> > On Fri, Apr 1, 2022 at 11:21 AM Victor Stinner > > wrote:
>> >  >
>> >  > ("Re: C API: Move PEP 523 "Adding a frame evaluation API to
>> CPython"
>> >  > private C API to the internal C API")
>> >  >
>> >  > On Fri, Apr 1, 2022 at 11:01 AM Chris Angelico > > wrote:
>> >  > >
>> >  > > On Fri, 1 Apr 2022 at 19:51, Victor Stinner <
>> vstin...@python.org > wrote:
>> >  > > > In Python, sadly the types.CodeType type also has a public
>> constructor
>> >  > > > and many projects break at each Python release because the
>> API
>> >  > > > changes. Hopefully, it seems like the new CodeType.replace()
>> method
>> >  > > > added to Python 3.8 mitigated the issue. IMO
>> CodeType.replace() is a
>> >  > > > better abstraction and closer to what developers need in
>> practice.
>> >  > >
>> >  > > It certainly has been for me. When I want to do bytecode
>> hackery, I
>> >  > > usually start by creating a function with def/lambda, then
>> construct a
>> >  > > modified function using f.__code__.replace(). It's the easiest
>> way to
>> >  > > ensure that all the little details are correct.
>> >  >
>> >  > Python 3.11 added the concept of "exception table"
>> >  > (code.co_exceptiontable). You have to build this table, otherwise
>> >  > Python can no longer catch exceptions :-)
>> >  >
>> >  > I don't know how to build this exception table. It seems like
>> >  > currently there is no Python function in the stdlib to build this
>> >  > table.
>> >  >
>> >  > Example:
>> >  > ---
>> >  > def f():
>> >  > try:
>> >  > print("raise")
>> >  > raise ValueError
>> >  > except ValueError:
>> >  > print("except")
>> >  > else:
>> >  > print("else")
>> >  > print("exit func")
>> >  >
>> >  > def g(): pass
>> >  >
>> >  > if 1:
>> >  > code = f.__code__
>> >  > g.__code__ = g.__code__.replace(
>> >  > co_code=code.co_code,
>> >  > co_consts=code.co_consts,
>> >  > co_names=code.co_names,
>> >  > co_flags=code.co_flags,
>> >  > co_stacksize=code.co_stacksize)
>> >  > else:
>> >  > g.__code__ = f.__code__  # this code path works on Python
>> 3.11
>> >  >
>> >  > g()
>> >  > ---
>> >  >
>> >  > Output with Python 3.10 (ok):
>> >  > ---
>> >  > raise
>> >  > except
>> >  > exit func
>> >  > ---
>> >  >
>> >  > Output with Python 3.11 (oops):
>> >  > ---
>> >  > raise
>> >  > Traceback (most recent call last):
>> >  >   ...
>> >  > ValueError
>> >  > ---
>> >  >
>> >  > By the way, this change is not documented at all:
>> >  >
>> >  > * https://docs.python.org/dev/library/types.html#types.CodeType
>> 
>> >  > * https://docs.python.org/dev/whatsnew/3.11.html <
>> https://docs.python.org/dev/whatsnew/3.11.html>
>> >  >
>> >  > I understand that these changes 

[Python-Dev] Re: code.replace() and Python 3.11 exception table

[Guido van Rossum]

On Fri, Apr 1, 2022 at 8:56 AM Gabriele  wrote:

> Does this mean that this line in the bytecode library is likely to fail
> with 3.11, with no way to fix it?
>
>
> https://github.com/MatthieuDartiailh/bytecode/blob/7b0423234b0e999b45a4eb0c58115b284314f46b/bytecode/concrete.py#L398
>

Yes, that constructor is not considered stable.

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

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

[Guido van Rossum]

On Wed, Mar 30, 2022 at 12:42 PM Steve Holden  wrote:

> Not defining the semantics of annotations was a brave move, but
> inevitably led to the situation where different use cases, all
> quite reasonable, would spring into being. Now they have, the development
> team has to decide a) which ones to sanction and b) which will be left out
> in the cold.
>

Interesting, in the JavaScript (excuse me, ECMAScript) world, there's
currently a proposal on the table to do just that, on steroids:
https://github.com/giltayar/proposal-types-as-comments (full disclosure:
some of the proposal authors are colleagues of mine). We'll have to see how
they fare.


> I wish them well.
>
> Kind regards,
> Steve
>
>
> On Wed, Mar 30, 2022 at 5:24 PM Christopher Barker 
> wrote:
>
>> > I personally would love for a typing.python.org or equivalent
>> subsection of docs.python.org to exist.
>>
>> +1
>>
>> There’s a wrinkle here, however. The type specs are Python, but how they
>> are used/interpreted is up to third party packages.
>>
>> So it’s a bit tricky to know exactly what to document where.
>>
>> I don’t think that’s insurmountable, but something to keep in mind.
>>
>> For example, while the clear specs are the first step, what the community
>> really could use is a good “recommended practices for static typing” doc —
>> and that’s harder to do without reference to particular tools.
>>
>> -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/YF5UIQIWNVIANFOCIQ2J4DJACQGJDGVM/
>> 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/NW3SRUA2H3KNZBD4CICXY5QF2YWELUV5/
> 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/YUGMANOPKSAR7SPDLQGTDGFAID6H5YHA/
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

[Guido van Rossum]

I don't think such a guarantee (to not vary internal APIs from 3.x.y to
3.x.(y+1)) has ever before been made in writing, although in practice we've
been doing this (more so now than we were in the 2.x timeframe).

I think we should not lightly vary internal APIs between bugfix releases,
but at the same time I am not sure I want to absolutely guarantee that no
internal API ever changes in a bugfix release (because that might prevent
fixing certain bugs).

So I think we need to officially embrace a category of "unstable public
APIs" and set a policy specifically for those, before we can make progress.

I'd like the SC to take some initiative here.

On Wed, Mar 30, 2022 at 9:34 AM Jason Ansel via Python-Dev <
python-dev@python.org> wrote:

> Got it, thanks for the clarifications!
>
> Tracking 3.x Python versions is fine.  We already need to do that to
> support things like new bytecodes, and PyTorch supports an explicit list of
> 3.x Python versions with separate builds for each.
>
> Tracking 3.x.y Python versions would be much more painful, and make us
> need to rethink our approach.
>
> So what Steve Downer described as "remain compatible within a single 3.x
> release", seems like exactly what we want.  I support that level of
> compatibility guarantee.  Could we keep that guarantee with this change?
>
> Thanks,
> Jason
>
>
>
>
>
> 
> From: Victor Stinner 
> Sent: Wednesday, March 30, 2022 7:56 AM
> To: Steve Dower
> Cc: Jason Ansel; python-dev@python.org
> Subject: Re: [Python-Dev] Re: C API: Move PEP 523 "Adding a frame
> evaluation API to CPython" private C API to the internal C API
>
> On Wed, Mar 30, 2022 at 2:26 AM Steve Dower 
> wrote:
> > Right now, the API is allowed/expected to change between 3.x releases
> > (which normally we don't allow without a deprecation period) but it
> > still has to remain compatible within a single 3.x release. Making it
> > fully internal *without adding a stability guarantee* means it could
> > change more frequently, which you wouldn't be able to handle as an
> > installable package.
> >
> > It's *unlikely* that it'll change that often, because there are still
> > other public interfaces that cannot. But, the plan behind this is to
> > make more stuff internal so that it can be modified more freely, so we
> > may see that rate of change increase.
>
> Well, my plan is not break these internal C API just for fun. It's
> only to better "advertise" the separation between the "stable" public
> C API (backward compatibility warranty) and the "unstable"
> private/internal C API (can change any time, changes are not
> documented).
>
> 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/U7M65SSDZMM7LNAKEDZZ4KKQIFTCOQ2M/
> 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/J3G5RO4FUO3Y3WJ2AJAUMJNS2BXYZ7J7/
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

[Guido van Rossum]

In the not so distant past I have proposed to introduce a new category,
"Unstable APIs". These are public but are not guaranteed to be backwards
compatible in feature releases (though I feel they should remain so in
bugfix releases).

I'm not sure whether those should have a leading underscore or not. Perhaps
(like some other languages do and like maybe we've used in a few places)
the name could just include the word "Unstable"?

On Wed, Mar 30, 2022 at 8:08 AM Victor Stinner  wrote:

> The internal C API can be used on purpose. But there is no backward
> compatibility warranty and it can change anytime. In practice, usually
> it only changes in 3.x.0 releases. For example, these private C API
> changed in Python 3.9 and Python 3.11 (see my first email in the other
> PEP 523 thread).
>
> To use the internal C API, you have to declare the Py_BUILD_CORE macro
> and include an internal C API header file. For
> _PyInterpreterState_SetEvalFrameFunc(), it should be:
>
> #ifndef Py_BUILD_CORE_MODULE
> #  define Py_BUILD_CORE_MODULE
> #endif
> #include 
> #include  //
> _PyInterpreterState_SetEvalFrameFunc()
> #include   // _PyEval_EvalFrameDefault
>
> Victor
>
> On Tue, Mar 29, 2022 at 12:26 AM Jason Ansel via Python-Dev
>  wrote:
> >
> > The PyTorch team plans to use PEP 523 as a part of PyTorch 2.0, so this
> proposal may break the next major release of PyTorch.
> >
> > The related project is TorchDynamo, which can be found here:
> > https://github.com/facebookresearch/torchdynamo
> >
> > We will likely move this into the core of PyTorch closer to release.
> >
> > If the changed happens, would PyTorch still be able to use the eval
> frame API?  Or would it prevent from being used entirely?
> > ___
> > 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/RVQ7LDIJ2OYAN4QMIPTI3A3PODGBLNN7/
> > 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/OQTAF6CQRKHQPYUY5HWVOTUAEXKHI5WE/
> 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/EIK3XLPV7A7WVB4FA47PM2G2SJ42RERO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: walrus operator and expression

[Guido van Rossum]

Parenthesize.

On Mon, Mar 28, 2022 at 3:50 PM Ethan Furman  wrote:

> In the following bit of code:
>
>
>  while s := input.read(MAXBINSIZE):
>  while len(s) < MAXBINSIZE and ns := input.read(MAXBINSIZE-len(s)):
>  s += ns
>  line = binascii.b2a_base64(s)
>  output.write(line)
>
> I'm getting this error on the second line:
>
>  cannot use assignment expressions with expression
>
> Can somebody explain why that isn't working?
>
> Many thanks.
>
> --
> ~Ethan~
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/3NONJDUTXANBTINCOZITLHOAUDMJ3H66/
> 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/Q3O55IVWRYCNQT7NIG6X3XSOIGLZCZ6P/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: import * and __future__ imports

[Guido van Rossum]

On Mon, Mar 28, 2022 at 8:52 AM Irit Katriel 
wrote:

>
>
> On Mon, Mar 28, 2022 at 4:44 PM Guido van Rossum  wrote:
>
>>
>> "Future" imports are special to the parser, and they may also set a flag
>> for the runtime to alter its behavior, but they are intentionally not
>> treated specially by code generation, so they are still properly imported.
>> However the presence of the imported thing is not used by the runtime to
>> determine its behavior; those flags are stored elsewhere guided by the code
>> generator.
>>
>
> Right, this is why it's confusing when the object is there for no reason
> (the future import did not have any impact on the module, but the object
> showed up via an import *).
>

As Petr said, it's no more confusing than any other imported thing showing
up as a global.


> I don't think there's anything to do here.
>>
>
> How about the suggestion in https://bugs.python.org/issue26120 ? It's
> about these objects showing up in pydoc (both when the __future__ had an
> impact and when it didn't - in either case it's not an interesting part of
> the module's API).
>

If pydoc wants to filter that's up to pydoc (I'm not maintaining that).
Though really this should be keyed off `__all__`.


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

[Python-Dev] Re: is __self__ an implementation detail

[Guido van Rossum]

It's documented in stdtypes.rst, so I think it's part of the standard
library.

I think it's unnecessarily obfuscated though.

On Mon, Mar 28, 2022 at 8:44 AM Robin Becker  wrote:

> A gentoo developer reported a symlink loop problem in reportlab's setup.py
> where we search for specific headers.
>
> The 'fixed' function looks like this
>
> def findFile(root, wanted, followlinks=True):
>  visited = set()
>  for p, D, F in os.walk(root,followlinks=followlinks):
>  #scan directories to check for prior visits
>  #use dev/inode to make unique key
>  SD = [].append
>  for d in D:
>  dk = os.stat(pjoin(p,d))
>  dk = dk.st_dev, dk.st_ino
>  if dk not in visited:
>  visited.add(dk)
>  SD(d)
>  D[:] = SD.__self__  #set the dirs to be scanned
>  for fn in F:
>  if fn==wanted:
>  return abspath(pjoin(p,fn))
>
> the fix is reported to have worked, but the developer is querying the
> lifting of  SD.append using the construct
>
> SD = [].append
> loop involving
>appends to the list
> .
> D[:] = SD.__self__
>
> his objection was that using __self__ might be implementation sensitive.
>
> I cannot tell from the documentation (eg
> https://docs.python.org/3.10/reference/datamodel.html) if these magic
> methods
> are part of python or of the implementation.
>
> On the other hand as a longtime python programmer I wonder if such simple
> cases are already optimized out in the
> produced bytecode; for years I have been avoiding s += 'string' and only
> recently found out that it was handled as a
> special case.
> --
> Robin Becker
> ___
> 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/3TAF3LR35HRRE6LD7XQ7O4BXPNLVXFVX/
> 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/6IMBFHOGAYJDDGJVPVYJNQJS4MICGJ7Q/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: import * and __future__ imports

[Guido van Rossum]

On Mon, Mar 28, 2022 at 6:29 AM Irit Katriel via Python-Dev <
python-dev@python.org> wrote:

> If you have a __future__ import in a script, and you import * from it in
> another script, the object for this future appears in the dir() of the
> other script, even though the __future__ import has no effect there.
>
> % cat x.py
> from __future__ import annotations
>
>
> % cat y.py
> from x import *
>
> print(dir())
>
> class D:
> def f(self, a: D):
> return 42
>
> % ./python.exe y.py
> ['__annotations__', '__builtins__', '__cached__', '__doc__', '__file__', 
> '__loader__', '__name__', '__package__', '__spec__', '*annotations*']
> Traceback (most recent call last):
>   File "/Users/iritkatriel/src/cpython-654/y.py", line 5, in 
> class D:
> 
>   File "/Users/iritkatriel/src/cpython-654/y.py", line 6, in D
> def f(self, a: D):
>^
>
> NameError: name 'D' is not defined
>
>
> I think we should change import * to exclude the __future__ import
> objects, and perhaps also to not show them in dir(x).   Any objections?
>
> This came up in the discussion about https://bugs.python.org/issue26120 .
> See the attached PR for a technique we can use to identify those objects.
>

"Future" imports are special to the parser, and they may also set a flag
for the runtime to alter its behavior, but they are intentionally not
treated specially by code generation, so they are still properly imported.
However the presence of the imported thing is not used by the runtime to
determine its behavior; those flags are stored elsewhere guided by the code
generator.

I don't think there's anything to do here.

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

[Python-Dev] Re: Changing unittest verbose output.

[Guido van Rossum]

Hopefully it only prints the first line of the docstring?

On Sun, Mar 27, 2022 at 2:42 PM Gregory P. Smith  wrote:

> For many of us, this isn't a nuisance. It is a desirable feature.
>
> test_xxx functions and methods typically don't have docstrings at all as
> the majority of tests tend to be concise and obvious with the function name
> itself describes what its purpose is.  When we added printing the
> docstring, it was useful, as you can expand upon the purpose of the test
> more than you can in a reasonable name within the docstring.  We do this
> all the many times in our own test suite.  When running the tests, you see
> the docstring and are given more context as to what the test is about.
> This can be useful when triaging a failure before you've even loaded the
> source.
>
> I don't doubt that someone writes thesis defenses and stores them in their
> TestCase.test_method docstrings. I'm just saying that is not the norm.
>
> I'd accept a PR adding another command line switch for unittest to disable
> docstring printing in verbose mode.
>
> -gps
>
>
> On Sun, Mar 27, 2022 at 12:59 PM Barry Warsaw  wrote:
>
>> On Mar 26, 2022, at 17:48, Itay Yeshaya  wrote:
>> >
>> > When running unittest with the -v flag, if a test has errors, and has a
>> docstring, the test name is shown on one line, and the docstring is shown
>> on the next line with the `ERROR` word.
>>
>> This has been a long-standing nuisance, but I’m like Guido.  I pretty
>> much use pytest for everything these days, except for maybe
>> unittest.mock.patch.
>>
>> -Barry
>>
>>
>> ___
>> Python-Dev mailing list -- python-dev@python.org
>> To unsubscribe send an email to python-dev-le...@python.org
>> https://mail.python.org/mailman3/lists/python-dev.python.org/
>> Message archived at
>> https://mail.python.org/archives/list/python-dev@python.org/message/ZIMXSRQMWFOE4U3C3MBK6SG5TH26PDRL/
>> 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/RJOWQWMMUMBJAZZTWXWEAJSRDVARA2XL/
> 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/6GKOOGDXGHND57VTM2FNVTXOS2H4PCUF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Changing unittest verbose output.

[Guido van Rossum]

I recall actually really liking the docstring. I think there are situations
where the test name just can't be sufficiently explanatory. IIRC in the
past we didn't print the docstring at all and it felt right when it was
added.

ATM I'm not using unittest for anything so I don't have a strong opinion.

On Sun, Mar 27, 2022 at 8:21 AM Eric V. Smith  wrote:

> On 3/27/2022 10:51 AM, Jelle Zijlstra wrote:
>
>
>
> El sáb, 26 mar 2022 a las 17:51, Itay Yeshaya ()
> escribió:
>
>>
>> Any thoughts on the mentioned solutions?
>>
>
> This is a bit more out there, but can anyone explain why we show the
> docstring at all? As far as I can tell it causes a bunch of confusion and
> helps little. If there's a failing test, I want the test name so I can
> quickly find it in the code; I don't want the docstring which may not even
> be unique.
>
>
> I think this is a good idea. The target audience for a docstring isn't the
> people trying to track down failing tests.
>
> Eric
> ___
> 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/BTF4LZWVTHNHBJVNHXNWSPB2WS4324TO/
> 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/LIZB53G6YT4NXEIWTPVP5BIPDWUC4S26/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Restrict the type of __slots__

[Guido van Rossum]

On Fri, Mar 18, 2022 at 9:40 AM Paul Bryan  wrote:

> On Fri, 2022-03-18 at 09:35 -0700, Guido van Rossum wrote:
>
> The motivation has been explained already.
>
>
> In this thread?
>

Yes, Eric's message.


> What on earth did your test do that got a speedup by using sets? Was it
> repeatedly checking whether a variable was in a slot? The other thing this
> does is rearrange the order in which slots appear from run to run (since
> set order is affected by hash randomization) and you might have gotten
> lucky with a popular attribute being moved to the front, where it's more
> likely to be in the memory cache already (cache lines being 64 bytes and
> pointers being 8 bytes nowadays).
>
>
> I created objects in a tight loop, populating attributes, noting the
> elapsed time.
>

It does not make sense that that is correlated to the type of __slots__,
since __slots__ is not used for instance creation at all (it is only used
to create the class). I stick to my likely explanation.

Regarding Serhiy's proposal, I'm +0 on disallowing strings, and +0 on
disallowing things that can't be reiterated (but it's not a problem in
practice). Given other responses the status quo is likely best.

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

[Python-Dev] Re: Restrict the type of __slots__

[Guido van Rossum]

The motivation has been explained already.

What on earth did your test do that got a speedup by using sets? Was it
repeatedly checking whether a variable was in a slot? The other thing this
does is rearrange the order in which slots appear from run to run (since
set order is affected by hash randomization) and you might have gotten
lucky with a popular attribute being moved to the front, where it's more
likely to be in the memory cache already (cache lines being 64 bytes and
pointers being 8 bytes nowadays).

I agree that dicts are a use case to preserve.

On Fri, Mar 18, 2022 at 08:59 Paul Bryan  wrote:

> You've proposed a "what", but I don't see a "why".
>
> Indeed, it will break some code.
>
> I've been (currently legally) expressing __slots__ as sets, which is
> arguably more consistent with its purpose, and in testing appeared to
> perform better than tuples.
>
> So, I would request that you amend the allowed types to include sets.
>
> Also, people are using dicts to provide docstrings on attributes, so that
> would need to be addressed as well.
>
> On Fri, 2022-03-18 at 11:42 +0200, Serhiy Storchaka wrote:
>
> 18.03.22 11:29, Serhiy Storchaka пише:
>
> It will break some code (there are 2 occurrences in the stdlib an 1 in
> scripts), but that code can be easily fixed.
>
>
> Actually it will break more code, because initializing __slots__ with a
> list is pretty common. Maybe restrict it to tuple or list? But having an
> immutable __slots__ may be more reliable.
>
> ___
> 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/HCZHJN2LSD2NXFLSFAO7VVOMEZRTLDBQ/
> 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/6AKHUOVUQ2SQRPE4HAGWAEW2VYRKPFCL/
> 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/ZMH4DECXV3AF5M3BFVHEEMF7FE6FLU6H/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 684: A Per-Interpreter GIL

[Guido van Rossum]

That sounds like a horrible idea. The GIL should never be held during an
I/O operation.

On Fri, Mar 11, 2022 at 19:00 Jim J. Jewett  wrote:

> > Is ``allow_all_extensions`` the best name for the context manager?
>
> Nope.  I'm pretty sure that "parallel processing via multiple simultaneous
> interpreters" won't be the only reason people ever want to exclude certain
> extensions.
>
> It might be easier to express that through package or module name, but
> importlib and util aren't specific enough.
>
> For an example of an extension that works with multiple interpreters but
> only if they share a single GIL ... why wouldn't that apply to any
> extension designed to work with a Singleton external resource?  For
> example, the interpreters could all share a single database connection, and
> repurpose the GIL to ensure that there isn't a thread (or interpreter)
> switch mid-transaction.
> ___
> 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/RUDVIEDDCNFDRBIQVQU334GMPW77ZNOK/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
-- 
--Guido (mobile)
___
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/VKFNIFQRQZ5EVZ4G4TQIR2NGMO7BAMWY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: RFC on PEP 655: Required[] and NotRequired[] for TypedDict

[Guido van Rossum]

Maybe this shouldn't be called syntax but notation or convention?

On Mon, Mar 7, 2022 at 7:00 AM Petr Viktorin  wrote:

> Hello,
> I'm sorry for my late reply -- keeping up with all the PEPs is
> somewhat challenging.
>
> The one nitpick I have is that the PEP should make a few things more
> clear to people outside the typing-sig:
> - if this PEP really only affects typing.py and external
> projects/tools, it should say so clearly (so e.g. a parser experts can
> skip reading the PEP with clear conscience, even though it "introduces
> two new syntaxes")
> - in Specification, clarify what "It is an error" means -- is it a
> Python runtime error, or an error type checkers should raise? Same for
> "It is valid".
>
> To be clear, I don't think this should block the PEP.
>
>
> On Wed, Feb 16, 2022 at 4:58 PM David Foster  wrote:
> >
> > Hi folks, PEP 655 (Required[] and NotRequired[] for TypedDict) is still
> > looking for feedback from core devs.
> >
> > I've copied the latest PEP text at the bottom of this email to make it
> > easier to comment on.
> >
> > Thank you for your time.
> >
> > Best,
> > --
> > David Foster | Seattle, WA, USA
> > Contributor to Python's type system
> ___
> 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/YT23XQSNUJF3S4HO5MWGOH3GR5GP4Y7Y/
> 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/RV3DX5M6CACGIAYSBG65I7UZMKL4FVTI/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Make __mro_entries__ mandatory for non-types

[Guido van Rossum]

Yes, it's supposed to work. There's tons of special code to support it, and
documentation (e.g.
https://docs.python.org/3/reference/datamodel.html?highlight=__mro_entries__#resolving-mro-entries
).

Now, I think it was an attempt at getting too fancy, but we can't remove
the functionality without deprecation etc. -- __mro_entries__ was
introduced in Python 3.7 by PEP 560 to support it (but the support itself
is much older).

On Sat, Mar 5, 2022 at 9:50 AM Steven D'Aprano  wrote:

> On Sat, Mar 05, 2022 at 04:42:55PM -, Jason Madden wrote:
>
> > zope.interface relies on this behaviour.
>
> The example you give shows that Interface is a class. It merely has a
> metaclass which is not `type`. (I presume that is what's going on
> behind the scenes.)
>
> I'm asking about the example that Serhiy shows, where a class inherits
> from something which is not a class at all. In his example, the base is
> 1, although it gives a TypeError. I'm asking if that sort of thing is
> suppposed to work, and if so, how?
>
>
> --
> 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/E2IWXPFY32R6JS22XXFORMNQTI4S6AOK/
> 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/JWT2KD3QPMDWNDQZFUPFJXKA6S6BZXLX/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Make __mro_entries__ mandatory for non-types

[Guido van Rossum]

Good to hear from you, Serhiy. I hope you and your family are safe.

On Sat, Mar 5, 2022 at 1:29 AM Serhiy Storchaka  wrote:

> Currently the class can inherit from arbitrary objects, not only types.
> If the object was not designed for this you can get a mysterious
> mistake, e g.:
>
>  >>> class A(1): ...
> ...
> Traceback (most recent call last):
>File "", line 1, in 
> TypeError: int() takes at most 2 arguments (3 given)
>
> If the object's constructor is compatible with type constructor by
> accident you can an unexpected result. To prevent this we usually add an
> explicit __mro_entries__() method which raises an exception.
>
> I propose to make __mro_entries__() mandatory if a base is not a type
> instance (with a deprecation period).
>

Funny, I was just thinking about this (reviewing Brett's draft for the next
installment of his desugaring Python blog).

How common is it that people get confused by an error message like from
`class A(1)`? I'm not sure that it's common enough to weigh down the
esoteric use cases (inheriting from non-class objects) with more API.

To me the weirder exception around this is that if a base class *is* a
class object, even if it has a __mro_entries__ method that isn't called. If
we added a __mro_entries__ to type (returning (self,)) it might make more
sense to insist on bases always having a __mro_entries__ method.

Then again I find the name __mro_entries__ somewhat poorly chosen, since it
really is a hook to override the list of explicit bases (i.e., (B, C) for
class A(B, C)), not the MRO (which would be at least (A, B, C, object), and
more if A and/or B have other superclasses).

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

[Python-Dev] Re: build cpython on M1 Pro mac

[Guido van Rossum]

On Wed, Mar 2, 2022 at 8:34 AM Yves Duprat  wrote:

> > How did you find that issue?
> This message printed from VSCode when I ran my script in debug mode
>

Oh, I see, this is something that pydevd prints when it doesn't understand
the .pyc file. We changed the bytecode significantly in 3.11 (more than we
did in previous versions, though it tends to change in each version) --
that message is at least a decade old.


> > the Pydev extension used by VS Code doesn't yet work well with
> > the changes in 3.11 internals.
> Is there a simple sheet, white paper about these internal changes ?
>

No, you could follow the discussions on
https://github.com/faster-cpython/ideas though and ask specific questions
there if something's not clear.


> >You should probably inquire with either the
> > Pydev extension (https://github.com/fabioz/Pydev) or the VS Code team
> about
> > what their plans are for fixing this
> Thank for the solutions.
>

The specific component to  look for is pydevd --
https://github.com/fabioz/PyDev.Debugger/. I recommend filing an issue
there.

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

[Python-Dev] Re: build cpython on M1 Pro mac

[Guido van Rossum]

How did you find that issue? It seems unlikely that a problem with 3.11 is
caused by an issue reported for Python 2.5 in 2007.

My own understanding of the problem with the VS Code debugger and 3.11
(which I have experienced myself as well :-) is that since 3.11 is still in
alpha mode, the Pydev extension used by VS Code doesn't yet work well with
the changes in 3.11 internals. You should probably inquire with either the
Pydev extension (https://github.com/fabioz/Pydev) or the VS Code team about
what their plans are for fixing this -- I wouldn't blame them if they
decided to wait until 3.11 beta 1 is released, which should happen on or
after May 6th this year.

On Tue, Mar 1, 2022 at 8:25 AM Yves Duprat  wrote:

> Hi,
>
> I built cpython on a mac OSX 12.01. Python runs well.
> When starts, Python shows that version info which looks good:
> 'Python 3.11.0a5+ (heads/fix-issue-43352:f899da7fe5, Feb 25 2022,
> 10:04:53) [Clang 13.0.0 (clang-1300.0.29.30)] on darwin'
>
> But when I want to used it in VSCode to debug a script, I have the
> following message:
> ---
> This version of python seems to be incorrectly compiled
> (internal generated filenames are not absolute).
> This may make the debugger miss breakpoints.
> Related bug: http://bugs.python.org/issue1666807
> ---
> What do I miss ? I looked for a specific option in ./configure but seen
> nothing  ?
> Can someone help me please ?
> Thank
>
> Yves
> ___
> 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/DISAPV26T2U6CHHSGXTD5EWX54CPMB6Z/
> 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/56TM7JH7MFTEHFWPKBRE3MWVG6CRIPO4/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Guido van Rossum]

Thanks!

On Wed, Feb 16, 2022 at 11:19 AM Kevin Modzelewski  wrote:

> Importantly, our system allows for the reference count of immortal objects
> to change, as long as it doesn't go below half of the original very-high
> value. So extension code with no concept of immortality will still update
> the reference counts of immortal objects, but this is fine. Because of this
> we haven't seen any issues with extension modules.
>

In CPython we will *have* to allow this in order to support binary packages
built with earlier CPython versions (assuming they only use the stable
ABI). Those packages will necessarily use INCREF/DECREF macros that don't
check for the immortality bit. Yes, it will break COW, but nevertheless we
have to support the Stable ABI, and INCREF/DECREF are in the Stable ABI. If
you want COW you will have to compile such packages from source.

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

[Python-Dev] Re: PEP-657 and co_positions (was: Please update Cython *before* introcuding C API incompatible changes in Python)

[Guido van Rossum]

It might require a detailed API design proposal coming from outside CPython
(e.g. from Cython) to get this to change. I imagine for co_positions in
particular this would have to use a "builder" pattern.

I am unclear on how this would work though, given that Cython generates C
code, not CPython bytecode. How would the synthesized co_positions be used?
Would Cython just generate a co_positions fragment at the moment an
exception is raised, pointing at the .pyx file from which the code was
generated?

On Wed, Feb 9, 2022 at 9:41 AM Pablo Galindo Salgado 
wrote:

> I can only say that currently, I am not confident to expose such an API,
> at least for co_positions, as the internal implementation is very likely to
> heavily change and we want to have the possibility of changing it between
> patch versions if required (to address bugs and other things like that).
>
> On Wed, 9 Feb 2022 at 17:38, Stefan Behnel  wrote:
>
>> Pablo Galindo Salgado schrieb am 09.02.22 um 17:40:
>> >> Should there be a getter/setter for co_positions?
>> >
>> > We consider the representation of co_postions private
>>
>> Yes, and that's the issue.
>>
>>
>> > so we don't want (for now) to ad
>> > getters/setters. If you want to get the position of a instruction, you
>> can
>> > use PyCode_Addr2Location
>>
>> What Cython needs is the other direction. How can we provide the current
>> source position range for a given piece of code to an exception?
>>
>> As it stands, the way to do this is to copy the implementation details of
>> CPython into Cython in order to let it expose the specific data
>> structures
>> that CPython uses for its internal representation of code positions.
>>
>> I would prefer using an API instead that allows exposing this mapping
>> directly to CPython's traceback handling, rather than having to emulate
>> byte code positions. While that would probably be quite doable, it's far
>> from a nice interface for something that is not based on byte code.
>>
>> And that's not just a Cython issue. The same applies to Domain Specific
>> Languages or other programming languages that integrate with Python and
>> want to show users code positions for their source code.
>>
>> Stefan
>>
>> ___
>> 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/VQSWX6MFKIA3RYPSX7O6RTVC422LTJH4/
>> 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/P7SMK5ZGFAHZMLUKW4WZNNX47CONXIQS/
> 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/YJHFRW4FYIPMYWGX57D4XNV7FIZSBSTY/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Guido van Rossum]

Thanks for trying it! I'm curious why it would be slower (perhaps less
locality? perhaps the ...Id... APIs have some other trick up their sleeve?)
but since it's also messier and less backwards compatible than just leaving
_Py_IDENTIFIER alone and just not using it, I'd say let's not spend more
time on that alternative and just focus on the two other horses still in
the race: immortal objects or what you have now.

On Mon, Feb 7, 2022 at 5:41 PM Eric Snow 
wrote:

> On Fri, Feb 4, 2022 at 8:25 PM Eric Snow 
> wrote:
> > On Fri, Feb 4, 2022, 16:03 Guido van Rossum  wrote:
> >> I wonder if a better solution than that PR wouldn't be to somehow
> change the implementation of _Py_IDENTIFIER() to do that,
> >
> > Yeah, I had the same realization today.  I'm going to try it out.
>
> I updated _Py_IDENTIFIER() to use a statically initialized string
> object and it isn't too bad.  The tricky thing is that PyASCIIObject
> expects to the data to be an array after the object.  So the field
> must be a pre-sized array (like I did in gh-30928).  That makes things
> messier.  The alternative is to do what Steve is suggesting.
>
> I ran the benchmarks and making _Py_IDENTIFIER() a statically
> initialized object makes things 2% slower (instead of 1% faster).
> There are a few things I could do to speed that up a little, but at
> best we'd get back to performance-neutral.
>
> -eric
>


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

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

[Guido van Rossum]

So you're proposing to completely get rid of those three? And you're sure
that each and every single call to any of those is better off being an
assert()?

(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.)

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

> On Mon, Feb 7, 2022 at 5:38 PM Guido van Rossum  wrote:
> > ISTM this is better discussed on a case-by-case basis than as a blanket
> policy change. (The latter could end up causing a flood of trivial PRs from
> wannabe-contributors who found and fix yet another violation of the policy,
> which is both a nuisance for reviewers and a risk of introducing bugs due
> to being over-zealous.)
>
> That's why I propose to only change code using these 3 functions:
>
> * PyErr_BadInternalCall(),
> * _Py_CheckFunctionResult()
> * _Py_CheckSlotResult()
>
> Victor
> --
> Night gathers, and now my watch begins. It shall not end until my death.
>


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

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

[Guido van Rossum]

ISTM this is better discussed on a case-by-case basis than as a blanket
policy change. (The latter could end up causing a flood of trivial PRs from
wannabe-contributors who found and fix yet another violation of the policy,
which is both a nuisance for reviewers and a risk of introducing bugs due
to being over-zealous.)

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

> Hi,
>
> I would like to replace runtime checks on C function arguments with
> assertions. For example, replace:
>
> PyObject *
> PyDict_GetItemWithError(PyObject *op, PyObject *key)
> {
> if (!PyDict_Check(op)) {
> PyErr_BadInternalCall();
> return NULL;
> }
> ...
> }
>
> with:
>
> PyObject *
> PyDict_GetItemWithError(PyObject *op, PyObject *key)
> {
> assert(PyDict_Check(op));
> ...
> }
>
> I'm not asking to remove all of them. For example,
> PyList_GetItem(list, index) will continuing raising an IndexError if
> the index is out of range.
>
> I'm asking to replace runtime checks with assertions when the C API is
> "obviously" misused: replace PyErr_BadInternalCall(),
> _Py_CheckFunctionResult() and _Py_CheckSlotResult() with assertions.
> The exact scope should be defined.
>
> --
>
> Python tries to be nice to C extensions authors and calls
> PyErr_BadInternalCall() to emit a nice SystemError exception when the
> C API is misused. There are many sanity checks run at runtime. We pay
> the cost of these runtime checks even if a C extension is well written
> (has no bug).
>
> In Python 3.6, I added the _Py_CheckFunctionResult() function to check
> the result of any function call. A function must return a non-NULL
> object and not raises an exception, or return NULL and raises an
> exception. Otherwise, SystemError is raised. For example,
> PyObject_Call() uses it to check the PyTypeObject.tp_call result.
>
> In Python 3.10, I added a similar _Py_CheckSlotResult() function to
> check the result of slot functions. For example, PyObject_Size()
> checks the result of the PyTypeObject.tp_as_sequence.sq_length slot
> function.
>
> --
>
> I modified Python 3.8 to be able to use a debug Python build as a
> drop-in replacement of a Python release build: debug and release
> builds are now ABI compatible. It is no longer needed to rebuild C
> extensions in debug mode. My first goal was to be able to use gdb on a
> Python binary built with -O0:
>
> https://developers.redhat.com/articles/2021/09/08/debugging-python-c-extensions-gdb
>
> A debug Python build adds many other debug features useful to develop
> C extensions:
> https://docs.python.org/dev/using/configure.html#python-debug-build
>
> IMO with Python 3.11, it's now easy enough to get a Python debug build
> to develop or debug your C extensions. End users should not have to
> pay the price of these runtime checks.
>
> On most Linux distribution, a Python debug build is available as
> "python3-debug" executable. To check if you are using a debug build,
> check if the sys.gettotalrefcount() function is available.
>
> By the way, it is also possible to build Python in release mode with
> assertions using "./configure --with-assertions":
> https://docs.python.org/dev/using/configure.html#cmdoption-with-assertions
>
> So, what do you think?
>
> --
>
> In 2019, I already proposed this idea on the bug tracker, but I
> abandoned my idea:
> https://bugs.python.org/issue37406
>
> 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/RR3DJ4IZVSFKZUE5AV6OUCJ3QPYXD26Z/
> 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/YLXFI7L3XTY5HPLNQL56WGDJY5YUBJD4/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Guido van Rossum]

Yes, please build it; I can't quite follow what you're getting at (probably
since I don't know the Windows APIs).

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

> On 2/5/2022 4:09 PM, Guido van Rossum wrote:
> > On Sat, Feb 5, 2022 at 5:18 AM Steve Dower  > <mailto:steve.do...@python.org>> wrote:
> >
> > The gap this has with what I'd like to see is that it will only work
> > for
> > compile-time strings. If instead it could work for an arbitrary
> uint8_t
> > pointer, rather than an embedded array, that allows even runtime
> > strings
> > to be very cheaply passed into the interpreter (and yes, the caller
> has
> > to manage the lifetime, but that's pretty easy).
> >
> >
> > What's the use case for that, that isn't covered by
> PyUnicode_FromString()?
>
> No dynamic memory allocation (and hence, no deallocation) for any case
> where the original string is already managed, which is really quite
> common. Access to the memory manager is what requires thread
> affinity/the GIL for primitive object construction, and string copies -
> especially with transcoding - are the expensive part.
>
> For cases where strings are just passed around but never manipulated
> (e.g. a lot of filesystem operations, or runtime/interpreter
> configuration), the string may never have to be decoded at all. It's
> almost as good as a tagged pointer, but without breaking our existing
> object model (assuming all the PyUnicode_* functions learn how to handle
> them, which is necessary).
>
> But it's purely a transparent optimisation for most users, with an added
> opportunity for those using native APIs and probably decent complexity
> for us as maintainers. There are a lot of edge cases to handle that I'm
> sure people will use to shoot down the idea, which is why rather than
> debate details here I'd rather build it and define its boundaries of
> usefulness, though for now there's plenty of stuff I'd rather do than
> both of these, so it remains an idea for now :)
>
> Cheers,
> Steve
>


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

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

[Guido van Rossum]

On Sat, Feb 5, 2022 at 5:18 AM Steve Dower  wrote:

> The gap this has with what I'd like to see is that it will only work for
> compile-time strings. If instead it could work for an arbitrary uint8_t
> pointer, rather than an embedded array, that allows even runtime strings
> to be very cheaply passed into the interpreter (and yes, the caller has
> to manage the lifetime, but that's pretty easy).
>

What's the use case for that, that isn't covered by PyUnicode_FromString()?

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

[Python-Dev] Re: PyPy on PySide6 is there: PyPy with a Gui

[Guido van Rossum]

Congrats Christian! It sounds like this will open new avenues for PyPy (and
maybe also for Qt/PySide6).

--Guido

On Thu, Feb 3, 2022 at 4:25 AM Christian Tismer-Sperling <
tis...@stackless.com> wrote:

> Hi Guido et. al.,
>
> since May 2021 I have been working at running PyPy on PySide6,
> which was a difficult undertaking, since PyPy internally is quite
> a bit different.
>
> I declared the project to be ready-to-use when the Mandelbrot
> example of the PySide examples
>  (examples/corelib/threads/mandelbrot.py)
> is working.
>
> This was finally solved this week on 2022-02-01, so we have the
>
>  first advanced Gui working with PyPy
>
> and with the amazing result of speed:
>
> PyPy 3.8 works
>  10 times faster than the identical code on Python 3.10
> and
>  5.5 times slower than the same example in C++ Qt.
>
> I think to send an official announce when this is available on pip.
>
> This effort marks the completion of my PyPy support, which began
> in 2003 and ended involuntarily in 2006 due to a stroke.
>
> All the best -- Chris
> --
> Christian Tismer-Sperling:^)   tis...@stackless.com
> Software Consulting  : http://www.stackless.com/
> Strandstraße 37  : https://github.com/PySide
> 24217 Schönberg      : GPG key -> 0xFB7BEE0E
> phone +49 173 24 18 776  fax +49 (30) 700143-0023
>


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

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

[Guido van Rossum]

Trying to cut things short, there's one thing I'd like to correct:

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

> [...]
>
> Another example is that Cython currently calls PyCode_New() to create
> a fake frame object with a filename and line number. IMO it's the
> wrong abstraction level: Python should provide a function to create a
> frame with a filename and line number, so the caller doesn't have to
> bother about the complex PyCode_New() API and frequent PyCodeObject
> changes. (Correct me if this problem has already been solved in
> Python.)
>

That was solved quite a while ago, with the PyCode_NewEmpty() API. Sadly
Cython doesn't call it (or at least not always), because it takes a C
string which is turned into a unicode object, and Cython already has the
unicode object in hand. I don't want to proliferate APIs.

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

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

[Guido van Rossum]

You *can* allocate unicode objects statically. We do it in deepfreeze, and
Eric's PR under discussion here (
https://github.com/python/cpython/pull/30928) does it. I wonder if a better
solution than that PR wouldn't be to somehow change the implementation of
_Py_IDENTIFIER() to do that, and make the special 'Id' APIs just aliases
for the corresponding unicode-object-based APIs? It wouldn't be ABI
compatible, but none of those APIs are in the stable ABI.

(Is there a requirement that an Id only contain ASCII characters (i.e.,
7-bit)?)

On Fri, Feb 4, 2022 at 12:52 PM Steve Dower  wrote:

> On 2/4/2022 5:37 PM, Eric Snow wrote:
> > On Thu, Feb 3, 2022 at 3:49 PM Eric Snow 
> wrote:
> >> I suppose I'd like to know what the value of _Py_IDENTIFIER() is for
> >> 3rd party modules.
> >
> > Between Guido, Victor, Stefan, and Sebastian, I'm getting the sense
> > that a public replacement for _Py_IDENTIFER() would be worth pursuing.
> > Considering that it would probably help numpy move toward
> > subinterpreter support, I may work on this after all. :)
> >
> > (For core CPython we'll still benefit from the statically initialized
> > strings, AKA gh-30928.)
>
> For me, I'd love to see a statically allocated string type (for a real
> example that's used in Windows, check out [1], specifically when he gets
> to the fast-pass strings).
>
> Essentially, a bare minimum struct around a char* (and/or wchar_t*) that
> acts as a PyUnicodeObject but doesn't ever allocate anything on the
> heap. This would also be helpful for config strings, which are often
> static but need to be copied around a lot, and good for passthrough
> strings that a native extension or host app might insert and receive
> back unmodified.
>
> Because there's nothing to deallocate, it can be "created" and stored
> however the caller likes. As soon as Python code does anything with it
> other than passing it around, a regular PyUnicodeObject is allocated
> (just like the HSTRING example).
>
> I'd expect usage to look very much like the intern examples earlier in
> the thread, but if we actually return a whole struct then we aren't on
> the hook for the allocations.
>
> Cheers,
> Steve
>
> [1]: https://devblogs.microsoft.com/oldnewthing/20160615-00/?p=93675
> ___
> 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/DGX4GBMDJYYFAE7OSVMBGKYAO2HPP3PT/
> 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/7LGVQRWLQQJNQD5M5BEUAPAFBCQTUWK7/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Guido van Rossum]

On Thu, Feb 3, 2022 at 2:50 PM Eric Snow 
wrote:

> On Wed, Feb 2, 2022 at 11:50 PM Inada Naoki 
> wrote:
> > It would be nice to provide something similar to _PY_IDENTIFIER, but
> > designed (and documented) for 3rd party modules like this.
>
> I suppose I'd like to know what the value of _Py_IDENTIFIER() is for
> 3rd party modules.  They can already use PyUnicode_InternFromString()
> to get a "global" object and then store it in their module state.  I
> would not expect _Py_IDENTIFIER() to provide much of an advantage over
> that.  Perhaps I'm missing something?
>
> If there is a real benefit then we should definitely figure out a good
> public API for it (if the current private one isn't sufficient).  I
> won't be authoring that PEP though. :)
>

Why not read through some of that code and see what they are doing with it?

I imagine one advantage is that _Py_IDENTIFIER() can be used entirely local
to a function. E.g. (from _operator.c):

_Py_IDENTIFIER(partial);
functools = PyImport_ImportModule("functools");
if (!functools)
return NULL;
partial = _PyObject_GetAttrId(functools, _partial);

That's convenient since it means they don't have to pass module state
around.

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

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

[Guido van Rossum]

I'm sorry, I was overwhelmed and didn't find the time until now to answer
this. A lot was already said about this, so I'll just briefly explain below
(inline).

On Sat, Jan 29, 2022 at 2:38 AM Victor Stinner  wrote:

> On Fri, Jan 28, 2022 at 6:28 PM Guido van Rossum  wrote:
> > I think we will get *one* chance in the next decade to get it right.
> Whether that's HPy or evolution of the C API I'm not sure.
>
> Would you mind to elaborate? Which risk do you expect from switching
> to HPy and from fixing the C API (introducing incompatible C API
> changes)?
>

IMO users would benefit if we recommended one solution and started
deprecating the rest. We currently have too many choices: Stable ABI,
limited API (not everybody sees those two as the same thing), CPython API
(C API), Cython (for many this is how they interact with the interpreter),
HPy... And I think you have another thing in the works, a library that
"backfills" (I think that's the word) APIs for older CPython versions so
that users can pretend to use the latest C API but are able to compile/link
for older versions.

To me, that's too many choices -- at the very least it should be clearer
how these relate to each other (e.g. the C API is a superset of the Limited
API, the Stable ABI is based on the limited API (explain how), and HPy is a
wrapper around the C API. (Or is it?)

Such an explanation (of the relationships) would help users understand the
consequences of choosing one or the other for their code -- how will future
CPython versions affect them, how portable is their code to other Python
implementations (PyPy, GraalPython, Jython). Users can't be expected to
understand these consequences without a lot of help (honestly, many of
these I couldn't explain myself :-( ).


> For me, promoting HPy and evolution of the C API are complementary,
> can and must done in parallel for me. As I explained in PEP 674, while
> HPy does help C extensions writers, it doesn't solve any problem for
> CPython right now. CPython is still blocked by implementation details
> leaked throught the C API that we must still maintain for a few more
> years.
>

I understand the CPython is stuck supporting the de-facto standard C API
for a long time. But unless we pick a "north star" (as people call it
nowadays) of what we want to support in say 5-10 years, the situation will
never improve.

My point about "getting one chance to get it right in the next decade" is
that we have to pick that north star, so we can tell users which horse to
bet on. If the north star we pick is HPy, things will be clear. If it is
evolving the C API things will also be clear. But I think we have to pick
one, and stick to it so users (i.e., package maintainers/developers) have
clarity.

I understand that HPy is currently implemented on top of the C API, but
hopefully it's not stuck on that. And it only helps a small group of
extension writers -- those who don't need the functionality that HPy is
still missing (they keep saying they're not ready for prime time) and who
value portability to other Python implementations, and for whom the
existing C API hacks in PyPy aren't sufficient. So it's mostly
aspirational. But if it stays that for too long, it will just die for lack
of motivation.


>
>
> > Victor, am I right that the (some) stable ABI will remain important
> because projects don't have resources to build wheels for every Python
> release? If a project does R releases per year for P platforms that need to
> support V versions of Python, they would normally have to build R * P * V
> wheels. With a stable ABI, they could reduce that to R * P. That's the key
> point, right?
>
> There are different use cases.
>
> 1) First, my main worry is that we put a high pressure on maintainers
> of most important Python dependencies before the next of a new Python
> version, because we want them to handle the flow of incompatible C API
> changes before the final Python 3.x versions is released, to get them
> available when Python 3.x final is released.
>

Hm, maybe we should reduce the flow. And e.g. reject PEP 674...


> It annoys core developers who cannot change things in Python without
> getting an increasing number of complains about a large number of
> broken packages, sometimes with a request to revert.
>

You are mostly talking about yourself here, right? Since the revert
requests were mostly aimed at you. :-)


> It annoys C extensions maintainers who have to care about Python alpha
> and beta releases which are not convenient to use (ex: not available
> in Linux distributions).


I don't use Linux much, so I am not familiar with the inconvenience of
Python alpha/beta releases being unavailable. I thought that the Linux
philosophy was that you could always just build from source?


> Moreover, it became common to ask multiple
> changes and 

[Python-Dev] Re: Please update Cython *before* introcuding C API incompatible changes in Python

[Guido van Rossum]

On Tue, Feb 1, 2022 at 5:52 PM Stefan Behnel  wrote:

> Guido van Rossum schrieb am 02.02.22 um 01:43:
> Yes. HPy is certainly far from ready for anything real, but even for the
> Limited API, it's still unclear whether it's actually complete enough to
> cover Cython's needs. Basically, the API that Cython uses must really to
> be
> able to implement CPython on top of itself. And at the same time interact
> not with the reimplementation but with the underlying original, at the C
> level. The C-API, and especially the Limited API, were never really meant
> for that.
>

Undoubtedly.

My question for you is if you're willing to write up a list of things in
CPython that you depend on. Or is this just something you're not willing to
commit to? It would be nice to know which it is, just so the CPython team
knows what we're up against. And if you just want to retain the freedom to
use any and all CPython internals you can gain access to, maybe (a) Cython
users should be told, so they can be prepared for the consequences, and (b)
you should probably just #define the C preprocessor symbols that let you
#include the truly internal headers so you can do what you want.

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

[Python-Dev] Re: Please update Cython *before* introcuding C API incompatible changes in Python

[Guido van Rossum]

On Tue, Feb 1, 2022 at 4:14 PM Stefan Behnel  wrote:

> Guido van Rossum schrieb am 02.02.22 um 00:21:
> > I wonder if a solution during CPython's rocky alpha release cycle could
> be
> > to default (either in Cython or in projects using it) to the "not quite
> as
> > fast but not relying on a lot of internal APIs" mode, and to switch to
> > Cython's faster mode only once (a) beta is entered and (b) Cython has
> been
> > fixed to work with that beta?
>
> This seems tempting – with the drawback that it would make Cython modules
> less comparable between final and alpha/beta CPython releases. So users
> would start reporting ghost performance regressions because it
> (understandably) feels important to them that the slow-down they witness
> needs to be resolved before the final release, and they just won't know
> that this will happen automatically triggered by the version switch. :)
>

It sounds like you are speaking from experience here, so I won't argue.


> Feels a bit like car manufacturers who switch their exhaust cleaners on
> and
> off based on the test mode detection.
>

That would be more like detecting benchmarks and doing something different.
In terms of the car manufacturing process, we're talking about testing next
year's model before production has started up yet. If the new model uses
more gas than last year's, that would be a problem that needs to be solved
before production starts, but what we seem to have with Cython is more like
the new model's doors don't open. :-)

It may be hard to imagine if you're working on Cython, which only exists
because of performance needs, but there are other things that people want
to test with the upcoming CPython release in addition to performance (are
the seats comfortable? do the controls for the moonroof work?), and given
the long dependency chains in modern apps and packages, people want to get
started on those things early. Until numpy builds with Cython for CPython
3.11, nobody can start testing scikit-learn with CPython 3.11, and that's
frustrating for the scikit-learn maintainers.


> More importantly, though, we'd get less bug reports during the alpha/beta
> cycle ourselves, because things may look like they work but can still stop
> working when we switch back to fast mode.
>

True, true. Nobody's perfect.


> I'd rather make it more obvious to users what their intentions are. And
> there is already a way to do that – the Limited API. (and similarly, HPy)
>

Your grammar confuses me. Do you want users to be clearer in expressing
their intentions?


> For Cython, support for the Limited API is still work in progress,
> although
> many things are in place already. Getting it to work completely would give
> users a simple way to decide whether they want to opt in for a) speed,
> lots
> of wheels and adaptations for each CPython version, or b) less
> performance,
> less hassle.
>

But until that work is complete, we're stuck with the unlimited API, right?
And by its own statements in a recent post here, HPy is still not ready for
all use cases, so it's also still a pipe dream.


> As it looks now, that switch can be done after the code generation, by
> defining a simple C define in their build script. That also makes both
> modes easily comparable. I think that is as good as it can get.
>

Do you have specific instructions for package developers here? I could
imagine that the scikit-learn maintainer (sorry to pick on you guys :-)
might not know where to start with this if until now they've always been
able to rely on either numpy wheels or building everything from source with
default settings.

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

[Python-Dev] Re: Please update Cython *before* introcuding C API incompatible changes in Python

[Guido van Rossum]

Hm... So maybe the issue is either with Cython's default settings (perhaps
traditionally it defaults to "as fast as possible but relies on internal
APIs a lot"?) or with the Cython settings selected by default by projects
*using* Cython?

I wonder if a solution during CPython's rocky alpha release cycle could be
to default (either in Cython or in projects using it) to the "not quite as
fast but not relying on a lot of internal APIs" mode, and to switch to
Cython's faster mode only once (a) beta is entered and (b) Cython has been
fixed to work with that beta?

Sure, occasionally things still change during beta, but the point of beta
is that things shouldn't change unless it is to fix bugs. On behalf of the
Faster CPython project I can commit to that for our contributions, we'll do
our advanced work on the 3.12 branch once 3.11beta has started.

All this is assuming that Cython's default can be adjusted independently
for CPython's upcoming release (3.11, for now) and separately for previous
releases (3.10 and before). But if it can't yet, surely *that* would be a
relatively simple change?

On Tue, Feb 1, 2022 at 3:07 PM  wrote:

> Greg Ewing wrote:
> > To address this there could be an option to choose between
> > "compatible code" and "fast code", with the former restricting
> > itself to the stable API.
>
> To some extent, that exists at the moment - many of the real abuses of the
> CPython internals can be controlled by setting C defines. For the
> particular feature that caused this discussion the majority of the uses can
> be turned off by defining CYTHON_USE_EXC_INFO_STACK=0 and
> CYTHON_FAST_THREAD_STATE=0. (There's still a few uses relating to
> coroutines, but those too flags are sufficient to get Cython to build
> itself and Numpy on Python 3.11a4).
>
> Obviously it could still be better. But the desire to support PyPy (and
> the beginnings of the limited API) mean that Cython does actually have
> alternate "clean" code-paths for a lot of cases.
> ___
> 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/Q3IQUKU35GNCUXBCK55JZ3B42LSVS2M2/
> 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/FUA5JDEN6374FDOZQWPZYHXH5E3U4V24/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Please update Cython *before* introcuding C API incompatible changes in Python

[Guido van Rossum]

It seems to me that a big part of the problem is that Cython feels entitled
to use arbitrary CPython internals. Another part is that there doesn't seem
to be any Cython maintainer interested in communicating with the core devs
who are changing those CPython internals. We have to resort to creating
issues in the Cython tracker and wait weeks before someone responds, and
often not in a supportive way.

I am fully aware that Cython is an important tool in our ecosystem. But
before I agree that we should roll back things "because it breaks Cython" I
would like to see a lot more participation in CPython's development by
Cython developers. (Who are they even? I only know "scoder" -- who else can
speak authoritatively on behalf of Cython?)

During a beta cycle I would see the roles reversed. But until late May we
are still working on alphas. If Cython wants to wait until beta 1 that's
fine, but then their input on the design of CPython changes is necessarily
much more limited.

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

[Python-Dev] Re: Increase of Spammy PRs and PR reviews

[Guido van Rossum]

Okay, now you might as well state which person you are talking about. Who
says their mentor hasn't encouraged them to do this?

On Mon, Jan 31, 2022 at 12:32 PM Lrupert via Python-Dev <
python-dev@python.org> wrote:

> > Gaming the system doesn't end up working well in the end anyway. The
> first time the gamers try to get a job interview and can't explain how
> they'd do a code review—something GitHub says they've done hundreds or
> thousands of times—the whole thing will fail.
>
> Observably, it feels like they are doing this for core privileges (if they
> don't already exist, they are a member of the python org?). Every time I
> see one of those PRs (e.g add test for X, add delete redundant variables
> for Y), the author seem to be cc-ing their mentor. This gives a bad
> impression to others about their intentions (constant contribution of
> trivial / low quality stuff with little-to-no-gain to achieve a higher
> number of commits, since it is a visible metric).
>
> ___
> 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/JZBQ2UYTXDCHADW4LEPGPE5SFLRHW5E3/
> 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/EU3YC4IU3BYTHNZIT26QQOGYFYCAQZGJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Increase of Spammy PRs and PR reviews

[Guido van Rossum]

Ah, now I see the section on GitHub user home pages. Honestly if employers
just take a glance at that they get what they deserve. I don't want to
worry about this, there are enough real problems.

On Mon, Jan 31, 2022 at 8:48 AM Brian Curtin  wrote:

> I was using points in a more generic sense, making your "contribution
> activity overview" look nicer—I wasn't sure if "points" was an actual thing
> or not, so maybe I'm speaking out of turn. Mine shows 70% of my actions are
> code review, then issues, commits, and PRs are 10% each.
>
> On Mon, Jan 31, 2022 at 9:40 AM Guido van Rossum  wrote:
>
>> Where does it say that a review gives you points? The GitHub blog post I
>> saw about the subject only mentions commits.
>>
>> On Mon, Jan 31, 2022 at 8:16 AM Brian Curtin  wrote:
>>
>>> On Sun, Jan 30, 2022 at 8:42 AM Mats Wichmann  wrote:
>>>
>>>> On 1/30/22 04:45, Inada Naoki wrote:
>>>> > On Sun, Jan 30, 2022 at 7:37 PM Irit Katriel <
>>>> iritkatr...@googlemail.com> wrote:
>>>>
>>>> > Some people may do "approval without review" to make their "Profile"
>>>> > page richer, because GitHub counts it as a contribution.
>>>> > Creating spam issues or pull requests can be reported as spam very
>>>> > easily. But "approve without review" is hard to be reported as spam.
>>>> > So approving random issue is the most easy way to earn contributions
>>>> > without reported as spam.
>>>>
>>>> Whnever there are metrics, some will find a way to game the system to
>>>> make theirs look better - this certainly isn't limited to github, or to
>>>> tech, or in any way a recent thing.
>>>>
>>>
>>> Certainly true, and I think this is more of a social problem than a
>>> technical one. If people are giving out review approvals to get more
>>> points, you (where 'you' is a person with some privileges on the repo) can
>>> click "dismiss review" and get rid of the noise, at least within that PR.
>>> Maybe they still get points for the review, I'm not sure. Taking away the
>>> ability for non-core contributors to offer official review approvals to
>>> stop people like that only harms the people actually trying to do good work.
>>>
>>> Gaming the system doesn't end up working well in the end anyway. The
>>> first time the gamers try to get a job interview and can't explain how
>>> they'd do a code review—something GitHub says they've done hundreds or
>>> thousands of times—the whole thing will fail.
>>> ___
>>> 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/R3YU44XPWLBUWVLSYTTTWJZCSRRCB67F/
>>> 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/>
>>
>

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

[Python-Dev] Re: Increase of Spammy PRs and PR reviews

[Guido van Rossum]

Where does it say that a review gives you points? The GitHub blog post I
saw about the subject only mentions commits.

On Mon, Jan 31, 2022 at 8:16 AM Brian Curtin  wrote:

> On Sun, Jan 30, 2022 at 8:42 AM Mats Wichmann  wrote:
>
>> On 1/30/22 04:45, Inada Naoki wrote:
>> > On Sun, Jan 30, 2022 at 7:37 PM Irit Katriel <
>> iritkatr...@googlemail.com> wrote:
>>
>> > Some people may do "approval without review" to make their "Profile"
>> > page richer, because GitHub counts it as a contribution.
>> > Creating spam issues or pull requests can be reported as spam very
>> > easily. But "approve without review" is hard to be reported as spam.
>> > So approving random issue is the most easy way to earn contributions
>> > without reported as spam.
>>
>> Whnever there are metrics, some will find a way to game the system to
>> make theirs look better - this certainly isn't limited to github, or to
>> tech, or in any way a recent thing.
>>
>
> Certainly true, and I think this is more of a social problem than a
> technical one. If people are giving out review approvals to get more
> points, you (where 'you' is a person with some privileges on the repo) can
> click "dismiss review" and get rid of the noise, at least within that PR.
> Maybe they still get points for the review, I'm not sure. Taking away the
> ability for non-core contributors to offer official review approvals to
> stop people like that only harms the people actually trying to do good work.
>
> Gaming the system doesn't end up working well in the end anyway. The first
> time the gamers try to get a job interview and can't explain how they'd do
> a code review—something GitHub says they've done hundreds or thousands of
> times—the whole thing will fail.
> ___
> 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/R3YU44XPWLBUWVLSYTTTWJZCSRRCB67F/
> 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/WZOOZ5O6TDBISB3VQ7HTCMEUGGEV63A2/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Guido van Rossum]

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

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

Can HPy do that?

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

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


-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*
<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/NOLJUPUZIIVXBLSZCENVYM5WYHOQS2DB/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Guido van Rossum]

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

[Python-Dev] Re: Is anyone using 15-bit PyLong digits (PYLONG_BITS_IN_DIGIT=15)?

[Guido van Rossum]

On Sun, Jan 16, 2022 at 2:21 PM Tim Peters  wrote:

> I have to believe the same is true under Visual Studio 2019, but
> offhand don't know how to prove that. I understand Steve uses PGO to
> build the python.org Windows release, but I've never done that - the
> "Release build" configuration I get from Github does not use PGO, and
> the code I get from my own "release builds" is equally slow for all
> divisors (and the generated assembler is obviously not trying to
> special-case anything).
>

I don't think there's a way to do a PGO build from Visual Studio; but a
command prompt in the repo can do it using `PCbuild\build.bat --pgo`. Just
be patient with it.

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

[Python-Dev] Re: Is anyone using 15-bit PyLong digits (PYLONG_BITS_IN_DIGIT=15)?

[Guido van Rossum]

As a bystander, this is all fascinating (I had actually anticipated that
the //10 optimization came from PGO).

Does the optimization for //10 actually help in the real world? It would if
people did a lot of manual conversion to decimal, which is easiest
expressed using //10. But presumably for that people mostly end up using
str() or repr(), which has its own custom code,
long_to_decimal_string_internal().

Then again I'm not sure what's *lost* even if this optimization is
pointless -- surely it doesn't slow other divisions down enough to be
measurable.

On Sun, Jan 16, 2022 at 12:35 PM Mark Dickinson  wrote:

> On Sun, Jan 16, 2022 at 12:08 PM Mark Dickinson 
> wrote:
>
>> So gcc is anticipating divisions by 10 and introducing special-case
>> divide-by-reciprocal-multiply code for that case, and presumably the
>> profile generated for the PGO backs up this being a common enough case, so
>> we end up with the above code in the final compilation.
>>
>
> Nope, that's not what's happening. This analysis is backwards, and
> unfairly attributes to GCC the apparently arbitrary choice to
> optimise division by 10. But it's not GCC's fault; it's ours. What's
> *actually* happening is that GCC is simply recording values for n used in
> calls to divrem1 (via the -fprofile-values option, which is implied by
> -fprofile-generate, which is used as a result of the --enable-optimizations
> configure script option). It's then noticing that in our profile task
> (which consists of a selection of Lib/test/test_*.py test files) we most
> often do divisions by 10, and so it optimizes that case.
>
> To test this hypothesis I added a large number of tests for division by 17
> in test_long.py, and then recompiled from scratch (again with
> --enable-optimizations). Here are the results:
>
> root@341b5fd44b23:/home/cpython# ./python -m timeit -n 100 -s
> "x=10**1000; y=10" "x//y"
>
> 100 loops, best of 5: 1.14 usec per loop
>
> root@341b5fd44b23:/home/cpython# ./python -m timeit -n 100 -s
> "x=10**1000; y=17" "x//y"
>
> 100 loops, best of 5: 306 nsec per loop
>
> root@341b5fd44b23:/home/cpython# ./python -m timeit -n 100 -s
> "x=10**1000; y=1" "x//y"
>
> 100 loops, best of 5: 1.14 usec per loop
>
> root@341b5fd44b23:/home/cpython# ./python -m timeit -n 100 -s
> "x=10**1000; y=2" "x//y"
>
> 100 loops, best of 5: 1.15 usec per loop
>
> As expected, division by 17 is now optimised; division by 10 is as slow as
> division by other small scalars.
>
> --
> Mark
>
> ___
> 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/2MOQCVMEQBV7PATT47GUYHS42QIJHTRK/
> 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/67DXYX3YLMDC5R4X6FI3NMRT2TGZDZHC/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Guido van Rossum]

On Thu, Jan 13, 2022 at 8:18 AM Matthew Rahtz  wrote:

> Thanks also Kevin for this feedback!
>
> Good point about being careful to distinguish type parameters vs type
> arguments. If I understand correctly, you're making two points:
>
> 1. The wording of the 'Multiple Type Variable Tuples: Not Allowed' section
> - you're saying that we're being a bit imprecise here in saying that we
> disallow multiple TypeVarTuples in a type parameter list, given that in
> e.g. `def f(x: *Ts1, y: *Ts2)`, both Ts1 and Ts2 are members of the
> parameter list for the function f, but there it's unambiguous, so in fact
> it *is* allowed.
>

That looks like a syntax error. We only allow *Ts if the argument is of the
form *a. `def f(x: *Ts1)` is not allowed.

Maybe you were thinking of `def f(x: Array[*Ts1], y: Array[*Ts2]) as the
example? That seems unambiguous since the two positional arguments are
given separately.

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

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

[Guido van Rossum]

when we try to assign type arguments [Height] to the unique list of type
> variables [Ts1, Ts2], I think we should end up with Ts1 containing Height
> and Ts2 being empty; thus:
>
> TwoArrays[Height]  # Valid; equivalent to Tuple[Array[Height], Array[()]]
>

I hope not.


> But I actually can't get this to type check correctly in Pyre. Pradeep,
> this is the test I was using:
> https://gist.github.com/mrahtz/cc86c29538de1d4a80a2e8958ae71c5a Am I
> doing something wrong?
>
> Also, by that logic, in this situation *all* the type arguments would be
> assigned to Ts1, and Ts2 would always end up being empty. That seems a bit
> weird but...*shrug* it also seems correct.
>

No?


> In any case, this is definitely something we should explain better in the
> PEP. I'll make a TODO for myself to write something on this once Pradeep
> and Guido have confirmed whether my understanding is correct.
>


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

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

[Guido van Rossum]

On Wed, Jan 12, 2022 at 4:57 AM Petr Viktorin  wrote:

> Matthew Rahtz wrote:
> > Hi everyone,
> >
> > We've got to the stage now with PEP 646 that we're feeling pretty happy
> > with it. So far though we've mainly been workshopping it in typing-sig,
> so
> > as PEP 1 requires we're asking for some feedback here too before
> submitting
> > it to the steering council.
> >
> > If you have time over the next couple of weeks, please take a look at the
> > current draft and let us know your thoughts:
> > https://www.python.org/dev/peps/pep-0646/ (Note that the final couple of
> > sections are out of date; https://github.com/python/peps/pull/1880
> > clarifies which grammar changes would be required, now that PEP 637 has
> > been rejected. We also have a second PR in progress at
> > https://github.com/python/peps/pull/1881 clarifying some of the
> motivation.)
> >
> > Thanks!
> > Matthew and Pradeep
>
> Hi,
> I'm very late to the discussion -- I relied on the typing-sig and SC to
> handle this, but now that I'm on the SC, I no longer have that luxury :)
> This mail has my own opinions, not necessarily the SC's.
>
>
> I've read the PEP, and I quite like it! It's clear that typing-sig
> thought this through very well.
> The thing that surprised me is the proposed changes that affect more
> than typing annotations. Quite deep in the PEP, the "Grammar Changes"
> section explains the (quite exciting) change to make star-unpacking
> possible in normal indexing operations, e.g.::
>
>  idxs_to_select = (1, 2)
>  array[0, *idxs_to_select, -1]  # Equivalent to [0, 1, 2, -1]
>
> However, the PEP is silent about indexing assignment, e.g.::
>
>  array[0, *idxs_to_select, -1] = 1
>
> IMO, it would be very confusing to not keep these in sync. If they are,
> the assignment change should be documented and tested appropriately. Is
> that the plan?
>

The previous SC approved the PEP despite this.

If you want to convince the SC to request this feature parity in the PEP, I
won't stop you.

But unless that happens I would rather not update the PEP again (it's been
tough to get to this point).

Maybe you can write a separate PEP? That would probably be simpler for all
involved (the PEP 646 authors would not have to be involved, and the
separate PEP would be very straightforward.


> For a second point, the PEP says:
>
> > this PEP disallows multiple unpacked TypeVarTuples within a single type
> parameter list. This requirement would therefore need to be implemented in
> type checking tools themselves rather than at the syntax level.
>
> Typing annotations are sometimes used for other things than *static*
> typing, and I wouldn't be surprised if type checkers themselves started
> allowing this (as a non-standard extension in cases where things aren't
> ambiguous):
>
>  def tprod(Generic[*T1], Generic[*T2]) -> Generic[*T1, *T2]: ...
>

I don't think that sentence is trying to forbid this. The problem appears
in things like

def foo(*args: tuple[*Ts1, *Ts2]) -> ...

Maybe the wording in the PEP can be imrpoved?


> If multiple unpackings in a tuple aren't blocked by the compiler, they
> should be tested and documented as syntactically valid annotations --
> just not valid static typing annotations (even though other uses are
> currently deprecated). In particular, once the compiler allows multiple
> unpackings, disallowing them at the syntax level later would mean
> breaking backwards compatibility.
> Do we share that view?
>

Agreed that the syntax with multiple stars will not be deprecated at
runtime, but type checkers may reject it. (Just as type checkers reject
many other programs that would run fine.)


> And after reading the PEP again, I'm unclear on some details in the
> Aliases section. Could you please clarify these examples for me?
>
> SplitDataset = Tuple[Array[*Ts], Array[*Ts]]
> SplitDataset[Height]  # Valid? What would this be equivalent to?
>
>
> TwoArrays = Tuple[Array[*Ts1], Array[*Ts2]]
> TwoArrays[Height]  # Valid? Equivalent to what? How to specify this fully?
>

I'll leave this to the PEP authors to address.

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

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

[Guido van Rossum]

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.

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?)*
<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/35R3DCNPIQJ7ZCHTLP64IP2XZCK7QSLJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 679 – Allow parentheses in assert statements

[Guido van Rossum]

Note that Pablo explicitly requested all feedback to Discourse.

On Mon, Jan 10, 2022 at 06:15 Batuhan Taskaya  wrote:

> > While it can indeed, make otherwise stable projects with "nop"s assert
> sudden failing, that should be a trivial fix for any non-unmaintained
> project.
>
> Agreed. This would be like a bug fix. I don't think anyone is depending on
> the current behavior (beside explicit tests in linters, which is only a
> handful (2-3)). +1 to the PEP as well, which I find this restriction
> unnecessary.
>
> On Mon, Jan 10, 2022, 4:20 PM Joao S. O. Bueno 
> wrote:
>
>>
>>
>> On Mon, 10 Jan 2022 at 08:39, Victor Stinner  wrote:
>>
>>> Does someone know if linters like pylint or pylakes current warn on
>>> "assert(test, msg)" statements?
>>>
>>> If a project use such assertions which are always true, they can start
>>> failing wit the PEP 679, right?
>>
>>
>> OTOH, any assertion which start failing in this way, is a statement which
>> _should_ have been failing from the start, and was being ignored up to
>> this change.
>>
>> While it can indeed, make otherwise stable projects with "nop"s assert
>> sudden failing, that should be a trivial fix for any non-unmaintained
>> project.
>>
>> +1 to the change
>>
>>
>>
>>
>>> Hopefully, the fix is easy: removing
>>> the parenthesis give the same behavior on old and new Python versions.
>>>
>>> (it will behave the same just if the first expression is actually truish)
>>
>>
>>> Is it possible to run a code search on PyPI top 5000 projects to see
>>> if such always-true assertion is common or not?
>>>
>>> Victor
>>>
>>> On Mon, Jan 10, 2022 at 1:22 AM Pablo Galindo Salgado
>>>  wrote:
>>> >
>>> > Hi everyone,
>>> >
>>> > I would like to start a discussion about a small PEP proposal to allow
>>> parentheses in
>>> > assert statements to fix a common gotcha with assert statements.
>>> >
>>> > Link to the PEP: https://www.python.org/dev/peps/pep-0679/
>>> >
>>> > Please, redirect all discussions to:
>>> >
>>> >
>>> https://discuss.python.org/t/pep-679-allow-parentheses-in-assert-statements/13003
>>> >
>>> > as I will not be monitoring answers to this thread.
>>> >
>>> > Thanks, everyone for your time!
>>> >
>>> > Regards from cloudy London,
>>> > Pablo Galindo Salgado
>>> > ___
>>> > Python-Dev mailing list -- python-dev@python.org
>>> > To unsubscribe send an email to python-dev-le...@python.org
>>> > https://mail.python.org/mailman3/lists/python-dev.python.org/
>>> > Message archived at
>>> https://mail.python.org/archives/list/python-dev@python.org/message/I7MKCD3GHJXCERFCZ2FD3X7IPAX6ASVK/
>>> > 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/LFQGI43BH3SWKHRBPO7T3DC6SEU5HMQ3/
>>> 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/SFBWV5SAFYRFEASNJZJIRY4VUPIEOX24/
>> 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/FOZDTZFT4EGS3UUDF6GGVKA65DF6COH7/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
-- 
--Guido (mobile)
___
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/36GLLZYP46CINXWL5QXRWKZ67G7GKJZH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Is anyone using 15-bit PyLong digits (PYLONG_BITS_IN_DIGIT=15)?

[Guido van Rossum]

uture with simpler better code here we come.
>
> -gps
>
>
>>
>> --
>> Mark
>>
>> ___
>> 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/F53IZRZPNAKB4DUPOVYWGMQDC4DAWLTF/
>> 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/5RJGI6THWCDYTTEPXMWXU7CK66RQUTD4/
> 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/ZUF5V7N2K65MNWANO5SH4BTQPEC52OX5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Function Prototypes

[Guido van Rossum]

There were multiple threads about this (or maybe the thread was split by
mailers) and I already stated that the colon-free (and hence body-less)
syntax with def is too confusing to consider. Please look it up in the
archives. Happy Holidays!

On Thu, Dec 23, 2021 at 18:36 Steven D'Aprano  wrote:

> On Thu, Dec 23, 2021 at 05:09:18PM -0800, Guido van Rossum wrote:
>
> > > def func(params)
> > >
> > > makes a Callable type object?
> > >
> >
> > No, no, no. That syntax has already been discredited.
>
> It has? Where? Have I missed something?
>
> This thread is about using that syntax as an alternative to Mark's
> proposal. If it is already ruled out, then somebody should mention it
> to asleep.cult (the original poster of this thread).
>
> I'm curious: what objections to asleep.cult's proposal don't equally
> apply to Mark's proposal? From what I can see, Mark's original proposal
> has all the same disadvantages, plus it is even more verbose.
>
> Dropping the need for the @Callable decorator reduces the level of
> verbosity somewhat (one less line, nine fewer characters) but all the
> other negatives remain.
>
> Honestly, I cannot see a single positive to using `def` statements.
> Sure, we can do it, and an experienced programmer could infer the
> meaning of it, but given the choice of writing an anonymous type in
> place where you want it, versus having to pre-declare a function
> prototype with a name that adds nothing to the readability of the code
> before using it, why would I prefer the `def` version?
>
> This is not a rhetorical question.
>
> The fact that the existing feature (Callable) and the PEP 677 arrow
> syntax are anonymous, and can be written in place rather than needing to
> be pre-declared with a name, are positives. *Requiring* a name to use
> this `def` syntax is a point against it.
>
> If I need a named type alias, I can already create one, and name it:
>
> IntToIntFunc = Callable[[int], int]
>
> and while I can see that there are complicated signatures where a named
> alias would be useful:
>
> FileOpener = Callable[ ... ] # complicated signature
>
> we can already do that, so the `def` syntax adds nothing. For simple
> cases we don't need a name. The name IntToIntFunc adds nothing that
> isn't just as clear, if not more so, in the signature itself. It is like
> the comment:
>
> x += 1  # add one to x
>
>
> > Mark's proposal was
> > ```
> > @Callable
> > def func(params): pass
> > ```
>
> Indeed, and I already wrote a criticism of that proposal.
>
> Removing the decorator saves one line and nine characters, but the other
> criticisms remain.
>
>
> > My question is, why does it need `@Callable`? 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).
>
> But without the Callable decorator, it isn't a type, its a function.
> You're just using it as a type (or to be precise, a function prototype).
>
> I'm okay with naming conventions reflecting usage (we sort of already do
> that, with int, float, etc) but we should be clear about what's really
> happening. `def` creates a function.
>
>
> --
> 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/VTOOJLPU2HPIW6TQBBYTW64W4DFGCQEG/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
-- 
--Guido (mobile)
___
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/O4RHT7JW7VGWUQSQ3QFVVP6XYQGJKVQI/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Function Prototypes

[Guido van Rossum]

Yes, and yes. (Or the PEP could say it has to be ‘…’ and static checkers
could enforce it. But checkers already carry everything they need to check
this with them, for checking calls.)

Downside of this idea is that it requires you to invent a name for every
callable type you use.


On Thu, Dec 23, 2021 at 17:37 Barry Warsaw  wrote:

> On Dec 23, 2021, at 17:09, Guido van Rossum  wrote:
> >
> > Mark's proposal was
> > ```
> > @Callable
> > def func(params): pass
> > ```
> > My question is, why does it need `@Callable`? 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))
> > ```
>
> That seems pretty intuitive to me.  The conventions you mention would be
> just that though, right?  I.e. `pass` could be used, but whatever the body
> is it would be ignored for type checking `twice()` in this case, right?
>
> -Barry
>
>
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/BRYQ26TIYPITNDOYYYGBDFS5EYEOZVUA/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
-- 
--Guido (mobile)
___
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/WW6QAPAZ2RTCWSSK2XJIJP3VWVHCOL7Q/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Function Prototypes

[Guido van Rossum]

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`? 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))
```


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

[Python-Dev] Re: Function Prototypes

[Guido van Rossum]

Without decorator too (that was Lukasz’ idea). Why bother with the
decorator (*if* we were to go there)?

On Thu, Dec 23, 2021 at 13:16 Joao S. O. Bueno 
wrote:

> My eyes are bleeding with these incomplete function definitions.
> If you are using decorators and "def", then, please, there is  no
> need for special syntax that would just be a syntax error
> in "normal"Python., Just add ": pass" to the end.
>
> If eyes bleeding is not enough of an argument for you:
> the new syntax would only be possible be usable in code
> that would run on Python 3.11 and above. While using
> the decorator + function declaration syntax, you have the
> annotations that could readly be checked and code compatible with
> existing all supported Python versions, right out of the box.
>
> On Thu, 23 Dec 2021 at 16:31, MRAB  wrote:
>
>> On 2021-12-23 19:04, asleep.c...@gmail.com wrote:
>> > Hello and thank you for the much needed feedback.
>> >
>> > One thing that you must consider is that function prototypes
>> > have a few implications beyond typing but it seems like you're
>> > only looking at it as a tool for type hinting. The interpreter will
>> > create a function prototype object regardless of if you forget your
>> > decorator, it needs to pass something to the decorator after all.
>> >
>> > After reading through your reply, I am seeing that the main concern
>> > is the bloat added by the lambda keyword. My decision to use lambda
>> > instead of introducing a special syntax was one that required heavy
>> > deliberation. I ultimately decided to stick with lambda because it was
>> > consistent with the prototype statement form. The fact that lambda
>> > is hard to type has been felt by almost everyone who has ever used
>> > Python, this isn't just a problem that would be introduced by
>> > function prototypes. PEP 677 has taken the lazy approach to solving
>> > this issue and has prioritized type hinting over functionality. PEP 667
>> > also suggests the usage of => for lambdas which would likely
>> > never be accepted because of the confusion it would cause.
>> > As someone who has used typing with Python, I do think that a new
>> > callable syntax is needed, but I truly believe that PEP 677 is taking
>> the
>> > wrong approach.
>> >
>> > So what if we broke every Python program in existence by creating a
>> > new lambda syntax, how would it look? This question is particularly
>> > hard to answer because the body and annotations both need to be
>> > optional. Our best bet is an augmented form of the PEP 677 syntax
>> > that allows you to add a body. Here is an example:
>> >
>> > (a: int) -> int: a ** 2
>> >
>> > But of course this causes ambiguity when the return annotation and
>> > body are both omitted. One thing that I did consider is simply treating
>> > it like a tuple if there is no return annotation AND there is no body,
>> but
>> > that might lead to confusion. Another thing that I considered is a
>> different
>> > prefix than lambda:
>> >
>> > $(a: int) -> int: a ** 2
>> >
>> Usually the suggestion is to use 'def':
>>
>>  def (a: int) -> int: a ** 2
>> ___
>> 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/AKS4IHJJFDV24QZNMVMFZR72H5ORU3TB/
>> 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/BGQUJQCBW72WDGRKXT5JXKS2AEBS36OJ/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
-- 
--Guido (mobile)
___
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/KE55W466H433ECZ4GSSSW2AXNFHZFBC4/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Guido van Rossum]

Yeah, making the body optional (without looking at decorators) is not
acceptable either. Too easy to do by mistake (I still do this All. The.
Time. :-)

On Mon, Dec 20, 2021 at 2:19 PM  wrote:

> My proposal wasn't to make the body optional based on the presence of a
> decorator, but rather to return a "function prototype" iff the body does
> not exist (I probably should have made my made my own reply instead of
> piggybacking on his proposal). I also mentioned some form of expression to
> represent this,  similar to lambda. Maybe a friendly error message telling
> the user to use a function when this thing is called would alleviate some
> confusion? I'm not sure how one would forget to add the function body
> anyway.
> ___
> 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/3HJY6VGLIWRJ7F4BZBNGNCSJJTXH3CVM/
> 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/6OCPFRM5UCRTUOZ2KFMG6ZV4XMS3YNJD/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Guido van Rossum]

On Mon, Dec 20, 2021 at 12:44 PM  wrote:

> This is such a great idea that I think it deserves its own PEP (to compete
> with this one?) Let me explain. PEP 677 was created for the sole purpose of
> replacing typing.Callable, but there are still some other areas where
> function metadata is required. What if we instead introduced a function
> prototype that allows you to "declare" a "function" without a body.
>
> typing example:
>
> import typing
>
> @typing.Callable
> def IntToIntFunc(a: int) -> int
>
> def flat_map(
> l: list[int],
> func: IntToIntFunc
> ) -> list[int]:
> ...
>
> ctypes example:
>
> import ctypes
>
> @ctypes.CFUNCTYPE
> def f(x: int) -> bool
>
> But of course this comes with a few issues: should it be an expression and
> if so, should the name be optional? How can ParamSpec be handled?
>

Allowing 'def' without a body based on the presence or absence of a
decorator sounds like it will just confuse people and cause bizarre errors
if people accidentally leave out a body. Let's not go there.

However, Lukasz has already proposed a very similar mechanism (with dummy
body), without needing a decorator. His proposal is simply:

def IntToIntFunc(a: int) -> int: ...

def flat_map(l: list[int], func: IntToIntFunc) -> list[int]:
# body

No need for a `@Callable` decorator!

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

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

[Guido van Rossum]

On Mon, Dec 20, 2021 at 12:16 PM Barry Warsaw  wrote:

> On Dec 20, 2021, at 11:34, Guido van Rossum  wrote:
> >
> > Fair enough. Quick design proposal:
> >
> >   -h and --help print info about flags (existing flags)
> >   --help-env (or --env-help?) prints info about env vars (new flag)
> >   -X help prints info about -X options (new -X option)
> >
> > Two lines printed at the end of the -h/--help output would refer users
> to --help-env and -Xhelp.
>
> +1, and —help-env seems better.
>

Sure.

What do you think about -hh (and maybe —help-full) printing full help?
>

Is there enough of a use case for this to bother?

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

[Python-Dev] Re: About the new CFrame structure

[Guido van Rossum]

Hi Gabriele,

I think the code is currently the only documentation, since this is
considered a CPython internal issue. I'm CC'ing Mark Shannon, since he
designed this for 3.11.

For a bit of background, see this issue in the Faster CPython tracker:
https://github.com/faster-cpython/ideas/issues/31 -- maybe this will help
you understand the background (though what was implemented doesn't match
the discussion there precisely).

Since you seem to be the author of Austin, a sampling profiler for Python
code (which I presume itself is written in C or C++), I'm guessing you're
asking because you're looking to make Austin work with 3.11. (Actually, the
CFrame structure appears in 3.10, but it's not usable for unwinding stack
frames in 3.10, since the 3.10 version doesn't have a pointer to the
interpreter frame -- it's only used to speed up access to the `use-tracing`
flag. So I'm assuming you're asking about 3.10.)

One of the goals for the Faster CPython project that has only become in
focus for the team recently is helping tools like Austin (and others like
Cython, PyDev and Greenlets) that use internal interpreter state figure out
how to get their code working in 3.11, without making too many commitments
to stable APIs -- we're already thinking about more performance
improvements in 3.12 and beyond, which most likely will require us to
change the internal data structures again. (We do commit to leaving these
internal data structures unchanged for bugfix release cycles, so that once
you've got it working for 3.11.0, it should work without changes for
3.11.1, 3.11.2, etc. In fact we hope to stabilize everything starting with
the release of 3.11b1, May 2020.)

Oh, I see that Brandt has already given a better overview of how this stuff
actually works (he's a faster typist than me :-), so I'll just sign off
here. If you have more specific questions, you can continue this thread, or
you can create a new Discussion item in the
https://github.com/faster-cpython/ideas repo.

--Guido



On Mon, Dec 20, 2021 at 10:25 AM Gabriele  wrote:

> Hi there
>
> I hope you would indulge me in asking for some details about the new
> CFrame structure, even in the form of existing literature (e.g. PEP)
> where the idea behind it is explained.
>
> Also, I'd like to a quick question, if I may. There now appear to be
> two ways of unwinding the frame stack: either iterate over
> CFrame.previous, or the more traditional PyFrameObject.f_back. I
> suspect there are reasons why these are perhaps not actually
> equivalent, and indeed this is mainly what I'd like to read in the
> literature I've requested above.
>
> Cheers,
> Gabriele
>
> --
> "Egli è scritto in lingua matematica, e i caratteri son triangoli,
> cerchi, ed altre figure
> geometriche, senza i quali mezzi è impossibile a intenderne umanamente
> parola;
> senza questi è un aggirarsi vanamente per un oscuro laberinto."
>
> -- G. Galilei, Il saggiatore.
> ___
> 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/KQOQTLR5IXMJXYZGPDHWR32I2Z53UVBL/
> 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/5MUUF4FPKW5PANCUQ55C2ZYHSSRVLSFW/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Guido van Rossum]

On Mon, Dec 20, 2021 at 11:15 AM Brett Cannon  wrote:

>
>
> 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.
>

Fair enough. Quick design proposal:

  -h and --help print info about flags (existing flags)
  --help-env (or --env-help?) prints info about env vars (new flag)
  -X help prints info about -X options (new -X option)

Two lines printed at the end of the -h/--help output would refer users to
--help-env and -Xhelp.

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

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

[Guido van Rossum]

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.

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.

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

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

[Guido van Rossum]

It’s *needed* when multiple interpreters share them.

On Thu, Dec 16, 2021 at 14:03 Jim J. Jewett  wrote:

> Guido van Rossum wrote:
> > On Wed, Dec 15, 2021 at 6:57 PM Jim J. Jewett jimjjew...@gmail.com
> wrote:
> > > Immortal objects shouldn't be reclaimed by garbage collection, but they
> > > still count as potential external roots for non-cyclic liveness.
> > So everything referenced by an immortal object should also be made
> immortal
>
> Why?  As long as you can get a list of all immortal objects (and a
> traversal function from each), this is just an extra step (annoying, but
> tolerable) that removes a bunch of objects from the pool of potential
> garbage before you even begin looking for cycles.
>
> > -- even its type. Hence immortal objects must be immutable.
>
> This is probably a good idea, since avoiding changes also avoids races and
> Copy on Write and cache propagation, etc ... but I don't see why it is
> *needed*, rather than helpful.
>
> -jJ
> ___
> 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/4KY5XSHRMP3F3CWAW2OUW4NRXN4AB7EM/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
-- 
--Guido (mobile)
___
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/PBCVE2XUKBHZ3F463I3BIXEM33NLQNH3/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Guido van Rossum]

On Thu, Dec 16, 2021 at 3:08 AM Petr Viktorin  wrote:

> On 16. 12. 21 11:52, Victor Stinner wrote:
> > On Thu, Dec 16, 2021 at 2:29 AM Nathaniel Smith  wrote:
> >> On Wed, Dec 15, 2021 at 3:07 AM Victor Stinner 
> wrote:
> >>> I wrote https://bugs.python.org/issue39511 and
> >>> https://github.com/python/cpython/pull/18301 to have per-interpreter
> >>> None, True and False singletons. My change is backward compatible on
> >>> the C API: you can still use "Py_None" in your C code. The code gets
> >>> the singleton object from the current interpreter with a function
> >>> call:
> >>>
> >>>  #define Py_None Py_GetNone()
> >>>
> >>> Py_GetNone() is implemented as: "return
> _PyInterpreterState_GET()->none;"
> >>
> >> It's backward compatible for the C API, but not for the stable C ABI
> >> -- that exports Py_None directly as a symbol.
> >
> > You're right. But we can add a macro like Py_SUBINTERPRETER_API which
> > would change the implementation:
> >
> > * By default, "Py_None" would continue returning "&_Py_NoneStruct".
> > * If Py_SUBINTERPRETER_API macro is defined, Py_None would call
> Py_GetNone().
> >
> > => no impact on the stable ABI (if used, the stable ABI is not supported)
>
> The stable ABI could be orthogonal here -- you could compile for the
> stable ABI even with Py_SUBINTERPRETER_API.
>
> This would require (_PyInterpreterState_GET()->none == Py_None) in the
> "main" interpreter, and extrensions without Py_SUBINTERPRETER_API only
> loadable in the "main" interpreter.
>

That would slow things down a bit -- even if the pointer to the interpreter
state was already in a register, getting None would require loading the
pointer to Py_None from memory by indexing relative to that register.
Compared to a plain global, the latter would be a "load constant"
instruction, and Eric's other proposal (move the Py_None struct itself into
the interpreter state) would be just adding a constant to the register
(possibly the fastest solution, since that constant would be much smaller
than the full address of the global). Alas, that last version is not
compatible with the stable ABI. So I'm still in favor of trying harder to
make immortable objects a reality.

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

[Python-Dev] Re: Static types and subinterpreters running in parallel

[Guido van Rossum]

Eric has been looking into this. It's probably the only solution if we
can't get immutable objects. But I would prefer the latter, if we can get
the performance penalty low enough.

On Thu, Dec 16, 2021 at 2:31 AM Victor Stinner  wrote:

> Hi,
>
> One option to solve the https://bugs.python.org/issue40601 "[C API]
> Hide static types from the limited C API" issue without breaking the
> backward compatibility is to leave the C API and the stable ABI as
> they are for the main interpreter (static types), but force
> subinterpreters running in parallel to use their own heap types. It
> means that subinterpreters would be able to use the main interpreter
> GIL or own their GIL. By default, the GIL would still be shared.
>
> C extensions using "" (static type) would continue to work
> in the main interpreter.
>
> C extensions which want to opt-in for running subinterpreters in
> parallel would not access to "_Type" but be forced to call
> PyLong_GetType() (heap type).
>
> Internally, Python should be modified to replace "" with
> PyLong_GetType(). So the code would work with static types and heap
> types.
>
> It also means that a subinterpreter running in parallel would only be
> able to import C extensions built with explicit support for this
> feature. Otherwise, an ImportError would be raised.
>
> 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/QTY25AHCLOXRCQ2LADUUZFVKNVLLYS25/
> 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/R2R7AHGEWHIRXBQ2VT63E6E5PZGFFZTT/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Guido van Rossum]

On Wed, Dec 15, 2021 at 6:57 PM Jim J. Jewett  wrote:

> Immortal objects shouldn't be reclaimed by garbage collection, but they
> still count as potential external roots for non-cyclic liveness.
>

So everything referenced by an immortal object should also be made immortal
-- even its type. Hence immortal objects must be immutable. (There's an
issue with making types immutable that we need to address though.)


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

[Python-Dev] Re: my plans for subinterpreters (and a per-interpreter GIL)

[Guido van Rossum]

On Wed, Dec 15, 2021 at 2:57 PM Guido van Rossum  wrote:

>
> I don't know how long that would take, but I suspect that a program that
> just increments the refcount relentlessly would have to run for hours
> before hitting this range. On a 64-bit machine the same approach would
> require years to run before a refcount would exceed the maximum allowable
> imbalance. (These estimates are from Mark Shannon.)
>

Hm, not quite. I modified a fast builtin to incref its argument, and then I
called it in a `while True` loop, interrupted, and timed it. This did
~24,000,000 INCREFs/second. This would hit 0x_2000_ in about 9 minutes.
And I wasn't even trying that hard -- I could have written the loop in C.
(I did comment out an audit call though. :-) The same loop on 64-bit would
take 1700 years to reach the limit, so we're safe there.

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