[Python-Dev] Is it too late to critique PEP 657? (Include Fine Grained Error Locations in Tracebacks)

2021-06-29 Thread Mark Shannon 

Hi,

I was expected the announcement of a BDFL delegate for PEP 657, as the 
author is a steering council member.


It seems that a PEP submitted by a SC member has been accepted by the SC 
with seemingly no external review.


PEP 657 is likely to cause significant worsening of start up time and 
interact poorly with debugging and profiling.



Cheers,
Mark.
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/OPTIO7SWLTEZCWMAHVDKF7WUX2LSQ46X/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Is it too late to critique PEP 657? (Include Fine Grained Error Locations in Tracebacks)

2021-06-29 Thread Pablo Galindo Salgado 
> I was expected the announcement of a BDFL delegate for PEP 657, as the
author is a steering council member.

Just to clarify this: as I was the author I didn't get to vote on the
approval or rejection of the PEP. Also, there is nowhere that I know where
this situation requires a BDFL delegate like you claim.

> It seems that a PEP submitted by a SC member has been accepted by the SC
with seemingly no external review.

That is very not true. We have added ton of beedback for at least 2
python-dev threads and a discourse thread:

*
https://discuss.python.org/t/pep-657-include-fine-grained-error-locations-in-tracebacks/8629
*
https://mail.python.org/archives/list/[email protected]/thread/DB3RTYBF2BXTY6ZHP3Z4DXCRWPJIQUFD/
*
https://mail.python.org/archives/list/[email protected]/thread/KR7ACFCUNMHT4M7R4XNHGRFV27HZBDFD/#KR7ACFCUNMHT4M7R4XNHGRFV27HZBDFD

The design has been iterated many times and we have draft implementations
from some of the alternative ideas as the ones proposed by Nathaniel.

> interact poorly with debugging and profiling.

"interact poorly with debugging and profiling." is making unfounded claims,
which is especially bad for a feature that is supposed to aid debugging.
You mentioned your worries on
https://mail.python.org/archives/list/[email protected]/thread/KR7ACFCUNMHT4M7R4XNHGRFV27HZBDFD/#KR7ACFCUNMHT4M7R4XNHGRFV27HZBDFD
and we answered them.

Kind regards,
Pablo




On Tue, 29 Jun 2021 at 16:30, Mark Shannon  wrote:

> Hi,
>
> I was expected the announcement of a BDFL delegate for PEP 657, as the
> author is a steering council member.
>
> It seems that a PEP submitted by a SC member has been accepted by the SC
> with seemingly no external review.
>
> PEP 657 is likely to cause significant worsening of start up time and
> interact poorly with debugging and profiling.
>
>
> Cheers,
> Mark.
> ___
> Python-Dev mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/[email protected]/message/OPTIO7SWLTEZCWMAHVDKF7WUX2LSQ46X/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/2VCQBSF67EZDRAFZOZBIG7IJHN2IEBW5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Is it too late to critique PEP 657? (Include Fine Grained Error Locations in Tracebacks)

