[Python-Dev] Re: Last call for comments on PEP 573 (Module State Access from C Extension Methods)
On 2020-03-10 19:21, Stefan Behnel wrote: Hi Petr! Petr Viktorin schrieb am 14.01.20 um 14:37: It also includes a more drastic change: it removes the MRO walker from the proposal. Reflecting on the feedback, it became clear to me that a MRO walker, as it was described, won't give correct results in all cases: specifically, is a slot is overridden by setting a special method from Python code, the walker won't be able to find module. Think something like: c_add = Class.__add__ # where nb_add uses the MRO walker Class.__add__ = lambda *args: "evil" c_add(Class(), 0) # Exception: Defining type has not been found. This can be solved, but it will need a different design and more discussion. I'd rather defer it to the future. Meanwhile, extension authors can use their own MRO walker if they're OK with some surprising edge cases. I read the last update. I can't say I'm happy about the removal since I was seeing the MRO walker function as a way to hide internals so that extension authors can start using it and CPython can adapt the internals later. But I do see that there are issues with it, and I accept your choice to keep the PEP even more minimal than it already was. Are there any more points to discuss? Not to my knowledge. If not, I would soon like to accept the PEP, so that we can focus more on the implementation and usage. Thank you! ___ 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/5UKDYM3JMZ4ZRDNTXRZSYGUVXLHAVBM5/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] pathlib.Path: inconsistent symlink_to() and link_to()
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. Any thoughts? 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/7QPLYW36ZK6QTW4SV4FI6C343KYWCPAT/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: pathlib.Path: inconsistent symlink_to() and link_to()
Despite the bug being closed as WONTFIX, at the very least this seems like a valid docs issue. But (for whatever a non-core-dev opinion is worth), I'm +1 both on the proposed solution and deprecation.of `link_to()` Jim On Wed, Mar 11, 2020 at 10:45 AM Barney Gale 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. > > Any thoughts? > > 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/7QPLYW36ZK6QTW4SV4FI6C343KYWCPAT/ > 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/5T2D3CUEC6E5PG3ZMLHMAI4N2B2NL7TI/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: pathlib.Path: inconsistent symlink_to() and link_to()
On Wed, 11 Mar 2020 11:17:22 + Barney Gale 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. 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/7BL6FK4ZFVBMGKIMZA53ODDO3H5CN5HJ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: pathlib.Path: inconsistent symlink_to() and link_to()
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/
