[issue32424] Rename copy() to __copy__() in xml.etree.ElementTree.Element Python implementation

Change by Gordon P. Hemsley : -- pull_requests: +4927 ___ Python tracker ___ ___

[issue32424] Rename copy() to __copy__() in xml.etree.ElementTree.Element Python implementation

R. David Murray added the comment: Yes, that's why I said "from our point of view" :) I know there is usually a fork in the practical sense, but we want to make it as easy as practical to sync that fork, which includes not breaking things in the python versions

[issue32424] Rename copy() to __copy__() in xml.etree.ElementTree.Element Python implementation

Paul Ganssle added the comment: > There is no "fork" involved in other projects using it, from our point of > view. I did not mean "fork" in some judgmental sense, I'm mostly just familiar with pypy, but I was under the impression that other projects were *literally*

[issue32424] Rename copy() to __copy__() in xml.etree.ElementTree.Element Python implementation

R. David Murray added the comment: Paul Ganssle: Even if Andrew were not suggesting adding copy to the C implementation (I have no opinion on that currently), it would still be correct to maintain backward compatibility in the python version in the standard library.

[issue32424] Rename copy() to __copy__() in xml.etree.ElementTree.Element Python implementation

Andrew Svetlov added the comment: Yes. For designing from scratch copy() is not necessary but if we have it for decade -- better to unify pure Python and C implementation by adding missing methods. -- ___ Python tracker

[issue32424] Rename copy() to __copy__() in xml.etree.ElementTree.Element Python implementation

Paul Ganssle added the comment: @Andrew Are you suggesting that a `copy` method be *added* to the C implementation, as an alias to __copy__? Because it makes no sense to keep the pure Python and C implementations out of sync just so that it's easier for projects forking

[issue32424] Rename copy() to __copy__() in xml.etree.ElementTree.Element Python implementation

Andrew Svetlov added the comment: For derivative Python implementation there is a standard strategy: they uses a copy of CPython standard library. Tthat's why any new module should have a pure Python implementation and that's why

[issue32424] Rename copy() to __copy__() in xml.etree.ElementTree.Element Python implementation

Paul Ganssle added the comment: > I mean dropping `.copy()` breaks not only compatibility between pure python > versions but also between pypy releases and pypy/CPython code. That's why I suggest to keep `.copy()` as an alias for `__copy__()`. If the main issue is that

[issue32424] Rename copy() to __copy__() in xml.etree.ElementTree.Element Python implementation

Andrew Svetlov added the comment: I mean dropping `.copy()` breaks not only compatibility between pure python versions but also between pypy releases and pypy/CPython code. That's why I suggest to keep `.copy()` as an alias for `__copy__()`. --

[issue32424] Rename copy() to __copy__() in xml.etree.ElementTree.Element Python implementation

Gordon P. Hemsley added the comment: Two notes: * It appears that pypy is based on no more recent than Python 3.5, so this wouldn't immediately break them. (3.6 support is maybe in development?) * pypy appears to have already made other adjustments due to the

[issue32424] Rename copy() to __copy__() in xml.etree.ElementTree.Element Python implementation

Andrew Svetlov added the comment: pypy for example has Element.copy() -- ___ Python tracker ___

[issue32424] Rename copy() to __copy__() in xml.etree.ElementTree.Element Python implementation

Julien Palard added the comment: I don't agree with the API breakage, the C implementation of the module does not expose copy(), so code using copy() is already broken (since 2005) in cases the C implementation is used. I also expect the C implementation to be used

[issue32424] Rename copy() to __copy__() in xml.etree.ElementTree.Element Python implementation

Andrew Svetlov added the comment: Agree with Srinivas -- nosy: +asvetlov ___ Python tracker ___

[issue32424] Rename copy() to __copy__() in xml.etree.ElementTree.Element Python implementation

Srinivas Reddy T added the comment: Renaming the method `copy()` to `__copy__` breaks the API. I would rather have an alias for `__copy__`. I agree that it is not documented, but some users tend to assume public methods are documented and use them. So i

[issue32424] Rename copy() to __copy__() in xml.etree.ElementTree.Element Python implementation

Gordon P. Hemsley added the comment: Ultimately, yeah, the Python version should probably define __deepcopy__ as well. But since this is just a rename of an existing method, I figure we can defer that to another time. --

[issue32424] Rename copy() to __copy__() in xml.etree.ElementTree.Element Python implementation

Change by Gordon P. Hemsley : -- keywords: +patch pull_requests: +4909 stage: -> patch review ___ Python tracker ___

[issue32424] Rename copy() to __copy__() in xml.etree.ElementTree.Element Python implementation

Julien Palard added the comment: As the C implementation is already shadowing the Python implementation when available (last lines of Lib/xml/etree/ElementTree.py), using `.copy()` is already a bug magnet (works when the Python implem is used, does not work when

[issue32424] Rename copy() to __copy__() in xml.etree.ElementTree.Element Python implementation

New submission from Gordon P. Hemsley : Currently, the Python implementation of the Element class in xml.etree.ElementTree defines a method called copy() which the C implementation does not define, whereas the C implementation defines a __copy__() method (and a