[Python-Dev] Re: Should we try to get a complete draft of What's New by b1?

[Jack DeVries]

On a broader note, how does the deployment pipeline for documentation work?
It seems to me that for branches that are in pre-release (3.10) or active
development (3.11), the documentation should be continuously deployed,
while deployment of changes to earlier documentation should follow minor
releases for those versions.

Sorry this question is naive -- I don't know how it works currently. Would
it be possible to set something like this up?

On Thu, Aug 12, 2021, 3:02 AM Serhiy Storchaka  wrote:

> 11.08.21 21:35, Brett Cannon пише:
> > So my question is whether we want to push to be more diligent about
> > updating What's New by b1 so people can provide feedback during the
> > betas beyond just reporting breaking changes?
>
> I think that What's New should be updated as soon as possible,
> immediately after the addition of the feature. I started contributing to
> Python after reading What's New for one of early alphas of 3.3 (and the
> questioned feature was changed later). There were other examples, when
> features were advertised in alphas, but were changed after getting a
> feedback before betas.
>
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/RQQ2QEV3OKCMAJGHLB52SKXLAIL7BB34/
> 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/V7E6UQPHXQSQZQSDFBLOGTS4AGGGPLJF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations

[Guido van Rossum]

Maybe we could specialize the heck out of this and not bother with a
function object? In the end we want to execute the code, the function
object is just a convenient way to bundle defaults, free variables (cells)
and globals. But co_annotation has no arguments or defaults, and is only
called once. It does need to have access to the globals of the definition
site (the call site may be in another module) and sometimes there are cells
(not sure).

On Thu, Aug 12, 2021 at 1:14 AM Inada Naoki  wrote:

> Lazy loading code object solves only a half of the problem.
> I am worrying about function objects for annotation too.
>
> Function objects are heavier than code objects. And they are GC-tracked
> objects.
>
> I want to know how we can reduce the function objects created for
> annotation in PEP 649, before deprecating PEP 563.
>
> --
> Inada Naoki  
>


-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/3DBMQJMD6JOXIE2O3CVUIDOJX6GRYG4P/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Problems with dict subclassing performance

