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

[Gordon P. Hemsley]

Change by Gordon P. Hemsley :


--
pull_requests: +4927

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[R. David Murray]

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 
without good reason.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Paul Ganssle]

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* 
forking the standard library as a practical matter. I get the impression that 
other interpreters maintain a patched interpreter often for the purposes of 
adding fixes like the one pointed out in msg309131 which bring the behavior of 
the Python implementation of the standard library into line with the C 
implementations, since the C version is the de facto standard (since most code 
is written and tested only for CPython).

I'd be fine with adding a C alias for `copy`, though as a purely practical 
matter, I strongly suspect that dropping `copy` from the pure Python 
implementation would not be a huge deal, but if that breaks the contract it 
breaks the contract.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[R. David Murray]

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.  We do not consider the standard library to be CPython specific, even 
though parts of it are.  There is no "fork" involved in other projects using 
it, from our point of view.  Quite the opposite, where possible.  We have given 
commit rights to developers from other python implementations specifically so 
they can contribute things that improve compatibility in the standard library 
and standard library test suite for those other python implementations.

--
nosy: +r.david.murray

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Andrew Svetlov]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Paul Ganssle]

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 the pure Python implementation to maintain backwards 
compatibility with their earlier implementations.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Andrew Svetlov]

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 https://www.python.org/dev/peps/pep-0399/ exists.

Jython has copy() method as well. IronPython has it. I doubt if an 
implementation without xml.etree.ElementTree.Element.copy exists at all.

The method removal breaks backward compatibility without a reason, __copy__ 
alias is valuable and backward compatible change.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Paul Ganssle]

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 pypy users have been using this, can't pypy just keep 
an alias for `copy` around, possibly with a DeprecationWarning?

--
nosy: +p-ganssle

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Andrew Svetlov]

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__()`.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Gordon P. Hemsley]

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 differences 
between the Python and C implementations: 
https://bitbucket.org/pypy/pypy/diff/lib-python/3/xml/etree/ElementTree.py?diff2=0939e3a8a08d=py3.5

That said, I'm neutral on the subject. I'm happy to implement whichever option 
you decide on.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Andrew Svetlov]

Andrew Svetlov  added the comment:

pypy for example has Element.copy()

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Julien Palard]

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 almost anywhere, but I may be 
wrong on this point: in which case the Python implementation may still be used?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Andrew Svetlov]

Andrew Svetlov  added the comment:

Agree with Srinivas

--
nosy: +asvetlov

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Srinivas Reddy T]

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 think it is better to not to break their code.

--
nosy: +thatiparthy

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Gordon P. Hemsley]

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.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Gordon P. Hemsley]

Change by Gordon P. Hemsley :


--
keywords: +patch
pull_requests: +4909
stage:  -> patch review

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Julien Palard]

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 
shadowed by the C implem).

So renaming the copy method to __copy__ in the python implementation looks good 
to me.

Ultimately the Python implementation would require a __deepcopy__ too?

--
nosy: +mdk

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Gordon P. Hemsley]

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 __deepcopy__() method) which the Python implementation does not define.

Given that the documentation makes no mention of a copy() method and that its 
definition would be masked by a standard import of xml.etree.ElementTree, I 
propose that it be renamed to __copy__() so that copy.copy() can make use of it.

--
components: Library (Lib), XML
messages: 309010
nosy: eli.bendersky, gphemsley, scoder
priority: normal
severity: normal
status: open
title: Rename copy() to __copy__() in xml.etree.ElementTree.Element Python 
implementation
type: behavior
versions: Python 3.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com