[Python-Dev] Re: PEP 624: Remove Py_UNICODE encoder APIs

2021-01-21 Thread Inada Naoki 
Hi, Lemburg.

I want to send the PEP to SC.
I think I wrote all your points in the PEP. Would you review it?

Regards,

On Tue, Aug 4, 2020 at 5:04 PM Inada Naoki  wrote:
>
> On Tue, Aug 4, 2020 at 3:31 PM M.-A. Lemburg  wrote:
> >
> > Hi Inada-san,
> >
> > thanks for attending EuroPython. I won't be back online until
> > next Wednesday. Would it be possible to wait until then to continue
> > the discussion ?
> >
>
> Of course. The PEP is for Python 3.11. We have a lot of time.
>
> Bests,

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

[Python-Dev] Re: PEP 651: Robust Overflow Handling, version 2

2021-01-21 Thread Guido van Rossum 
On Wed, Jan 20, 2021 at 9:16 AM Mark Shannon  wrote:

> I've updated the PEP in light of my experiments and feedback.
> The new API is simpler and a bit more backwards compatible.
>
> https://www.python.org/dev/peps/pep-0651


Minor question: what's the `where` argument to `Py_CheckStackDepth()` for?

The implementation section doesn't mention how you intend to avoid the C
stack for Python-to-Python calls. I have some idea, but it would be nice if
you explained this a bit more. (I'm guessing you are planning to move some
state from local variables into the frame object, store a "return location"
(really frame object + bytecode program counter) somewhere, and then jump
to the top of `_PyEval_EvalFrameDefault()`, or at least somewhere near the
top. Of course this requires adjusting the various `CALL_*` opcodes to
check whether the target is a Python function or not. On `RETURN_VALUE` you
reverse the process, but only if the call came from the previous mechanism.
Do I get a lollipop? :-)

I'm guessing you needn't do anything for generators -- IIRC recursion
through `next()` is not possible, since an active generator cannot be
entered recursively.

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

[Python-Dev] Re: pathlib.Path: inconsistent symlink_to() and link_to()

2021-01-21 Thread Barney Gale 
Hi Brett,

Per your PR review feedback [0] I left a comment on the bug [1] asking when
the link_to() method should be scheduled for removal. It didn't elicit a
great deal of feedback, so I'm raising this again here!

The proposed deprecation warning in the docs currently reads:

> This method is deprecated in favor of :meth:`Path.hardlink_to`, as its
argument order does not match that of :meth:`Path.symlink_to`.

My view is that the removal does not need to happen soon. Any existing code
will be written by people who have already figured out the argument
reversal, so the current situation doesn't seem dangerous. That said, a
speedy deprecation and replacement will remove a guaranteed headache for
people creating hardlinks in pathlib.

Apologies if replying to an old thread is bad form - I'm not well versed in
mailing list etiquette.

Best,

Barney

[0] https://github.com/python/cpython/pull/18909#discussion_r392416154
[1] https://bugs.python.org/issue39950#msg365275

On Wed, 11 Mar 2020 at 17:31, Brett Cannon  wrote:

> Antoine Pitrou wrote:
> > On Wed, 11 Mar 2020 11:17:22 +
> > Barney Gale barney.g...@gmail.com wrote:
> > > Hi,
> > > Pathlib's symlink_to() and link_to() methods have different argument
> > > orders, so:
> > > a.symlink_to(b)  # Creates a symlink from A to B
> > > a.link_to(b)  # Creates a hard link from B to A
> > >
> > > I don't think link_to() was intended to be implemented this way, as the
> > > docs say "Create a hard link pointing to a path named target.". It's
> also
> > > inconsistent with everything else in pathlib, most obviously
> symlink_to().
> > > Bug report here: https://bugs.python.org/issue39291
> > > This /really/ irks me. Apparently it's too late to fix link_to(), so
> I'd
> > > like to suggest we add a new hardlink_to() method that matches the
> > > symlink_to() argument order. link_to() then becomes
> deprecated/undocumented.
> > > I think that's a good idea.
>
> +1 from me as well; new method and deprecate the old one.
>
> > 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/EID35RFJJQBHL4WKSO5DM36O7DDVDEKP/
> 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/3MCTZLLCZ2WGVPDW6R5RK7YNL7WK52D6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Please explain how to migrate when a function is removed, thanks ;-)