[Steven D'Aprano]

On Thu, Aug 12, 2021 at 08:26:47AM +0200, Marco Sulla wrote:
> No ideas? Excuse me for the up.

Perhaps you can be more concrete in what you expect from this mailing 
list.

Are you looking for upvotes on StackOverflow (or however it works 
there)? Or for some core dev to acknowledge that your analysis is 
correct? Something else?

Are you suggesting the current behaviour is buggy? You will probably get 
more responses if you make it more obvious what sort of response you are 
looking for.



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

[Python-Dev] Re: Problems with dict subclassing performance

[Paul Moore]

Has anyone raised this on bugs.python.org? That's the best way to get
something like this looked at, not via a post on Stack Overflow. The
SO posting didn't include a bpo link.
Paul

On Thu, 12 Aug 2021 at 07:33, Marco Sulla  wrote:
>
> No ideas? Excuse me for the up.
>
> On Fri, 6 Aug 2021 at 21:29, Marco Sulla  wrote:
> >
> > I've done an answer on SO about why subclassing `dict` makes the
> > subclass so much slower than `dict`. The answer is interesting:
> >
> > https://stackoverflow.com/questions/59912147/why-does-subclassing-in-python-slow-things-down-so-much
> >
> > What do you think about?
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-dev@python.org/message/ODHRCDEPOP3AUJJ6IKF2GFLOWJ5BY7TX/
> 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/BS3SWNUFGFRHGQFY5KKYJB5C2FHZNOAJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Should we try to get a complete draft of What's New by b1?

[Ned Deily]

On Aug 12, 2021, at 12:58, Jack DeVries  wrote:
> > If you look at the version picker on docs.python.org you will see that we 
> > already have the docs for 3.10 and 3.11 available. I don't know if they are 
> > updated per release right now or per commit.
> 
> I understand that they are available options. To clarify my suggestion, I 
> think that 3.11 should be updated on a per commit basis (continuous 
> deployment); including updating the what's new pages continuously. If that is 
> not done already, I'm curious if it is been looked into before, and whether 
> it might be possible to set things up like this?

This is mainly from memory so some of the details may be incorrect but it's 
pretty close. The Python docs on python.org come in various formats - on-line 
HTML and various downloadable formats - and in English as well as various 
translated versions. It takes multiple hours on a dedicated virtual server to 
build the complete set of doc products, so updates are done on different 
cycles. The complete set of document products in all languages for branches 
either in feature development (currently 3.11), pre-release (3.10), or bugfix 
(3.9) status, are built and published every 24 hours.  In addition, the on-line 
English html versions for these branches are re-built and published every 3 
hours. Docs for security-fix branches (3.8, 3.7, 3.6) are generally only 
re-built when new releases are made. We also produce archived copies of the 
documentation current as of each release (https://www.python.org/doc/versions/).

Julien Palard is the release team documentation expert who manages the doc 
build and translation processes, along with the PSF IT team headed by Ee 
Durbin. There is some information (not quite up-to-date) in the Dev Guide. The 
infrastructure code is primarily in https://github.com/python/docsbuild-scripts 
and https://github.com/python/psf-salt.

--
  Ned Deily
  n...@python.org -- []

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/KMOSFHHTHRZ6Y7I2QPIRTMDNVGDLKYCG/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Should we try to get a complete draft of What's New by b1?

[Brett Cannon]

On Thu, Aug 12, 2021 at 6:04 AM Jack DeVries  wrote:

> On a broader note, how does the deployment pipeline for documentation
> work? It seems to me that for branches that are in pre-release (3.10) or
> active development (3.11), the documentation should be continuously
> deployed, while deployment of changes to earlier documentation should
> follow minor releases for those versions.
>
> Sorry this question is naive -- I don't know how it works currently. Would
> it be possible to set something like this up?
>

If you look at the version picker on docs.python.org you will see that we
already have the docs for 3.10 and 3.11 available. I don't know if they are
updated per release right now or per commit.

-Brett


>
> On Thu, Aug 12, 2021, 3:02 AM Serhiy Storchaka 
> wrote:
>
>> 11.08.21 21:35, Brett Cannon пише:
>> > So my question is whether we want to push to be more diligent about
>> > updating What's New by b1 so people can provide feedback during the
>> > betas beyond just reporting breaking changes?
>>
>> I think that What's New should be updated as soon as possible,
>> immediately after the addition of the feature. I started contributing to
>> Python after reading What's New for one of early alphas of 3.3 (and the
>> questioned feature was changed later). There were other examples, when
>> features were advertised in alphas, but were changed after getting a
>> feedback before betas.
>>
>> ___
>> Python-Dev mailing list -- python-dev@python.org
>> To unsubscribe send an email to python-dev-le...@python.org
>> https://mail.python.org/mailman3/lists/python-dev.python.org/
>> Message archived at
>> https://mail.python.org/archives/list/python-dev@python.org/message/RQQ2QEV3OKCMAJGHLB52SKXLAIL7BB34/
>> 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/V7E6UQPHXQSQZQSDFBLOGTS4AGGGPLJF/
> 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/YS3354SXYCFFD7ZQWQQZEYY4YCUMPFYH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations

[Larry Hastings]

On 8/12/21 8:25 AM, Guido van Rossum wrote:
Maybe we could specialize the heck out of this and not bother with a 
function object? In the end we want to execute the code, the function 
object is just a convenient way to bundle defaults, free variables 
(cells) and globals. But co_annotation has no arguments or defaults, 
and is only called once. It does need to have access to the globals of 
the definition site (the call site may be in another module) and 
sometimes there are cells (not sure).


Yes, there are sometimes cells.

   def foo():
    my_type = int
    def bar(a:my_type):
    return a
    return bar

Both bar() and the co_annotations function for bar() are nested 
functions inside foo, and the latter has to refer to the cell for 
my_type.  Also, co_annotations on a class may keep a reference to the 
locals dict, permitting annotations to refer to values defined in the class.



I don't know if it's worth making a specialized object as you suggest.  
I'd forgotten I did this, but late in the development of the 649 
prototype, I changed it so the co_annotations function is /always/ 
lazy-bound, only constructed on demand.


There are three possible blobs of information the descriptor might need 
when binding the co_annotations function:


 * the co_annotations code object,
 * the tuple of cells, when co_annotations is a closure, and
 * the locals dict, when co_annotations is defined inside a class and
   might refer to names defined in the class.

The code object is always necessary, the other two are optional. If we 
only need the code object, we store that code object inside the function 
object and we're done.  If we need either or both of the other two 
blobs, we throw all the blobs we need in a tuple and store the tuple 
instead.  At the point that someone asks for the annotations on that 
object, the descriptor does PyType_ checks to determine which blobs of 
data it has, binds the function appropriately, calls it, and returns the 
result.  I think this approach is reasonable and I'm not sure what a 
custom callable object would get us.



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

[Python-Dev] Re: Should we try to get a complete draft of What's New by b1?

[Jack DeVries]

> If you look at the version picker on docs.python.org you will see that we
already have the docs for 3.10 and 3.11 available. I don't know if they are
updated per release right now or per commit.

I understand that they are available options. To clarify my suggestion, I
think that 3.11 should be updated on a per commit basis (continuous
deployment); including updating the what's new pages continuously. If that
is not done already, I'm curious if it is been looked into before, and
whether it might be possible to set things up like this?

I was originally thinking that 3.10 documentation should be deployed
continuously as well, but on further thought I realized that that would put
the beta releases out of sync with the documentation which obviously does
not make any sense. Maybe we could add a new tab to the version picker
called 3.10/HEAD or similar. Maybe there's another solution?

Either way, continuous deployment of documentation for 3.11 (or whatever
version cpython/HEAD is at any given time) seems like it should be the norm
if it isn't already. If that is already the case, I'm sorry for the noise!
I still think that continuous deployment of documentation on the head of
the beta or alpha release branches is worth considering, maybe with a
different label on docs.python.org like "cpython/3.10@latest" or similar.


On Thu, Aug 12, 2021, 12:46 PM Brett Cannon  wrote:

>
>
> On Thu, Aug 12, 2021 at 6:04 AM Jack DeVries 
> wrote:
>
>> On a broader note, how does the deployment pipeline for documentation
>> work? It seems to me that for branches that are in pre-release (3.10) or
>> active development (3.11), the documentation should be continuously
>> deployed, while deployment of changes to earlier documentation should
>> follow minor releases for those versions.
>>
>> Sorry this question is naive -- I don't know how it works currently.
>> Would it be possible to set something like this up?
>>
>
> If you look at the version picker on docs.python.org you will see that we
> already have the docs for 3.10 and 3.11 available. I don't know if they are
> updated per release right now or per commit.
>
> -Brett
>
>
>>
>> On Thu, Aug 12, 2021, 3:02 AM Serhiy Storchaka 
>> wrote:
>>
>>> 11.08.21 21:35, Brett Cannon пише:
>>> > So my question is whether we want to push to be more diligent about
>>> > updating What's New by b1 so people can provide feedback during the
>>> > betas beyond just reporting breaking changes?
>>>
>>> I think that What's New should be updated as soon as possible,
>>> immediately after the addition of the feature. I started contributing to
>>> Python after reading What's New for one of early alphas of 3.3 (and the
>>> questioned feature was changed later). There were other examples, when
>>> features were advertised in alphas, but were changed after getting a
>>> feedback before betas.
>>>
>>> ___
>>> Python-Dev mailing list -- python-dev@python.org
>>> To unsubscribe send an email to python-dev-le...@python.org
>>> https://mail.python.org/mailman3/lists/python-dev.python.org/
>>> Message archived at
>>> https://mail.python.org/archives/list/python-dev@python.org/message/RQQ2QEV3OKCMAJGHLB52SKXLAIL7BB34/
>>> 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/V7E6UQPHXQSQZQSDFBLOGTS4AGGGPLJF/
>> 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/HKYS5D5KHXAQEAMX5ZKF6UXFVG26ELZF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] May/June steering council updates.

