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

[Mariatta]

I opened an issue on Devguide: https://github.com/python/devguide/issues/655



On Thu, Jan 21, 2021 at 11:37 AM Kyle Stanley  wrote:

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

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

[Steve Dower]

On 1/21/2021 6:30 PM, Brett Cannon wrote:
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.


Thanks. Work from this point on will be tracked at 
https://bugs.python.org/issue41282


The next immediate step is finishing off 
https://github.com/python/cpython/pull/23142 to do the biggest task of 
bringing sysconfig up to compatibility with distutils.sysconfig. Once 
merged, we'll add the deprecation warning on import 
(Lib/distutils/__init__.py) and close all the current issues in the 
tracker (and any associated PRs). That should be done before 3.10 Beta 1.


From there, I'll spend time publicising the deprecation as much as 
possible (and everyone is welcome to help out) to find enough cases for 
retaining functionality that we can make sensible decisions on where to 
move things. From discussions so far, most of the functionality that 
people expect is well covered by either setuptools or the standard 
library. The rest, officially, should be copied into your own project as 
needed.


Eventually, my plan is to move distutils into our Tools folder and 
update the setup.py we use for building stdlib extension modules (and 
the PEG parser tests) to point at it there. However, if someone else 
updates our build system to do it all through the Makefile, that won't 
be necessary, and I know a few people were keen to do it. I'm not 
*requiring* that it be done, and we have an easy fallback plan, but I'll 
happily *encourage* anyone who wants to update the Makefile to go ahead.


One thing I do *not* intend to do is go through and thoroughly document 
everything that's being deleted. Some have asked or implied that this 
should be done, but it's just not going to happen. Everything beyond the 
package build support and sysconfig is helper functions, and mostly 
pretty rough ones to be honest. There are almost certainly 1st or 3rd 
party modules with better quality implementations, and if not then I 
expect there will be (and if you're one of the really concerned people, 
the best thing you can do to help now that the PEP is accepted is to 
create a new library with these helpers).


Feel free to raise any questions here or on the bug linked above.

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

[Python-Dev] Summary of Python tracker Issues

[Python tracker]

ACTIVITY SUMMARY (2021-01-15 - 2021-01-22)
Python tracker at https://bugs.python.org/

To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.

Issues counts and deltas:
  open7578 (+32)
  closed 47161 (+35)
  total  54739 (+67)

Open issues with patches: 3037 


Issues opened (52)
==

#42604: EXT_SUFFIX too short on FreeBSD and AIX
https://bugs.python.org/issue42604  reopened by vstinner

#42937: 192.0.0.8 (IPv4 dummy address) considered globally reachable
https://bugs.python.org/issue42937  opened by cdirkx

#42939: Linux's chattr i.e. ioctl(FS_IOC_SETFLAGS) is not supported in
https://bugs.python.org/issue42939  opened by socketpair

#42940: Incorrect behavior of inspect.signature(f).bind
https://bugs.python.org/issue42940  opened by slavkostrov

#42941: Infinite loop in asyncio sslproto
https://bugs.python.org/issue42941  opened by linxy95

#42943: singledispatchmethod should expose registry of all known overl
https://bugs.python.org/issue42943  opened by Ilya.Kulakov

#42946: email: ValueError in get_section when parsing header with non-
https://bugs.python.org/issue42946  opened by The Compiler

#42947: email: Handling when both extended/ascii parameter (filename*/
https://bugs.python.org/issue42947  opened by The Compiler

#42948: bytearray.copy is undocumented
https://bugs.python.org/issue42948  opened by wim.glenn

#42949: pdb & multiprocessing.Pool: AttributeError: module '__main__' 
https://bugs.python.org/issue42949  opened by macfreek

#42950: Incorrect exception behavior in handling recursive call.
https://bugs.python.org/issue42950  opened by xxm

#42952: Incorrect handling of EC_KEY_new_by_curve_name() in the _ssl m
https://bugs.python.org/issue42952  opened by ZackerySpytz

#42955: Add sys.module_names: list of stdlib module names (Python and 
https://bugs.python.org/issue42955  opened by vstinner

#42956: Easy conversion between range and slice
https://bugs.python.org/issue42956  opened by nemeskeyd