2021-01-21 Thread Kyle Stanley 
On Jan 20, 2021 at 9:51 PM Chros Jerdonek  wrote:

> Is there / would it make sense to have a section analogous to "Porting to
> Python X" that covers "Make All DeprecationWarnings Go Away in X"? If we
> had such a section, the "Porting to" section could be constructed by
> copying the relevant bits from that section in the previous release.


+1 from me to include this section in 3.10 and future whatsnew.

On Thu, Jan 21, 2021 at 2:17 PM Mariatta  wrote:

> I agree that when we land a feature that introduces incompatible change
> like this, as part of the PR it should also include updating the
> documentation on how to migrate.
> I would think that the feature should not be merged unless the doc has
> been updated too.
>
> Perhaps we should include this explicitly in devguide, as one of the
> things to consider when reviewing pull requests.
> Do we have such a guide/doc yet, on how to review CPython pull requests?
>

This seems like it would be a good location to include that information:
https://devguide.python.org/pullrequest/#how-to-review-a-pull-request

Maybe also a brief mention in the checklist for
https://devguide.python.org/committing/#is-the-pr-ready-to-be-accepted.
Step 9 currently has: "Was “What’s New” updated (as appropriate)?", which
could have a sub-point to mention "Incompatible changes should include
migration information in their respective "What's New".".
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/E7NYJ5DUQM46GXKCQTUWRXBJUQ5DOAHR/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Please explain how to migrate when a function is removed, thanks ;-)

2021-01-21 Thread Mariatta 
I agree that when we land a feature that introduces incompatible change
like this, as part of the PR it should also include updating the
documentation on how to migrate.
I would think that the feature should not be merged unless the doc has been
updated too.

Perhaps we should include this explicitly in devguide, as one of the things
to consider when reviewing pull requests.
Do we have such a guide/doc yet, on how to review CPython pull requests?


On Thu, Jan 21, 2021 at 2:49 AM Victor Stinner  wrote:

> Currently, we wait until the first user complains, sometimes after a
> 3.x.0 final release, before starting to document how to port existing
> code. I agree that it should be done earlier.
>
> I suggest that developers who want to introduce an incompatible change
> think about how to port existing code, especially if it's possible to
> write code compatible with the old and the new behavior. It should be
> done while the incompatible change is designed.
>
> I also agree that we document how to port code in the change which
> introduce the deprecation, not when we introduce the incompatible
> change (ex: remove a function).
>
> I also suggest to communicate on future incompatible changes ;-)
>
> 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/F4YKK4ERIDDYZ7RUVZ5FPJFA4TSA3AP7/
> 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/LKKFITEKMTLHWN7XHY75FJGRK3GVX6UT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] The SC is accepting PEP 632: deprecating distutils

2021-01-21 Thread Brett Cannon 
On behalf of the SC, I'm happy to announce that we have chosen to accept
PEP 632. Congrats, Steve, and thanks for the work on the PEP!

I'll let Steve outline what the next steps are for implementing the PEP.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/TXU6TVOMBLQU3SV57DMMOA5Y2E67AW7P/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Doctest does not work with mock.call PR #22981

2021-01-21 Thread Alfred Perlstein 

Hello,

There's been a bug open where doctest can break if there are proxy 
objects that fail to unwrap (https://bugs.python.org/issue35753) since 
python 3.7, this includes when importing 'call' from the 'mock' module.


Does someone have time to review PR 22981 
(https://github.com/python/cpython/pull/22981).


Last feedback from folks with merge capabilities seems to be from 
November 8th.  I've replied a few times in December on the PR but there 
is no response.


-Alfred

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

[Python-Dev] Re: Please explain how to migrate when a function is removed, thanks ;-)

2021-01-21 Thread Victor Stinner 
Currently, we wait until the first user complains, sometimes after a
3.x.0 final release, before starting to document how to port existing
code. I agree that it should be done earlier.

I suggest that developers who want to introduce an incompatible change
think about how to port existing code, especially if it's possible to
write code compatible with the old and the new behavior. It should be
done while the incompatible change is designed.

I also agree that we document how to port code in the change which
introduce the deprecation, not when we introduce the incompatible
change (ex: remove a function).

I also suggest to communicate on future incompatible changes ;-)

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