[Thomas Wouters]

The Steering Council is a bit behind on the community updates, but we just
published the May and June ones (also included below):

https://github.com/python/steering-council/blob/main/updates/2021-05-steering-council-update.md
https://github.com/python/steering-council/blob/main/updates/2021-06-steering-council-update.md

Just as a reminder, if you have any questions or concerns, feel free to
contact us or open an issue in the SC repo:
https://github.com/python/steering-council


May 3

   - Steering Council used the weekly meeting to record their PyCon US
   keynote 

May
10

   - The Core Developers voted to promote Irit Katriel to Core Dev, and the
   Steering Council has no objections.
   - SC scheduled a PEP review in two weeks.
   - SC discussed delegating typing PEPs, but did not reach a conclusion.
   - SC discussed PEP 563  (Postponed
   Evaluation of Annotations), the unexpected effects of the change, the
   last-minute postponement, and how to prevent similar occurrences in the
   future.

May
17

   - Group discussed documenting SC history and procedures. Carol is going
   to start on it in the private repo and then it can pushed out to the public
   one.
   - Thomas is going to ask Nathaniel for a concrete counter proposal for PEP
   654  (Exception Groups and
   except*).
   - Group discussed using Hypothesis in the standard library.

May
24

   - The Steering Council did PEP review and assigned pings to PEP authors
   and sponsors.
   - The Steering Council discussed who applied for the
   Developer-in-Residence position and Carol placed it on the agenda for June
   7th.
   - The Steering Council will not be meeting next week due to Memorial Day
   in the US.


June 7

   - The Steering Council reviewed the résumés received for the
   Developer-in-Residence position. The candidates were selected for the
   interview process. The Steering Council prepared for Developer in Residence
   interviews by reviewing questions for the interviews.

June
14

   - Steering Council and PSF staff interviewed candidates for the
   Developer-in-Residence position, and discussed the interviews immediately
   afterwards.

June
21

   - The Steering Council extensively discussed the Developer-in-Residence
   candidates, and made their final selection.
   - The SC discussed improving workflows around full-time contributors.
   The group will continue to think and discuss this.