2021-06-29 Thread Pablo Galindo Salgado 
Also, regarding startup times. Here are our benchmarks, measured with Linux
perf (https://perf.wiki.kernel.org/index.php/Main_Page)

* Importing all the standard library without PEP 657:

 Performance counter stats for './python import_all_stdlib.py' (500 runs):

303,78 msec task-clock#0,999 CPUs utilized
   ( +-  0,05% )
 4  context-switches  #0,014 K/sec
   ( +-  6,33% )
 0  cpu-migrations#0,000 K/sec

 7.602  page-faults   #0,025 M/sec
   ( +-  0,05% )
 1.146.643.923  cycles#3,775 GHz
   ( +-  0,03% )
 1.613.882.354  instructions  #1,41  insn per cycle
  ( +-  0,01% )
   391.399.735  branches  # 1288,440 M/sec
   ( +-  0,01% )
 6.501.180  branch-misses #1,66% of all
branches  ( +-  0,02% )

  0,304092 +- 0,000147 seconds time elapsed  ( +-  0,05% )

* Importing all the standard library with PEP 657:

 Performance counter stats for './python import_all_stdlib.py' (500 runs):

310,56 msec task-clock#0,999 CPUs utilized
   ( +-  0,06% )
 5  context-switches  #0,017 K/sec
   ( +-  9,39% )
 0  cpu-migrations#0,000 K/sec

 8.359  page-faults   #0,027 M/sec
   ( +-  0,05% )
 1.170.505.335  cycles#3,769 GHz
   ( +-  0,03% )
 1.637.448.123  instructions  #1,40  insn per cycle
  ( +-  0,01% )
   396.921.300  branches  # 1278,097 M/sec
   ( +-  0,01% )
 6.568.450  branch-misses #1,65% of all
branches  ( +-  0,02% )

  0,310904 +- 0,000179 seconds time elapsed  ( +-  0,06% )

The overhead is a 2% increase in startup time, which is 0.006812004
seconds of difference.

On Tue, 29 Jun 2021 at 16:39, Pablo Galindo Salgado 
wrote:

> > I was expected the announcement of a BDFL delegate for PEP 657, as the
> author is a steering council member.
>
> Just to clarify this: as I was the author I didn't get to vote on the
> approval or rejection of the PEP. Also, there is nowhere that I know where
> this situation requires a BDFL delegate like you claim.
>
> > It seems that a PEP submitted by a SC member has been accepted by the SC
> with seemingly no external review.
>
> That is very not true. We have added ton of beedback for at least 2
> python-dev threads and a discourse thread:
>
> *
> https://discuss.python.org/t/pep-657-include-fine-grained-error-locations-in-tracebacks/8629
> *
> https://mail.python.org/archives/list/[email protected]/thread/DB3RTYBF2BXTY6ZHP3Z4DXCRWPJIQUFD/
> *
> https://mail.python.org/archives/list/[email protected]/thread/KR7ACFCUNMHT4M7R4XNHGRFV27HZBDFD/#KR7ACFCUNMHT4M7R4XNHGRFV27HZBDFD
>
> The design has been iterated many times and we have draft implementations
> from some of the alternative ideas as the ones proposed by Nathaniel.
>
> > interact poorly with debugging and profiling.
>
> "interact poorly with debugging and profiling." is making unfounded
> claims, which is especially bad for a feature that is supposed to aid
> debugging. You mentioned your worries on
> https://mail.python.org/archives/list/[email protected]/thread/KR7ACFCUNMHT4M7R4XNHGRFV27HZBDFD/#KR7ACFCUNMHT4M7R4XNHGRFV27HZBDFD
> and we answered them.
>
> Kind regards,
> Pablo
>
>
>
>
> On Tue, 29 Jun 2021 at 16:30, Mark Shannon  wrote:
>
>> Hi,
>>
>> I was expected the announcement of a BDFL delegate for PEP 657, as the
>> author is a steering council member.
>>
>> It seems that a PEP submitted by a SC member has been accepted by the SC
>> with seemingly no external review.
>>
>> PEP 657 is likely to cause significant worsening of start up time and
>> interact poorly with debugging and profiling.
>>
>>
>> Cheers,
>> Mark.
>> ___
>> Python-Dev mailing list -- [email protected]
>> To unsubscribe send an email to [email protected]
>> https://mail.python.org/mailman3/lists/python-dev.python.org/
>> Message archived at
>> https://mail.python.org/archives/list/[email protected]/message/OPTIO7SWLTEZCWMAHVDKF7WUX2LSQ46X/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/TBDLJ5ZKN4Q7MUKOLTPNPHBQV5GUTVJO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Is it too late to critique PEP 657? (Include Fine Grained Error Locations in Tracebacks)

2021-06-29 Thread Barry Warsaw 
On Jun 29, 2021, at 08:27, Mark Shannon  wrote:
> 
> I was expected the announcement of a BDFL delegate for PEP 657, as the author 
> is a steering council member.

PEP Delegates are not required, even when the PEP author is an SC member.

-Barry



signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/I5F674MXMCWGRE5JA2QAOSEI3OPLLNOP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Is the Python review process flawed?

2021-06-29 Thread esmeraldagarcia 
I just stumbled upon the following issue and subsequent pull request. It is a 
very small bugfix. There is currently a bug in Python and this pull request 
fixes it. It's not a new feature or an enhancement, it is a bugfix! Yet, it 
doesn't get reviewed, nor merged. And this has been going on since March 2017. 
Why not just merge this? It's not like it's huge or obstructing or obfuscating 
the current code base? There's always time to write an improvement or a 
complete rewrite of this module feature later for an upcoming minor release. 
But if there is currently a bug in Python and the bugfix is available - why 
doesn't it get merged?

https://github.com/python/cpython/pull/4819

If this doesn't get fixed, doesn't that mean the Python review process is 
flawed? Sure, Python is an open source project and many people just work in 
their free time. But this doesn't really apply here, does it? The bugfix is 
available. Only a review is required. All this is happening while new features 
get added to Python with every new minor version. While the bug is allowed to 
live there. Please help me understand how this can happen.

I love Python. No hard feelings. But this is really bugging me and I can't help 
but feel disappointed.
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/TTJAVTPF6RYO63GTBSTXFJG3IVCYPHXT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Is the Python review process flawed?

2021-06-29 Thread Chris Angelico 
On Wed, Jun 30, 2021 at 2:36 AM  wrote:
>
> I just stumbled upon the following issue and subsequent pull request. It is a 
> very small bugfix. There is currently a bug in Python and this pull request 
> fixes it. It's not a new feature or an enhancement, it is a bugfix! Yet, it 
> doesn't get reviewed, nor merged. And this has been going on since March 
> 2017. Why not just merge this? It's not like it's huge or obstructing or 
> obfuscating the current code base? There's always time to write an 
> improvement or a complete rewrite of this module feature later for an 
> upcoming minor release. But if there is currently a bug in Python and the 
> bugfix is available - why doesn't it get merged?
>
> https://github.com/python/cpython/pull/4819
>
> If this doesn't get fixed, doesn't that mean the Python review process is 
> flawed? Sure, Python is an open source project and many people just work in 
> their free time. But this doesn't really apply here, does it? The bugfix is 
> available. Only a review is required. All this is happening while new 
> features get added to Python with every new minor version. While the bug is 
> allowed to live there. Please help me understand how this can happen.
>
> I love Python. No hard feelings. But this is really bugging me and I can't 
> help but feel disappointed.
>

It looks like that was closed in favour of a different PR:

https://github.com/python/cpython/pull/16341

There's been quite a bit of discussion on both of them. Are you sure
you linked to the correct pull request?

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

[Python-Dev] From the SC (was Re: Enum -- last call for comments on 3.10 changes)

2021-06-29 Thread Barry Warsaw 
The Steering Council discussed this topic at our meeting yesterday.  We have 
some discomfort about the changes to Enum’s str and repr in Python 3.10, both 
in the specific changes and in the way the changes were decided on.  No knock 
on Ethan or others who participated in those decisions, it’s just that to us, 
the changes cumulatively feel like they need a more formal, centralized 
discussion to understand all the issues in detail.

While we’re stopping short of requiring it, the Steering Council strongly 
suggests that for Python 3.10, the changes in Enum’s str and repr be reverted 
back to the Python 3.9 behavior, and that a PEP be written for Python 3.11.

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

> On Jun 28, 2021, at 00:56, Ethan Furman  wrote:
> 
> I have spoken with Pablo (3.10 RM), and he agrees that a change to Enum str() 
> in 3.10 and another in 3.11 is less than ideal, so this new thread is to 
> collect comments about Enum and it's str() and repr() and whether the changes 
> take effect in 3.10, 3.11, or both.
> 
> TL;DR -- sorry, there isn't one.
> 
> History:
> 
> As Enum and IntEnum have started proliferating in the stdlib, some of those 
> enumerations have changed the str() and repr() of their members -- for 
> example, in 3.8 re.RegexFlag had its repr() and str() changed to be 
> module.name (re.ASCII) for both instead of  
> () for the repr(); that change made sense because all 
> the members are exported to re's global name space, and they are accessed as 
> `re.ASCII` in existing code.
> 
> While a good change (in my opinion and with which I had nothing to do), we 
> now have stdlib enumerations with differing str() and repr()s, which is a 
> minor ding against recognizability and usability.
> 
> 
> Current 3.10 Changes
> 
> In an effort to standardize the stdlib enums, a new decorator was added: 
> global_enum().  It can be called manually (for example in re.RegexFlag), or 
> automatically by Enum._convert_ (for example in ssl.VerifyFlags).
> 
> That changed was visually appealing, and I had users wanting that type of 
> output for Enum in general, so after asking for feedback on python-dev and 
> python-ideas (and receiving little) I changed the basic str() and repr() of 
> Enum to:
> 
> - str(): NAME
> - repr(): enum.NAME
> 
> While working on some other bugs/changes in Enum.__format__ and serialization 
> in general, I have come to believe that IntEnum (and IntFlag) should be as 
> near-perfect a drop-in replacement as possible for when they are used to 
> replace existing integer constants (which I believe is their most important 
> use-case).
> 
> 
> Reverting 3.10 Changes
> --
> I have been increasingly unhappy with the general `Enum.__repr__` change, so 
> while the stdlib global repr() change is staying, Enum, IntEnum, etc., is 
> going back to .
> 
> 
> Proposed 3.10 Change (for 3.10.0 beta 4)
> 
> In order to improve the drop-in replacement use-case for IntEnum and IntFlag, 
> I would like to change the str() for those two to be simply the value of the 
> member, as if it was still a plain integer and not part of an enumeration.  
> At that point the only obvious difference would be the repr(), which I think 
> is the most important and useful change as that is what (should) show up in 
> log files, the REPL, etc.
> 
> This would also make IntEnum and IntFlag consistent with StrEnum as, for 
> other reasons, StrEnum member str()s are the values of the members rather 
> than the names of the members.  Note also that this change would not affect 
> user created enumerations that mixed in int on their own.
> 
> 
> The Question
> 
> With all the changes currently happening to the str()s and repr()s of the 
> various enums, what are the good reasons to not make this final change now, 
> and instead have one more change in 3.11?
> 
> 
> --
> ~Ethan~
> 
> 
> Summary of Enum str()s and repr()s by category
> 
> |   | repr() | str() | format()
> | stdlib global | re.ASCII   | re.ASCII  | 256
> | Enum  |  | Color.RED | RED
> | IntEnum   |  | 1 | 1
> | int, Enum |  | Color.RED | 1 (will be RED in 3.12 due to 
> back-compatibility
> |   || constraints which should 
> affect very few people as
> |   || as they are probably using 
> IntEnum instead of mixing
> |   || in int themselves -- comments 
> about this likelihood also
> |   || appreciated)
> ___
> Python-Dev mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at 
> https://mail.python.org/archives/list/[email protected]/message/ZMC67QA2

[Python-Dev] Re: Is the Python review process flawed?

2021-06-29 Thread Joannah Nanjekye 
 > why doesn't it get merged?

The last significant discussion from a core dev on the most relevant PR
here: https://github.com/python/cpython/pull/4819
shows that Antoine was familiarizing himself with the feature and had added
it to their to do list.

Merging something is also a responsibility to whoever does it, so I suggest
we approach this with grace given at least someone
promised to look into it.

BTW, am not writing off your concerns.

On Tue, Jun 29, 2021 at 1:36 PM  wrote:

> I just stumbled upon the following issue and subsequent pull request. It
> is a very small bugfix. There is currently a bug in Python and this pull
> request fixes it. It's not a new feature or an enhancement, it is a bugfix!
> Yet, it doesn't get reviewed, nor merged. And this has been going on since
> March 2017. Why not just merge this? It's not like it's huge or obstructing
> or obfuscating the current code base? There's always time to write an
> improvement or a complete rewrite of this module feature later for an
> upcoming minor release. But if there is currently a bug in Python and the
> bugfix is available - why doesn't it get merged?
>
> https://github.com/python/cpython/pull/4819
>
> If this doesn't get fixed, doesn't that mean the Python review process is
> flawed? Sure, Python is an open source project and many people just work in
> their free time. But this doesn't really apply here, does it? The bugfix is
> available. Only a review is required. All this is happening while new
> features get added to Python with every new minor version. While the bug is
> allowed to live there. Please help me understand how this can happen.
>
> I love Python. No hard feelings. But this is really bugging me and I can't
> help but feel disappointed.
> ___
> Python-Dev mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/[email protected]/message/TTJAVTPF6RYO63GTBSTXFJG3IVCYPHXT/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
Best,
Joannah Nanjekye

*"You think you know when you learn, are more sure when you can write, even
more when you can teach, but certain when you can program." Alan J. Perlis*
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/BCGNYV73S2O44OJ3OT2L3HKDK3BFLAE3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Is the Python review process flawed?

2021-06-29 Thread Barry Warsaw 
As specifically to the flaws in our workflow and the backlog, this is exactly 
what the Developer-in-Residence program was designed to address:

https://pyfound.blogspot.com/2021/04/the-psf-is-hiring-developer-in.html

Stay tuned!
-Barry

> On Jun 29, 2021, at 09:56, Joannah Nanjekye  wrote:
> 
> > why doesn't it get merged?
> 
> The last significant discussion from a core dev on the most relevant PR here: 
> https://github.com/python/cpython/pull/4819
> shows that Antoine was familiarizing himself with the feature and had added 
> it to their to do list.
> 
> Merging something is also a responsibility to whoever does it, so I suggest 
> we approach this with grace given at least someone
> promised to look into it.
> 
> BTW, am not writing off your concerns.
> 
> On Tue, Jun 29, 2021 at 1:36 PM  wrote:
> I just stumbled upon the following issue and subsequent pull request. It is a 
> very small bugfix. There is currently a bug in Python and this pull request 
> fixes it. It's not a new feature or an enhancement, it is a bugfix! Yet, it 
> doesn't get reviewed, nor merged. And this has been going on since March 
> 2017. Why not just merge this? It's not like it's huge or obstructing or 
> obfuscating the current code base? There's always time to write an 
> improvement or a complete rewrite of this module feature later for an 
> upcoming minor release. But if there is currently a bug in Python and the 
> bugfix is available - why doesn't it get merged?
> 
> https://github.com/python/cpython/pull/4819
> 
> If this doesn't get fixed, doesn't that mean the Python review process is 
> flawed? Sure, Python is an open source project and many people just work in 
> their free time. But this doesn't really apply here, does it? The bugfix is 
> available. Only a review is required. All this is happening while new 
> features get added to Python with every new minor version. While the bug is 
> allowed to live there. Please help me understand how this can happen.
> 
> I love Python. No hard feelings. But this is really bugging me and I can't 
> help but feel disappointed.
> ___
> Python-Dev mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at 
> https://mail.python.org/archives/list/[email protected]/message/TTJAVTPF6RYO63GTBSTXFJG3IVCYPHXT/
> Code of Conduct: http://python.org/psf/codeofconduct/
> 
> 
> --
> Best,
> Joannah Nanjekye
> "You think you know when you learn, are more sure when you can write, even 
> more when you can teach, but certain when you can program."
> Alan J. Perlis
> ___
> Python-Dev mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at 
> https://mail.python.org/archives/list/[email protected]/message/BCGNYV73S2O44OJ3OT2L3HKDK3BFLAE3/
> Code of Conduct: http://python.org/psf/codeofconduct/



signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/KJW4WBL27EB7EDVYDC3HL22VGXYJZ7SF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Is the Python review process flawed?

2021-06-29 Thread Brian Curtin 
On Tue, Jun 29, 2021 at 10:38 AM  wrote:

> I just stumbled upon the following issue and subsequent pull request. It
> is a very small bugfix. There is currently a bug in Python and this pull
> request fixes it. It's not a new feature or an enhancement, it is a bugfix!
> Yet, it doesn't get reviewed, nor merged. And this has been going on since
> March 2017. Why not just merge this? It's not like it's huge or obstructing
> or obfuscating the current code base? There's always time to write an
> improvement or a complete rewrite of this module feature later for an
> upcoming minor release. But if there is currently a bug in Python and the
> bugfix is available - why doesn't it get merged?
>
> https://github.com/python/cpython/pull/4819


For starters, the PR is closed in favor of another issue that has reviews
and a discussion, but even the smallest change like that requires a lot out
of a reviewer. Looking at that change, I don't personally know that it's
correct, so I'd have to take the time to figure out that it's correct. It
includes no tests, so I certainly don't trust that it's correct, so it
looks incomplete to me.

Time is irrelevant here—there's no need to rush things because a change
appears small. What if that one line change is even more wrong than before?
I have merge access and if I just said "ah it's a small PR and it's been
open for a while, I'll just merge it for them," any change to Python has
the possibility to affect a huge amount of people.

When I got the shutil.which feature merged, the PR had been open for I
believe 11 years and it was mostly complete in the initial patch outside of
a few small issues, and the change itself wasn't a lot of code. To just
have merged it because it was open for 11 years would have been the wrong
thing to do. It needed to cover some things it didn't initially cover, it
needed tests and documentation, and it wasn't merged until it was completed
and properly reviewed.

If this doesn't get fixed, doesn't that mean the Python review process is
> flawed? Sure, Python is an open source project and many people just work in
> their free time. But this doesn't really apply here, does it? The bugfix is
> available. Only a review is required. All this is happening while new
> features get added to Python with every new minor version. While the bug is
> allowed to live there. Please help me understand how this can happen.
>

"Only a review is required" is vastly understating the value of code
reviews. Almost anybody can write a one line fix, but is it the right fix?
Does it cover all of the cases it needs to? Is adding "manager_owned=False"
correct or should something else actually be done? Who knows and is
available to understand the impacts of this change?

So does this mean the review process is flawed? I would say no, the _review
process_ is maybe working as expected—the linked PR was incomplete and
wasn't merged, another PR has come up, and there's discussion on it
including a comment about tests and one about familiarizing with the code.
The process of finding humans who are willing and able to do this
work—currently for free—is possibly broken, possibly working as expected,
and overall is a significantly harder problem to fix than most anything
involved with open source software.

I love Python. No hard feelings. But this is really bugging me and I can't
> help but feel disappointed.
>

The good thing is that you paid nothing for this, so being disappointed is
something you can fix. If you would like more value out of it or to speed
up the process, you can provide your own reviews. Reviewing code is
immensely valuable and helps so many people—the core developers, the users,
and yourself. Alternatively, paying people to do the reviews is also
possible.

___
> Python-Dev mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/[email protected]/message/TTJAVTPF6RYO63GTBSTXFJG3IVCYPHXT/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/5PYTF4BEKS3H2AZX6ZQXKIQM5SYTOH7H/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Is the Python review process flawed?

2021-06-29 Thread Guido van Rossum 
On Tue, Jun 29, 2021 at 9:34 AM  wrote:

> If this doesn't get fixed, doesn't that mean the Python review process is
> flawed? Sure, Python is an open source project and many people just work in
> their free time. But this doesn't really apply here, does it? The bugfix is
> available. Only a review is required. All this is happening while new
> features get added to Python with every new minor version. While the bug is
> allowed to live there. Please help me understand how this can happen.
>

I think there's a misunderstanding here -- you seem to imply that producing
a bugfix is work that takes somebody's time, while reviewing a bugfix is
not work and doesn't cost anything. But realistically, for most issues,
things are the other way around -- writing the code is easy (at least to a
core dev :-) but reviewing code is a gut-wrenching process that takes up
emotional energy and a lot of time. Given the discussion in the issue
corresponding to the PR it is clear that that is what is going on here.

As Nadia Eghbal writes in her book _Working In Public_, *maintainer
attention* is actually the scarcest resource in many open source projects,
and Python is no exception. It is also the least satisfying kind of work,
which is why volunteers prefer to work on new features.


> I love Python. No hard feelings. But this is really bugging me and I can't
> help but feel disappointed.
>

Thank you for that! Hopefully all the responses you are getting help you
see why this is not so simple.

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

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

[Python-Dev] Re: Is the Python review process flawed?

2021-06-29 Thread Antoine Pitrou 
On Tue, 29 Jun 2021 13:56:18 -0300
Joannah Nanjekye  wrote:
>  > why doesn't it get merged?  
> 
> The last significant discussion from a core dev on the most relevant PR
> here: https://github.com/python/cpython/pull/4819
> shows that Antoine was familiarizing himself with the feature and had added
> it to their to do list.

Oops. I'm really sorry for giving false hopes, then, because I don't
think I'm motivated to review this PR. I'm not really maintaining
multiprocessing these days, anymore.

Hopefully some other core developer would like to take a look, but
we're talking about a slightly niche feature of multiprocessing...

Regards

Antoine.


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