#42957: os.readlink produces wrong result on windows
https://bugs.python.org/issue42957  opened by simon mackenzie

#42958: filecmp.cmp(shallow=True) isn't actually shallow when only mti
https://bugs.python.org/issue42958  opened by AlexVndnblcke

#42960: resources module, FreeBSD update adding RLIMIT_KQUEUES constan
https://bugs.python.org/issue42960  opened by devnexen

#42961: Use-after-free (of a heap type) during finalization
https://bugs.python.org/issue42961  opened by bstaletic

#42962: Windows: SystemError during os.kill(..., signal.CTRL_C_EVENT)
https://bugs.python.org/issue42962  opened by William.Schwartz

#42963: [multiprocessing] Calling pool.terminate() from an error_callb
https://bugs.python.org/issue42963  opened by sjelin

#42964: Draft PEP blob etc
https://bugs.python.org/issue42964  opened by larry

#42966: argparse: customizable help formatter
https://bugs.python.org/issue42966  opened by monkeyman79

#42967: [security] urllib.parse.parse_qsl(): Web cache poisoning - `; 
https://bugs.python.org/issue42967  opened by AdamGold

#42968: multiprocessing handle leak on Windows when child process is k
https://bugs.python.org/issue42968  opened by dgrunwald

#42969: pthread_exit & PyThread_exit_thread from PyEval_RestoreThread 
https://bugs.python.org/issue42969  opened by gregory.p.smith

#42970: File path with blank causes open error in 3.8, not in 3.7
https://bugs.python.org/issue42970  opened by dday52

#42971: Some errnos for BSD/OSX are missing from errno module
https://bugs.python.org/issue42971  opened by ngie

#42972: [C API] Heap types (PyType_FromSpec) must fully implement the 
https://bugs.python.org/issue42972  opened by vstinner

#42973: argparse: mixing optional and positional arguments... not agai
https://bugs.python.org/issue42973  opened by monkeyman79

#42974: tokenize reports incorrect end col offset and line string when
https://bugs.python.org/issue42974  opened by romanows

#42976: __text_signature__ parser silently drops arguments with certai
https://bugs.python.org/issue42976  opened by Antony.Lee

#42977: Tkinter Optionmenu Too Narrow on Mac
https://bugs.python.org/issue42977  opened by zjdavid

#42979: _zoneinfo: zoneinfomodule_exec() doesn't check for PyDateTime_
https://bugs.python.org/issue42979  opened by vstinner

#42980: argparse: GNU-style help formatter
https://bugs.python.org/issue42980  opened by will

#42981: Error messages raised by _hashlib_scrypt_impl() are slightly m
https://bugs.python.org/issue42981  opened by illia-v

#42982: Update suggested number of iterations for pbkdf2_hmac()
https://bugs.python.org/issue42982  opened by illia-v

#42985: AMD64 Arch Linux Asan 3.x fails: command timed out: 1200 secon
https://bugs.python.org/issue42985  opened by vstinner

#42986: pegen parser: Crash on SyntaxError with f-string on Windows
https://bugs.python.org/issue42986  opened by neonene

#42988: Information disclosure via pydoc -p: /getfile?key=path allows 

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

[Brett Cannon]

On Thu, Jan 21, 2021 at 4:43 PM Barney Gale  wrote:

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

Per PEP 387 (https://www.python.org/dev/peps/pep-0387/), the deprecation
needs to last for at least 2 versions (so if this landed in 3.10 then
removal couldn't happen any sooner than 3.12).


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

I would replace "its argument order" with "the argument order of
:meth:`link_to` to disambiguate what "its" is referring to (my brain kept
associating it with the last noun, which was Path.hardlink_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.
>

The removal can't be any _sooner_ than 3.12, but it can be postponed if
desired/necessary.


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

Not a problem! Sometimes it's just called for, and you kept the old emails
quoted in your reply which helps.

-Brett


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

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

[Mark Shannon]

Hi Guido,

On 22/01/2021 5:20 am, Guido van Rossum wrote:
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 same as for Py_EnterRecursiveCall(where); it gets incorporated into 
the exception message.




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


Yes you do. 

I'll expand the PEP a bit to include that information.



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.


Yes.
It might be nice to handle generators as well, but it is not necessary.

Cheers,
Mark.



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