June
28

   - The Steering Council reviewed PEP 654
    (Exception Groups and
   except*). Thomas will schedule a call with Nathaniel and the SC, possibly
   for next Monday (July 5), to hear Nathaniel's alternative proposal.
   - The SC reviewed PEP 467  (Minor
   API improvements for binary sequences) and there are concerns about the
   value of the change and the future implementation. Thomas was going to
   start a draft response, but didn't get around to it.
   - The SC reviewed PEP 657
 (Include
   Fine Grained Error Locations in Tracebacks). The group approved it (Pablo
   abstained because he's one of the PEP's authors) and Barry sent the
   announcement
   

to
   python-dev@.
   - Group discussed the request
    around modules
   following a provisional policies. Group decided that Barry will reach out
   to the module author about importlib.metadata's provisional status. The
   group will continue their discussion on how to move forward with
   provisional modules/packages.
   - Group discussed enum.Enum repr and str changes in 3.10 & 3.11. It was
   decided that Barry will email python-dev@ and strongly suggest that we
   rollback to 3.9 behavior for 3.10 and write a new PEP for 3.11.


-- 
Thomas Wouters 

Hi! I'm an email virus! Think twice before 

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations

[Guido van Rossum]

I will try to find time to review the code.

On Thu, Aug 12, 2021 at 08:56 Larry Hastings  wrote:

>
> On 8/12/21 8:25 AM, Guido van Rossum wrote:
>
> Maybe we could specialize the heck out of this and not bother with a
> function object? In the end we want to execute the code, the function
> object is just a convenient way to bundle defaults, free variables (cells)
> and globals. But co_annotation has no arguments or defaults, and is only
> called once. It does need to have access to the globals of the definition
> site (the call site may be in another module) and sometimes there are cells
> (not sure).
>
> Yes, there are sometimes cells.
>
> def foo():
> my_type = int
> def bar(a:my_type):
> return a
> return bar
>
> Both bar() and the co_annotations function for bar() are nested functions
> inside foo, and the latter has to refer to the cell for my_type.  Also,
> co_annotations on a class may keep a reference to the locals dict,
> permitting annotations to refer to values defined in the class.
>
>
> I don't know if it's worth making a specialized object as you suggest.
> I'd forgotten I did this, but late in the development of the 649 prototype,
> I changed it so the co_annotations function is *always* lazy-bound, only
> constructed on demand.
>
> There are three possible blobs of information the descriptor might need
> when binding the co_annotations function:
>
>- the co_annotations code object,
>- the tuple of cells, when co_annotations is a closure, and
>- the locals dict, when co_annotations is defined inside a class and
>might refer to names defined in the class.
>
> The code object is always necessary, the other two are optional.  If we
> only need the code object, we store that code object inside the function
> object and we're done.  If we need either or both of the other two blobs,
> we throw all the blobs we need in a tuple and store the tuple instead.  At
> the point that someone asks for the annotations on that object, the
> descriptor does PyType_ checks to determine which blobs of data it has,
> binds the function appropriately, calls it, and returns the result.  I
> think this approach is reasonable and I'm not sure what a custom callable
> object would get us.
>
>
> */arry*
>
-- 
--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/A5NH72LLWW4YFJ4LFQMY3WOM7X4DAIHP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Problems with dict subclassing performance

[Marco Sulla]

No ideas? Excuse me for the up.

On Fri, 6 Aug 2021 at 21:29, Marco Sulla  wrote:
>
> I've done an answer on SO about why subclassing `dict` makes the
> subclass so much slower than `dict`. The answer is interesting:
>
> https://stackoverflow.com/questions/59912147/why-does-subclassing-in-python-slow-things-down-so-much
>
> What do you think about?
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/ODHRCDEPOP3AUJJ6IKF2GFLOWJ5BY7TX/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Should we try to get a complete draft of What's New by b1?

[Serhiy Storchaka]

11.08.21 21:35, Brett Cannon пише:
> So my question is whether we want to push to be more diligent about
> updating What's New by b1 so people can provide feedback during the
> betas beyond just reporting breaking changes?

I think that What's New should be updated as soon as possible,
immediately after the addition of the feature. I started contributing to
Python after reading What's New for one of early alphas of 3.3 (and the
questioned feature was changed later). There were other examples, when
features were advertised in alphas, but were changed after getting a
feedback before betas.

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/RQQ2QEV3OKCMAJGHLB52SKXLAIL7BB34/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations

[Inada Naoki]

Lazy loading code object solves only a half of the problem.
I am worrying about function objects for annotation too.

Function objects are heavier than code objects. And they are GC-tracked objects.

I want to know how we can reduce the function objects created for
annotation in PEP 649, before deprecating PEP 563.

-- 
Inada Naoki  
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/OTZ4EPAQ2DTOIFFRBNG5CDMSRBKDUME5/
Code of Conduct: http://python.org/psf/codeofconduct/